Archived

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

Making an engine

This topic is 5573 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

I pretty much got the start of some simple class wrappers for OpenGL, DirectInput, DirectAudio, and DirectPlay. Now that I have these simple classes working I was thinking of putting them all together into some kind of standard starting point when I go to write a game (or attempt a piece of one). Should I keep these things seperate in thier own little classes or do you throw them altogether into one giant class? Do I compile the result into a lib or dll or just keep it as source code? Whats the general layout of a game engine and what all should it include or exclude? Thanx Much, Christopher

Share this post


Link to post
Share on other sites
The first 2 questions are simple:

quote:
Should I keep these things seperate in thier own little classes or do you throw them altogether into one giant class?


Divide them up! Having a seperate class for each subsystem really imporves code readability and maintenance. You might provide one manager class which initializes each subsystem with one call, but it''s not a big deal.

quote:
Do I compile the result into a lib or dll or just keep it as source code?


Whatever you like. Just consider that if you leave it as source code, you''ll always have to manually add the source files to your project (or makefile) for each new project you create. Going the lib route is simple, allowing you to keep the lib in one directory and just making sure you link each project to it. The DLL route allows you to update the lib without recompiling any of your games (if you load the DLL via LoadLibrary, otherwise it defeats the purpose). Another option, one that I am currently using, is to make the lib itself an exe, and any game code you create goes into DLLs. This approach has some nifty advantages.

quote:
Whats the general layout of a game engine and what all should it include or exclude?


This question is nearly impossible to answer (without a 10s or 100s of pages, methinks). What to include/exclude depends entirely on what sort of games you intend to support. 2D? 3D? FPS? RTS? MMO? Landscapes? Interiors? What sort of effects? Remember, the term game engine, while thrown blindly about by many people, is not the same as an OpenGL wrapper. Game engines power games. Consider the Quake engines. They are designed for Indoor First-Person games. Making something along the lines of Tribes 2 would be impossible without adding a terrain renderer.

My advice, consider what kind of game you want to make. Do some research around GDNet, Flipcode, Gamasutra... Tailor your engine for that type of game. But try to keep your design modular and flexible. With a good design, you can drop in new features to support different types of games later.

Share this post


Link to post
Share on other sites
quote:
Original post by brekehan
I pretty much got the start of some simple class wrappers for OpenGL, DirectInput, DirectAudio, and DirectPlay. Now that I have these simple classes working I was thinking of putting them all together into some kind of standard starting point when I go to write a game (or attempt a piece of one).

Should I keep these things seperate in thier own little classes or do you throw them altogether into one giant class?

Do I compile the result into a lib or dll or just keep it as source code?

Whats the general layout of a game engine and what all should it include or exclude?



I think you should divide the engine into a game engine (data-driven, loads the datafiles, and plays the game) and a graphics/sound/network/input engine. The game then calls the engine to do all the lowlevel stuff.

Maybe a .dll isn''t right, it would let people reverse engineer your interface and allow people to write their own game using your engine. For speed, size etc. it would be best to compile it together, so keep it either as source or lib.
It doesn''t have to be one class, a bunch of classes would be better, then your game can define as many class variables as needed.

Share this post


Link to post
Share on other sites
quote:
Another option, one that I am currently using, is to make the lib itself an exe, and any game code you create goes into DLLs. This approach has some nifty advantages.


This is precisly how the Quake3 engine does it.

quote:
Maybe a .dll isn''t right, it would let people reverse engineer your interface and allow people to write their own game using your engine.


I would consider this a good thing. In fact, I would even release the source code needed to compile the game specific dll that plugs into the ''engine''! If people make MODs, then more people are playing your game. The more people play your game, the better.

quote:
I think you should divide the engine into a game engine (data-driven, loads the datafiles, and plays the game) and a graphics/sound/network/input engine. The game then calls the engine to do all the lowlevel stuff.


What he means is, you build your ''engine'' as a bunch of ''managers''. For instance, I have a ''manager'' that handles all the texture stuff. It loads them from file, prevents them from being loaded twice, etc etc. Then, the game itself just calls ''TextureManager::getSingleton()->loadImage(filename)'', which returns an ID for the texture data that the game then uses when binding the texture.

quote:
For speed, size etc. it would be best to compile it together, so keep it either as source or lib.


Yes, dlls can be slower - but would it be noticable?

Share this post


Link to post
Share on other sites