Global Game Jam 2013 came and went this past weekend, and I was among the throngs of enthusiasts who spent my weekend crafting, cursing, and coding. I participated last year, but this year I decided to go to the jam location being held in my backyard of Indianapolis.
If you're unfamiliar with a game jam, it's a weekend spent developing a game (either digital or analog) given an announced theme. What makes Global Game Jam special is it's a world-wide event, thousands of people take part all around the globe.
At the Jam I met up with a former professor of mine, Paul Gestwicki, who I've developed a few games with while I was attending Ball State University. We quickly started coming up with ideas based off of the theme, which was purely auditory: the sound of a heartbeat. We checked the list of diversifiers, which are ways to make your game more interesting or difficult to design and implement. Some of them are silly, while some of them are quite hard. One from 2012 comes to mind:
9. Kiloplayer
(1024 players or more at once)
The game supports 1024 players (or more) simultaneously.
One of the 2013 diversifiers piqued our interest: pulling in data from an outside source that affected gameplay. At first I suggested using trending Twitter topics. Upon some quick research we agreed that the Twitter API was a bit too limiting (I may be wrong, but it looked like it only allowed us to pull in the top 10 trending topics). Next, we checked out Google Trends. In our mockup, players would input topics that were currently very popular, and then they would input topics that weren't currently trending. We'd calculate the difference and then...well, we didn't have a definitive game design spec but we had roughed in some kind of combat of sorts based on this difference.
But after a few minutes of research, we realized that Google smartly obfuscated the code, and there were not free or easily implementable means of tapping into this data. Blast...So we were back to square one.
We thought for a bit, searched online for a bit longer, and decided to try to find a different data set. To complicate issues for us, we didn't have a dedicated server that we could use to get the data for us, so we'd have to get a little creative. There's quite a bit of easily accessible data out there in JSON format, but we'd need to find a server that was configured to let us wrap a JSON query in a callback function with JavaScript, called JSONP (P standing for with padding, more info here: http://en.wikipedia.org/wiki/JSONP). Eventually we found that Wikipedia's servers would allow JSONP formatted queries. Huzzah!
We knew from the get-go that we'd use Google Web Toolkit, since our collective experience (admittedly, mostly Paul's) with Java & GWT was stronger than our collective Javascript knowledge. Looking back, I think we could have built something very similar with Javascript, though we definitely would've been slower developing with Javascript.
Using a mostly test-driven approach with Java + GWT saved us a lot of time and headaches. There were a few bugs that shipped out with the code, but we avoided many by having our unit tests guide us. I don't know if I'm drinking the GWT Kool-Aid quite yet, though. It was odd that some (most?) of the Java libraries are supported in GWT, but certain key ones aren't - such as java.lang.string. I'm sure there are good reasons for not being able to use it, it's just odd. It was also mindbending to write native Javascript code in Java, which we had to do a few times but not often. GWT as a whole felt like a roundabout way of getting things done, but I'm sure I'd understand the benefits of GWT if I researched it and used it.
One thing I'd look into ahead of time before my next jam is web hosting. Paul has some server space within the Ball State Computer Science Department, but it wasn't ideal for hosting much traffic or proxy'ing the data for our game. At work, we utilize Microsoft's Azure cloud hosting service and many tools connect to it seamlessly if you're developing in the .NET realm. Going from that, to using Dropbox for hosting our game's website was an underwhelming compromise. If Paul and I were able to host the game somewhere (for free), it might have given us some more options, such as avoiding the headache of JSONP altogether. I was a bit surprised that Facebook or Microsoft, who were sponsors of the event, didn't give the participants anything tangible. But hindsight is 20/20, and using more tools brings on more headaches. Perhaps less was more for the development of our game.
It's been about a year since I graduated, and I definitely felt more capable as a developer during this jam as opposed to last year. I would've liked to have done more to aid Paul throughout the weekend, but he has years of development experience over me. Even with a year of experience under my belt, I still have a lot to learn. It was nice to be reminded of that and to watch him work, to see the code grow and shrink quickly. The codebase was small enough that I could understand all of the parts, and getting back into the Red - Green - Refactor test-driven development way of thinking was encouraging. I'm hopeful more collegiate students get to work with their professors like I was able to while in college. My opinion is that novices really need to work with experts, especially in my field.
If you'd like to play the game, titled WikiBeat, navigate on over to the game's GGJ Page: http://globalgamejam.org/2013/wikibeat. Also, check out Paul's take on the weekend.
Special thanks to my wife for sacrificing parts of her weekend to watch our little one while I made a game.
 |
| Randy Savage vs. Punxsutawney Phil, a battle for the ages. Also, Punxsutawney is hard to spell. |
We thought for a bit, searched online for a bit longer, and decided to try to find a different data set. To complicate issues for us, we didn't have a dedicated server that we could use to get the data for us, so we'd have to get a little creative. There's quite a bit of easily accessible data out there in JSON format, but we'd need to find a server that was configured to let us wrap a JSON query in a callback function with JavaScript, called JSONP (P standing for with padding, more info here: http://en.wikipedia.org/wiki/JSONP). Eventually we found that Wikipedia's servers would allow JSONP formatted queries. Huzzah!
We knew from the get-go that we'd use Google Web Toolkit, since our collective experience (admittedly, mostly Paul's) with Java & GWT was stronger than our collective Javascript knowledge. Looking back, I think we could have built something very similar with Javascript, though we definitely would've been slower developing with Javascript.
Using a mostly test-driven approach with Java + GWT saved us a lot of time and headaches. There were a few bugs that shipped out with the code, but we avoided many by having our unit tests guide us. I don't know if I'm drinking the GWT Kool-Aid quite yet, though. It was odd that some (most?) of the Java libraries are supported in GWT, but certain key ones aren't - such as java.lang.string. I'm sure there are good reasons for not being able to use it, it's just odd. It was also mindbending to write native Javascript code in Java, which we had to do a few times but not often. GWT as a whole felt like a roundabout way of getting things done, but I'm sure I'd understand the benefits of GWT if I researched it and used it.
One thing I'd look into ahead of time before my next jam is web hosting. Paul has some server space within the Ball State Computer Science Department, but it wasn't ideal for hosting much traffic or proxy'ing the data for our game. At work, we utilize Microsoft's Azure cloud hosting service and many tools connect to it seamlessly if you're developing in the .NET realm. Going from that, to using Dropbox for hosting our game's website was an underwhelming compromise. If Paul and I were able to host the game somewhere (for free), it might have given us some more options, such as avoiding the headache of JSONP altogether. I was a bit surprised that Facebook or Microsoft, who were sponsors of the event, didn't give the participants anything tangible. But hindsight is 20/20, and using more tools brings on more headaches. Perhaps less was more for the development of our game.
It's been about a year since I graduated, and I definitely felt more capable as a developer during this jam as opposed to last year. I would've liked to have done more to aid Paul throughout the weekend, but he has years of development experience over me. Even with a year of experience under my belt, I still have a lot to learn. It was nice to be reminded of that and to watch him work, to see the code grow and shrink quickly. The codebase was small enough that I could understand all of the parts, and getting back into the Red - Green - Refactor test-driven development way of thinking was encouraging. I'm hopeful more collegiate students get to work with their professors like I was able to while in college. My opinion is that novices really need to work with experts, especially in my field.
If you'd like to play the game, titled WikiBeat, navigate on over to the game's GGJ Page: http://globalgamejam.org/2013/wikibeat. Also, check out Paul's take on the weekend.
Special thanks to my wife for sacrificing parts of her weekend to watch our little one while I made a game.
No comments:
Post a Comment