Case Study of Freja’s JourneyGame Design and Design Documentation during Prototyping

AbstractThough two months of work, we have helped a team of four seasoned game artists create a prototype of their own personal project in terms of code. Having such a big impact on the entire project, we had to help them flesh out the game design as well as the documentation, and as a result also experienced firsthand the huge impact that lacking documentation can have, compared to properly developed documentation, and what truly sets the two apart. In this paper we discuss the fundamentals of writing a design document and how we, using our knowledge of game design, could help the team achieve a better quality design document and a fleshed out gameplay. We also highlight some of the important pitfalls that a game designer should try to steer clear of, when writing a design document.

Freja’s Journey

The Project’s OriginFreja’s Journey started out as a concept between four artists working at IO Interactive under the collective name: “Tinysaurus”. They wanted to create a game set in the world of Norse Mythology, revolving around a character called Freja. The game should be a 3D side scrolling action/adventure game, that would have Freja travel through Middle Earth, Asgard and Jotunheim. The game should be playable by younger gamers and older games alike, and work on a multitude of platforms, including the iPad.

A visual vertical slice had been sent off to DFI’s (Dansk Film Institut) video game fund, but was rejected due to the lack of gameplay and documentation for the game.

Our Role in the ProjectThis is where we came in. The team was looking for a student to help them with the programming for creating a prototype needed for their next submission to DFI. They ended up recruiting two instead of one, and we were immediately tasked with realizing the vision. Later in the process we would also work along the team on improving both game design and the design documentation, with the goal of improving the game and the better documentation that might help them when pitching the game.

The Goal of Freja’s JourneyThe goal for us to begin with, was to realize as much as the gameplay for the vertical slice as possible within two months. The intention was to build a prototype that could be presented to DFI or other funds or publishers. It was our job to build, in Unity, the gameplay of Freja’s Journey. The prototype of Freja’s Journey had a deadline of March 1st (2013) where the team had to submit the game for funding evaluation at DFI. It was our goal to realize as much as possible of the

1

game design, before the deadline.

Design DocumentationEven though it was not our task at first, we ended up spending a lot of time, working on the documentation of the game. In order for us to build up a great document that would represent the experience in a sales pitch as well as clearly communicate the design in depth, we required further knowledge on what truly makes good documentation. This chapter is dedicated to discussing the role of a Design Document, and how we ourselves helped handle the documentation of the designers’ vision.

The Role of a Design DocumentIt’s common practice to write a design document for a game idea, but often the role of the design document is mistaken. Some people think that the design document is just a way to write down some ideas about the game in a standardized template, that could then be shipped off to a development team, that churns out a great product (Rouse, pp. 380­381). However the design documents are very organic, and have to suit the needs of whoever should read it, which in almost all cases are the developers.

"A design document is all about communicating a vision for a game for mapping out as much information as possible about how that game will function, what players will experience, and how players will interact with the game world. Organizing and structuring all of this information into appropriate section is one of the key challenges in writing a good design document." ­ (Rouse, pp. 356)

Something that people might not also know is that the Design Document has to be kept relevant during development, and the writing is not a one time job.

The Impact of Bad or Good DocumentationThe design document is the core that an entire development team work around, and the quality of it can be the difference between a smooth development or a painful experience (Freeman, 1997). It’s important to know what role the design document is supposed to play, when writing it. If the designer can’t imagine the document being used regularly, he might not write in a way that makes it easy to do so. The game design document is a reference tool that should “automate” the game design, so developers can don’t have to be in constant dialogue with the game designer (Ryan Part 1, 1999, p. 1), and most questions about the game should be easily looked up and answered. (Shuytea pp. 109)

Truly good documentation is difficult to describe, since it’s very dependant on the game and the team and is a fine balance between too little and too much information, but truly bad documentation is often very superficial and does not go into depth with any game mechanics (Rouse pp. 361). The documentation may also be out of date or the indexing might be bad. The game designer has to look at the document from the team’s perspective, and predict what information that will be most critical to them, when implementing new features. (Ryan Part 2,

2

1999, pp. 2) Programmers probably won’t need any variables or algorithms, but instead just a basic set of rules. Maybe a few if­else sentences or some simple illustrations might help the coders, but especially if the designer has little knowledge of programming, he might confuse the programmers more than he might be helping them. Similarly, the designer should consider the other branches of the team. Artists may need some detail about the world, but the details should be short and to the point, so it’s not necessary to read through tens or hundreds of pages, which would slow down the process considerably.

Another thing that may make the document easier to handle is readability (Freeman, 1997), which may stem from the fonts chosen. How much white space there’s kept between the sections that should be separate or eye­catching headers. Finally information should never be repeated in the design document, but instead reference to the appropriate place where the design will be described. Repeating the information can lead to contradictory information later, when the design document needs to be revised, and information might only be changed in what seems like the appropriate place. (Rouse, 2004 pp. 358))

Categorizing Bad Design DocumentsWriting a design documents seems to be very individual to the designer, it’s still important for us to communicate what the flaws in a document may be, even though there no such thing as a standard template. Rouse has neatly categorized design documents under 5 names, according to the mistakes that they make:

The Wafer-Thin or Ellipsis Special DocumentDocuments that barely mention the gameplay, and often focus on very small and specific elements, but will fail to describe the gameplay beyond simple comparison like: “This plays like [Video Game] but has graphics like [Other Video Game].” or just describe the basic feeling of the levels and weapons (ex. “This level will be fun”) It’s often a sign of a manager that tries to be a game designer (Rouse, pp. 374­375), and truly misses the point of the design document for the developers.

The Back-Story TomeUnlike the Ellipsis document, the Back­Story Tome is very detailed, especially when it comes to describing the backstory and the world, and often has a lot of work put into it, sometimes hundreds of pages. However these are not always indexed properly. The Back­Story Tome is often written by people that are more interested in the story­telling, and don’t care much for the way that it’s presented to players (Rouse pp. 375­376). The Back­Story Tome might be a sign that the game designer can’t distinguish the game design from storyline or lore, and it’s definitely a good idea to separate the two into different documents.

The Overkill DocumentCompletely opposite the Ellipsis document, the Overkill document will dig too deep into the gameplay details, and can easily subtract from the ease of use that a design document should have (Rouse pp. 376­377). Examples might be that code or pseudocode is stated, or that all

3

statistics for an item or weapon are stated. The Overkill document’s details are probably best stripped entirely from the design document, and added as additional documentation for the game (i.e. items list, system architecture or level data.

The Pie-in-the-Sky DocumentThe Pie­in­the­Sky document refers to a design document that describes an unrealistic game or game feature (Rouse, pp. 377­378). Examples could be inconsideration to technical limitations or levels of detail that are unachievable in the the timespan set for the development of the game. These documents are often results of management setting too high expectations or a designer without proper knowledge of what the technical or artistic staff can achieve.

The Fossilized DocumentA document is called a Fossilized Document when it’s become out of date for the development (Rouse pp. 378­379). Sometimes a design document starts out as a great reference tool, but the designer may not have built up a good routine of continual modification of the design document, as decisions are made, and changes implemented.

Design Documentation in Freja’s JourneyThe first documents that we were introduced to was a short single­page pitch and some screenshots from their visual prototype. The pitch was well written, and well considered. It was able to communicate that game very well in few short sentences.

“Freja’s Journey is an exciting side­scrolling action game set in a magical viking world based on the Nordic mythology. Freja’s quest to save her family and friends brings her all the way from the green fields and forests of Midgard, through the icy mountains in Jotunheim, all the way to the god’s mighty fortress Asgard. The game is targeted at soft gamers: people of all ages who enjoy quality casual games with a little more depthto the game experience. It will be available on the following platforms: iPhone, Android, Windows 8, Mac and Linux. It features beautiful game art and stunning visuals, with a rich customization system, Deep combat system and a unique quests and achievement system with exciting rewards.” ­ Freja’s Journey Pitch

The pitch might also be referred to as the games High Concept (Shuytema p . 85) which describes the core of the game, where a pitch would normally be a bit longer, and include demos or proof­of­concept and describe in detail the themes, play styles and the team behind it. (Shuytema p 86). In this case it was a mixture of both, a very short pitch or a long High Concept. We’ll refer to it as the Core Overview, which seemed to be the best description according to Shuytema. (p 95)

When we started working on the project however, the design documentation that we had to work with seemed to suffice, yet later revealed itself to be lacking. The team had put time to put a lot of effort to write a design document that covered as many categories as possible, but didn’t have much experience writing them, which is probably the reason that the document did not meet our

4

needs as consulting programmers.

The design document we had to work with to begin with was just 32 pages long, which to begin with seemed like sufficient information to build our game on. Furthermore the team had also created a document called “Level Zone Overview” that held the most basic information about the levels throughout the game.

The Quality of DocumentationAs described, the Core Overview that pitched the game was well written, and did well in putting the game concept into as few words as possible. Since it wasn’t meant as specifically Core Overview, High Concept or Pitch, we just went along with it being a Core Overview, since it seemed like the best description.

The Level Overview document had a long list of levels, and had neatly categorized them under which world (Midgard, Asgard, Jotunheim) that they belonged to. They all listed what gameplay type the level was, and what time of day the levels would be shown as. Some levels also held quest information for the mail quests, and all levels had a small description.

The level document was definitely unfinished, but provided great material for starting work on the different level. For future development, the document might also include links to concept art and quests, and might even be expanded further with a detailed description of the level.

As we also mentioned, the design document consisted of several pages of documentation. However, when we started working on the game we immediately hit a roadblock, because details of the game didn’t seem to be communicated well enough. We had to implement the basic movement and actions of Freja to begin with, but it seemed like there was too much freedom given to us. After discussions with the team, we realized that many of the deeper details had not been thought of at all. It seemed like a case of an Ellipsis document, where the details of the game mechanics looked underdeveloped, but at the same time the length of the document seemed to imply otherwise. We definitely got an impression that the team knew how the gameplay should work, but that they were unable to properly put it into words.

Like a Back­Story Tome, the document was rich in story and descriptions of the world, and was missing a proper table of content (Rouse, pp. 360). The way it was set up in the document was two bullet points to help people look up 32 pages of design document. The table of content split the document into two sections: “The first part” (that covered story, characters, world and basic gameplay) and “The second part” (that held the technical specifications and workflow description and other technical details). This made it very difficult for us as well, as it was hard to grasp what we could look up, without having to read the entire document, even though the document was rich in sections and subsections with proper headlines. The document also felt very Wafer­Thin in some sections:

“People ­

5

During her journey Freja encounters different people ­ from peddlers and merchants to villagers in distress, who will need her help and send her on quests.“ ­ Initial Design Document

“Basic MovementThe basic player movement is the following: walk, run, jump.” ­ Initial Design Document

with other sections providing much more information. It was obvious to us that the design document needed to have a lot more information about how these mechanics worked, and what the player could do to trigger the game mechanics.

In terms of readability, the document really excelled, with nice headers, a good amount of whitespace and few but simple pictures.

Expanding the Documentation for Freja’s JourneyWe had identified the design document as having the biggest flaw, and that’s where most of the focus should be put. We especially wanted emphasis on the things that we had to implement in prototype, and we started to work with the Tinysaurus team on making detailed descriptions of the game mechanics, and how Freja was controlled.

Since the design document is protected by an NDA (Non­Disclosure Agreement) we will not be able to quote the final design document directly, but we are able to include a stripped down excerpt of it. This excerpt does not contain the full details of the final document, but examples will be given on how the final document should describe the gameplay details.

MovementMovement was only described using a single sentence in the original document, yet the teamalready knew how this mechanic was going to work, so the process here was as simple as justwriting in greater detail how the controls of Freja worked.

Besides the information in Appendix A, we further needed to describe the input. The final designdocument we had to also explain that: Freja moved by tilting the left joystick left or right. Over aspecific threshold would she start running, otherwise she would walk. On touch devices, thisjoystick would be visually drawn on the screen. The jump­button would make Freja jump, and ifshe was running or walking, would keep moving forward in the air when jumping. Freja wouldkeep moving in the direction that she was running/walking when the jump button was pressed.While in air, Freja could still be controlled a bit, but would still keep the same general direction.

CombatWhen we had to write about combat, unlike the basic movement, the team had not thought thecontrols though, and were split between how it should be implemented. As described later in theGame Design chapter, you’ll see that process of evaluating and updating the game mechanicsof the combat, but in terms of documentation, it’s easy work once you know how the gameplayshould work.

6

The combat section was expanded to include the button layout and how it was utilized:To attack, Freja had a single attack button. To make a quick slash, the attack button should betapped quickly. To make a heavier attack, the button should be pressed and held down briefly.The attack button would execute different attacks, depending on what state Freja is in. Exampleswould be that when the attack button is tapped right after a jump, would make Freja execute anupwards slash or tapping the attack button while in mid air, which would enable Freja up to threeslashes of the sword while suspended in mid­air.

EnemiesSince the Tinysaurus team had very little knowledge of programming, AI hadn’t been a concernof theirs to begin with, and therefore the behaviour of enemies had not really been fleshed out. Inthe trimmed down design document (Appendix A) there’s short description of the enemiesbehaviour, which was more than we had to work with at the offset. The finished designdocument described the enemies behaviour in terms of state, but didn’t take into considerationthe AI Director (Chapter: Prototyping ­ Enemies and AI) for example.

Examples of state would be that enemies pulling the wagon were in a “Pulling” state and wouldthen only pull the wagon. If all protecting enemies for the wagon had been defeated, the enemywould enter a “Fleeing” state, and run away and disappear. If Enemies were in a “Protecting”state, they would move towards the wagon, until a certain distance, and be “Idle”. When in theidle state, they would move towards the wagon, once the distance was too big, or enter“Combat” when Freja was within a certain distance. After a few seconds of “Combat” they wouldenter “Attack”, there they would charge Freja and attack her, after which they would re­enter thecombat state. Combat state would go back to idle if Freja got too far away. AI usually might bemuch more detailed than we described here (Ryan Part 2, 1999, p. 4)(Rouse, pp 366­368) butfor the purposes of developing the prototype it would have been a bad idea to set too much instone for the developers in terms of AI, since only a single quests (the wagon) had to have AIimplemented.

Finally some details of the design document were also removed. As we will discuss in anotherchapter (Game Design Process in Freja’s Journey) some aspects of the game design were toocomplex (Ryan Part 2, 1999, p. 3), but some places game objects had been written in too muchdetail, maybe even a small case of an Overkill document and we advised them to strip it away.

PrototypingOur first concern when starting work with the Tinysaurus team was to write code for them. In this chapter we will touch upon all the areas of coding that we had to work with. Documentation and Game Design are discussed in their separate chapters. In this chapter we discuss all of the major systems that we implemented into the game in a more or less finished form.

FrejaThe most important thing was of course to get Freja to run around the level properly. Animations

7

were handled separately from Freja’s basic movement, that depended on a character controller. This controller would be fixed to a lane, defined by the level. Each level would have three lanes, where the middle one was intended for Freja, and the other two would allow enemies to walk past each other without colliding.

Besides simple walking, we also had to implement attacking and jumping. Since a low priority had been kept for combat in terms of documentation, a simple attack was just implemented, and not combos as it would later be described in the Design Document.

Freja was also fitted with a lot of smaller scripts: e.g. ‘suck in’ all surrounding items or money, if there were any of them close to her or hold different weapons that had a small chance of doing extra damage.

AnimationsThe team had many animations of the main character but they had not been configured to play with the controls, and were impossible to merge. The artists were very keen on portraying a fantasy yet realistic feel in their game, so animations had to be worked until there was no sliding (walking animation while not moving), the jumping felt accurate and realistic, and the animations were merged nicely.

This work was done with Mecanim, Unity’s animation system, which proved to be immensely useful in creating state­machines and configuring it to perform blends between walking, running, jumping and attacking. Freja had to be able to attack while standing, while running and while jumping, and also jump while standing and running. All these actions had to be mapped according to controller input and polished until they seemed realistic enough.

We had to ask for “basic animations” (walk, run, jump, attack) from the artists in order to perform effective blends (run­attack, walk­jump), modifying the clip length and the blending conditions in order to make them fit one another.

In the end, the work was validated and appealed to the artists, as it effectively conveyed the sense of realistic fantasy they wanted to portray.

Enemies and AIThe enemies of the game had to at the least have a basic AI that could walk on the lanes, and not collide with each other. For this a central AI was created that would be the director of all enemies, and assign each of them a task that they should accomplish. That way only a single enemy would attack at a time, and not every one of them acting completely identical. The AI system could tell the enemies to walk to a specific place (x­position) and the enemies should automatically walk around each other, yet end up in the middle lane whenever they are the closest enemy to Freja. The AI director would look at all enemies and their target position, and see if any of their paths would cross, if so the AI director would tell one enemy to switch to a different lane.

8

As mentioned, enemies would only attack one at a time, and for this prototype it would always be the closest enemy to Freja. Some enemies however could be tasked with other things that would not allow them to attack. For example in the level, two goblins will pull to wagons with supplies away from Freja (each in a separate direction) and for each wagon, two enemies will spawn to protect it. The two pullers would no be concerned with Freja at all, but instead only pull the wagon. If the protectors died however, he would flee the scene. The protectors would however stay within proximity of the wagon, unless Freja would be near them, in which case they would be in an aggressive stance, and attack when told to.

QuestsSince the game was told though quests, a simple quest system was put into place, for the purpose of the single scene. A list of quests would be created upon start of the game, and each quest would then have a number associated with it. The number would be the progress, so 0 meant that it had not been started, and 1 meant that Freja had triggered something, and progressed the quest to the next stage. ­1 meant that the quest was completed. For the wagon quest, it would be triggered once Freja initiated a dialogue. Once the dialogue was complete the second stage of the quest would trigger a cutscene. The third stage would be triggered once all wagons had been stopped, and Freja could return to the original dialogue trigger, and receive a ‘thank you’ message, which would set the quest progress to ­1.

ConclusionIn this chapter we have looked at what a design document is, and what impact a bad design document can have. We have also given some examples of typical bad design documents, and where (if at all) they the Freja’s Journey design document had similarities. We have furthermore given some examples of how we expanded the design document of Freja’s Journey, and made it more detailed where it needed be. Both to make sure that future developers on the project have better reference tools, but also in order to help the team to sell the game idea, so they can get funding for the project.

9

The Role of the Game DesignerWhy do we need Game Design in Games?

Game Design is the process of imagining a game idea, defining how it works, describing the various elements that make up the game and communicating the information to the rest of the team (Adams & Rollings, 2007, pp. 36­42). It is important to evade various misconceptions, such as thinking of the player as oneself, or thinking of him as an opponent. This process includes conceptual design elements, such as mechanics and character design, but also artistic aspects, such as visual art, music and sound.

Stages of Game DesignThree important steps

According to Adams & Rollings, the Game Design Process is “divided into three major parts: the concept stage, which you perform at first, and whose results do not change; the elaboration stage, in which you add most of the design details and refine your decisions throughout prototyping and playtesting, and the tuning stage, at which point no new features may be added, but you can make small adjustments to polish the game” (2007, pp. 52­60).

We focused on the first two stages, as the aim of the project was always to create a functional prototype and game design document, not to have a final, polished version of the game.

Game DesignersThe Game Designers are the team members in charge of overseeing and documenting the whole design process of the game. Starting from the most abstract level and detailing the idea and mechanics as the team iterates on the design, the game idea turns into a game concept and then into a game design, closely following the team’s progress in the other areas.

Specialized game designers which are responsible for levels are called level designers, and must get the mechanics and concepts down to earth in a practical, tangible level, combining all the elements. In our work, we helped design the first prototype level, with the main mechanics of the game.

Concept StageFrom Game Idea to Game Concept

This is the initial stage, where the group comes up with a game idea and works on it until it becomes a solid game concept.

Coming up with an IdeaThis process is usually characterized by various creative brainstorming sessions with the team or a smaller sub­team in charge of design. As Jesse Schell states in The Art of Game Design,

10

the core of this phase is iterating through an idea until it is good enough (pp. 58­61). Some tips regarding this process are to find inspiration outside games (environments, art, history, everyday chores, childhood memories, hobbies) and to lead a good creative brainstorming process with a moderator, promoting an active environment.

Ernest Adams and Andrew Rollings have also been very keen on expressing, in both Fundamentals of Game Design and Game Design, to dream the dream, and think of designing games as fulfilling dreams. Shigeru Miyamoto has found inspiration for The Legend of Zelda games in his childhood memories, exploring a river valley with mountains and caves near his rural village. (http://www.newyorker.com/reporting/2010/12/20/101220fa_fact_paumgarten) Videogames are about gameplay and entertainment, but also have a lot to do with enacting fantasies (mimicry) and presenting the player with rich, virtual worlds, societies and characters.

Richard Rouse states that it is possible to start a game idea from a story or setting (pp. 45­46), as long as it dramatically affects the gameplay and the designers have the skill to think how it will adapt to the game. Many games are more about the story and setting than the gameplay, while others focus more on the gameplay, with the setting being only a way to illustrate the world. In fact, in our process, we started with an idea or a fantasy, and coupled it with gameplay that would fit.

Games that feature a balance between the setting, gameplay and mechanics create harmony between them, and are the most solid games. Andrew and Rollings state the importance of harmony in games, and how designers should strive for harmony and portray the feeling that all elements of a game belong to a single, whole, coherent experience (Adams and Rollings, 2003, pp. 56­60). This is what we intended in the game design process that we carried out.

Crafting the Game ConceptOnce the basic idea has been established, it is a good idea to describe it in a document and validate the idea with the team. The process of writing the document is usually an enlightening one, as it is a process fueled by questions and placing oneself in the position of a third party reading the document. As Adams & Rollings state, it is an “assembled skeleton” (2003, pp. 52­53).

In this stage, it is usual to write a Pitch Document or a Game Concept Document. Many authors make several distinction between them, but they are mainly the initial pitch or idea of the game, with the vital elements and game feel.

Adams & Rollings have stated that the four vital points that need to be established in the Concept Stage, which cannot be changed once the elaboration stage has started, are four (2007, pp. 54­55):

the concept of the game, which is the general idea of the gameplay and the reason behind why the game is compelling

the target audience of the game, which dictates the kind of experience the players will be

11

presented with, and is vital in a player­centric design approach the player’s role in the game, which relates to the character or characters that the player

will control and the objectives that the player will have the fantasy of the game has to do with fulfilling the player’s dreams and wishes, and

presenting him with what he expects from the game

Note: These points do not apply to abstract games, which are games that lack a defined setting, world and reason to be, and rely on abstract mechanics. The game the design team is making, however, is a representational game, so the points stand valid.

Finally, Jesse Schell recommends applying eight filters to any game idea in the iterative process (pp 76­79), by asking eight questions:

Does the game feel right to the designer? Will the intended audience like the game enough? Is it a well­designed game regarding the theme, mechanics, balance? Is the game novel enough? Will this game sell or appeal to its consumers? Is the game technically possible to build? Does the game have social goals, and does it fulfill them? Do the playtesters enjoy the game enough?

With playtesting, Jesse Schells enforces the idea of early prototypes (paper, white­board, basic digital) in order to try out ideas.

Elaboration StageDeveloping the Concept into a Full­fledged Design

With the concept in a basic level of abstraction, each mechanic is further developed and put together into a harmonic design. This vital stage involves describing the game in a higher level of detail and prototyping the mechanics to test the ideas in practice.

Game Design TasksThis stage involves completing various tasks (Adams & Rollings, 2007, pp. 56­59), which are:

defining the primary gameplay mode, which means defining what the player will mostly be doing in the game, not having to specify every single element, but defining the components that make up the mode, the interaction model, the challenges presented to the player and the actions available to him

designing the protagonist in order to let the player feel identified with it, working on its appearance and/or behavior, the emotions and body language he possesses, the vocabulary he uses

12

defining the game world, relying on real life and imagination in order to create the world inside the video game, which includes look and feel but also physics, time, environment, emotions and ethics

further designing the core mechanics to understand how they will relate to the intended challenges the player will face and the actions the main character will be able to perform

creating additional modes when necessary, such as tactical modes in a war game, or equipment modes in a role­playing game, documenting their perspective, interaction model and gameplay

designing levels that will bring to life the intended game experience using the components provided by the design (characters, challenges, actions, world, mechanics, story), starting from the first playable level (important future milestone) and leaving space for level designers to continue their work

writing the story if there is one, as they help to keep the player interested and involved, and act as motivation to the player’s actions as they go through the levels; it may be linear or nonlinear, with optional quests and different kinds of progression

building, testing, and iterating through the various versions of the game, as the underlying principle behind game development states, prototyping various ideas and keeping the ones that work best, testing them at every step right from the start

Luckily, the game concept that we were elaborating required the completion of most of the tasks, so most of them will be referred to in the following sections.

Towards a better Game DesignRichard Rouse recommends keeping the design process and documentation organic and simple (Richard Rouse, pp 283­286). What he means is that overly long documents at an early stage are not useful, as the concept may still be flawed and needs playtesting and elaboration. He recommends developing the concept at a steady pace, allowing prototyping and playtests to validate it as the process go further.

Adding too much content too early or going from abstract to overly specific can only bring flaws and errors to the process. It is the designer’s role to always keep the right level of abstraction and the right amount of content in each process. Paul Schuytema states that adding just the right amount of detail is necessary in order to keep the design documents effective as blueprints of the final game (pp. 108­109).

Adams & Rollings (2007, pp 278­281) also recommend to focus on execution and fun, not focusing on innovation but execution, and finding the fun factor. To help carry out this process, they mention a series of principles which state the importance of gameplay over the rest of the

13

elements of the game (players’ actions), solid features (more valid to ship a game with few solid features than many broken ones) and player­centric design. They also recommend having a person with the vision of the game and keeping true to it.

Level DesignAs the others processes taking part of Game Design, it is also an iterative process. It is enriched by early input by artists, programmers and other designers, as they will take charge of developing the visual aspect and mechanics of the game, and should comment on the scope and feasibility of them. Adams and Rollings (2007, pp 418­421) recommend structuring the process into certain tasks, that the design group has divided in three small phases: Planning Phase, Prototyping Phase and Review Phase.

Planning Phase is, in short, about sketching the level itself, thinking of gameplay, challenge areas, triggers with certain events, storytelling, save points. It deals with determining the scope of the level, the required visual assets. Prototyping means building the prototype in a digital medium, getting the models and using placeholders to get a basic version on the level, upon which the level designer can iterate and playtest. Level review and refinement is about holding review meetings, getting the team members to playtest the game and give feedback, dealing with things such as scope, pacing, placement, performance and aesthetics.

Adams and Rollings (2007, pp. 400­404) also offer a series of principles, from which we highlight the importance of making the early levels tutorial levels, pacing the game correctly, keep the player informed of short­term goals and being clear about risks, rewards and consequences. Additionally, they recommend big rewards with small punishments and trying to implement difficulty settings, to keep players balanced with the game. Regarding action­adventure and role­playing games, they state that varying the pace, promoting character growth and player self­expression and offering location­based challenges and story development are the three most important principles to focus on.

Tuning StageBalancing and Polishing

The design group will not focus on this stage, as it falls out of the scope of the project, but will briefly describe the main points of it. In this stage, no more features may be added to the design, as the design enters a locked state. However, small design adjustments are still necessary, as balancing elements and core mechanics of the game is a priority.

Tuning and polishing the game is the main goal of this stage, and should be seen as a subtractive not an additive process, removing imperfections and making the game shine (Adams and Rollings, 2007, pp. 59­60).

14

Game Design Process in Freja’s Journey

Conceptualization Stage

The concept stage was atypical in the sense that, when we joined the team, a basic game idea had already been established. They had the feel of the game in their head and were trying to get it down to a document, albeit focusing too much on certain elements (like story progression) but being too vague in mechanics (like fighting, items and equipment, quests). The design team helped them develop those ideas, simplifying the concept and making it work for their target audience.

Assessing Initial PitchFrom the beginning of the project, the Tinysaurus team had a vague idea of the game they wanted (with a very high level of abstractions and plenty of unexplored points). They had talked to each other and agreed on basic mechanics, yet as these never got written down, the idea each individual had on its mind was, in fact, different. This was the starting point of the project, as the design group began to polish this idea.

We deeply read the pitch document that they had made and held a first game idea meeting with them, where the main ideas of the game were discussed and written down. Moreover, we got information on the client’s intended target audience and possible platforms.

The pitch document was overly long, but was effective in getting the idea across. They could effectively convey the feel of the game and main character, with their fascinating world based upon norse mythology and the story of a child in her quest of rescuing her family and friends.

The key words for their game were adventure game, engaging world and narrative, semi­casual and game for everyone. They had carefully crafted a world and adventure based on norse mythology, with vikings, goblins, trolls and various locations also derived from this mythology.

Conceptualization meetingsWe held a conceptualization meeting, where we gathered the main ideas, further developed them and made them fit together. Initially, the scope of the project was too broad and not suited for the target audience they expected. Furthermore, there were many elements that had not been discussed yet, such as supporting characters and how level progression adapts to the story progression they had planned.

Original IdeaThe team originally wanted a 3D side­scrolling adventure game with a fighting system (which they had not developed), items (that you can buy or found and use at any time), quest system (with rewards), equipment (weapons, armor, accessories, magic runes, which you can buy or find) and big magic runes, which change properties. They had talked about having status effects, elemental attacks and achievements.

15

The fighting model they wanted included levels, active stats (such as strength, willpower, endurance), passive stats (Damage, Protection, Magic), Energy and skills (becoming stronger for some time). They wanted accessories to enable the player to use magic attacks or have elemental attacks in their weapon. They wanted different types of weapons that worked differently (axes, hammers, maces, swords) and different types of armor.

The game idea did not fit its intended audience, as the complexity of the system was too high, the mechanics did not fit with one another and were not coherent and harmonic. A meeting with them was held to adjust the scope of the project, and decisions were made to reduce the basic idea to a feasible concept.

Simplified IdeaIn the meeting, we decided to merge many concepts, remove the complex ones, and make a system easy and understandable. This allowed us to create a simple System Image for the game, enabling users to create their own User Models in a more intuitive way, with a much more intuitive mapping between the controls and the gameplay (Donald A. Norman, pp. 12­26).

Firstly, the players’ actions were discussed. The player can walk/run, attack, block, jump, perform combo moves and interact with townsfolk. The player can also build up energy, and unleash a special attack when enough energy has been built up.

Secondly, the whole stats model was heavily simplified, removing active and passive stats, leaving only 5 basic, intuitive stats: Strength, Agility, HP, Vitality and Limit Energy. Strength would affect the attack power, agility the speed, HP the player’s life, vitality its defense, and limit energy would establish the frequency with which the player can use special attacks. It was important to create a simple enough interaction model for the player to understand and manage (Adams and Rollings, 2003, pp. 358­361).

Leveling up would allocate stats automatically, allowing the player to choose one stat to give a bonus point to. Enemies would level up as the player levels up, in order to carefully control the difficulty for each player.

Regarding equipment, it was cut down to weapons and armor only, removing accessories and magic runes. Different types of weapons have small differences, but have the same combo moves and way of attacking. Some may have an elemental property embedded, which may offer resistance to fire, or ice­based attacks, etc.

Achievements, quests and equipment were combined, having equipment be the reward of fulfilling quests, with only one of each piece of equipment in the world (working as a collectible). Quests can be undertaken from the city hub and viewed from the main world map.

A very basic inventory system was developed, being able to buy 2 types of items (HP potions

16

and Energy Elixirs) and use them in any combat.

ResultThe final concept’s complexity finally suited a semi­casual audience much better, leaving space to cut certain elements (different types of weapons, different special attacks) if the playtest showed that the concept was still too complex.

After rounding up the concept idea, the Game Concept Document was crafted by the designers, including every element from the game idea. After validating the document with the client, the design group made sure to possess all the vital elements needed to move to the next phase.

Elaboration Stage

Towards a Game Design DocumentWith all of the concepts in a basic level of understanding and abstraction, we developed the concepts further. This lead us to find different problems in the concept, and mechanics that were still vague. Specifying these mechanics in a lower level of abstraction enabled us to develop them and understand them better.

Game ModesFour game modes were defined, to explain the game better: Menu mode, World mode, Village mode and Combat mode. The first two deal with stats, equipment and levels. Village mode involved exploring villages, talking to townsfolk, taking on quests and buying items. Combat mode involved fighting with enemies, being able to attack and perform combo moves.

Fighting SystemThe fighting system and controls were still vague, so we developed them. We held a creative brainstorming session and discussed various possibilities for the combat, finally settling down for a simple one­button attack with different possible combinations according to their timing and the character’s position (ground, mid­air, air).

Combos such as ground combo (attack on ground), upwards slash (attack while beginning to jump), air combo (attack while in mid­air), downward thrust (attack while falling) and round attack (charge a powerful attack and unleash the attack button) came up.

EnemiesTo better fit the different combos, enemies were changed to appear intuitive to these combos: tall enemies would have to be knocked down with air combos, short enemies could be attacked from above with downward thrust and armed enemies would have to be disarmed by blocking and counter­attacking. Enemies would be able to be defeated using normal fighting skills, but these special tactics could be used to dispose of enemies in a more effective way.

Furthermore, different types of enemies were developed, with small differences between one

17

another (such as normal goblin, armed goblin and goblin soldier). This would prove to be useful as artists can reuse models with small differences in equipment but big differences in tactics.

Bosses were also defined, with the game flow being different from normal enemies, as these have certain attack patterns and tactics to be destroyed.

Quest SystemThe whole narrative is divided in quests: mandatory quests (advance the story and open up new areas) and optional quests (revisit old areas and learn background story). Quests are divided in three types: defeating an enemy, rescuing a villager and finding a hidden treasure in certain level. These quests are collected automatically and may be fulfilled simultaneously whenever the player visits the level, with a messenger delivering the corresponding item/villager to the city, and giving the player its reward.

Level DesignThe team of artists had an idea of the levels they wanted, but the design team helped themdevelop them. We developed one prototype level that would include many main mechanics,portraying the game feel of adventure the artists intended.

Initially, the level would feature exploring a forest, going to a village and battling some goblins.The combat part was further developed, with the goblins wanting to steal food from the village,with the main character trying to prevent this. To add variety to this, the goblins progressivelybecome harder to beat (different goblin types appear), and a battle indicator appears to showhow the player is faring.

As the game is side­scrolling in 3D, a lane­system was developed to place each goblin in adifferent lane, so that the player is not overwhelmed while attacking the enemies.

The general level­progression was also discussed, but the team already had a progression inmind, which worked quite well. They divided the world in regions, each with their city hub (to takeon missions and buy items) and different areas according to the theme (fire volcano, mysticforest). The quest system was quite compatible with these progression as well, and made iteasy to the player to know how to progress further.

Prototyping and PlaytestingThe team agreed on making a small vertical slice of the mechanics, including fighting,exploration, a small cut­scene involving a villager, enemies and the visual style of the final game.

The fighting system was simplified for this playtest and items are not present, but it includes thefully animated and textured main character with a location (forest and village), a villager andgoblins. The enemies have tactics and position themselves in different lanes according to theirpeers, and will attack Freja or run away if outnumbered. The battle shown is a timed battle, asFreja needs to run from one edge of the town to another, trying to prevent the goblins from

18

stealing carts with food.

The fantasy of the game and the players’ actions can be understood from the prototype, whichwas the focus we all wanted to give.

ConclusionTo sum up, the process was very enlightening, and quite motivating for all members of the team. The artists and designers developed a bond of trust between one another, which motivated both parties to work more, with artists giving the initial ideas and art and the designers polishing the idea into a concept, and later, into a design, and crafting a prototype of the game.

The close contact between all team members made the concept and prototype much easier to develop, as the design team could take control of the different phases, with the support of the artist team.

The project went through the concept phase successfully and executed part of the elaboration stage with high­satisfaction from the team. The design team progressively lowered the concept’s level of abstraction and specified mechanics in higher detail as the initial prototype was being developed. We could make use of the feedback we received from the artist team playtesting the prototype and our own observations while playing it, which enabled us to develop more accurate mechanics, keeping the documentation organic and simple, and in close relation to the game developed.

19

SummaryThis project has been a successful case study of a well­documented and executed game design process, which has satisfied all members of the team.

In the process of writing this report, we have mostly learned about the importance of documentation throughout the game design process and the role of game design in the game development process.

We have also first­hand experienced the need for proper game design documentation, when working with other people’s visions. Being able to work with them on developing it has also been a great way to experience this aspect of game development from both a designer’s perspective as well as a programmer’s.

Our role in this project has mostly been polishing the initial idea and turning it into a concept that would fit the intended target audience and scope. After that, we were responsible for developing vague mechanics into detailed and coherent mechanics, which together integrate a cohesive and harmonic design. We took part in both game design and level design, and also prototyped a first vertical slice of the game. In the process, we learnt a lot about practical tools, such as Unity and Mechanim, and how to integrate 3D assets into a project and animate characters.

To sum up, it has been a very useful experience to both of us, and the learning experience we got from this project will be very useful for us in the future, in our roles of game designer and game developer.

20

References

Literature:A. Rollings and E. Adams (2007). Game Design and Development. Fundamentals of Game Design

A. Rollings and E. Adams (2003). Andrew Rollings and Ernest Adams on Game Design

R. Rouse III (2005). Game Design Theory and Practice. 2nd Edition

J. Schell (2008). The Art of Game Design

Donald A. Norman (1988), The Design of Everyday Things

P. Schuytema (2007), Game Design A Practical Approach

Online Articles:T, Ryan (1999), The Anatomy of a Design Document, Part 1: Documentation Guidelines for theGame Concept and Proposalhttp://www.gamasutra.com/view/feature/3384/the_anatomy_of_a_design_document_.php

T, Ryan (1999), The Anatomy of a Design Document, Part 2: Documentation Guidelines for theFunctional and Technical Specificationshttp://www.gamasutra.com/view/feature/3411/the_anatomy_of_a_design_document_.php

T. Freeman (1997), Creating a Great Design Documenthttp://www.gamasutra.com/view/feature/3224/creating_a_great_design_document.php

21

Appendix

Appendix A - Excerpt of Game Design Document

2 Gameplay

2.1 Overview and Story ProgressionFreja’s Journey is a 3D side­scrolling adventure game with light RPG elements, aimed at a semi­casual public, for gamers that want experiences with more depth than most casual games. The game features fighting, exploration and quest­fulfilling mechanics in an interesting world based in the Norse Mythology.

The game tells the story of a Viking Kid in a quest to rescue her family. The story is divided in different quests: compulsary quests that move the story forward, and optional quests, that feature small sub­plots and tell Freja background information about villagers and the world.

2.1.1 Player’s objective The player’s main objective is to help Freja rescue her family, exploring the world

around her and defeating enemies in each stage The player’s secondary objective is to fulfill the quests that are given to Freja in order to

get rewards and items, and become more powerful

2.1.2 Game Modes

2.1.2.1 Village ModeWhen Freja’s inside a town and no enemies are around, Village Mode is activated. This mode lets Freja explore her surroundings and talk to villagers and merchants. She can’t attack in this mode, but she can jump to get to new places.

2.1.2.2 Combat ModeWhen enemies appear, Combat Mode is initiated, where Freja can attack the enemies that surround her. She can jump, attack with her weapon, unleash combos and use items.

2.1.2.3 Main MenuWhen the player pauses the game, he/she enters the game menu, where information about Freja, her equipment, quests and abilities are seen. From there, the player can select new equipment or change the abilities assigned to Freja.

The main screens of the Main Menu are: Stats, Equipment, Quest Log

22

2.1.2.4 World MapIn order to traverse the world, Freja can choose what area to enter from the World Map. The World Map is divided in regions, each of them divided in different areas (villages or dungeons).

Every village and dungeon are shown and represented in the World Map, with a small description of the quests and items in each place. Cities and compulsory dungeons are represented in the main road, whereas optional dungeons and secret areas pop up on the sides of main areas.

<Drawing of Main Map needed>

New areas appear in the World Map as Freja completes Compulsory and Optional quests. Freja does not have to replay old areas to move from one place to the other, but can simply skip old areas, being able to go back to town to buy new equipment.

2.2 Game Mechanics

2.2.1 Main Character

2.2.1.1 Main MovementsFreja’s normal movements are: walking, running, jumping, double­jumping, attacking, blocking and unleashing combos.

Walking and Running: Freja explores the world by moving around. She will automatically walk or run depending in what Game Mode she is in.

Jumping and Double Jumping: When pressing the jump button, Freja will jump high in the sky. If pressed again while in mid­air, Freja will jump again performing an acrobatic roll. This enables her to evade some attacks and reach higher places.

Attacking and Combos: The game has one attack button, but many easy and intuitive combinations (see 2.2.2.1 Moves and Combos).

Blocking: Freja can block enemy attacks with her shield, allowing her to knock back the enemy and counter.

2.2.1.2 Stats and Leveling­UpFreja has 5 basic stats: Strength, Agility, HP, Vitality and Limit Energy.

Strength affects how strong she hits Agility changes the speed with which Freja moves and attacks HP represents Freja’s life

23

Vitality is Freja’s defense against the enemy Limit Energy affects Freja’s limit abilities (see 2.2.1.3 Limit Abilities)

Freja will earn experience as she defeats the enemies that surround her. When she gets enough experience, she will level­up one level, with her stats being automatically updated. The player can put 1 bonus point in a stat he/she chooses, in order to let the player create his own fighting style.

The enemies in the game will level­up automatically as Freja levels up, keeping their strategies but improving their stats, to keep a basic level of challenge in the game.

2.2.1.3 Limit abilitiesFreja has a limit bar that gets filled as she hits the enemies and gets hit. When it gets full, she can unleash a powerful limit attack, being able to overturn the tide of battle.

She learns new limit abilities as she levels up and can choose which to use from the main menu.

List of limit abilities: Viking Rage: Freja’s speed is doubled, her strength increases and she becomes

invincible temporarily Healing Pulse: Freja is surrounded by a healing force field that cures her health

constantly for a limited time Powerful Shield: A force field surrounds Freja. Her defense increases and she can’t be

knocked down

2.2.2.4 EquipmentFreja may equip a weapon and a piece of armor. Generally, weapons improve her strength and armor improve her life and vitality.

There are 3 types of weapons: swords, axes and maces. Swords are average in damage and speed, axe damage is more erratic and critical hits may occur, and maces are slower to use but hit stronger.

There are weapons with special abilities in the game. Some may inflict a status effect on the enemy (poison, burn, freeze, stun) while others may possess elemental properties (fire, ice, wind), adding them to Freja’s attacks and defending her from these kind of attacks (see 2.2.2.5 Status Effects and Elemental Attacks).

Many weapons and pieces of armor are hidden in dungeons or can be bought from merchants. There’s only one of each type in the world, and Freja can select which one to equip from the Equipment Screen. (I.e.: there’s only one Fire Sword in the world, which can be found

24

inside “Fiery Volcano Area”).

Weapons and Armor may be bought or found but never sold. They will appear in the Equipment Screen as “found” or “not found”, as means of a percentage of completion of the game.

2.2.2.5 ItemsFreja can buy and use 2 types of items: potions and elixirs. Potions heal a percentage of her HP, and Elixirs fill her Limit Bar.

These items can be used from Combat Mode or Village Mode without the need to enter the Main Menu Screen.

2.2.2 Combat and EnemiesCombat in the game is fast­paced, with Freja unleashing streams of combos into the enemies, evading their attacks and disarming them. Enemies have different pieces of equipment (helmets, shields, armor) and can be disarmed if attacked effectively.

When the player disarms the enemy, its defense lowers down, and it’s easier to attack it.

2.2.2.1 Moves and CombosThe game features only one attack button, but different combos can be triggered according to Freja’s position (jumping, on ground) and whether the player presses buttons quickly or charges up for a heavier attack.

The game’s combat adapts well to a med­casual public, as there are few buttons but many different combinations.

Freja’s Moves Ground combo: While on the ground, Freja hits up to 4 times. The last hit knocks

enemies down Upwards Slash: If the attack button is pressed when Freja starts to jump, an upwards

slash is executed. This upwards movement allows Freja to take off helmets from enemies and disarm them

Air Combo: While in mid­air, Freja can hit continuously up to 3 times. Downward Thrust: When landing from a jump, Freja can perform a downward thrust,

allowing him to attack fallen enemies and break their armor Round Attack: If Freja is surrounded by enemies, by charging the attack button she can

perform a Round Attack, knocking most enemies down and pulling them away from her

25

2.2.2.2 Blocking attacks and Knocking­down enemiesFreja and the enemy can be Knocked­Down. This implies them falling back to the ground and interrupting any ongoing combo.

Freja can also shield herself from enemy attacks by blocking. Some enemies start by attacking heavily, and Freja must block their attack to prevent being knocked­down. Most enemies will fall back when blocked, giving Freja a chance to counterattack.

2.2.2.3 Enemies and RacesThere are several enemies in the world. They are classified in 4 main races: Goblins, Trolls, Gnomes and Yetis

Each race is further divided into different types (I.e: Slimy Goblin, Fire Troll, etc), each with its own AI, moves and equipment, retaining a similar appearance but with some aesthetic changes.

Enemy Name Description AI and Strategy to Beat

Slimy Goblin<images>

They are the weakest type of Goblins. They don’t have any armor but fight with clubs and wooden swords. No special move is required to beat them.

They will attack Freja when she comes into range, waiting for a couple of seconds and then rushing at her. They can’t block.

Fire Troll They are a strong type of Troll that lives in fiery places. They can stand extreme heat and attack with fire weapons. They have no armor but use weapons and shields.

They are very tall, so Freja must use jumping combos to defeat it. They will block when they see Freja and then charge a slow but strong attack. They are difficult to knock­down.

Soldier Yeti They are a very strong breed of Yetis, knowing battle tactics and wearing different types of armor.

They are strong and armed, so Freja must effectively disarm them to be able to beat them. They usually wear a helmet and an armor, which can be removed with an upwards slash and downward thrust respectively (see 2.2.2.1 Moves and Combos).

Enemies level­up automatically with Freja in order to maintain a level of challenge in the game. The higher the enemy level, the greater the money it carries and the higher the chance of them dropping a special item, so grinding levels is still rewarding

26

2.2.2.4 BossesApart from normal enemies, Freja will encounter a variety of Bosses guarding certain areas. The strategy with these enemies is different, as they’re much more active when attacking Freja, and the player has to follow certain patterns (evading attacks) and looking for a weak spot in their attack.

2.2.2.5 StrategiesThe equipment the enemy carries is a very intuitive and visual hint on how to beat it

Enemies carrying helmets must be attacked with an upwards slash in order to remove it

Enemies that have an armor must be knocked down and disarmed with a downward thrust

Tall enemies must be attacked with air combos in order to get more damage Small enemies can be knocked down easily with a round attack

2.2.2.7 Elemental RunestonesEvery once in a while, Freja will come across a Magical Elemental Runestone. If activated, these stones give Freja power, and allow her to greatly improve her speed, strength or vitality for a limited period of time.

2.2.3 QuestsIn her Journey, Freja will have mandatory quests and optional quests.

Mandatory quests are connected to the main storyline and how it advances, so they must be completed in order to continue the adventure

Optional quests open up alternative areas, and allow Freja to pursue secondary objectives and acquire better equipment

Each quest is given by a villager in the city and has a different objective. Freja does not have to accept or deny the quest, as all quests are saved in the Quest Log (Main Menu).

Defeating certain enemy in an area Rescuing a villager from a dungeon Finding hidden treasure and returning it to villagers

From the World Map, in each area Freja can enter, the list of Quests to be fulfilled and Equipment to be found in the area can be seen

The player does not need to select a specific quest, as they are all compatible, and a player may fulfill all in the same area playthrough

2.2.3.1 World Map Messenger SystemAfter a quest has been completed, the player doesn’t have to return to the villager who gave him the quest. A messenger will appear in the World Map and give him the reward.

27

The quest will appear as fulfilled in the Quest Log and World Map.

2.2.4 World Map, Villages, DungeonsThe World Map is divided in 3 main regions.

28

Appendix B - Game Concept Document

Project Info

Working Title: Freja’s Journey

Genre: 3D side­scrolling action­adventure

Platforms: iOS / Android / Windows 8

Game Modes: Single Player

Audience: 9+

Description

Freja’s Journey is a 3D side­scrolling, semi­casual action­adventure game where the player takes on the role of Freja, a kid viking, in her quest to rescue her family and friends from the evil goblins and trolls that have invaded her hometown.

Her journey will take her through forests, icy mountains and powerful fortresses in this rich world based in Norse Mythology. Players will be able to use different weapons and customize their character in order to fight the enemies and restore peace to the cities.

With beautiful game art, a character growth system and a semi­casual quest and fighting system, every player will be able to complete quests and help Freja reunite with her family.

Setting

The game takes place in a world based in Norse Mythology, with locations such as green fields and forests of Midgard, the icy mountains in Jotunheim, and the mighty fortress of Asgard, and enemies such as Goblins, Trolls and more. The protagonist is a kid viking whose village has been raided and her family kidnapped.

In a quest to attain personal growth, Freja embarks on a journey that will take her to the edges of the world in order to get back with her family and defeat evil in the world, helping the villages she goes through, making new friends and attaining powerful equipment and abilities.

With a simple but deep combat system, a fun quest system and achievements, the game will prove to be ideal for semi­casual players looking for an adventure with depth and action.

29

Core Mechanics

Game The game is a 3D side­scrolling adventure game with fighting and character

growth, where the player controls a kid viking The objective is to help her rescue her family, fighting the enemies around her and helping

nearby cities and villagers

Gameplay The player can walk, run, jump, attack, block and perform special combos Combos are a combination of moves, progressively unlocked during the adventure The game involves exploring levels, visiting towns, fulfilling quests and fighting enemies

and bosses There are several collectibles to be found

Game World The game world is based on Norse Mythology, with important locations such as the forests

of Midgard, the icy mountains in Jotunheim, and the mighty fortress of Asgard The characters and enemies all fit into this world, as they are vikings, goblins, trolls, etc

Stats, Fighting and Equipment Freja has 5 basic stats: Strength, HP, Agility, Vitality and Energy Freja can use different moves and combinations to attack in different ways (upwards,

downwards, mid­air) Each enemy has certain move weakness that the player can exploit Freja can use a special attack when she gathers enough energy Freja will level up throughout the journey as she defeats enemies

Quests and Levels There are several quests for the player to undertake Mandatory quests advance the story and unlock new levels Optional quests give backstory details and rewards to the player

Visual Art, Music and Feel The game will feature 3D cartoony yet realistic visual art with a colorful environment

and a cheerful setting The music will be range from mysterious (when exploring) to adventurous and fast­paced

(when fighting)

30

References

The game plays like a mix of a 3D adventure game but with a fighting and growth system reminiscent to action RPG games.

The Legend of Zelda: The Wind Waker

The tone of the game is light­hearted and cheerful, with comical characters and quests

The battle system is similar to the Ys RPG series, with a simple but deep fighting system

Risks

The game’s setting should appeal to the target audience, with the narrative being light but motivating the player to continue the adventure

The game should comply with the semi­casual target audience of the game. If too complex, it should be simplified.

The game is quite ambitious in the art department, but this makes the world very tangible and colorful. The assets should be closely managed.

31