   How do you structure your game around OOP?
  How do you structure your game with OOP? I am itnerested in learning different ways people do this.What I do is make a MainGame class, which does everything. in my Main() I create the MainGame class, and the game starts and runs through the MainGame class.How do you structure you game?   
  I use objects only to represent objects - compound data with states and a set of operations that pertain to them. For everything else I just use functions. There's nothing wrong with writing functions that don't live in classes, you know.OO is a tool. It shouldn't become an ideology, particularly an exclusive one.   ;  depends on what type of gamei usually have some inherited classes for sprites and other draw objects,but unless your using java or something i woundlnt create a class for something like main, if you dont need to pass refrences or create multiple instances just use namespaces in c++ or global moduals in .net   ;  I started working on a new concept in C# by creating an Interface called IGameStatethen I had another class that something like the Stack class called GameStateManager then I'd be able topush and pop classes that use the interface IGameState from the stack.Now the IGameState interface has two functions called Input() and Render() whichboth return a boolean then the GameStateManager goes through each gamestate onthe stack and if the gamestate returns true then it stops going onto the nextgamestate. Doing this seems to have made game programming so much easier.   ;  I'm using system of Systems ;), that means "big", independent, singleton class which use each other e.g.Engine - Main class initializes all other systems, do game loop job.Has states: startup, gui, play, load etc.GuiSystem    - shows and operates gui,GraphSystem  - :)InputSystem  - reads user input and sends it to the Engine,PhysicSystem - looks after physic and collisionsPlayerSystem - looks after player game entityAISystem- do AI work for all AI entities in the gameResourceSystem - keeps and manages resourcesEntitySystem   - keeps tree of entities, and do it actions. It's make on the basis of the http://www.devmaster.net/articles/oo-game-design/ articleentities - the most important part of the engine, have states, signals and actions. The game is one of the entities :)Such structure give you possibility to change internal implementation of all systems e.g. GraphSystem can be own 3D engine or uses external 3D engine (I'm using Ogre)   ;  the best architecture i've ever used i got from Game Coding Complete.It uses the Application/Rules/View paradigm(ala Microsoft)if you're dealing with a project with a large scope i've found it work pretty well and i strongly suggest the book. :)   ;Quote:Original post by Dreddnafious Maelstromthe best architecture i've ever used i got from Game Coding Complete.It uses the Application/Rules/View paradigm(ala Microsoft)if you're dealing with a project with a large scope i've found it work pretty well and i strongly suggest the book. :)Seconded. That book has LOTS of good information about how to structure not only your game architecture, but the code directory, resources, etc.;Quote:Original post by OluseyiI use objects only to represent objects - compound data with states and a set of operations that pertain to them. For everything else I just use functions. There's nothing wrong with writing functions that don't live in classes, you know.OO is a tool. It shouldn't become an ideology, particularly an exclusive one.Hear hear!  Even more strongly: OO is a means, not an ends.  The question you (the OP) pose implies you think OO is an ends, but there is no intrinsic value in OO in and of itself.  For each problem you face you should ask yourself, can OO help me structure the solution to this problem?  The answer isn't always yes, so blindly trying to OO-ify every problem is the wrong thing to do!As for how we structure our games, the overall gameloop is functional, with an INIT - LOOP { GAMEUPDATE } UNTIL DONE - CLEANUP setup. No OO there.;Quote:Original post by OluseyiI use objects only to represent objects - compound data with states and a set of operations that pertain to them. For everything else I just use functions. Behavior is state as well.;Quote:Original post by Christer EricsonQuote:Original post by OluseyiI use objects only to represent objects - compound data with states and a set of operations that pertain to them. For everything else I just use functions. There's nothing wrong with writing functions that don't live in classes, you know.OO is a tool. It shouldn't become an ideology, particularly an exclusive one.Hear hear!  Even more strongly: OO is a means, not an ends.  The question you (the OP) pose implies you think OO is an ends, but there is no intrinsic value in OO in and of itself.  For each problem you face you should ask yourself, can OO help me structure the solution to this problem?  The answer isn't always yes, so blindly trying to OO-ify every problem is the wrong thing to do!As for how we structure our games, the overall gameloop is functional, with an INIT - LOOP { GAMEUPDATE } UNTIL DONE - CLEANUP setup. No OO there.While i completely agree with you & Oluseyi, your game loop example isn't functional at all, it's an imperative loop, no doubt doing a stateful computation in the "GAMEUPDATE" bit.That is not to say it isn't not possible in a purely functional setting because it is via monadic programming and a hint of syntatic sugar.   