Saturday, February 2, 2013

Global Game Jam 2013: WikiBeat

I spent last weekend at Global Game Jam. Last year I was at the VBC, and I took several students with me to Columbus, where we had a great time. This year, I brought two students from my game studio to the Indianapolis site, hosted at the Art Institute of Indianapolis. We arrived in plenty of time to chat with some of the other jammers, many of whom were students from the area, including one other Ball State student. Closer to 5pm, we moved over to the computer lab for the keynotes and theme announcement.

The theme—in case you didn't click the link before or haven't heard—was a heartbeat. It was announced with a bit too much melodrama, but I congratulate the organizers for identifying a universal theme. I want to say a bit about "theme" here, though. Last year's theme was the ouroboros, and while many game ideas explicitly included snakes and tails, there was a lot of discussion of metaphorical interpretation. This year, everything I heard had to do with hearts quite literally. This was disappointing. One of the primary reasons I took the team to Columbus last year was to meet up with Ian Schreiber, who is one of the GGJ organizers, and I remember him stopping in toward the end of the jam and saying something like, "There are so many damned snake games!" Clearly, as a member of the theme selection committee, he was hoping for metaphorical interpretation. I wonder what he thinks of all the heart games created this year?

There were a few reasons that I wanted to go to the Indianapolis site this year. It was organized by the Indianapolis IGDA, of which I am a member, although I don't make it to a lot of their events; this made it a good opportunity for me to go see some friends that I only see a few times a year. I have some other friends in the city that I was hoping to meet up with for lunch, but sadly that didn't come together due to a communication breakdown. I also have several alumni in Indianapolis, including folks I worked very closely with in 3:15 Studio and Root Beer Float Studio. Josh Hurst was the only one who came and participated in the jam, but I am glad he did, and we were both eager to work together again. (Here's his blog post about the weekend.)

When Josh and I heard the theme, our minds both went to the same place: hearts and babies.1 We figured there would be a host of games about hearts and babies, and so we decided to draw inspiration from the diversifiers. We had both read through them before and were intrigued by this one:
The Truth is Out There
Some external real world element, such as weather, time of the day, etc, affects gameplay. It MUST affect gameplay and can’t be only a scenario element.
After the theme announcement, we started brainstorming data sources and gameplay elements. We liked the idea of a word game in which the player has to know what topics are currently in the news or trending, and with this inspiration, we started exploring available data sources. All the jammers were in one crowded room, so Josh and I went to one of the other rooms for our experiment. As a result, we missed some of the discussion and pitches, but we were already on a good course that we knew required some serious investigation.

We were really excited to try to get data out of Google Trends, my thought being that popularity and unpopularity are the oxygen and carbon dioxide of culture. Unfortunately, there's no public API for it, despite there being noise about a release as far back as 2007. Twitter required accounts that we didn't want to tinker with. Turns out, a project of mine had just recently been covered by the AP, and so I was inspired to see if they provide public RSS feeds, which they do. In fact, they're conveniently separated into eleven categories.
Plan A: AP RSS
We talked about doing multiplayer on mobile devices, but that felt both ambitious and limiting—although we both had Android devices, we decided we'd rather have the game be widely playable than customized to one mobile OS. We ended up with a sketch of a hotseat multiplayer design for the Web, with the plan to add simple networked multiplayer if we had time. We chose GWT, in part because I've really wanted to build and ship something with GWT for ages, and also because we knew it would simplify adding App Engine networking should we have time to add that.

At this point I will note, in case it's not already clear, that neither of us are Web developers, and we were victims of second-order ignorance, heading for a brick wall. We didn't know that at the time, of course, so we got to a happy place and headed home/hotel for a good night's rest. We both have infants at home and had just finished stressful weeks at work, so a good night's sleep was certainly in order.

The Pyramids, home of the AII, early in the morning
I got up early the next morning and was back at the AII by 7:30AM. Two bleary-eyed jammers were in the computer lab, and everyone else was asleep. You can't keep a morning-coder down, so I set up shop and got to work. Josh arrived a little later, and by midday, we had all of our RSS parsing logic done and had turned to prototyping the interface. We had been writing everything in Eclipse using TDD, and at this point Josh suggested that we should get the end-to-end prototype running in the browser. I told him I was not worried about it, but a moment later realized he was right, and so we slapped together a simple UI.

Maybe you've heard of the same origin policy. It's a security feature in the browser that prevents scripts from connecting to domains other than the one from which they were loaded. The implication for us was that our Javascript in the browser, loaded from our server, could not open a connection to the AP RSS feeds. It took us hours to realize the problem, and when we did, there was much forehead-slapping. We found some documentation about workarounds, but none seemed to work.

After a bit of investigation, we decided we'd try JSONP, which appears designed specifically to circumvent the same origin problem. It requires a server to support it, and the AP doesn't, so we began to look for similar kinds of data sources. We spent a few hours tinkering with different servers until we landed upon the MediaWiki API supported by Wikipedia. This API is fantastic. Everything you can do through the browser, you can do through the API. Based on the data we could get, we retooled our design so that the player would get points for identifying Wikipedia pages with the most edits in the last thirty days. It's not quite the same as "trending", but certainly, controversial and newsworthy topics see a lot of edits, so it's in the same spirit.
Plan B (or C, or something): Wikipedia Revisions
We set to work retooling the design and decided to abandon hotseat in favor of a local high score table, which was easily implemented with GWT's cookie support. A single player can play to beat their high score, and one can easily share this score with friends to get ad hoc multiplayer, without our having to implement multiplayer as a mechanic. This observation actually emerged from testing, where Josh and I informally challenged each other to beat scores when testing the API access.

Somewhere in the middle of the afternoon, we needed to go get some lunch, so we went down the street to Famous Dave's. I haven't been to a Famous Dave's since visiting my brother in Madison around fifteen years ago. Our waitress was fantastic, and I enjoyed a generous lunch platter along with a Wee Mac. It was so good that I took a picture.
Southside Rib Tips at Famous Dave's
By the end of the day on Saturday, we had and end-to-end prototype working in the browser, but in dire need of some beautification. We called it a night around 12:30am and headed back to the hotel for a few hours' sleep.

Here's an interesting phenomenon: If you have a newborn at home, and you worked all week, and you programmed from 7:30am until 12:30am, and you don't set an alarm, ... well, you can't really guarantee when you will wake up. I woke up a little groggy and looked at the clock, surprised to see that it was 9:30am. We missed the continental breakfast, but at least we were well rested! I grabbed a yogurt and coffee, and Josh ran out for bagels, and we were back at the jam by 10:00am.

Sunday, we officially named the project WikiBeat, and we worked primarily on the high score support and user experience. The best contribution was Josh's idea to turn each guess into a link to the relevant article. It's obvious when you take a step back, but the thought hadn't crossed my mind. We made one blunder with about two hours to go, where we decided to modify how the player's guesses were presented, which meant altering a core data structure that was also part of the presentation layer (yeah, I know). As a result, we discovered later that there is an error where after your first game, your score may or may not be computed correctly. Sorry about that.
Raised by a cup of coffee
After all the submission deadline, there was some time for demos to show results to the other local jammers. You can see all the other games that were created at the GGJ page for the AAI site. I'll point you directly toward the other two that my students created, aMAZEing Embolism and Distance Makes the Heart Grow Angrier. Both of these games were spearheaded by my students, who were able to form teams around them. I like to think the work we've done together on game design and game programming helped. As predicted, all the other games included hearts literally, and when I presented WikiBeat, one of the few questions was, "What does this have to do with the theme?" I briefly explained what I said above, about literal vs. metaphoric interpretation, but since I think Josh and I may have been the only ones who discussed metaphoric interpretation, I suspect this may have been lost on the rest. I suppose that's the flip side of my and Josh's separating ourselves from some of the rest of the pitch process, that our ideas were a bit insular.

I had a great conversation with my students on the way back to Muncie about game design, game development, and jamming. I think it was a good learning experience for them, and I know it was for me. It took me a week to start this post, and it took me most of the morning on a day off to write it. Regardless, I enjoy the process of pulling all the details back into my head and getting them into a coherent narrative. I am reminded of a comment that came up the week prior to GGJ: if game development were easy, people would do it all the time. Turns out, it's really hard, and that's what makes it such a rich intellectual activity.

Thanks to the Art Institute of Indianapolis for hosting and providing subs on Friday night, to Indiana Uploaded for the pizzas on Saturday, and to all the global partners and sponsors. Extra special thanks to Thomas Marshall (Puca Studios) and the Indianapolis IGDA for organizing the event.

Here are the GGJ page for our game and the playable version of the game. Global reported high score so far is David's 301 (in the comments below). Post if you can beat it!

1 On the way home, I talked to my students about the design process. When I told them that Josh and I assumed there would be a lot of "baby" games, they had no idea what I was talking about. For those of you who don't have children (or maybe missed this experience), there is an amazing moment early in the pregnancy where you can hear the little person's heartbeat. It's well before all the sonograms and checkups are possible, and it's an amazing experience. Hearing a heartbeat makes me (and Josh, and probably lots of other fathers) think about that moment.


  1. There may be two very good reasons for teams taking the theme literally.

    Firstly, the team selection process was scheduled to take place 30 minutes after the theme was revealed. This is hardly enough time to come up with a coherent game idea let alone ponder metaphorical interpretations of the theme. That you and Josh had already decided to work together before the jam, meant that you wouldn't need to be part of that process. I'm not sure how team selection worked at other GGJ locations, but, given that I was told to expect this format, I assume it is by similar process.

    Secondly, prior to the team selection process, you are pitching your ideas to as many people as you can talk to. At the beginning of this process I had 9 ideas down on paper. Six were literal interpretations and 3 contained abstractions of the theme (center of the universe, earth mother, and something else that escapes me now). By the time the call for the final pitches went out, there was one idea that resonated more than any other. This was "Distance Makes the Heart Grow Angrier." Had I chose to make a game myself or had a pre-selected team, who know what I would have made. Because I had to worry about whether my idea was popular enough to entice people to jot their name down next to it, I didn't get that freedom. In a way it is similar to the way AAA game publishers choose which games to make, just that the audience I had to win over wasn't composed of end-users but developers.

    In the end though, the theme is the least important part of a game jam in my opinion. It is merely a catalyst. As long an interesting game comes out of it, regardless of how literal it is, then it is a success in my opinion.

    1. I do not know what the "norm" is for GGJ team formation, or if organizers are given guidance along these lines. The experience in Columbus was ad hoc: after the theme was announced, everything that happened was from and of the community. The organizer was there to help us get our software keys and find the bathroom, but he hadn't set up any formal structure beyond that. The result was that sketching, pitching, revision, and team formation happened organically around ideas as they developed. This worked well, in my opinion, since some ideas took longer to gestate than others, and people naturally roamed around and found teams. (Maybe a reader who was there can clarify if I remember this wrong, since I didn't really take notes about the process, and memory can be imperfect.)

      You know my proclivity when it comes to formal structure: do the minimum necessary, but no less. In fact, I originally had a paragraph in the post about this, but I took it out, as it became more about event administration than my experience at the Jam.

      So yes, I agree that in this case, the structure probably inhibited creativity, though perhaps it was deemed a necessary sacrifice in order to get teams together. I think it's fair to say that the game design skill of the average participant was quite low: most were undergraduates, and few gave any indication of having made anything in the past. This is fine, of course, as GGJ is a great opportunity for them to learn. However, novices require rules, and I can imagine the organizers--knowing the number of novices--decided that structure was necessary. On the other hand, some of us have been working in games for years, and we tend to approach the whole thing from a different perspective. Rules help the novice, and rules inhibit the expert.

      If I keep typing, it will end up as a lecture on the Dreyfus Model of Skill Acquisition, so I will just stop here. ;) Thanks for commenting!

  2. 301 ^_^
    You can tell I ran out of ideas in the last few seconds by my last few words and their score
    Water - 6
    love - 3
    Elm - 1 (yes, the elm tree, and apparently someone has updated it recently)

    1. Wow! I'll edit the post to reflect this.