Just read an interesting article on Chris DeLeon’s blog on the value of deliberate practice when learning game development. This makes perfect sense and I agree completely, having read extensively on the subject of expertise and practice recently. He gets a lot of enthusiastic beginners come up with some grandiose proposals for their first game project. His point is that if you want to learn to write games, start off writing toy games, based on old video arcade classics like Asteroids, Pong, and Space Invaders. Each project is supposed to be difficult enough to be challenging, but not so hard that you cannot finish in a reasonable amount of time. So the “10,000 hour” rule applies to us amateurs as well. I hope I can get some of my previously accumulated hours credited to my own 10K hour tally, and get there before I forget why I started.
Chris also goes on to make some interesting comments on Minecraft, and the commercial realities of game development, and why big gaming houses tend to publish the same kinds of games. It can be good news for indie game developers (find a small niche big enough for you, but not the heavyweights), but probably makes no real difference to amateurs like me.
In My Defense
So why I am ignoring his advice and not building a Pong clone? Let me explain, with the aid of my evil twin with the deceptively pleasant name.
Naysayer Bob: Isn’t a role playing game biting off more than you can chew?
Yes, if I was planning to write my own version of World of Warcraft. Instead, I am writing something far more modest, a dungeon game similar in scope to games made in the 80’s – 2D graphics, some sprites and simple mechanics. The dungeons will have dozens of rooms, not thousands. The number of interactions will be limited – no fancy AI, or open game world to explore. I DO think about this sort of stuff, as well other more far out ideas – but they stay in my head, where they belong for now. I am focused on the basics first.
Naysayer Bob: Yeah right, but even a simple dungeon game has a lot of elements making it far more complicated than Space Invaders, for example.
True, but I am building things one piece at a time. I have no deadlines, and the journey itself is probably at least as interesting. I suspect that when the game is finished, it will be a mediocre example of the genre. I will still be as proud as any preschooler sitting on the potty, as I “did it all by myself”.
Naysayer Bob: Hmm, I’m not convinced. You don’t have much experience.
Yes, and no. No, I do not have a track record in game design or development. What I do have in spades, however, is experience in building complex systems in my spare time, one piece at a time. For better or for worse, I am a compulsive developer. I always have some project or other on the go. Despite this character flaw, I have learned to become a ‘finisher’ – I will finish what I start before doing the next thing – I am too time poor to do it any other way. And I pick my projects with care, favouring modest goals and fast iterations. Armchair agile development.
Given my situation, I aim to make things that are highly modular, maybe more than would appear necessary for a guy, a laptop and a rainy afternoon. I do this because sometimes I write a piece of functionality which I may not revisit in a year, as I’m off doing other things.
One of the things that happens when you singly handedly write hundreds of classes over a long period of time, is you forget what you did and why you did it that way. You don’t forget straight away and not everything – some code is just seared into your brain – but enough falls out of my head to make it a problem. You look at something you did years ago, and think – “I don’t remember why I did it that way. That looks dumb!”. Maybe it was dumb, and maybe it wasn’t. Who knows anymore? More than once in such situations, I decided that Current Me knew better than Past Me and deleted that weird line of code – and then a few weeks later spend hours puzzling over a subtle, weirdass problem which has magically appeared. After much screwing around, I often come around full circle and realised why that weird line of code was there in the first place. I put it back in and presto! Weirdass bug is fixed. Scenarios like this have hammered home to me that a hobbyist’s time is even more expensive than a professional’s. The few hours you get to work on your own stuff is precious, and you should learn to be ruthless with your time. Repeating the same mistakes will destroy your productivity, all the fun will leach out, and you will quit and go watch TV.
So after more electric shocks than average, this monkey has finally learned to pull the lever to get his food pellet – I now religiously write a sensible number of unit tests and document all ‘interesting’ decisions in the source code, as a sort of time capsule to Future Me. As with all things, moderation is key. Hundreds of unit tests and pages of documentation do NOT help. After all, it’s a pet project, not the Panama Canal.
Here are some examples of how I protect Future Me from himself.
Example 1: Do not press the red button with a skull on it.
“This line looks stupid but is a necessary hack for a rendering bug (6724) in v1.2 of library ZZZZ. Do not delete no matter how much you want to!”.
Example 2: If you were lazy at the time, confess
“Fix this later. Found a better way but a lot more work – use thread-safe collection to store each element keyed by its ID – MUCH faster, but need to fix A, B and C to avoid race conditions.”
Naysayer Bob: You are totally right and I am totally wrong.
I made him up, so I can make him say whatever I want. It’s bedtime for Bob.
I have a plan, just not a good one, and why I don’t care
I have a plan, but it’s in my head. The broad brush strokes are fairly constant, but the day to day today stuff can change a lot. I have tried writing it down, but keeping it up to date never seems to work. My brain does undo and delete better. Besides, it’s not that complicated.
Here’s a quick list of my short and longer term goals. This is as close this project will get to project management – I’m a fan of John Carmack’s approach, which I will paraphrase loosely as “It’ll be finished when it’s done”.
Short Term Goals – days to weeks
- Finish Dungeon Editor v 0.1
- Make sprite walk around a dungeon
- Create Monster and simple AI
- Character vs Monster Combat!
Longer Term Goals – few months
- Dungeon Editor Upgrade
- Character Creation Editor
- Monster Creation Editor
- First Real Dungeon!
That sums it up really – a carefully thought out, meticulous plan to produce the world’s greatest game, by myself, in about eight months.