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

Stuck in a world of legacy code

cliffski

I use the odd bit of code that has char* in it. There I’ve said it. It feels like a big confession. I bet some programmers just sprayed their coffee everywhere. I’m sorry. They say the first step is admitting that you have a problem.

I’m a very very productive game developer. I churn out a lot of very very big and ambitious games. One of the ways I manage that is that I don’t change my ways unless I can make a really good argument for doing so. I never learned what on earth .Net was, no I don’t mind it’s passing. I don’t really know C#. I have no idea what design patterns exist other than singleton. I have no idea what a UML diagram is (is that even a thing? I don’t know…)

You have no idea what a huge big deal it was for me to switch from directx7 to directx9. That took some doing*, and it’s why I still use DX, not OpenGL (which would make apple mac ports far easier and cheaper).

While I’m in confession mode, here are a few other howlers you might be amused by:

  • I manually type out for() loops without using for_each()
  • I use FILE* not the stream stuff
  • I use my own GUI library, and Input code, not third party stuff. In fact I wrote my own hash table code too. The only stuff I rely on is STL, and only partially use std::string

Scary huh?

Why am I such a luddite? Well it comes down to time. If I had regular bugs that I could attribute to passing around char* now and then rather than a std::string, then things would be different, but I know all the functions that handle chars better than I know STL, so I code much faster that way. I have a slight niggling doubt that for_each() is as fast as it should be. I can’t remember the iostream syntax, so I use FILE*, because frankly my file handling code was written years ago and still works fine, so why change?

I see a lot of coders jump on every code bandwagon, and learn new stuff all the time. They are constantly rewriting their whole engine, and constantly going back and changing the code they wrote a month ago. They rarely ship games, and very rarely ship large ones. To me, it always makes sense to make occasional big jumps, rather than constantly fight to keep up with the latest stuff. I have no idea what was in Directx8, it passed me by totally. I’ll maybe move to directx12 (more likely opengl).

It may make me seem old fashioned, but it’s incredibly productive.

*it’s not learning the API, but building a bug-free FAST engine that correctly encapsulates the API that takes time.

17 thoughts on Stuck in a world of legacy code

  1. Naah, nothing terrible here. I’ve been programming C++ for only a few years (probably 3x less than you have), but I also prefer FILE* to the stream stuff. The API is simply better, much less convoluted. Even char* doesn’t cause coffee-spraying for me ;)

  2. You’d be surprised how many people use stdio instead of streams for file handling.

    I probably shouldn’t talk though, I don’t do C++. I learned the basics (very basics, like pretty much classes and nothing else, not even templates), but honestly I can’t be bothered with it. I can deal with higher level languages, I can deal with C and assembly, but for some reason I can’t deal with C++. It’s like an ugly middle point that can’t decide what it tries to be.

  3. Hey, as long as it works fine in the end, honestly it doesn’t matter.
    But I’m not a “real” programmer… I do AS3, so maybe you shouldn’t listen to me :P

  4. This is something I’ve been wrestling with recently. I suspect I’d be more productive as a developer if I concentrated on core C++ (agree about iostreams – I suspect thats why boost::format exists), but then I keep thinking if I had to get myself employed again, learning a growth technology like WebGL/HTML5 would help. So I end up vaccilating…

  5. I pretty much live in both the C/C++ world and the C# side of things (well, and a bit of Java and Python and Delphi) for my job. It is interesting because there are features I like in C# that I wish C/C++ had.

    But, when I write C/C++, I pretty much prefer the stdio stuff because that is what I started with (back when ANSI C was the “new” thing). It didn’t have all the extra trappings and syntax that supposedly make your life better but I found it was just to be different. The f* functions were good enough and pretty simple; I also pretty much use the equivalent in C# too.

    The really fun things is when you move. Right now, my current project is to move a VC++ 6 project to VS 2012. It is forcing me to learn about all the things that have changed in almost a decade even with C++. There is something to be said about always keeping up or never keeping up, but jumping around is the worst of both worlds.

    Though, OpenGL would be awesome… because you know, Linux. :) I’ve been playing GSB pretty heavily since the Humble Bundle got it (and more so when Steam got on Linux).

  6. Have you had a play with/considered Unity or UDK et al, you lose some control but gain powerful middleware features that can make developing your game so much faster and porting so much easier?

    Although you would then be in the position of a user of middle ware and tied into the stability of their engine.

    Arowx

  7. I’ve been using C++ for about 17 years and C# for about 10 years. With C++, I’ve found that I sometimes will use newer features and sometimes I will do without them.

    I’ve never used FILE, but always filestreams instead. They aren’t the friendliest things to use, but I’m used to them. I’ve never bothered to use for_each() in C++, always using for loops instead. It seems to me that it was always a bit clunky to use and didn’t save much time, so I never bothered to. However, I’ve always used foreach in C# because it’s a well-integrated part of the language and doesn’t feel clunky. I believe, however, that C++ 11 now has a native foreach. I should check that out.

    I prefer using std::string (I even came up with my own std::string-like classes for handling UTF-8 and UTF-16 strings), but I see nothing wrong with using char* if you want to. For me, char* is nice for constants strings, but I prefer the encapsulation that std::string brings.

    I find that C++ has a lot of weird behaviors and rules to remember. After 17 years of using it, I don’t think I could truly say that I’ve mastered it. I only regularly use a subset of it. The STL can be both helpful and daunting. There are some parts of it I use regularly and some parts I ignore because I don’t have a good idea of what I can do with it. It can get really complex sometimes, and can be not fun to use. I typically use things like data containers (map, vector, list) and tend not to use the STL algorithms. Templates are nice, but the errors they generate when you did something wrong are horrific to read.

    I quite like the Boost libraries, using shared_ptr and the threading libraries a lot. Boost also has some good function pointer related stuff dynamically bind functions. shared_ptr is great, and provides a more C#/Java-like way of dealing with objects, although with reference counting instead of garbage collection. It’s nice to not have to worry about making sure that an object is deleted in the right place or having it deleted too many times or not at all. I can throw that pointer all around the place, letting the shared_ptr clean up the object for me when the last shared_ptr goes out of scope.

    I do prefer C# over C++, as it is way nicer to use. However, C++ is where it’s at when it comes to cross-platform portability.

    Some of the new C++ 11 features look interesting to me, especially the lambda and threading functionality that’s now built into the language. Not all compilers fully support C++ 11 yet though. Visual Studio 2012 still only has partial support, implementing some features but not others.

    I’ve messed around with DirectX in the past, making a few very simple games. If I was to embark on anything significant though, I’d want to use a library like OGRE that takes care of all the details for me. I understand the need for control and understanding what all the code is doing, but there are some things I would prefer to not worry about. I guess I could look into the OGRE code to see what it’s doing, but as long as it does what I want it to, I have no desire to. I have better stuff to do than a bunch of lower-level graphics code. Unity is great in that it takes care of a lot of stuff for you. However, Unity is a bit too encapsulated and doesn’t offer enough flexibility and extensibility for me. For example, it doesn’t appear to me that there is any way in Unity to create tasks in different threads that run your own code in the background.

  8. @Kevin Peter, The Unity engine is not thread safe but you can use C# System. Threading to launch your own threads and process tasks in the background.

  10. The older I get, the more I start to loathe, fear and avoid C++.
    Just read Scott Meyers More Effective C++ and More Effective STL books:
    there are just too many ways in which you can get yourself into trouble with C++.

    That is why I now choose char* over std::string, as C will do nicely.
    And with C you are less encouraged to go OO, which I’ve learned to be wary of.

    I try to use less OO, less state, more functional and more data oriented approaches.
    It’s the only way to keep a complex program robust I think.
    The old fashion way is the winning approach for me.

  11. I sometimes remind programmers who’ve worked for me with that making games is not a ‘programming competition’.

    I’ve seen lots of beautifully engineered code which ultimately runs games which are sh*t.
    Some of the best games I’ve been involved in have had the worst codebases (by any measure of software engineering standards).

  12. Like most of the commenters here I’m using C/C++ for my projects. It’s still a very important language in game dev.

    Nevertheless I’m getting fed up with these horrible compile times and picky type system. C/C++ is the language of choice for engines and libs but high level code is better written in other (script) languages. This way productivity, portability and security get a tremendous boost.

    @cliffski Using C over STL stuff may be faster but also very dangerous. Not using RAII sounds frightening. You’re not using exceptions, are you? At least STL and http://www.boost.org should be used by serious C++ programmers. It makes so many things easier, more maintainable and more secure. IMO that’s more important than a few percent more speed, especially for engines you’ll use for years.

    P.S.: I’m curious how to prove that a decent game engine is BUG FREE?

  13. …and you’re one of the few, succesful indies – it must mean something!
    @Bram: I agree sooo much… I’m falling in love with Standard ML!

  14. I’ve been a full time indie for the last 6 years. My engine was Dx8 like yours, and it took me a considerable effort to port it to iOS (iPad/iPhone). It took me far less time to port it to Mac and almost no time at all (few hours) to port it to the future BB10 platform from BlackBerry. You should completely separate your main c++ code from your engine even if it means having an intermediate layer between your engine and Dx or OpenGl. My engine is way simpler than your (as far as pixel shading/ fx crap is concerned), I make the choice to make it easy for multi-platform even if I am loosing a bit of flexibility. At this stage, my engine is a dream to work with. I code 99.99% of the game on PC and it take me minutes to test the game on any other platforms. This is saving me a huge amount of $ on porting and it is making my business sustainable by having many income streams (at almost no cost). Everything else, I am like you: my code is old type C++ (read C with classes). I’m coding extremely quickly, and unlike you ;) I don’t have a lot of bugs in my code (according to you). By running the same code on 4 or 5 different platforms, it can help catching more easily some bugs. The platform specific part is tiny (just few cpp filles per platforms), I am using _CrtSetDbgFlag on the PC to catch memory leak and don’t bother with other platforms as the game code/path is 100% the same on all platforms. I have many other tweaks that I was able to code to make my life easy with different screen/resolution (a big concern on touch screen, less a problem with PC).

  15. I don’t like for_each, it just feels wrong, like it’ll go off and do things in parallel when you don’t want it to or something.

    I’ve used a couple of macros instead, which do a better job for me of making loops easier, quicker and less buggy.

    There’s FORWARD_LOOP(variable, max) which goes from 0 to max-1, and BACKWARD_LOOP(variable, max) which goes from max to 0.

    The definitions are something like (from memory):

    #define FORWARD_LOOP(x,max_x) for(u32 x=0 ; x= 0 ; x–)

    Gets rid of appalling disasters like using an unsigned variable for a backwards loop (it’s never less than 0)

  16. I’ve explored both sides of this at different times by distributing a couple of indie games, and later focusing on tech development. To me it comes down to where my interests are at any particular time. I think for those who are determined to earn a living doing indie games, the game is far more important than the architecture. Capabilities of the architecture are all that matter to meet the game’s requirements.

    Lately I find myself more interested in tech exploration than committing to a whole game, and I end up debating whether it even makes sense to not just switch to Unity. it always comes back to my current desires, which are to learn and explore, and not to ship a product. That will flip eventually but there’s not immediate need for it to be now.

    It certainly does seem like C++ is being groomed for destruction, but it’s not going anywhere in the AAA game space for quite a while. It seems pretty likely that next gen consoles ~might~ end up being the last that use C++ as the primary language but it’s hard to say for sure. Most likely it’ll stick around next-next gen sort of like Assembly did for a while. Some engine components will still use it.

  17. Pingback: Dev Links: Nothing To Hide | The Indie Game Magazine - Indie Game Reviews, Previews, News & Downloads

Comments are currently closed.