It’s been a while turns out the final year of a Master’s degree involves a lot of work, with projects swallowing up all my spare time. Somehow I managed to make it to Lille for the third Art Game Weekend though: here are my results!
In brief, it was a failure as epic as our success at the previous edition. You’d think I’d know better after all the jams I’ve entered. I should… in theory. Then again as our favourite Mythbuster would say, failure is important
This is not a full post-mortem – I’ve done such post in the past, but here I’ll try to limit myself to an enumeration of what went wrong without going into detail about what the project was exactly. If you’re interested in (re)reading my previous post-mortems in the mean-time, here they are in chronological order:
- Ten lessons from GGJ 2012 (GGJ 2011, Verona)
- Going, going “Gone” (Art Game Weekend 2, Paris)
- “Free” as in “Freedom” Game Jamming (GGJ 2012, Paris)
Note that this is all take-it-or-leave-it advice for game-jams only: for longer projects I’d be inclined to advise the exact opposite in many cases!
1. Don’t use OpenGL”raw”
By this I mean don’t use it directly: libraries that mask OpenGL calls, such as SFML or Slick2D are fine. I started out using LWJGL though, which meant that all the draw calls were written directly using OpenGL 1.1 (back when glBegin/glEnd were still the first order of business).
Because OpenGL is a global-scope state-machine it can be hard to debug when it goes wrong, because it’s not always immediately apparent where the problem is coming from. More importantly, don’t mix your OpenGL code with somebody else’s! SlickUtils implements text-rendering, but forgets to unbind texture it used. Since all OpenGL calls change the state of the same global object this caused bugs to appear in my own code, seemingly out of nowhere!
I was going to say “48 hours isn’t long enough a kludges to come back to haunt you, so code filthy” but, as my friend Gaeel pointed out, I’ve said this before many times yet persist in coding in an anal-retentive fashion.
That I’m an academic is serious a problem. I’ve been taught to use modularity, encapsulation, genericity, const-correctness other buzz-words, to specify positions and sizes as fractions of the world/window size and to avoid “dangerous” things like global variables and goto statements. Self-taught programmers might write code that makes my eyes bleed, but if it works as well as mine and takes a third of the time then maybe they’re onto something.
In future jams I’ll avoid the private and const keywords altogether I think, and use hordes of global variables rather than worrying about proper scoping. That way I might actually get something done.
3. “Work smarter, not harder”
This is the kind of advice that makes you want to slap the person who says it, but then doesn’t make it bad advice. Looking up read-eyed from my computer after hours of coding I noticed that one of the other group’s artists’ were playing Farmville. When I looked up again hours later they were still playing Farmville. I told myself that this team must have given up. They won.
Why? They’d taken an interesting idea and gone to the essence of it, while I’d spent 48 hours going around in circles. I say congratulations.
4. Don’t use your own engine
What this jam has in common with the equally disastrous Montpellier in Game 2012 was that I used my own engine (in the former case “Arrogance” in this case “Ambition”). If you do this you may be tempted to add things to it rather than working on a specific solution to a specific problem, and to keep your code clean for posterity…
5. Don’t count on unstable, untested or unimplemented features!
My engine didn’t have support for drawing textures or playing sounds. These things should have been easy to add… in theory. I already had an OpenGL texture-loader written for another project, so all I needed to do was to copy-paste the code… in theory.
I hadn’t counted on how Slick’s code would interfere with mine. In practice I spent most of the jam debugging engine code, which takes many times longer than gameplay code and isn’t much fun. When all’s said and done I didn’t have fun at this jam at all, and it was nobody’s fault but my own.
6. Change direction if necessary
At the GGJ 2012 I’d overheard Oliver LeJade (@LeJade) suggested that one group start again with Game Maker when they got stuck. Luckily I thought of this while pulling my hair out at 2am: probably the only thing I did right at this jam was to cut our loses and start again with a different technology (AWT rather than LWJGL).
7. Use the same technology as other programmers
I hate to say this, but had we used Unity I could have discussed problems with the other developers instead of ending with only bugs for company. I was very lonely, where at the previous AGW I’d had Marc (@corpsmoderne), André and Kevin (@oneliferemains) to bitch about Android to!
Because we programmers are a rare breed at certain kinds of jam (for this reason), and because designers, musicians and artists tend to be united in their lack of mathematical rigour (read: lack of anal-retentiveness), we really need to stick together!
8. Everyone should be play-testing the game all the time
The first thing we should have done was to set up the JRE on all the team’s machines so they could test the game, or even Netbeans so they could make tweaks. Playing the game tends to help one see the bigger picture, when otherwise you might be blinkered by specific art or sound or programming concerns. It also would this have allowed us to avoid a few platform-specific bugs (the game didn’t run on Windows two days after the jam).
Last but not least, it would have helped the designers do their job: game-design without a modifiable prototype (digital or no) in front of you is like painting blind-folded or singing blind-drunk. It’s can fun and fulfilling at the time, and it feels like you’re accomplishing something brilliant, but the result is often not something you’re very proud of.
9. Don’t be a “tool”
By this I mean don’t blindly do as you’re told. I don’t mean that you should do the designers’ job for them, but giving them your feedback on their ideas will very likely help them to do it themselves. Think of it as your duty as part of the team: if you plan to wash your hands of the result, you might as well not come. After all, nobody’s paying you.
More than this though, I think the whole idea of seperating people into castes is wrong. We’re all “game-developers” here, and while I may be better at programming than art I can draw, animate, do basic 3D modeling and rigging; I’ve tampered with foley, I’m learning make basic electronic music with Samplitude and Ableton Live and I spend most of my time thinking about or reading up on game design.
There should be an design “department” in a 5-man team any more than there should be a software or art department: everyone should have their fingers in every pie. This is important because…
10. Come up for air on occasion
If you’re too focused on your specific programming problems you may not to realise that there were problems with the art-direction, not to mention the overall design! The same goes for art (from experience) or sound (I’m guessing) problems: it doesn’t pay to keep your head in the sand!
We had a mixture of cartoon and sombre artwork, and were either making a tamagotchi, an interactive desktop or an interactive painting, depending on who you asked. This brings us to…
11. Communicate! Communicate! Communicate!
As a whole, we just didn’t talk enough: each of us had our own idea of what the game was/should be, and we never sat down to sort out what it was that we were making. The result was utterly schizophrenic.
12. Be self-critical, and critical of others
It’s not because you’ve been to a lot of game jams that you can’t make stupid mistakes: look at me I try to be humble, but it’s not very humble to think that you’ve succeeded in being humble. I suppose the only way to be truly humble must be to believe that you’re incapable of humility. That said, if I were to tell you that I am incapable humility, that wouldn’t be very humble of me either…
While I hate to paraphrase The Philosopher’s Stone of all things, it’s easier to stand up to enemies than friends: nobody likes to be the bad guy, but I’m starting to think that trying your hardest to poke holes in every idea (yours and the rest of the team’s) is the best way to ensure that the only ideas that survive are water-tight. The rest of the team will thank you later (or not) provided you’re constructive.
Not so short in the end – oops! The blog will likely continue to be a little quiet, but you can follow the twitter and github feeds on the right-hand side of the page to see what I’m up to