Sign in to follow this  
maxfire

Framework design and structure

Recommended Posts

Hey gys

Im currently learning SDL and am in the process of creating a simple bouncing ball game. I am up to the point where I now need to get the ball moving. I have the code ready but not sure how I should structure its implementation.

I have classes for both the main window called MainWnd and another for my Ball (Ball), now should a game item such as a ball contain/know-about its own logic (how to react depending on a parameter passed in then redrawn depending on the outcome). Or should I have a global logic class that holds/deals with logic and events of all items? (moves the object position then tells them to redraw themselves).

My second question is about timing, I have often read about how games run off one global timer (the frame rate) any pointers on how to organise my classes to all run of this one timer? is a singleton timer the way to go or should it sit at the top of the class structure and call the methods in the other classes?

Share this post


Link to post
Share on other sites
you might be interested in looking at the architecture i used in my game engine.

to sum it up have a look at the pdf www.marek-knows.com/files/3D_OpenGL_Game_Engine_flowcharts.pdf

Share this post


Link to post
Share on other sites
hey buddy thx for your input but sadly it didnt tell me anything I didn't already know. I can think of many ways of doing the timer based around those models I was just wanting peoples reviews on some common practiced ways

Got any ideas about the logic layout ?

thx a bunch
max

Share this post


Link to post
Share on other sites
what i have done is created a scene class which is used to keep track of all objects in my game. this class is responsible for telling how to update each game object based on the global game time. each object is only responsible for rendering and reacting to input given to it.

you need a global manager like the scene class because you don't want each object having to keep track of all other objects for collision etc

hope this helps

Share this post


Link to post
Share on other sites
When I write games I usually break things down into logical chunks (like you have) and everything related to that chunk would be contained in that object. It is really an object oriented approach. So my ball class would contain the logic that knows what the ball should do when a parameter is passed in.

Now with this approach you WILL get people giving you the has a/ is a argument but personally I have never ran into a situation that a lot of that argument brings up such as "What if you have a ball that does not draw to the screen but needs the logic". I think a lot of the more seasoned developers (I am fairly new, only been at it about 3 years now), would suggest splitting your drawing and logic apart so having a visual ball class and a logic ball class.

Personally as stated before, I would just have a single ball class that contained all logic related to your ball. The important thing to note here is in larger games, this approach works fine still if your render and drawing code are called separately such as from a rendering thread and a logic thread.


Just my two cents, I hope it helps. A lot of replies you get will be opinion based. Basically my philosophy is design something the way it makes sense, don't try to design the world up front and account for 99% of the scenarios.

Share this post


Link to post
Share on other sites
....and then there's my solution: where I just recognize matters like these as being the futility typified by OOP from the get go.. but then everyone always says I'm crazy for many reasons..

just my two cents ;)


and my other two cents says that I agree with mmakrzem's concept of a scene manager that could be used to execute logic according to its tracking of time elapsing, and it could also have a rendering method that also handles whatever scene graph or occlusion culling and then finally rendering objects invoking their own render code.. and also I agree with XXChester with regards to avoiding making the effort to account for every imaginable scenario. Find a general solution that suits your current needs, revamp when you start a new project from scratch.

Share this post


Link to post
Share on other sites
I think your first question depends on your own design decisions, it will work regardless. If youre not looking to build a very general enitity type of system for reuse, just do whats easy for the specific problem at hand.

I personally have each game "entity", in your case the ball, have its own move logic in a method, usually the "update" method. Then the main game classes update method will call the balls update whenever needed, bsaed on input, time, whatever. So basically, the balls actions are handled by the ball itself, but when, where, and how they are performed is handled in the main game logic. I think it works well and decouples the ball from the game. The ball does not have to care at all about the game, it is only told to move based on its own velocity and direction vectors.

Then again thats how I do it for small projects. If I was building a very resuasble framework, I would probably make it even more decoupled.

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