Plan for Paul Malyschko

Game in a Day... Week... Two Weeks... Or How Not To GID

One of the problems of being competent in more than one major stream is that inevitably, you end up not quite having the skills you hoped you'd have. At times, it can lead you to strange decisions, like participating in a GID when you may not have a hope of actually completing it. So here are a few lessons I've learnt, titled:

How Not To GID

Lesson 1: Know your software.

My first GID, in fact, the first time I had programmed in a very long while, was not so much a GID, more of a, "this is how you set up a VC.NET project and compile a basic SDL program". Oh joy.

Also, hailing from a console-programming and Linux/BSD-heavy background, setting up VC.NET projects is a little foreign to me. In short, experiment and learn your software... go through tutorials and get a working codebase before you waste precious hours on setting up.

Lesson 2: Don't code an engine.

In my GID stints (which did not equal a day, check the next lesson to see what I mean), I started in C++, after setting up classes for god knows how long, I broke open the dusty old C code. Boy, was that a transition. Memory management just isn't the same anymore, but I can't help myself; I do love my pointers.

Don't overdesign; don't switch languages halfway through; don't code an abstract framework anticipating the needs of the next 3 GIDs. It may seem obvious, but when you're in the thick of it, these seem like natural things to do. Avoid it like the plague.

Lesson 3: Manage your time.

My first GID also came around a time when EVERYTHING was happening. Void War artwork, exams, late assignments... the list goes on. I did not have a complete day to spend on a GID, so I intended on breaking it up into stints. A week later, I decided it would be a good time to look at the code again, after taking 3 days too long on a programming assignment I thought would be easy.

Big mistake.

If you have too many things to do, don't GID. If you can't spare a weekend, don't GID. If you want to get drunk and pass out in the middle of the day, don't drink beer while GIDding (go me!). Plan ahead, during a time when you aren't counting the seconds you have left before a deadline.

Lesson 4: To HELL with it all!

I do art; I design games; I code; yet at the moment I have NO GAME to my credit. Why? I'm forever too busy to put time into making a game. TO HELL WITH IT ALL! If you have said any of these things:

"I'm too busy to GID"
"I'm don't have the skills to GID"
"I'm coding a game now, why should I GID?"
"I don't have any ideas for a GID"
"I'm an artist and I don't GID"

You are a prime candidate to GID. The most important lesson is, if you keep making excuses, you're never going to do it.

Too busy? WHAT'S ONE DAY?
Don't have the skills? LEARN ON THE JOB.
Coding a game now? FINISH ONE TODAY.
Don't have any ideas? ONE WORD: REHASH.
An artist? TEAM UP WITH A CODER.

I wasn't sure if I had the time management or coding skills to complete a GID, and I was right. However, the act of participation is in itself the most empowering thing, as you realise your dreams needn't stay dreams; that they are manifesting even as you code.

Not only that, but GIDding is the best way to prototype a game to see if it's going to be fun. You may not have all the features you want, but you'll decide what goes in and what stays out, a crucial skill to learn in any field.

Thanks to Tom Bampton, Phil Carlisle, Nauris Krazue, Craig Fortune and the rest of the GID crew who've made the often painful process of coding games a delight to bear.

Addendum

For Matt, who insists on having screenshots for every .plan

While this appears simple, it's actually about four separate data structures with cascaded linked lists (in C, which if you know about coding with pointers in C, is ALL FUN!). Also, I've yet to get the screen to clear... at least it goes to the other side of the screen now, instead of crashing everytime it goes beyond the screen boder.



And more: