Cool. The main reason why jME doesn’t supply any special game class implementations in the core is that jME is not a one-trick pony and we don’t want to limit the users possibilities. Just for “entities” (whatever that is ;)) theres many ways they can be done and some prefer to do it this way, some another. So the jME3 core will always just provide the tools so that you can make and organize a game the way you want it.
Having said that though, we planned to do basic “game type templates” with things like special map editors / scene composer extensions for things like spawn markers etc. for a long time now. They would be external libraries and jMP extensions bundled as jMP plugins. If you really plan to integrate this in the jme economy and keep working on it I suggest making this a jME SDK plugin. Maybe you can kickstart something in the game template direction.
@normen Yeah. I know that jME doesn’t have those things, but that is why I wanted to create this. This is pretty much a base for games, but doesn’t hide jME in any way. Really, I’m creating this to make game creation faster for me, but helping others at the same time is even better
The difference between jME and JCE is that they are totally different things. jME is a game engine, while JCE is a base for a game that uses jME. jME is great for starting from scratch on a game without worrying about assets, rendering, sound, and other stuff, while JCE provides a base so you can start working on content faster.
He was taking about jMP, the jME3 SDK. It also allows creating new projects with premade files, editing models, editing parameters of objects etc. etc., no need to create a new application for that… Thats actually why the jME3 SDK (jMP) has been created, to avoid so many scattered projects as it was in the times of jME2.
Oh. This has nothing to do with jMP. jMP is an editor and sdk. This is an actual ‘game’ (if you can call it that) built on jME. You could use jMP with JCE, but I don’t personally (had a few problems with it, so I just use normal netbeans).
So what kind of game is it? I don’t think its wise to expect that people want to set up their programming environment the way you yourself like to do it. Are you using the Controls and AppStates as suggested n the manual? If not you dont make it easier for people to create games but harder because they have to bridge your system and other jME3 code. Also why can this not just be a project template for jMP if its “just” a game without content?
I guess you could call it a template. I don’t mean it is really a ‘game’, so I guess it is a template. I just didn’t really know what to call it. The reason I’m not really calling it a template I guess is because I plan for it to be a bit more than that. Possibly something like the source engine, where everything, from game logic to menus, is already done, and you just have to modify it a bit to do what you want. I’m of the opinion that you should spend less time coding and more time with the content like maps if possible. If you are making an FPS, then just take the code, modify it a bit to maybe add some new weapons, then map your heart out (and I’m trying to mimic Source’s ease of use for making dynamic maps with I/O)
Also, there is absolutely nothing that says you have to set up your environment ‘this’ way. I use netbeans, but you could even use nano if you really wanted to (ok, I don’t suggest that…)
In terms of controls and AppStates, there is nothing in my code that stops you from using them (actually, as of right now I don’t have anything that would use them just yet). The state machine in my code is used for different things than what AppStates are used for. My game states are used more to control things like menu hierarchy and such instead of how to render things. Using them together wouldn’t be too hard. The game states are used more for setting up a scene or menu and then it lets some other object do the actual work.
You also don’t have to ‘bridge’ my system to jME3 code. Everything that I do is done with jME3 libraries (and nifty and bullet…).
The internal logic you would use for a FPS game or a strategy game or something else would differ quite much. Nifty provides a simple way to display UI items, also here simple templates for jMP would allow easy creation of GUIs for any game really.
For the bridging thing: What I mean is not bridge class types or anything but code logic. If you are using Controls in your games to modify spatials and entities as suggested you will have a big set of reusable classes after a while. If your system uses a different logic to enable actions or save data then the user has to bridge that.
For example Paul Speed used some code in Mythruna that he had lying around for years before he finally really used it in Mythruna. The game itself is set up in the way that Paul likes to set up his systems so he was easily able to integrate his code of course. If he had to adapt his code to a system like yours just to use some functions of it that he likes that would be the kind of “bad bridging” I am talking about.
Now you surely have the argument that this should “allow newbies a quicker start with jME3” and I agree. However, when you start out with a simplified system you are confined to that simple system (one trick pony) and have not really learned much about the system behind it. Thats why I would urge you to do the implementation according to the guidelines we give in the manual. If you have a system that somehow modifies a Spatial then you should have Controls in it.
When I wrote MonkeyZone I really found out that to do a basic game you do not have to write any “system base” code with jME3. Its all there. Just use a spatial as entity, use controls as components, some spatial UserData and you are done. Then the editors of jMP really just become map editors. All code that I wrote (except for net syncing) was basically real game code, specific to my implementation.
So I dont want to sound like I wanted to stop you from doing what you plan to do, actually I want to push you to actually do it… But maybe you can consider making this more of a set of templates for jMP (e.g. base classes, gui elements, tool classes, whole example projects etc.) and then even extend it with visual editors for jMP (e.g. to edit special maps for entity classes that implement wayfinding etc.).