Archived

This topic is now archived and is closed to further replies.

Nirklas

object oriented game engine architecture

Recommended Posts

What are your thoughts on how to design a "general purpose" game engine? I know, general purpose is difficult, think maybe a 1942-type-of-game. But it''s the general design of the game engine that i''m interested in, not so much the graphics-engine, or the AI or the input-engine, but how they interact. What parts are MUST-HAVE? what parts are SHOULD-HAVE? COULD-HAVE? and, as I mentioned, how should they interact? Which patterns are useful? Where to use them, and WHY? For example... * Which part is responsible for creating / deleting new objects (enemies, powerups, projectiles etc)? * Should I have a common interface to control the entities that both the AI, the input-engine and the network-engine utilizes? etc, etc I''d like a general discussion on game engine architecture. =) i think this is the one part of game developing that there''s still very hard to find good articles / information about. I''ve got some ideas regarding some parts of an engine, but I think I want to hear some of your thoughts first... /Niklas Andersson Sweden

Share this post


Link to post
Share on other sites
Ahh, well... I''ve been there ...and read that.
...and it''s not excactly what I''m looking for.

I''m more interested in game-engines object-oriented design

/Niklas Andersson
Sweden

Share this post


Link to post
Share on other sites
Take a look at OGRE:

http://ogre.sourceforge.net

Pretty nice OO design they have there. Not sure how fast/efficient/etc it is.

Might give you an idea or two

[edited by - tyson on May 3, 2003 9:58:39 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by Nirklas
What parts are MUST-HAVE?
what parts are SHOULD-HAVE?
COULD-HAVE?
and, as I mentioned, how should they interact?

Which patterns are useful? Where to use them, and WHY?

For example...
* Which part is responsible for creating / deleting new objects (enemies, powerups, projectiles etc)?

* Should I have a common interface to control the entities that both the AI, the input-engine and the network-engine utilizes?

etc, etc

I''d like a general discussion on game engine architecture. =)
i think this is the one part of game developing that there''s still very hard to find good articles / information about.

I''ve got some ideas regarding some parts of an engine, but I think I want to hear some of your thoughts first...


Just a few notes on what I did:
- The program controls the Game engine, which controls all "sub-engines" (Graphics, sound, input) by telling them when to do their job and with what.
- The game engine also controls all physics, the game loop, etc. It has functions like UpdateInput() which call those "sub-engines". Another function I used was PlaySound(int SoundIndex, ....) which played a loaded sound.
- OOP is the best way to go. Have similarly named functions in each engine (ex. Init, Unload, Draw/Paint, Move, etc).




- Rob Loach
Current Project: Go Through Object-Oriented Programming in C++ by Robert Lafore

"Do or do not. There is no try."
- Yoda

Share this post


Link to post
Share on other sites
Another good thing to look at is the ''engine exports'' code in the Half-Life SDK. It should give you an idea of the kind of services a game engine makes available to the game. It''s not OO (at all - one big structure of function pointers ) - but it''s worth a look.

I *really* need to get my first few articles up

Superpig
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.

Share this post


Link to post
Share on other sites
quote:
Original post by Tyson
Take a look at OGRE:

http://ogre.sourceforge.net

Pretty nice OO design they have there. Not sure how fast/efficient/etc it is.

Might give you an idea or two

[edited by - tyson on May 3, 2003 9:58:39 AM]



This is a graphics engine, not a GAME engine.


"Five passengers set sail that day, for a three hour tour, a three hour tour...."

Share this post


Link to post
Share on other sites
quote:
Original post by Damage_Incorporated
A bold statement, a bold statement indeed. Before you make such a statement you should define what you mean by best .

Best as in best solution compared to other solutions available (due to compatibility, flexability and easability ).



- Rob Loach
Current Project: Go Through Object-Oriented Programming in C++ by Robert Lafore

"Do or do not. There is no try."
- Yoda

Share this post


Link to post
Share on other sites
hiya

I recently was having the same problem... how should things
interact with each other... I still havent got a perfect solution but I now know though a lot more about it...

What im doing in my engine is making virtualy every system derived from a pure virtual class, this alows me to add new
features when ever I want and easily change, or even remove other systems... for example, I have a basic inout class that uses GetAsyncKeyState() and such, and then a direct input class
that uses DikDown()... all I have to do to change witch one I want to use is to point the virtual class at either wich one.

This goes for entitys as well and any other system in the game.
Something I was having trouble with, was "how do you load certain
functionality for the AI and such and know what objects are in the game?"... my solution: Lua! (www.lua.org)

AI, physics, rendering, etc all are and should be seperate form each other, but there still conected by thru the octree system
and the scene manager. My collision system works (or will work) by testing whats around the entitys ina certain radius (collision test1) and then after you get a list of the objects that your close by, then you do a more advanced collision test (ie, BB test) or such, all you need to handle collision responce, is to be able to get the objects velocity, "bouncyness", etc and possable what type of object it is: (ie. a explosion, a NPC)
etc...

Also, what I have is a global octree that holds all other octrres, both static and dynamic, and when an explosion or such occurs, it uses this global octree to get every to get a list of every object in a certain radius, gets the distance to each object and then "applys damage" accordingly.

The most important thing though is (to me anyways), if you really want a powerfull engine that alows for many games to be made using it and be very flexable, you'll want to use a scitping engine! it is almost a must for modern day games. and
it helps so much! I would strongly recommend you read the lua
article (if you havent already), a great read, and really helps you get started.

Ok, now as for AI, what Im planning is to have some basic classes for different object types (flying, driving, walking,
triggered objects, etc) and then extending upon this in the script, like maybe pseudo script :

if(playerposition is within trigger area)
opendoor(1.2); //1.2, speed it opens at
else
do nothing...

ok, now this is very basic stuff, but implementing this functionality in the engine may be another story.

fewww, im getting tired

well, I hope this helps, and if it confusses you just forget about what you have read these are meerly my own ideas that
Im going with.

GoodLuck


"your all going to die down here" - Resident Evil




[edited by - yodaman on May 5, 2003 3:40:06 PM]

Share this post


Link to post
Share on other sites
Thanks for all replys.

Since I want this "engine", or framework, I think framework is a better word, ...anyway. Since I want this framework to be as generic as possible it will inheritly be very lightweight.

So far I've only got brief ideas about how the Game-object is going to work.

The design for the InputManager though is really getting there.

It'll look something like this pseudo-codeish snippets....

class CInputEvent
{
Event mEvent; //Event is an enumeration of keys/axii
ASuitingType mEventData;
...
};

class IInputListerner
{
virtual bool ProcessInput(const InputEvent&) = 0; //returns true if the object used the input
};

class CInputManager
{
public:
bool Update(); //retrieves data from the input devices and generate a list of InputEvents
bool ProcessInput(); //delegates the InputEvents in the list to the registered listeners

RegisterListerner(const IInputListener *, bool top=false);
UnregisterListener(const IInputListener *);
private:
LinkedList mListerners;
LinkedList<inputEvent> mCurrentEvents;
...
};

Objects that want to recieve input only have to implement IInputListener and register with the InputManager. The idea is not is that Entities should register to recieve, rather objects like ContentLayers and such (described briefly below)

As for graphics I think I'll end up with a layered approach, inspired by Scott Patterson's article in Game Programming Gems 3.

it goes something like this

CGame::GameLoop()
{
...
for(each ContentLayer in list)
{
ContentLayer *pPL = get layer from iterator
pPL->Render();
}
SwapBuffers(mHDC);
}

it makes it very easy to display in-game menus and user-interfaces on top of the actual game-scene.

Other things that eventually will be included is some kind of sound-manager, logging and, of course, a manager that takes care of the window-creation. It is not going to be a multi-platform framework, not during this phase anyway. It will be aimed towards a Win32/openGL configuration.

So... what are your thought on this?
Am I making a fool out of myself? falling into each an every OOD pitfall?

/Niklas Andersson
Sweden

[edited by - nirklas on May 6, 2003 12:23:15 PM]

Share this post


Link to post
Share on other sites
Nirkas, i''ve the same question as you do, that is after learning many techniques of a game engine (from our dedicated online tutors NeHe/Digiben and others) we should learn how to actually design it. All the tutorial sites have good resource on the technologies but not anything on game engine desing.
I found a design discussion on the ''OpenGL Game Programming'' book, which is a basic structure but helpful. I''m currently starting from that design hopefully it''ll help.
I wish some good programmers would put up some article on ''game engine design'' which is the first thing we need to start building an engine from.

Share this post


Link to post
Share on other sites