So, I’m rebuilding my game engine for a slightly fresh start; I’m going to use all of my resources and what-not so that the game will be back to where it was in a week or two, but this time I want it to be pleasing to open up.
So, how do you organize your games? This is going to be a bigger RPG project, so I really do need a way of keeping everything together, but altogether organized.
Like, for example, how do organize different environments, the objects, and the logic related to that?
First you need to understand completely each class’s behaviour. Try to pull out common things that they can share, and make a class to resemble it. If you’re unsure with some method, make them abstract.
It helps me to actually write things out. Not necessarily text but to draw the different classes I need as boxes and write inside them the things they need and then links things together. This helps me so when i code I am not writing stuff that will change almost right after I write it.
My trick would be to use inheritance only for main behaviours and natural things and use composition / injection dependances to glue others functionnalities.
It let you more flexibility after to construct more variants of behaviour than inheritance that may block you in an inheritance tree for a specified functionnality.
An UML will help a lot.
You dont need to actually make it fully propper, but having a simple Graph with classes, methods and dependencies makes
you organize your code before coding it.
Already by designing the UML (or a simplified version of it)
And you can later look it up to not get lost in how your many classes interact.
I always start by writing a Prototype first wich runs quite well, and lets me play around with features.
But it gets messi and hacked.
At a certain point I completetly rewrite the project, using the prototype as reference (and copying some parts, but not all of it, mostly only the novel tech)
Since you have the prototype you can concentrate on propperly planning and implementing your architecture, as you have a concrete reference of
how it should look like in action.
Hi
Of course, I try to avoid circular dependencies between packages. I combine a scenegraph with several state machines and some schedulers. I have a class per type of state machine, I use state machines for the main step in the game (PEGI, intro, main menu, etc…) and for the player(s). The schedulers are used to postpone operations in state machines until conditions get satisfied. Moreover, I try to separate the Model, the View and the Controller but I admit that the separation between the Model and the Controller is sometimes not clear. I separate the concerns, I avoid creating too big classes. I agree with advises suggested by divxdede. I use Fettle API for state machines, it is simple, small and it just does what I expect. The whole architecture is organized in several layers so that high level objects never have to use raw OpenGL. I try to avoid using anonymous and/or internal classes. I try to allow to override almost everything because I cannot imagine what people will do with my source code, it would be better that they can use the JARs as is without modifying it because an extra useless final declaration. I agree with Damocles too about UML but I use it differently, I iterate, I modify the design, I don’t try to have a “perfect” design at the beginning but I try to keep something nice at each iteration.
Still wonder why that’s my fav way.
There are 2 times
A time to prototype, and quickly realize a vision, test a new mechanic and throw together stuff to get an impression.
And
A time to sit back and thinker about how badly hacked this prototype is. Then to raise and craft a nice and propper architecture
of how to let the project look like the prototype, but please the inner propper Computerclass teacher.
-> rewriting (its not a waste of time, but a smart way to combine testing new ideas with planning a clean implementation)
A vague question.
First, define your requirements. Don’t try to be a visonary, but know what you want, can do, and very important, can not do. A “bigger RPG” is, hmm, somewhat alarming.
Start with modules or layers. Clearly assign responsibilities, like e.g. for rendering, actors, logic/AI, network. Don’t mix things up. For example, the whole game should be runnable without an attached view. No imports of graphics classes in your logic packages.
Stay clear of package cyclic dependencies. Use a tool like JDepend to help you.
Like mentioned, use inheritance with caution.
Read, no, buy the design pattern book, if you haven’t so far.
Drawing diagrams is good, doesn’t have to be official UML. The best UML tool is the cheapest as well: paper & pencil.
Concentrate on one task at a time. Use JUnit tests for fast developing and verifying of functionality. Don’t waste time on tasks with minor priorities in the beginning.
Keep your public interfaces (meaning interface and class methods) as small as possible. No public member variables. Stay away from statics.
I’ve always found this to be a tedious waste of time IMHO. If I can borrow a phrase from Cas “object orientated wank”.
Agreed; you want stuff on screen, as soon as possible.
Pro tip: do all the title screen, menus, and options first, before you start the game. Because you won’t want to do them afterwards.
Cas 
I’m not into overengineering either to which the whole Java world is prone. And I have seen enough bad examples in the domain of business applications.
Primarily, this is not about object orientation, but about separation of concerns and modules.
I would even suggest the opposite: it saves time in the long run
It goes very far but if you succeed in following his advice, it means that no rendering code is mixed with the logic code which is fine in term of separation of concerns. For a turn-based RPG, it is quite doable, isn’t it? Moreover, if this “bigger RPG” has to work in a client-server architecture (not P2P) with an headless server, this last one should not run rendering code.
Both of which are utterly irrelevant to getting a game done. It might produce nice ‘architecture’, but it’s additional complexity for zero actual practical gain. Not all abstractions are born equal, and separating logic from rendering for any non-trivial game is a massive net loss.
For client/server it’s more viable, but I’ve always found it more practical to have a ‘null’ renderer / render backend that hands out dummy Model / Mesh etc. instances. (I believe Unreal does this as well btw).
Note that I’m not saying that you game logic should be scattered with GL or Java2D calls, but there’s nothing wrong with it dealing with higher level visual objects like Sprites or Models.
Indeed. If you’ve got completely separate “Sprite”, “Effect”, “Emitter”, “Particle” and “Game entity” classes you’re well on your way to achieving everything you need to achieve.
Funny factoid: all my games are basically the same. Yes, even Revenge of the Titans compared to Ultratron. They’re so similar that the way we actually start a new game is literally to copy and paste the entire project in Eclipse and then rename the packages. I always end up with the same general structure: Entity class with a bunch of subclasses such as Player, Bullet, Building, etc. Game screen. Game state. Then a few bits and bobs like Weapons, etc.
It helps that the whole lot is sat largely atop a fairly stable set of libraries that handle sprites, particles, special effects, GUIs, etc. However these libraries didn’t grow in a vacuum. They were developed without great thought placed into reuse of neat API design as part of other games; gradually when I realise I want to pinch a bit of code for another game I have a think about whether it’s worth dragging it out of the original game and trying to make it work with another game. A lot of extreme refactoring goes on to achieve this, but then, I’ve now got 4 games to manage simultaneously with it all and making sure stuff doesn’t break is increasingly complex.
Cas
I am going back up princec and Orangy Tang. Working game first. Playable faster is better. Working code is better that well designed code that is not working.
UML? what? UML is so some MBA can give a talk about your work and show a picture to pretend that he/she even knows what it is that you do. I have never found such things useful. Simpler class diagrams perhaps, but only auto generated ones that use the live code. Not some version of the code from 2 years ago.
Fact is that no matter how much you design ahead of time. It will be wrong by the time you write up even 20% of it and you will know it. So good enough is good enough, and that means some idea of a design and direction, but then write code. Code code code. There is no substitute for writing code.
And writing “good” code for the future. You don’t know what that is so you can’t design for it. Write code to do the job in front of you now well. Chances are that that is the best future proof code. It has nothing more in it than it needs.
There was a time when I would make the “tools” my game would need in a way that I could use them in other projects. This soon became a complete mess to work with all these shitty “tools” I’ve made, most of which needed updating anyway because I’d have found better ways of doing things.
So I quickly scrapped that methodology and now I always rewrite everything and make things specific to the game and add things as I go along without worrying about making the class super flexible for other “future” projects.
I just rigorously sort similar things into folders/packages and I even use a few static classes (singletons actually).
A UML may help. I find myself tweaking/rewriting the UML constantly. UML are of much more help (imo) in group projects and coding things designed by others… or when you know what you’re doing (like in your case).
The practical gain is that you spend less time in fixing bugs with such a nice architecture. When you don’t separate enough things that could be separated, you have to do this separation in your mind anyway when you have to fix a bug (and to do it each time you think about the code), that’s why I agree with 65K. Separating logic from rendering is a bit difficult when you’re not accustomed to do it but as time goes by, when you take good habits, it is no more an effort, it becomes natural. I do that both in business applications and in games.
If the source code becomes too much ugly, you won’t probably even want to improve it at a certain step. If fixing bugs requires too big an effort, it may discourage the developer(s). Imagine that your girlfriend or your boyfriend becomes extremely ugly, I assume you won’t want to spend any time with him/her. That’s the same thing for the source code. Personally I can spend some time in dirty code but I have my own limits; if I can’t improve it, it becomes really discouraging.
For a big RPG I’d think about writing the world building tool first.