Wednesday, November 25, 2015

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?


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.

Sunday, September 27, 2015

Global Gam Jam 2015 Retrospective


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.


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.