I’ve worked my way through the various tutorials and feel ready to create a simple game. However whenever I try to start I face a strange problem. I just don’t know where to put my code. I’m coming from unity3d. In unity you write short scripts that are attached to objects in a 3d scene graph. These scripts can access properties of their object and the underlying engine as well as a special framework for math, networking… To make the scripts do something you can also override functions like update, onTriggerEnter, … This is very easy to understand and puts the 3d objects in focus. One object can have dozens of different scripts and scripts can easily be reused for various objects. In jme you write the entire game as “code”. Up to now I have understood how to create new nodes, add light and physics simulation but I don’t know how to put it all together. I think the key to all of this is called “control” and I tried to figure out how to use them by analysing an example project - MonkeyZone. Well, I failed. MonkeyZone is just too complex to use it to learn the basics.
Can you give me advice how to structure my code?
Do you know a good manpage or tutorial?
Thanks in advance.
First of all I guess there will be no way around learning java and basic application structure (e.g. Objects, Classes, static and non-static Methods etc.). For starters you can simply put your code in the Main class that is generated in the Project. Then read up in the documentation on how to split your code for single objects and global game code into Control- and AppState Classes.
Since jMonkeyEngine is not restraining the way you do your game in a way like Unity does it to achieve a more UI-based approach to game development the implementation of all logic like “where do I put AI code” is in your Hands completely. Though we give you some programming patterns at hand that are very well supported in the engine and will eventually find their way into a more UI-based approach to coding with special project types.
I faced the same problem as you a while ago (and still learning as I go). I think MonkeyZone is an excellent example to work from though even though it is quite complex. My main reason for looking at MonkeyZone was that I had no idea how to work with controls and how to get something acting on the code that is in the control. So I started by ripping out everything from MonkeyZone that I did not understand which was most of if lol
The way I did this was to take the ClientMain as base and going line by line through it and first just commenting out anything that I did not understand or want in my game, then running it and seeing what it complained about and fixing/removing more. So I ended up with a fairly watered down but usable template that did not have any networking functionality and still contained a great base to work from with Controls, Statemanager and even has NiftyGui integrated in it
Not sure if this helps, but I think MonkeyZone was purposely written for us to learn from by having a fully complete example, and you do not need to use all of it, just the bits you need. I also kept all the class names etc. the same as in MonkeyZone so that when I do get past the point where I now would like to use some of the functionality that I ripped out, I can go back to MonkeyZone and look at how it was done there (eg. networking)
@jatheron Thank you for your help. I’ll look at MonkeyZone again. Up to know I just read but didn’t really touch the code for fear of breaking something. I guess you’re right: It won’t hurt to tear the project apart.
@normen I already have experience in Java: I learned it for the uni and made a few simple projects.
Though we give you some programming patterns at hand that are very well supported in the engine
This is exactly my problem. I don't want to end up with an unusable architecture. In unity3d the way to go was quite clear but even there you had to plan every detail for a functional game with readable code. I would like to know what pattern is suited best for organizing the code and how to use it the jme way. If there's a good manpage for controls could you please post a link? Maybe I've been blind but I didn't find the information I needed.
The structure i use (have 100+ classes now :(), is to organize my packages like follows:
controls (30 classes) (all logic for objects)
graphics (50 classes) (every object is a class)
level (5 classes) (controls the game)
sound (2 classes) (sound effects)
ui (10 classes) (GUI, main menu, other HUD elements)
util (2 classes) (random stuff i didn’t know where else to put)
fileIO (reading/writing files)
… and few others specific for my game
and have inner packages for specific things inside them to organize everything a bit more. Obviously it all depends what type of game your making, but i would say something like what i wrote would be the general case, but people do what ever they want, theres no right answer.
zwillenguru said:If there's a good manpage for controls could you please post a link? Maybe I've been blind but I didn't find the information I needed.
Under "Best Practices" and specifically "AppStates" and "Controls":