Zeppelin Studio was founded in Vienna, Austria by a group of former classmates who wanted to apply their skills to the real world after winning several student game competitions. The company, in collaboration with German sound studio, leed:audio, is dedicated to delivering games that leverage cutting-edge technology, unique art and fun gameplay. Zeppelin’s first title, Schein, is an award-winning, puzzle platformer currently available on Steam.
Posted by ZeppelinStudio on Feb 5th, 2013
Posted in Textual Content | Feb 5, 2013 | by Kilian Reisenegger
Up until now I have only reported from the field of GUI Programming, however I am also responsible for a second resort, which carries the pretty name „Textual Content“. As the name says, this has to do with texts and not at all with programming. That’s really good for keeping balance.
Textual Content refers to literally everything containing text, starting with GUI labels, to the writing of story and dialogues and finally composing our Game Design Document (GDD). Since I don’t want to reveal too much of the story just yet, I will talk a little more about the GDD, which I have taken under my wing right from the beginning of Schein.
The GDD is practically the centerpiece of this project, in which all details of the game can be found. Since we at first had no idea how to structure such a document, and what its content should actually be, I started looking for a template. I ended up using the one by Mark Baldwin, which I can only recommend. Of course the template was not copied 1:1, but adapted to our necessities.
The picture above shows a part of the index of our GDD, which demonstrates the detailed structure in which this document was written. It also lets you divine the great extent of this document, for our comparably small game. In the course of development it has often proven to be a very useful reference book, since all game mechanics, interfaces, end bosses, etc. are all fully described in it. An important part of the task is to always keep the GDD up to date. Especially in the beginning, this resulted in a lot of writing and sometimes serious restructuring.
Even though we are a small team, which is working on a relatively small project, all the work that has gone into the GDD has already paid off thousandfold. With the GDD the team has one central document, which defines the whole game. If a question arises, about how this or that feature was defined, a quick look into the GDD suffices. Of course the main condition is that the document is kept up to date, and the entire team agrees, that what is written there is also what will be realized.