• Advertisement
Sign in to follow this  

Where to start coding a game engine?

This topic is 3873 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've become interested in programming a properitry game engine for my projects needs. I have no clue where to start... Can anyone give me an insight on some good tutorials or something or advice :)

Share this post


Link to post
Share on other sites
Advertisement
Before we can answer that question, how much programing experience do you have? What programming language are you going to be using? How much game programing experience do you have?

theTroll

Share this post


Link to post
Share on other sites
You could start with the Enginuity series here on GameDev. It isn't really deep, but it should whet your appetite.

There are quite a few books on the subject, as well. I'm sure you'll get some opinions about the quality of those books in other responses, but I've heard the names of the first couple listed thrown around here a few times.

EDIT: Enginuity link fixed.

Share this post


Link to post
Share on other sites
No, don't use the Enginuity series, unless you know the downfalls of singletons. The engine he was writing was quite singleton heavy. If you're using it as a very general overview it might be ok but its highly dated at this point.

Share this post


Link to post
Share on other sites
Thanks! I have 2 years of experience with C++ and 1 Year with C#, it wouldn't matter to me which one I'd use...

EDIT: Haha, hadn't even seen you post that :P Ok, is there any other tutorial series?

Share this post


Link to post
Share on other sites
Thanks, but I need to code an engine for a company which will be doing several more games. To save time, we would like to code an engine :P

Thanks for the other link though :P

Share this post


Link to post
Share on other sites
Then I would suggest jumping into XNA. It is pretty easy, decent performance, no memory leaks.

theTroll

Share this post


Link to post
Share on other sites
For our engine, I used the bottom-up approch, starting from the
basic details, and building on them.

The basic details include calling conventions, data type sizes,
architecture types, and engine building (DLL and static *.libs).

All engines should have a logging manager and a memory manager
(Of sorts), espically if using C++. You can also provide a Task
Manager system (The Enginuity series describes how to do this)

You can then provide base interfaces to individual subsystems,
such as Video, and Input. Using the Task Manager, you can provide
multiple instances (if any) of the subsystems.

Other possible managers you can have are module managers, file managers,
diectory managers, etc. It all depends on what you want the engine to
do, and if portability is a concern.

On the usage of singletons--overusing them is bad. Probably the only
class that should be a singleton is the engine core--but, then again,
it depends on what your needs are.

Share this post


Link to post
Share on other sites
I've found over and over that any attempts to design a game engine without a game have been semi-failures, because once it came down to writing the game, the engine was forced to mutate substantially. Maybe it's different when you've had a lot of experience, but for me, the game always ends up needing things that the engine didn't plan for or needs them in a different way.

Instead of building engine, game, game, game, build the engine and first game together. Take longer about it and take the time to refactor and redesign as you go. That way you will end up with an engine that actually suits your needs.

Share this post


Link to post
Share on other sites
Quote:
Original post by Shadowlan
Than how should I code the game? Pure DirectX? Pure OpenGL?

You can't mix OpenGl and DirectX, so it would be either plain DX or plain OpenGL. The choise is up to you.

What's important is to make sure that things you use often are correctly encapsulated. If you are cereful about that, an engine will emerge from the code of your gane without actually having to cope with the writing of an engine in the first place. That's monthes of work which are done automagically.

Share this post


Link to post
Share on other sites
From your starting position (=0) planning to do a game engine
and then some games is not a good idea. There's no way you'll
get it right the first time. To paraphrase the bible
(That's Brooks Mythical Man-Month FYI)

PLAN TO THROW THE FIRST ONE AWAY

Do a simple game based on your best ideas, and plan to start
over from scratch after you've learned a few lessons.

Share this post


Link to post
Share on other sites
Quote:
Original post by Shadowlan
Thanks, but I need to code an engine for a company which will be doing several more games. To save time, we would like to code an engine :P

Thanks for the other link though :P


I don't mean to be rude or condescending but to be in such a position you should have had enough knowledge & experience to not ask such a question. Furthermore you've given us very little information such as the type of game to give you any useful advice.

I really think you're heading for trouble so i suggest either using a pre-existing commercial or open source game engine or make one out of pre-existing components such as Ogre for graphics and something else for physics and so on. This is the ony way you'll be saving time not writing one from scratch.

Share this post


Link to post
Share on other sites
Quote:
Original post by snk_kid
Quote:
Original post by Shadowlan
Thanks, but I need to code an engine for a company which will be doing several more games. To save time, we would like to code an engine :P

Thanks for the other link though :P


I don't mean to be rude or condescending but to be in such a position you should have had enough knowledge & experience to not ask such a question. Furthermore you've given us very little information such as the type of game to give you any useful advice.

I really think you're heading for trouble so i suggest either using a pre-existing commercial or open source game engine or make one out of pre-existing components such as Ogre for graphics and something else for physics and so on. This is the ony way you'll be saving time not writing one from scratch.


I would say that's more than a bit too quick to judge. You can be a C++ guru spending your time writing databases for big-name companies and just not be sure where to start with your traditional game engine. Is that the case here? I don't think so, but bashing newcomers seems a bit elitist, which is something I hope GameDev is not. Nothing personal.

EDIT: Also, a well-designed game engine is also *never* consigned to any one particular genre. Struck me later on, but 'tis true.

For starters, have a look at Enginuity and see all the basic components, as they're all pretty much there. I and the rest of the community strongly suggest that you come up with some of your own implemenations for most things, but you're still going to need some form of a memory manager, engine class, renderer, etc.

As a jumping off point, (and you can tie all of these together as you may, I'm not going to tell you specifically how to do that as what works for me may not for you) I give you this "shopping list":

- Look around and get a couple articles on memory pools. These are pretty fast if done correctly, and if you combine them with some of the reference counting functionalities found in Enginuity you'll end up with something pretty efficient/robust. This is a pretty good place to start off as you can get some experience working to implement technologies found in research papers.

- I also would suggest to take the time to learn the ropes of multithreading, OpenMP may be just what the doctor ordered for you. Consider expanding some elements of the pool to use mutexes(mutices?).

- Next try and come up with a decent console system. There are a few decent implementations on FlipCode and Enginuity has a pretty solid framework as well. Some aspects should be cut out, (like the initial settings mechanism-- it sucks and is pretty easy to solve at the cost of the variables not being memory managed, but that's hardly necessary anyways as it strikes me as being rather stupid to manage something that shouldn't be deleted really at all.) but once again the basic structure is fine.
Note: Actually configuring some elements of the memory pool with console variables is also a handy tuning element to have. My particular engine allows for block and page size to be adjusted at runtime with the console system. Fun fun :)

- Profiling is pretty handy, I think Enginuity's particular system is fine as well. You *will* need this at some point to optimize, but you don't necessarily need this during the very very early stages of design. Do consider doing this early on to ease the difficulty of integrating it later at a later date.

- Finally look into miscellaneous management functions and methodologies for GUIs, models, textures, particles and other staple elements of a game. There are more possible ways to do this than there are games on the market, but pretty much remember that linked lists are your friend.

- Once you have that all out of the way and all the bugs have been mercilessly stomped into oblivion, it's finally time to design your visual and audio rendering APIs. My personal suggestions are DirectX and OpenAL, respectively. If you're feeling especially daring, try and separate your engine's rendering functionality completely from the API. My own currently supports DX9 and DX10, with a wee bit of OpenGL 2.1 functionality and perhaps 3.0 support when it becomes available. At this point that sort of thing should be pretty easy, just remember to make your own structures/classes/whatever to store lights, cameras, models, etc. That should be pretty easy, if not already done, and then all you have to do at that point is just pass the required info from your homegrown containers into the shaders and the like you use in rendering. Congrats, you have an engine!

I also suggest you take as much time as possible learning all the little optimizations and quirks of the language you're using in order to wrest every last drop of performance out of your hardware. GameDev has a couple of good articles here, and you can find a lot of useful tricks and techniques on FlipCode and The Code Project. Never assume that "I'm probably never going to need this" when reading Dr. Dobb's Journal or whatever, as I made that mistake earlier on. But finally, and most importantly, have fun while doing all of this. Nothing can have more of an impact on the quality of the finished product, as without some sort of fire/drive you're never going to come up with any kickass, uber-efficient solutions to your problems. Keep at it.


Good luck in your endeavours, I hope to publish a much more in-depth article on exactly this sort of thing very soon. Just ask here if you have questions, of course.

Share this post


Link to post
Share on other sites
Quote:
Original post by Emmanuel Deloget
Quote:
Original post by Shadowlan
Than how should I code the game? Pure DirectX? Pure OpenGL?

You can't mix OpenGL and DirectX, so it would be either plain DX or plain OpenGL. The choice is up to you.


This is probably what you meant, but I just thought I'd clear up any potential confusion... You can mix the two using OpenGL for graphics and DirectX for everything else -- DirectSound, DirectInput, etc. You can even use both OpenGL and Direct3D/DirectGraphics in the same application, just not simultaneously. OpenGL and the DirectX graphics modules cannot be used together simultaneously, which I'm sure is what you meant.

Share this post


Link to post
Share on other sites
I would suggest creating a game with the engine. That way, when making the game you will notice things that you could add to your engine to make things easier and less repetitive. Then you can add to your game engine and constantly improve it to simplify your own game and add functionality that you may not use in that game, but it could be useful later on.

As for what InvalidPointer said about game engines and that they should not be consigned to one specific game genre, I am in the same state of mind as him. I believe that game engines should be able to be used in any game you program to simplify it. If you make it specific to one genre, you are probably putting so much of the code in your engine, that it is hardly reusable at all and has to be used with that specific type of game.


Share this post


Link to post
Share on other sites
In reply to what InvalidPointer said, don't optimize early! I'd also likely skip my own profiling code, just get AMD/Intel's profilers, they're MUCH better then anything you could write. Once you go multi-threaded your own profilers go out the window most times anyways. This isn't to say they're useless and shouldn't be at all difficult to add later on either. I'm not sure where he got the idea they would even be remotely difficult as a last minute introduction. They should only be stuff you put in for a few tests then remove anyways.

Even if you just use OpenGL or D3D I'd still abstract the renderer so adding in another rendering path (D3D9 then D3D10) will be much easier.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement