09-11-2012, 03:43 PM
GRANODE - A proposal for a new game design tool
1GRANODE.pdf (Size: 2.09 MB / Downloads: 30)
Abstract
When creating computer games it is necessary to use extensive documentation so that everybody involved in the creative process is up to date. This paper has investigated what prospects there are to improve the GDD process to a more updated version that would be less linear in its format and more user-friendly to everybody involved.
The theory describes relevant concepts about the characteristic computer games industry and touches some points that programmers and esthetic content creators come in contact within this environment. The theory also highlights some contrasts between these professions and the game designer concerning available resources and the communication between them.
It also highlights the advantages of using graphical information over text to convey certain information faster and more ubiquitous over several channels.
Introduction
When creating a game there are many good tools, sometimes several within a single field/area. When work is divided and shuffled between different disciplines and forward in time there are also a lot of established methods and good tools to choose from as well. There is however one important transition that could work better regardless of production size, platform or genre; the transition from concept to production (Dille & Platten 2007).
It is an elusive step that has to convert abstract ideas and concepts into tangible (and often measurable) items and rules that can be understood by everyone that will work with the game (Callele et al 2004, Kanode & Haddad et al 2009). The conversion from idea to practice is a difficult one at best since it is usually the esthetically inclined designer(s) that writes down a number of ideas of how the different parts of the game should behave (among all other aspects of the design like appearance and feeling) (Adams & Rollings 2007). This text is going to be read by people that want specific (less interpretive) format of the information since they are going to create their pieces based on what is available in the documentation. This requires that the documentation is extensive and that a rigid version handling system is in place, all aspects of game production is very iterative.
Same concept, growing mass
A game could be described as a closed interactive system where the user tries to execute specific combinations of instructions in order to achieve completion of defined tasks to progress to an end goal, there are several more descriptions (Salen & Zimmerman 2004) and attempts to give a definitive description but this one is adequate for this paper. This concept has not changed since the beginning of games.
Creating games requires some sort of method/tool where every entity in the system could be given a set of attributes and how they interact with each other, entity to entity but even attribute to attribute. Some of the attributes even have to be able to change depending on specific circumstances, keeping track of all the variables and producing a consistent and rigid model of game mechanics is very complex.
Today this is done with tools and methods developed for games that was fairly simple, the technology to do so back then was, in comparison with today’s technologies, simple but adequate. The games have evolved; the methods and tools have not seen a parallel evolution in capabilities.
This paper will investigate if it is possible to construct a tool/concept to generate a general system that can describe any interactive system and make the resulting description a framework for subsequent design decisions.
Existing tools and methods/systems
To get to a finished concept of a game is a process in itself and there are many paths to choose from, regardless of path/method taken the ideas and decisions made must now be organized so they are easy to grasp for anyone that was not part of the decision process (Adams & Rollings 2007).
There is no universal standard for how a GDD should look like, there are many templates that one can download and use, but they are only guides. In the early stages of development the GDD structure is roughly pieced together from what worked before that is still applicable and figure out how to fill in the gaps with a new workflow (Adams & Rollings 2007).
Current shortcomings
The software solutions available in theoretically assisting with structuring a GDD as intended in this new context are too specialized or generic to be efficient. Also, none of the solutions found could provide an adequate holistic strategy to either be integrated, or export any result created, into an established workflow. In order to create a comprehensive image of what the game is supposed to do that is easily understood by others today, a designer have to use several software packages and manually linking them together, this is a very error prone and time consuming method (Dille & Platten 2007, Kanode & Haddad 2009).
Another issue that is often changed/updated and hard to describe is the behavior of the entities in the system (Dille & Platten 2007). Behavior is complex since there are often several factors that determine what happens at specific circumstances and keeping track of all interdependencies is a massive undertaking. When changing one aspect of one entity one could unknowingly offset a finely tuned balance of an entire section.
Target Audience
This concept should be beneficial for anyone who is involved in the creation of user interactive systems such as games and/or web-pages.
Conveying what a designer means and wants into a more technical and practical format is notoriously difficult to capture, this tool would help both the esthetic and technical side to meet half way. The designer will have to define the interaction and behavior of the system with a set of rules (that also is defined by the designer) which has unambiguity to programmers thus showing the intention of what is to be achieved more clearly.
Posts in production
When computers came about the computer games soon followed, up to the mid-eighties one game was usually made by no more than a handful of people and when technology improved so did the demand for better/bigger/faster games, today it is not uncommon for a big game having 200-300 people working on it (Dille & Platten 2007). What a person does in a company is among the few things that have become a standard in the industry, mostly because it is based on skills from mastering the available tools.