6
\$\begingroup\$

I'm going to make a snake remake with SDL library and right now I'm thinking heavily about the object-oriented design.

I can imagine that I will have classes like GameEngine, Snake, Board and Food, but the interesting part is - how shall they interact between each other? How shall the game logic be designed?

For example, let's imagine here are some of the possibilities:

  1. Every class except of GameEngine will hold only it's data (position of snake, food, etc.). All the game logic will be done in engine's Update() function. Therefore this function will be very big and every other part of the program fairly small.
  2. GameEngine will only call appropriate functions of every object with the reference to Board and these individual functions will take care about the game logic.
  3. something other

So I would like to know your opinion - what approach do you think is the best? I'm not aiming at low number of lines the game will have, but at the quality and "modularity" of the game object design.

\$\endgroup\$
2
  • \$\begingroup\$ You need some layer in between. I would have GameEngine calling CoreGameScreen (later you'll have a title screen, right?) which will have state for your board (complete with snake + food). \$\endgroup\$
    – ashes999
    Commented May 26, 2012 at 13:34
  • \$\begingroup\$ Also, you may want to look into component architecture for games. \$\endgroup\$
    – ashes999
    Commented May 26, 2012 at 13:34

3 Answers 3

10
\$\begingroup\$
  1. Option 1 is a very bad idea, you might aswell be coding in BASIC.
  2. Option 2 sounds good enough for a Snake remake. Now start coding! :-)
  3. If you were making something bigger than Snake, or are just using Snake as a toy project to get to know more advanced software engineering practices for games, go for option 3: .
\$\endgroup\$
4
\$\begingroup\$

Here's what I would suggest:

Start with a GameObject class. These will be objects that can interact with each other. Then, derive three children from it:

Snake, Food and Wall. Each will have its own Update function. Finally, you have a Scene which holds a list of GameObject's. The main loop calls the Scene's Update every frame, which calls the Update function for each object.

Then you can start thinking about how each object interacts with each other. A final suggestion: let the Scene keep track of the score. It will probably make things easier.

\$\endgroup\$
2
  • \$\begingroup\$ Good idea, I have already thought about it, but only a little. I will think about it, definitely. \$\endgroup\$ Commented May 26, 2012 at 15:04
  • \$\begingroup\$ Another class name commonly used in games for same role as "GameObject" is "Actor". A actor is an object (eg: player or enemy) that can move on screen and interact with other objects. The class should hold attributes and methods that all actors have in common : position/rotation angle, texture/sprite number, current animation and such. \$\endgroup\$
    – tigrou
    Commented May 27, 2012 at 18:11
0
\$\begingroup\$

My approach is create two main classes:

  • Sprite: Background, npcs, etc. has methods and properties related to loading images, etc.
  • Object: Inherits from Sprite, it's a more advanced Sprite, usually an npc or player, since it has properties/methods for collision, moving etc.

Then you create different classes/objects from those classes.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .