Sign in to follow this  
Mr_Fhqwhgads

How do you structure your game around OOP?

Recommended Posts

Mr_Fhqwhgads    100
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?

Share this post


Link to post
Share on other sites
Oluseyi    2115
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.

Share this post


Link to post
Share on other sites
Kaze    948
depends on what type of game
i 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

Share this post


Link to post
Share on other sites
Razor89    134
I started working on a new concept in C# by creating an Interface called IGameState
then I had another class that something like the Stack class called GameStateManager then I'd be able to
push and pop classes that use the interface IGameState from the stack.

Now the IGameState interface has two functions called Input() and Render() which
both return a boolean then the GameStateManager goes through each gamestate on
the stack and if the gamestate returns true then it stops going onto the next
gamestate. Doing this seems to have made game programming so much easier.

Share this post


Link to post
Share on other sites
Ocelot    375
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 collisions
PlayerSystem - looks after player game entity
AISystem - do AI work for all AI entities in the game
ResourceSystem - keeps and manages resources
EntitySystem - keeps tree of entities, and do it actions. It's make on the basis of the http://www.devmaster.net/articles/oo-game-design/ article

entities - 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)

Share this post


Link to post
Share on other sites
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. :)

Share this post


Link to post
Share on other sites
Oberon_Command    6088
Quote:
Original post by Dreddnafious Maelstrom
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. :)


Seconded. That book has LOTS of good information about how to structure not only your game architecture, but the code directory, resources, etc.

Share this post


Link to post
Share on other sites
Quote:
Original post by Oluseyi
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.

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.

Share this post


Link to post
Share on other sites
Arild Fines    968
Quote:
Original post by Oluseyi
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.

Behavior is state as well.

Share this post


Link to post
Share on other sites
snk_kid    1312
Quote:
Original post by Christer Ericson
Quote:
Original post by Oluseyi
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.

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.

Share this post


Link to post
Share on other sites
Quote:
Original post by snk_kid
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.
Sorry, I was sloppy. When I said functional I didn't mean it in a programming language paradigm sense, just that the code was structured to focus on its function and not on whatever objects may or may not be present. You're absolutely correct that the loop itself is imperative by paradigm.

Share this post


Link to post
Share on other sites
bnadland    162
Quote:
Original post by Oluseyi
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.

I also use a MainGame class. My Game class is a Singleton. It contains data about whether the Game is still Running and pointers to the subsystems. As a Singleton Class it is easy accessable from other classes. I think here it is not just an ideology but practical to use in this case.

In other cases I agree with you.

Share this post


Link to post
Share on other sites
snk_kid    1312
Quote:
Original post by Christer Ericson
Sorry, I was sloppy. When I said functional I didn't mean it in a programming language paradigm sense, just that the code was structured to focus on its function and not on whatever objects may or may not be present. You're absolutely correct that the loop itself is imperative by paradigm.


No worries, anyways i'm glad somebody said something, i've seen lots of similar threads to this recently, OO pong, OO this, OO that, OO for the sake of OO without a single thought it's really irritating.

It's just a tool that should only be used where needed, where it fits the problem domain best, if it's the most elegant solution, etc, etc.

Share this post


Link to post
Share on other sites
acid2    451
I just got my copy of Game Programming Gems 5, and it has a chapter called "Component Based Object Management." This solution, at first glance seems really nice, and it's a principle where by objects are built up by smaller components - like lego building. Might be worth a look (the rest of the book looks superb too!)

Share this post


Link to post
Share on other sites
Daerax    1207
In some languages though, you cant have independent functions - functions which are external of some class or interface or whatever. This forces you to design or implement your work more carefully if you wish it to have any kind of chance of reuse and more importantly, not having to trudge through a broken down brain-wrenchingly horrid mess of tangled code as the program grows in complexity. It makes you more careful. Functional languages force you to be careful or die a horrible death as well.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
I usually use a simple:

Mainloop
-Game class
-World
-Object
-Rendering Engine
-Input
-Sound (I don't use sound that often, so sometimes I'll have it at this level, sometimes I'll put it in the game or the world).
-Networking (I don't do that much networking so I don't often include this stuff).
-Math libraries



Not everything is a class, and depending on how you want to structure your main loop, you may want to place the rendering/input/sound/etc. modules into the Game class rather than the main loop. I don't tend to follow OO principles that closely in general, but for certain classes I do (mainly game specific stuff, any of my common stuff is most often not all that OO).

Really, you should just be structuring your code in a way that makes sense. If you need function that takes in 2 parameters performs some operation on them and spits out the result, then you don't necessarily need a class to contain it, nor do you need to instantiate an object in order to make use of it.

If the problem you are trying to solve lends itself to a class based module, then by all means implement an OO solution to the problem. Such a solution isn't always necessary however.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
"Application/Rules/View paradigm"

Hello All,

Could someone summarize the Application / Rules / View paradigm as you mean it
applied to game developpement?

It is not very clear for me how it would "compete" versus Entity/Action OO design...


Share this post


Link to post
Share on other sites
Prgrmr@wrk    109
My 2D engine is written completely with OOP, with heavy use of virtualization.

There's the Engine class, which is a singleton.
The engine contains multiple Mode classes. (Each mode is a different screen, such as the options screen, multiplayer room screen, main game screen, etc)
Each Mode contains multiple Frame classess, each of which is a window (not always rectangular) on the screen. For example, the main view, the minimap, and the interface would all be different frames. Doing it this way made it easy to have multiple views for one frame.
Each frame contains multiple Layer classes. Each Layer contains a set of ObjectList classes, each of which contains multiple Object classes, which can be sprites, buttons, gravity sources, light sources, etc. The layer organizes those Objects depending on type when they're spawned, and places them into the right ObjectList.

Each frame also has other sub-classes, such as Camera and ObjectGrid.
Joysticks, gamepads, and mice are controlled with a uniform HID class.

There's also Shape classes, such as Rectangle, Circle, Polygon, Dot, and Square.

The graphics and sound drivers are also organized into classes, so that it will be easier to add DX compatibility later on.

The game itself is started by calling Engine::run(), which sets up everything it needs to, spawns the window, and then loops the active mode, frames, and layers, until it's told to exit. Once per frame it calls a user specified function which manages the actual unique game. When certain things happen, such as a Sprite requesting an AI tick, collision, or interface events, a different user specified function is called which behaves a lot like a standard wndproc.

A lot of those things didn't start out as classes, but I experimented with changing them, and it didn't cause any difference to speed, so I kept them that way. Usually I would change a structure into a class just to make sure it was initialized properly, and to organize the header files better.

Share this post


Link to post
Share on other sites
cwhite    586
Quote:
Original post by acid2
I just got my copy of Game Programming Gems 5, and it has a chapter called "Component Based Object Management." This solution, at first glance seems really nice, and it's a principle where by objects are built up by smaller components - like lego building. Might be worth a look (the rest of the book looks superb too!)


This is an idea I've seen pop up in a few different places. I've begun prototyping a system around this idea, and found that it was extremely effective at decoupling different subsystems. I used to use gool ol' inheritance abuse and had entities that had health functionality, physics functionality, AI code, etc. The component aggregation scheme separated all of that code out, which made things much cleaner and easier to read/write/understand. It also significantly cut down the code I had to write. If done right, all your components are orthogonal (i.e. it doesn't matter if I swap out a newtonian physics component with a static object physics component... the other components still work and interact properly), which gives you quite a bit of flexibility. I've seen it in a few other places besides the Gems article, but I'm not really sure why it hasn't taken off. It gets my stamp of approval.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this