I’m helping out with a student game-programming competition at the moment – Dare 2 Be Digital – and we’ve just had a day of judging pitches from teams, trying to decide which ones to allow into the full competition. During the pitch process, a few pieces of recurring advice came to mind. We were allowed to advise, but since the day was mostly about deciding who to let through to the next round, there was very little time left over to give each team any specific comments (we had to focus instead on asking searching questions :)). For those that get through to the next round, they’ll get properly and intensively mentored, so it should be fine but I thought I’d throw my thoughts up here (and maybe some readers will want to add to them?)
Competition Overview
Part 1: teams of up to 5 students (typically undergraduates studying Computer Game Development, Computer Science, or Art) enter a written pitch in the hope of being selected to take part in the competition. Each pitch is judged, and the top 50% or so get invited to come and give a 20-minute presentation in person to the judges. The judges then decide a few of them to let through to the next round.
Part 2: the teams are all put together into one office / campus / whatever for just over 2 months, working 9-5 (probably more like 9-7) every day to design and implement their games. The teams are able to look at each others work, and get daily mentoring and lectures from games-industry professionals.
Part 3: the previous part is repeated at multiple locations around the country. Towards the end, winning teams are selected from each location to go through to the final, where they have to present to the judges and allow them to play the finished games. The winners get prizes.
We’re just finishing the first part at the moment, at least for the regional centre which I’m involved in.
Essential advice
So, here’s the big one. Numero Uno. The Big Cahuna.
Will you finish this game before the competition ends?
This is absolutely essential: if you can’t finish your game, then you CANNOT win – you’ll have nothing to show, and you lose by default.
Technically, of course, finishing a game in 9 weeks is easy. In practice … well, just go over to GameDev net and ask what percentage of game projects people have ever finished, out of all the ones they’ve started – and that’s *ever*, not with some short time-limit like in this competition.
Last year, I gave a talk to the teams at one of the hosting centres about 2/3 of the way through the development phase. Almost half of them were in danger of having NO playable game ready by the end of the competition. Sure, they had graphics, and a control system, and you could use a 360 controller to “play” the game – but there was no gameplay, no mechanics, no meaningful experience.
This is not a competition to see who can invent the most imaginative game *idea*.
This is not a competition to see who can write the most clean or efficient source code.
It’s a competition to see who can write the best game. So, you need to make it absolutely clear that you’re going to have a game by the end of it!
Recurring problems
So, here’s some things that you probably can imagine might go wrong, but you assume are relatively easy to avoid – but where you’re wrong. “Won’t happen to us”, you think. In practice, these are things that seem to be very difficult to avoid – often the reasons why these “simple” problems are difficult to avoid are themselves actually quite complex, so I’m not going to suggest you try to understand this (and I won’t try too hard to explain). Suffice it to say, if you find this stuff interesting, you’ve got a lot of study and experimentation ahead of you, enjoy! But these are things for your team leader to be keeping an eye on every week, and MORE IMPORTANTLY these are things that EVERY member of the team should be sounding the alarm on if they notice them happening, sooner rather than later.
No way to measure progress
All difficult projects – especially iterative, creative ones – are 90% complete 90% of the time.
If you’re not used to making games, you really have no benchmark for how close you are to completion. Those of us who’ve been doing it for years have a lot of gut feeling we can use to tell how far something is from being ready. You don’t.
Without knowing how close you are, you have no idea how much you need to panic – do you need to stay late tonight, and every night for the next week, or should you be relaxing and spending some time chatting up the mentors trying to secure yourself a job at the end of the project?
Suggestions:
Any measurement will do, no matter how silly. Just make sure that it’s INDEPENDENTLY VERIFIABLE, because otherwise sooner or later you’ll lull yourself into a false sense of security / false sense of panic.
None of you are managers
Those of you who put down “team leader” or similar all think you are. You’re not, guys, sorry. You have nowhere near the skills to do that, let alone the experience and training. You’re just “interested amateurs” who might like to become managers one day.
Suggestions:
Don’t be a dick. Yes, that’s all – just keep an eye out for any accidental arrogance, grandstanding, or bullying on your behalf.
Treat yourself as EXACTLY equal with everyone else in the team. (note: I chuckle every time I hear a team leader say “we’re all equals in this team, but of course I make the final decisions”). Don’t try to push anyone in the team harder than you push yourself. But … that’s not enough. More importantly, don’t ask anyone else to do stuff that you’re not doing the equal of: too many team leaders end up whipping their programmers whilst not producing any code themselves, or asking for detailed design docs whilst spending all their time coding. If your team needs to plan, you should all plan. If it needs to implement, you should all implement. Not all the time, but … it’s far too easy to end up focussing on the stuff you know how to do / want to do, and then arbitrarily “assign” a member of the team to do the other bits. That almost never works out well. Approach the tasks, the duties, and especially the problems, as a TEAM. Because you’re all far too inexperienced and unskilled to manage to succeed any other way.
Consider SCRUM. It lets you do away with the “manager” and instead have the workload split between TWO people: an “organizer” and a “vision holder”. If you decide to use it, buy a copy of Ken Schwaber’s book “Agile Software Development with Scrum”, and follow it *exactly*. Even highly experienced industry professionals are rarely wise enough to know how to modify Scrum without breaking it – you certainly aren’t.
It’ll be ready when it’s ready
No. It won’t. It’ll never be “ready”: you are in a competition designed to push you to make the best you can make in a short period of time; I guarantee that what you end up with will NOT be “finished”.
Suggestions:
Get to “first playable version” as fast as frickin’ possible. Let me give you a hint here: I’ve worked on games that went from “someone thought up a vague idea for a client/server multiplayer game” to “designed, implemented, tested, deployed and live being played by thousands of people” in around 3 days (if you’re interested, the programmer on several of those projects was Kev Glass – have a look at his “24 hour” games and even “8 hour” games). That’s how fast it’s possible to go.
YOU have whole WEEKS available! I see a lot of 9-week schedules with milestones for making the level design, or adding the assets, or getting the controls working, or doing the game design, all in the last 3 weeks. Screw that. Get something playable in week 2. I doubt any of you will manage it, but you should at least aim for “something playable by end of week 3”.
If it’s completely uninteresting and dull, you should probably take this as a great big massive flashing warning sign (AWOOGA, AWOOGA!) that your game design is overly ambitious and that you’re going to fail to implement the “fun” parts by the time the competition ends. Get back to the drawing board. FAST!
You will NOT finish your game
None of the winners had “finished” their games by the end of the competition last year, they all had tonnes more stuff to add, including cool features that would really add a lot to their games.
Suggestions:
So, be very, very prepared to cut viciously. Most importantly, you need to know which part(s) of your game design are truly, utterly, essential to there being any hint or essence of fun *at all*. Not “enough to fulfil the game idea” but rather “enough to make it look like you actually wrote anything at all in those two months”.
When you get to the end of the compeition, and you stand up to give your presentation, imagine you had no working version of the game, and imagine what a complete muppet you’d look and feel. Now imagine how little functionality you would give your right leg for to have in the game and working at that point. That’s what you should be ensuring you ALWAYS have working in the game. That way, no matter how much you need to cut, you’ll always have *something* to show for yourselves.
And, as it turns out, often that kernel of the game – often its not even a complete gameplay mechanic, just the key elements of one – is the only part of the game design that survives unchanged to the very end. You might discover in the last week that your core features can be used to implement a different game than the one you intended, and that actually it’s a lot more fun (I don’t advise this, but it can and does happen in real life).
Middleware never works
Look, even the professional games companies have massive problems getting the best of middleware to work properly. If you’re not sure of this, google the court-case brought last year against Epic, the makers of the Unreal Engine, probably the most famous piece of game-industry middleware.
Suggestions:
Don’t use any middleware, unless it is VERY VERY simple (like “allows you to play a sound clip”).
Be very cautious about using a third-party 3D engine: aim for something that’s quick and easy to get up and running, and forego as many features as you possibly can. Every feature in that engine is just one more confusing source of bugs that you don’t understand and have nothing to do with your game – but which you have to debug anyway because for some incomprehensible reason they’re crashing your game. Even though you aren’t using those features. WTF? Well. Exactly. Welcome to the world of middleware!
Most teams write their games in C++. Java is probably a much wiser alternative *IF* you have people who are skilled in it. Obviously, what language you know is far more important than which is the best language for the job (that’s counter to what you’ll read on the web; people on the web aren’t talking about 9-week game-programming-competitions – don’t listen to them (too much)). Flash is also an excellent choice, with the best built-in scripting language, but with substantially less flexibility than Java, which in turn has less than C++. For instance, I wouldn’t want to try and get a 360 controller to work with Flash (although it’s easy with C++ and Java, I’ve never tried it with Flash but suspect it’s (nearly) impossible).
Programmers and artists are not dispensable
The vast majority of most game development teams are programmers or artists. 75% is not an unreasonable guesstimate. You’re a team of 5. How many of you are programmers? (ideally: at least 2) How many of you are artists? (ideally: at least 2).
What’s the other person? I can’t say – varies enormously from team to team.
Suggestions:
ALWAYS have at least one person who is ONLY a programmer, nothing else. Ditto for ONE artist. They have far too much work to do for you to be placing mutliple roles upon them!
If you don’t believe me, or think you can work around it by lots of job sharing, just think about this: when you have 1 hour left to fix a nasty bug just before the final presentation, and it needs a code fix AND new artwork, are four of you going to sit around drinking neat vodka whilst just one of you does all the work? Make sure you have those core people! (obviously, the ability and the willingness to share tasks helps enormously as well, just don’t use it as an excuse to not have the core members too).
Wrap-up
I’m sure there’s more. I’ll go through my notes from the judging day to see what I’ve missed, and probably add to this post later. In the meantime, feel free to add your own comments / ideas / suggestions below…