Hyprions - a serious game by Nanda Dias

HYPRIONS FINAL REPORT

DEVELOPED BY Alexander Firsanov; Ashish Vaishya; Daniel Weidner; Fernanda Dias; Hector Baide; Martina Malinowski; Martha Damus; Preslav Rachev; Steffen Sass; Tim Ă&#x2013;tting; Xeni Prassa.

TABLE OF CONTENTS 1. INTRODUCTION

2. HYPRIONS GAME

2.1 Team Members

2.2 Game Proposal

2.3 Target Group

2.4 Name

3. TOPIC & STORY

4. CONCEPT

4.1 General description

4.2 Gameplay description

5. PROGRAMMING

5.1 From Cross-Platform to “Windows Only”

5.2 Reinventing the Wheel

5.3 The Honey Cube Engine

5.4 Hyprions - The Game

5.5 About Ambitions - Why we failed?

6. VISUALS

6.1. The world

6.3 The Buildings

7. USER INTERFACE

7.1 User Interface Elements

7.2 Interface Summary

8. LOGOTYPE DESIGN

9. ANIMATION

10. SOUND DESIGN

11. EVALUATION

11.1 GUI Evaluation analysis

11.2 Analysis of the Writing Style Paper test

12. CONCLUSION

13. APPENDIX

64 3

1. INTRODUCTION

This document initially named “The HYPRIONS BIBLE” was generated since the first semester of the project. The main purpose of the “bible” was to serve as a guideline for the project members. Such document was updated from time to time displaying the main changes and developments occurred. The Bible served as the main basis for the HYPRIONS final report finalization. This final report delivers the results achieved by all the sub-groups. This document describes some decision making and often highlights the final results of the project rather than keeping track of every single initial states and phases developed during the ten months of project. Every sub-group was responsible for the writing of its own chapter. The respective authors can be found as foot notes in every page. Some paragraphs were written alternately by different authors (especially in the programming part). To identify the respective authors more easily their names are put in square brackets at the beginning and the end of a paragraph ([>] indicates the appearance of a new author, [<] indicates the end). The design and revision of this report was made by Fernanda Dias. The text coherence check and the second text revision was made by Martha Damus.

author: Fernanda Dias

2. HYPRIONS GAME

HYPRIONS is a serious game project developed by a team of eleven members, in one year time. It is being developed at the Hochschule Bremerhaven, in the Digital Media Masters of Science Program, in the summer term 2011 and the winter term 2011/12. The project was coordinated by the Professor Dr. Ulrike Erb.

2.1 TEAM MEMBERS

The team was formed by different backgrounds and nationalities: Brazil, Bulgaria, Germany, Greece, Honduras, India, Poland and Russia are their nationalities and graphic design, fine arts, informatics, digital media, music, marketing/ PR and science of communication are their academic backgrounds. The tasks were divided into different dynamically changing sub groups or individual working fields with the following staff: PROGRAMMING: Daniel Weidner, Steffen Sass, Preslav Rachev, Tim Ötting VISUAL DESIGN (3D objects, animation, colors): Tim Ötting, Martha Damus, Martina Malinowski, Ashish Vaishya, Alexander Firsanov INTERFACE DESIGN: Alexander Firsanov, Fernanda Sa Dias LOGO DESIGN: Alexander Firsanov SOUND DESIGN:

Hector Baide, Martha Damus, Xeni Prassa CONCEPT: Hector Baide, Xeni Prassa, Fernanda Sa Dias PROJECT MANAGEMENT: Steffen Sass, Hector Baide, Martina Malinowski, Martha Damus PROJECT SUPERVISION: Prof. Ulrike Erb author: Martha Damus

2.2 GAME PROPOSAL

2.3 TARGET GROUP

The game proposal was initially to unify “game + book The HYPRIONS project has a wide range target group. + web 2.0”

in a product to be used for educational The target is not limited by gender or nationality and it

purposes. The book proposal was removed from the is recommended to 14+ years old players. The group had scope of the project, which changed to a game with the challenge of developing a global language in order educational purposes only. Nevertheless it is acceptable to communicate to all of the instances of its consumers. to say that the fact that we are delivering real content to the public through the gameplay it could be interpreted The team members had decided on delivering the as a “book designed as a game”. The web 2.0 was achieved content based on irony and sarcasm mood. The player by the implementation of the Pulse explained in depth in will learn destroying the planet earth and not actually further chapters.

“saving it”. The reverse psychology tone must be the first differential of the HYPRIONS game.

The scope of the project was decided after a number of debates within the group during the first meetings in march and april 2011.

2.4 NAME [>Hector Baide]

A single book content will not be found in the game as a mirror or in an immediate way. However, the game will The name HYPRIONS was voted after a selection of certainly deliver consistent educational content. It was names offered by the Concept Group in July 2011. decided by the group in the first month of work that the content should be on environmental issues caused by The name Hyprions comes from the combination of two human intervention, more specifically was chosen the words: Hyper which indicates that something is above energy management topic.

and beyond another from its class and Prions, which are infectious agents composed of proteins that infect

Many discussions were made on how to deliver the mammals and cause terminal brain diseases. The idea content of the game. The first step was to state that was to relate the influence of the alien on the humans the game should not educate or display content as “an to an advanced biological technology, which reveals the electronic encyclopedia”. It was one of the first goals stealthy ways on which the race of our protagonist acts. established: “The importance of producing a fun game Therefore, a Hyprion would be a highly developed strain above all the laws”. Many studies prove this point. If the of artificially designed prions which engulfs its victims game is educational but massively “polluted” with texts and makes them act in ways that benefit the attacker. or spoken content it will turn into a boring acivity to the This touches multiple references to doomsday scenarios, player, particularly for children and teenagers. If the such as a killer virus or the uncontrolled development game is not enjoyable, it will be immediately discarded and propagation of malfunctioning nanotechnology. by its players. They will lose their interest and motivation as soon as a screen full of words pops up. The action and It was also created to avoid direct allusions to ecological fun aspects were the main challenge for this team! disasters and environmentalism, to keep the game set in a neutral tone and to make the procedure of manipulating minds explainable in an approximately scientifically plausible way. [Hector Baide<]

author: Fernanda Dias

3. TOPIC & STORY

The HYPRIONS game deals with the topic of energy management and human (anthropogenic) caused climate change. This topic should be obviously connected to the whole game background story. “Zu den wichtigsten (vom Menschen ausgehenden Ursachen des Klimawandels) gehören: der Verbrauch von Ressourcen und fossilen Energieträgern, die demographische Entwicklung, fortschreitende Globalisierung der Weltwirtschaft und der technologische Fortschritt.“ (Schaefer, Ina, 2008: http://www.bpb.de/themen/LMZKSN,0,0,Der_Mensch_als_Klimaver%E4nderer.html, 19.1.2012)

Summarising, the main human caused problems considered responsible for the climate change are: Consumption of resources and fossil fuels (no sustainable energy mix, too many coal powered plants etc.); Demographic development; Progress of globalization of world economy; Growing industry/technology (increasing number of new electronic devices, cars, aircrafts, etc. require more and more energy and produce a big amount of carbon dioxide). To meet the learning objectives, those real daily life activities and facts of us humans should play a role in the game. To a fictive objective mind, that observes humans on earth, it should seem as humans do not care about their environment or even intent to destroy it. Moreover, that humans are quite advanced, but not smart enough to help themselves to keep the balance between powerful technology and a healthy eco system. In general, that they require too much of everything and kill those beings, that are less powerful as themselves (their natural environment). The alien in our game functions as a metaphor of human destruction of our own planet by drawing the reversal conclusion: the story of an alien that does not care about environment, kills less powerful beings, etc. As a consequence, the background story of our game is the following one: Because of overpopulation of the aliens‘ home planet, he/she was traveling through space and looking for new planets to settle his/her race. Of course, the new planet had to fulfill certain preconditions. As the alien breathes carbon di-oxide, it needs an “unbalanced” eco system. Also, the inhabitants of the planet should be weak minded and therefore easy to influence to make them work as his/her slaves, before later erasing them completely. Moreover, as the alien is a quite advanced being on the technical field, he/she requires a big amount of energy every day. Planet earth now seems to meet those requirements perfectly! The inhabitants are mostly string puppets of money, spoiled their natural environment already a lot and do not learn much from their mistakes in the past. Best conditions to settle here!

author: Martha Damus

4. CONCEPT

4.1 GENERAL DESCRIPTION Health properties (dependent from the geological HYPRIONS is a real time strategy game on which the player influences the earthÂ´s inhabitants to construct, properties): destroy or protect energy production facilities with AirHealth, GroundHealth, WaterHealth, TerrainHealth the objective of polluting the environment and create disasters.

Conditional properties: RecoverableStatus, Playable

4.2 GAMEPLAY DESCRIPTION

Area Units Characterization Properties Settled: Applicable to terrain units which have geological

4.2.1 GAME OBJECTIVE

properties ground or shoreline. Determines that the

Pollute the environment until it becomes uninhabitable. damage of this terrain unit will potentiate the citizens This is described in detail on the next section.

inclination to green. It is also a requirement for some buildings.

4.2.2 DESCRIPTION OF GAME ELEMENTS Game objective (game units)

Mineable: Applicable to terrain units with any geological

Reach a level of global terrain health of 30% or less property. Requirement for some buildings. (uninhabitable). Running or Still: Property always and exclusively attached GlobalTerrainHealth is the average of the health of all to water, not relevant for terrain units with other playable terrain units.

geological properties. Mutually exclusive, determines whether a building needing running water can be built or

Terrain

not (f. ex. Hydroelectric power plants need to be near a

The terrain is measured in squares in a grid. Each terrain source of running water to work). unit has the following properties: Characterization properties:

Terrain Health

settled, mineable, running or still

A global health is assigned to every playable terrain unit, composed by a weighted mix of the different health

Geological properties:

properties of the terrain values.

ground, water, shorelin

The weight of the value of each terrain unit depends on the geological condition it has and the associated health

author: Hector Baide / Xeni Prassa

values for each condition. A table with the different possible conditions is presented afterwards. The values of the health are absolute values ranging from 0 to 100, but the weight each one has is different on each type geological condition of terrain. Geological Properties table Geological property

AirHealth

GroundHealth

WaterHealth

Ground

Yes

Water

Yes

Shoreline

Yes

Weights of the health dependent on terrain properties Ground, Settled = AirHealth 65%, GroundHealth 25% Ground, Mineable = AirHealth 50%, GroundHealth 50% Water, Still = WaterHealth 65%, GroundHealth 25% Water, Running = WaterHealth 50%, GroundHealth 50% Shoreline = AirHealth 50%, WaterHealth 30%, GroundHealth 20%

Conditional Properties Both recoverable status and playable determine game changing conditions for terrain units. The playable property defines terrain with which the player can interact. The reason for having this is to have lockable terrain or terrain which can be accessed after certain objectives are met (similar to the “fog of war” idea but in an objective minded sense). The recoverable status determines if a terrain has reached a “point of no return” meaning that the healing properties of the pollution percentages have been lost and the terrain has become unlivable. The TerrainHealth value for an unrecoverable terrain unit is 30 or less. 4.2.2.1 Citizens and leaders ABOUT THE CITIZENS The citizens are the main operators in the game. They determine whether things are built or destroyed, and their balance in priorities shapes the outcome of the actions. They work with three basic properties Priority: Determines the inclination of a citizen within its acts of support. Health: Determines how influenced he/she is by the environment Charisma: Determines how much influence the citizen has towards its peers and his capabilities for becoming a Leader or a LeaderPlus

author: Hector Baide / Xeni Prassa

They can only exist in terrains which have the ground or shoreline properties and which have RecoverableStatus true (more than 30 on the TerrainHealth value). About the leaders Leaders are the citizens which are enabled to propose actions of building and destroying. They are both player and computer controlled and can lean towards creating buildings of any kind. They exist only while executing an action and return to normal citizen mode after the action is (successfully or unsuccessfully) completed. Leaders are controlled by the player and by the computer opponent. They are the executors of action and the only action unit available to the player. They can influence citizens into the construction and destruction of buildings and they can also move directed by the player. Influence Influence areas of the Leader and the LeaderPlus are illustrated in the following diagram.

FIG.1 LEADER AND LEADER + INFLUENCE AREA

author: Hector Baide / Xeni Prassa

Citizen behaviors Citizens are governed in their behavior by two factors: priorities and charisma. The priorities are influenced by the health, their interactions with other citizens and the influences of the leaders. A citizen can be inclined to the Greed or Green priorities. In order for a player to support an action, he must be 70% inclined to the side of the leader influence, f. ex. if a green leader decides to destroy a coal power plant, a citizen will support it if their inclination is at least 65% green. Greed inclination will make a citizen support the actions which will affect the environment in a destructive way, or in other words, actions which will lead to the decrease on the TerrainHealth value. Generally these actions will be initiated by the player. The opposite is also true for the green actions, generally made by the AI opponent. Health TerrainHealth (Pollution) over Health The value Health itself is controlled by a weighted mix of the AirHealth (45% influence), WaterHealth (35% influence) and GroundHealth (20% influence) values. When these values decrease below 50% they start affecting the health towards a negative value and when they are over 50% they start affecting the health towards a positive value. Health over inclination Health is a value which influences the priority of the citizens. It has a value from 0 to 100, which determines the intensity of the influence. At values over 60 it leans the citizen towards the greed side of the priorities, between 60 and 40 it has no influence in the inclination and below 40 it leans the citizen towards the green side. Charisma Charisma is a property of the citizens which determines their influence value and the outcome of conversations they have between each other. It also determines whether the citizen is able to become a leader or a leader+. It is determined by a value between 0 and 100. Citizens with more than 70 of Charisma are enabled to become leader+, below this level, they will become normal leader. Citizen interaction Citizens will interact with each other in the base of conversations on which they will compare each others inclination (whether itâ&#x20AC;&#x2122;s green or greed and depending on this equality or inequality several things can happen: If the inclination is equal, both citizens Charisma will increase by a 2 point value and their inclination will remain the same. If the inclination is different, the citizen with higher charisma will gain 5 charisma points, and will keep its inclination value (winner). The citizen with lower charisma will lose 5 charisma points and will alter its inclination 5 points towards the side of the winner. Support and influence areas Citizens under the influence area of a leader will start altering their inclination towards the inclination of the respective leader. This will be based on time (+5 on the inclination towards the inclination of the leader every X amount of seconds). If the inclination becomes higher than 70%, the citizen gets locked and supports the action.

author: Hector Baide / Xeni Prassa

The citizens keep on moving autonomously during this used energy production methods and most types of period unless they become locked. The conversation pollution consequences, which happen on all the stages of system stops for the citizens within an influence area.

energy production. Therefore, pollution would not come only from the production stage, for example, air being

LEADER ACTIONS

polluted by the burning of coal, but also represented in

A leader can be directed to do four actions. They are earlier stages of the process, for example, water being described in the next section

polluted by a spill of oil in a drilling platform.

Build / demolish

Behavior modifiers

This actions initiate the processes of building and The behavior modifier facilities have as a purpose to alter demolishing facilities.

the priorities of the citizens under their range of influence. They are built to make the citizens more interested in the

Move to place

greed orientation of their priorities. This is done in order

Moves the leader to a selected space within the game world. for them to be more likely to support the creation of buildings which affect negatively the environment. Attract Brings citizens closer or into the influence area of leaders. Some considered facilities were parks, hospitals and banks, mirroring the needs of equilibrium with the 4.2.2.2 Facilities

environment, health and money.

There are two types of facilities in the game: environmental modifiers and behavioral modifiers.

4.2.2.3 Catastrophes As a further gameplay element, catastrophes were

The idea of creating these two categories was to enable planned to catalyze the effect of the player actions, the player to pursue its objectives on different strategic and would accentuate dramatically the consequences fronts. The environmental modifiers are the tools for of unsustainable energy practices. These events would polluting directly the environment and the behavior happen both as an effect of a player action (for example modifiers give an edge to the player in controlling the an explosion in a coal plant) or as a random occurrence mind of the citizens. Based on the interplay of both which could have also accentuated the choices of a player categories of facilities, the player can build different (a nuclear plant meltdown after an earthquake). playing styles.

The exact implementation of this system was not developed because of time constraints.

Environmental modifiers 4.2.2.4 Pulse These facilities have the main purpose of cleaning or The pulse is the gameâ&#x20AC;&#x2122;s information delivery system. polluting an area of the game space.

It works on different levels as a gameplay assistant,

The direction or their influence (whether it is to pollute as an educational component and as a narrative or to clean), the extent of this influence and the time descriptor of the game. It is also designed to be needed to exert this influence depends on the type of extendable into an in game referent of real world the facility.

information with the integration to the pulse nexus, which will be described below.

This categorization was created with the idea of making it modular in order to accept or substitute different Tone and language buildings without altering the main design of the game. The Pulse messages are written in a language which tends Different energy facilities such as power plants of to color the messages in an ironic and playful tone. This different fuel origin (solar, nuclear, coal etc.) and different decision was taken after analyzing samples of writing in resource mining facilities were considered for inclusion on games of evil, computer characters, for example, GlaDOS the game. We tried to cover most of the types of widely from the game Portal or guide characters of strategy 12

author: Hector Baide / Xeni Prassa

games such as the fictionalized version of Gandhi in the Narrative descriptor Civilization games or the character which narrates in the The pulse tells the story of each game session by pointing game Tropico. This was done in an effort to lighten up the out to different events that happen as a consequence of tone of the game and engage the player through humor.

the player action. Each time the player completes a game

This writing style was validated as the most attractive session its experience will be different because the order one by the participants of our usability test (pp. 61), of its actions, the methods used to play the game and and while it was not considered to be the most neutral the reactions of the system will be different. The pulse one, it communicated the messages clearly and in an identifies different possible messages to be displayed entertaining way.

depending on preset conditions and because of the way it is designed, it would select different combinations in

Conceptual background

order to not tell too often the same story.

The main inspiration of the delivery of information in small sentences came from the very common social Educational component media interfaces existing in services like Twitter or Data related to consequences of the actions of the player Facebook and the achievement and trophy systems of is displayed in the pulse. The information is delivered in the XBOX360 and Playstation 3 game consoles. The idea a double layered way. In the first layer, a short message was to condense small information samples in a way that (less than 140 characters) roughly describes the event. was manageable and understandable to the player.

In the second layer and as an express request from the player, details are shown in the form of short stories

This information samples were linked to events happening which describe in a more detailed way the effects and in the game by tags, which were after associated with causes of the events. These messages are recorded in events that were inspired by real life effects of energy a log which enables the player to track what happened production. It was designed as a gateway for the player on the game and leads him/her to learn in successive to become interested in the process of creation of energy play sessions which strategies he/she could correct or and its consequences.

improve and how the events unfolded.

Non-gameplay information would also be displayed in This log was created with the Pulse Nexus extension in the pulse. This information would be related to the game mind. The Pulse Nexus would be a web service which world and by extension, would also be related to the real connected to a content provider, such as environmental world. Information such as protests by activists, relevant organizations, news outlets or governmental offices, statistics of pollution and other related information would connect events happening in the playerâ&#x20AC;&#x2122;s session would be displayed with the intention of communicating to real events that have happened or are happening at in a deeper way the relationship between energy and the moment. the condition of the human race. This also helps to characterize the game world and mirror its actions with Since every event is associated to various tags, these actions happening in the real world.

tags could also be applied to different media resources (text, audio, video, diagrams, animation, etc.) in order to

Gameplay assistance

connect them and create an analogy between the game

The pulse would communicate the major game events as world and the real world. This would also allow the player alerts and would point the player to relevant situations to learn about the topic in different depths and to learn occurring in the game world. It would also give the player as much or as little as he/she decides. a good idea about his/her progress and about possible threats to its intentions.

A picture of a proposed interface is shown on the next page.

author: Hector Baide / Xeni Prassa

FIG.2 PROPOSED PULSE NEXUS INTERFACE

author: Hector Baide / Xeni Prassa

5. PROGRAMMING

5.1 FROM CROSS-PLATFORM TO “WINDOWS ONLY”

[>Daniel Weidner] Today the consumption of digital media more and more moves from the classical desktop computer to a versatile set of mobile devices like smartphones, netbooks or notebooks. People play games now while waiting for the bus or while lying in the bed. What makes the overall human-computer interaction ways more comfortable and natural provides in return a huge challenge for the developers of interactive software and games. “How can we support a preferably huge amount of devices and system configurations?”. A keyword often referred to in this context is “platform-independence” 1. While not a new concept, cross-platform support has become a key feature for successful games since the increasing spread of new gaming devices. Even though it is desirable to maximize the number of supported devices and systems, to reach as many potential customers as possible, it does not come without any overhead. As an example components have to be modified or rewritten in order to work with different input technologies or a target device does simply not provide enough hardware resources for a certain [game] feature. Anyway, many commercial development environments provide separate modules which simplify this process. At the beginning of the project we headed for a cross-platform solution. As we already knew that HYPRIONS is going to be a 3d real-time strategy game, we had a given set of requirements the programming environment of choice had to fulfill. In total we invested more than four weeks to find an adequate environment. During this time we created several rudimental prototypes to test the individual environments and to get used to the different language syntaxes. Candidates tested have been: Java3D, Unity3D, Flash 10 with third party engines like Alternativa3D, Away3D, Papervision3D, Flash 11 Beta and the Stage3D API.

5.1.1 JAVA3D Talking about platform-independence Java is generally a programming language that comes to mind first. Programs written in Java are compiled to bytecode which can then be run on any java virtual machine2 regardless of the underlying system architecture. Furthermore Java is considered to be easy to learn as it provides automatic memory allocation and garbage collection (in contrast to C++). Java3D in that context is a 3D application programming interface (API) for Java which allows for general graphics programming and spatialized sound. Unfortunately Java3D did not provide hardware acceleration at the beginning of our project3 which makes the execution of complex 3d scenes almost impossible due to low runtime performance. 1

The terminology “platform-independence” or “cross-platform” is used when games, software or methods are implemented to operate on multiple platforms.

The Java Virtual Machine (JVM) executes the bytecode of an application and acts as an interface between application and operating system.

The latest release of the Java3D API from february 2012 includes wrappers for OpenGL and DirectX and therefore the missing hardware acceleration.

author: Daniel Weidner

Since our game concept requires to render a variety of characters, buildings and terrain units each frame we quickly reached the limits of the 3D API.

5.1.2 ADOBE FLASH Adobe provides with Flash and the object-oriented scripting language ActionScript a platform for the development of multimedia applications and games. The browser plugin â&#x20AC;&#x153;Adobe Flash Playerâ&#x20AC;? is widely spread and allows to run the application directly within the web browser. The plugin is available for most platforms including Windows, Linux and Mac OS (not iOS though). Furthermore the Adobe Integrated Runtime (AIR) allows, similar to the Java Virtual Machine, to run a flash application like a standard desktop application. Unfortunately Flash had no native 3D support at the beginning of our project nor support for hardware acceleration. Existing solutions like Alternativa3D, Away3D or Papervision3D tried to fill this gap but the missing hardware acceleration again reduced the resulting performance of complex 3d scenes intolerably. With Flash 11 Adobe introduced these missing functionalities with the Stage3D API in October 2011. Unfortunately we could not rely on these new technologies as during our research phase at that time only highly instable beta releases have been available to the public.

5.1.3 UNITY3D Unity3D is an integrated authoring tool for the creation of interactive 3D content. The game engine running behind the scenes of Unity3D ships with a powerful editor which helps designing and developing the content. While the editor is only available for Windows and Mac OSX, it is possible to release the actual game for additional platforms like iOs, Android, Xbox 360, PlayStation 3 and the Nintendo Wii. Unity3D has a huge user base which especially appreciates the good accessibility to game development through the editor. It makes creating the game world easy as moving 3d objects in space and attaching behavior scripts to create the game logic. As scripting language the user can choose between UnityScript, C# or Boo. Different to other examined solutions Unity3D is only free in its base version. For features like version control or deployment to mobile devices you have to purchase a license. Even though Unity3D would have provided us an ideal development platform for the creation of our game we had to reject it due to the missing possibilities of collaborative development in the free version at that time. Indeed we requested an educational license but the claimed license fees of $750 per seat did simply exceed the project budget.

5.1.4 MICROSOFT XNA - THE LESSER EVIL After testing so many different environments we had to take a step back and think about our requirements and resources. We learned the hard way that platform-independence has its shortcomings which (for us) may not justify the efforts necessary to implement a 3d game with acceptable performance. We refocused our project aim on having a decent prototype showing most of our game concept. Therefore the release of the game for different platforms comes second. Back to the beginning then? Not exactly. As all of the programmers had already good experience with the XNA Framework we decided to stop searching for further solutions and start implementing the game with a toolset we are already familiar with. The decision was in fact taken to avoid losing even more project time and might have deprived us of the opportunity to find a more suitable solution. Nonetheless at that time we had the feeling a decision must be taken to progress with the project.

author: Daniel Weidner

XNA provides an extensive set of class libraries specific to game development based on the .NET Framework. It is not supposed to be a full game engine but provides game developers with core concepts like a game loop or methods for graphics programming, sound streaming or input handling.

5.2 REINVENTING THE WHEEL - BIRTH OF THE HONEY CUBE ENGINE

XNA is not an engine, it is a framework. Consequently typical engine features like a scene graph, physics simulation or particle effects are not provided and have to be self implemented or introduced through third party solutions. Both has its advantages and disadvantages. A custom made engine allows us to tighten the functionality to the requirements of our game. We do not have to modify external code to get things running and more important we have a deeper understanding of what is going on “under the hood”. Furthermore it allows every member of the team to learn more about the components of an engine and their implementation. Creating an engine from scratch is not trivial though and can be very time consuming. Using existing solutions would allow us to directly start with the implementation of the gameplay. In addition they generally provide more features as they can look back on several years of development by an active community. In contrast it needs a certain induction period to learn the functionalities and concepts and possibly some support by the developers in case of missing features or arising bugs. So why have we decided to create a custom made engine then, if the primary aim of the project was to create a real time strategy game? The major reason was, that we haven’t been satisfied with the existing XNA engines available. Beside commercial projects like SunBurn or DigitalRune most solutions lack proper documentations. Some of the promising candidates are not even maintained any longer so we could not expect any support. Furthermore becoming acquainted with an engine which we might never use a second time was not the learning experience we hoped for during the master project. Consequently we decided to implement the necessary components on our own while using the knowledge already provided by the XNA community 4. It allows us to limit the functionality of the engine to our needs and to gather extensive and lasting knowledge about game engine architectures and their implementation.

5.3 THE HONEY CUBE ENGINE

The Honey Cube Engine is a game library providing classes and methods to quickly hook up elemental game components like a scene graph, a screen manager or an input manager. The engine is completely separated from the actual game implementation and can be included as simple dynamic link library (DLL) to every project. It does run without any external requirements apart from the XNA Framework 4.0. Subsystems of the HoneyCube engine inherit from the component interface provided by the framework (IGameComponent5) and therefore allow for a modular use of the provided features by the actual game (see “Utilizing the Engine” for more detail). The Honey Cube engine primarily focuses on essential functionality for 3d real time strategy games but with small additions it could be used for every kind of genre.

The XNA education catalog as an example provides an extensive collection of demonstrations about elemental game components like animation, collision and many more. 4

See the GameComponent class documentation for more detail http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.gamecomponent.aspx

author: Daniel Weidner

FIG. 3 HONEYCUBE IS THE WORKING TITLE OF OUR CUSTOM MADE GAME ENGINE. THE LOGO WAS CREATED BY SASHA (ALEXANDER FIRSANOV)

5.3.1 REQUIREMENTS AND NECESSARY FEATURES Before starting to implement it is advisable to analyze which features are actually necessary to realize the game concept and to decide on how those elements work and interact. Software engineering is a well elaborated field which suggests a variety of different methods and tools for this phase of development. A feature list as well as different kinds of UML Diagrams have been our tools of choice. In the following you have a short summary of game requirements from the beginning of the implementation phase extracted from the game design document:

“Hyprions is a 3d real time strategy game with educational purpose. The visuals are simplified and require a cubic environment similar to the one of the popular game “Minecraft”. The player is primarily interacting with autonomous citizens and different building facilities in the game world. Both of these entities will be textured and animated. The complexity of strategy games requires an extensible interface which allows to publish important game statistics for the player. Information needs to be attached to individual entities or to a fixed region of the screen. Audio and sound effects will support the gameplay and create atmosphere.”

This summary of necessary game features helped us to isolate the following necessary engine subsystems: Scene Management A proper scene management is essential to maintain all available game entities within the game world. After testing several approaches we decided to use an entity-component approach. In that approach the features of an entity

author: Daniel Weidner

will be determined by the components attached. A component in that context implements a certain behavior which influences in return the entity. All entities are additionally registered in a scene, which allows for communication between entities present in the same scene. Rendering System The Rendering System describes an interface to the graphics device of the system. It allows to easily register game entities for rendering and follows different strategies for performance optimization to avoid typical bottlenecks. Terrain Generation A strategy game generally needs to display a huge environment

which

part of the game world and describes a kind of playing field. In case of the HYPRIONS game this game world is supposed to be created of cubes of a given size and shape.

FIG.4 SCREENSHOT OF THE GAME MINECRAFT

Animation System Some of the 3d models used to represent the entities are animated using a 3d application like 3ds max or Maya. The engine allows to read and import those information and to display those models correctly within the game world. Artificial Intelligence (AI) In order to create the illusion of intelligence in computer games different strategies exist. The engine provides a combination of Behavior Trees and a Pathfinding algorithm to allow for autonomously walking and acting citizens. Input Manager The Input Manager provides an interface to query for the user inputs. The player will mainly interact with the game world using the mouse and keyboard. Support for gamepads or touch devices is not implemented. Graphical User Interface (GUI) The Honey Cube engine provides a base structure for interface elements which can be loaded from an XML file. All loaded elements are attached to a screen instance and maintained automatically by the engine using a Screen Manager. The implementations of the interface elements are flexible enough to get extended by the actual game. Audio System In order to allow for sound effects the Honey Cube provides a separate AudioManager which allows to play *.wav files in a cue19. A selection of the core components of those engine subsystems are discussed in more detail within the next chapters.

author: Daniel Weidner

5.3.2 CONTENT CENTRIC DESIGN: “BY THE POWER OF … XNA” Computer games are generally content driven real time applications. Game assets (content) are placed within a 3d world and scripts influence their overall appearance on the screen. Popular game engines like Unity3D apply this concept in perfection and make game development accessible to nearly everyone. Users can simply load a variety of different content types (e.g. 3d model or sound file) into the editor provided with the Unity engine and attach small programming scripts acting as behaviors on those entities in a drag-and-drop manner. XNA in contrast does not provide such an editor but a highly extensible content pipeline instead. The XNA Content Pipeline is a set of processes initiated on compile time when the game is attempting to load any kind of game asset. At the time the game is compiled every asset file has to run through the content pipeline and is transformed from its original file format to a custom data format in memory for runtime execution. The following diagram illustrates this process:

FIG.5 A VISUALIZATION OF THE PROCESSES TRIGGERED BY THE XNA CONTENT PIPELINE. FIGURE TAKEN FROM HTTP://MSDN.MICROSOFT. COM/EN-US/LIBRARY/BB447745.ASPX

The original content file is first imported and converted to an internal document tree holding all the parsed information. The XNA Framework does already provide a variety of default importers e.g. for XML files, FBX models or JPG images. After the file data is transformed into the custom format the created document tree is passed to a processor unit. It is up to the developer to select which importer or processor to use for each individual asset file. The processor unit converts the document tree into a customizable output format that gets serialized into a binary file format (XNB) later on. During runtime this serialized and preprocessed content file is loaded by a content manager instance via a simple call to a generic load method. The real strength of this procedure is that the developer has the chance to create custom importers or processors to influence what kind of data the resulting runtime type holds. These extensions do not necessarily have to be written from scratch but can simply extend already existing ones. The Animation System of the Honey Cube Engine for example extends the default Model Processor provided by the XNA Framework to extract animation information which otherwise would have been discarded. The Honey Cube engine uses this functionality for several of its components. Generally you can assume that a custom processor is involved while loading any of the custom content types described within the following engine components.

5.3.3 HOW TO BUILD A GAME ENGINE - THE SUBSYSTEMS In the following we will describe most of the engine components in more detail. We are going to depict the concepts our implementations are based on and highlight the challenges and difficulties. [Daniel Weidner<]

author: Daniel Weidner

5.3.3.1 Entity Component System [>Preslav Rachev] Traditionally, programmers have been favoriting inheritance as the main way of extending functionality. Indeed, on many occasions, inheritance proves to be a fast and simple way to extend existing objects, and in need, one can further extend the inherited functionality by overriding. However, it could quickly turn out to be a burden as the project size increases and the requirements for the different types of objects start to vary drastically. Many existing implementations still feature inheritance as the main way to extend existing functionality. This usually results in a somewhat generic class called GameObject which serves as the root of a deep hierarchy of sub-classes, each slightly modifying the main functionality to make it serve its needs. For example, one can create a MovingObject, extending GameObject, and two more classes Citizen and Camera extending MovingObject. Normally, such kinds of inheritance chains can reach a level of 4 or 5, with numerous leaf subclasses, all stemming from one generic GameObject. Up to a certain level of depth, this is manageable. The problem occurs when somewhere along the development process, the requirements change (which is quite a normal incident) so that some kind of new functionality is needed by a few of the inheriting objects. Moreover, what if a sub-class of Citizen, would need some functionality of Camera? The classical inheritance approach postulates that all the repeating functionality can be generalized in a mutual parent class. Therefore, oftentimes GameObject turns into a massive blob class, containing all kinds of functionality, not necessarily related to each other. Not only that, but as a result, all of the classes inheriting from GameObject also carry the burden of containing functionality, which they are not responsible for. This situation strays away from the principles of good design, and is also very hard to manage, both by programmers, and by machines (overblown objects are generally heavier to create, manipulate, and dispose).6 A much better, and seemingly more scalable approach in the long future turns out to be splitting the functionality of the GameObject, and encapsulating it into a number of different component classes, each of which is responsible for a particular task, for example, rendering the entity on screen, adding physics, movement, or any kind of AI logic, etc. As a result, the GameObject turns into a hollow container (Entity), each instance of which can be filled with a different set of components. For example, if we want it to have a visual representation, we simply add a specific RenderComponent, if we want it to have physics, an instance of a specific PhysicsComponent, if we want to be able to control it with keyboard, an instance of a specific ControllerComponent, etc. Each component might have a set of dependencies, for

instance,

PhysicsComponent

might

require that the entity has an instance of CollisionComponent, and is not going to get updated until the dependencies are satisfied. The purpose of the Entity class as a component container is to manage and update every specific component instance, which is added to a given entity instance.

FIG.6 THE FIGURE SHOWS HOW A FEW DIFFERENT TYPES OF ENTITIES CAN BE CONSTRUCTED BY COMBINING DIFFERENT SETS OF COMPONENTS. FIGURE TAKEN FROM http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

See â&#x20AC;&#x153;Evolve Your Hierarchyâ&#x20AC;? - http://cowboyprogramming.com/2007/01/05/evolve-your-hierachy/ author: Preslav Rachev

Extending the functionality of the entity becomes an incredibly simple task. Instead of extending the entity class, one can simply add, remove, or switch a given entity component with another one. One can do this for every instance of a given entity type, with the use a Factory object, which assembles every specific entity instance before it let to be used, or by simply grabbing a specific entity instance and playing with its components. One can do this at runtime, for example, when the gameplay requires it - a task not so easily achieved with the traditional inheritance approach. Within HoneyCube, the entity-component mechanism is implemented by using a singular Scene object, containing a list of Entity objects. Each entity can contain one or more Component objects, and allows for runtime addition or removal of components. When an entity gets attached to the Scene object (for example, when a citizen gets created and added to the world), the Scene object inspects what component objects this entity object consists of (in the case of the Citizen, there are at least one Transform component, which is required for positioning the citizen in space, one RenderComponent, to render the citizen model and its animations, one AI component, to care for the behaviors, etc), and adds each one to one of a few lists depending on the type of the component. At a regular interval (on Update or Draw), the different lists of components get updated accordingly. Therefore, it is the Scene, not the entities themselves, responsible for updating the different components. When an entity state changes, for example when a new component gets attached, or an old one gets removed, the Scene gets informed accordingly, to be able to add or remove the component from its lists. [Preslav Rachev<]

author: Preslav Rachev

5.3.3.2 Rendering System [>Daniel Weidner] The Rendering System uses the entity-component system to its advantage. The engine provides a set of render components (1). Such a component will render a content representation for the entity the particular component is attached to. Once such a render component is connected to an entity it gets registered in the running Rendering System. The Rendering System maintains all of those components and initiates the actual rendering process. It simply has to iterate over all registered components and call the Draw() method of these components (2).

FIG.7 THE CLASS DIAGRAM SHOWS THE STRUCTURE OF THE RENDERING SYSTEM. SOME CLASSES AND ATTRIBUTES HAVE BEEN LEFT OUT FOR SIMPLIFICATION.

author: Daniel Weidner

Sending geometry to the graphics device can be a an expensive operation. All vertex7 and texture information has to be loaded into the memory of the graphics processing unit (GPU). Dependent on the complexity of the geometry this takes processing time which can not be used by other operations. A drop of the frame rate is the result which at a certain point might lead to stuttering graphics. Different strategies exist to minimize the number of changes to these internal memory buffers. Two of them have been investigated for the implementation of the Rendering System of the Honey Cube engine that help to improve the rendering performance of complex scenes: Batching and Culling. When using a batch strategy, geometry is not sent directly to the GPU but collected in a separate class structure for example a GeometryBatch class. The GeometryBatch allows to register new geometry instances and will check whether it has already been registered before. The RenderSystem, like before, iterates over all available RenderComponents, but instead of drawing them directly, it will allow the component to register it to the GeometryBatch. Once the GeometryBatch detects that a piece of geometry is going to be rendered twice within this frame it just has to remember the difference between both instructions. This will typically be the position in world space, but can also be the applied material. After all RenderComponents had the chance to register their geometry to the GeometryBatch each individual geometry instance is sent once to the GPU. Generally this reduces the number of necessary memory buffer switches tremendously, especially for larger scenes where models for citizens or buildings repeat frequently. Culling is a further very simple principle which tries to discard geometry which is currently not visible by the scenes camera.

Frustum Culling ignores all vertices that are situated outside the current viewing frustum. The viewing frustum is a geometric volume representing the field of view of the current camera. Generally the viewing frustum is represented by truncated pyramid. The RenderSystem does perform frustum culling on a per game object basis not a vertex basis. This means that all the game objects get rendered as soon as a single polygon is visible by the camera. This approach is quickly implemented and adequate for the low complexity of the HYPRIONS models. Backface Culling is done automatically by the XNA Framework and will discard all polygons which are currently situated on the back of an object and therefore covered by the polygons on the front (on opaque geometry). Occlusion Culling is a technique to determine geometry that is currently covered by other objects within the scene. The RenderSystem does not perform any further optimizations as we did not run into any performance issues so far. Further techniques could be added in the FIG.8 ILLUSTRATES THE TECHNIQUE OF FRUSTUM CULLING. ALL OBJECTS INTERSECTING WITH THE VIEWING FRUSTUM ARE VISIBLE BY THE CAMERA.

future though.

A 3d model consists of a collection of vertices which form the corner points of the actual primitive geometry. A vertex holds at least the position data of a point in 3d world space but can hold additional information like color, transparency or texture coordinate as well. Three vertices generally form a triangle often referred to as polygon. 7

author: Daniel Weidner

5.3.3.3 Animation System The Animation System of the Honey Cube engine is separated into two essential components:

• •

A content pipeline extension to extract the animation data from the model file (1). An animation controller component to calculate the actual model transformation (2).

5.3.3.3.1 Self do. Self have. Extracting the Animation Data By default the XNA Framework does not provide any animation data. Nonetheless, as described before, it is easy to add this functionality by implementing a custom content processor. Luckily the default fbx model importer already extracts all keyframe information from the model, the default model processor just ignores this kind of information when processing the document tree. We implemented a processor that does compensate for this missing functionality. After loading a model with the custom processor the model holds a collection of AnimationClips. Each AnimationClip consists of a dictionary which assigns to each bone instance an AnimationChannel. The AnimationChannel is nothing more than a collection of AnimationKeyframes which additionally provides some useful interface for retrieval. An AnimationKeyframe finally holds the transformation of a bone at a certain point of time in the animation clip. Everything is now setup for the animation controller to perform model animations. 5.3.3.3.2 “I like to move it”... the Animation Controller Now that we have all animation data available on the model we can start animating it. But before we describe how the ModelAnimationComponent works we shortly talk about hierarchical animation in general.

Most

complex

object

animations will generally involve a hierarchical structure of subelements. For example a robot arm might be a child element of the shoulder which in turn might be a child of the torso and so forth. Once transforming one of these elements all its child elements get affected relative to its parent as well. The

ModelAnimationComponent

accounts

for

such

hierarchical

transformation and calculates the absolute transformation for each individual bone on a per frame basis. Once a ModelAnimationComponent is

attached

Entity

the

FIG. 9 AN EXAMPLE FOR A HIERARCHICAL SKELETON ATTACHED TO A 3D CHARACTER USED FOR THE HYPRIONS GAME

component tries to retrieve the model that should be animated. If there is no [Model]ContentComponent available on the Entity the ModelAnimationComponent is simply disabled. Is however the ModelAnimationComponent correctly initialized, it starts playing the first animation clip available on the model. From then on the component determines every frame which keyframe is currently active for each individual bone/element in the hierarchy. author: Daniel Weidner

Therefore the component runs repeatedly through the following process:

•

The component has to update the internal timer to track the progress of the current animation clip. Therefore it measures the time elapsed since the last frame and increments its counter correspondingly.

•

Once the already elapsed time of the clip has been detected the component tries to retrieve the local bone transformation for each bone at the given time from the model. Therefore it iterates over each bone instance to check whether an animation channel for the active bone exists. If a channel exists the bone is animated and we have to retrieve the corresponding keyframe at the given point of time. In a last step the transformation of the retrieved keyframe is copied to an associative array.

•

Now we account for a possibly existing hierarchy. We again iterate over all bone instances. Thereby the order of these bones is a crucial factor. After each bone follows its children what ensures that we are always going to calculate the absolute transformation of the parent first. Consequently the calculation of the absolute position is a simple Matrix multiplication. For each bone instance we have to retrieve the local transformation and multiply it with the absolute transformation of its parent. We are done when we calculated the absolute transformation for all bones.

•

The calculated array of absolute matrix transformation can then be used by a render component to position the respective geometry instance at the correct position and orientation. While the array is updated with each frame the animation is progressing continously.

The game developer of course has the possibility to control the playing state of the current animation clip or to switch the active clip entirely. This is especially useful to reflect a changing behavior of the corresponding entity. For example a character might have an idle animation when it does not change position for a while, so the currently active animation clip needs to be changed from “walking” to “idle”. In the following you can see a class diagram of the essential components of the animation system and some of the described methods and properties provided by the components.

author: Daniel Weidner

FIG. 10 CLASS DIAGRAM OF THE CORE COMPONENTS FORMING THE ANIMATION SYSTEM

author: Daniel Weidner

5.3.3.4 Game Interface [>Preslav Rachev] A good game is nothing without an interwoven, responsive, and consistent user interface. That applies even more to strategy games. Surprisingly, despite the fact that UI is defining the way the player communicates with the game, the XNA framework itself offers almost no support for building complex UI layouts besides displaying strings, and making certain objects on the screen react to user input. Therefore, ever since the beginning, having a system for easily constructing, and managing the complex layouts designed by the interface team was a high priority. Before approaching the matter internally, a few state-of-the-art libraries for generating graphical user interfaces were tested, but for one reason or another, none managed to quite fit the requirements of the game. Some were simply relying on an older version of the XNA framework, and were incompatible with the latest one. Others simply made building and managing UIs a task, too integrated within the code. This was undesirable because it made it impossible for the design team to change or fix their designs without the need of a programmer. Last, but not least, some libraries were not using XNA, but directly used GUI components from WinForms, the framework, used to make normal Windows applications. This on one side once was going to make designing and styling hard, and on another, mixing two rendering approaches would definitely lead to decreases in performance. Therefore, the development team set off to build a complete UI management system from scratch. The UI system which the HoneyCube engine provides is based on a few paradigms known to both designers and programmers. Building UI components, from tiny buttons, to entire screens filled with buttons and gauges, resembles designing a web page. One does not have to handle layout and styling using C# code. Instead, one does that in XML files, which very much resemble designing HTML pages. In a visual and structured manner, the design team can easily construct complex UI components, consisting of deep hierarchies of objects, or having a lot of different types of objects in one place - much in the same way that one can design a complex web page, consisting of numerous DIV elements, some wrapping others, some spanning across the entire screen, others tiny, etc. One can precisely position elements relative to their parent elementâ&#x20AC;&#x2122;s position or based on the dimensions of the screen. Similar to using CSS, one can even create stylesheets using XML, which define what type of font, and font size to be used, what the background color or image should be, and other aspects, which can be externalized, and then simply reused whenever needed. This creates consistency among the interface elements, as well as reduces the effort of writing the same specification again. On the engine side, several readers exist, which in runtime construct the hierarchies of UI elements from the XML specifications. Two main classes exist - UIComponent, and UIGroup. UIGroup extends from UIComponent. It is an invisible container and provides the possibility for adding an infinite number of UIControl-based children to it. It is what the readers return after parsing some XML-based layout. Every UI component can be queried, and a reference to any of its child components obtained, by using the type of the child component, or the name, with which the child component is specified in the XML template file. Different event listeners can be attached to every UI component, allowing for certain logic to be executed when an interaction is performed, for example, the element gets clicked with the mouse. With the use of styles, the designer is able to define a few different visual states for every component, based on what interaction is being performed. For example, a normal button usually has minimum two states, onUp, and onDown, which define the visual changes to the button when it gets clicked. Using the existing system, it is very straightforward for the design team to define those visual styles within the template and style XML files, and for the programming team to invoke those style changes within the code, when a certain interaction with the component occurs. 5.3.3.4.1 Interface Elements The common interface elements within the game directly extend from the concepts and conventions laid out by the GUI system (see Game Interface). Both the building menu and the interface of the Pulse (see Pulse) are designed 28

author: Preslav Rachev

to represent complex layouts of different UI elements. Therefore, once the final visual representation of both was agreed upon, and the graphic assets (backgrounds, icons, fonts, etc) extracted, each was laid out in its own XML template. Within the game, each is represented as a group of user interface elements, which is queryable, i.e. any child element can be reached, by using the name it was given in the XML template. Also every element can be interacted with - buttons and icons can be clicked, tooltips appear on mouse over, labels change their content on certain events during the game, elements or entire groups of elements get hidden and then pop up again, etc. Pulse As described in the conceptual part, the Pulse is the link between the events occurring during gameplay, and the educational element, conveyed by real-world data. As such, the Pulse consists of two interconnected parts: on one side, this is the pure user interface, which is responsible for conveying the message to the player, and the evaluating mechanism behind, which decides whether, when, and where to show a particular message containing real world information. It can be said that the evaluator is more or less the essence of the Pulse. The evaluator was implemented with the architecture of an achievement system. When it shows a message to the screen, it actually gives an achievement to a particular object. In this way, different types of achievements can be designed (not only pollution-based) and assigned to different recipients. Achievements are extracted and processed form an XML file containing a list of all possible achievements in the game. Each achievement in the game is written manually by a team member, in order to keep the real data in it and make it fit to real world content. Achievements are threshold-based, and can be related to each other. This allows for complex scenarios (mimicking the real world, for example all different stages of an oil spill crisis) to be thought of, and demonstrated through the gameplay. The way the Pulse evaluator works is pretty loose, in order to make a large set of potential cases to be estimated and the best fitting one to be displayed to the user. If the evaluator simply assigns achievements in the way they were set in the XMl file, will result in a monotonous and repeating gamely. Therefore, every achievement has a list of tags (keywords) which describe it, as well as a singular category to which it fits. For, example A Pollution achievement may have the following sample list of tags: air, water, coal, dust, nuclear, fish, etc. When actual pollution occurs, the Pulse gets the message dispatched through the message system (see Message System) and runs the specific Pulse-subevaluator, responsible for handling Pollution (there are a few different sub-evaluators mapped to different types of messages that the Pulse is subscribed to). Based on the parameters of the Pollution message, the evaluator sorts and filters the collection with actual possible achievements, selects the ones which most closely map to the current selection (i.e. creates a score for each achievement, and chooses the ones with the highest score). Then, depending on the situation, it might simply select a random achievement from the remaining ones, or do further recalculation. Once an achievement is assigned to a given object, the Pulse UI updates itself and displays the message of the concrete achievement to the user. [Preslav Rachev<] 5.3.3.5 Oh behave! â&#x20AC;Ś Artificial Intelligence [>Steffen Sass] The final AI concept of the game consisted of mainly three elements: behavior tree, pathfinding algorithm, and steering behaviors. The behavior tree contains the largest part of the logic and can be understood to be the decision maker of the whole structure. It commands where our agents (citizens) should move, what they would do and when they would do it. The A* pathfinding algorithm then is responsible for finding a path from point A to point B on the game map. At last the steering behaviors would move the agent along the path and introduce a more organic behavior while traversing the path rather than moving along the waypoints in a straight line, making the movement look too artificial and robotic. Following we will explain the elements in further detail. author: Preslav Rachev/Steffen Sass

5.3.3.5.1 Finite State Machines Finite state machines have been very popular in game development for the last decade and maybe longer, which was the reason why we chose this structure to begin with. The concept itself is pretty simple. A state machine in general consists of the states itself and a transition table, which keeps track of the current state (a piece of logic) and the conditions that have to be met to transition into another state. The transition table in our case was a state machine object itself that kept track of the current state and could change states on request. It is very easy to set up simple logic with such an implementation. However, the more complex the logic gets, the harder it is to maintain the whole structure or even extend it. Each state in a state machine has to be connected to the next state with an explicit transition. The more states (logic for different situations) you have, the more connections you have to draw to other states, which leads to a lot of overhead in written code. The code of the states itself is written on a very basic level and specific to a certain situation. It is rarely possible to easily reuse states for different but similar tasks. A lot of logic ends up being rewritten over and over; code becomes redundant. As the logic scales up the state machine usually ends up being edited as a whole, instead of us being able to work on smaller pieces of logic individually8. 5.3.3.5.2 Behavior Trees Behavior trees take a different approach and try to increase the modularity of states. The logic for different tasks is kept to a bare minimum to make them reusable for different goals and situations in the game. Some hybrid HFSM (hierarchical finite state machine) try to offer the same functionality. The main difference here is that the transitions themselves are separated from the logic and moved to external states (tasks/leafs). The game logic itself then turns into self-contained behaviors, which are basically a collection of actions that are executed and terminated. Those behaviors no longer contain transitions or links to their successors. Instead they are inserted into the parent scope and executed according to its semantics. Standard examples for those types of parents are sequences and selectors. By inserting tasks into those â&#x20AC;&#x153;parent tasksâ&#x20AC;? we are able to allow for transitions based on the type of parent that is chosen. One can then further extend a behavior tree by adding custom decorators that modify task behavior and execute tasks based on chance or the time passed since their last execution.

9 10 11

Sequences and selectors are easily understood when we compare them to the AND and OR gates of electric circuits. A sequence successfully terminates when all its child tasks have been completed successfully (AND). A selector successfully terminates when one of its child tasks completes successfully (OR). This allows the behavior tree to manage the basic logic and transitions we need while keeping the individual tasks modular and transparent. The illustration shows a simple section of the behavior tree used by the citizens in the HYPRIONS game. The planner is the root node of the tree which is called on every update cycle and puts the whole logic in motion. It is reset after every cycle, since it is not supposed to ever terminate, but keep the AI machine going. The regulator determines in what time interval the AI is calculated. Beneath the root node, which functions as a selector, we have a leader task12 and a citizen task (selector). Based on certain conditions (the citizen being a leader or not) the tree will follow either one of those branches. A regular citizen then has a chance to go into the waiting task, which in the game will look as if the character is simply pausing. The alternative would be to switch to the wandering sequence, which tells the character to calculate a path to a specific waypoint. See also: Champandard, A. J. (2007): 10 Reasons the Age of Finite State Machines is Over. Retrieved from: http://aigamedev.com/open/article/fsm-age-is-over/ on 04/18/2012. See also: Champandard, A. J. (2007): Understanding Behavior Trees. Retrieved from http://aigamedev.com/open/articles/bt-overview/ on 04/18/2012. 10 See also: Champandard, A. J. (2007): Popular Approaches to Behavior Tree Design. Retrieved from http://aigamedev.com/open/articles/popular-behavior-tree-design/ on 04/18/2012. 11 See also: Knafla, B. (2011): Introduction to Behavior Trees. Retrieved from http://bjoernknafla.com/introduction-to-behavior-trees on 04/18/2012. 12 The complete logic of the leader would consist of further sequences etc., but is omitted for illustration purposes. 8

author: Steffen Sass

This waypoint can be chosen randomly or based on landmarks (parks, hillsides, the coast, etc.) or a character’s needs (e.g.: a hospital). The character will then follow the path calculated by the pathfinding algorithm until it finally reaches its goal.

FIG. 11

Compared to the earlier state machine implementation the behavior tree offered us a more flexible solution of programming our AI by writing small pieces of logic and grouping those together to create more complex behaviors. Whereas working together on the state machine implementation ended up being chaotic really quick, the selfcontained tasks of the behavior tree allowed for a much better collaboration. 5.3.3.5.3 A* Pathfinding Pathfinding and object avoidance was another of our concerns while implementing the logic of the game. Our game has a number of obstacles that might get into the way of an agent’s path. There are hills, trees, buildings, and other citizens occupying blocks of the game map. Initially we introduced a basic obstacle avoidance into our steering behaviors. When one of our citizens came close to an object that it should avoid, it simply tried to steer away from it. This solution worked to some extend, but didn’t look really elegant. The citizens were moving close up to an obstacle to then steer around it. This behavior didn’t look really natural. We don’t usually go up to a wall and then realize that we should find a way around it. It was more desirable to have solution that recognizes obstacles early enough and finds a way around it that looks more intelligent. Pathfinding is one of those areas where even the top games, that are selling millions of copies, are lacking. Some have found well performing solutions to this problem, but many games still do it the same way as it has been done decades ago. 13

Kalani, C. (2008): Fixing Pathfinding Once and For All. Retrieved from http://www.ai-blog.net/archives/000152.html.on 04/18/2012. author: Steffen Sass

This certainly is a fascinating topic, but we didn’t have the time to dive too deep into this area. Therefore we decided to use the A* (read: A star) pathfinding algorithm as an acceptable solution to the problem we were facing. This algorithm has been in use for quite a while and owes its popularity to its performance and accuracy. This is why there was also ample documentation to be found on the internet explaining how this algorithm works and how it can be implemented in numerous ways. 14 The A* algorithm follows the path of lowest known cost. Starting at the initial node it keeps a sorted priority queue of alternate path segments along the way. At each step those path segments are being evaluated and the segment with the higher cost is being abandoned in favor of a segment with lower costs. This cycle goes on until the final goal is reached. Costs can be assigned within the algorithm, which allows us to modify the pathfinding behavior. It is, for example, possible to assign higher costs to nodes that are located diagonally to the current node, nodes that are polluted or of a certain kind of terrain. 5.3.3.5.4 Steering Behaviors The steering behaviors based on a popular paper by Craig Reynolds was one of the first concepts we implemented for our game AI. The goal of these behaviors is to allow artificial agents to navigate through a game world in a lifelike and improvisational manner. They include actions like seek, arrive, flee, wander, and more. It is also possible to combine those behaviors to achieve higher level goals. We can, for example, tell our game character to move from point A to point B while avoiding obstacles. One combination, we used in our game, was to let our citizens move between waypoints while adding a wander behavior to randomize their movement and make it appear as if they were not just following a straight path. To achieve those combinations each of the steering behaviors has a weight assigned to it which determines to what extent a certain behavior influences the character’s movement. 5.3.3.6 Like honey to my ears … the Audio System The audio implementation of our game is rather simple. XNA already offers a lot of functionality for simple audio playback. To be able to play multiple sounds at a given point we had to make use of the XACT engine. A project is set up outside of the code containing multiple sounds, as WAVE files, and cues . These cues can then be used inside the code to be able to play a certain sound file. XNA also offers the possibility to set up 3D audio playback. To implement such a feature we have to set up an Audio Listener, which receives the sound output, and an Audio Emitter, which emits the sound to be played. To keep track of all audio playback our game entities had to register with the Audio Manager. The manager kept track of all objects emitting sounds in 3D space and updated the sound position according to the emitter position on each update cycle in the game. The camera served as the listener in this scenario and allowed us to give the player the illusion of being inside the game world, surrounded by sounds, like people walking, talking, building construction, and many more. Another feature we added on top of the XNA engine was the ability to fade sounds in and out. This gave us the possibility of making the background music dynamic depending on what was happening in the game. By connecting

17 18 19

Patel, A: Amit’s A* Pages. Retrieved from http://theory.stanford.edu/~amitp/GameProgramming/ on 04/18/2012. Patel, A.: The A* Algorithm. Retrieved from http://theory.stanford.edu/~amitp/GameProgramming/AStarComparison.html#the-a-star-algorithm on 04/18/2012. Reynolds, C. W. (1999) Steering Behaviors For Autonomous Characters, in the proceedings of Game Developers Conference 1999 held in San Jose, California. Miller Freeman Game Group, San Francisco, California. Pages 763-782. Online version: http://www.red3d.com/cwr/steer/gdc99/. XACT: Cross-Platform Audio Creation Tool. WAVE: Waveform Audio File Format, also known as WAV. Cue: A cue in XACT serves as an event marker or identifier for a certain sound and can be used inside the actual code to play the associated sound.

author: Steffen Sass

the earth’s health points with the background music, we could for example darken the mood of the music as the planet gets more and more polluted. [Steffen Sass<]

5.4 HYPRIONS - THE GAME

[>Daniel Weidner] As the Hyprion game has some special requirements, which we discussed in more detail at the beginning of this chapter, not all of the features need to be located within the core of the Honey Cube engine. Some of them are tightly coupled to the explicit game concept and thus should not be included in a general strategy game engine. In the following we will describe some of those features and illustrate how these integrate with the engine.

5.4.1 UTILIZING THE ENGINE [>Daniel] The Honey Cube engine and the Hyprion game are two completely separate solutions. The engine itself is totally independent from any external resources. Every game project that wants to use Honey Cube needs to include the compiled dynamic link (*.dll) libraries as a project reference and can then start to use its functionalities. This has the advantage that the engine itself is delivered as a finished product which can not be accidentally changed by any project using it. Furthermore it reduces the overall compile time of the game as the functionality of the engine is already converted. One disadvantage though is that the referencing project is not able to debug any of the functionalities of the engine. All of the Honey Cube components are implementing the IGameComponent interface provided by the XNA Framework. This allows to use these components by simply adding them to the component collection of the game instance. Consequently the game designer can decide himself which functionality of the engine he wants to use. E.g. in order to use the Input Manager provided by Honey Cube the developer simply needs to add Components.Add(new InputManager(this)); to the Initialize() method of his game instance. XNA will then include this component in the game loop and automatically call the adequate Update and Draw methods. Components not only can be added to the component or service collection of a game but also retrieved. The following piece of code for example would retrieve a reference to the rendering system20 : Services.GetService(typeof(IRenderService));

[Daniel Weidner<]

5.4.2 IMPLEMENTING THE GAME FEATURES 5.4.2.1 Cubic Terrain [>Tim Ötting] The design decisions on how to show the world also influenced the way to implement the structure of the basic concept of the terrain. As the world was supposed to come up in a technical, cubic look. The obvious result was to organize the game world in a grid. To be more precise, CubicTerrain class was planned to have a huge three dimensional array containing every block the terrain consists of. Doing so, however, would lead to fatal performance issues. The resulting array would contain informations of all the blocks, including their geometry, even though they would not even be visible on the screen. Therefore, another region layer in the form of regions (CubicTerrainRegion) was introduced in between the overall 20

The RenderService should be available as soon as a Scene was created. author: Daniel Weidner / Tim Ötting

terrain and the blocks (see figures). Each of these regions

hold

feasible amount of blocks which can be rendered if necessary, i.e. when the respective region is inside the camera’s field of view. Each the CubicTerrain and the

CubicTerrainRegion

class offers a bunch of useful

properties

and

methods to access specific FIG. 12 THE FIGURE ILLUSTRATES HOW THE INTERNAL STRUCTURE OF THE TERRAIN LOOKS LIKE

blocks on the world’s map.

The blocks then provide important information for the gameplay. First of all, this is where the pollution (ground, air, water) is saved. Each block, furthermore, is associated with a responsive type like “land”, “water” or the different types of rocks. The block also “knows” if a building is placed on top of it. This information is important both for the AI and for other buildings that will be placed on the terrain. [Tim Ötting<]

FIG. 13 CLASS DIAGRAM OF THE TERRAIN STRUCTURES USED FOR TERRAIN GENERATION IN THE HYPRION GAME

5.4.2.2 Game World [>Preslav Rachev] The game world was implemented as an extension of the cubic terrain implementation in order to provide coverage for specific aspects within the game such as pollution (regional, global, average), and serve as a geo-service for the citizen artificial intelligence (providing information regarding the accessibility of certain types of blocks, the types of entities which are occupying a given block/region, etc). The game world is also used by the game manager to decide if the player has won or lost, as well as by the Pulse (see Pulse), to provide specific pollution-related information. The game world object facilitates the use of the messaging system (see Messaging System) by subscribing to a set of messages, and appropriately managing the state of the terrain, as well as the level of pollution, if necessary. 34

author: Tim Ötting / Preslav Rachev

5.4.2.4 Messaging System Every complex system, which involves the use of deep hierarchies of objects (for instance scene graphs, or an entitycomponent architecture), requires a strong need for a centralized messaging system, which each single object instance, no matter how deep within the hierarchy, must be able to access, and use to broadcast messages to the rest of the game universe, or to specific recipients. Messages are important for notifying the different game objects that the state of a specific aspect of the game, for instance the global pollution level, has changed. Messages allow a decoupling of the architecture, as it reduces the coupling between the different components. Rather the components communicate indirectly through a medium, i.e. the messaging system. A few existing implementations of messaging system were researched and their benefits analyzed. A good state-ofthe-art messaging system, which facilitates the use of an entity-component architecture for is the one in the Unity3D engine. It is deeply integrated within every single game object instance, and allows for broadcasting global messages to the whole game universe, as well as sending messaging only to the children of a given object, for example an entity to all of its components, or a component to its subcomponents. Moreover, it reduces the need of components to subscribe and listen for a specific message. All it is needed is that the component which will eventually get the message, has a method named in the same way as the message itself. After a few attempts following the aforementioned approach, it turned out that using the existing technologies, message delivery performance is going to drop significantly, because the approach requires a lot of runtime reflection, and recursive checking. After a short discussion, the team reached the decision that the complexity of such a system is not going to bring as many benefits, as much effort we would have to invest into increasing its performance. Therefore, the current implementation features a central messaging system instance, which is accessible to anyone (using XNA’s concept of Services), and currently only allows objects to dispatch global messages. To eliminate the necessity of checking every single object for a specific message subscription, we used C# built in concepts of delegates. Delegates are essentially function pointers, and are used by the messaging system to notify the subscribed objects when a message occurs. All a component has to do to subscribe to a message is to point a dedicated method, which will be called when the message is broadcasted, to the message system. As an end effect, when a message is broadcasted, it has to go only through the function pointers, which were subscribed to that specific message, and call the methods associated with them. [Preslav Rachev<] 5.4.2.3 Buildings [>Tim Ötting] The buildings in the game are a essential part of the gameplay. The different building types influence the world by polluting or cleaning the ground, water and air. This, as described in the concept part, has to be utilized by the player to reach the goal of the game. The building concept is mainly implemented in the following classes: Building.cs The building class extends the formerly mentioned entity class to provide more specific functionality by attaching components. The BuildingConstructionComponent makes the building constructible, meaning that the building process requires a specifically defined time frame to be finished before it starts to affect the surrounding terrain. During this time, a simple animation shows the progress of the building. The BuildingPollutionComponent controls the building’s pollution. Each type of pollution is defined by a radius, strength and a frequency of pollution. This functionality is closely connected to the terrains properties, especially author: Preslav Rachev / Tim Ötting

to the responsive blocks. Each time,

the

building

pollutes,

a set of blocks around the building will be affected by the pollution. The size of this set is dependent on the pollution radius. The further away each of these affected block is, the lower is the actual pollution of the block. Ground-, water- and air pollution are then added to the pollution properties inside the block and can be influenced FIG. 14 SCREENSHOT OF THE PROTOTYPE. POLLUTING BUILDING ON THE LEFT POLLUTES GROUND, BUILDINGS ON THE RIGHT CLEAN IT.

by several buildings. Hence, a block’s ground pollution can be increases by a cole power plant and decreased by nearby windmills and solar power plants at the same time. The levels of pollution are indicated by the block’s colors. The more sick the nature is, the less saturated and greyish is the color. The pollute method can also be triggered by other game events. This can be useful to simulate abnormal events like the explosion of a nuclear power plant. BuildingFactory.cs This helper class provides the programmer with all the functionality that is needed to create and place buildings on the world. All the building types are defined by associating them with model path’s, duration of construction, pollution radius/strength and other properties. Moreover, the building factory provides a function to check whether a building is placeable or not. A reason for a building not to be placeable could, for instance be rocks or other buildings inside the building area. Another example is a drilling platform, that can only be built on water and not on land. The main task of the building factory is, however, to prepare buildings with the needed properties, to connect the building components to the building entities and to provide them to the game. [Tim Ötting<]

5.5 ABOUT AMBITIONS - WHY WE FAILED...

[>Steffen Sass] There are a number of elements playing into the fact that we did not manage to finish our game as it was intended. One of them being the decision to create a full game and not just a casual game. Casual games are oftentimes a lot of fun and do not require a big commitment (e.g.: time) on part of the player. This would have probably allowed us to cut down on the extent of programming required and focus on other elements of the game. Considering that we had only a few inexperienced programmers in our team, it was not the best decision to go for a game that requires a lot of programming. A simple casual game might have helped us to better leverage the individual skills of our group, which might have been the creative aspects, like audio and graphics, rather than programming.

author: Tim Ötting / Steffen Sass

The next step we took was to decide on creating an own engine due to several reasons, one of them being the specific requirements of our game. When making this decision we knew it was a lot of work, but we probably did not know exactly how much work it actually was. This lead to a split of the programming group into engine and game, which further reduced the manpower contributing to the game itself. There also have been problems specifically in the programming part itself. At times it was difficult to split up the workload for certain aspects of the game, since some elements of the code were tightly interrelated. A general lack of communication at certain points in the development process has further hindered us in achieving our goal. [Steffen Sass<]

author: Steffen Sass

6. VISUALS

6.1 THE WORLD 6.1.1 STYLE In the game the player is in the role of an agent from an alien race, who tries to destroy planet earth by making its inhabitants pollute their environment until complete destruction. The agent does intervene directly in this process, but influences certain citizens thelepatically from his spaceship. As a result he has to have a clear and structured overview of what happens on the planet and of the buildings, people and environmental factors which are important for his mission. What the alien sees on the screen on his spaceship is also what the user is seeing while playing the game. Hence, the visuals of the interface, game world, buildings, citizens, etc. should follow a schematic representation which would best suit an alien to fulfill his plan. Therefore the overall design of the game world is inspired by the visual style of two different concepts: architectural models and blueprint drawings. Architectural models are characterized by simple and minimalistic shapes with little, but well placed, details. Similarly to blueprint drawings, they are intended to give a structured overview of a complex system, like for example a town district, and serve as a general plan and visualization of such. And although blueprints are usually quite detailed, they remain clear due to their schematic look and underlying grid. All elements of the game should be modeled in such a way that their function is clearly and quickly visible, without unnecessary details. A certain level of abstraction is applied in order to underline the notion that what the player sees is not a realistic view on the world, but seen through the alien‘s eyes through a computer screen. Nevertheless, the visuals should be appealing to the audience and foster a positive game experience. The general design principle can therefore be summarized with the famous quote of french poet Antoine de SaintExupéry: “It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away“.

6.1.2 COLORS

FIG. 15

The color palette used in the game is very reduced and follows the minimalist approach of the design in general. Colors function mainly to indicate certain aspects which are important for gameplay. The two dominant colors in the game world are white and green. White is used to indicate the man-made parts of the scene, therefore all buildings, facilities, power plants, as well as the ground and other objects are pure white. Green and shades of green are used to indicate nature and its current state of health. Trees, bushes or natural landscapes can therefore become a different shade of green during the game. The color grey becomes more important as the player progresses in the game - the more polluted the environment

author: Martina Malinowski

becomes, the â&#x20AC;&#x153;dirtierâ&#x20AC;&#x153; the scene is. The grey mixes in with the greens and additionally

influences

how,

previously

mentioned,

the

colors

change

throughout the game. The last color to be used is Blue. It fills areas with water in them like lakes or oceans. No other and additional colors are to be used.

6.1.3 ENVIRONMENT As mentioned in the first section of this chapter, the environment is not realistically looking but shows the player how the alien sees the world: in an abstracted, schematic and reduces way, focusing only on what is important for him/her to reach his/her goal of total destruction. Therefore the normal level of ground is pure white, covered with a subtle grid of grey lines which resembles the look of blueprint drawings. Each cell can also contain one or more colored cubes, which are stacked on top of each other and can, together with others, form a mountain or any other kind of natural elevation in the landscape. Trees are also placed in one cell grid each. This underlines the schematic view of the alien on the world. When lakes, rivers, oceans or other forms of water are to be indicated, grid cells are simply colored blue and the grid lines are removed.

FIG. 16

6.2 THE PEOPLE 6.2.1 CITIZENS When it comes to the outer appearance of the population, there is only one type of citizen. There is no difference to be made between genders, races, ages, nationalities or professions. The characters are recognizable as human beings but look rather abstracted and simplistic. The head should look slightly too big, as a metaphor for the main goal of the player: to influence peopleâ&#x20AC;&#x2DC;s preferences and thought thelepatically. When it comes to colors, citizens are generally uni-color and do not wear any identifiable clothing. Another feature of the citizens which is important for gameplay is their movement. Citizens walk around the scene, talk, debate and listen to what leaders say. Their movement can be clearly divided into two types: natural and robotic. A more natural FIG. 17

author: Martina Malinowski

way of moving indicates that the citizens are not yet influenced by the leaders and that their thoughts and opinions are still defined by themselves or “green“ leaders. A more robotic movement shows the player that citizens are under the influence of a “bad“ leader.

6.2.2 LEADERS Leaders generally look just like regular citizens. As they have a special function in the game though, they have to be easily distinguishable from the other people by the player. Therefore leaders differ in color, size and types of movement. FIG. 18

They have a more striking color and are a bit bigger than normal characters. Additionally leaders have an added type of movement, next to the walking, talking and listening of regular citizens. They can also hold a speech to attract other citizens and convince them of a certain topic or to build a building.

6.3 THE BUILDINGS 6.3.1 STYLE

FIG. 19 OFFSHORE DRILLING

FIG. 20 PLATFORM ABSTRACTED VERSION AS USED IN THE GAME

As previously mentioned, the look of the buildings in the game resembles the style of buildings in architectural models. Shapes, proportions and sizes are abstracted in a way that the buildings have a minimalist feel to them, but the type and purpose of the building is still clearly recognizable. Their most important feature is that their function can be immediately identified by their form. There are the following types of buildings: Energy plants (considered generally “good“ or “bad“), housing and buildings that may have an influence on people‘s preferences.

author: Martina Malinowski

6.3.2 RESTRICTIONS In order to ensure a good game performance, some restrictions for the modeling of 3D objects for the game had to be set up: Polygons: The amount of polygons in a single model should not exceed the number of 10000. The optimum is a number between 1000 and 5000. Meshes: The model should ideally consist of a single mesh, or at least of as little meshes as possible. Therefore the models should be created using the box modeling technique were parts of a model are extruded from a single box. Geometry: As all NURBS or other type of geometry are converted into polygons when exporting the model, those should be avoided and polygons are to be used from the beginning when creating a model. The conversion of other types of geometry into polygons usually results in a high number of polygons. Materials: Materials and textures with the same or very similar properties should be merged in order to make the process of loading materials in the game a lot faster.

FIG.21 WIREFRAME OF GEOTHERMICAL ENERGY PLANT USED IN THE GAME HYPRIONS

FIG.22 WIREFRAME OF GEOTHERMICAL ENERGY PLANT

author: Martina Malinowski

7. USER INTERFACE

The interface elements were designed following the interface using mainly 2D elements. This decision was parameters pre-stablished by the Visual group. Our made due to criteria of graphics rendering optimization. main goal was to design a light and comfortable UI. We have chosen to display the essential data making use The HYPRIONS interface was designed throughout of a very simplified look, avoiding the use of long texts, the following stages: extremely contrasting colors or heavy shapes. To do so - Initial sketches on conceptual discussions; we had designed elements using subtle transparency, - Setting a coherent visual unity; a restricted number of color hue, simple iconographic - Layouts set up; system, light type faces and sound feedback.

- UI prototyping in flash app; - Usability testing;

Although the game scenario and characters were designed - Last corrections on the usability test results; in 3D it was a decision made by the group to design the - Final layouts presentation.

7.1 USER INTERFACE ELEMENTS 7.1.1 CREATE A LEADER MENU When double clicking on any citizen, the player might choose the option of creating a “LEADER” or a “LEADER+”. One certain amount of Biopoints will be consumed after this action is executed. This action is followed by a sound feedback and a subtle animation of the FIG.23 CREATE LEADER. FIG 24 CREATE LEADER + .

author: Fernanda Dias

Biopoints panel takes place at this point.

7.1.2 LEADER ACTIONS MENU

In this Menu the player finds the main four actions executed by the leader: - Build; - Destroy; - Attract; - Move. FIG.25-28 LEADER MENU ACTIONS: BUILD, ATTRACT, MOVE AND DESTROY.

7.1.3 THE DESTROY ACTION When clicking on the button “DESTROY” the player will visualize this icon when hovering buildings. The action is accomplished when the player clicks over the chosen building. Such action will be followed by sound feedback and a building disappearing animation.

FIG. 29 LEADER ACTION: DESTROY.

author: Fernanda Dias

7.1.4 THE BUILD MENU When clicking on the button â&#x20AC;&#x153;BUILDâ&#x20AC;? the player will visualize the screen below. The info displayed are essential and summarized. That will help on the decision making executed by the player. It also delivers some of the educational content implicit in the game play.

FIG. 30 THE BUILD MENU.

After choosing the desired building the player will hover areas [having a feedback where it is allowed to build this specific facility]. After clicking on the chosen area the following actions will take place: the building bar, the timer, the building area, the influence zone and influence area will turn visible.

FIG. 31 LEADER ACTION: BUILD.

author: Fernanda Dias

7.1.5 THE MOVE ACTION The player might move the leader in order to reach more citizens. When clicking on the button “MOVE” the player has a hover feedback as displayed below. When clicking in the desired area the leader will move being followed by the citizens already inside the influence zone.

FIG. 32-33 LEADER ACTION: MOVE.

7.1.6 THE ATTRACT ACTION

FIG. 34-37 LEADER ACTION: ATTRACT.

The player can attract new citizens when in need of more supporters in a more drastic action. When clicking on the button “ATTRACT” the player has a hover feedback as displayed below. When clicking in the desired area the citizen placed in the specified area will move to a vacant square at the influence zone.

author: Fernanda Dias

7.1.7 THE CITIZENS PRIORITIES When the player presses a special key (on the joystick or keyboard) he/she visualizes the citizens priorities inside the building area. This visual resource helps the player to know who is already convinced, who is not and how good or bad the process of influencing citizens is developing.

FIG. 38 CITIZEN PRIORITY.

In order to avoid overlapping the bars should be placed in one of the corners of the square occupied by the citizen. Not necessarily always the same corner of each square.

7.1.8 THE BUILDING BAR AND TIMER They were designed to help the player to visualize how the building process is taking place and how much time he/she has left to convince the sufficient number of citizens.

FIG. 39 BUILDING PROGRESS BAR. 46

author: Fernanda Dias

7.1.9 THE PULSE The Pulse displays messages related to the events taking place during the game play. It might be used also in sound mode when clicking on the speaker sign, it adds a more pleasent experience to players that would be bothered by

FIG. 40-44 PULSE FEED IN ACTION.

reading it constantly while playing. That suits to specific players and the resource can be activated or deactivated at any time according to their needs.

More relevant notifications, such as a “Build Success” and a “Build Fail” will also be displayed in Pulse, but will offer a special animation and sound feedback, in order to impact the player. Such events will also have animations on the floor (influence area blinks and timer background blinks).

author: Fernanda Dias

7.1.10 GREEN BUILDINGS INFO The info for the “Green Buildings” are displayed when the player hover it. In case the player wants to visualize more details, he has to click in “MORE”. Some of the educational content is delivered in such info panels.

FIG. 45 GREEN BUILDINGS INFO

7.1.11 CITIZEN’S HEALTH The citizen’s health is displayed according to its body color. It gradually changes to black, which means the citizen is near to die by the pollution in the environment.

FIG. 46-49 HEALTH LEVEL DICREASING

author: Fernanda Dias

7.1.12 Leaders The body color was chosen as the fastest manner to show an important information. In order to generate a more immediate recognition of characters the leader will have two distinct appearances: green or red. Via such interface the player recognizes who are their enemies [green leaders] and who are their allies [normal leaders and Leader +â&#x20AC;&#x2122;s] .

FIG. 50 GREEN LEADER

FIG. 51 LEADER +

7.2 INTERFACE SUMMARY On the screen below the main interface elements are being displayed. It is the situation where the player will visualize the biggest amount of elements simultaneously. It is possible to notice in this screen the visual identity unity aimed by the designers, bringing coherence among scenario, characters and the game GUI design. FIG. 52 INTERFACE SUMMARY

PROGRESS BAR COUNTING THE NUMBER OF SUPPORTERS

TIME COUNTER

PULSE FEED

BIO POINTS COUNTER

PRIORITIES DISPLAY

INFLUENCE ZONE

ATTRACTION ZONE

author: Fernanda Dias

8. LOGOTYPE DESIGN

The logo of Hyprions was created in the tight relation to the concept and game play of the game and had a great impact on the further development of the interface visualization. The logo represents the idea of polluting or infecting the game entities and creating the chain of events which bring the environmental catastrophe. The single elements of the letters are linked together in order to create an impression of intersection of all the actions in the game. The visual center of the logo is the stylized letter “O” which has a bigger size in comparison to the other letters of the logo. The size and visual significance of the letter “O” represents the leader in the game which persona is stronger and more powerful and enables him or her to attract and influence citizens in the game. Besides the graphic representation of the leader, the letter “O” also relates to the idea of destruction or demolition by resembling with the prohibiting sign (a circle which is crossed with a line).

FIG. 53 - 54

author: Alexander Firsanov

FIG. 55

FIG. 56

FIG. 57

FIG. 58

author: Alexander Firsanov

9. ANIMATION

The animation’s part in the game has been done with consideration of the whole game environment. The complete animation in the game is coherent with the general aesthetic style of the game. Animators in the game were responsible for the movement and behavior. Most often this is applied to give life to game characters and creatures, but sometimes animations were also applied to other elements such as objects, scenery, vegetation and environmental effects to give the player feel more realistic and entertaining. In the HYPRIONS game, the visual design and animation group tried its best to keep animation style as simple and realistic as possible. The citizens and leaders don’t have any facial expressions so the animators tried to give the game players the feeling of any incident of current game scenario by leaders’ and citizens’ main body part movements. The same philosophy applied on object’s animation. Building construction and destruction held just by appearance of building from the ground and disappearance by going in the ground with slight changes in the color.

9.1 ANIMATION PROCESS Special software packages are used to create the animations, which are used for both object as well as character animation. Animation were mostly done in 3Ds Max 2012 platform. In the starting of the character animation, biped readymade walking animation was used but it was not very feasible according to game environment so manual animations were made with proper animation process. Character animation was a complex combination of many different types of movements, so the Animators made extensive libraries of re-usable animations for each character. Animators worked closely with Programmers and visual design in order to create the best balance between smooth seamless movement and optimized performance on the target platform, keeping in mind how the animations will appear in the context of the game. The other reason behind keeping the animation part quite minimalistic is, not to give much load on the game engine processing. Adobe After Effects and Adobe Flash were also used in the animation part specially while making the trailer of the game. In the process of the whole game animation part, animators made the two following steps:

•

Staging or Blocking First main posing stages were made by inserting the key-frame in the time-line.

•

Tweening and secondary animation After creating the proper stages, tweening was made between key-frames and then, specially in the character animation, secondary animation was created.

author: Ashish Vaishya

9.2 HIGHLIGHTS OF BASIC ANIMATION PLAN

In the game some pre-defined movements and animations were needed according to game concept and visual design. In the starting stage after the clear visualization of the concept, visual design and animation group sat together and defined some of the basic movements and animations which were needed for the game environment to give life to the concept and design of the game. Character animations of citizen and leader were the most important parts of the animation work. Basic actions were defined for the character animation like thinking and conversation animation before doing any kind of action, looking around, scratching head and body animation when they are neutral or standing, sad expression when any action was not completed successfully, happy expression when any action was successfully done, reaction on leader’s attraction animation, pass greeting animation, bursting away animation of citizens at the time of explosion, looking around animation at the time of mouse over and the most important animations were natural and robotic walk animation according to the amount of influence on citizens by a leader. Apart building

from

character,

animation

was

also an important part of FIG. 59 ANIMATION WORKING ON 3DS MAX

animation because it gives a more natural look to the game environment eg. wind mill’s wings rotation animation, effects on the color of plants as per the pollution level, effects and object animation at the time of construction and destruction and blasting. Also to prepare the trailer and for the starting of the game there is a special effect animation for the game logo presentation. When the game player interacts with the game environment, specially when interacting with the citizen or leader menu bar, there is a slight rotation of different icons and text popping animations as for the action of mouse click or mouse over. Animation in a game (animated character, animated object, etc.) bring a game to life – literally – giving players an increased sense of involvement and interaction.

author: Ashish Vaishya

10. SOUND DESIGN

The audio was designed to be coherent with the general aesthetic style of the game. As a guideline, sounds were conceptualized as the interfaceâ&#x20AC;&#x2122;s interpretation of the events happening in the world. Since the alien protagonist is perceiving the world through its ship, the sounds were designed to have an artificial quality to them. Other considerations such as the musical soundtrack were also taken into account into balancing the audio mix.

10.1 SOUND DESIGN

Sounds were designed mostly without a recorded base. Virtual synthesizers were used for most of the sound design, relying on methods inspired in the sound design of science fiction movies. The most common method of designing the sounds was to use a subtractive synthesizer with a simple waveform and shape the sound with filters. After this process, effects such as reverb and delay were applied and the mix was finished by the layering of an equalizer on top. Further reference and methods of design can be found on internet. As an exemplification of a similar process the reader can reference this website: http://www.beesar.com/2010/02/transformers_sound_tutorial/ The software used for the sound design was Propellerhead Reason and Ableton Live, with plugins such as TALELEK7RO and KORG M1 virtual synthesizers. An analog synthesizer, the KORG Monotron was used for certain sound effects. Recordings of live material were done in a SHURE cardioid microphone.

10.2 SOUND PACKAGING AND MANAGEMENT

For integrating the sound effects and music to the game the XACT Audio Authoring Tool from Microsoft was used. This tool allows sound designers to package files which can be referenced by programmers directly in the code.

10.3 MUSIC

Three tracks were created for the game, one for the title screen, one for the gameplay section and one for the promotional materials. They are based on a recurring melodic theme and are designed to be able to loop.

author: Hector Baide

11. EVALUATION TEST

11.1 GUI EVALUATION ANALYSIS In the process of developing the HYPRIONS game, a usability test of the game interface had to be done. The results should show how usable the prototype of the game interface is and also if the testpersons like the visual appearance, to then continue developing it on the right path and to rework parts that are not satisfying yet. The evaluation of the actual game interface was made as a combination of individual practical use of the game interface and, at the same time, a theoretical paper evaluation of that experience. The interviewees were asked to sit in front of a computer screen, where an interactive flash simulation of some game situations was presented. In the given paper questionnaire, the tasks, that had to be completed in the flash simulation, could be found (e.g. “Please try to make the action of building a new facility.”). The evaluation was done with 17 Digital Media Bachelor Students of the Hochschule Bremerhaven on 10th of January 2012. Although we captured the screens and peoples‘ face expressions while play testing, this analysis is based on the self evaluation of the interviewees. We think, the self evaluation can be more important than the real data. If a person needed thirty seconds more to find out how to do an action than his/her neighbor, it may still be that this person would say he/she reached the goal quite fast. Because it did not feel that much, or the neighbor is an advanced computer player in comparison to him/her and is therefore always faster. Summarizing, it can be said that there is no average amount of time of “fast” and “not so fast”. Hence, it would not make sense to compare measured time for every game tester, moreover, a definition of fast and slow also depends on a persons´character – if he/she is e.g. an impatient person. The most important thing is that the player does not feel bored or overstrained by the interface.

11.1.1 QUESTIONNAIRES The questionnaire consisted of eight quantitative questions, asking for the just made experience with the game interface. After giving personal information as name and age, the interviewee should estimate how often he/she plays computer games. The next four questions demanded to judge the usability of interface elements to achieve certain game actions, such as building a new facility, attracting new followers, destroying a facility and moving. In case the interviewee needed help to complete the practical task, an additional qualitative answer was required (“In case you needed help, please specify your main doubt:“). The next questions aimed on knowing how satisfied the person was with the interface elements´ legibility, the hover time (if text info should appear immediately while hovering an icon, or a bit later) and the general visual menu appearance. In the following analysis, only those evaluations will be considered that are filled out completely (except name). As a consequence, only 14 questionnaires out of the 17 will be evaluated. Moreover, one qualitative answer was given, although it was not required in that case. But it will still be considered as a comment.

author: Martha Damus

11.1.2 RESULTS (DATA) 11.1.2.1 Personal information The majority of the 14 interviewees was female (nine female, three male, two where we have no information about the gender). The male persons were 21, 23 and 25 years old, the persons of whom we do not know the gender were 20 and 23 years old and the female persons were between 18 and 26 (one of 18, two of 19, four of 20, one of 21, one of 26). The average male interviewee would then be 23 years old, female interviewee a little younger, 20,33 years old. All of them are Digital Media Bachelor students and although there are still at the beginning of their studies, they are most probably interested in digital media and considered as rather digital media-savvy, which would guarantee that they fulfill the basic requirement of handling a computer and its interface to do the computer test. 11.1.2.2 Previous computer game experience To the question “Do you usually play games?“, the majority of six people answered “not at all“, five “rarely“, one “yes, but not so often“ and two “yes, very often“. The two persons, who stated that they play very often were a woman of 21 years and a man of 25. As the percentage of men and women of all interviewees was not balanced (3+? : 9+? ) and the group of people was not big enough to be representative, it is not possible to conclude if generally men or women play computer games more often. But this is also not the aim of this evaluation, as we do not focus a target group of either men or women, but of both. The two interviewees that play very often, did reply in every of the following four questions, where they had to estimate how fast they found out how to complete a game action, with the first answer choice (“yes, very fast“). Again, the group of people who play often, was too small to draw general conclusions, but it seems, that more game experience makes it easier to complete actions faster. 11.1.2.3 Game Play Actions Amongst the game play actions that had to be completed by the test players there was the task of building a new facility. Eight people said that they found out how to do it very fast, five managed to do it, but not so fast and one (a woman of 20 years) said that she needed help to do it. Unfortunately she did not explain why she had problems. Although it was not required, one person made an additional comment (english translation of the german answer): “order of the different building types is not clear to me“. In the next task: to attract new followers, the result was the same (but this time it was a man of 23 years who needed help). In the required comment, he suggested what would have helped to solve the task: “A status bar which shows me how many people or in what kind of area I can attract people would help“. The third action: to destroy a facility, was made (estimated to be) very fast by 13 people, not so fast by only one, no one needed help to complete the task. Action four: to move was completed very fast by ten people, by four not so fast, no one needed help. It can be stated that the two first actions were not solved as fast as the last two actions. That may be because the test players got used to the interface elements and its logic or structure after the first two tasks. Although that is the more obvious explanation, it might also be that the two last tasks were easier to solve than the first two. Summarizing, the results are really good. Out of four tasks, only two people needed help with one task each and in every question, the majority of people answered that they managed it really fast (“yes, very fast“ was answered by: 57,14% [building], 57,14% [attracting], 92,86% [destroying] and 71,43% [moving]). 11.1.2.4 Legibility Regarding the legibility of the interface elements on the screen, the play testers had to answer amongst five options (very satisfied, satisfied, neutral, dissatisfied, very dissatisfied) and made the following evaluations: eleven persons were satisfied with the font size, Three were really satisfied with it. Seven persons were very satisfied with the color of the font, six satisfied, one was neutral. Nine people were very satisfied with the size of the icons, three were 56

author: Martha Damus

satisfied, one was neutral, one was dissatisfied. Seven interviewees were very satisfied with the color of the icons, four satisfied, two neutral, one dissatisfied. No one was very dissatisfied with anything. The two persons, who play computer games very often, chose either satisfied or very satisfied for every question, regarding legibility. That may be more important data than from someone who does not, or rarely play computer games. As the ones who play often have more experience with game interfaces and should know better what is convenient and comfortable, e.g. for the eyes after some time of playing. In general, the results here were also quite good. Only in the field of font size not the majority of people was very satisfied. So that parameter had to be reworked (although it was not clear if the size should be smaller or bigger). 11.1.2.5 Hover Time The results for hover time were unisonous: every play tester preferred the first option, which means to show the text information immediately when hovering an icon and not showing it only after a moment. 11.1.2.6 Menu Appearance Regarding the legibility and visual harmony of the menu, the answers were more diverse. The interviewees had to choose between different color schemes of the same interface. Four people stated that they feel more comfortable with the first option, the majority of six people liked more option two and four people chose option four. No person voted for option three. As the difference between the majority and the other options was not that much, we finally decided for a color scheme within the group (see interface part of this report).

11.1.3 CONCLUSION - ANALYSIS BY MARTHA The computer test (including the questionnaire) gave us valuable data, presents opinions about visual preferences and shows that the GUI usability is quite good so far. Unfortunately, some errors were made in the questionnaires. Mistakes can always confuse the interviewees and therefore influence the quality of the data. Nevertheless, the committed mistakes are not severe and probably did not interfere. The last question, concerning the menu appearance, was not titled separately and therefore it seemed as it was part of the hovering section, then the questions were not numbered properly (confused order: 1., 2., 3., 4., 5., 3., 6.). Moreover, one answer choice in the game action part was maybe not clear for everyone: “Time was irrelevant“. Every other answer choice (“yes, very fast“, “yes, but not so fast“, “no, I needed help“) was chosen, only that one was crossed never, which could be an indicator for not understanding its meaning. That it would have been better to ask for gender, instead of name was mentioned and explained above already. Another point – although not really a problem – is to offer odd-numbered answer choices as in the legibility section. Even numbers of answer choices force the respondent to express his/her opinion either strongly or as a tendency, but avoids taking a neutral position, which can be more valuable data. Other problems, apart from the questionnaire, were for example, that the interviewee group was not diverse enough. As mentioned before, it was important to have play testers that can use computers, but by having only Bachelor students, we missed players of 14 years and older (our target group aims on 14+). That is problematic on the one hand. On the other hand, our interviewees can not only be considered mediasavvy, but maybe also design-savvy (as it is part of their study course) and those people can give us probably a better (more reflected, deliberated) feedback about visual appearance. A severe problem was caused in our flash simulation of the game flow. As a lack of time or consideration, confirmation screens (or other) were missing to indicate when a task was completed successfully. Therefore, the play testers spent more time and were confused without purpose because they could not be really sure if they reached their goal or not, but had to ask always to one of the assistants. Although the data would be more valuable with less mistakes in the test preparation and accomplishment, the results were satisfying the goals of the pretest. The reactions towards the game interface and its usability were good but some points had to be reworked. author: Martha Damus

11.1.3 THE IMPORTANCE AND OUTCOMES OF THE GUI EVALUATION TEST It is well acknowledged the relevance of prototyping in the process of designing games. Once the HYPRIONS project achieved a stage, where it had passed through the paper prototype tests but could not yet be play-tested in a computer basis, the group decided for a GUI evaluation test. The GUI main interactions was designed as a flash application. Such procedure was of great help for improving the “look and feel” of our project. In addition, aspects such as text style and iconography legibility was made in a paper based test and on a web based tool. The interface test was highly useful for the decision making in the final stage of its design. Such data helped mostly when considering parameters of legibility of elements [icons, text, color contrast] and visual communication [text and icons were clearly understood or not]. The web based test was useful to point the icons that were not so clearly understood by the public. The iconographic questionnaire was also analyzed for the first time and improved after feedback made by some of the group members. The questionnaires were then updated for the second test, that took place in the Hochschule Bremerhave. Although some icons were not well recognized in the web based test, it was concluded after the second test that such icons were understandable for the users with in the game context (when using the flash app). After figuring this point it was decided in a group meeting that the rejected icons were no longer supposed to be redesigned. The test was equally helpful to consider the experience of users that were not attached in any level to the designs presented. Differently of a previous methodology, where the decision making of the interface design was being affected by discussions in the group meetings. Once the project members had their opinions more closely attached to the process of designing it, some points could had been ignored or inaccurate. On the other hand, when users are experiencing the GUI for the first time, they could indicate new points and even reinforce previously discussed ones. As mentioned before the GUI test was relevant for the “look and feel” analysis. It temporarily substituted a finalized computer prototype of the game play proposal. As responsible for the interface design, I had closely observed during the test day if the main actions were satisfactory. If they were clear or confusing, if they were redundant or if they could be simplified somehow. After comparing my personal observations and the data obtained out of the questionnaires it was concluded there was no apparent complexity during the execution of the main actions tested: “Create a Leader” and “Create a leader+” and the Leader four menu actions (build, destroy, move and attract). As previously mentioned, it was noticed during the test day a lack of feedback in the flash application. The user should have some feedback when completing an action, indicating that he / she should move to the next question. The team members were then indicating to move forward to the next action during the test execution. It was concluded that it could have been a richer user experience if some sound feedback were already implemented and some extra pop ups were inserted in such cases. Unfortunately the flash application was delivered in the same date of the test execution. The inefficient time management, crossing the stipulated dead line, made it impossible for the team members to point the app problems - supposedly to be fixed in time for the test day. The questionnaires, according to Martha’s analysis, had some unclear points but unfortunately none of he group members pointed such unclear aspects in time for improvements. The questionnaires were available for revision a week before the test day and was shared with the project members for their analysis and feedback. Some changes were made after the web based test and had a few group feedback. After such changes it was understood by the test writer that there were no longer unclear points in the final questionnaires delivered.

author: Fernanda Dias

The Pulse system was tested in the matter of elements legibility and language style. It was not tested in animated or sound mode as it was still being developed as a concept. The Pulse UI was then finalized based on such results. The question related to the Menu appearance21 had a balanced result therefore it was reconsidered. The final decision was based on the coherence with the game color palette maintaining the game visual identity more clearly unified. It was finalized under the visual group statements and proposal. The evaluation test took place during the month of January 2012. The responsible for the planning were Ashish Vaisha, Fernanda Dias, Hector Baide and Xeni Prassa. The responsible for the web based test and analysis of its results was Fernanda Dias. The responsible for the Flash app was Ashish Vaishya. The handling and assistance with the images for the Flash application was made by Fernanda Dias as well as the writing of the questionnaires for the second test. The responsible for analyzing the test results and presentation of its final data (in the computer test) was Fernanda Dias, Ashish Vaishya and Martha Damus. The responsible for summarizing the computer test results as a written report was Martha Damus. Xeni Prassa and Hector Baide were responsible for the writing style test as well as for its final result analysis. Both also introduced the topic in the final test day, explaining how the paper test was supposed to be handled and its importance. Ashish Vaishya, Fernanda Dias and Martha Damus were assisting the people in the computer test room. The five of us could observe and add our impressions of the test day dynamics during the following project meeting. Although we had noticed some weak points during the evaluation test I believe such step was highly relevant in the design process. The data revealed reflected a more satisfactory level of understanding the user interaction in our project. When fulfilling the tasks in time, certainly we could have achieved more accurate results on the tests. Analyzing the application previously, fixing any possible problems or correcting any unclear questions. Additionally, it was mentioned that if the test had been attended by a larger number of users with more diverse profiles, it could had presented more accurate results. Nevertheless the group was in accordance with the plan presented in the last meeting of 2011. The final interface design delivered

was

reviewed

based on the evaluation test results and its final analysis briefly discussed with the project members. The GUI evaluation test questionnaires

and

its

results are available in the Appendix section 22 .

FIG. 60 THE USABILITY TEST DAY - PHOTO BY MARTHA DAMUS.

21 22

Reference available at pp. 78 question 6. Reference available at pp. 64 - 80.

author: Fernanda Dias

FIG.61 THE USABILITY TEST DAY - PHOTO BY MARTHA DAMUS.

11.2 ANALYSIS OF THE WRITING STYLE PAPER TEST QUESTIONNAIRE Another part of the usability test was developed to test different writing styles for the representation of the real data that will be delivered within the gameplay. As an example we used a piece of environmental information from the news. That example was a two-line sentence which was rewritten in three different styles. We used a journalistic, an activistic and a more greedy way of writing. The interviewees were asked to characterize all styles with some given adjectives with the possibility of giving multiple characterizations for each style, in a paper based evaluation test. The results of that specific part of usability testing should show how usable and understandable some of the components of our systems are and the real data is undoubtedly one of them.

11.2.1 QUESTIONNAIRES The questionnaire was based in three statements written in three different writing styles, which for categorization purposes were named “journalistic”, “activistic” and “greedy”. Though, these three style titles were hidden under the labels Style 1, Style 2, Style 3 for not affecting FIG. 62 THE USABILITY TEST DAY - PHOTO BY MARTHA DAMUS. 60

author: Xeni Prassa

the opinion of the participants. Below each statement was placed a table with adjectives (funny, boring, neutral, interesting and understandable) that could describe the writing style. Participants were asked to cross with an “X” the adjectives that they felt that describe the writing style of each example and multiple crosses were possible when necessary.

11.2.2 RESULTS All of the 17 interviewees completed the questionnaire. At the end of the process we had collected a big variety of combinations of their characterization for each writing style. According to the choice of the students the activistic style (Style 2) was the one which was found as the most interesting (gathered 10 “X”) while at the same time it was said to be pretty understandable (5 “X”). This way of writing was described also as the funniest text (3 “X”). The majority of the participants voted the journalistic style (Style 1) as the most clear to understand and claimed that it was also interesting. It comes out of the results that it is a neutral way of writing, yet a bit boring. For the third and last writing style, the one with the greediest tone (Style 3), students believe that was equally neutral (7 “X”) and understandable (8 “X”), though it didn’t capture particularly their interest (4 “X”). Here it is worth to mention Usability Test Questionnaire Paper Test Style test) although it was not required from the task. They that two participants wrote a comment for(Writing that style of writing, Questionnaires´reviewer: Xeni mentioned that the activistic style that except from funny is also ironic. unvalid questionnaires/out of all ﬁlled out questionnaires: 2/17 => 17 valid evaluations The results can be seen also from the table below.

Journalistic Activistic Greedy

Funny 0 3 1

Boring 2 1 2

Neutral 6 2 7

Interesting 8 10 4

Understanding 9 5 8

NOTE: 2 students mention about the activistic style that exept of funny is also ironic!

11.2.3 CONCLUSION

After the end of usability test we got some useful feedback from the participants. As they claimed, they didn’t have any problems of understanding and following the instructions of this part of the Usability test. The questions and answers were simple and the way of response was also easy to follow. The meaning of all statements was clear and the freedom of using more than one adjective for describing a writing style was helpful for them. With this test we had the opportunity to evaluate the reactions of our potential users and we focused on how usable some of the components of our systems are. The real data that are going to be used is definitely an important component of our concept. Therefore, knowing the weaknesses and the strong points of each writing style was a useful tool for the further development of this task.

author: Xeni Prassa

12. CONCLUSION

At the end of such a long term and complex project it is always interesting to see what and how it was achieved and where are weaknesses. At the beginning of the project, we composed a summarized list of our primary aims for the master project: create a cross disciplinary work situation develop our skills, as everyone came with a different set of qualifications; experience as a group, independent from any customer fulfillment; learn from each other and self organize everything which meant to decide and manage all the processes in the group. We successfully created this cross disciplinary work situation, experienced without any pressure of contract, partners or other external limits, learned from each other (mostly when working in smaller sub groups) and we self organized everything with all its advantages and disadvantages. After two semesters of meeting, creating and developing in the master project team, we deliver a running prototype of a strategy game. Unfortunately, not all the created designs, animations and concept ideas could be realized in the current game (not implemented interface designs, additional character and building animations, the PULSE idea and mockup, etc.). Which problems did we encounter? To get an overview of the group membersâ&#x20AC;&#x2122; opinions, we started to gather comments on trac â&#x20AC;&#x201C; our online project management system. People were asked to post their ideas, to evaluate the whole process and to suggest alternatives â&#x20AC;&#x201C; as if we had a second chance to restart the project. People mentioned problems in the concept part, in the project management or hierarchy and the decreasing motivation of the group members. Concept: As there was no detailed project idea at the beginning, we had to find a common vision of our concept. That was a really time consuming process, that took us four months of project working time. On trac, it was stated that by either narrowing down the extent and complexity of this ambitious final product or having a detailed idea already at the beginning, the result could have been a complete product. Project Management/ Hierarchy: At the beginning of the master project, we decided to have a non-hierarchical structure in our group. Therefore, decision-taking was always a really democratic procedure. Every group member was included in the discussions (unless it was really specific and only discussed in sub groups). As a consequence, some, in that topic less involved persons, got bored. Moreover, we lost working time. Although having project managers who were responsible for the organization of meetings and reminding people of their tasks and deadlines, we felt problems with different senses of responsibility of individuals and also inefficiency. In order to accelerate and direct the working process, some people suggest to assign (temporary) specific decision makers with more influence than our project managers had.

author: Martha Damus

Motivation: During those two semesters some people lost their motivation or interest in the project. Until the end it became more and more clear that we would not finish the game and hence, not deliver a final product until april 2012. Developed designs and ideas that could not be implemented anymore â&#x20AC;&#x201C; due to lack of time and complexity â&#x20AC;&#x201C; may have discouraged the creators. It was said, that motivation is probably bigger, if many people identify (completely) with a project. Although the group acted always democratic, all the decisions were compromises. Possibly, the motivation would have last longer, if we had chosen a more reduced and manageable product aim. Nevertheless, we do not see the project as failing and only leaving an unfinished product! We see it as a journey â&#x20AC;&#x201C; as a learning process in that we reached our main goals of having a cross disciplinary work situation, experiencing with all the freedom we wanted and learning from each other.

author: Martha Damus

13. APPENDIX

13.1 WEB BASED ICONOGRAPHIC TEST

author: Fernanda Dias

13.1 WEB BASED ICONOGRAPHIC TEST

author: Fernanda Dias

13.1 WEB BASED ICONOGRAPHIC TEST

author: Fernanda Dias

13.1 WEB BASED ICONOGRAPHIC TEST

author: Fernanda Dias

13.1 WEB BASED ICONOGRAPHIC TEST

author: Fernanda Dias

13.2 PAPER TEST RESULTS

author: Fernanda Dias

13.2 PAPER TEST RESULTS

author: Fernanda Dias

13.2 PAPER TEST RESULTS

author: Fernanda Dias

13.2 PAPER TEST RESULTS

author: Fernanda Dias

13.2 PAPER TEST RESULTS

author: Fernanda Dias

13.2 PAPER TEST RESULTS

author: Fernanda Dias

13.2 PAPER TEST RESULTS

author: Fernanda Dias

13.2 PAPER TEST RESULTS

author: Fernanda Dias

13.3 COMPUTER TEST RESULTS

author: Fernanda Dias

13.3 COMPUTER TEST RESULTS

author: Fernanda Dias

13.4 FLASH APPLICATION TEST

author: Fernanda Dias

13.4 FLASH APPLICATION TEST

author: Fernanda Dias