   structure of a simple game
  Hey guys and girls, names X86Legend and I have a question.When designing a game, say a simple one like a 2d platform game (hush hush, I know its not simple but its alot easier then say, a 3d game) how do you go about with the actual structure of your Source code? Like, a game has a Title screen, and many different game areas, how do you go about structuring these?Do you have a many different classes that 'hold' the room, or do you do it all in one Class? I am curious because (Just having learnt Java) I feel like I would be well suited to learning a more 'Advanced' language such as C++, and since the Syntax of Java is very similar to C++ I was (Fingures crossed) hoping it would be possible for me to use my knowledge of Java to quickly learn C++ by creating a simple game. ===P.S Why is + + (Plus Plus, as in C Plus Plus) not visible in my thread?[Edited by - Sneftel on June 15, 2009 11:14:51 AM]
Quote:Original post by x86Legendsince the Syntax of Java is very similar to C++Only the most basic parts of the language. The really interesting bits of C++ have no counterparts in Java.Quote:Original post by x86LegendP.S Why is + + (Plus Plus, as in C Plus Plus) not visible in my thread?The preview is broken, but it works when you post it.   ;  I'm fairly new (at game programming with C++, not actual C++), but in a platform game, I usually break it down to these classes:The Game class: Holds levels. (Depending on the game it might also hold the player). This class is able to change levels, save the game, load, end the game, load the levels from a file, etc.The Level class: Holds a player, a camera and the tiles of the level. This class checks for collisions in the level and all those things, and sets the camera when the player moves.The Tile class: Hold one tile and its properties.The Player class: Holds the player properties. This class handles keyboard events to move and jump.The Render class: Holds the window properties. This class has a member functions to basically draw anything needed.Then, in each class I make, I add a "draw" function. For example, if you call the Tile "draw" function, it will check if it's within camera range and if it's supposed to be drawn, and if so, asks the render class to draw it.Same goes for Player class. Then the level "draw" function will call the "draw" function for every tile/player/whatever needs to be drawn in the level.   ;  For a large game, I believe a single level can be described as a collection of game objects, assets, and scripts.A game object is just an entity that exists in the game. It can be an enemy, or a player, or an NPC. It can even be a UI item, like a text box (for the score, maybe), or a button. Pretty much any entity in the game that has behavior is a game object.An asset is a raw audio or visual data file. So, it could be a sound effect, or a texture, or a 3D model, or an animation file, or something similar. The game objects usually make use of one or more of these files in order to fulfill the aural and visual aspects of their existence.A script would be a file that contains instructions for manipulating game objects through scripted events and sequences. This part is optional, because you can fully define an object behavior in your code if you want to. It's just, if your game is complex enough, you may find that it would be easier to describe certain things in a more simple programming language, like Lua, rather than use C++. This is especially true if you want to pass these tasks off to a non-technical person, like a designer. The big commitment with scripts, though, is that you have to write code that parses and interprets these scripts. You may even find that you want to write tools that allow you to create scripted events and sequences through a UI, similar to that of Flash or Maya, that generates these scripts behind the scenes. I'm getting into way advanced stuff, though. Your game may be simple enough that it needs no scripting at all.Anyway, I believe the best route is to create a scene management class that can load an arbitrary collection of object and assets (and scripts, if necessary) at the start of the level. Since the game objects have behavior that is defined in code, the level will sort of run itself.Edit: As far as rendering or whatever, I think that each game object should have two main methods: update() and addToRenderingList(). These can probably be pure virtual methods in an Object base class that all of your object classes derive from.When calling the object's update() method, you pass in the delta-time (i.e., the amount of time that has elapsed since the last frame). The object will query the input (if necessary) and update its position (if necessary).When calling the object's addToRenderingList() method, you pass in a pointer to the rendering list. This is just a list of all of the objects in the game that need to be rendered. It is inside this method that you do tests to see if the object is actually on-screen. If so, it adds a RenderItem object to the list that contains all the data that the renderer needs (position of the object, orientation of the object, and what meshes and textures to use). Some objects will be non-visual in nature and will not need to be added at all.So somewhere in your main game loop, your scene management class (the one that loads all of these game objects and assets) will iterate through all the objects in the scene, calling the update() method on each. Then, it iterates through all the game objects again, this time calling addToRenderingList() on each.Then you have a third step, which is the actual rendering. In this step, the rendering list gets passed of to the Renderer class to be drawn.That's sort of a high-level overview.   ;  In my game, Ghost Toast, I break everything down into objects and try to reuse as much code as possible.  This way when I go to create my next game, I don't have to re-write it all from scratch.For details check out the source code on my site, but as a big overview, I have one class that handles the OpenGL rendering, one class that holds the scenegraph, and one class that holds the user settings.All GUI objects are derived from one object, all loaded geometry comes from another class and all nodes in the scene are derived from a root.;  Well, there are many ways to do the same thing with different advantages and disadvantages.Usually it is a good idea to have a class for the things you can give a name, like Player, Level, Camera, Renderer, Enemy, Weapon, GameLogic and so on. Next you should try to avoid code duplication. For example the Enemy, Player, Weapon might share some code that could be put into a model class that is a member of base class of the other classes.I also suggest, that not all classes know all other classes. It makes sense that the GameLogic knows the Player, Enemy, Weapon class and so on, but if possible avoid that these classes know the GameLogic class.All in all, the best way to learn is to play around, rethink your design, try to do it differently, take a look at others, and retry again ... ;-)If you are used to Java, you might consider using C# for your games ;-)   ;  Thanks for all the great advice guys. 