I’m a professional programmer by day and an indie game developer hobbyist by night. As far as the game dev part goes, I’m really bad at finishing what I start, so, while I get a lot of enjoyment out of the process, I don’t really have a whole lot to show for it, other than games like this one I made for a game jam (a challenge to make a complete game in just 48 hours with a topic that isn’t revealed until you start) this past weekend, and if you could go there and vote honestly about it I’d really appreciate it! I thought I’d share how working on games, even on small, one-to-five person teams, and being a professional programmer working in similarly small teams, has taught me a lot about games and how they are made.

The Last 10% of a Project Takes 90% of the Time
A lot of people seem to think this is a copout–it’s really unintuitive, even to those of us who do this for a living–but it’s absolutely true. The tail end of a project is where all kinds of bugs an inefficiencies rear their ugly heads, and you spend a lot of time refactoring, or changing the internals of the way a piece of code works without changing what it does. It’s unexciting and time consuming. Plus, code can be like playing Jenga; you remove one piece and put it somewhere else, and everything collapses.
That said, this does not excuse crunch practices. Crunch always means your project manager didn’t do his or her job right. There has been a lot of talk going on about this lately, most recently with Rockstar bizarrely bragging about it, unbidden, to the press, then trying to backpedal. A good project manager knows to bake enough time into their estimates for that last 10%. If your people are working 100 hours a week on a game, that’s not something to brag about, that means you’re doing it wrong. There are people out there who are willing to do that just so they can put on their resume that they worked on Read Dead Redemption 2 or whatever, but I can’t imagine a world in which that’s worth it, and most devs who have been there will agree. There are companies out there making games, even AAA games, that don’t force this kind of thing. On top of that, a good many studies have shown that crunch actually reduces productivity in the long run because it introduces a lot of mistakes that would have been caught if your employees weren’t exhausted.

Everything is More Complex Than You Think
I can’t tell you how often I’ve started a project and thought, “This will be easy! I’ll be done in a couple days!” And after a few hours, after realizing all of the complicating factors, it’s more like couple of weeks. Sure, sometimes the reverse happens–we asked ourselves several times this weekend if we were going to finish our game jam entry, and we ended up completing it with several hours to spare–but that seems less common. My point is, give developers some slack when things get delayed. Time estimates are hard.

More Money/More People Not Equal A Better/Faster Project
I remember my Computer Science professor talking in one of our project management classes about a book called the Mythical Man-Month. The idea is that managers (especially non-technical ones) think that if a single developer can get a project done in six months, then two developers can finish it in three months, six developers finish it in one month, and 24 developers finish it in a week. Sadly, that’s just not how it works in software development. Sure, two developers might be able to cut the project time nearly in half, but the more people you add to the project, the more you get bogged down in meetings and communication and conflicting ideas and styles. Sometimes a small, agile team of quality developers who work well together can do way more than a big-budget team that’s bloated and inefficient. I’ve seen this even on two-man teams; at a previous job I came in one morning and found code that I had spent three days writing gutted and rewritten in a different way without explanation just because the other developer had stylistic differences. I think this is a large part of why Wildstar ultimately failed; the communication element just wasn’t there, and it took too much to get fixes and changes in place. This isn’t an easy issue to fix, but it’s a huge one!

Be Nice To Devs
Generally, the things you don’t like about a game aren’t the individual developer’s fault (or at least not just their fault), and the things that are actually broken will get fixed faster if you’re nice than if you’re a jerk (mainly because it causes stress which lowers productivity, but sometimes we just bump things down on the priory list because the affected user was a jerk).

What Game Devs Accomplish Is Really Impressive
Knowing what goes into just the small games I’ve made has given me a deeper appreciation for what professional game devs put into their games. I can’t even get two computers talking to each other over the network right, I can only imagine trying to get thousands of computers talking to one server and staying in sync. And it’s not just developers; there are musicians, sound designers, voice actors, graphical artists (both 2D and 3D), mocap actors, testers (not as fun as you’d think), network engineers, database administrators, and a whole list of other jobs I can’t do that go into making a professional game. And everything has to fall into place at once, just so Stuga can remind you how long she’s been looking for you.