View more

View more

View more

### Image of the Day Submit

IOTD | Top Screenshots

### The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

# Structuring game engine code

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

15 replies to this topic

### #1Easy Rider  Members

Posted 08 February 2014 - 01:14 PM

I'm writing a game engine in C++ using visual studio 2012, and so far its going great and I'm having a lot of fun! One problem has been creeping up on me for a while now though.

What's the best way to structure a large game engine project?

By structure, I mean how each separate piece of the engine is laid out in the solution. Currently I have it all cut up into four separate VS projects:

Engine

- Contains all custom classes and structs, from Materials to GameObjects to Quaternions. This project doesn't really DO much, its just a place to store all the bits and bobs.

Render

- This project solely contains rendering functionality, as all the classes and types related to rendering are stored in the 'Engine' project. At the moment, all it contains is Render::init() and Render::render(), so maybe this is too small to constitute a whole project on its own.

Scripting

- This project only contains the code for AngelScript and Scripting::init() for setting it all up.

Runtime

- This project is what contains the main loop and interaction with whatever system you're on. My idea for making this separate is that this project should be the only one that deals with the underlying system implementation (just GLFW at the moment, but if I port to mobile or consoles the idea is that this can change without any of the other projects needing modification). This project handles starting everything up, running it all during the game, and shutting it all down at the end.

I'm also planning on adding 'Physics' and 'Network' projects once I get to those parts of the engine, and possibly a 'Resource' project that solely deals with loading and releasing external resources as the engine uses them.

When the engine is compiled, all projects are linked together as static libraries. My original idea for cutting things up so much, is so that once I start writing an editor, it can hook into rendering and scripting functions without being attached to the final runtime itself, and that if I ever want to change a certain middleware component (for example, from Bullet to Havok or from OpenGL to Directx) I can do so by only modifying the one project it relates to. While I'd like to keep this separation, I'm beginning to think that cutting it up into so many pieces may not have been the best approach. Inevitably, projects are starting to need to reference each other more and more (like the Material class in 'Engine' needs to have some OpenGL code, which should only be in the 'Render' project). The way I see it, I have two options:

- Spend more time encapsulating each project, so that there is no bleeding between them.

- Put Engine, Render, and Scripting all into one monolithic project, so that Runtime is still independant

Any thoughts on what would be the most convenient or "professional" solution to this?

Edited by Salty Boyscouts, 08 February 2014 - 06:04 PM.

### #2ddn3  Members

Posted 08 February 2014 - 04:55 PM

Your going to need these as well

UI : handles logic and events from user and handles stateful transitions of UI views.

Persistence and Packing : handles the serialization and deserialization of game states and objects.

AI : handles higher level intensive AI logic ( visibility checks, A*, optimization algor, behavior trees, etc.. ) which ever is appropriate for your game.

Making a "full" game engine is a herculean task these days, even pros don't do that anymore. They usually license out a 3rd party engine like Cryengine, UDK, Unity, etc.. The ones which do go for it, usually spend years on their engine only to see tech eclipse them and pass them buy ( unless your R*, EA, Bungie which can spend lots  on it to evolve with the times ).

If this is jut for learning go for it, but don't try to make the be-all engine.. Just get a handle on the overall picture..

Good Luck!

### #3Irlan Robson  Members

Posted 08 February 2014 - 08:03 PM

If is a larger software, take a look at the Component Based Entity System Architecture. Can be a little off-topic, but can save your time if you are interested to get a modular engine.

### #4Easy Rider  Members

Posted 08 February 2014 - 08:10 PM

ddn3:

Thanks!

You didn't really answer my question though, its not so much what I need as how I'm going to organize everything. Also as for what you've said about the troubles of developing a custom engine, I've thought long and hard about its merits vs. acquiring a license, and I've decided that for what I'm trying to achieve there doesn't seem to be anything out there that is well geared towards my goals. I'll be using plenty of libraries and middleware to ease the development process, and as far as staying on the tip of the technology curve, that has never really been my concern; as long as my game looks good, runs well, and is fun, then I'm happy.

irlanrobson:

I've had a lot of experience with the component-object model with Unity and other engines that employ a similar architecture, and I've decided to get as far away from it as possible. I'm sure there's people out there like yourself that work well with that particular solution, and I think that's great because you should be able to use whatever you find works best for you. Personally, I've found it to be a truly awful way of dealing with game logic and development, because you end up with random behavior scripts all over the place, and modifying behaviors can create unexpected domino effects as you can't be sure exactly what is using that component. In a strictly OO scenario, if I modify a class I know exactly what is being affected: instances of that class and those that inherent from it. If I'm creating a Katana, I want it to be an instance of the 'Sword' class which extends the 'Weapon' class, not an object with an equip ability and a swing ability and a damage ability and whatever other components it might need. Maybe its just how I think, I don't know, but I really don't like that system (believe me, I've tried to get used to it). I don't mean to offend you at all, if that system is how you like to develop games then that's awesome. I just personally don't like it.

Again, thanks for the response!

Edited by Salty Boyscouts, 08 February 2014 - 08:52 PM.

### #5Irlan Robson  Members

Posted 08 February 2014 - 08:36 PM

ddn3:

Thanks!

You didn't really answer my question though, its not so much what I need as how I'm going to organize everything. Also as for what you've said about the troubles of developing a custom engine, I've thought long and hard about its merits vs. acquiring a license, and I've decided that for what I'm trying to achieve there doesn't seem to be anything out there that is well geared towards my goals. I'll be using plenty of libraries and middleware to ease the development process, and as far as staying on the tip of the technology curve, that has never really been my concern; as long as my game looks good, runs well, and is fun, then I'm happy.

irlanrobson:

I've had a lot of experience with the component-object model with Unity and other engines that employ a similar architecture, and I've decided to get as far away from it as possible. I'm sure there's people out there like yourself that work well with that particular solution, and I think that's great because you should be able to use whatever you find works best for you. Personally, I've found it to be a truly awful way of dealing with game logic and development, because you end up with random behavior scripts all over the place, and modifying behaviors can create unexpected domino effects as you can't be sure exactly what is using that component. In a strictly OO scenario, if I modify a class I know exactly what is being affected: instances of that class and those that inherent from it. If I'm writing a 'Weapon', I want it to be a weapon, not an object with an equip ability and a swing ability and a damage ability and whatever other components it might need. Maybe its just how I think, I don't know, but I really don't like that system (believe me, I've tried to get used to it). I don't mean to offend you at all, if that system is how you like to develop games then that's awesome. I just personally don't like it.

Again, thanks for the response!

No problem. I've just gave you an option. Personally I never got a full implemented ECS. The communication between components becomes hard stuff. I'm currently doing a mixing of OOP Strategies, Component-Based, Functional Programming to get my engine working. Otherwise, I'm the creator of the engine and I want to get things made by me not just copying Unity's code and putting on my project even knowing that Unity has a powerfull Component Based System.

Edited by irlanrobson, 08 February 2014 - 08:36 PM.

### #6cdoty  Members

Posted 09 February 2014 - 02:45 AM

What's the best way to structure a large game engine project?

It will take years (and many cross platform projects) to find a design you are happy with.

I have finally gotten to the point where I do not hate my code layout with my Super Play game engine (http://superplay.info/).

For me I keep my 'global' interface in a class called either System or Platform. I depend on the project include directories to supply the location of files i need. The engine needs certain files from the game, which are supplied by the game project in specific file names.

Check out Super Play, the SNES inspired Game Engine: http://www.superplay.info

### #7MaxDZ8  Members

Posted 10 February 2014 - 02:16 AM

A good architecture is a start but execution is key.

I'm also planning on adding 'Physics' and 'Network' projects once I get to those parts of the engine, and possibly a 'Resource' project that solely deals with loading and releasing external resources as the engine uses them.
When it comes to physics I can tell you we're talking about <1000 LOC.

Don't over-engineer. Use an iterative, explorative approach.

Over all, don't write a game engine. Always keep in mind your goal. You will never get to something usable without keeping your design documents at hand.

Previously "Krohm"

### #8Aldacron  GDNet+

Posted 10 February 2014 - 08:00 AM

A great way to get a feel for engine architecture is to learn from people who have already done it. I would recommend Game Engine Architecture by Jason Gregory as a great place to start. It's full of good advice and examples. Of course, the ultimate teacher is experience. The experience of cobbling an engine together, no matter your approach, will open your eyes to better approaches in a way that you won't be entirely satisfied with the result. Do that a few times and you'll eventually end up with something you really like.

### #9Easy Rider  Members

Posted 10 February 2014 - 11:45 AM

Thanks everybody for the helpful feedback! I've decided I'm going to go with the first solution I proposed, which is to spend more time encapsulating everything.

Krohm:

I respectfully disagree. While writing this game engine, I've learned so much more and had so much more fun than I've ever have had in my coding experience, so I don't see why you would ever tell someone not to write a game engine (besides, they're probably sick of people telling them that anyway, as I can tell you that every time I've asked a question, somebody has tried to tell me not to do it). I'd go as far to say that every aspiring game programmer should at least attempt to write a game engine at some point in their career. This engine is the product of my free time over the past four months, and I have no intention of stopping now. I'm sure you mean well, but I have to ignore you on that point.

Aldacron:

I already own that book, and I also highly recommend it to anyone interested in writing their own game engine. There are a few points it does not cover (this being one of them) but over all it has plenty of tips that will save you hours of pain.

Anyway, thank you all again!

Edited by Salty Boyscouts, 10 February 2014 - 11:54 AM.

### #10TheSasquatch  Members

Posted 11 February 2014 - 07:34 PM

When it comes to physics I can tell you we're talking about <1000 LOC.

Really? I'm extremely skeptical of that one. Seems like the rudimentary collision logic for my tile-based 2D game was at least 500, all things considered. Granted, it was pretty bad and I wrote it while running a pretty high fever (it all made perfect sense at the time, and it even almost worked).

I'm in the early stages of working on a simple C++/DirectX engine as well, and found this topic while looking for discussions on the subject. Surprisingly difficult to find useful information; mostly just sloppy "here's how you render a single cube" tutorials and posts linking to said tutorials, or to that Game Engine Architecture book*. The biggest problem I'm having is figuring out in what order to work on things; I keep running into situations where I need a functioning x to test y, but I can't write x without a functioning y. And, of course, before I can think of a resolution, I get distracted by the realization that I have no idea how to handle z and spend the rest of the day reading z-related topics here and on stackexchange. I think a step-by-step list of generic steps/goals for incrementally putting together a game engine would be immensely helpful, but I've yet to find such a thing.

One useful tidbit I learned over the weekend: don't try source diving the various open source 3D engines in hopes of finding some best practice, or a common architectural thread that'll make everything clear--you won't find one. But you will find demotivation. And a headache.

*Off-topic, but seriously, they've delayed the 2nd edition by over a year at this point--Amazon had it listed as coming out early May 2013 when I first saw it, then October, then March, and now it's late May 2014. I'm not going to buy the first edition with a second imminent, nor will I preorder the second edition with it looking like it's going to pull a Duke Nukem Forever... Bad marketing strategy, tbqh. If they hadn't announced the second edition, I'd have bought the first a year ago.

### #11Servant of the Lord  Members

Posted 11 February 2014 - 10:20 PM

Even if you disagree with the idea that the best way to write engines is to first complete several games, Krohm gave some other very good advice as well that you don't want to overlook. He said:

• Don't over-engineer.
• Use an iterative, explorative approach.
• Over all, don't write a game engine. (I agree with this fully! But better to exclude this one and accept the other four, than to throw all five out)
• Always keep in mind your goal.
• Keep your design documents at hand.

I'll also toss in my personal opinion that for a engine or API to be of practical use in actual projects, it has to strike a balance between being overly general and overly specific. If it's too general, and can be used for any game genre, that's not a feature, that's a flaw! If it can be used for any game genre, than you basically wrapped an API with another layer of abstraction, but without getting any closer to the games that are trying to get made.

The more focused an engine is, the more it's actually practical to use - otherwise the programmer will have to write the real engine for the game over the API that's masquerading as an engine. In my opinion, when making engines, it is better to err on the side of too specific (more features can be added later if needed) than to err on the side of too general.

It's perfectly fine to abbreviate my username to 'Servant' or 'SotL' rather than copy+pasting it all the time.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Of Stranger Flames -

### #12Easy Rider  Members

Posted 11 February 2014 - 10:33 PM

TheSasquatch:

I'm not quite sure what Krohm was talking about either, as I'll be using the Bullet physics engine which is several thousand lines of code.

Also, when piecing together your engine step by step what can be very helpful is to use a library that handles that certain tasks for you, even if you plan on replacing it with your own code eventually. It can get you up and running very quickly, which is important because it lets you get onto the fun stuff as soon as possible. Just focus on the basics first (Basic rendering, scene construction, etc) and then start adding in advanced features when you have a good code base to rely on.

Servant of the Lord:

the best way to write engines is to first complete several games

I fully agree with that statement (I have several years of experience with UDK, Unity, and the Blender game engine myself), but the way Krohm phrased it was as if you should never make a game engine, which doesn't make sense to me. I do have a game in mind that I'm designing alongside the engine, but I'm also trying to keep the engine as reusable as possible.

Edited by Salty Boyscouts, 11 February 2014 - 11:25 PM.

### #13Servant of the Lord  Members

Posted 12 February 2014 - 12:28 AM

I hope Krohm's other advice at least proves useful to you. I mean hey, if 4 out of 5 of his tips proves useful to you, he's swinging a good 80%.

It's perfectly fine to abbreviate my username to 'Servant' or 'SotL' rather than copy+pasting it all the time.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Of Stranger Flames -

### #14Hodgman  Moderators

Posted 12 February 2014 - 12:44 AM

I'm not quite sure what Krohm was talking about either, as I'll be using the Bullet physics engine which is several thousand lines of code.

Well, the code that glues your game objects to bullet objects would probably only be <1k LOC

I use two different bits of physics sim middleware, and my code that integrates them both into the engine is 1134 lines (C++ headers and sources).

As for "don't write a game engine". I'd extend that to "don't write a game engine for the sake of producing a game engine... write a game such that by the end of it, you've got a very slim and focused engine that provides for the needs of that game and nothing more".

Edited by Hodgman, 12 February 2014 - 12:48 AM.

### #15Easy Rider  Members

Posted 12 February 2014 - 01:34 AM

Servant of the Lord:

Yeah, I'll definitely keep the rest of his advice in mind!

Hodgman:

I'm designing a game that goes along with the engine, though the engine will be definitely reusable. I'll admit that the fact that I'm writing a custom engine has influenced some of my design choices for the game (for example: I chose a snowy environment as an excuse to play around with fancy particle effects, though snow will be a huge part of the atmosphere of the game) but that's all part of the fun!

### #16SunDog  Members

Posted 12 February 2014 - 12:03 PM

I would echo the comments that I would write at least one game first, or if you don't want to do that, possibly develop the game in parallel to the engine ... add piece by piece

One of the most critical aspects of game engines is performance.   Its hard to know where the bottlenecks are, without a test beds.  On top of that, they are usually different for different games.

The problem with writing the game engine first, is that you aren't going to be aware of the specific problems that come up when trying to write a game.   If you don't know the specific problems (a game) well, its hard to solve the general problem (a game engine).   This is a common problem in software - general solutions are too general and they don't do anything particularly well (solution A) , while a specific solution B may be totally inflexibile but it does X really well.  And customers are usually going to be drawn in by doing X really well.   Only later, they'll complain that well "B can't do Y", but the usual solution is to come up with specific solution C, because they no longer care about X as much.

Don't fall for the mistake of "it will be easier to write my game once I write the engine".   It won't.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.