Spoilers in the Video! Consider Playing LootGrab first. (As of Sept 2010,
Chrome was definitely the best option since Firefox and IE struggled, you can give your smart phone a try too).
2010 Triangle Game Jam game:
LootGrab Video on youtube, or
LootGrab Video on vimeo.
This year brought changes from the Game Jams of past:
First, I moved from the Research Triangle and now work at Google, and Adrienne came too (we've worked together on 5 of the game jam projects now). So, we got some fresh blood at Google to join us and ran a game jam in parallel with the 2010 Triangle Game Jam.
Second, instead of using C# we used HTML5 this year:
Third, you can
Play LootGrab with a click of a button - ridiculously easy compared to all previous Jams where I didn't even bother giving you the gazillion prerequisites required.
Theme and Game Ideas
The theme this year was, "Placing Blocks". Here is my game concept, which didn't make the cut::
(someone pointed out it would be great from the side too, with ballistic arcs.)
We voted up ideas, and Adrienne's one out: LootGrab is about placing down blocks in a dungeon to influence the hero, instead of controlling the hero directly. The greedy guy runs for the closest loot, food, or exit ... without care for monsters or traps.
We figured we'd need a map editor, the runtime, and perhaps a level sharing system online via AppEngine. I was particularly attached to an idea of allowing user contributed game object definitions. Allow a user to upload an image and a snippit of javascript that defines it's behavior. How cool would a mod-able game jam game be? :) That was stretching a bit far though.
HTML5
HTML5 is a grab bag of new functionality in browsers. Some of it is pretty cool (peer to peer networking, local storage, video and audio tags). We focused on two simple components,
canvas 2d to draw and
audio for sound effects.
In my day job I'm working to accelerate canvas with GPUs, as are others at Microsoft, Mozilla, and Apple. It's fairly fast even in software, and LootGrab runs fine without GPU acceleration. In fact, it runs on phones pretty well, such as my Nexus One Android phone. That's pretty cool, all we did to support mobile was to make sure we handled low frame rates without changing gameplay. To do that we used fixed time step gameplay logic (tick based), and just run as many ticks as needed to cover the amount of time elapsed.
Our use of canvas is basically clearing it, drawing a pile of sprites (via sub-rectangles of larger images), and also a line to show where the player is moving. Actually, we have a few layers of canvas stacked on top of each other. Theoretically we could have saved performance by not redrawing non animating tiles - just compositing them underneath.
Adrienne took on audio for sound effects, and did run into a bit of trouble. The sound effects were very short, and had to be padded out to longer audio lengths to trigger properly. Also, multiple instances needed to be created in case the sound was played more than once.
Javascript
Several of us hadn't done anything substantial in Javascript before. Certainly not an object oriented game entity system that can factory from user created levels. Some complicated flurry of activity by Glen, Ian, Nat, and Gregg made that happen. The result could be cleaner, but worked well. We have JSON data blobs, e.g. for the
tile definitions.
Things I loved:
Need to add extra data to your level components of game object definitons? Perhaps only to particular items? No problem! Just start typing. At runtime it is trivial to just check if the data is there and use it if so.
Writing some code and wish you could hang more data off an object? Just set that value! Check to see if it's === "undefined" later and you can pick up your special data easily. Object definitions don't have to worry about implementation details of other systems, and those other systems don't need extra book keeping kept in parallel. e.g.:
try {
ctx.drawImage(this.img, ...);
} catch(e) {
if(this.error_printed === undefined) {
tdl.log("problem with image " + this.entDefID);
this.error_printed = true;
};
Development tools: Logging. Resource load timeline. Immediate mode editor: Hit a breakpoint, and just execute some code at the Javascript console.
Fast iteration time, though C# was great for that too.
Instant continuous "build"! Glen installed an
Auto Reload Chrome extension and put the game up on a projector. Check in some code and see the game running it in 20 seconds. ;) Helps to have a game that can play its self.
Libraires such as
TDL, and JQuery: some helper code for Javascript. It's not so important what you use, but you definitely want to not worry about the minutia.
Not so great?
I didn't use an IDE that had code analysis, and that's a very convenient feature of MSVC. Though, Ian had good things to say about
WebStorm.
Also "classes" in javascript are syntactically very sad, and inheritance to my novice eyes looks
messy. And variable "
scoping" is dicey.
Debugging is functional and GUI, which is better than what most programmers use around my on linux. But it falls short of a modern debugger such as MSVC with C++ or C#.
Also, deciphering a web page via HTML, script, HTML embedded in script, CSS files, and dynamic changes to styles? ... yikes.
Things for Next Time
Would be nice to have some basics already written:
- Factory that will created entities from JSON data packs
- Cleaner audio solution
- Sprite system for canvas
Smaller teams. We had six on this project, and that's a bit much for a game jam game. Several were first time jammers, and several Javascript newbies, so it did really help to share know-how. But we wasted a lot of time getting started, coming to consensus on implementation choices, and stepping on each other's code.
The End
And now I leave you with some screen shots:
And a thanks to whoever oryx is, who created the sprites we used:
