Thursday, December 22, 2016

Global Game Jam 2016 Retrospective


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.


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.

Sunday, July 31, 2016

Pokemon Go Nearby Radar

Pokemon Go's Nearby feature is quickly fading away. When it released in the US, each Pokemon was given a "steps" icon to indicate how close it was to the viewing trainer.

Within about a week of the Pokemon Go craze, the step indicators appeared to go on the fritz, where all Pokemon appeared at a distance of the highest and most ambiguous value of 3+ steps. Adding to its pile of obvious Pokemon Go bugs, most people referred to this issue as a bug or glitch.

After a few days and the relatively trivial nature of a distance formula, many realized that this problem was not a bug, but a coping mechanism to handle the excessive load on the application's servers.

With the 7/31/16 version 0.31.0 update, this notion has been cemented--the steps indicators have been removed. However, the Nearby screen remains.

Over this time, people have pointed out that the order of Pokemon listed in the Nearby screen is listed in closest to farthest, like written text from top left to bottom right. What is the value of this representation? If nearly all Pokemon are at a long distance, it's nearly impossible to track them down through diligent walking and triangulation, as new Pokemon are added to the list, its order can shift drastically.


Personally, I think the lack of adequate distance indication makes the current Nearby screen useless. It's nearly a vanity and perhaps just psychological bait to elicit a "Ooh, a Pikachu. They do exist!" response. People walk around a little bit, fail, and then give up and move on to the closest Pokestop.

Granted the distance puzzle makes people walk around more--more or less the motive of "Go". Given what we've seen so far, where is this feature going? Is this update a step in its slow deterioration. In the next update, is it going to be gone? Maybe the step indicators will be restored once server load stabilizes.

The problem I see is that the Nearby screen was never done well from the beginning. A flat list is not how people think of proximity in a 2D space. If providing distance measures is problematic for these servers, what information is actually provided?

Perhaps instead of distance, trainers can be provided a direction or bearing. I made a mock-up of this idea:

I believe this approach is a healthy and reasonable compromise to provide meaningful information without giving away too much. One may have to walk around for quite some time but there is reassurance that these Pokemon are obtainable and that the Nearby screen is helpful. All the while, people would still be walking and traveling about their community.