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.

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.

(Source: Forbes.com)

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.

Icons to Buttons

Every once in a while I come across some text at work where the term icon is being used in place of a desktop shortcut; the context being that icons are being created on the system's desktop.

Being how I am, I immediately think how silly it is to make this mistake--I am a stickler on semantics and I can't stand lexicon branding (eg Kleenex for tissues).

Perhaps the term icon is colloquially accepted for the thing that appears on a modern & conventional computer virtual desktop. Maybe I'm being harsh. I can't think of many times when I've had to refer to these things that appear on your desktop. And maybe I would end up telling someone to "press the blank icon".

I think of icon as an image used to convey or recognize something or an intent. What is created on the desktop is something more than just an icon. I'd say they have icons. Again, the software engineer in me has to make the distinction between is a and has a relationships.

The most recent time when I saw this misnomer, I decided to Google define:icon. The result was pretty much what I expected:  the use of icon ramps up around the popularization of the personal computer (circa 1980).

But around 2000, the use of icon starts to decline. Why is society starting to abandon this term now? Given the misnomer noted previously and the correlation to computers and the modern computer desktop, did something change about computers around this time to influence this change?

First thing that came to mind:  the iPhone; the new wave of mobile computing.

Below is the Google Books Ngram Viewer of icon crossed with iPhone.
  The graph supports the theory that the diminishing usage of the term icon is eclipsed by the mobile paradigm spearheaded by Apple's iPhone.

So, that leads me to my next question:  what term are people using in place of icon, particularly in the context of mobile computing?

Button?

Although the term button is also subject to the computer influence as icon, around 2000, increases in a similar fashion to the decreasing of icon.

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.

Response to GamerGate

Gamers--it's a large group of individuals who associate with a culture that has, for a long time, not been accepted as part of the social norm. It comprises of men and women who tend to score very high in video games but do not perform very well in social situations. Games have taught this culture to get frustrated at, hit, and manipulate the things which are deemed antagonistic, rather than flex a more civil muscle to find a social based solution that is not destructive.

As the use of computers and gadgets has become common place, the moniker of 'gamer' applies to nearly everyone. Suddenly, the same demographic that was always picked last at school gym are now part of the mainstream.

Enter feminists into video gaming. This classification of people are challenging video game narrative much in a same way a community challenges a government. Everyone should have a right to express their perception of a situation which affects them negatively, as a means to change this situation, regardless of the validity of such a claim.

The claim put forth by feminists like Sarkeesian is that, although many women play video games, women in video games are not represented in a manner which fairly and truly caters to female gamers. In other words, women are the last to be picked at video game gym.

My experience as a computer using geek growing up was very much like explained:  I was a sort of social outcast at school. But there were always others like me. I recall (what is likely a normal phenomenon) that other social outcasts at school would bind together and socialize. There were the computer nerds, the math nerds, the band nerds, the drama nerds, the D&D nerds, the card playing nerds, and others. They were of varying ages, races, genders, sizes, and so on, but they tended to have one thing in common:  they were gamers.

My experience is why GamerGate saddens me:  it's a fomerly rag tag group of unique individuals now fighting to exclude outside thought and defend the norm.

Android L and the disappearance of the smart phone

Polydevicism is a term I coined in a 2010 blog entry, depicting the ever present array of personal computing devices which surround us in our daily lives. More specifically, the blog entry mentions how all those devices will be satellites to one primary device.

That primary device used to be a desktop computer. Now it is our phone. Soon, that device will be as non imposing as a credit card that is carried in a wallet--the disappearance of the phone as we know it.

Google announced the code name of the next version of Android called "L" at their yearly IO conference. A huge underlying theme of IO 14 was the integration between devices with an emphasis on "casting", like with their successful Chromecast device as just one of the means of doing so. If you connect the dots between everything shown at IO, it paints a paradigm shifting picture where the phone is made transparent.

I'll explain:
1. Google showcased Material Design; their attempt at a universal approach to UI that scales to any device, from watches to car displays to desktops to TVs.

2. Chromecast is an avenue in which anyone with a phone can walk up to an enabled TV and start viewing their own personal media:  videos, music, pictures, music and likely soon news feeds, calendar, and documents. Casting doesn't have to be one directional; I suspect video conferencing will follow (think Google Hangouts on a TV).

3. To bounce off my last idea in #2, it was rumored before IO that Google will merge Google Voice and Hangouts.

4. Google announced Android Auto; an Android interface for a car. Think of Auto as the template and basis of my argument. The driver's phone will cast to the car, allowing for the car to act as a controller for the phone. In essence, the car is a phone, complete with speaker, microphone, and display. It will undoubtedly allow the driver to place calls.

5. IO also showcased Android Wear and more specifically an Android wrist watch. It is able to instantiate phone calls with the aid of a smart phone. Things like calendar events and even the time can be viewed from the watch. It used to be something to carry a pocket watch until wrist watches replaced them. Modern cell phones are like pocket watches.

6. Google also showed how a Chrome OS enabled computer will be able to run applications installed on the user's phone. The phone will communicate with the other computer, relaying notifications like when the user receives a call. I suspect making calls through the computer via the phone (like with Auto) is inevitable.

7. Google showed both the situation where A) the proximity of a Wear device unlocked a smart phone. B) the presence of a phone unlocked a Chromebook without the use of a password. A password is just a way of proving identity.

8. Chromecast will be getting some form of user permission system, where the owner can allow for some people to use their device instead of the current policy where anyone on the network can cast. I suspect permissions will be broken down into various tasks like viewing videos, making calls, etc. The user identification via device from #7 will play a role.

All the points I made have 1 major implication:  the user does not have to take their phone out of their pocket or purse.

So, why does a "phone" require a display or speaker or microphone for that matter? All it really serves is a network connection.

Imagine a world where we can walk up to any display and access our "cloud data". Your computer stays tucked away while every display feels familiar as though it is your own. For example, ATMs will just be a cast of your computer's banking application. Drive through menus will display your favorite items as well as offers specifically for you.

Google will try to get microphones, cameras, and in some instances, speakers into or around every display. We'll see how well our social paranoia of surveillance lasts as we cast our hearts away.

Virtualization from my life seeping into my dreams

So, yesterday was officially the first day of Spring. And the weather seemed to agree. I came home from work and cooked my usual staple of fish for dinner. Because the weather had not been so nice for some time, my partner and I decided to take a walk.

On the walk, my partner told me about a recent trip to New Orleans, focusing on an encounter with a stereotypical Voodoo magic fortune teller. The subject of horoscopes was brought up and I had asserted the notion that I am considered a Pisces (represented by fish).

It was good to come home as these recent weeks have been pretty stressful at work, as the software company I develop for is approaching a release deadline.

At home, in my spare time, I've been designing a fairly sophisticated software framework, where both computer programming language and system architecture are not only abstracted on one level, but in some situations, on two levels (namely, Javascript to native C/C++ to/from Java). Not to get too technical, but this process requires each software layer to interface the next with essentially what are functions that act as translations just like one person often requires a translator or dictionary when abroad in foreign countries.

I had a strange dream last night that seems to have tied these past events together. Much of the dream was seemingly inconsequential, involving me interacting with the various different people who facilitate the transfer and ultimate delivery of products at a large big box retailer or grocery store. First I drove around, early in the the morning, to meet up with the truck drivers who shipped products. There was some purpose in this encounter, but it is hazy. Later, I remember being in the store, wanting to make some kind of purchase or trade, but I recall having some minor difficulty with such.

The dream had a very abrupt culmination and realization not too soon before it ended. I finally acquired two things: a large quantity of fish that had been frozen in stasis (as in, ready to be thawed and to resume living) and a typed white on black (aka carbon paper) of a rather extensive specifications sheet.

The spec sheet listed the syntax for binding all the biological functions of that particular breed of fish, allowing them to be programmed via a computer application. I remember seeing lines that looked like Java JNI function declarations with titles like "..._fish_heartbeat", "..._fish_swim", "..._fish_breath", etc. Thinking back, I seem to recall that I understood the contents on the sheet, but I don't recall now what was the nature of the technology. Had humans developed the technology to precisely project and impose electrical signals that drove neural synapses in the fish? Or did the technology involve nanotechnology or both?

The principles in the dream are the same concepts played with in the comic/movie Surrogates and the movie Avatar: biological virtualization. I can only conclude that my subconscious felt it was starting to overcome some significant computer language/architecture barriers and decided to tackle electrical/biological barriers as well.