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.