Structuring game engine code

Started by
14 comments, last by SunDog 10 years, 2 months ago

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.

Advertisement

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.

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%. wink.png

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 cool.png

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".

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!

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.

This topic is closed to new replies.

Advertisement