Original Post
My goal is to create and engine that could be used to make any 2D platform game from Metroid to Sonic. All rules of physics would be read from a file, all level files would have pointers to image files in them, so levels could look like anything with tiles of any size (and any apparent shape, thanks to alpha channel). Terrain engine is alreade done and is working just like I hoped (currently on directX, but easily portable to OpenGL, or DirectDraw). Collision engine is almost done, but that's about it. I have reached point where I realize that I will never be able to organize it all and I need a plan. System of closely intertwined together, which can be easily modified, improved, with little need to change any other parts. Here is a design I came up with. It is long, consider yourself warned, it is also written in comment style with little forethought, just for myself, only latter I realized that this might not work at all and I should ask someone who knows this stuff little better.
Level 1:
gam and AI
Level 2:
phy
Level 3:
col
Level 4;
mob and ter and snd
Here is what they actually do:
1. Gameplay engine (gam) is leader of the land. It does two things. First it performs scripted actions, such as bridge fallling, when player walks over it or sky turning red when player dies. All that comes from script files. Second is performing game logic, if player falls into lava, gam is
responsible for killing him and his col (collision) and mob (graphical) instances, then it is responsible for cuing music and
other things that happens after death. It never does the dirty work, only tells other parts to do it (sometimes thru intermediary). Works very closely with AI, sometimes tells AI what to do, at other times takes orders from AI. Cotrols most high level stuff, including user input.
2. Artificial Intelligence (AI) engine takes control of all enemies that are not projectiles or other things incapable of propelling themselves (that is job for phy). It gives directions to phy engine to move them or make them jump (so forces can be correctly calculated). Never actually
moves mobs itself, only tells phy engine to do it
3. Physics (phy) engine does all the dirty work. First it bases all of its actions on data from col engine. All actions are initiated by gam and AI. It also communicated back when certain things happen (acts as medium for col, which never talks to Level 1 engines). It will also control all animation
for mob instead of sending pysics data to gam and letting gam do it, however as soon as something unsual happen (like death of a mob or explosion of a projectile or a collision of player and mob) it sends data to gam to decide on next action. If it get a collision data from col, it will check both materials, calculate reaction (a bounce) return new position data to col (every frame),send position data to mob engine and possibly send an order for sound to snd engine.
4. Collision detection (col) this one has pretty simple job. It takes orders from phy and phy alone. It returns every collision to phy. It gets another set of orders from phy, which it uses to change positions of its internal objects and to resume to normal mode.
5. Mobile object (mob) engine will control all moving objects. Projectiles, enemies, special effects, plus other crap. It will receive directions from phy engine for normal operations, from gam engine for things like creation and destruction of mobs. It will change its appearance by directions it receives.
6. Terrain engine (ter), will do pretty much nothing, it will receive directions from gam, conserning camera position. Everything will be precalculated. It is a very complex part to initialize, and very much processor intensive, but also very automaic, needs no help once it is running. Everything will have to be created by level designer
7. Sound engine (snd) will get instructions from both gam and phy engines will play a sound. Sounds easy, possibly will be hardest to code. All codes will be read from file and matched with .mp3 and .wav files. All music directions will come from gam engine.
It this too complicated, too simplistic for most modern engines ?
It doesn't go into specific details of how these things should be accomplished, but I have some ideas. It encourages separation of collision detection and graphics. For example: all terrain graphics stuff is held in one file, all terrain collision data is held in another, it would allow production of beautiful layered landscapes by one person, while other person would go their entire level and lay collision data only on objects that are supposed to collide with anything, if I wanted new type of material (mud or green ozze that slows player), I wouldn't need to change collision or graphics engine at all, as soon as collision part registers a collision, it will send a message to phy engine which will slow the player down or maybe even tell gam engine to reduce player's health. I hope you see great modularity it offers. What do you think ? All feedback is welcome
EDITED: several spelling mistakes
Edited by - juozasg on November 29, 2001 7:30:04 PM
