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

After 36 years of it…its mostly just typing

cliffski

I guess that a lot of people who read my blog are programmers and a lot of them are younger than me. I’m now 47. I was coding a new feature for Production Line yesterday, (the colored overlay & icons for the zoomed-out view) and it occurred to me to kind of ‘live-blog’ it in my head as I was typing, wondering if it would be of interest to people if I recorded doing that sort of thing in a video. Maybe if you are new to coding, or wondered what the real-world dev process for coding a strategy game was like…it might be interesting.

As I did it, I started to realize it would be VERY hard to follow if I did it. Frankly I can code faster than I can describe what I’m coding. Much faster. In fact I write C++ code faster than I write this blog. Visual studio has Intellisense, and I use Visual Assist (from whole tomato) to make use of their even smarter intellisense, so I’m only typing a few characters of each word anyway. Plus…after coding since age 11…I can pretty much write the iteration of an STL container in a for loop and call member functions whilst drinking tea (or on the phone to someone).

I am often AMAZED at how long it takes some people to make a game. I know that sometimes these people are perfectionists and they put a lot of ‘craft’ into their games, and they agonize more about design features than I do..and often it pays off with those mega indie hits that don’t look technically hard to make, but have such good design or polish that they sell a bazillion copies. I totally understand that, and I admit that I don’t spend *enough* time on my games (although I intend to change that with production line, which deliberately has no schedule or end date.

What I do *not* understand is the time it seems to take people, or the effort they seem to think is involved, when it comes to implementing a particular feature from a technical point of view. This is especially true when those people use ‘managed’ code or a higher level language, or unity or some other middleware. Frankly if an old fashioned dinosaur like me can code a feature from scratch in C++ in a day, then the younger more savvy kids with their middleware should be able to do it in an afternoon, but that never seems to be the case. For a long time, knowing this has driven me nuts, until I eventually have concluded that its just because I’m older, and have a scary amount of experience doing one thing day-in and day out for DECADES.

I literally have been coding longer than most indies have been breathing, and its always been in C++ (Actually I think Asteroid Miner may have been C) , and always directx, and always for windows. I went from DX5 to 7 to 9, but thats it, I’m still on 9, and I know it well.  As a result, when I’m coding, unless its some complex multi-threading stuff…I’m probably not  ‘coding’ as much as I am just typing. I know the code to type, and it flows immediately from what I want to achieve. Its just a matter of hitting some keys on the keyboard.

image1

I think this is a big advantage to not being a magpie when it comes to new software and development environments. I still use Visual Studio. I still use C++/DirectX. I still use perforce, I still use Photoshop and paintshop pro, and AQTime and nvidia nsight. In the last year or two, the only change to my development environment has been that I now also use the Visual Studio Concurrency Profiler, which is excellent. Thats one new piece of development GUI I had to learn in 24 months of work.

As you can imagine, this makes life extremely easy. I also coded my own graphics engine, which means it never changes unless I want it to. I don’t have to ‘work out the bugs introduced by the latest changes’ in the engine, because there aren’t any, and if there are, I did them, and I know what I did. And obviously I have all the source code anyway, and can roll-back whenever I like. Its easy. Never underestimate how much keeping a stable work environment can boost your productivity.

In addition, I also am a bit of a workaholic (which helps), plus I have no kids and only low-maintenance pets (cats). I live somewhere incredibly quiet and am rarely disturbed. My office is dedicated to my work, not shared with anyone, and its quiet, and laid out very comfortably with a comfortable chair, big desk and lovely big monitors, so its a nice place to be. This all definitely helps.

My tip to anyone finding their coding productivity low is to resist that urge to upgrade to the new X, or the new Y, or to make any change to your work environment just because you like new things. Sometimes keeping things the same is the best way to boost your productivity.

19 thoughts on After 36 years of it…its mostly just typing

  1. My problem is that Visual Studio *itself* keeps bloody changing. I used to be able to play VC6 like a musical instrument, then they killed it by moving to the .NET monstrosity that was 2003. It made me switched to Emacs for editing, since it’s basically timeless…but that meant losing Intellisense. Swings and roundabouts.

    2. The newer Visual Studio’s (2012,2013,2015) are better, stable and backward compatible with older projects which helps.

  2. Thanks for writing this, its kind of reassuring. I’m also a C++ dinosaur working on an indie strategy game. I appreciate the benefits of having written pretty much everything myself and sticking with the same development environment but the game is still taking a long time to put together. Maybe I need a nicer office ;-)

  3. 3rd party engines are great as long as you are doing what they want.
    Stray off the happy path though and prepare for a world of pain – especially if there’s a bug in the engine. There’s always a bug in the engine. Good luck getting it fixed!* They’re generally fine for things below a certain level of complexity though.

    I don’t know why people would think that a game engine would be perfect, but they seem to. It’s still software. It’s still written by people. It still has bugs.
    I worry that it’s the same with the cloud.

    (I still use VC as an IDE, and I’m trialling Visual Assist)

    *Does happen though.
    Gamemaker now has audio support beyond just ‘play(loop?)’ and ‘stop’.
    RPGMaker can now (finally) integrate with source-control systems.
    Pot luck though.

    1. Oh, and network-based apps (JIRA, Jenkins, Trac, Bugzilla etc.) are an absolute productivity sink because of the incredible slowness with which they update their pages, and their useless internal-platform-effect interfaces.
      If it takes more than about 150ms to respond to a button click I’m (mentally) gone elsewhere.

      Source control provides a much better model of synchronisation – it does everything fast and locally until I’m ready to commit (and have a cup of tea).

      Our bug tracking handling improved no end when we switched from a web-based dedicated bug system to a simple spreadsheet we checked out from source control when we wanted to update it.

  4. I noticed a marked decrease in my productivity when I moved from XNA / Monogame to Unity, which I’ve only recently began to repair.

    Part of this, I think, was moving from a ‘code-first’ workflow, to an ‘editor-first’. Unity is technically more productive. So much is done for you. But you really need to learn the productive way to use the engine. As a programmer, I probably think much like you – as soon as I imagine a feature, I start to think of the data structures needed to support it, and process it, and I the classes for the appropriate abstractions etc. I noticed this wasn’t a natural way of working inside the ‘editor first’ structure of Unity, and it’s taken me a good while to adjust.

    The second point that I think probably helps your productivity is that you’ve written a long series of 2D and UI heavy games. I’m not saying all your games are the same, or even similar, but the technical underpinnings have a lot in common, and I bet that makes you very productive.

      1. Just out of interest.. what were your motivations for trying out Unity? Was it just to see what “all the fuss” was about?

  5. I’m curious about why you are still on DX9 and if you are planning to upgrade to the newer DX? That sounds like a big gap…

    1. With 2D tech games, you really don’t need to go beyond 9, and if you support windows XP, you need a pipeline that runs on 9 anyway.
      I may change eventually, purely for multithreading support, but there is no pressing need.

  7. Frankly if an old fashioned dinosaur like me can code a feature from scratch in C++ in a day, then the younger more savvy kids with their middleware should be able to do it in an afternoon

    I’m not that much younger, and I’ve been working with middleware (Unity) for many years (and coding in general since I was 11), and I do in fact code many features in just a few hours, less than an hour sometimes. Middleware and managed languages and all that jazz definitely help, but they’re not a substitute for experience – more like a multiplier.

  8. I can tell you why it takes me forever to write a game and why I gave up a million times by now. My problem is called analysis paralysis and I tend to over-do and over-analyze everything. My hobbyist code is crap because I’m always thinking that I make the wrong choices, always. I also get stuck on idiotic problems, for which I imagine complex solutions and I obviously don’t implement said solutions.

    This happened on all my personal projects. I’m a complete failure without a real client to ask for concrete features and expecting me to deliver (and this is my second problem). However, I have absolutely no problem delivering a solution for my real „work”. And yes, the only game I ever finished was a Sokoban clone for a multi-media system back in 2003, it took me almost nothing to implement it. I just needed a deadline and a client to ask me to do that.

    I guess it’s lack of discipline and/or motivation in my case.

    1. There’s a solution for your problem, it’s called Ludum Dare. :)

      You have to finish within 72 hours so there’s no time to over analyze anything. The first day is easy because it’s fun to write something new, when the fun wears out by the second or third day you keep going out of fear. Fear that you won’t finish by the deadline, and all of the time you’ve spent so far will have been wasted.

  9. I have been using the Qt framework for the last 16 years and C++ for even longer. Staying with the same tech stack has definitely helped my productivity. Thankfully Qt and C++ have continued to grow and improve, so I don’t feel stagnant. Also I am more focussed on the what I can achieve than learning the latest bleeding-edge tech (‘resume driven development’).

  10. I’ve got a bit of a different approach to coding. I’m neither quick at programming or particularly learned. I have a very poor memory when it comes to writing code to do stuff I’ve probably done months previous. I’m always hacking into old code and copying bits across and then meticulously fine-tuning it because I’m awfully OCD about doing stuff in the neatest, most-optimised way I can manage.

    I’d love to be able to code fluently but i’m Cliff’s age and I’m actually getting worse at it as I get older. I’ve taken the Unity trial a few times to try and get my head round it and recently had another go after a friend recommended a good intro book that’s reasonably accurate with the current version. I had an fps example up and running within an hour and it wasn’t that tricky.

    I don’t know C# or java so the code-side of using it would be a learning process all over again, but it’s true that a lot of the really tricky and labor-intensive stuff like physics, camera’s and collisions is mostly done for you.

    I do prefer 2d games, however, so it may be a case of it being actually harder to use Unity like that for something I wanted to write, than just a code-orientated development system instead, with a decent framework.

    Unity has a lot going for it but it takes a fair bit of effort before a lot of it starts to make sense. That feeling of being lost when it launches is going to be with most people for a fair while.

  11. Unity is slower because it’s a half baked engine, everything you want to do APPEARS to have multiple ways of doing it, but there’s usually only ONE way that works in Unity.

    All the wrong ways of doing things are either deprecated, bugged, or performance killers.

    But I accept all of these problems in exchange for the Unity editor, which is infinitely better at making a 3d game than any editor I would have written. :) I know because I made my own 2d editor with XNA and it wasn’t good.

Comments are currently closed.