Sign in to follow this  
hereticprophecy

Designing Game Engines

Recommended Posts

My question: what are the primary design philosophies behind game engines? While I'm fairly new to game programming, I've noticed that I have much more fun programming a game's architecture rather than the gameplay, graphics, or GUIs. So I endeavored to start programming a basic RPG engine based off a pre-existing pen-and-paper game to get some practice. However, I've come to the realization that I'm not exactly sure what these engines should look like, what they should be doing, and how they should be structured. I can imagine that an engine of the scale I'm working with can pretty much be designed however I need it to be, since performance and generalization will come in time: I'd just like to get moving in the right direction now, rather than changing bad habits later. I'm working in C++ atm, while I'm learning Python, and if it arises, I'll be happy to post some of my primary classes for critique. Any information would be appreciated: links to articles, references to books, personal experience, useful algorithms, and the like.

Share this post


Link to post
Share on other sites
No articles to point you towards but three things I always try to keep in mind while designing game engines.

1. Write the least code possible.
2. Write the clearest code possible.
3. Never be afraid to rewrite code.

These are all of equal importance in my opinion. They arent necesarily guidelines for general game development, since time constraints and other things factor in, but for learning to design good things, they are crucial.

Share this post


Link to post
Share on other sites
If you're designing a game engine, perhaps a good way to start would be to list all the actors in your game. Then start listing all the possible objects in the game. From there, you could start listing the attributes and abilities of these characters and objects. Once you have all these things on paper, you could start building your classes. I'd say more, but I've got to go now. Good luck.

vinb :)

Share this post


Link to post
Share on other sites
The shortest answer is: you won't know how to put an engine together until you actually put one together. That will teach you some core basics. You can start at it like this:

1) get something drawing
2) get the camera moveable by user input
3) get something moving randomly
4) get something moving "intentionally"
5) get 2 things colliding
6) get some sound playing

At the end of that you'll know a great deal. Then you can throw away all your code and design something that makes a little more sense.

Another approach would be to get an open-source engine and see how it's put together. Then try to modify the game by adding a feature and see where that architecture limits you.

The only real "core" architecture of a game engine is that is must have a list of objects that get updated and drawn to the screen. Everyone works out the details differently.

-me

Share this post


Link to post
Share on other sites
My project is in the process of implementing an engine to use for the project. It has been a really interesting experience. While our team (there are just 2 of us) has quite a bit of general development experience, neither one of us really has much experience of engine design. Also, neither one of us really has much game development experience beyond our existing code.

To sort of second what has already been said, we learned a lot about game programming as a result of just trying it. We worked on what was in hindsight really a bad code base for a long time. With that experience (and the help of some good books), I am hopeful that our rewrite will be a major step forward. I'd recommend reading Game Coding Complete if you can find it. If you care to read more background into our abandoned (failed?) code base, I have written a little on our development blog: Reasons for a Rewrite and History of Crown and Cutlass. I guess while I did learn a lot, I would recommend you avoid my mistakes and do a little research before just trying to make something appear on the screen. In our case, that "ooh look, I can draw something" code was the start of the game. That was ugly.

The other thing that I would recommend that you do is play with some existing engines. I have not done this, and time and time again I think "I wonder how the Unreal Engine handles such and such". One of these days, I'm going to just try to make some mods to see how commercial engines work from the engine user's perspective. It seems like having experience with the strengths and weaknesses of other game engines would be very helpful in designing your own.

One last thing: I found several promising open-source "3D engines" but I didn't really find any "game engines" that I was satisfied with. If you are looking for open-source projects for reference, just be aware of what the project tries to do and what it doesn't try to do. I should also note that while we are writing our own "game engine" we are using Ogre for the graphics. It is nice not to have to worry about that whole side of things...

Share this post


Link to post
Share on other sites
It's very true that in order to write a decent flexible engine, you have to have written a number of games. This is because without doing so, you won't understand the requirements of different games - you can only guess.

I'd actually recommend working on a number of games before moving into engine development because of this.

That said, if you do decide to go ahead with the engine development, Illumini's post is highly useful. Basically, if you only write what you need, you don't spend time speculatively writing stuff you might not need. Writing clear code is always a good thing. Not being afraid to rewrite is an explicit acknowledgement that you're exploring a problem space.

Even though I've written a ton of stuff, I still adopt this basic approach, because I'm always finding ways to re-invent an approach to a problem that I had already "solved", but a new approach is more elegant (or efficient, or whatever).

Share this post


Link to post
Share on other sites
I recently got done reading Jeff Plummer's masters thesis, A Flexible and Expandable Architecture for Computer Games (pdf), and found it quite interesting. If nothing else, it might help inspire ideas and direct you in your own attempt to evaluate design ideas you come up with.

I'm personally working on my own variation of his design, that uses a central component that coordinates rather than stores data that other components use (gameplay, input, graphics, physics, et cetera). My hope is that it will be able to easily and efficiently allow the creation of wrappers for existing engines (Ogre, ODE, and so forth), along with easy modification of higher level components (gameplay, for example). We'll see how it turns out. (Or I'll see how it turns out, and if it turns out poorly, then no one else will see how it turns out. [smile])

Share this post


Link to post
Share on other sites
Thanks for the replies, everyone.

Illuminati and Palidine pretty much summed up what I've been doing so far, so it's good to know I'm on the right path. My next question lies in the content of a game engine or what aspects of the game it should be powering.

I read a little on Dungeon Siege's architecture and am attempting to organize my RPG in a similar fashion: a handful of base classes, many derivative classes for specifics. Then I read up on some of the more powerful FPS engines and noticed they were not as much about organization as they were about connecting graphics, physics, and player control.

Now, I understand that RPGs and FPSs are vastly different, but should the average game engine include a physics module, graphics module, etc.? It seems to me that it's not as paramount for an RPG (since I'll be starting in text) to have a strong dialogue between the game mechanics and say physics, but should I be concerned with that type of overall structure in the earlier stages? Can those sort of things be ironed out later?

Share this post


Link to post
Share on other sites
Your problem is that you think the word "engine" actually means something specific, when in fact it really just means "anything in the game software that isn't the game". Ask 10 developers what their engine consists of and you'll get 10 subtly different answers. Thus there is no such thing as the "average" game engine, and two teams could implement almost identical games in completely different ways. I am going to repeat what others have said and say that you won't know what you need in your code until you develop a game with it. Until then, you're just flailing around implementing features that you suspect someone might need, creating interfaces that you suspect might approximate the way someone will need to use them.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this