Library Feature Set
I have programmed sound engines, many graphics engines, input code, etc. I decided that I would stop just making demos and put everything together into a game api. I made a page stating the desired functionality and interface of the api. I would like to hear your suggestions.
The Plan
er... Slightly hard to read. Could you summarize what''s inside ?
Thanks,
David
--
===
Am I the keeper of my brother ?
Thanks,
David
--
===
Am I the keeper of my brother ?
I wanted dynamically loadable behaviors that could be attached to objects. The behavior library is passed other objects that can load behaviors at program startup. The reason the library doesn''t load any behaviors itself is so the program can handle any file type.
All other code should be based on behaviors. The behaviors have an identification string, and a set of overrideable functions. The behaviors are attached to objects when they are loaded.
Some of the design goals was to make the library easy to extend, and also easy to use in a world editor.
These are the overrideable behavior functions.
// ALLOCATION
StartUp() and ShutDown()
These are called whenever the behavior is loaded so that it can allocate memory.
// INTERFACE
int Run()
This is called once every cycle of the game engine, it could be drawing code, ai, etc.
int Message( Object MessageSender, p_Function CallBack, ID type, void* message)
This is to recieve messages from other behaviors and objects.
void OtherFunction(void*)
This was added in case of need for another function.
void* CallBack( Behavior* caller, void* data);
This is to let the behaviors that send messages get called back with replies.
// TYPE SAFETY
void* SafeCast( char *type)
This is just to insure that if the behavior is cast to another type, it is legal.
Behavior GetInstance()
This is to instantiate new behaviors based on this behavior.
Objects
These hold an id and behavior code. For example a sphere object could hold code to draw itself and code to check for intersections with other objects.
It has functions to add behaviors, get behaviors, etc. It has functions to add child objects or set its parent in a hierarchy.
Most of the rest of the things in the plan are standard game features.
All other code should be based on behaviors. The behaviors have an identification string, and a set of overrideable functions. The behaviors are attached to objects when they are loaded.
Some of the design goals was to make the library easy to extend, and also easy to use in a world editor.
These are the overrideable behavior functions.
// ALLOCATION
StartUp() and ShutDown()
These are called whenever the behavior is loaded so that it can allocate memory.
// INTERFACE
int Run()
This is called once every cycle of the game engine, it could be drawing code, ai, etc.
int Message( Object MessageSender, p_Function CallBack, ID type, void* message)
This is to recieve messages from other behaviors and objects.
void OtherFunction(void*)
This was added in case of need for another function.
void* CallBack( Behavior* caller, void* data);
This is to let the behaviors that send messages get called back with replies.
// TYPE SAFETY
void* SafeCast( char *type)
This is just to insure that if the behavior is cast to another type, it is legal.
Behavior GetInstance()
This is to instantiate new behaviors based on this behavior.
Objects
These hold an id and behavior code. For example a sphere object could hold code to draw itself and code to check for intersections with other objects.
It has functions to add behaviors, get behaviors, etc. It has functions to add child objects or set its parent in a hierarchy.
Most of the rest of the things in the plan are standard game features.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement