Ok, I''ve decided to take a step back from writing my first game engine and transcribe what notes I have in my head to paper. These are just parent level class names, and specific (ie Keyboard derrived from Input) areas aren''t listed. Please let me know if I am forgetting something: - Input - WorldObjects - models and such - Renderer - the graphics engine - Draw - draws menus, credits, etc. - will be child of Renderer - AI Sound and networking probably will not be handled right away, but will be kept in mind when I write the classed. Oh yeah, it is a C++ based engine.

This was posted on the games programming newsgroup by Javier Arevalo, you might find it helpful.

- Game Logic
- Game System
- Application / windowing / startup
- File System
- Memory
- Debugging
- Event / messaging system
- Compilation configurations
- Game Character behaviour
- World Physics
- Character Movement
- Pathfinding
- Collision Detection
- Basic Character Interaction / messaging
- Basic Character Animation system
- Game player control
- In-game User Interface (mouse, multi-user management, etc)
- Game player character(s) behaviour
- AI
- Computer player character behaviour
- Computer player strategy
- Scripting
- Missions
- Scripting
- Making each mission''s details fit together
- Save / Load mechanism
- Network gameplay logic
- In-game sound management
- Menu
- Menu system
- Game-specific menu implementation
- Tools
- Mission / game logic map editor
- Technology
- Math
- Low-level optimized math classes / code
- Graphics
- Low level graphics management
- Low-level Windows, screen, 3D device, textures, etc.
- Scenery rendering
- Character rendering
- Character animation
- In-game Special effects
- 2D rendering (for menus, etc)
- Video playback
- Graphics support tools
- Scenery editing
- Character editing
- Animation editing, importing
- Bitmap compilation
- Input device system
- Low-level network system
- Low-level Sound system.

Good Luck

-ddn

It removed all the tabs, making the layout much less clear. Oh well, if anyone knows how to make a post with tabs, i''ll repost it.

-ddn

I went through and replaced the leading spaces with dashes. Perhaps this will make the original intent more clear.

(P.S. - Thanks for posting this, I found it terribly interesting)

- Game Logic
-- Game System
----- Application / windowing / startup
----- File System
----- Memory
----- Debugging
----- Event / messaging system
----- Compilation configurations
--- Game Character behaviour
----- World Physics
------- Character Movement
------- Pathfinding
------- Collision Detection
----- Basic Character Interaction / messaging
----- Basic Character Animation system
--- Game player control
----- In-game User Interface (mouse, multi-user management, etc)
----- Game player character(s) behaviour
--- AI
----- Computer player character behaviour
----- Computer player strategy
----- Scripting
--- Missions
----- Scripting
----- Making each mission''s details fit together
--- Save / Load mechanism
--- Network gameplay logic
--- In-game sound management
--- Menu
----- Menu system
----- Game-specific menu implementation
--- Tools
----- Mission / game logic map editor
- Technology
--- Math
----- Low-level optimized math classes / code
--- Graphics
----- Low level graphics management
------- Low-level Windows, screen, 3D device, textures, etc.
----- Scenery rendering
----- Character rendering
----- Character animation
----- In-game Special effects
----- 2D rendering (for menus, etc)
----- Video playback
----- Graphics support tools
------- Scenery editing
------- Character editing
------- Animation editing, importing
------- Bitmap compilation
--- Input device system
--- Low-level network system
--- Low-level Sound system.

I appreciate the post, but it, well, doesn''t seem very OO friendly. I rehash the above list tonight and see how pretty we can make it. It also appears to be too specific towards a single type of game, aka, not generic enough yet too generic. This was off the cuff, right?

Urk! Man. Yes. You got a point there. Personally I''d be inclined to split that list up:

Resources:
-> Data Structures: Handling in game structures: freeing, allocatng, etc.
-> File System: Anything touching the file system. Loading, etc.

Graphics
-> Primitve: Simple stuff: drawing text, drawing images, opening windows, etc.
-> Interface: Handling menus, pointer, keyboard
-> Effects: Any complex graphics manipulation
-> 3D
* Polygon library: 3D rendering stuff
* Other... eg. pixel arrays, etc.
-> 2D
* Sprite library: All basic 2D manipulations

Sound
-> primitive: finding sound card, etc.
-> Music (either CD or whatever)
-> effects: triggered effects from an action or event

Physics
-> Object Physics: Calculations for any game objects
-> Environment Physics: Calculations for game environments
<br><br>World<br> Totally changable. Basically things about the game environment.<br><br>Library<br> Again, depends on what your doing. I''d put all the definitions and manipulations for any game objects here: players, monsters, objects. Each in a sub module (class) for that type of object I guess. <br><br>Networking<br> -> Primitive: basic stuff<br> -> Protocols<br> * TCP/IP<br> * UDP<br> * if.u.use.IPX.shoot.yourself.no.offence.anyone<br><br>Debugging<br> -> Set of tools to debug your game with<br><br>Most of that stuff in the list''d go into the approprate place in my library module I think: eg. AI would be different for characters and monsters, etc. <br><br>Dunno: doing this of the top of my head: but with a list like that I think you''d have a bit of trouble. I find its easier to think of it as:<br><br>What do I need, basically?<br><br>* Graphics<br>* Sound<br>* Networking (if multiplayer/required)<br>* Resources<br><br>(If you''re feeling happy also add:<br><br>* Generic AI<br>* Debug tools<br>* Builder tools<br>…)<br><br>And work down specifying what each module is responsible for. If any module is too big, break it up into sub modules. Then list what each module should have as functions to achieve its objectives (public functions). Then code each function… (and add private ones as appropriate).<br><br>Ciao!

Just a quick note about the formatting... if you put
(without the spaces) around the text, then it will preserve any extra spaces or tabs that the text has

Edited by - chippydip on May 26, 2000 1:13:16 PM

Here''s what I usually use. Usually. One line is one class.

Graphics
Sound
Input
World
Object

Anything that needs to move (like the player) is some type of sub-class of Object.

Actually, I have object as being the parent of anything in the world that can be interacted with (camera, models, and the terrain). The world will actually be my object list, and part of the Game class I created to handle the actual game play. I am also going to have an event que, but it will be just a list of ints and objects. It probably will be a overloaded class because sometimes, the event will have an object, no object, or two objects. Event types will be of a known range of possible values with menu operations, game actions (hit, pickup, use, etc), and terminals (game engine exit, exit on error, out of memory).

I''ve just added Intro, Menu, Game(the meat of the game controller class), and GameMain (the overall game loop controller class). I might just have the Renderer class accept a bunch of verticies, materials, and whatnot in order to keep the interaction between the graphics API and the game engine to a minimum, in an effort to reduce their dependencies on one another. It will allow me to place just about any graphics API underneath it.

Unfortunately, I see no easy way to deal with different API''s other than creating a parent Renderer class and having each supported API inherit it. It would allow me to simply create a pointer to the parent class in the GameMain class and assign it the appropriate child to deal with the varios API''s. Oddly, that will create a new message ''FEATURE_UNSUPPORTED'' that I''ll have to deal with (ignore?).

The Menu will be a list with each node having a multi-leaf tree. Each leaf indicator will simply be an index value on the tree. I am going to have to hard code certain aspects of the tree (like the save,load, and configure leaves) in order to accomodate the in game support of the menus.

So far, I have about 20 classes, with about 5-6 parents. Things are looking like a go, at least until everything isn''t .