We had 21 people register, almost all of whom showed up. There were several people who came on Friday but then didn't return, unfortunately. I have seen this each year, and I think it tends to be people who are interested novices. They don't know how to move from idea to implementation, and they are not familiar with the little failures that are to be expected along the way. I take a laissez faire approach to site organization: I don't manage teams or themes, but instead I encourage people to use the whiteboards around the room to gather interested people. I've thought about whether I should include more didactic interventions, but the truth is that teaching is already my job: the jam is about jamming after all. I would never kick an amateur musician out of a jam session if they wanted to participate, but I would also not be surprised if they left. Perhaps it sounds a bit harsh when I write it out, which makes me think I need to work on better packaging for my pragmatic philosophy.
This relates to something I want to share about this year's keynote. I had a sense that none of the four speakers were actually talking to my audience: mostly novice jammers. The thoughts they shared might resonate with people who already know what they are doing, but that's not helpful if you have no grounding. Let me pick on one particular example. Rami Ismail was the most on-point of the three speakers, but he made a claim in his presentation that you cannot do a game jam wrong. I firmly disagree: there are many, many ways to do things wrong. Here are several: being an unpleasant team member, for example by refusing to compromise on your ideas or by not keeping your commitments; focusing on accidentals such as title and credits screens rather than the essence of the game; taking too long to get to a minimally playable state; thinking that ideas have value rather than implementations; not considering packaging or deployment until just before the deadline. These are the kinds of mistakes that I have seen jammers make and, more to my point above, that I see novices make in my game design and game programming classes. In fact, I think it's much easier to do it wrong than to do it right—regardless of the quality of the final product. I think a rhetoric that says you cannot do things wrong sets novices up for mistakes and frustrations.
At the end of the jam, we had four playable projects. There were two more that were "done" but not uploaded, one of them because the jammer disregarded my and others' advice to stop trying to add features and instead to figure out how to package and upload his work, and the other because he could not make it on Sunday and didn't get around to uploading his.
Last year, my oldest son came and participated in the jam, making two games of his own in the time it took me to break one. This year, I encouraged him to come again, but I told him that I really wanted us to work together on something. He actually started working on his own anyway right after the theme announcement, but once I reminded him that I really wanted to collaborate, he was up for it.
We struggled to turn the theme ("What home means to you") into a game idea. One of our best sketches was of a game where the family stands around the counter, waiting for Mom to look away, reaching out and grabbing tidbits to eat before the siblings can. I imagined we might even use a polka soundtrack and be able to name it after the Shmenge hit, "Who stole the cabbage roll?" As we kept talking, though, we somehow pulled inspiration from Terror in Meeple City and the idea that kaiju have a home as well... and there are people in it, and we don't want those people there. This was the idea that became Kaiju Homecoming.
We built a minimally playable version in Unreal Engine just to make sure the pieces would fit, just dropping a plane onto some cylindrical columns and throwing a ball at it. We laughed from the get-go. I asked my friend Emma if she could make up some digital meeples, and so she and her friend Jessica provided these models. The next day, my son worked on some more original art for the floors and he did all the level design. We had to tweak the level a few times because we couldn't get the floors to stack nicely on the columns in the UE4 editor. Playing the game, you can see the physics solver create wobbles and even occasional collapses as a result. There are probably snapping or simulation sleeping settings that we could use to fix that, but I am really happy with the look and feel, given our constraints. My son was also in charge of all the audio direction except for the soundtrack: I found the music on Kevin MacLeod's site, and he reviewed sound effects using the free weekend access to SoundSnap. We had the game mostly finished on Saturday, and because of other family obligations, we only had a few hours to work on Sunday, right before the deadline. We got as much polish in as we could, and the game was complete.
The game runs best as a Windows 64-bit executable, and you can download the project for Windows from the Global Game Jam site. We also produced a Web build that I've hosted on GitHub: it's more accessible, but lacks the performance of the native version. All the source code and assets are in a repository on GitHub as well, although we actually used Perforce Helix for version control during development. Finally, for those who want the quick overview, I recorded this short gameplay video:
It was a fun weekend jamming with my son and seeing what the other jammers put together. I've started some conversations that might lead us to a different location for the 2020 jam, but that's a long way off to worry about planning. Now, I need to return to all the tasks that I put in the "I'll take care of this after Global Game Jam" bin.
No comments:
Post a Comment