Original Post
Hello,
I've been thinking about "game engine code design" a lot, lately I've shifted to just "game code design".
Obviously you can have a entire game engine which is quite flexible and allows you to do many stuff, versus a less flexible architecture suited just for the game you are currently making.
What I came up so far is that you have a couple of totally independent modules, which can be reused no matter what kind of a game you make:
-physics simulator (could be a wrapper around something like Havok or PhysX)
-AI simulator (make something very simple on my own) - well for this one you would obviously add new AI behaviour based on the game type
-renderer (wrapper around directX, openGL or whatever)
-user input (keyboard,mouse)
The thing I want your opinion on is how to design the "glue" code, the code the connects all modules into a game (so the code that makes the actual game & gameplay mechanics).
Right now I'm working on a simple top-down space shooter for Android.
The player is in control of a base that can rotate around and shoot incoming enemies, but it cannot move.
So how would you go and design the glue code?
The most obvious way that I saw it was to create a common class for everything that does something/is visible in the game world (so a super class like "Entity" or "Actor").
Then I would use single inheritance and derive all of my game objects from it, for example:
-ActorPlayerBase
-ActorEnemyWeak
-ActorEnemyStrong
-ActorLaserWeaponBullet
-ActorPlasmaWeaponBullet
These Actors then contain objects of the Renderer, Physics, AI and user input modules.
So for example, the enemies: I read the stuff from the AI module (in which direction the enemy should go or whatever), apply this to the physics object of this Actor and then use the physics object to move the Renderer object of this Actor.
What do you think of this? Would this be a "proper" way to use object oriented design since it is just single inheritance (and don't forget that the game is meant to be very simple)?
I hear a lot about the data driven approach, could you explain to me how the data driven approach could be used in a simple top-down shooter like the one I'm making?
I've been thinking about "game engine code design" a lot, lately I've shifted to just "game code design".
Obviously you can have a entire game engine which is quite flexible and allows you to do many stuff, versus a less flexible architecture suited just for the game you are currently making.
What I came up so far is that you have a couple of totally independent modules, which can be reused no matter what kind of a game you make:
-physics simulator (could be a wrapper around something like Havok or PhysX)
-AI simulator (make something very simple on my own) - well for this one you would obviously add new AI behaviour based on the game type
-renderer (wrapper around directX, openGL or whatever)
-user input (keyboard,mouse)
The thing I want your opinion on is how to design the "glue" code, the code the connects all modules into a game (so the code that makes the actual game & gameplay mechanics).
Right now I'm working on a simple top-down space shooter for Android.
The player is in control of a base that can rotate around and shoot incoming enemies, but it cannot move.
So how would you go and design the glue code?
The most obvious way that I saw it was to create a common class for everything that does something/is visible in the game world (so a super class like "Entity" or "Actor").
Then I would use single inheritance and derive all of my game objects from it, for example:
-ActorPlayerBase
-ActorEnemyWeak
-ActorEnemyStrong
-ActorLaserWeaponBullet
-ActorPlasmaWeaponBullet
These Actors then contain objects of the Renderer, Physics, AI and user input modules.
So for example, the enemies: I read the stuff from the AI module (in which direction the enemy should go or whatever), apply this to the physics object of this Actor and then use the physics object to move the Renderer object of this Actor.
What do you think of this? Would this be a "proper" way to use object oriented design since it is just single inheritance (and don't forget that the game is meant to be very simple)?
I hear a lot about the data driven approach, could you explain to me how the data driven approach could be used in a simple top-down shooter like the one I'm making?
