What do you guys think about doing a collaborative project involving any member who wants to contribute to the best game ever?
I was thinking everyone has a partner and they are designated tasks. They can learn from each other, and in the process find bugs/improve the engine. I seem to know a little of everything, and all of nothing, and i’m sure there’s a lot of other people in my shoes, so if everyone has specialty areas to focus on, then all the code would be well written, easy to follow, and everyone could learn from each other.
I obviously wouldn’t be leading it, as there’s a lot more experience people who would do a lot better job at organizing it. I know a lot of people are doing their own projects (including me), so I was thinking maybe start in a month or 2. I just wanted to throw it out there, as I thought it would be a fun, show off the power of JME and everyone could benefit.
Would anyone be interested?
Actually, I’m interested. I have the same idea about a collaborative project. I want to make a scroll-shooter like mario(old game) or prince of persia(old game). It’s easy to make and easy to learn… At present, I have one 3d artist (his nick is Jama) and me (half-3d artist and started-programmer java).
I want to make a scroll-shooter as I believe it will be very interesting for tablets with Android 3.2. 
At present, I want to try making a game without physics… as old games were written without it.
So, if someone is interested, so we can join. Jama will make cool art and a concept.
MonkeyZone was meant to be that, nobody ever contributed.
IMHO I think that what JME really needs is a good WYSIWYG editor similar to the Unreal development Kit, CRYEngine Sandbox or the Unity Editor. This maybe is the only thing that JME needs to be a real professional development tool. Obviously there could be many other things that need to be improved but are things that are continuously improved What do you think in something like this?
However i know there are many plugins like the NeoTexture editor, the terrain editor, there wiil be the vehicle editor e many other useful tools but every thing should be used in the same environment and not in many little plugins…
Sorry me if i may be boaring but i’m sure that the only reason that could send away a professional team in using JME is this…
Erm, we have the SDK? ^^ And it is one application putting this all together? Editing of scenes will be unified so that you can use e.g. the TerrainEditor and SceneComposer at the same time on one scene. For specific things like navigation marks etc. there has to be libraries in the core engine for that first. For now you can edit everything thats available/relevant for a scene (e.g. spatial UserData, adding nodes, changing names etc).
Right! But, what about a bult in editor for water, effect, lights, environment-audio and a drag & drop from asset to scene system?
What i am talking about is a full level editor like the tool i’ve quote in the above post… JME doesn’t have something like a WYSIWYG editor where all is organized in sub menus and not in different plugin-windows. I’ve tried the plugins and olso a friend of mine that does really good jobs with blender, but in an artist perspective the plugin are almost cryptic…
And one of the first things that my artist said was that a full drag & drop system is the most important thing that a good level-design tool should have and JME isn’t mature enough to bhe used in this way…
@kazeshiro
Your best bet is to come up with a design document outlining what you think would be needed to alleviate the problem. Just saying “It doesn’t do this”, “it lacks that”, etc doesn’t do anyone any good.
It’s ok to criticize and suggest new features but we’re not mind-readers and often time more than not, the way things are implemented are that way because it felt right to whomever did it in the first place.
I’m sorry but my intent is to give an idea of what JME really needs and not to offend or criticize. I’m sure this is one of the best opensource project ever and my wishes are just the success of the project and not the fallen. What i was trying to say (my english doesn’t let me explain things in the right way) is that JME should include the functionalityoffered by the others game engine and if you try tools suche as UDK CryEngine Sandbox and Unity Editor, you will understand what i’m talking about.
It is not necessary to read minds, i’me sure that a looks into the above tools and a level designer surely will choose the editors instead of the JME SDK becuase it doesn’t offers tools like UDK and others… I repeat that is not my intention to just criticize JME, instead what i wish to do is to advice a needed tool for this project.
Had I make myself clear?
Ok, i’ts waht I’m trying to do, suggest a good project where everyone should contribuite… If i choose my future job, i will chose game development with JME, but a professional team will choose an engine that integrates a level-design editor that improves the production of videogame. Now, if i want to make a full static scene with skydome, terrain, textures etc. (to use in JME) the tool i can use is Blender(3DSM, Maya, Rhino…) with the ogre .scene exporter. This kind of tools should be used only for creating mesh and animations but for a fast development of levels, world and such things, the game engines offer a bult-in editor that improve this job many times. Don’t you think that a good game engine such as JME should include a tool like that? 
kazeshiro said:Don't you think that a good game engine such as JME should include a tool like that? ;)
I thought there was a lot of those implemented already. I can't say because my scenes are not static and are all procedurally generated so I'm not using those tools. But even you, in your first post, say these tools are there, just lacking some functionalities.
So if you think something should be improved then explain how. Details how things could be done, the behavior, the result, etc.
Many people are already using those tools and honestly you're the first person to post about this, maybe you and your friend need a new perspective, maybe you're not used to the engine enough, maybe your ideas are great and nobody thought about it.
Don’t worry. Critics are good. No bashing here.
You see, the thing is many of us use the engine the way it is and we think it’s ok. But if your experience is telling you otherwise then by all means do suggest how things that could be improved. It doesn’t mean it would be though. I certainly don’t wish jMP to feel like a copy of those SDK though. Just saying.
I really don’t think the majority of users will simply download the UDK or Unity to compare notes with jMP. If you want features, talk about it, suggest it. That’s what I’m saying.
kazeshiro said:
Right! But, what about a bult in editor for water, effect, lights, environment-audio and a drag & drop from asset to scene system?
All of the above is already possible, drag&drop not quite, but putting a cursor somewhere and then pressing a button comes close, no?
You’ve successfully derailed @wezrule 's original topic matter entirely.
@kazeshiro if you see any merit in this debate, please start a new thread about it. If you ask me, your most compelling argument came from the artist’s perspective. If you or your friend could tell us specifically “how I would like (or expect) to import my model into jME3 SDK”, that would be a great place to start, as it is small and specific enough for the developers to actually consider allocating time to improve upon it if the proposed workflow holds enough merit.
Getting back on topic: I think it’s safe to say there are plenty of people interested in this idea, core developers and contributors alike, and even developers outside the jMonkey community. But high interest is not always enough, as we learned first hand when MonkeyZone was announced.
- Great deal of interest
- Minimal involvement
The basic “share it & improve it” approach has worked fine for most other parts of jME, but, not surprisingly, games work a little different.
I do think we could make this work, but before I get into project vision and action items, the main problem behind this type of collaboration remains: We all enjoy different games. How do you suppose we decide, together, on a game we would all like to be involved with? We all know there’s no game-of-all-games we would all love. On the other hand, I’m not much for “design by democracy” online, whether it be by designing something together from scratch, or pitching several ideas against one another (e.g. by poll) and choosing the most popular one. The former tends to become a great mess of incongruous ideas, while the latter tends to lose traction quickly because even though one idea “won”, the “losers” greatly outnumbers the “winners”.
I believe we made some mistakes in the way we “launched” MonkeyZone, but what I think we did right was just doing it. At the end of the day it’s not the idea that matters, it’s the developers, and that’s coming from someone studying to become a game designer by trade.
MonkeyZone is still a great place to start, because:
- It’s supported by a core developer, @Normen
- It’s based on an established concept (BattleZone) that can easily be expanded upon (into entirely different genres of gameplay even). This greatly simplifies vision & design, seeing as we have existing visuals to point at for rudimentary examples of gameplay.
- It’s a fairly minimalist concept. As in, it requires a rather small amount of working mechanics & game assets to be playable.
I think we could do better by:
- Having a detailed design doc, describing the key features and core mechanics of the game.
- Making explicit calls for participation, with direct guidance & mentorship. This seems to be working quite well so far for SDK plugins.
- Being more public: Frequent blog updates with guest posts and how-tos. Dedicated twitter tag & YouTube playlist.
These are all action items by and large within my own area of comfort & expertise, so I’m confident it could be done.