Game Design – Nicolas Barriere

Flubs was my first project as game designer. It is definitely an important step for me, on a personal, emotional and professional level. I wanted to take the opportunity to write about one my first experiences at helping build a proper video game. You can play the game online by following this link.

I was selected as game designer by the National Institute of Digital Entertainment (ENDI) based on my previous experiences in multimedia, graphic/web design and 3D production. The way ENDI builds their teams for the development of their game projects is by recruiting graduate students from various fields (art, coding, design, etc) and combining everyone’s expertise on a single project.

Excitement and anxiousness begin to describe my state of mind back in April 2010 earlier this year. I knew I possessed good knowledge and culture of games, a solid grasp of core game design concepts and good communicative skills that would help me accomplish all tasks and challenges. Still, I worried a bit. Designers are often required to have a certain amount of leadership skills, which was something I previously had little familiarity with.

For the next few months, I would be spending around 20 to 30 hours per week working and tinkering on various aspects of the project such as establishing our pitch and initial concept, describing the game systems and mechanics and ultimately helping coordinate the direction our team took. At the same time, I was also splitting my workload by simultaneously developing an iPhone project at ENDI.

It was both hard work and a terrific learning experience. Luckily, our team bonded really quickly. With everyone’s help and support we managed to shape Flubs into a solid game.

What went right:

Initial idea already figured out

In a somewhat surprising turn of event, the idea for the project that would be named Flubs was already thoroughly decided before my arrival. ENDI’s General Manager and Producer had already brainstormed the concept of “Break-Out-meets-Tetris”. That small chunk of phrase summed up a clear picture for every party involved.

What could have turned into a problematic cycle of early and endless creative meetings to establish a concept was instead replaced with immediate and practical effort. By having this information right from the start, this immensely helped me and my team focus on building and iterating a first prototype from a few ideas.

Freedom to experiment

An enjoyable aspect of working at ENDI was that we had an amazing amount of leeway regarding where we could take the project. In total, we must have come up with 5 different versions of Flubs until we found decided on a final design.

The mechanics of two alternating phases (one associated with each play style) and color matching to create combos was always at the forefront. The real challenge became figuring out how to make the phase switch happen without any confusion. This proved very difficult. After trying a phase switch triggered by the player or various sets of conditions (score targets, number of blocks destroyed, block patterns, etc). Eventually we found that a timer-based switch with increasingly shorter intervals helped the overall flow and could be communicated easier to a wide range of players.

Game Balance

Flubs difficulty was incredibly easy to balance successfully. From early on in development, I insisted on having access to most of the game’s variables to they could be tweaked depending on playtest feedback. Every element in the game such as ball speed, piece shape, block colors, ratio of colors in pieces, timer duration and much more were all available for any adjustments deemed necessary. Changes to different builds could be done incredibly fast without requiring the need of a programmer’s assistance. There never any downtime and slight modifications could be made in seconds.

Great team

I extremely enjoyed my time with everyone on the team. We were all around the same age and by chance this was also everyone’s first game project. At our peak, moral and general excitement was very high and made for an energetic and fun atmosphere. Communication was also excellent from the get-go, which minimized frustration a great deal.

What went wrong:

Past decisions impacting development

Overall, the design and scope of Flubs was kept very tightly from the get-go. While I mentioned this helped keep our aim true, we did very little experimentation beyond tweaking some tropes of the puzzle-action genre. This was affected by my line of work in particular. In the beginning weeks of development, I was gradually learning the ropes and simply did not want to make hard creative decisions that could have impacted development negatively down the line. I regret not taking the opportunity when I had the chance. Ultimately it made development safe, but the end result felt very formulaic with very little innovation at all.

Communicating game mechanics

Something I didn’t realize at first and quickly learned: half of the work of a good game mechanic/feature is about communicating it effectively to the player. Especially in casual games, where the audience is simply not aware of the recurring tropes, themes and game mechanics. My team and I struggled immensely for a long time on certain features such as the phase switch and color matching/combo mechanics.

For example: for about a month, there were two gauges showing player progress towards a phase switch and level up. This was ultimately scrapped because we found out through playtesting that most players were always focused on the ball during the more active phase. These issues were ultimately solved by focusing on the specific communication problem for an entire 3 week sprint before resuming normal development.

Progressive team reduction

Throughout our entire development cycle, the team kept becoming gradually smaller. This was really bad for both production and overall morale. We started as team composed of 1 game designer, 2 programmers and 3 artists. After a few weeks our first programmer went to work full time on an iPhone project, then 2 months later 2 artists left to pursue other projects outside ENDI.

This situation left our last month of development a rather bitter pill to swallow. Some important features that were already designed, like a power-ups system, had to be ultimately cut because we didn’t have the manpower to produce enough assets or code to integrate them.

Documentation structure

In all honesty, during the first months of development the documents containing information about the overall concept, features, game systems and mechanics were a bit of a mess. Big documents with too many paragraphs were not the way to go and now I know better. Thankfully because of our small team, peer-to-peer communication was ultimately functional enough that we managed to progress at a solid pace.  Learning how to communicate idea effectively through writing, document structure and schematics was one of the skills I learning during my time at ENDI.

Conclusion

I can definitely say that Flubs was very much a tremendous learning experience. While we did have our share of setbacks, the game came into its own quite nicely. My team and I definitely try to put as much care as possible into the game as we could and I do believe it shows. We delivered a polished casual puzzle experience that plays to its strength. In the future, whenever starting a new project I will be sure of starting off with bigger ideas and progressively shaping them into a fully-working design.

Thank you for reading!

Developer: National Institute of Digital Entertainment (ENDI)
Publisher: Independent
Release Date: July 2010
Platform: Web Browser
Number of Full-Time Developers: 2-6 depending on stage
Number of Contractors: None
Length of Development: 4 months
Development Software: Flash, Photoshop, Illustrator
Technology: Flash