Archived

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

What goes in an Engine: Am I right??

This topic is 5376 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Ok I''m currently designing a simple 2D Engine (I don''t want to jump straight into 3D!), and I want it to be reuseable for other games that I make (of course, that''s what an engine is for I hear you say). I''ve divided all the functions of the game I will make into A Game Eninge list, and A Game List. Take a look and tell me if I''m on the right track please GAME ENGINE FUNCTIONS/CLASSES *Init and Shutdown API (ddraw for my case ) *Load Bitmap *Draw Bitmap *Draw Shapes (rect,circle etc) *Play .wav file *All other graphical functions *Timing ACTUAL GAME FUNCTIONS/CLASSES *Create window and other stuff like that *Main game loop *Player input / Move player *All Menu''s *Collision detection *All AI *Save/Load high scores I''m not sure what to put in the engine, and what will go into the actual game code. I am mostly confused where to put the Menu,Save/Loading,Timing,And the sound? Should the engine contain sound functions, such as playing a .wav file? As you can see I am new to game engines, befores I was just putting everything into 1 file! Thanks for your time

Share this post


Link to post
Share on other sites
try to put as much in the engine as possible, that means less code per game. that means the window should probably be in the engine part, if you can make a generic game object class and then have the main loop in the engine along with a storage structure for the game objects, that''d probably be best. collision detection should definitely be part of the engine, don''t want to be programming that for every game. basically anything that you would be programming in every game should be part of the engine. there are of course exceptions, but you get the idea.

Share this post


Link to post
Share on other sites
to add to billybob''s answer a bit, it can be hard sometimes to put all of a subsystem for a game into the engine. For example, collision detection can be very game specific. Usually the best way to do it is if you can''t put it all in the engine, then put as many generic helper functions in the engine as possible. In the case of collision detection, testing for a collision between a polygon and a line will be required in any game, so it can be put in the engine. Then the game can use some of it''s own code to utilise this code from the engine to create the game''s collision detection code. There are also many AI functions that you may want in your engine (e.g. A* pathfinding algorithm), but you won''t be able to put all of a game''s AI into the engine and still keep the engine generic. Hope that helps anyway.

Share this post


Link to post
Share on other sites
Hey thanks guys (or gals), you really helped me out.
But one thing:

quote:
Original post by billybob
If you can make a generic game object class and then have the main loop in the engine along with a storage structure for the game objects, that''d probably be best.


I don''t quite understand what you mean here, could you
(or someone else) please explain this thouroughly?

Thanks again

Share this post


Link to post
Share on other sites
yeah, melvin melvin is right, but you want to keep basic object interactions in the engine. the way i have it set up is the collision functions of my game objects are virtual, but usually don''t need to be overridden. if i do need to, i can override those and make new collison. and answer this quesiton. to make a generic object class, you need inheritence, and then create a class that would fit ALL game objects that you make (really basic example):


class GameObject
{
unsigned long ID;
Coord Position;
bool Visible;
...

GameObject();
virtual ~GameObject(); // MAKE IT VIRTUAL

virtual void Render();
...
};

then, you would have specific game object classes, say a pickup class, and a player:

class Pickup : public GameObject
{
Bitmap * PickupImage;
...

Pickup();
~Pickup();
};

class Player : public GameObject
{
bool Moving;
...
void KeyDown();
void KeyPressed();

Player();
~Player();
};

Share this post


Link to post
Share on other sites
Ok so the Game object classes would NOT be part of the engine??
Sorry, I''m a little slow today! (or maybe I always am)

Oh yeah, and in your first post billybob, you say to put the game loop IN the engine?? Did you really mean that?
I was thinking that the game loop is what changes most in games so....

Again, thanks

Share this post


Link to post
Share on other sites
the functions that you call in the main loop might change, but you would still always get/handle input, do physics, do ai, render the scene..

you could do basic physics and include it in the engine and if you need something else just change the function. either the oo way or simply use function pointers.

also you would probably want the engine to apply physics and ai functions to every suitable object in the scene graph automatically, so your game doesnt have to care about anything but spawning objects and letting the engine know what kind of physics and ai to use for it. a simple example of how the engine could be used would be:

spawnObject(plane, "bomber.bmp", planePhysics, BomberAI);
though of course you can also create a class Bomber.

in this case physics and ai might be derived classes that contain functions or function pointers to functions that do physics and ai.

hierachy could be something like (all inside the engine):
baseObject
|
drawableObject (with attribute sprite)
|
gameObject (with attributes physics, ai)

and alone while writing this i thought about a dozen versions so whatever you decide to do: think it over and over again, think about how it would be used and if it would work if you couldnt touch the engine again at all and have to get along with the interfaces it provides.

Share this post


Link to post
Share on other sites
heh, yes i did. basically, you want the engine to know nothing about the game, this way it remains "neutral" i guess you could say. if you have a class hierarchy of game objects, then the game loop could look something like:

void YourEngine::MainLoop()
{
GetDelta(); // update time from last frame
GetInput(); // get new input
...
for(int i = 0; i < NumObjects; ++i)
Objects(i)->Update(Delta); // call every objects update function, send it the time elapsed
}

so, if you keep the game object class totally game independant, you never have to look at any code in future games other than the game object code.

edit: replace (i) with bracket i bracket, since the forum is retarded

[edited by - billybob on March 23, 2003 11:10:02 AM]

Share this post


Link to post
Share on other sites
Ok I sorta get the idea now (sorta).

Just a few questions....

Are large classes bad??
Eg: I''m thinking of dividing my engine into 4 parts,
Video,Audio,Input,and helper functions.
Is this approach any good?

My classes would look like this:

class CVideo
{
All ddraw functions, polygons, bitmaps functions etc.
All ddraw surfaces, clippers, color keys, etc.
};

class CAudio
{
All audio....
};

And so on for the other two classes.
I am guessing that this wouldn''t be a good idea, any comments??

I''ve been thinking a lot of the way to design my 2D Engine
using OOP, my ideas start off well, but then I find some sort of pitfall usually because of the way the engine will interact with the Game Independent game objects.

Please if you don''t mind, could you (in pseudocode) show me rough outline of a simple 2D Engine using classes.
Remember that I want it split into 3/4 main parts:
Video,Audio,Sound and other.

And should I use inheritance?? Should I have a base Game Engine
class and derive other classes from it??

As you can see, I have many questions and I probably sound like a total newbie (I probably am!)

Thanks for your time
Regards, Julien.

Share this post


Link to post
Share on other sites