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

You wouldn’t start from here

cliffski

So many programming, and technical things are bodged, not just in games or software, but everywhere, because the ideal best-case academic method is totally useless given that we are always working from an imperfect base.

The railway network, telephone infrastructure, road network, sewers and god-knows-what-else here in England are all rubbish. Why? Because we got these things very early in history due to being economically and technologically quite advanced, esp during victorian times. As a result, as pioneers, we have what I guess is ‘first-mover disadvantage’. Our countries infrastructure is like excite vs today’s google :D

I definitely find this problem in my own code, my own methods of working etc. I have an engine, it doesn’t really have a name, the folder is called ‘Positech Engine’. I save my imagination for the actual game… The engine isn’t like the unreal engine or other fully-featured thing, but it has all my library code which handles stuff like directinput, rendering, vertex buffer and texture management, file loading and so on. Bizzarely, 90% of the my UI code is NOT in the library, I copy it to each new game. How sucky.

Not only that, but I have a bunch of long standing balls-ups that I am now stuck with, pending a major rewrite for the next game. I should have done them for this one, really… Here are the ones that spring to mind.

STRINGS: I can’t decide if I like char* buffers or std::string. I pretty much use std::string, but because historically I know functions like sprintf and strcpy really well, I still use them in places. As a result some of my library stuff is designed to accept either std::string or char* as input. I can type ‘.c_str()’ so fast now it’s scary

UNICODE: I don’t use unicode. This means a Japanese GSB is not going to happen any time soon. I should probably use unicode, but I don’t

TOOLTIPS: I know this seems minor, but my tooltip class isn’t integrated with my window class. This means if I create a new window, and it needs a tooltip, I need to add a tooltip object, and call a destructor, and make it respond to the mouse and get drawn. This sucks. I should have defaulted to all windows having tooltip functionality

BUTTONS: Buttons should be a subset of windows, but mine aren’t. Both windows and buttons at least derive from the same class, but a window thus now derives from a buttonlist. That means a window has a list of buttons, and a list of child windows, and they are handled seperately. THIS SUCKS.

I know this all sounds crap, and if you are a coder writing a new engine, or a student, it sounds like I’m a n00b, but the thing is, you wouldn’t start from here. Unfortunately I have, and re-using my existing engine saves me hundreds if not thousands of hours for each game, so it’s tough to make a business case for changing a lot of this. Both big studios I worked on had code that was at least as messy as this, so I know it’s not just me…

Next game I’ll fix it all, sure…   maybe…

5 thoughts on You wouldn’t start from here

  1. Unclebob (www.cleancoders.com) said that “Code Gets Old. It needs to be periodically massaged an re-arranged, otherwise it gets so old it’s just tempting to throw it away and start over”.

    The problem is making sure that the “massage and re-arranging” doesn’t break anything (answer: automated tests). I’m not so sure about gaming and UI stuff though. The amount of code required for automated tests would be high.

  2. It certainly isn’t just you, you describe current rolling codebase quite well.

    At the low level, I’ve used Unicode since day 1, which has served me well since I find publishers are increasingly interested in Japanese, Chinese and Korean.

    But I tend to do higher level UI code wrong every project! It’s something I just can’t seem to turn into a re-usable set of tools and modules.

  3. When we switched from our custom .NET/SlimDX engine (which was a lovely development and runtime environment but deploying .NET apps to a general audience sucks really, really bad; etc) to Unity3D one of the nice things is that we had a chance to revisit a lot of code. The GUI was pretty much a complete reinvention, and it’s served us pretty well going forward.

    The switch had all kinds of other problems, of course, but we’re past those now :)

    On std::string/char*, I’m assuming that both are mutable? In .NET string is immutable, which is great for most uses but in concat-heavy cases can cause massive transient memory alloc (and thus GCs) and CPU spikes. We’ve been using char[]-based approaches for a while now.

  4. I remade an in-game mission editor from the bottom up and I feel you. At least then I was starting fresh and could lay the UI code out properly. The end result was fantastic to work with, but it took me so much longer than I initially thought (first job out of college, right?) that it probably cost me that job in the end.

    I find that since coding is such an intellectual pursuit that I am constantly learning and figuring out things as I go. As a result I often look back at older code I’ve written and realize that I would’ve done it differently today. The constant struggle is in determining first whether the new way is actually better or just different (feels better) and second whether it’s worth the time for the rewrite.

    I think until people get real experience under their belt they don’t realize that “It’s not a bug, it’s a feature” and “ship it” aren’t dirty phrases, but necessary to getting a product out on the market.

  5. I agree with the above that automated testing is really critical for rapid code improvements, debugging, and refactoring.

    I think trying to get it all right the first time is why I always fail. At work when I do a small patch every day, other people contribute or spot problems and things progress fairly rapidly. But when I sit on a many-many line patch polishing it for three weeks, it’s just a bomb and nobody touches it, and if stuff is wrong it’s a real bear to deal with it.

    We have modules where we’ve actually coded up two or three different versions all derived from the same base. The newer versions are sometimes just plain better, but they older ones are so integrated it’s no small feat (and the people who originally wrote them aren’t even around anymore..). But you still want, need, and can have improvement if you use module v3 instead. Slowly as development focus shifts from version to version older features get revisited and that’s a prime opportunity to decouple v1 and use v3 instead.

    Obviously if you’re doing big changes to your base interfaces its not always that easy, and it might even break everything…

    Sounds like a LOT of people are having very bad experiences with UI, and that’s something I’ve never really done. What are some examples of good and bad ways to do things?

Comments are currently closed.