I am curently having a problem deciding on a broad scope how my game engine will be structured. One important thing that i am looking for is separation of logic and rendering. In order to do this my first idea was to to have a Engine base class and have two composited classes, Logic and Graphics. This all works until i try and implement a state system. I do not like the common state systems that are allowed a single state and use switch cases to decide what to do, so i got the idea of a Screen or Canvas class to encapsulate the rendering of a certain screen along with screen logic. The problem with that is that logic is now under Graphics:
Is there a more elegent/flexible way to implement a Frame or Screen type class that has the ability to handle its own state without having to mix rendering and logic? Would it be fine to implement the array of screens in the Engine and call their logic and Rendering separate?
The other thing i am curious about is, where is it that most game engines store the bulk of game data? In my game i was planning to put the game date in the engine class so all subclasses can be passed a pointer to the game data. Is this the most efficient way of doing this? I have heard quite often that most games use singleton instances for subsystems, is this the best way to declare subsystems and is this the best place to store a game data manager class?
Thanyou for your time
jusCuriousMember Since 28 Mar 2012
Offline Last Active Apr 16 2012 01:10 PM
- Group Members
- Active Posts 2
- Profile Views 682
- Submitted Links 0
- Member Title Member
- Age Age Unknown
- Birthday Birthday Unknown