Junior’s first 48 hour collaborative gamedev
Life gets boring sometimes when you do the same thing over and over again by yourself. Two weeks ago, I had an epiphany: I didn’t have to do the same thing by myself if there were people I could coax into doing it with me. Must have been what I’d missed out on all this time.
Finding people was easy enough: I scrounged 30 seconds of my day and put up a Facebook status update.
"Find adventure and excitement in game development!"
"Dedicate 48 hours of your time for the glory of the motherland!"
(Not really though, it was slightly more boring than that.)
Luckily, some friends fell for the bait almost immediately. I contacted these upstanding citizens and thinned down the list to whoever would be available soonest.
There was about a week of pre-planning involved in this project. We started a measly scrap of a Google Doc and turned it into a kaleidoscope of schedules, tasks and game mechanics. It felt wise to ensure as smooth a start as possible. If we could make that happen, we’d have an incredible amount of creative momentum.
The resulting high level plan boiled down to using these technologies in our game:
Language : Haxe
Framework : NME
Platform : Flash
Move fast, break all the things
A classic slogan in the world of tech. Boy, did things break. Haxe turned out to be a poor choice of tech for a few reasons:
- No Haxe experts on the team, both of us were totally green in using the language. This meant that fixing compilation warnings and errors took up most of the coding time. Actual progress in programming the foundational features in the game proceeded at a snail’s pace because of this.
- Flash has lackluster performance on mobile devices which support it. We could not figure out how to overcome
touch event delays or if the device was even able to register certain events (like
touchend) properly. - Other “subtle”, but significant language annoyances which this blog post sums up pretty well.
- Near total lack of up to date and properly searchable API documentation.
- We disregarded the key feature which had originally made us choose Haxe: its cross-compilation into many languages.
The decision to choose Flash as our target platform muted that advantage.
Inevitably, we gave up trying to use this new language to write the game and switched to HTML5. No time was wasted trying to port the existing code over. Having devices ready for testing made this a confident decision and we enthusiastically wiped the slate clean.
Game mechanics
A clever idea came out of some brainstorming we’d done on the first night of the gamedev: combine the player’s attack with the player’s movement. With this key mechanic and the newly programmed collision detection for game objects, we whipped out a mini-game in about 8 hours time. Defend yourself from an onslaught of enemies in a top-down view reminiscent of Crimsonland.
The player has to steer his character and shoot wrenches at enemies simultaneously. When the enemies touch you they wear down your health and you slowly die. Enemies spawn faster as time goes on. An ‘enemies killed’ counter keeps track of how many heads you’ve bashed in with your infinite supply of airborne wrenches.
I did most of the core engine coding, while Hesam tweaked the game balance and feel. This combination worked quite well since it meant there were fewer low level conflicts whenever any part of the game had to be changed. And about 9 hours later, we had a working build of the game that ran on both the Android tablet and the iPad.
Where do we go from here?
We may reuse some of this code to refine the game idea into something more complete, though the experience of team-based game dev will have to suffice for now. As brutal as this event had started out, it was a miracle we got anything working at all. For our first taste of collaborative creation, we were very pleased with what we had at the end of 48 hours. Sunday brunch solidified that rewarding feeling in food form.
Actual Time Spent
Hours Used
Day for Game Dev Total Hours
Fri 3 / 5
Sat 8 / 24
Sun 2 / 4
Total 12 / 33
Productive* for ~36.4% of the time.
Around 40% of *that* time was spent going over more / new plans.
The remaining time is a fair estimate of total physical production time
e.g. drawing out mechanics diagrams, debate on how to balance the movement, etc.