Global Game Jam 2016 Retrospective

Introduction

In January 2016, I participated in my second game jam. I attended the Global Game Jam at Northeastern University in Boston. I'm writing this retrospective a bit late, but I wanted to make sure I made one as a follow up to my last one.

Overall, this event was unsuccessful. But nonetheless, it was a learning experience.

What went well?

Game design:  Once I had found a team, it was full of people who were friends, fairly positive, creative. For most of the days of the jam, we had a sectioned off room that had plenty of whiteboards. We utilized those boards to draft out UI and mechanics. We discussed design and edited to try and account for limited time and resources.

Coordination with other coder:  I paired with a coworker (a goal from my last retrospective) with the coding work for this jam. We both had felt the pain of trying to coordinate coding commits on a game built with Unity3D. We did well to split up the tasks and flag when we were making commits to help minimize the weird conflicts that can be encountered when using Unity3D for a time constrained game jam.

What went wrong?

Brainstorming:  Like the previous GGJ, people were assigned colors to indicate an initial large group. My group initial brainstorming session was led by someone who apparently had game development experience. This leader led us (a very large group) through a sort of rapid fire "say the first word that comes to mind" process. I do not remember my color group was as large as it was this time (easily 50 people). I felt there was no real conversation happening and maybe that was a good thing for 50 people. But I lean towards thinking that the way my brainstorming session went in the previous jam was better, where the group broken in small groups, timeboxed mini brainstorm sessions and rotated groups and repeated; eventually, leading to a entire color group listing and conversation of the best ideas.

Idea submission:  After the brainstorming session, everyone was asked to get in a very (too) large group and share each groups best ideas. We did not do this large group discussion last time. I think a big flaw in general with the early part of the jam was a scaling issue--trying to do something with too large of a group without breaking down into reasonable groups. Also, there was some kind of push to use Slack to communicate game ideas and form teams. I think it would have been good had I or most people participating had used Slack before. But when the proverbial gun shot fired and the words "form teams" was declared, people scrambled. I have a sense that most people did not use Slack for this part. I was able to find a team that already had an idea (one which did not really fit the "Ritual" theme for the GGJ), verbally looking for coders.

Team creation:  I think the Idea submission and Brainstorming sections more or less express the problem with forming teams.

Wireless connection:  I experienced the same network problems I had the previous year. Granted, there is some blame on the configuration of my work laptop, as most people did not have this problem. But again, it was a huge time sink to overcome, both times requiring me to plug into an Ethernet jack. This time an Ethernet jack caused me and my fellow coder to actually base ourselves spatially distant from the rest of our teams--that had a significantly negative effect on communication.

Food:  Meals were not provided this year, as opposed to last year. Instead, a bunch of junk food was available at times. I suppose it could have been worse. But it seems in a short amount of time in a place which is far away from home, having quality food around is pretty important, as there is a temptation to ignore this vital human requirement.

Art integration:  My team was fairly large but mostly comprised of artists. They were pretty good 3D artists. Unfortunately, the 3D demands of this project definitely taxed me and the other coder. Coding and 3D model design both took a lot of time. Although my plan to use cubes as placeholders for 3D models to be integrated later was a good idea, it did not work out in practice. Integrating these models late in the process proved to be critical. There were some issues with animation and our coding skills did not prepare us for troubleshooting such seemingly Unity3D hangups.

Sounds & music integration:  Biggest issue here was that we never integrated the sound and music that our musician created. When visual asset integration failed, there was no priority given to audio. It was just a matter of time and resources. The art integration process we used made it appear as though the coders were indeed a bottleneck.

Experiments & goals for next time

• Everyone have a GitHub account:  This experiment was one from the last retrospective. I brought up the idea but it seems people who are not coders do not see value in this idea. How do I convince people otherwise? Require that everyone knows how to code? As in, build a team mostly of coders who can create assets--hybrid roles?
• Ask artists to integrate assets:  Related to the GitHub account experiment. It would be nice if artists could add their art to the game. Even if this addition is just ensuring that the art is in the game and the game loads it--not necessarily applying it to game elements.
• Integrate assets as soon as possible:  From both game jams, I experienced weird chain reaction effects from integrating assets, such as scene scaling and translation problems. It is probably best to plan and deal with such issues earlier than later.
• Distributed & multiple roles:  This experiment was one from the last retrospective. I think I have pretty much expressed this idea in the previous experiments.
• Stay away from Unity3D:  This experiment was one from the last retrospective. It is also increasingly nearly impossible to do when joining a jam with strangers. I see two ways of supplementing this inevitability:  1) Ensure that a Unity3D based team has lots of coders who know that framework well and way better than me. 2) Only team with people you know personally, who all know an alternate 2D framework (like Phaser).
• Make a simpler game:  The game idea was seemingly simple, but it had a lot of elements. In fact, it was pretty much an attempt to make something that could be evolved into a MOBA at a later time. This goal is easier said than done.

Conclusion

On the final day, we all agreed to surrender to the pressure of the game jam and call it quits. We did not finish a game. Feeling defeated, we all went and ate and drank at a local bar.

I am already seeing patterns in participating in game jams. In order to have a successful game jam, it is clear that repeat problems need to be overcome. I do not think I will be participating in the next GGJ at Northeastern University. If anything, I may pick a different location; hopefully that would solve the network issues.

Global Gam Jam 2015 Retrospective

Introduction

In January 2015, I participated in my first game jam. It was also my first live on site game jam. I attended the Global Game Jam at Northeastern University in Boston. What is special about this location is that it is the domain of Susan Gold, one of the proprietors of the Global Game Jam. I intend on going again next year in 2016.

The company for which I work has over the last year or so has made the attempt to adopt a more agile software development approach. I figured a live on site game jam would be a good opportunity to either learn or utilize some agile skills. That was the intention. Creating a game in 48 hours seems like an endeavor that requires rapid development. However, in the end, my team's largest mistakes were not following agile practices.

I've been putting off writing a retrospective. So, here I go.

What went well?

Preparation: I was meticulous with preparation. After registering weeks in advance, I drafted up a spreadsheet checklist of various things to acquire, take, and learn before going to the game jam. In some ways, it was like preparing for a software project at work. In other aspects, it was like prepping for a sleep over or camping trip. Apart from lots of tech and tools, a good portion of prepping was practicing various common elements of game development with an intended game engine, Unity3D, just to make sure I knew them.

Team building:  In general, a large group of predominately computer and video game geeks have trouble meeting strangers and forming teams. The jam site was packed with many new faces. It was encouraged to team up with strangers rather than coming with an already assembled team. I didn't know anyone, except for a coworker that I asked to attend.

As a way to overcome this situation, the jam site put everyone in one of about six large groups. And from there, asked the group to participate in some planning exercises. In the end, my team consisted of seven people which I believe all originated from my larger preassigned group.

Brainstorming:  We spent about a half hour brainstorming game ideas centered around the Global Game Jam theme for that year ("What do we do now?").

We were told to brainstorm game ideas for about half an hour. What we did resembled speed dating. We all broke up into smaller four people groups. We decided to spend 4-5 minutes pitching and sharing ideas. After that time expired, we randomly dispersed to form another small group and repeated this process until the entire block of brainstorming time was up.

I actually ended up being the person which used my phone timer to time-box the small group brainstorming sprints for the larger group. It worked very effectively, as a lot of game ideas were generated during this time.

At the end of the session, we made a list of our favorite ideas on a whiteboard to go over with the entire group.

I was very intrigued by the way ideas were passed around, cross-pollinated, and evolved. In fact, by the end of the entire game jam, I saw splinters of game ideas which I contributed in a lot of the final games.

Workspace setup:  The game jam took place on an entire floor of Northeastern University's library. This floor had tons of islands and tents with many workspaces with extra monitors and / or iMacs. Our group was fortunate to secure a 2 x 3 person workspace for the entire duration of the game jam. It was there that we were all able to work in a centered location. Face to face communication provided for quick communication and feedback, as well as fostering a sense of team and togetherness (which kept the team positive through pretty much all of the jam).

Manager role:  One of teammates had a role which was fairly under-utilized with our particular game:  writer. This individual shifted their role to be more of a manager (something that was close to their profession). This person communicated between present and non-present team members and facilitated the acquisition of art and other assets.

On the final day, energy was low. Our manager was one of the few team members which managed sufficient amounts of sleep. During the last stretch, particularly during the submission and finalization phase, our manager kept us together and on point.

What went wrong?

External game coach:  The intention of the game jam site was to have an experienced game developer initially coach each group to make sure they were on a good path. Our coach, who shall remain nameless, set us on a bad path. This person had a tendency to insert their ideology into our more favored game ideas. In the end, the game idea we went with barely resembled any of the nice ideas initially brainstormed.

I read a game developer's blog concerning some game jam advice that now really resonates with me:  don't let anyone else (outside your team) tell you how your game should be. They aren't going to be the ones working on it. Your game is for you and your teammates.

Wireless connection:  Northeastern sent out instructions well ahead of the game jam date to acquire a temporary user account to be able to use their network. Despite doing this, although I could log on with one of the provided desktop computers, I spent hours on the first day without network access and trying to track down IT to remedy the situation. The person I found to help me (and a few others who had my same problem) never did fix it. Fortunately, I brought a very long Ethernet cable--I used it for the rest of the game jam. I had to unplug one of the provided workstations and run my trip hazard away from my team's table.

Remote teammates:  One of my teammates decided to phone it in, during about 90% of the game jam by working from home. Unfortunately, this individual was the only person designated to create art. The claim was that this person had their work cut out for them and that they would do best by isolating themselves to the privacy of their home.

The problem with this approach was communication. We went several hours without even seeing a sample of art. Our team's impression was that this person wasn't actually working on the game jam. Given such a short amount of time to produce a game, all members need to be present for the majority of the game jam.

Art integration:  Art came late during the session. Getting the art late required that the dimensions and alignment of objects in the game to be reworked after much of the work had been done. In some cases, this caused some regressions due to some quirks with the Unity3D editor combined with some novice coding. It was a set back that caused at least an hour of time.

An idea I put forth early but my team generally rejected was to have everyone on the team have a GitHub account, so changes to the project could be made and submitted by all members. The alternative was that art (and other assets) were channeled through email and through certain individuals and eventually to one of our coders. It caused a bit of unnecessary overhead and bottle neck.

Sounds & music integration:  We were fortunate to have a very skilled musician on our team. My only criticism was that in combination of other complications with asset and code integration, sound effects were such an afterthought, most of the elements in the game were not accompanied with any sound effects--just music.

Software integration:  Free GitHub projects work great for a 48 game jam. However, Unity3D, even with some tweaking, does not lend itself well to collaboration--auto-generated scene files and the like were often conflicting and resolving those conflicts manually was not always straight forward.

Distribution & faith of skills:  The team breakdown of seven people was:  writer / manager, artist, musician, coder, coder, coder, coder. The array of coders represented a range of experience both with video game development and software development. We perhaps had too many coders and not enough artists.

Being mostly strangers, we did not have much to base our confidence in each other's skills. Our unvoiced approach to work around this dilemma was to develop entirely separate mini-games. There was nearly no functional relationship between these mini-games. It didn't really feel like a complete game.

Game submission:  During the final hours of the game jam, it was time to submit our game to the official Global Game Jam site. Our team worked up until the moment, furiously trying to pack in working code and assets. After we finalized our work, we were uploading our project with nearly the rest of the world of jammers. The system just couldn't handle this stress--and it was stressful for us.

Experiments & goals for next time

• Come and team with coworkers:  I enjoyed meeting new people during my first game jam. However, having work experience with other people, particular with software projects, should be a big boon against the "faith of skills" problem.
• Everyone have a GitHub account:  Regardless of role, everyone should be able to contribute to adding & modifying project files. This approach attacks some of the "integration" problems.
• Distributed & multiple roles:  If there are not enough people on the team or just not enough people taking on certain roles, it may be a good idea to have most everyone on the team take on a major and a minor role. For example, a coder could also be an artist or a coder could also be a musician. This attacks the "distribution & faith of skills" problem as well as the "assets integration" issues.
• Only team with people with a strong interest in creating a game:  It's questionable whether our artist spent the same amount of time as the other present members on our team. Being in person at least creates expectation and conditions which kept us working on the project. Of course that's the point of a game jam--to apply pressure, expectation, and synergy to actually create a game. It's hard to anticipate this problem. The only thing you can do is team with people you know and you have a sense that they are willing to put in the work for the entire game jam. This attacks the "remote teammate" problem, in the least.
• Only as for guidance if we need it:  Our "coach" was kind of self-invited. We had a lot of good ideas and at the time, I don't think we had decided on one yet. It was just a matter of time. I think having a game jam under our belts should reduce the need of a coach.
• Stay away from Unity3D:  Yes, I'm saying it. This beloved game environment is not conducive to collaboration, at least not for 48 hour / novice game development. The code conflicts it created were devastating. It's better to use something almost entirely manually source driven, such as HTML + Phaser.
• One game:  The team should focus on making one game instead of a handful of incomplete games. This goal should be attacked in multiple ways:
1. Focus the game-play around one or a few mechanics or genres.
2. Break down the game into features, stories, and tasks that can be completed by any members.
3. Break up the code into separate files and modules. In this way, there will be more opportunity for collaboration between coders and such. People will be less likely to step on each other's toes and create code conflicts. Come to the game jam with a project template which is ready to be populated by all the team members.
• Get the game working early:  The term that's used to define getting a software project to this point is called "the critical path". The team focuses on the most essential portions of the project first to get something that is working and playable. This should mostly happen on the first day. It can involve incorporating placeholder assets, using non-elegant code solutions as proof of concept, and even borrowing code. Having the game always in a working state means the project is always almost done, in a way. It provides for early feedback and iterative improvements until it's time to call it quits. This goal partially attacks the "game submission" problem, in that it's easier to say the game is done early and thus submit the game early as well. This approach also plays a part in the "one game" goal.

Conclusion

I'm looking forward to the next Global Game Jam. I hope to bring with me the experience from last year to the next. No doubt things won't go exactly as hoped. Perhaps things that worked really well last time won't do so well this time. Hopefully, the overall experience will be more rewarding and successful.