Working On Working

I’ve been called a workaholic by other workaholics who don’t consider themselves workaholics which is probably not a good sign. I consider myself a programmer and track my hours spent working and employ various metrics because I like measuring things.

From 2010 to 2015 I averaged about 15.4 hours of work a day (that’s 5,621 hours of work a year). Around September 2015 I “owed” myself over 365 days (over a year!) of weekends – Saturdays and Sundays where I worked the whole day.

I’ve been trying to work a lot less these days. The wake up call was when my father, previously a workaholic, told me I was working too hard. When the hardest working person in your life tells you that you might be taking the thing you know them for to an extreme you tend to take notice.

I took a vacation from September 2015 to January 2016 where I only averaged about 3.8 hours of work a day; I bought a work laptop specifically for the trip so clearly I’m not doing this cold turkey. It was fun. I spent a lot of time with my nephew, who is a little hellion, and ate way too much food. My nephew also kept begging for way too much food.

It’s late January now and I’m still catching up on work my contractors did for my game while I was off playing uncle, but it cleared up some issues I had floating around in my skull.

Task-Based Scheduling

It’s always better to think about work in terms of tasks rather than time. You can’t divorce the time aspect of tasks, but it’s just better to say “I got tiny task X done today” rather than “I worked eight hours today.” For one thing it’s just more meaningful – I doubt your commit logs say, “Worked for eight hours on [System Y].” For another when you’re talking about day to day REAL WORK TM getting done, the time scheduling doesn’t even really matter. No, really.

I mean I knew this years ago. I think most people (apart from managers) understand this intuitively. But my four month vacation also made something a little more clear to me: don’t jump the gun if you have the time.

I don’t mean if you find yourself with a windfall of two hours and you can hammer something out on your todo list to not take advantage of it. I mean just don’t do this consistently. I’m not talking about burnout which is a separate and very real thing. I’m talking about clarity of purpose and avoiding redundant work.

Maybe this is different for other programmers, but I frequently find myself implementing a system, tying it in with relevant systems, then doing a bunch of filler work to get everything working smoothly. Unnecessary things. Things that may change. This isn’t about pre-mature optimization, this is about not knowing at a given point in time what is actually needed. It’s more like, “Hey, this thing knows about [some value] now. This should tie into the GUI, right? And it needs code-specific handling when interacting with…”

It’s subtle and annoying when you realize you’ve wasted your time, like when you made an entire inventory system before realizing inventory is a real crappy system for your game and you could have figured that out just by hard-coding a healing potion and a sandwich.

This also means your task list really needs to not be things like “Make [Massive System X].” It needs to be broken down into very small, bite-sized tasks you can accomplish in a relatively short amount of time. Personally I think that if you can’t do it in 15-30 minutes you haven’t thought it through or broken it down enough yet.

Aside 1: As the exception that proves the rule, if you’ve done something frequently enough and you know for sure you can slam it out really fast without thinking too much, you can put giant-looking items on your todo list. For example coding up a simple grid-based level generator for a roguelike game is pretty straightforward for me these days. I don’t need to break that down into room/corridor/placement/digger/whatever components anymore on paper or in my head. A benefit of experience you can apply to the things you know a lot about.

Aside 2: If you’re coding a bunch of systems that you don’t really like but are too attached to to throw away, this is also a Very Bad Thing TM.

Maybe I’m just really concrete sequential and this all sounds ghastly to you. Sure, and I guess it depends a bunch on what kind of game (or non-software project) you’re trying to make as well. I don’t work well in chaos, but maybe you do.


Vacation What?

Right. So my four month vacation had me using a laptop which, though quite nice for development, was not up to my main dev machine standards. So this limited what things I could work on. I ended up spending a lot of time cleaning up old code and scripting for side mechanics because even my old Mac Classic let me type text reliably.

But four hours feels a lot less than sixteen hours a day, and when January rolled around I felt like I had a lot of catching up to do. Turns out not that much catching up to do.

It’s not that I got so much done, it’s just that working in a lower capacity actually made me focus on what things mattered and what didn’t. You know how if you have a set budget you start buying random crap? Well it’s kind of like that except you’re budgeting with time. Hey, I’ve got sixteen hours of work to do today; Let’s do a buncha crap.

I consider myself fairly disciplined, particularly regarding issues of prioritization, but apparently I’m not. A review of my current project since inception revealed that I wasn’t actually doing much better at doing real work that stuck around. I had previously reviewed my last game and discovered that I spent [EMBARRASSINGLY REDACTED] percentage of my time on systems that just never made it into the final game.

Turns out the percentage from my last game had aligned almost exactly with the development of my current game. Awkward. But the work I had done recently while on vacation? All in the game, at least currently.

I know, more current work is more likely to still be in the game. Obvious, right? Except I went back to a one week period I took a working vacation on my first game and reviewed what I had done during that period. Turns out all of that stuff, written about nine months before the game fully released, made it into the final game.

Well shit. That seems like a pattern.


I Hate People Who Waste My Time And I Really Hate Myself Right Now

Without exact numbers on how much work makes it through to final release it’s hard to determine how much to restrict your own work time. I mean yeah, maybe if I work 25% fewer hours 100% of that work gets through, but how does that work exactly? If four hours a day means 100% (haha yeah right but argument’s sake okay) of work is effective, does eight hours mean the first four hours is 100% and the last four is like 50% or what?

It’s probably some weird graph curve but that’s actually not that important. It’s not important because I know three things:

  1. I can’t get the bare minimum I need done for my game if I only work four hours a day (28 hour work week). Not if I want to release in a reasonable time frame.
  2. I prefer to finish sooner rather than later.
  3. Any amount of work between 4 and 16 hours a day is better than 4 or 16, assuming I estimated the time of tasks reasonably accurately.

I think this means that I should be trying to schedule tasks per day that I think will take me four (or a little more) hours a day, every day for the length of the project, and more or less stick to it. Inevitably some work will expand into available time, because I suck at estimating and because some things crop up that you didn’t plan for, and if not that leaves me time to expand on non-bare minimum tasks.

It’s a weird way to approach a creative project, perhaps, but I also have the benefit of making turn-based tactics games, and so spending more time on the core stuff has a lot more value than if I was making a game that really depended on loads of new content (e.g. a fully-fledged RPG.)



  • Populate your todo list with the bare minimum, core things your game needs to be the game you want it to be.
  • Make a schedule of the tasks you need to get done every day until release (and maybe post-release!)
  • Stick to it and use extra time to work on extraneous stuff.

P.S. I’m down to about 60 hours a week on average for Steam Marines 2. Progress.


Thanks for reading,
Mister Bums

You can contact me at [email protected]Twitter, or leave a comment below.

Game Development Videos to Watch

Obsessive-Compulsive Development: Retro/Grade Postmortem

GDC Vault video link (~33 minutes).

Matt Gilgenbach discusses what went wrong with the development of Retro/Grade and (perhaps) common pitfalls between developers and their labors of love.


Guy Kawasaki: The Top 10 Mistakes of Entrepreneurs

YouTube talk at UC Berkeley (~84 minutes).

Guy Kawasaki is probably best known as former chief evangelist of Apple. He refers mostly to software startups/entrepreneurs in venture capital stages, but many of his points and lessons are relevant to game development, especially with the rise of crowdfunding.


Brenda Romero: Jiro Dreams of Game Design

GDC Vault video link (~57 minutes.)

Brenda Romero, known for her work on the Wizardry series, talks about making great games. She speaks on deliberate and comprehensive design, draws connections between the culinary arts and games, and failure.


Juice it or lose it – a talk by Martin Jonasson & Petri Purho

YouTube talk with demo game and code links (~15 minutes).

Martin Jonasson and Petri Purho of Jesus vs. Dinosaurs fame talk about bringing your game’s attention-holding capabilities to the next level. Filled with salient demonstration and a real-time generated audience laugh track.

7 Day Roguelike (2014)

Jam, Jam, Jam

7drl is my first game jam, possibly being paired with Procedural Death Jam. I had an itchy feeling to make a Judge Dredd type of game (in terms of mechanics, probably not atmosphere or environment.) It will probably be called Crime Central (I can change it later if I want to!)

Due to some real life time restrictions I won’t get the full 7 days worth, but that’s okay; I can always think about it when doing some other, non-game related stuff. My main objective is actually to sit down and railroad a full game so I can get the full taste of Unity 3D for future projects. To that end this is a rough schedule I’ve got for myself:


Day #1 – Plan and design (~9 hours)

Determine main mechanics and aesthetic. Create some music so I can loop it over the next week and determine whether it’s annoying or not!

Get going on the core gameplay. Generate levels, spawn the player and enemies and obstacles, and get some basic interaction going. Write this blog post.


Day 2 # – Flesh out (~6 hours)

I probably made a bunch of mistakes in Day One. I will wake up feeling irritated and make a lot of coffee. Make a main menu. Make a death screen. Make a victory screen. Maybe make a boss. Save state?

Game options or alternate control schemes? This is supposed to be a full game, not just a tech demo!


Day #3 – Tweak and polish (~6 hours)

The game balance is probably non-extant at this point. Start to fiddle with resources, turn management, enemy spawn count and positions, et cetera. Is the game fun? Is it challenging? Is anyone going to play this pile of crap?

Think about open sourcing the code while eating candy.


Day #4 – Oh crap! (~3 hours)

This is the authorized time to panic. Last day to work on this so squash any remaining showstoppers, run through the game a few more times to make sure nothing obvious was missed, and build for Win/Mac/Lin.

Let the roguelike community eat my face. Maybe I’ll get lucky and find myself with more days/time toward the end. But 24 hours should be enough to slap something playable together, for sure!

Aside: Those are some famous-ass last words.

I’ll be updating this blog post as I progress. Interestingly if I succeed then Crime Central will be the first roguelike I finish, not Steam Marines.


Thanks for reading,
Mister Bums

You can contact me at [email protected]Twitter, or leave a comment below!




8 March 2014, 12:41 a.m. EST
Finished the main music loop for actual gameplay. Still need main menu music. May wait to do that later.

8 March 2014, 1:10 a.m. EST
Finished a basic level generator with placeholder graphics. Pretty easy to knock out if you’ve made more complicated level generators before. The real meat is ahead!

7drl 2014 - Day 1, Level Generator
7drl 2014 – Day 1, Level Generator

8 March 2014, 1:55 a.m. EST
HUD elements! I hate (G)UI so I figure throw some elements and slave everything to them rather than the other way around. Keeps feature creep in check, too.

Added basic enemies. Don’t let them catch you, or they’ll.. keep catching you? Added an event log (only one line – the last action taken.)

7drl 2014 - Day 1, Basic HUD
7drl 2014 – Day 1, Basic HUD
7drl 2014 - Day 1, Enemies
7drl 2014 – Day 1, Enemies

8 March 2014, 2:12 a.m. EST
Surprisingly easy to setup a basic minimap in Unity. Less than 100 lines of code, and only that many because of the weird nature of the player/enemy art. On the other hand it seems non-rectangular minimaps are a bit of a pita.

I felt a minimap in this kind of turn-based, first-person game is fairly necessary. As a lesson from Steam Marines players really want to know what’s around them. I actually had facing/turning cost an action point and people really didn’t like that. I eventually caved and added an option to make it cost 0 AP. This is my attempt to head off that issue.

Aside: I believe Eben, in Roguelike Radio Episode #68, referred to spinning in a circle to see around you as “lighthousing.” I think it’s a fairly accurate term.

Unhappy with the message log on the lower left. Not sure what to do about it, though. Not even sure what exactly I don’t like!

7drl 2014 - Day 1, Minimap
7drl 2014 – Day 1, Minimap

8 March 2014, 2:23 a.m. EST
Added a RogueTemple post to be updated with progress and build links once available!

8 March 2014, 2:31 a.m. EST
Enemies can now melee the player. Built an action point system for each enemy and the player. Current action point pools act as speed, meaning more AP = act before lower AP units.

Added death screen with fading to black, music fade out, and screen shake. Everyone loves screen shake. Screen shake was probably the hardest part. It’s also not very good xD

7drl 2014 - Day 1, Death Screen
7drl 2014 – Day 1, Death Screen

8 March 2014, 2:38 a.m. EST
Cross-posted to Reddit’s Screenshot Saturday!

8 March 2014, 3:24 a.m. EST
I’ve been practicing pixel art for about an hour a week for the last few weeks. It doesn’t show xD Still, this is the Enforcer. He’ll punch you in the face when he looks like the left side. He’s ready to be arrested when he looks like the right side. He is NOT crying. Really.

I will do better on my next enemy…

7drl 2014 - Day 1, Enforcer
7drl 2014 – Day 1, Enforcer

8 March 2014, 3:58 a.m. EST
No sexy screens this time. Fleshed out basic movements, attacks, and resource mechanics. Looking into combinations and chaining.

Put together a main menu. It’s two text buttons – not sexy.

8 March 2014, 6:53 a.m. EST
Implemented those resource use combinations I mentioned earlier along with some action chaining. Gameplay actually requires some thought now – huzzah!

Gang Member. Rude. Violent. Stabby stabby.

7drl 2014 - Day 1, Gang Member
7drl 2014 – Day 1, Gang Member

8 March 2014, 8:32 a.m. EST
Almost winding down Day 1 and Crime Central is almost playable. Well, you can play it, but it has no ending and no goal aside from “don’t die.” Three resources tied into combinations to use/regain each other, action chains for special abilities, three enemy types in increasing difficulty, and some placeholder tiles shamelessly ripped from Steam Marines. Will work on changing those tomorrow xD

Enemies are 2D and rotate to face the player and flip around when killed. Current status:

7drl 2014 - Day 1, Mostly Playable
7drl 2014 – Day 1, Mostly Playable
7drl 2014 - Day 1, Current State
7drl 2014 – Day 1, Current State

9 March 2014, 1:27 a.m. EST
After struggling with this for about an hour I don’t know wtf I wanted xD Was supposed to be a Techno Witch end game boss. Will probably make the surrender/arrest version later and stick it in after fiddling with it more.

But for now I’m going to cut my losses and go back to code!

7drl 2014 - Day 2, Techno  Witch
7drl 2014 – Day 2, Techno Witch

9 March 2014, 3:42 a.m. EST
Squashed a bunch of bugs. Tightened up the joystick axis controls; itfelt very sloppy when trying to execute commands quickly. In terms of making it a “completed” game I pretty much just need to implement the end goal and have a victory screen – huzzah!

I also have a design problem where it’s best just to dash for the elevator on each level. Need a sub-goal so the player may wish to explore/clear each level. Score is a possibility, but I’d like to avoid that if possible. It can be a lazy solution.

9 March 2014, 5:51 a.m. EST
Got quagmired in making the main menu fancy. I am an idiot.

9 March 2014, 6:48 a.m. EST
Some Win/Mac/Lin/Web builds!

Win x86 build.

Mac x86 build.

Lin x86 build.

Webplayer build (Note: This version is awful xD)

11 March 2014, 12:11 a.m. EST
More time to work on this! Going to finish that Techno Witch and add her as a boss – maybe with ranged attack or aoe?!? Implement an ending – and a secret ending? Also I want to add another chain combo.

11 March 2014, 2:20 a.m. EST
Implemented the Techno Witch as the end boss. Opted to keep her melee but give her power up abilities. The level generation also changes on the last level where she spawns.

11 March 2014, 3:28 a.m. EST
Added end game status and victory counter to the main menu. Added shotgun upgrade option after the player dies ten or more times. Game is essentially a complete (beginning/middle/end) product! Huzzah!

11 March 2014, 6:48 a.m. EST
I think I’m done? Polished some assets and UI. Added some sound effects for interaction confirmation. Pushing final builds soon.

11 March 2014, 7:30 a.m. EST
Some (final) Win/Mac/Lin/Web builds!

Win x86 build.

Mac x86 build.

Lin x86 build.

Webplayer build.

Unity 4.3.4 project with license file (Fairly certain I used no Pro-only features.)


That’s all for now! ^_^



Thinking About Code

(Note: This blog post is mostly for fun. I don’t really intend on drawing any grand, sweeping insight into good or bad code. This is just me tired of squashing bugs and wanting to dig around in what I’ve created. I also promise not to talk about Big O.)


By the numbers

Let’s start with some Steam Marines v0.8.6a script source numbers!

162 script files
1747 script functions
43532 lines of game logic code (non-GUI, non-engine)
8415 lines of comments
4385 blank lines
3488 if statements
638 else statements
456 else if statements
305 switch statements
28 while statements
15 do-while statements

This turns out to be 9860 lines of code with only a single bracket, either { or }, on them. This means that the number of non-GUI game logic not including comments, blank lines, or trivial single bracket lines, is 20,872 lines of physical code. Of those nearly 21k lines 4,930 are control statements, or about 23.6%.

I don’t really know what these numbers imply, nor am I aware of anyone who has done analysis of “good” and “poor” code and gathered relevant statistics (although there probably have been.) But it’s interesting to note that almost a quarter of the relevant lines of code are about flow control. We are here and we want to go there.

This suggests a few more metrics to look into, namely how many functions need to be called and how many source files need to be touched to perform actions or respond to user input.



I was taught to write re-usable code. Make it abstract, make that list of things be able to hold all the things! I’ve mostly abdicated this approach for coding games, at least from an object oriented perspective. But I do love functional programming, and that intrinsically allows for more re-usability. So maybe I haven’t abdicated so much as melded the concept in my brain.

It’d be pretty cool if every action was a single function that contained some straight-line code; no branching, no other function calls, just bam bam bam and we’re done. It’d be pretty easy to debug, too. But probably a nightmare to write with lots of duplicate code.

If we think of the number of functions touched to complete a task being a metric of complexity, functional code is a big help. Sure even functional code adds complexity, but it doesn’t change state which is the biggest help. We know that by themselves functional code didn’t screw something up, although some other code might have taken what they returns and mucked about with it.

Steam Marines is written with Torque 2D, but for the purposes of this post let’s ignore the engine guts and talk about script code execution only. What happens when the player presses the key to move in the left direction? Well, it enters a function conveniently called left in the input.cs file.

It essentially looks like this (minor details left out, but all files touched are included):

left – input.cs
—> globalInputLocked – input.cs
—> clearFireControl – fireControls.cs
—> —> clearTargetIndicators – fireControls.cs
—> engageCharacterActionLock – characterMovement.cs
—> canMoveToMapPosition – characterMovement.cs
—> getTilePositionFromIndices – dungeonGenerator.cs
—> moveUnit – unitMovementHandler.cs
—> —> growAndShrinkUnit – unitMovementHandler.cs
—> setSquadMemberFacing – facingHandler.cs
—> mountSightToUnit – weaponModHandler.cs
—> initializeReadout – readoutHandler.cs

Yowza! That’s a dozen (12) function calls to move a unit in one direction! It also touched eight (8) physical files. Like I said above I don’t know if there’s a good way to measure this stuff, but to me that feels like a lot of files to jump through just to see if basic unit movement is working.

To me the code structure works well this way, though.Code is split into small functions, each with a very specific job, and they are categorized into physical files based on functionality.


Doom 3 GPL Source

Counting just .cpp files in Doom 3‘s GPL’d source code shows that it has:

531 cpp (C++) files
377566 lines of code
115818 lines of comments
89582 blank lines
38829 if statements
5517 else statements
5767 else if statements
693 switch statements
1161 while statements
123 do-while statements

That’s 172,166 lines of physical code with 52,090 control statements, or about 30.3%.

I want to point out that I am in no way suggesting this is an accurate comparison, or that the code quality between Doom 3 and Steam Marines is similar. It’s not a full source comparison; I rather arbitrarily chose to ignore my GUI code, the Torque 2D engine code, and that Doom 3 and Steam Marines are remarkably different games. I also stripped single bracket lines out of my own numbers. Really the only thing going for this comparison is that it was only between .cpp and .cs files since I excluded .c and .h files from Doom 3. It speaks to code structure more than anything else.

But it’s still interesting to look at, eh? Maybe it suggests Steam Marines is way too complicated for it’s own good! To be completely honest I assumed Doom 3‘s OOP structure would have indicated relatively less flow control statements. So maybe this is a metric of nothing!


Now what?

I dunno. Wanna tell me your source stats?

Aside: I’ve churned out approximately 31 lines of physical code a day (that remains in the current dev build) for Steam Marines since starting on it – not including GUI or engine code.

I didn’t include GUI code because there’s not a lot of explicit flow control in that kind of code. Full script (not engine) numbers if you’re curious:

Steam Marines cloc
Steam Marines cloc


Thanks for reading,
Mister Bums

You can contact me at [email protected]Twitter, or leave a comment below!

Use Revision Control

This doesn’t seem like very controversial topic!

The number of arguments I’ve gotten into recently suggest otherwise! Regardless, even if you are a seasoned programmer and understand the value of using revision control I’ve run into a lot of indie devs who don’t quite understand why the extra effort has value.

So this is a blog post about value – specifically long term value.


What are the naysayers nay… saying?

It’s not just for code! It can all go into a repository. You may not be able to have the granularity of control and comparison over some binaries as you do over “plain text” files like source code, but that doesn’t mean it doesn’t add value!

The main arguments against revision control seem to be:

  • I’m the only person working on the project – it’s not a big deal!
  • I can remember my project’s entire history in my head – no biggie!
  • I have DropBox!
  • It’s just extra work for no gain!

Wrong, wrong, wrong, and holy hell no.

It does not matter if you are the only person working on a project. Future you is not current you, and future you is going to stumble across something current you left behind because 1) You made a mistake, 2) You forgot something, 3) You made a decision that made sense at the time but was made obsolete or invalid.

You cannot remember your project’s entire history in your head. I’ll bet you can’t even tell me what those four bullet points were. Go ahead – I’ll wait. Don’t cheat. You cheated, didn’t you?

DropBox is not revision control. It is sharing/backup software. It’s good for what it is. There is limited utility for getting old copies of files, but it cannot handle all the other basic functions of revision software, e.g. branching, merging, tagging, conflict handling, et cetera.

It is definitely extra work. The value is that you can access all those historical actions. You can pull up different versions of your work, branch to prototype on stuff, label builds, and generally be more organized with your work flow.


Future You Wants to Talk

You could make manual backups – that’s a large part of what revision control automates for you, though. Have you ever wanted to:

  • Revert files to older versions?
  • Had to maintain multiple versions of files?
  • Compare changes in different versions of files?
  • Compare performance or other metrics in different versions?
  • Had multiple people working on the same files?
  • Work on something that might muck up existing files?
  • Have a history of what you did and why you did it?
  • Had incremental backup that doesn’t require constantly copying everything manually?

Then you might want to take a closer look at revision control. Broke something? Look at the commit history. Chopped off that ugly block of code that you thought you’d never need again? It’s okay – you can still find it. Refactored a bunch of stuff and broke all the things? You can completely revert as an absolute failsafe.


I draw stuff! I use a typewriter!

You don’t use a typewriter, you liar. But okay, a lot of that seems to be for programmers and for code – plain text files! What about artists? What about crazy file formats?

Revision Control - Graphics

Handy, no? And you can compare every single graphic version with every other. You can see how stuff changed or revert to an older version. You can even set other external programs like Photoshop to diff for you.

But I don’t want to mislead you. Current revision control really shines for “plain text” files. For example if you compare versions of a file in Rich Text Format, you’ll get something that looks like this:

Revision Control - RTF

That’s because by default Subversion (the revision control software paired with TortoiseSVN I’m using in these screenshots) simply treats .rtf files as plain text. You can set file extensions or mime types to use designated programs (such as MS Word) or pre-existing scripts (like diff-doc.js in the case of .rtf files) to diff them properly.

If you’re silly like me and still use Open Office you might diff your .rtf files this way:



Very handy.

Very. Another popular flavor of revision software is Git. You can manipulate files in similar fashion as Subversion, it’s just called Attributes instead of Properties. A Google search will get you more information than you can shake a stick at.

Unfortunately I’ve never had to try to diff other file types like .wav, .mp4, or .ogg; audio/video stuff. I’m also not too familiar with audio tool chains and needs – maybe someone who is can enlighten me!

The point I hope you take away is that revision software is valuable not just for incremental backup and workflow, but also if you’re not a programmer.


Thanks for reading,                                                                                                                   Mister Bums

You can reach me via email or Twitter.