1- High concept before anything else

The all-powerful, all-important master idea is paramount to helping cement what game a will be for you and your team. It is vital to have a clear idea early in production and throw as much elements into the mix. After it’s done, you can shape the game idea into something practical that can help launch production. Ideas that aren’t useful at a time may just become the solution to a problem later.

I learned about the value of the high concept by trial and error. When working on a game, we found out around the end of production that one of the game systems was a bit overly simple and lacked depth. This could have been easily avoided if we had brainstormed just a little harder more before starting building the system in question.

2- Structure is key

Clear idea and documentation structure is an invaluable tool. It is paramount to be able to structure and communicate ideas through the spoken and written word. Bullets points, small interconnected documents, use cases, schematics and graphs. Not all-encompassing master documents, pages of text and paragraphs.

Everyone should be able to understand a game system or mechanic by reading or looking at it. It is useful for everyone involved in production, minimizes confusion and helps transparency in the case that something is gravely misinterpreted.

I learned to use Jesse James Garrett’s model for information architecture and it’s a great tool. The programmer’s I worked with responded really well to it.

3- Playtest often

Playtests help at every stage of production. Even between team members or exterior players, it is essential to obtain feedback on a particular feature or idea. It helps confirm or reconsider a particular element in the design that might cause extra work later on.

Simply asking the person next to me their opinion proved to be helpful on several occasions. Unfortunately, during the first 3 months of work we focused too much on trying to obtain feedback from people outside the studio. No one was always readily available during work hours, so this proved difficult. We did have minor success with an online limited release of different builds through friends and professional acquaintances. This gave us solid feedback. Unfortunately was a bit too late in production for us to use the data to improve the game substantially.

I personally assure that the next projects I am involved will have more opportunities for playtests and feedback.

4- Making the game communicate

From the user interface to game mechanics, it is vital that the game communicate effectively its actions to players. Too many times during production we had simple ideas or mechanics that would occur and genuinely confuse the player. Half the worth of a game mechanic is about proper communication when you consider it.

I learned during the early writing/planning stages that it is essential to decide on proper feedback and usability for everything in the game. Paper mock-ups done in pencil help burn through high amounts of possible scenarios and find flaws efficiently.

5- Emotions and game theory are nice, but…

They come later. I’ve spent a lot of time reading up on game design in the last few years. Reading about big productions and how they tried involving and immersing players through art, story or novel game mechanics. Understanding how new platforms shaped innovation or lack thereof, depending on your opinion.

It came to me as bit of a culture shock that almost none of that is involved in actual day-to-day activities of being game designer. My time was mostly spent doing actual work like writing or communicating with my team members about how things should be built for the game to function in the most literal way possible. It really brought my expectations down to a more down-to-earth level and I am happy for that.

I definitely aspire to someday reach a professional level where I can help video games, as a medium, advance and reach new heights but it’s not going to happen tomorrow. Right now I would rather invest my time into working on fun and enjoyable projects.

Conlusion

After growing so much these past few months, even with a solid reality check on many levels, I can’t wait to do more. Video games are my passion. By working and writing every day, I hope I’ll be able to continue making better ones. I will never stop learning, to be sure. Game design is a growing field of study and there is still so much to do.

Overview & process

After having shaped other core design elements (controls, combat, player/enemy abilities, mission types, power-ups, etc), I started tackling the creation of the first maps. What would they look like? Where would they take place? What sort of props and other elements would the player see? At the very least, I knew I had these constraints to follow:

• No vertical movement
• Low-poly environment
• Medium sized locale
• Easily identifiable surroundings
• Must reference imagination and silliness
• Must be polyvalent enough to allow different mission types
• Easy navigation and visibility

The first few versions were very stale and dry. They were too much focused on horizontality and having simple areas to navigate to keep the complexity and poly count low. Objects were placed too carefully close to one another and seemed artificial. Nothing meshed really well until around the third iteration.

Maps were originally blocked in 3D Studio Max. After opinions and feedback the blocking, it was rapidly integrated in Unity Game Engine to play with primitive colliders. The second helped identify any problem regarding problems with the volume and scale of objects. After another round of final adjustments and comments, the 3D Studio Max file was handed to the artists so they could build the levels.

The final version showcased more vertical structures that helped mask visually the horizontal movement constraint. The small sand gap was especially helpful in delimiting the map into two subzones, one for each stronghold.

Dual areas

One of the apparent concepts that seemingly started to click very fast for the team and I was that the “kid” had built different areas out of anything he could find around his house or backyard to create a battleground for his toys. This would go on to be the master idea for the other maps we would create.

The “kid” was imagined as being around 6 to 10 years old, where children often develop an unambiguous view of conflicts. This is the reason behind the separating his sandbox into two areas.

An important aspect was that enemies and power-ups would always need to be easily visible at almost any time. Therefore the environment as no high walls and the player’s vision is almost never impaired.

Sandcastle area

The sandcastle is the most impenetrable and more logical of the two areas. The player can only enter from the front, albeit from two entrances. This was designed to add tension if the player entered the area, since his view would be momentarily blocked by the high walls and couldn’t rapidly notice if an opponent would come from the sides or behind.

Fixed enemies needing to be destroyed or power-ups would often be situated inside the sandcastle to incite the player to enter it. Since the player cannot escape through the sides, I felt it was important that no other major obstacle would impede on navigation when he left the castle.

Blocks area

The blocks area, in general, is bit more difficult to navigate. The small fort is the highlight of the area. It is bigger than the sandcastle and features 5 different ways to quickly enter or exit. This allows creative enemy and power-up positioning that can be different depending on the selected mission. Rocks are placed a bit more carefully to complicate maneuvering a bit more difficult during combat moments.

Bridge area

Both bridges are the same length and offer straightforward way to both sides of the level. One interesting feature to notice about the area is the low fence created out popsicle sticks. It keeps the player from falling into the ravine, but still allows him to see the enemies all around him. It is possible to fire at opponents from the other side of the map with careful aim.

The books’ size allow for two vehicles (player or enemy) to pass through simultaneously. The player and enemies frequently start skirmishes on them. They act as a helpful trigger to start conflict during missions.

Conclusion

The Sandbox is overall the simplest map created for ENDI Tank battle. It helps introduce the basic gameplay mechanics to the player and is easily accessible. It helped stylize and set trends for the entire project. You can take a look at a short video displaying the level right here.

Thank you for reading!

This was an incredible project to work on. I learned an incredible amount of precious game design knowledge and go to work with amazing and inspiring people that delivered spectacular work on all levels. In the end, I feel the game looks amazing visually and is accessible and fun. The game will be released on the Apple Appstore in September 2010 as a free downloadable game.  I do hope you’ll try it out.

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

You can listen to it here. My segment starts around the middle.

I will be participating in the 2010 edition of the Bivouac Urbain, an electronic culture festival that hosts a 36 hour game jam from the 5th to 8th of August .  My team, The ENDIstructors, will be the official representatives of the National Institute of Digital Entertainment (ENDI). I will be Team Captain and in charge of Game Design. One of the judges this year will be none other than Jenova Chen, co-creator of titles such “flOw” and “Flower”. I am quite eager to see what everyone in the competition will end up creating. I’m sure it will be immensely fun.

I am extremely happy to announce that I will be attending the National Institute of Digital Entertainment (ENDI) in Quebec City as game designer during their Spring/Summer 2010 semester. I’ll be in charge of the design and developments for video game two projects. I will be mentored by Frima Studio during my passage at ENDI. This is an exciting opportunity and I am overjoyed to be able to work with dedicated and passionate companies to produce outstanding work.