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

The programmer constraint

Positech Games suffers from the programmer constraint. Everything that gets made directly by positech goes through the funnel of coding by me, and it’s becoming difficult to keep that up. GSB 2 is a BIG BIG game. It introduces a lot of new features to the game, and it has a much much more complex engine (a multi-threaded one). It will also have higher production values, more music and art and so on, than it’s predecessor. This is fine, as I have the budget to match my ambitions, and no real time constraint (although I’ll have to have a ‘playable’ version for Eurogamer in London, this September. The only thing that holds the game back now is me.

I’m the only programmer, and that is a pain. GSB2 uses my own custom engine, and no middle ware other than a sound library. There is a LOT of code, and although I do none of the art, the constraint of me being totally the only coder slows down the games production, and possibly limits its scope. I can see various mitigation strategies.

Mitigation Strategy #1

Delay the game. Just deal with the fact that it will take another year, and keep plugging away. This is the easiest option, although one I don’t like. I dislike 2 or 3 year projects. I already have plans to show the game in September, I can’t wait years to release after that. Plus the memory (and player-base) of GSB will degrade more the longer I leave it. Plus also I won’t earn any money until I start selling it!

Mitigation Strategy #2

Scale down the ambition. The engine runs very fast already, it really does not need to be optimized that much more. The GUI can be functional but not flashy.  I really don’t need to go bananas with features like steam leaderboards or online messaging etc. That’s stuff I can leave out of the game. I dislike this strategy too. This is a sequel, it should be the better interpretation of the idea, with better everything, and all cool features intact. I’d be disappointed otherwise.

Mitigation Strategy #3

Hire a coder. This would be ideal but vastly problematic. Experience with Unity or Unreal or the Source engine will not help you with my engine. it’s all my work, and never written to be understood by anyone else. Plus how can I be sure their work is good without checking it and testing it, which might take more time than me just doing it? I  am not good at code collaboration, so this might keep me awake at night. What if they code some bugs I then have to fix? Nightmare… Plus I’d be VERY picky. How will I find a very experienced (no time to teach) coder that is available, reliable, affordable and motivated enough to work alongside me between now and the project end. This is unlikely.

Mitigation strategy #4/

Offload everything else. I already have taken steps towards this. My Linux & Mac ports are done by other people, some of the PR stuff is outsourced, as is making trailers. All the art and music is outsourced, should I hire a sound designer to pick sounds too? what else takes time? QA? Should I hire some QA company to do playthroughs? Could I maybe hire a designer to do some balancing? A writer to do some writing? Even though i am never really happy with it (because its’ hard to edit) should I take the plunge again and get the website designed and implemented entirely without me?

This is my favorite strategy. I can probably do a bit more of this, offloading all ‘non-core’ code stuff, and literally everything else. it does mean a pure-code lfie for me, which can be a bit maddening at times. I still have the biz strategy and advertising task in my court though :D

17 thoughts on The programmer constraint

  1. #3.1 Why not hire another coder, but have them do the small bits, bug fixes, small features, testing ect. Leaving you to work on the bigger features and issues.

  2. Hi Cliff,

    Posting it here because I cannot find your e-mail address.

    I am an experienced, reliable, affordable and available C/C++ developer from Latvia (2 hour time difference with UK). I also have experience in working and communicating with small distributed teams.
    However, I don’t have any real-world experience in game development, though I’m good at math and have a general understanding of modern graphics programming (played a bit with both OpenGL and DirectX some time ago). I suppose that could be a problem when starting a new project from zero, but since you already have a big codebase, it shouldn’t matter that much – I’m good at understanding others code.

    I’d be happy to talk if you are interested. I left my e-mail in “Mail” field of comment.

  3. …and I could give you a quote for the writing, if you have some idea of the spec.
    (former Edge writer, written for four games, two for Nintendo; Directed voice-recording sessions).

    As I’m also a coder I can make it easy to get the end result into an engine-usable form (eg. C arrays of text, processed audio files with sensible filenames to match) rather than just dumping an unsorted mass of babble on you.

  4. You might be surprised how helpful having someone else can be. Having someone else test review all of your work will generally dramatically improve the quality of code in a project. Higher quality code means less bugs, and more time spent on features. It’s worth considering at least, but of course you do need to find someone competent, which I don’t know how to do.

  5. I like the idea of you doing things more programmer time efficient. I think once you get the App market sorted out this could be a really good thing for you. It relies on your efficiency of code, and also opens up a possible place to advertise. Maybe incorporate more ‘thoroughly reviewed’ 3rd party libraries. This would also help with others understanding your code. For instance C# has a number of them. Maybe you should start moving over. Have you looked into Xamarin?

  6. Along the lines of what Arowx said, another coder could work on tooling. By that I mean working on tools to make bringing assets into the game easier, tools for building/deployment of your code, and tools for developing/designing in-games things that you’re currently performing with with hand written code.

    You’re certainly right that finding a competent developer that you’re able to work well with remotely is going to be a challenge.

  7. I feel you’re overestimating the trouble involved with #3 a bit.

    1. The urge to review the other person’s code is not at all bad. I think it’s vital even. And not at all condescending: You know the code base very well and the other person not at all. By reviewing all changes, you can make sure that you still understand the whole code base (consistent code style, naming etc.) and catch lots of issues before they can be introduced. And as a bonus, the new person will learn a whole lot from this, without you having to explicitly teach. Reviews are common practice in many dev teams, if not that much in the game industry. We review every single code change in my team.

    2. Finding someone good will definitely take some time. But I’ve done quite a bit of hiring, and I’ve always found that it already pays off after a few weeks, sometimes in the first week. You want to hire when you need more hands, so you need to sacrifice some of your time now to save more of it later. That’s frankly the situation most people find themselves in when hiring. It does generally pay off soon in my experience.

    You could hire someone on a part time freelance basis at first. The big benefit here is that you can see how it works out and cancel things without any hard feelings (as long as you made that clear upfront). If someone quits their day job for you and it doesn’t work out, that’s way more awkward.

    If you’re looking for part timers with relevant experience, I’d bet there are a bunch of wannabe game devs that’d love to learn from you reading this very blog. (Me for example, let me know if you’d like to see some engine code from me :D). People can absolutely make themselves useful while still learning. The trick is that it has to be someone who can do most of the learning on their own, someone who can dig into a large code base, figure out how things work and make themselves useful. There are many people like that.

    My approach to hiring is to first look through a candidate’s code (something they’re particularly proud of), which takes up to one hour. Then I discuss their code and experience in a call for about an hour. That’s usually enough to figure out if it won’t work out. Most people can be filtered out before the call stage. After that you could hire the most promising candidate and make it clear that you want to see if this works out first, in the next 1-2 months or so. You’ll see if it works out.

    Nonetheless, I’m not saying #3 is the best option for you, I wouldn’t know. But I think you’re overestimating the trouble involved with it. And after following you for a while, I think it could be about time for you to get a helping hand with the code, so you can keep the big picture in mind.

  8. Hire me to do QA! I love bug testing, breaking things, doing repetitive and tedious tasks thoroughly, and writing succinct yet informative reports. Plus I’m pretty cheap. How can you lose? :-)

  9. You would think so, but everything is pretty related, and in any case, they then need to know how all the code it affects works, which takes time to explain.

  10. Which programming language is Democracy written in, by the way? I presume C++ since it uses DirectX, but I’ve heard that other languages like Java can load DX.

  11. You’re basically describing my job here. :D

    I’m a Systems Programmer at Nixxes Software. We make PC and console ports for games like Tomb Raider, Deus Ex: Human Revolution and Thief. I’m always thrown headfirst into foreign and sometimes even hostile codebases. And it’s really not that bad.

    Yes, you’ll be breaking pots left and right while you stumble around trying to make fixes and adding features, but in a project this size, *everybody* is doing that. Somebody will make a fix and the train keeps on rolling.

    I wouldn’t be too concerned about your codebase not being ready for other eyes than your own. None of them are. But they often get a lot better with an extra pair of eyes scrutinizing it.

Comments are currently closed.