I’ve gotten to the point where I’m fairly comfortable with lwjgl, however; my issue is that when I start a new project, I have issues deciding where to put everything in the overall structure.
ie: I don’t know where to put certain rendering methods to make everything easier on myself.
Are there any design structure articles or references that might be of use to me?
or do you guys have any suggestions on how to plan out the structure of the game?
One of the problems that I have when I code is that I think I have to get everything right the first time. Just remember that if you put a method in a class, it’s not permanent. If you realize that you don’t like where a method is, then change it. Also, remember about what that method is going to have to access. Can you just pass in parameters, or does it always need to access instance variables?
I’ve heard that writing out your structure on a piece of paper is very beneficial (ex. boxes are classes, lines are methods); and although I’ve never tried it (I probably should), it sounds like it would keep me from having to refactor a lot in the early stages of development. Basically start with a main class Then, you can draw lines to other classes based on how that main class should access them.
Really, I think it’s just an iterative process. You start with something that ‘works’, then you make into something that you like to use.
I tend to use Lucid Chart, it is a free but limited flow chart creator.
I find it quite useful when designing basic structure, I have used it quite heavily when dealing with complicated logic in classes, to keep track of each stage of the code and minimize errors.
Couple of techniques for organising your ‘thinking’:
Nouns and verbs: If you’re starting a new project or a new feature in your game categorise your ideas into classes (the nouns) and methods (the verbs), a simple UML diagram will help you organise your thoughts - or it helps me anyway.
MVC (Model-View-Controller): Another way to work out where to put everything is to categorise your code using the MVC design pattern, quick summary: the model is the state of your game (entities, events, etc), the controller(s) manipulate the model (player actions, animations, game AI, etc) and the view is the representation of the model to the player (scene graph, UI, etc).
Cohesion: A good way to check that you’re organising your code as best as you can (and it will never be perfect) is to consider how concise each chunk of code is, i.e. does it have a straight-forward purpose? is the ‘API’ of that code clear and simple? If the answer is no then you might want to reconsider the design, break that class up, etc. A good test is whether that code can be easily unit-tested, if you find that it’s complicated to test then the code is probably a bit messy.
Just some random thoughts off the top of my head, hope it helps.
My take on this topic:
Logic:
Just slam the code in the same class. Once you can see that you need to move it somewhere, do it. There is no point in structuring the code if you don’t feel like it. If you code is perfectly readable without structuring it, whats the point of doing so?
I agree with most of this however I don’t believe that just “slamming” it in a class without thinking it through.
Imo you should at least have a basic idea of what is going where, a couple to note are:
However for everthing else, just go for it. You can chop it up into chunks later.
I don’t create complicated design docs etc. because my project is a solo one.
However, I try not to sit down and program unless I have a clear mind and conceptually have a plan of action of what I’m trying to do.
This often requires multiple hours of not being in front of the computer, going for a walk, or some other activity to encourage the subconscious.
With a clear mind I can sit down and bang out a feature in an hour or so. Without one, I can sit in front of the computer all day and whatever comes out is pure crap.
And to answer the OP’s questions: get it working first and then refactor until you can stand the smell. It’s pretty much impossible to plan something you don’t yet know how to do.
There’s no single good way to structure your game. It depends on the type of game you are making and your personal preferences. As other suggested, the best way to learn this is by doing it. Make a couple of small games (like tetris or breakout), read up a bit on game design and things will start to fall into place.
Some good approaches to structuring game code are the mentioned Model-View Controller approach, or the entity system approach, e.g. used by Artemis. However, you will most likely notice that while these approaches are helpful, they are nearly impossible to follow strictly.
Sites like GameDev.net or Gamasutra also have a lot of articles on this. Learn by doing and reading.
Thank you everyone for the responses! You’ve all given me some stuff to think about, and hopefully I can use this to get my head in a different state of mind while creating future programs.
One follow-up question though:
Some of you mentioned certain standard program models such as the model-view-controller approach, and the entity structure.
What are some other common structures that I could research to get a basis to work from?
Only thing I can think of is to learn the concepts behind Object Oriented Programming well. If you understand and can apply MVC, entity systems and OOP you are already ahead of most (game) developers.