Jump to content
  • Advertisement
Sign in to follow this  
dean1012

Game Engine Design Questions

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

Hey everyone, I have been reading a ton of articles around gamedev and other sites lately and am trying to get a feel for designing and implementing C++ applications that use features such as inheritance. As I read these articles, a few questions pop into my head. At the risk of discouraging comment, I have decided to design a game engine. I have plenty of time to try and try again (and surely will as my computer science degree track progresses) and already have somewhat of an idea on how inheritance and the like is implemented. I have decided to use DirectX to render 2D tile graphics. No networking will be implemented. My questions are as follows: 1) Where to start? There are a lot of parts to a game engine. I am not sure which part(s) to design first; and even if I knew what to design first, how do I make sure all of the parts will fit together? 2) What components are involved? I know there will be a rendering component (for displaying 2D graphics, text, etc...), input component, audio component, timer component, and probably a few I don't know about. Are there any I forgot? 3) I have read several articles on game engines and most of them mention memory management systems. Is one necessary? If so, i'd really appreciate design and/or implementation suggestions. Although I'd appreciate any implementation suggestions, I'd prefer design questions. With a project as large as a game engine, I would like to have it designed on paper before I write code. I would like to leave room in the engine's design for future additions (so that when I learn more I can extend it to have advanced features like per pixel lighting) I appreciate any replys to this thread, positive or negative, and any suggestions on how to and how not to design the various components for the engine. Thank you very much, Jerry Smith Iota Beta chapter of Sigma Kappa Delta [EDIT] Added question 3 [Edited by - dean1012 on April 21, 2006 5:21:40 AM]

Share this post


Link to post
Share on other sites
Advertisement
To be honest, if you're interested mainly about designing a game engine sucessfully, rather than getting a fast game engine, I wloud suggest C#. It has the flexiblity of C++ (to a degree, but when you need the advanced features, you could always drop back into C++). C# is nice for designing engines and systems imo, because all the framework is down for you.

You mentioned that you want extensibility in your engine. In this case I can recmmomend some design books, especially "Head start design patterns." Have you seen the Enginuity series of articles? At the moment, these are generally the best for engine design.

Share this post


Link to post
Share on other sites
acid2,

I have looked at C# but I really would prefer to stick to C++ right now. My ultimate goal is to design and program a stable 2D game engine using DirectX. Of course, I probably won't accomplish that the first time around but that is okay. I do believe, however, that if I design it on paper and get a clear understanding of how it will work then I will have a much better (and easier) chance at programming it successfully.

I have read the Enginuity series, as well as other articles here and elsewhere, and have somewhat of an understanding on how it works. However, the same thing happens with every article I read: I kind of understand the end product but I don't see the design process. IE, what went on in the guy's head when he designed the Enginuity engine? This is why I want to design my own and need help getting started. I want to fully understand exactly how and why everything in my engine works all while avoiding simply copying someones code.

P.S. It wasn't my intention to sound rude if indeed I did.

Thank you,

Jerry Smith
Iota Beta chapter of Sigma Kappa Delta

Share this post


Link to post
Share on other sites
So here is what I have so far (in general terms, still not "designed" in my opinion):

I will have a kernel that will handle tasks (this idea is based off of the Enginuity series). It will allow me to add a new task, remove a task, pause a task, resume a task, kill all of the tasks, and execute the application loop.

Timer, Input, Audio, and Video will be tasks. Any other tasks will most likely be game specific.


Any suggestions on the specific components and how they fit together? I have a sheet of paper out and i'm trying to draw this on a flow chart and it just isn't clicking. Can anyone point me to another engine's flow chart? Or give me tips on how each component flows into the next?

Thanks,

Jerry Smith
Iota Beta chapter of Sigma Kappa Delta

Share this post


Link to post
Share on other sites
The interaction between game engine components is mostly the only real difficulty in designing an engine. Each individual component is quite simple if it is isolated.

The Task/Kernel approach by superpig works real well for me. I just made a post describing how my engine works at the thread Design Issues: Making systems know about eachother. Bare in mind that I have a "small scale" engine, i.e. this is not top of the line, but as hobbyist game framework, it is very functional.

Share this post


Link to post
Share on other sites
I've been working on a 2D "engine" with OpenGL/SDL for about a year and a half now. You will probably find that certain setups work well for some things and not others. Like my setup was originally designed for an action-styled game. I'm now adding a lot of GUI over the top of it for a strategy game which changes the basic way i deal with the system.

But long story short, start with a basic method to update/draw everything. You can hang everything else off of that. You will probably find that your update and draw routines are the ones that get used the most (if you profile your code, you'll see what i mean), so spend the time to make them work cleanly and fast before expanding the rest of your system.

Resource management and drawing are also things that i think should be nicely encapsulated. With a decent resource manager, you can put all of your image, sound, font loading and dumping in one place and ideally not deal with it anymore.

Drawing should be encapsulated so you don't have to worry about [insert API] calls. Ideally, you want it to be this simple:

image.Blit(x,y);

That helped my system a great deal.

Audio is pretty much it's own thing and usually runs in it's own thread, so you don't have to worry too much about how to integrate that.

If you plan an action game, collision detection is going to be one of the biggest hurdles for you. It's almost always ugly and can be done in a bewildering number of ugly ways ;-) Give it a lot of thought before you code it.

Share this post


Link to post
Share on other sites
A good design will always try to solve the requirements. Nothing more, nothing less.

Creating the utopian design is just that.

Before starting, define the requirements, limitations and features of your game.

For example:
Requirements:
- level based aproach
- tile based
- discrete unit positioning
- small world (maximum map has 500x500 tiles)
- interpolated unit movement
- asynchronous user input
- cut-scenes
- persistent user settings
- multi-player support
- 30 fps on Radeon 9xxx series
- Positional stereo sound
- Event driven sound score

Limitations:
- directx 9.0c or higher
- written in C++
- maximum of 200Mb of ram, 128Mb of video ram (or as implied by Radeon 9xxx requirement)
- distributable over internet (you can only afford hosting 5000 Mb per month)
- Supports mouse and keyboard (not necessarily joystick, gamepads, etc.)

Features (these can be scaped at any time if you run out of time/money/resources):
- Particle effects
- Shaders for unit rendering
- Optimized LAN support
- Support for player created units

After you do this, simply develop the design that fits these requirements, while considering the limitations, and adding as many features as you can.

I intentionally put "support for player created units" under features. While modability "could" be put under requirements, it adds a lots of upfront work for little immediate benefit.

Do not, ever, put everything under requirements. The less you have there, the better chances of success you have. If you're doing this for the first time, each feature in itself will take a huge ammount of time, and will prove to be completely mis-designed by the time you complete several requirements. But this will allow you to keep a close check on what you're trying to acomplish, how far you are, and where to focus next.

Basically, you start with project management, design only follows that.

Share this post


Link to post
Share on other sites
To Enselic,

I am currently reading your post now. So let's see here.

I will have a cKernel class that will simply allow me to add tasks, remove tasks, kill all tasks, suspend tasks, resume tasks, and execute the engine loop.

Each task will be it's own class derived from the abstract interface iTask.

cKernel's execute method will begin a loop. It will run all of the tasks in the list in order of priority and then remove any dead tasks from the list. The next iteration of the loop will then begin. Each iteration of the loop will be one frame.

So it is established that a task will be considered any process that needs to be run every frame. For example, video updates, sound, input, and timer functions.

so far what I have looks kind of like this (I am not that good with flow charts, so if my flowchart doesn't match the text i have in this reply please help me correct it):

http://img154.imageshack.us/img154/9974/flowchart0oz.jpg

To everyone,

Thanks so far for your help.

Thanks,

Jerry Smith
Iota Beta chapter of Sigma Kappa Delta

Share this post


Link to post
Share on other sites
Quote:
Original post by dean1012
My questions are as follows:

1) Where to start?



Logging. You're writing code that likely will not work, having a reliable logging interface [and other in-engine debugging tools] will help greatly.

Share this post


Link to post
Share on other sites
To Antheus,

Thanks for your advice. I never thought about it that way. I suppose I have a small list of requirements then:

Requirements:

tile based maps
movable/animated character (most likely needs to be timed)
audio capabilities
keyboard and mouse input capabilities

Limitations:

DirectX
C++

Features:

scripting capability (Lua)
3D EAX Audio

Thanks,

Jerry Smith
Iota Beta chapter of Sigma Kappa Delta

Share this post


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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!