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?
Framework design and structure
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
to sum it up have a look at the pdf www.marek-knows.com/files/3D_OpenGL_Game_Engine_flowcharts.pdf
Author
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
Got any ideas about the logic layout ?
thx a bunch
max
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
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
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.
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.
....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.
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.
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.
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.
Author
Thanks for your your info gys very interesting, gave me a good thinking direction much appreciated
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
