🔒 Locked

TECHNICAL design

Started by gumball Sep 11, 2000 at 8:16 PM 1 replies 700+ views

Original Post

Sep 11, 2000 at 8:16 PM

Hi, I have been playing around with various aspects of game programming ie. 3D graphics, sound, input .... for a while now, but before I start doing something serious which uses all of these plus more (eg AI), I was wondering about Technical Design issues that I should definitely sort out before I jump in and code. What I mean specifically is that I know I should keep each ''component'' of the game as isolated and independant from everything else - ie keep rendering system seperate from AI system, which is seperate from Sound system etc etc. The thing is I don''t really know how to go about this so the result is good, clean, uncoupled code. Any guidelines, hints, psuedocode, examples, would be appreciated by myself and others on this board I''m sure. Thanks

Sep 12, 2000 at 4:27 AM

I try to break every thing down into series of INPUT, PROCESS, and OUTPUT.

From a really generic view, ala main():
INPUT - initializations (Window setup, defaults, configuration)
PROCESS - the main loop
OUTPUT - return ...;

Inside the main loop, the components are sorted by the INPUT, PROCESS, and OUTPUT sections. Within these components is another series of INPUT, PROCESS, and OUTPUT.

Loop:

INPUT

*Device Management

(INPUT)

Get Device Inputs

. Keyboard

. Mouse

. Gamepads/joysticks

(PROCESS)

Generate input events

. (if key[custom_left] then CreateEvent(PLAYER_WALK_LEFT) etc...

(OUTPUT)

Post these events for access outside of engine.

PROCESS

*World and Entity Management

(INPUT)

Get timeslice to work with (if working in time based frames)

(PROCESS)

Update World

. environmental changes

Update Entities

. AI

. graphic

. sounds to play

(OUTPUT)

Post Information (viewport, entities to draw, sounds to play)

OUTPUT

*Graphic

(INPUT)

Detect update method

. screen scrolled?

. dirty rect cleanup?

(PROCESS)

Update screen accordingly

(OUTPUT)

Information (polys rendered, time taken, sprites copied...)

*Sound

(INPUT)

Get sounds to play

(PROCESS)

Play sounds

. Music

. Effects

(OUTPUT)

Information (sounds playing, music bpm, ...)

Within each section there is the OUTPUT where it posts information to be accessed by other components. There are several ways to do this. If want each component to be in a class (c++, other OOLs) set it up so the OUTPUT can be accessed by other classes. You may also setup some sort of shared variables between components, aka global variables and arrays. This method tends to be considered more of a hack or sloppy programming, but if it doesn't give you errors or unwanted side effects, go for it.
You do not have to follow this exactly, but it gives you a nice framework to work with. If you don't want to set up a device event system (which I like, as other components don't view keypresses but rather the events they represent; plus, it makes for easy configs) you can start with this frame work, and modify it as you like, such as hard coding key presses within player (entity) movement. Be careful though, a bad design will always try to appear.

I didn't list it, but the first component to do in the main loop is the OS. For example, Windows would look like this:

OS

INPUT

Detect Messages

PROCESS

Process messages

OUTPUT

Info that the engine should know based on these messages
(ie. [ALT]+[F4] = time to shutdown game)

I hope this helps, fire any other questions you may have.

Travois (thats Tra-vwah)

Edit: added TABs to diagram

Edited by - TV on September 12, 2000 5:33:24 AM

Knarkles

Sep 12, 2000 at 4:37 AM

I wrote about my modular engine in a thread quite a long time ago. It''s called something like "Engine structure." You can look for it if you want.

-Jussi

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.