Game Design, Programming and running a one-man games business…

Cleaning the engine

It’s tricky to get the timing right. Some people do nothing but update their engine. they have re-factored it so much and re-implemented everything so often that it is a true work of art, worthy of actually putting in books on how to code. These people never ship a game. The other extreme is people who are still using assembly language routines for loading in ini files because they wrote them in 1996. These people have tech support issues galore, and are probably still using Directx3.

In between there somewhere is common sense, if you *are* going to write your own engine and not use someone else’s. I think, from chatting to devs and surfing a lot on developer forums, that people tend to want to redesign their engine after every game. They consider that quite a major compromise compared to their real hidden urge to do it every morning. The thing is, if you are doing that you aren’t really writing an engine, you are just writing a new game from scratch all the time.

lexus

I tend to go with a system of marginal improvement. I still have some code from about 5 games ago (non critical stuff like ini file loading, text handling, game timers and some math stuff), but a lot of it is fresher. The graphics stuff, as you would imagine gets a major refresh more often, and my engine only contains some pretty ‘raw’ directx wrapper and vertex buffer / text engine stuff. The actual ‘scene management’ for my games is done in the game itself.

Despite the occasional between-project update and maintenance, occasionally you have to step in and clean things up. The last big update was when I went from Directx7 (Democracy 2, Kudos games…) to Directx9 (GSB,GTB,Democracy 3). This time I’m updating almost everything BUT the directx version.

I recently bought Visual Studio 2013, mostly for the concurrency profiler to enable me to experiment with multi-threading more. This was a good opportunity to take a look at some of the flakier things in my engine. I have a lot of warnings in there for data-conversion and other sloppiness. I also have code I never use (I’m culling it), and the worst and most embarrassing thing is that I can’t decide if I like char* or std::string. I Figure that std::string must be at least a bit better, more robust and safe than char*, so I’m trying to purge all that char* from the engine, and eventually, the game. I’m also planning on re-wiring stuff so that the main game code doesn’t have any FILE* or other old fashioned stuff, but uses my file wrapper more.

Why? Mostly because I can see me heading towards cross platform eventually. maybe not with the next game, but baby-steps and all that… Plus it makes life easier if getting my engine ported is a less messy business. I’m sure after a few days of sorting out this stuff I’ll be climbing the walls and wanting to code some explosions again…


4 thoughts on Cleaning the engine

  1. Cliff, I’m curious to know if you ever hit the scenario where you make updates to your engine, the end result being it nicer and easier to work with. Then you perhaps go back to an older game to fix one or two things and it feels so much harder to do because it’s running the older engine.

  2. I’ve found C++11 to be mana from heaven. I don’t do game development but it’s allowing me to write code with native performance that can be compiled on just about any platform. It’s beautiful.

  3. About char* vs std::string, you might find std::string_view (which is a proposal having an implementation in boost as boost::string_ref) might be very interesting in a lot more cases than std::string, and have similar usage than char*.
    It should be easy to re-implement (or copy paste from boost) in your code and would make life easier than with char* without the necessary copying of std::string (for example when you just want to refer to some text in a big language-relative text buffer).
    Here is the proposal, it describes what will probably appears in the future in C++ and have some rational so that you can tweak your version if you think some points don’t apply to your case: http://isocpp.org/files/papers/N3762.html

    About FILE* well I would recommend at least encapsulating it’s behaviour into a RAII type.

    My current game is made of several engines “glued” through game-specific engine glue code, which is I believe not that usual. It’s the step between you, implementing everything yourself, and the guy using a framework.
    The fun thing is that for this particular game I just have no choice (I could do like you but I believe that I don’t have enough time, the game-specific part being already pretty hard/long to implement).
    I always fear the tendency to refactor too much, so what I do currently is setup high-level tasks (like for example, playing some placeholder musics to have the game ambiance) which drives my game-engine development (like developping the audio parts of the game, to match what I need currently).
    I make sure to isolate each part as much as I can, but that’s always difficult.

    As I don’t have much to show yet I tend to think I might be doing the mistake of never finishing the game. But looking at my task list (I’m using Trello for this) I can see that it’s just that I worked first on non-visible hard problems to solve to even allow the game to be possible. I made a previous version of this game that was stopped because of unrelated issues, and I first did the visual parts. At the time I realized that there were fundamental problems to solve that impacted all aspects of the game’s code, which I should have thought before writting the first line. Now that I’m working on a new version of this game, I solved these problems first, then (in recent months only) started to get some visuals.
    I can’t wait to reach the point I can finally focus on making the game “pretty”!

  4. I really don’t understand, why did you made your engine based on DirectX? I would advice to use something like SFML or SDL 2. That wouldn’t snatch any power you might get from raw DirectX but would give cleaner and Multi Platform code.
    And why scene management isn’t part of engine? That means you are basically rewriting scene management again and again (until you copy paste).

Comments are currently closed.