Yesterday, I asked my Twitter (@gogogic) followers/friends if they would be interested in a blog post about our concept and development processes. The answer was an overwhelmingly repeated “yes, please!”.
It was hopelessly clear that I would not be able procrastinate this here post… So, as promised, here is a rough look at how Gogogic operates, using Symbol6 as an example. Enjoy!
It all begins with an idea
Gogogic designs, develops and publishes games for the web, as well as the iPhone and the iPod Touch. This basically means that we have to come up with a lot of cool game concepts. Constantly. Which is what probably sets companies like Gogogic apart from companies that are more used to building “conventional” games – or “big” games (although, some of our future titles would certainly be considered big but “casual”). We work with volume while others work with size. And, of course, all good game developers constantly work with quality.
This means that ideas are very important to us. Polished game mechanics, innovative features and games that fit the intended platforms perfectly are all things that we look to incorporate in an initial idea. A lot of our time is spent on ideas. Everyone can participate and pitch their ideas. At any given time.
The following image roughly describes the overall process, where an idea is molded into a concept which then becomes a formal proposal which is accompanied by an animatic that serves as an initial prototype.
At any given time we have a stock of very rough “game ideas” – some are little more than a few lines of text and a rough sketch or two. All of our “logged” ideas are stored on an internal wiki and they are developed gradually, through a very organic process of reading, reviewing, re-writing and updating.
Everyone can be involved, in one way or another. Some people have to participate, of course, but anyone can chip in. Concepts are discussed during meetings (both formal and informal), sent between staff members for comments, etc. And, of course, a lot of doodling and drawing goes on as well. The following image shows the very first paper draft for Symbol6:
Some concepts never make it past the “few lines and an image” stage (the initial idea stage), while others become drafts that are developed and “finalized” (of course concepts are never “finalized”, but there is a point where you have to stop and decide that you’ve reached the stage that separates concept from full blown design). A finalized concept feels complete when:
- It describes the basic workings of a game
- It captures what would initially seem to be main elements and mechanics
- It has an initial story
- It has a flow to it – a basic game play description
- It holds conceptual suggestions to look/feel/sound/size
- It suggests user stories and interactions
When a concept is ”fully developed”, it becomes a part of a “proposal” pool – which basically consists of a number of concepts that we feel are all worthy of being analyzed and broken down into specific requirements.
Symbol6 was formally picked from the proposal pool because
- The concept indicated that the game could be a lot of fun
- The game had the potential to reach a broad audience, even though it was especially interesting to a niche market (puzzle game lovers)
- The game had replay value, although it was simple and relied on a single (but unique and polished) game mechanic
- The game was simple enough for us to implement it fairly quickly on a new platform, without compromising kick-ass graphics, sound quality or game play implementation
After being picked for production, the Symbol6 concept was turned into a full blown game proposal, where basic game design took place. Proposals also hold further implementation details, goals, feature specifications, etc.
For smaller projects, like Symbol6, the game proposal actually acts as the first draft of a design document, so when the game proposal for Symbol6 was accepted, we already had finalized most of the game design, as well.
But the proposal (or the game design document) is not the most important part in our process. The “prototype animatic” is, however. Below, you can see the initial animatic that was created for Symbol6 (Amusing fact : the working title for Symbol6 was Hexago).
The animatic has one purpose, and one purpose only. It visualizes the experience of a conceptual player, given a specific scenario. Simple games, like Symbol6, only need a single animatic to describe the whole game, while bigger games need multiple animatics to portray different “player stories“.
As those of you who are familiar with Symbol6 can see, most of the features portrayed in the animatic were implemented in the final version of the game. The animatic instantly set the tone for the entire game, how it would look, how it would work and how a player would experience it. Everyone on the team knew what to do from the moment we reviewed the animatic.
It also allowed us to decide what features we would implement and what features we wanted to skip, based on a visual experience. Furthermore, it allowed us to quickly prioritize features, requirements and critical elements.
At Gogogic, the animatic is king.
Production and design
Finally, the game is ready for production, along with sound and graphic design. Concept images and sounds have, of course, been set up. But this is the point where everything is finalized and handed in.
The following image shows the complete symbol set for Symbol6, as the graphics department handed it over to production.
I’ll leave the production, testing and publishing processes to another post (or two) since they diserve more than a couple of lines at the end of what has become a pretty long post.
Of course, this post only covers the fundamental parts of what we do ,while I’ve tried to avoid specific details of “how we do it”. Each aspect would need a separate post, if the intent was to cover that as well.
But “what we do” leads to the question “why we do it”. The answer is simple. We’re trying to build games that are extremely fun, innovative, user friendly, slick, stylish, beautiful and immersive. We’re trying to create an experience and that is why we go to painstaking lengths to see if a concept works or not - by an iterative process that organically weeds out ideas that do not work and by visualizing what we’re trying to achieve, early on.
Hopefully we’ll be successful with Symbol6, because we have a lot of great concepts just waiting to be produced and released. I’m sure I’ll publish “sneek peak” images and examples here, on this blog, before long
And remember to check out Symbol6 in the App Store, or the offical site, if you haven’t already. http://www.symbol6game.com