Category: Game Development

Since I am a part-time indie game developer, I am highly aware that the time I spend on game development tends to be a very significant function of my output.

If my other responsibilities are great, and I don’t consciously make an effort, maybe I’ll only get a couple of hours of work in. No matter how efficient I could use that time, two hours a week isn’t going to let me accomplish much. I can’t prototype or play test much, nor can I really get much implemented.

So all year I’ve been setting goals to increase this amount in a sustainable way. That is, I make sure I can handle my day job, my family, and my home responsibilities while also ensuring I get enough sleep. Stealing time from my sleep, for instance, allows me to temporarily use that time productively, but it always catches up with me and I end up paying for it in the end. What usually happens is I get slower and less efficient, and then I start sleeping in, which takes away my precious mornings that I dedicate to game development.

Recently I’ve been rereading Steve Pavlina’s book Personal Development for Smart People: The Conscious Pursuit of Personal Growth, and in the chapter on Power, he talks about personal quotas.

The idea is that to increase your performance in an area of your life, you can set minimum daily quotas to reach. Some authors set a daily word count. No matter how long it takes, they must write 250 words. Or maybe they do what I’ve been trying to do and set a minimum number of hours since word count might not represent the effort of writing very well if they spend a lot of their working time researching or editing, actions that don’t necessarily increase their word count but still contribute to the finished project.

Pavlina said he used to dedicate a few hours to writing, but he found that the end results weren’t ideal because his focus was on putting in the time instead of finishing. So he focuses on outcomes. Instead of writing for two hours, he writes until he finishes an article.

In a way, this reminds me of the Theory of Constraints and the story told in The Goal: A Process of Ongoing Improvement. Eliyahu M. Goldratt’s protagonist is put in charge of a failing manufacturing plant.

This plant has very expensive machines, and so the company insisted that to be the most efficient, those machines should be running as close to 24/7 as possible. Downtime meant lost efficiency and wasted opportunities to make back the investment in those machines.

Here, they were focusing on effort.

What they forgot was that the effort should serve a purpose.

People weren’t buying what was being made, either because they produced too much, or it wasn’t the right product for their needs, or the finished product couldn’t be made because there were bottlenecks in the manufacturing process in which some parts were ready while others needed to wait to be made. No matter how efficient the plant was in utilizing their resources, all they ended up with was a warehouse storing the unsold and unneeded parts they were creating.

Once they started to focus on the finished product, the outcomes, they rearranged priorities, ensuring that what was being built at any given time was shortening the time of the entire process, not just making any one part more efficiently.

I just spent the last couple of months implementing what was supposed to be a “simple” physics model for a game I’m working on. It turns out, physics isn’t simple, and there are plenty of solved problems in this domain, as well as many available 3rd-party libraries such as Box2D. But no, I insisted on implementing my own. I don’t need an entire physics engine. I just need something that looks good enough. How hard can it be?

In terms of my personal education, I gained a lot. I consulted a number of resources, such as the Impulse Engine by Randy Gaul and Chris Hecker’s Physics articles for Game Developer Magazine. I had a refresher from my high school and college physics classes, plus I learned about ways in which physics engines in games have historically fallen on their faces.

But in terms of outcomes, that’s two months I spent implementing and tweaking a small part of my overall game project. I focused on spending time on development, and I just kept working on what I was working on because I didn’t ever feel I had a good stopping point. It’s easy to want to spend a lot of time fiddling with coefficients and parameters to see if I can get the feel just right.

If, instead, I really focused on outcomes, such as getting the physics implemented in a week, maybe I would have seen that I was running out of time and so decide to use a 3rd-party library.

It doesn’t matter if I wrote the code myself. It matters that I am a step closer to having customers play the game.

Some game developers keep a simple list of tasks in front of them, and they work on whatever seems interesting, adding and removing tasks as they go. Others have a full project plan.

Now, as a part-time indie game developer, time still means results. If I spend 10 hours in a week, I am able to focus more than if I spend two hours in a week. It can mean the difference between getting meaningful accomplished in a given development session versus starting and stopping over the course of weeks to get something equivalent done.

So time still has a huge effect on output.

But I can do a better job of ensuring that the time I do spend on game development isn’t open-ended. There’s always more work to do, so just putting in time to work isn’t necessarily going to result in all of the work getting done so much as just a portion of the work getting done really, really well.

Over a decade ago, while I was still in college, I went to my first indie game developer meetup. It was in a suburb of Chicago at a Starbucks, and it involved mainly people who participated in Dexterity Software’s game development forums, which are now the Indie Gamer forums. My first meeting’s minutes are still online: Indie Game Dev Meeting Summary December 2004

It was kind of a mastermind group. We showed off what we were making. Or rather, they did. I never had anything to demonstrate. I played their games and gave feedback, and we talked shop and set goals for the next month’s meeting.

Some people traveled from downstate to make it out to these meetings, which alternated between that Schaumburg Starbucks and the Dave & Buster’s in downtown Chicago.

I remember while packing up to leave one meeting I asked everyone, “How do I get better at programming?” At the time, I felt like I wasn’t making a lot of forward progress and it was mostly due to my lack of experience and knowledge.

I remember getting a few looks, there was a pause, and then someone said to nods of agreement, “Just…do it.”

It didn’t feel like very helpful advice, but I chalked it up to the idea that no one actually knows how they get good at something. When you are good at it, you don’t remember how you got there because your goalposts are always moving, and if you aren’t good at it, you don’t know how to change that fact.

Unless you ask, of course, and “just do it” actually is fantastic advice.

I learned C++ in college, but it was Visual C++ 6.0, and it wasn’t consistent with the C++ Standard, and I think I was taught wrong. I remember reading code online and not understanding why people were needlessly using “advanced data structures” such as vectors and sets. I taught myself BASIC on the Apple II c+, but programming in C++ was not fun or enjoyable.

But then I found some advice in the GameDev.net forums to read Accelerated C++: Practical Programming by Example. I bought the book, forced myself to read it from the beginning and do the exercises, and wouldn’t you know it, it turned out that C++ wasn’t so bad. What were considered advanced topics in college were introduced in the first few chapters.

I was still struggling to be productive with programming. I was challenged to find tools and libraries to make my job easier, and it is how I learned about a sprite engine, which I blogged about extensively.

I learned how to use libSDL. I succeeded at my first game jam when I attempted to work on Game in a Day, which was hosted by people at Garage Games. Kinda. I made something playable. It just wasn’t what I wanted to make originally.

And I learned a ton participating, including the first time I had an overwhelming sense of fear that I had no idea what I was doing and should stop, even though I had no rational reason for listening to this fear. I pressed on somehow, but I was shocked at how that experience challenged me. I didn’t expect it.

I had that almost tangible anxiety a second time, probably during my first Ludum Dare compo, but it was less powerful and I recognized it and pushed through it, and I haven’t felt it since.

I started finishing games. I built confidence in my abilities. When I read my old blog entries, I read about someone who struggled with focus and time management, someone who felt like he wasn’t putting in enough effort to learn and work on games.

But over the years, chipping away at ignorance made a difference. Today I’m seen as not only an expert in C++ but also in software development in general. I still find myself surprised by C++ today, though. For instance, sometime in the last couple of months I learned that I could forward declare more often than I thought I could.

A decade ago I couldn’t code my way out of a wet paper bag. Today, I could rearchitect a complete game halfway through its development without so much as a flinch.

Most of my experience and knowledge of software development came about due to my persistence with working on my own game projects. I did research on best practices. I sought answers to the problems I ran into. I wrote code outside of class and outside of my day jobs.

I just did it.

And while I might not have felt I was making a lot of progress on any given day, over a decade of such days resulted in a ton of growth.

It could be argued that a more focused effort with a lot more time dedicated to it would have been better, that I could have gotten to the same point years earlier.

But the advice would still be the same. You want to learn how to be a better programmer, artist, game developer, mathematician, engineer, or designer?

Just do what they do, and push through the “I suck” phase until you get the hang of it, push through the fear where you feel like you might choke and give up. Just do it, and even if you don’t figure it out today, tomorrow you’ll know how.