Hello,
In the past couple of weeks I started the (huge) task of designing a game engine from the ground up. I have read a couple of books that were good and I learned something from each one, but still the task proves very difficult. I am trying to use UML to design it, but it is so big that it looks impossible to get almost everything down at design stage.
Do you have any advice as how I should approach designing such a big piece of software? I did software designs before for various projects at work, but none was so complex as this one. Also, it is quite hard to identify use cases, giving this is not an end user application, and I never designed a middleware before, so any input will be appreciated.
Thanks.
Designing a game engine...
Draw up the specifications for the game that this engine is going to be used to build first, and then you'll have your use cases.
Developing an engine without having a companion game project (or several) will do that - you won't have concrete requirements, specifications, goals... it'll suffer feature creep, or have groups of features that don't gel together. It's like trying to design a vehicle when you don't know if it has to get you to the corner store or get you home from outer space - design a vehicle without those specifications and god knows what you'll end up with.
Developing an engine without having a companion game project (or several) will do that - you won't have concrete requirements, specifications, goals... it'll suffer feature creep, or have groups of features that don't gel together. It's like trying to design a vehicle when you don't know if it has to get you to the corner store or get you home from outer space - design a vehicle without those specifications and god knows what you'll end up with.
Author
Quote:Original post by Hodgman
Draw up the specifications for the game that this engine is going to be used to build first, and then you'll have your use cases.
Sounds like a good advice, unfortunately I do not have a game project to write this for, I was thinking of designing and writing a game engine just for learning. However, I realize what you are saying would be very helpful in determining the use cases. In this situation, should I just make up a game project (which eventually can become the demo game) so I can nail down the requirements?
I wonder how companies behind other engines, like for example Unity or C4, did this task, as they didn't make the engine for a specific game...
Quote:Original post by meeshoo
I wonder how companies behind other engines, like for example Unity or C4, did this task, as they didn't make the engine for a specific game...
That's why most of those companies only find customers within the indie scene and not professional game studios. U wont really find a AAA game using C4. Thats why "we should write games, not engines (tm)". An engine is usually the result of the requirements of your game. U wont be able to produce something useful, unless u've worked already with a professional game engine on a real game.
Read this.
Writing a game and extracting the engine is the only way to make something useful - if you lack experience.
It doesn't need to be a fully fledged game with great assets and interesting mechanics, but it must fully exercise the engine. If you design a tech demo that doesn't reflect real use then don't be surprised if the engine turns out to be poorly designed in the areas the tech demo didn't cover.
The fallacy of such an approach is frequently evident by many "engines" with pretty tech demos that never seem to grow into games.
You know yourself that you need experience to guide design. The designs you made at work would not have been possible had you done smaller scale design beforehand. Design is an iterative process (both during one project and between different projects), you cannot immediately jump to the deep end when you lack experience in a given domain.
Writing the game will give you this experience.
Writing a game and extracting the engine is the only way to make something useful - if you lack experience.
It doesn't need to be a fully fledged game with great assets and interesting mechanics, but it must fully exercise the engine. If you design a tech demo that doesn't reflect real use then don't be surprised if the engine turns out to be poorly designed in the areas the tech demo didn't cover.
The fallacy of such an approach is frequently evident by many "engines" with pretty tech demos that never seem to grow into games.
You know yourself that you need experience to guide design. The designs you made at work would not have been possible had you done smaller scale design beforehand. Design is an iterative process (both during one project and between different projects), you cannot immediately jump to the deep end when you lack experience in a given domain.
Writing the game will give you this experience.
Author
Quote:Original post by cruZ
That's why most of those companies only find customers within the indie scene and not professional game studios. U wont really find a AAA game using C4. Thats why "we should write games, not engines (tm)". An engine is usually the result of the requirements of your game. U wont be able to produce something useful, unless u've worked already with a professional game engine on a real game.
Hmm, interesting idea. I have some game designs written on paper, however I don't have any that would require more than a 2d engine or a simple 3d engine. I think then I should first try to think of a game genre that is more visually demanding and try to fit one of those designs there.
Author
Quote:Original post by rip-off
Read this.
Writing a game and extracting the engine is the only way to make something useful - if you lack experience.
It doesn't need to be a fully fledged game with great assets and interesting mechanics, but it must fully exercise the engine. If you design a tech demo that doesn't reflect real use then don't be surprised if the engine turns out to be poorly designed in the areas the tech demo didn't cover.
The fallacy of such an approach is frequently evident by many "engines" with pretty tech demos that never seem to grow into games.
You know yourself that you need experience to guide design. The designs you made at work would not have been possible had you done smaller scale design beforehand. Design is an iterative process (both during one project and between different projects), you cannot immediately jump to the deep end when you lack experience in a given domain.
Writing the game will give you this experience.
Thanks for the article and the advices, they were very helpful. I have a game design that has been on my mind for a few months now(already written a part of it), I think i can adapt it to a 3D environment, I'll start by doing that.
Author
I'm back with another question. Whenever I develop a modular application (like a game is), I usually go for a plug-in system. This is quite easy to implement if I decide that game should run on only one platform (e.g. Windows) through dlls. However, building a multi-platform plug-in system can be difficult from what I read in during some research. I found a good article about it, but it is quite complicated and I don't know if the overhead is worthy.
Should I try it or I should just go with a big exe for the game and a big dll or static library that contains all reusable modules?
Link to the mentioned article http://www.drdobbs.com/cpp/204202899
Should I try it or I should just go with a big exe for the game and a big dll or static library that contains all reusable modules?
Link to the mentioned article http://www.drdobbs.com/cpp/204202899
I just put each of the modules in it's own static library. Unless you want the end-user of the game to be able to add their own modules (mod the engine, maybe?), then there's not much need for the core engine modules to be dynamic plug-ins.
Author
Quote:Original post by Hodgman
I just put each of the modules in it's own static library. Unless you want the end-user of the game to be able to add their own modules (mod the engine, maybe?), then there's not much need for the core engine modules to be dynamic plug-ins.
Well, the only thing i want is to for example to have a Rendering interface and more renderers that implement it (one for direct x, one for opengl, one for opengl es, etc). Of course, for start I'll have only one (direct x), but I want to keep it open for porting on other platforms. Same thing for the input system. I think this result can be achieved with static libraries, thanks for the tip.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
