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.

Report article RSS Feed Of Texts and Documents

Posted by ZeppelinStudio on Feb 5th, 2013

Posted in Textual Content | Feb 5, 2013 | by Kilian Rei­senegger

Up until now I have only repor­ted from the field of GUI Pro­gramming, howe­ver I am also responsi­ble for a second resort, which car­ries the pretty name „Text­ual Con­tent“. As the name says, this has to do with texts and not at all with pro­gramming. That’s really good for keeping balance.

Text­ual Con­tent refers to lite­r­ally ever­y­thing con­tai­ning text, star­ting with GUI labels, to the wri­t­ing of story and dia­lo­gues and finally com­po­sing our Game Design Docu­ment (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 begin­ning of Schein.

The GDD is prac­tically the cen­ter­piece of this pro­ject, in which all details of the game can be found. Since we at first had no idea how to struc­ture such a docu­ment, and what its con­tent should actually be, I star­ted loo­king for a tem­plate. I ended up using the one by Mark Bald­win, which I can only recom­mend. Of course the tem­plate was not copied 1:1, but adap­ted to our neces­si­ties.

Game Design Document\

The pic­ture above shows a part of the index of our GDD, which demons­tra­tes the detailed struc­ture in which this docu­ment was writ­ten. It also lets you divine the great extent of this docu­ment, for our com­pa­ra­bly small game. In the course of deve­lop­ment it has often pro­ven to be a very use­ful refe­rence book, since all game mecha­nics, inter­faces, end bos­ses, etc. are all fully descri­bed in it. An import­ant part of the task is to always keep the GDD up to date. Espe­cially in the begin­ning, this resul­ted in a lot of wri­t­ing and some­ti­mes serious restructuring.

Even though we are a small team, which is working on a rela­tively small pro­ject, all the work that has gone into the GDD has alre­ady paid off thousand­fold. With the GDD the team has one cen­tral docu­ment, which defi­nes the whole game. If a ques­tion ari­ses, about how this or that fea­ture was defined, a quick look into the GDD suf­fices. Of course the main con­di­tion is that the docu­ment is kept up to date, and the ent­ire team agrees, that what is writ­ten there is also what will be realized.

Post a Comment
click to sign in

You are not logged in, your comment will be anonymous unless you join the community today (totally free - or sign in with your social account on the right) which we encourage all contributors to do.

2000 characters limit; HTML formatting and smileys are not supported - text only

Level
Avatar
Avatar
Offline Since
Feb 19, 2015
Country
Austria Austria
Member Watch
Track this member
Blog
Browse
Blogs
Views
64 (1 today)
Report Abuse
Report article