Slick Forums

*
I'm copying this from another forum (GameDev) since I didn't get an answer there. Sorry about that.
*

Hello.
I have been learning game programming for the past year, and I have made some small tests and prototypes to test my skills (for instance a Tetris clone, a 2D platformer etc), and now I'd like to start building a bigger game. But I have a big problem - I don't know anything about games' architecture. I'm talking about big games like World of Goo, VVVVVV, Super Meat Boy and Braid. I can't just start writing a game as big as those into a few of classes. I used only 2 classes in the Tetris clone I made, but now I really have to learn how to keep things organized in the game code and start learning some game architecture.

I hope someone can explain these things so that a beginner can understand what each branch in the game code should hold.
Some of the things a game's architecture should have (AFAIK) are

• GameStates
  
  • MainMenu
  • InGame
  • InGameMenu(Pause, Round end)
  • etc
• ResourceManager
• Renderer
  
  • Subrenderer
    
    • CharacterRenderer
    • World's Static Objects renderer
    • btw, how to manage entities' rendering order?
    • etc
• Logic
  
  • GameLogic
  • Simulation
    
    • SubSimulation
    • PhysicsSimulation
    • Ai
      
      • PathFinding
• World
• GameAccessPoint
  
  • Init
  • Input

Some of the things listed there might be in wrong places, but the point is that the tree is huge! and I need your help.

*

I'm using Slick2D, so please tell me if you know any time-saving classes inside the library, when designing the architecture. Basically, I'd like to know a class architecture that is efficient when working on a big project.

For architecture, my suggestion is to decide what kind of approach you want: some classes, entity-component (Artemis approach: http://www.gamadu.com/artemis/) or some utility classes bind together (MarteEngine, see signature).

A obvious question is: have you planned your game? Because if you have written and made some thought about it, you can think about architecture

_________________
Blog | Last game Gravity Duck tribute | In progress Gravity Duck tribute

I think more important than anything in a "big game" is a solid set of tools for content creation. I don't mean Tiled; I mean a start-to-finish game creation toolset geared towards your specific engine: where you define new levels, game states, in-game GUIs, etc. all within your in-house editor. You won't have an "OptionMenuState" or "InGameMenuState" class because you've defined that from within the editor.

Of course I have planned some basics about the game I want to make, but don't yet have all the details. It's a singleplayer 2D platformer/puzzle game which has different chapters and levels. The level system would be similar to the one in World of Goo, like, the game has five chapters and each chapter has multiple different levels. The game will have many different kinds of entities/objects, like Super Meat Boy has. Spikes, blades, enemies, animated background objects, physics objects, switches, scripted events etc.

By this definition (I think) at least some basic guide lines about the software architecture can be drawn. The resource manager, input, simulation, world and gamelogic (for example) is pretty much the same for all the games that match these criterias, but I don't know the most efficient architecture for these classes, or how they are linked.

I will use JBox2D as the physics engine, and I'm planning to build my own very simple level editor (as a separate software) so creating the ground for each map with static bodies is easier (than typing manually all the coordinates of each static body's corners).

I was thinking about building just the foundation for the game first, making the code re-usable. Let's assume I'm making World of Goo from the ground up using Slick2D and JBox2D. What kind of architecture would fit my needs?

I don't know what World of Goo plays like, but if it's not your generic 2D platformer, then a "one-size-fits-all" architecture will most likely be futile. It would be best to know exactly what your game needs before building its engine/architecture.

Do you know the game Super Meat Boy? It might actually be closer to what I'm going for.


YOUTUBE LINK
The video shows the level system of the game, some gameplay and the way how the game switches between GameStates from the chapter-menu to the level-menu, then in-game and pausemenu etc.

My game idea is basically SMB with physics puzzles, better special effects, proper story and scripted events.
btw, telling me a generic 2D platformer architectural solution might not be a bad thing, as I might learn from it.

I think I have to start it from the resource manager and the world class. Slick already has a built-in main simulation loop, so after the resource manager I guess I should divide the loop into different sub-simulation classes - Physics, Ai etc.
I just need a more in-depth guidance on these things.

I used to be like you, worrying about having a good architecture. I'd ask other people for advice and got frustrated because they never gave the answer I was looking for. So I began coding and implementing one thing at a time. Starting with having a red square move around, and then having a tank shoot at other tanks, and then having nice menus, to having, and finaly having a multiplayer mode. All this without having any plan on what the game architecture should look like (actually I didnt even know what kind of game I wanted to do, it started off as a strategy game, and ended up as a top-down shooter. I came up with ideas for the architecture while progressing with the game. Sure, I've had to change a lot of code, even totally redo whole classes. So my advice to you is stop worrying. You'll learn what works and what doesn't while working on the game.

Hmmm if I was making a 2D platformer with traps I would...
Have the GameStates.
I would probably have a class for terrain and either have it able to be all types of terrain (via passing variables) or have classes that extend it to the various types of terrain.
If you are loading maps from a file, I would have a class for that.
I would have at least one class for enemies and I probably would extend it for each type of enemy.
I would probably have the AI in the enemy classes themselves. Unless you want the enemy's to act together, in which case I would have a master control AI that would give orders to each of the individuals.

------------
General rendering order.
1. Render background
2. Render terrain.
3. Go through the enemy's and render them.
4. Render the player.
5. Render foreground elements of the terrain.
6. Render the user interface (Health, HUD, etc)

-----------------
You're gamestate should contain the input code. You'll be detecting input events there anyway for the gui elements, so you might as well have it all there and pass commands to the other classes (like the player, enemies, bullets, etc)

-------------------

General rules of thumb:
If it is only 1 method or only a couple paragraphs long that's used only in that class... you don't need a separate class to hold it.
If it is something you reuse everywhere... then you might want the code in one spot to make reusing it and debugging it easier. It will reduce the chances of bugs as well.
You might consider shunting code into a new class if a class is getting very large and hard to read.
Stuff in a class should be related and make sense that they should be together.
Comment, Comment, Comment you're code. You might not remember what a particular method does when you go back and try to debug some code you haven't looked at in a month. So remember to Comment it! /** **/ is your friend.

--------------------
Cool tool:
http://findbugs.sourceforge.net/ <- This is an awesome tool that catches some bugs before you run the code. Easy to install if you use eclipse, though you will have to enable it to run automatically for each project.

Thank you!
The last two replies are great!