Analysis and improvement of tools used in a game-pipeline

Full text

(1)LiU-ITN-TEK-A--08/104--SE. Analysis and improvement of tools used in a game-pipeline Mikael Hasslund 2008-09-12. Department of Science and Technology Linköping University SE-601 74 Norrköping, Sweden. Institutionen för teknik och naturvetenskap Linköpings Universitet 601 74 Norrköping.

(2) LiU-ITN-TEK-A--08/104--SE. Analysis and improvement of tools used in a game-pipeline Examensarbete utfört i medieteknik vid Tekniska Högskolan vid Linköpings universitet. Mikael Hasslund Handledare Gustav Taxén Examinator Ivan Rankin Norrköping 2008-09-12.

(3) Upphovsrätt Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under en längre tid från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/ Copyright The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances. The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page: http://www.ep.liu.se/. © Mikael Hasslund.

(4) Abstract Tools development is a sometimes overlooked process that is crucial for developing high quality games. The experience of the users will vary which makes usability an important issue as well as having good guidelines for communications and development of user interfaces. This report presents the development process of two different tools used in production of high-quality projects at Avalanche Studios and describes both the added functionality as well as the methods used to provide them.. Sammanfattning Programmering av verktyg är en process som ofta är förbisedd men som är mycket viktig för utvecklingen av hög-kvalitativa spel. Den varierande kunskapsnivån hos användare gör att det är viktigt att fokusera på användarbarheten samt även ha bra riktlinjer för kommunikationer och utvecklingen av användargränssnitt. Den här rapporten presenterar hela utvecklingsprocessen av två olika verktyg som används vid utveckling av högkvalitativa projekt vid Avalanche Studios, och går igenom både ny funktionalitet samt även använda metoder för att uppnå detta.. i.

(5)

(6) Acknowledgments Thanks to all employees at Avalanche Studios which have been very helpful and supportive. I also want to thank my examiner Ivan Rankin and Kristina Hasslund for your extensive proofreading. Thanks to my supervisor Gustav Taxén and a special thanks to Mathias Westerdahl who has has been greatly supportive all through my time here at Avalanche and have made me feel like one of the team!. iii.

(7)

(8) Contents 1 Introduction 1.1 About Avalanche Studios . . 1.2 Problem statement and goals 1.3 Glossary . . . . . . . . . . . . 1.4 The structure of this report .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 3 3 3 4 5. 2 Background 2.1 What is a tool? . . . . . . . . . . 2.2 Who makes the tools? . . . . . . 2.3 Avalanche Studios . . . . . . . . 2.3.1 Just Edit . . . . . . . . . 2.3.2 The Location System . . 2.3.3 The Rule System . . . . . 2.3.4 The Rule Editor . . . . . 2.3.5 The World Locations Tab 2.4 Visual programming . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. 7 7 8 9 9 10 10 13 14 15. 3 Method 3.1 Evaluating the User Interface 3.1.1 Heuristic Evaluation . 3.1.2 Usability Testing . . . 3.2 Code Reviews . . . . . . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 17 17 18 19 20. 4 Development 4.1 Rule Editor . . . . . . . . . . 4.1.1 Heuristic evaluation of 4.1.2 Desired features of the 4.2 World Locations Tab . . . . . 4.2.1 Heuristic evaluation of 4.2.2 Desired features of the. . . . . . . . . . . . . . . . the Rule Editor . . . . . . Rule Editor . . . . . . . . . . . . . . . . . . . . . . . the World Locations Tab World Locations Tab . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 21 21 21 22 24 25 25. 5 The new version of the Rule Editor 5.1 New functionality of the Rule Editor . . . . . . . . . . . . . . . . . 5.1.1 1-1 Assignment connection . . . . . . . . . . . . . . . . . . 5.1.2 Firing events using event nodes . . . . . . . . . . . . . . . .. 27 27 27 28. . . . .. v. . . . ..

(9) vi. Contents 5.1.3 5.1.4 5.1.5 5.1.6 5.1.7 5.1.8 5.1.9 5.1.10 5.1.11. Auto-formatting of node positions . . . . . . . . . . . . . . Dynamic creation of hierarchical module structure . . . . . Incremental search in module structure . . . . . . . . . . . Auto-connection of nodes . . . . . . . . . . . . . . . . . . . Quick creation of rules using keyboard . . . . . . . . . . . . Quick creation of rules using mouse . . . . . . . . . . . . . Common functionality (delete, undo/redo, selection, zooming) In-editor compilation of rules . . . . . . . . . . . . . . . . . Template rules for easy access . . . . . . . . . . . . . . . . .. 6 The new version of the World Locations Tab 6.1 New functionality of the World Locations Tab . . . . . . . . 6.1.1 Refinement of location and world system . . . . . . 6.1.2 Multiple open worlds . . . . . . . . . . . . . . . . . . 6.1.3 Common functionality(New/Open/Close/Reload) . . 6.1.4 Usability improvements(Icons/Hierachical Structure). 28 30 31 32 32 32 32 33 33. . . . . .. 35 35 35 36 36 36. 7 Results 7.1 User feedback on the Rule Editor . . . . . . . . . . . . . . . . . . . 7.2 User feedback on the final World Locations Tab . . . . . . . . . . .. 37 37 38. 8 Discussion 8.1 The Development process . 8.2 Future improvements . . . . 8.2.1 Rule Editor . . . . . 8.2.2 World Locations tab. 39 39 39 39 40. Bibliography. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . .. . . . .. 41.

(10) List of Figures 2.1. 2.2 2.3 2.4 5.1 5.2 5.3 5.4 5.5 5.6 6.1 6.2. The ratio of tool programmers to game programmers at 10 professional game developers. Six developers did not know the ratio used at their company or did not want to answer. . . . . . . . . . . . . . The JustEdit editor. . . . . . . . . . . . . . . . . . . . . . . . . . . The Rule Editor opened as a plugin to the main editor. 1: input nodes, 2: operator node, 3: output node . . . . . . . . . . . . . . . The World Locations Tab (as seen in the final version) . . . . . . .. 8 10 13 14. The 1-1 assignment before and after implementing the improvements. A rule implementing the new event node as seen in the Rule Editor. The same rule before and after applying the Orthogonal Hierarchical Graph Drawing Algorithm. . . . . . . . . . . . . . . . . . . . . . . An example of a list of variables, created dynamically and separated in a hierarchical structure using a set naming convention. . . . . . Searching through a list of variables using incremental search. . . . The two most common rule compositions transformed into templates.. 27 28. Switching between open world files using a context menu. . . . . . A context menu implementing the new common functionality of the world tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 35. 29 30 31 32. 36.

(11)

(12) Chapter 1. Introduction This chapter introduces the reader to the concepts which lie at the base of this thesis. Avalanche Studios, the game developer where this master thesis work was conducted, is presented at the beginning of this chapter. The chapter also presents the problem statement and goals for this report.. 1.1. About Avalanche Studios. Avalanche Studios is a game developing company founded in 2003 by Christofer Sundberg and Linus Blomberg. The company focuses on developing original intellectual properties for games using the powerful Avalanche Engine. The Avalanche Engine is an unique engine that powers huge detailed landscapes which are procedurally rendered. Avalanche Studios have previously released Just Cause in 2006 and have announced that they are working on a sequel.. 1.2. Problem statement and goals. In minor game projects, consisting of one or just a few programmers, it is usually enough to do all in-game scripting by manually hacking code. Since everyone has been involved in coding the engine, there are no or few demands on documentation or tools that simplify the work. In larger game projects where the team consists of five or more programmers and one or more designers, the demand for documentation and tool quality naturally increases. Working with tools of decent quality is crucial for the success of any major game project, but tool design is a delicate task that requires good planning and a good insight in usability issues. It is often a balance act between quality and minimizing production time. Tools must always be kept updated, especially when the project size increases. Tools that were usable for one project may be lacking in another. This is why tools must be written in code that is easy to grasp and maintain. Two tools, the Rule Editor and the World Location Tab, are examples where the usability has gone out of control due to the increased complexity (in the form 3.

(13) 4. Introduction. of more and more complex rules, and enormous numbers of world locations). The goal of this master thesis hence is to evaluate these tools, develop guidelines on how they can be improved, implement the improvements and finally conduct testing with real users to decide whether the tools satisfy demands for being usable both on current projects as well as in the future.. 1.3. Glossary. • Avalanche Engine The engine which is the backbone of Avalanche Studios’ JustEdit and is used to develop game projects. The Avalanche Engine power huge procedurally generated landscapes shown in great detail, real-time weather and time-ofday effects and much more. • Breakpoint A place in an application where program execution is paused. Commonly used in debugging. • Debugging The process of removing bugs (also known as defects) of a computer program. • Event Events are commonly used in the Avalanche Engine to describe something happening. Events can be triggered by a number of actions, such as having the player walk by or by explicitly firing the event by defining conditions for when it should be triggered in a rule. • LOD Level of Detail. Includes techniques used for decreasing the complexity of objects when they move further away from the viewer. The purpose is to decrease the workload on the system by improving the efficiency. • NPC Stands for Non-Player Character. In a video game it is a computer controlled character. • Plugin An addon to a host application with the purpose of extending the capabilities of the program. • UML The Unified Modeling Language is a standardized modeling language used to build models of a system (UML models). • WTL The Windows Template Library which is a C++ library for developing Windows applications. It provides classes for dialogs, frame windows, etc..

(14) 1.4 The structure of this report. 5. • XML The Extensible Markup Language (XML) is an extensible high-level language which allows users to define their own elements. It is a multi-purpose language which due to its hierarchical structure is suitable in a vast number of situations.. 1.4. The structure of this report. The report is divided into six parts: • Chapter 1 describes the situation and the purpose and goals of this report. • Chapter 2 provides background on what a tool and a tools programmer are and why they are needed, and background on theories used during the development process. It also presents the tools and systems used at Avalanche Studios relevant to this report. • Chapter 3 describes the working methodology both used and considered during the development phase. • Chapter 4 provides information on the development process of two different tools. Each tool was evaluated and a list of desired features was created. • Chapters 5 and 6 describe in detail the new features and functionality of the finished products. • Chapter 7 describes the users’ reactions and the results from testing of the finished products. • Chapter 8 contains ideas on what could have been done differently during the development phase, as well as discusses future improvements of the developed tools..

(15)

(16) Chapter 2. Background This chapter provides a background on what a tool and a tools programmer are and why they are needed, and background on theories used during the development process. It also presents the tools and systems used at Avalanche Studios relevant to this report.. 2.1. What is a tool?. In this report a tool [15][3] is an application which is used in the creation or modification of game-related content. Content might define anything that makes up a game; graphics, level design, mission objectives, etc. The size and complexity of a tool may differ a lot. Some tools are designed to do something as simple as copying files from one location to another, and another might incorporate editing a full 3d world. The rule of thumb is that the complexity of a tool is relative to the complexity of the problem it is intended to solve. A toolset is a collection of tools that make up the content production of a gamepipeline. Any tool in a toolset should be designed such that it could be reused in multiple projects (as long as it is designed with reusability in mind, which usually is the case). When the quality and quantity of the content of a game increases, the quality of the tools must increase as well. Experience has shown that great tools are a requirement for a great game. Tools can be internal or external. An internal tool usually lacks features and documentation as well as having an ”incomplete” user interface. It is designed primarily for expert users and required features will be added when needed. Tools that are designed for external use, and shipped with the game, are usually rich in features and have a proper user interface. These tools are usually designed so that common users will be able to pick it up and start creating content without much delay. Making tools such as level editors available to the public is usually a good way to keep users interested in the product long after they have finished the actual game (for example by downloading content created by other users). There are several public tools available for editing content of different games which have 7.

(17) 8. Background. been great successes, for instance Hammer and UnrealEd. Most tools never ship with the game though, and are constantly under development as the game is developed. There is a fine balance between quality and quantity of tools. Internal tools, designed for use by the developer only, are usually as featureless and unintuitive as possible. It is common that the code is very difficult to maintain. Usually you want to create the tools as fast as possible but with reasonable quality. If a tool is designed for re-usability and has a code that is easy to maintain, production time is saved that could instead be used to build more tools of decent quality, or to improve current tools or write documentation. If the core functionality is separated into reusable libraries (known as modular programming) and has code which is easy to configure and maintain, several tools will use common libraries which can improve the ability to maintain the code as well as ease debugging. The result is always a better tool. Hence proper, readable code is a plus no matter what the purpose of the tool is.. 2.2. Who makes the tools?. A game development studio can be classified into five different main models regarding toolset maintainment taken from the book Game Engine Toolset Development[15] (see table 2.1). The size of the tools department is usually greatly determined by the financing of the company. A survey was conducted during the Game Developers Conference 2005, where 16 professional game developers were asked about their ratio of tool programmers to game programmers[15] (see figure 2.1). It was not proved that the ratio had any impact on the performance of the teams though.. Figure 2.1: The ratio of tool programmers to game programmers at 10 professional game developers. Six developers did not know the ratio used at their company or did not want to answer..

(18) 2.3 Avalanche Studios. 9. Table 2.1: Organizational Models of Tools Development. 2.3. Organizational Model Dedicated Tools Team. Description A specific tools team both design and support the tools.. Developer Ownership. You build it, you support it. An individual or a team which is responsible for a certain game system makes and supports the tools that use the system.. Game Team Develops; Tool Team Supports. The game team builds the tools, but a tools group keep tools updated and supported for future projects.. Engine Team Develops; Game Team Supports. Similar to Game Team Develops, Tools Team Supports. The engine team creates the tools and the game team adapts the tools to work with the game system they interact with.. Content Team Develops and Supports. The creators of content for the game create their own tools to help themselves be more productive. This model is not commonly used, but rather used in certain special situations.. Avalanche Studios. This section provides background on tools and systems used at Avalanche Studios and relevant to this master thesis work.. 2.3.1. Just Edit. JustEdit (figure 2.2) is the name of the main editor used by world artists and level designers to create content for games. It is designed for internal use and uses a plug-in system to add new functionality to the editor. It is constantly under development and new features and plug-ins are added whenever needed. It is also common that individual instances (versions) of the editor are created for different projects to better fit the current requirements. Whenever needed, features and.

(19) 10. Background. functionality are incorporated from one instance to another. Functionality is divided into systems which are named according to their purpose. Systems which are relevant to this report are described in their own sections (2.3.2 and 2.3.3).. Figure 2.2: The JustEdit editor.. 2.3.2. The Location System. A location is a specified place in the game which could be either mission specific, a place where there exist some special 3D models or just a bookmark set by a designer to help during development. Bookmarks are important for designers when the world gets very large and navigating the world manually would take a lot of time. The information contained in a location object is not only restricted to a set of coordinates describing the position, but could contain data about the location concerning LOD level, 3d models, etc. All locations are stored in their own location files in an XML structure, but to be loaded in game they also need to be referenced from a common world file.. 2.3.3. The Rule System. Rules make up a very important part of a game, one could even go as far as saying that with no rules there would not be any game. A rule could be something as simple as boolean expressions such as If A do B or an arithmetic expression or equation. The expression If A do B might look lacking at first glance but in reality this expression is very powerful, and has been the foundation of all rules that build up a game during the last forty years. The following example might give an idea of just how powerful:.

(20) 2.3 Avalanche Studios. 11. Example 2.1 • If it is raining do take out umbrella. • If it is getting late do make sky darker. • If random variable do make it rain. • If mission objective A is complete do start next mission objective. In the Avalanche engine the rule system is used to control the world simulation and mainly influences spawning and mission specific logic. Rules are described using nodes connected in a graph structure. The different parts that make up an expression are divided into specific node types: variables (inputs), binary operators, assignments and events (outputs). In the Avalanche Engine a rule is stored hierarchically with an operator acting as root (stored at the top of the hierarchy) with inputs stored as children. When the rule is loaded the root operator is loaded which in turn, recursively loads its child nodes until all children have been iterated. Output nodes are always connected to the root operator. The requirements of a valid rule is very strict in that a rule must have exactly one root operator, and at least one input variable and assignment to be validated. All supported node types are described in the following list: • Variables (inputs) are always named and might be of either boolean or float value. • Operator nodes contain an operator which may be defined as any of a wide collection of mathematical expressions. The input to an operator is either of variable type or another operator (making it possible to chain together more advanced expressions). The output is the binary result (true or false) of the operation. • Assignment nodes act as something in between variables and operator nodes and acts as terminating nodes (they do not output to other nodes). An assignment contains both an operator and a named variable. The variable is given the value received after applying the operator on the nodes input value. There may exist several assignments in one rule, but they may only get their input variable from the single root operator. • An event node is a special case of an assignment which works in the same way, only that instead if the input is true an event (which is specified in the variable) is fired. No assignment is performed, rather this acts as one of many different ways of triggering events in the game. The following is a set of examples designed to make the rule notation more clear (examples 2.2-2.5). Each example has the expression first expressed in the node structure, followed by the expression written in C++ and a description..

(21) 12. Background. Example 2.2. A = ( B > C ) ? TRUE : FALSE ; An assignment rule. A (output) is equal to TRUE (1) if B(input) is greater than C(input), and FALSE (0) otherwise.. Example 2.3. A = ( ( ( B > C ) ? TRUE : FALSE ) == D ) ? TRUE : FALSE ; A more complex assignment rule, making use of the chaining functionality provided by the operator node. The root operator is the == node.. Example 2.4. if ( B > C ) { run_event ( A ) ;. }. An event rule. The event A (output) is triggered if B (input) is greater than A (input)..

(22) 2.3 Avalanche Studios. 13. Example 2.5. A = B; This example demonstrates the delimitation that makes simple A = B assignments require more than just two nodes (one input and one output).. Figure 2.3: The Rule Editor opened as a plugin to the main editor. 1: input nodes, 2: operator node, 3: output node. 2.3.4. The Rule Editor. The Rule Editor (figure 2.3) is a plug-in to Just Edit that is designed to edit ingame rules using visual programming. Visual programming is used before manual coding due to the fact that it is more time effective and prevents the user from making errors. It is based on the Rule System described in 2.3.3 and variables, operators and assignments are displayed as connected nodes in a directed flow.

(23) 14. Background. graph. Variables output values to operators, which output to other operators or assignments. The assignments are terminating nodes. The Rule Editor has primarily been used to design rules controlling mission specific logic. Rules were mostly of lesser complexity, such as assignments (A AND A ) = C. It also features a debug mode where the user can evaluate specific rules by attaching breakpoints to nodes and running the game. There are numerous ideas for an improved future version, which would improve the usability of the application when the size of the rule increases as well as implementing a number of new features.. Figure 2.4: The World Locations Tab (as seen in the final version). 2.3.5. The World Locations Tab. In contrast to the Rule Editor, the World Locations tab is not a plug-in but a tab in the base editor (figure 2.4). Its purpose is to keep track of all locations which.

(24) 2.4 Visual programming. 15. are included in the world. All locations are marked to show whether or not it is available for loading by the system. The full list is shown in a hierarchical folder structure with the top folder fittingly named World. There exist plenty of ideas on how to improve the usability of the tab, some which have been partly implemented in previous versions and some that have not. Users have commented that this has resulted in a half-finished look with unwanted or missing functionality.. 2.4. Visual programming. A programming language which lets programmers specify programs by manipulating graphical objects rather than specifying them textually is a Visual programming language[18]. Visual programming languages are further classified into purely visual languages, hybrid text and visual systems, programming-by-example systems, constraint-oriented systems and form-based systems. The purpose of using a visual programming language is to make programming less difficult for the user. Common coding requires that the user has specific knowledge in the language and still it is challenging for the user to specify clean programs without errors. A visual programming language can be designed to prevent the user from making any errors. On the other hand, a visual programming language tends to be of a very high level and puts heavy restrictions on what the user can and cannot do. For the creation of rules in the Rule Editor, a high level visual programming language is a perfect choice since the requirements of a valid rule are very strict and there are only a limited number of actions and objects that the user may use to define a rule..

(25)

(26) Chapter 3. Method This chapter presents the working methodology used during development to evaluate the program.. 3.1. Evaluating the User Interface. Usability Inspection[9] is the common name for a selection of effective methods for evaluating user interfaces to find problems related to usability. The purpose of the methods is to debug and improve code. In a historical aspect Software Inspection[1] was for a long time the most commonly used method, but since 1990 usability inspection has seen increasing use. The methods for evaluating user interfaces can be divided into four categories[8]: automatically, empirically, formally and informally. In empirical methods user interfaces are evaluated by testing with users and studies have shown that during the last 15 years this kind of evaluation has become the most commonly used method[6]. Heuristic Evaluation is an empirical method which was used to evaluate the tools in this report (described in 3.1.1). Informal testing is testing performed by a coder while working on a class. Its purpose is to find bugs in the code early on and increase the coder’s confidence in his code. Informal testing was performed all through the development of the tools. Acceptance testing[16] occurs just at the end of the development and is performed by users. During the testing the users validate that the system works as expected by using it in as realistic way as possible. The test design technique used should preferably be Black box testing[17] which means that the testers would have no knowledge about the internal structure of the program, hence it would be a simple testing of seeing whether a certain input would give the correct output. Usability testing (described in section 3.1.2) is testing performed by users to evaluate the usability of the program. 17.

(27) 18. Method. 3.1.1. Heuristic Evaluation. A heuristic evaluation is a usability inspection method used to evaluate user interfaces and find usability problems. It is an expert method, where the reviewers should be expert users or similar [14] to assure that the reviewers find as many usability problems as possible. The method relies on a collection of guidelines, rather than specifications, and a full evaluation can usually be completed within days which makes this a popular method among software developers. Jakob Nielsen and Rolf Molich listed the first guidelines in 1990 [12][11] but Nielsen has since then presented a new improved list of guidelines[9]: • Visibility of system status The user should always be kept up to date about what is going on, through appropriate feedback within reasonable time. • Match between system and the real world Communications should be conducted in the user’s language, using familiar words, phrases and concepts. Avoid system-oriented terms and make sure that information is presented in a natural order. • User control and freedom Users will make mistakes eventually and will require functionality to both undo and redo actions. • Consistency and standards There should be no confusion about whether different words, situations or actions mean the same thing. • Error prevention Careful design should be applied to prevent the user from creating errors. Error-prone conditions should be checked and confirmation options should be presented to the users before committing error-prone actions. • Recognition rather than recall Keep the user’s memory load at a minimum by making objects, actions and options visible. Instructions on how to use the system should be visible at all times or easy to retrieve. • Flexibility and efficiency of use Accelerators and other ways of speeding up the interaction are liked by both expert and novice users. Users should be allowed to tailor frequent actions. • Aesthetic and minimalist design Irrelevant information should be kept to a minimum, especially in dialogs. • Help users recognize, diagnose, and recover from errors Error messages should be well defined (written in plain language) and indicate both the problem and the solution..

(28) 3.1 Evaluating the User Interface. 19. • Help and documentation Help and documentation may not be required for all systems, but it is always better if it exists rather than to be without it. All information should be easy to search and focus on the users task. The size of the information should be reasonable. The strength of these guidelines is that they are just suggestions, and can be tailored for specific projects and situations (such as Avalanche Studios). When listing the problems found, each problem should be graded to prioritize its importance. Three factors should be considered: How often does the problem arise, how difficult is it for the user to work around the problem, and how annoying will the user find it. In the evaluations conducted in this report suggestions for improvements are ranked using three levels of priority: • Low priority (purely an aesthetic improvement or a minor usability issue or feature). • High priority (large usability issue). • Catastrophe (major usability issue that must be fixed). Studies have shown that using 5 testers is enough to find 85% of the usability problems[10] which proves that applying heuristic evaluations is not only effective in improving the usability of the software, but it is also cost-effective.. 3.1.2. Usability Testing. Usability Testing is a technique for evaluating the user interface by testing it on users. This is in contrast with Usability Inspection methods where the reviewers are expert users who evaluate the user interface without involving common users. The goal of usability testing is to measure how users respond in the following areas [13]: • Efficiency How long does it take people to complete basic tasks? • Accuracy How many mistakes did the users make while using the application? • Recall How much can the user recall from the experience afterward or after a period of time? • Emotional response How did the person react to completing the tasks? Phil Carter [2] suggests a ”laid-back” approach to usability testing: sit alongside someone as they use something. By just observing as the tester uses the application, many of the questions that the observer may have become answered without even asking. Because of its simplicity, it becomes a powerful tool, which is useful in many situations..

(29) 20. Method. 3.2. Code Reviews. A Code Review (also known as Code Reading)[7] is a method for formal inspection of the source code that a developer has produced. This is a special kind of review which has shown to be very effective in detecting and reducing errors in the code. Code Reviews are a common practice at Avalanche Studios and are conducted such that a lead programmer reviews the source code that a member of his group has produced. The concept of Code Reading is loosely defined but could be summarized as follows: • The author hands out his source code, as a preparation for the meeting, to the code readers. About 4000 lines of code are typical although it may vary. • At least two people read the code. Using at least two code reviewers encourages competition and as a study by DIRC[4] has shown, the skill that professionals (even with the same background) show in debugging may vary a lot, hence more than one reviewer would be appropriate. • The reviewers should read all code independently of each other. • The code-reading meeting is hosted by the author after the reviewers have finished reading the code. It should last for about one hour and focus on the problems found in the code. The code should not be iterated row-byrow. A study by AT&T found that the meeting itself may be somewhat overrated since 90 percent of the defects were found in preparation for the review meeting, leaving about 10 percent to be found during the review itself [5]. • The Code Reading ends with the author fixing the problems pointed out by the reviewers during the meeting..

(30) Chapter 4. Development This chapter provides information on the development of the Rule Editor and the World Locations tab. Both tools were evaluated and a list of desired features was created. Each tool is discussed in their own sections in this chapter.. 4.1. Rule Editor. In this section the previous version of the Rule Editor is evaluated and a list of desired features for the next version is presented.. 4.1.1. Heuristic evaluation of the Rule Editor. One major issue which had to be solved before conducting any evaluation whatsoever, was that the previous version of the Rule Editor did not start due to bugs and not being up-to-date with the game system. The focus of the following heuristic evaluation is the usability issues that arose in the Rule Editor after the issues mentioned above had been solved. Details on the terminology used can be found in 3.1.1. • Stability The plug-in frequently crashed which was very frustrating for users as well as it could destroy hours of work. This was a potential usability catastrophe. Although an auto-save functionality would ease some of the frustration, along with proper error messages, it would naturally be a better solution to correct the crashes all together. • Error handling The undo/redo functionality is very common in most modern applications and is a functionality that almost all users are used to. Since there is no way of preventing the user from eventually making an error, this is a a very important feature that should exist. Adding this feature was a very high priority, making this a potential usability catastrophe. 21.

(31) 22. Development • Common functionality Besides undo/redo, common users are used to features such as copy/paste. An application that lacks these common features tends to generate a degree of uncomfortableness due to the inconsistency with similar existing applications. Accelerators (such as keyboard shortcuts) are also very common, which should also be used in the same way as in similar applications. There is also one apparent reason why these features are as common as they are; they are very time-saving. Hence adding these features was of very high priority. Especially noticeable was the lack of the ability to delete nodes which is a major usability issue. The context menu (the menu that appears when you right click on objects) is also a nice time saving feature which would make the plug-in act more consistently compared with similar applications. Since the plug-in manages multiple objects at the same time, the common functionality to select multiple nodes by shift-selections and by dragging boxes was of very high importance. Although the application supported selection boxes at the time, it didn’t support manipulation of more than one object at a time. • Preserving Context The plug-in presents the data in the form of a node-tree, which helps the user keep the context, but if the tree tends to get too complex there need to be ways of preserving the context. One functionality is for example the ability to zoom, which is also consistent with similar applications. Existing methods for handling boolean values (which the tree mainly consists of) and nodes could also be implemented to keep the tree easy to ”read” at all times. • Performance Delays not only slow down work but it may also make the user ask himself whether or not the application has crashed. Debugging rules causes a major slow down which renders the debug mode completly unusable. Although improving performance would be of very high priority if one would use the debug mode, interviews with users showed that they almost didn’t use it at all, making this a somewhat low priority. • Help and documentation Although the existing documentation was lacking, the application was not really complex enough to demand a thorough help and documentation functionality. Whenever a user ran into a problem, it would still be more convenient to just go and ask another user directly. This would not have been the case if the common user had lacked computer experience.. 4.1.2. Desired features of the Rule Editor. The new features of the next version of the Rule Editor was defined by applying the results from the heuristic evaluation from section 4.1.1 and by conducting user interviews..

(32) 4.1 Rule Editor. 23. 1. Make the Rule Editor run without frequent crashes and errors. Due to bugs, the current version could not start at all without fixing certain bugs. This also involved fixing a number of bugs concerning not only the user interface but also the way rules are loaded, saved and handled in the application. 2. As much of the interaction as possible should be done through context menus. The user should be able to perform all tasks without using the keyboard. 3. Accelerators (keyboard shortcuts) should be provided for expert users to speed up operations. All tasks should be possible to perform without using the mouse and only rely on the keyboard and keyboard shortcuts. This includes moving between nodes using the keyboard arrows. 4. The system should allow nodes to be connected automatically. Since the requirements of the rules are very strict, it was common that new nodes could only be connected through one or two different ways. The system should allow the user to choose how new nodes should be connected when more than one option exists. 5. The user should be allowed to undo/redo actions. In the current version only a limited number of actions supported undo/redo and due to bugs it didn’t always work as expected. 6. The user should be allowed to delete nodes. 7. The list of variables, shown as a context menu, should be created dynamically and be built in a hierarchical matter. The hierarchical structure should be created by making use of the naming conventions, splitting a variable name into tokens which will form the hierarchical structure. The purpose of the structure would be to support variable lists containing a huge number of variables. This list should also support incremental search for easy access. 8. Context menus regarding selection of actions (such as creating new nodes) and variables should be created dynamically since the list of variables may differ as well as allowed actions. 9. Connections between nodes should be created/modified manually by dragging a line from one node to another. Only valid connections should be possible. 10. Concerning the look of the nodes, they all should have relevant labels (showing their name, operator, etc.) as well as dynamically altering their size to best fit the contained information. 11. The user should be able to create simple assignment rules ( A = B ) by using just two nodes. As seen in example 2.5 the Rule System requires a total of four nodes, hence this could only be achieved by circumventing the delimitation of the Rule System, by defining it as a special case in the Rule Editor..

(33) 24. Development. 12. The system should support selection of one or more nodes at once, as well as operations such as delete should be applied to all selected nodes. 13. The system should support a number of template rules, with node structures which is common in the rule design, to speed up the visual programming. 14. The system should support auto-formatting of the placements of all nodes such that it should be as easy as possible for the user to read. An autoformatting algorithm would both change the positions of the nodes and zoom in and out to find the best suitable view of the rule. 15. It should be possible to view all nodes in two modes: minimized and nonminimized. In minimized mode only the most important information such as name and type were shown, and in non-minimized mode also information about its connections and values was shown. This was implemented in the previous version although it did not always work as expected. 16. The code design should be rewritten to improve maintainability as well as to increase support for future possible improvements. 17. The system should support not only assignments, but also firing of events. The previous version of the Rule Editor did not have this feature although the Rule System supported it. Adding this feature would require the creation of a new node type (an event node) as well as tweaking the rule system and modifying the compilers so that the rules would compile properly (while containing backward compability). 18. It should be possible for the user to compile rules from within the editor. This would also involve making sure that rules are validated properly to prevent error-prone rules from compiling. The visual programming language prevents the user from making errors when connecting nodes with each other, but this validation is still required because it does not prevent the user from creating unfinished rules (see section 2.3.3 for the requirements of a valid rule). 19. The user should be allowed to zoom in and out in the rule view to get a more synoptical view of the rule. Support should also be added for zooming automatically (in relation with the auto-formatting functionality) to a view where all nodes are shown.. 4.2. World Locations Tab. In this section the previous version of the World Locations Tab is evaluated and a list of desired features for the next version is presented..

(34) 4.2 World Locations Tab. 4.2.1. 25. Heuristic evaluation of the World Locations Tab. The previous version of the World Locations Tab is both ridden with bugs and has a lot of missing functionality (some which are critical for using the application). As with the Rule Editor, the most critical issues were resolved before conducting the evaluation. • Stability One major issue with the world locations tab was that some actions didn’t always work, or didn’t work as expected. If a tool doesn’t work it can’t be used, hence this is a usability catastrophe that must be fixed. • Error handling Users would work with locations by checking/unchecking a box next to the location in the list, to signal whether or not the location should be loaded (and included in the world). Clicking in a box for a folder (containing one or more locations) would alter the properties of all containing locations. Since this could potentially alter the properties of a large number of locations, some kind of error handling would be useful (such as undo/redo functionality). • Preserving Context All loaded locations were shown in a plain list without any hierarchical structure at all. When the number of locations increases the user will eventually loose overview since the size of the list will go out of control. A solution such as dividing the list into a hierarchical structure would be a much better solution and was given a very high priority. • Performance The World Locations Tab suffered from long loading times and when switching between tabs the system seemingly froze for long time periods. This was a usability problem of high priority since it was very annoying for the user and directly affected the development times. • Help and documentation The common guideline at Avalanche Studios is to ask another user when a problem arises (preferably another expert user). But documentation on how to use the tab was lacking and this would present a steep learning curve for new users. Since hiccups in the system would arise if users use worlds and locations in the wrong way, this could be a main usability issue.. 4.2.2. Desired features of the World Locations Tab. The new features of the next version of the World Locations Tab was defined by applying the results from the heuristic evaluation from section 4.2.1, conducting user interviews and by arranging meetings where users and coders discussed the future of the tab. 1. A refinement of the locations and world file system should be made. In the previous version, only one common world file (which contains all locations) was allowed which several users may had open at the same time, and it would.

(35) 26. Development be desired that users could define their own local world files to work in as well as defining directly in the location files whether locations are included in the common world. A script should be written that iterates all location files and creates a new world file which includes all locations which are flagged as being included in the world. 2. The list of locations should be divided automatically into a hierarchical structure using a set naming convention. All locations included in the common world file should be marked as being so and be shown under the folder named world. 3. All locations, not only those included in the common world file, should be loaded and stored in the locations list. Locations not included in the world file should be shown under the folder named external world locations. 4. The system should allow the user to define a default local world file that is loaded, instead of the common world file, when the user starts the main editor. 5. It should be allowed to have multiple worlds open at the same time. Switching between worlds would be quick and easy. Support should be added for creating new world files, open existing world files as well as save functionality. It should also be possible to close all local world files (the common world file should always be open since it is the backbone of the current game project). 6. The loading of all locations had shown to slow down the system in the current version. The system should always keep track of the currently open world files, and store location properties as well as the structure (which folders are maximized/minimized). It is important that loading should only be conducted when needed. 7. The user should be presented with a list of actions in the form of a context menu when selecting a location. This is implemented in the previous version although it does not work as expected due to some bugs and missing functionality. 8. The usability of the user interface should be improved by having different icons for folders and files. 9. When a user selects the action to teleport to a location, the camera should be moved to the proper position.. 10. Open world files should be possible to reload through the user interface, to show changes that have been made from outside the editor. 11. Increase stability and usability of the application by fixing a number of diffent bugs..

(36) Chapter 5. The new version of the Rule Editor This chapter provides information on added functionality in the next version of the Rule Editor.. 5.1. New functionality of the Rule Editor. New functionality was added by following the list of features specified in section 4.1.2. All new features are discussed in the following subsections.. (a) The ”workaround” seen in the first version to(b) The same assignment as seen in the final vermake assignments work. sion.. Figure 5.1: The 1-1 assignment before and after implementing the improvements.. 5.1.1. 1-1 Assignment connection. The most common structure among all rules in Just Cause 2 was the trivial assignment when one variable is equal to another. Due to delimitations in the plug-in this connection was not possible to create using just 2 nodes (1 variable and 1 output). The limitation is that a rule must have one root operator to be valid, 27.

(37) 28. The new version of the Rule Editor. and since an operator in turn requires two input variables you ended up with something like in the figure 5.1a. The solution was to set a special 1-1 assignment case which looks like in figure 5.1b in the editor but still is stored in the rule file as in figure 5.1a.. 5.1.2. Firing events using event nodes. A new event node (see figure 5.2) was implemented that acts as a special case of an output node. This new node type allows the user to enter the name of an event in the game which would be fired when the conditions (input is either true or false) is approved. For example this new functionality could be used to change the weather whenever a specified condition is true. Implementing support for this functionality required some alterations to the rule compiler and care had to be taken to make sure that rules still were backwards compatible. Rules that have events specified will still be validated in an old game system, but all events will be skipped.. Figure 5.2: A rule implementing the new event node as seen in the Rule Editor.. 5.1.3. Auto-formatting of node positions. Nodes are connected as in a hierarchical graph. When the number of nodes in the structure increases, the readability of the structure decreases. An algorithm was defined that could automatically alter the positions of the nodes on screen to increase the readability (see figure 5.3). The auto-formatting algorithm would have several desired features: • Unconnected groups of nodes would be separated. • Alter the horizontal positions of the nodes such that they are ordered regarding to their inheritance, with input variables to the far left and output variables to the far right. • If possible remove all crossing connections by switching the vertical position of pair of nodes..

(38) 5.1 New functionality of the Rule Editor. 29. • Prefer to draw connections as straight horizontal lines when possible. Alter the vertical positions of nodes to allow this.. (a) A rule where a number of nodes have been(b) The view after applying the auto-formatting manually added. algorithm on the same rule.. Figure 5.3: The same rule before and after applying the Orthogonal Hierarchical Graph Drawing Algorithm. A full algorithm was created, and named Orthogonal Hierarchical Graph Drawing Algorithm, which was conducted in five steps as described below. The input to this algorithm is a set of nodes: 1. Unconnected groups of nodes are separated. The consecutive steps are all conducted on each group of nodes, one at a time while offsetting the vertical position of the nodes regarding to the final offset of the previous group. 2. Iterate the graph and define the depth of each node as: depthn = max (children_depth) 3. Calculate the final column position of each node by using: columnn = max (parent (children_depth)) 4. Removement of crossing connections. A crossing connection is found if the following specification is true: A1y > B1y AN DA2y < B2y OR A1y < B1y ORA2y > B2y Where A1 is the upper left node connected to the lower right node B2 and A2 is the lower left node connected to the upper right node B1 . The algorithm is conducted in three steps, starting at depth = 0to depth = n. (a) Start with depth = 0. continue..

(39) 30. The new version of the Rule Editor (b) Get the number of crossing nodes at the current depth. If there are no crossing nodes, increase the depth and repeat step b. Else continue. (c) For a crossing connection A1 − A2 , B1 − B2 swap the horizontal position of A1 and B1 . If there is still exists a crossing connection which includes A1 − B1 , revert and swap the horizontal position of A2 and B2 . Go to step b. Else decrease the depth and go to step a. 5. This step minimizes the number of non-horizontal connections and is an algorithm divided into four steps. An adaption fails if another node is currently at that position or if nodes would need to switch positions. (a) Start with depth = 0. Continue. (b) For each node, from top to bottom i. Try to adapt horizontal position to parent. ii. If adaption is not possible, try adapting to child. iii. If an adaption of the horizontal position was made successfully, go to step a. (c) Increase the depth. Go to step b. If depth = f inaldepth the algorithm is finished.. Figure 5.4: An example of a list of variables, created dynamically and separated in a hierarchical structure using a set naming convention.. 5.1.4. Dynamic creation of hierarchical module structure. A list of all variable names (or modules which is how they are defined in the plugin) is loaded in the editor through a singleton class. The drawback is that this list isn’t sorted in any way which make viewing of the list close to impossible (due to.

(40) 5.1 New functionality of the Rule Editor. 31. list sizes of more than 1000 items). Hence the list must be dynamically built and divided into a hierarchical structure. Luckily there are strict naming conventions which could be used to divide a variable into tokens, where every token acts as a folder as in figure 5.4. The primary objective was to allow support for the default Just Cause 2 variable naming convention but support was also added for naming conventions that may be used in the future or has been used in past projects: • JC2 Mission01objective02 ⇒ Mission/01/objective/02 • Grouping Mission01objective02 ⇒ Mission01/objective02 • dot mission01.objective02 ⇒ mission01/objective02 The dynamical creation is further improved to clean the created structure, removing unnecessary folders where it would be better to keep the structure as it is.. 5.1.5. Incremental search in module structure. Incremental search is another improvement of the dynamically created list. The purpose is to allow the user to quickly find variables which he knows the name of (or at least knows part of the name). The add-on is a key which the user enters through the keyboard and is used as a base to create the structure, including only variables which matches the key (fully or in part). The key is reset whenever the context menu is closed but the user may alter it through direct input through the keyboard as long as the menu is open (which will make the menu redraw immediately using the new key as a base). If the user inputs a key which would render an empty structure, the input is ignored. An example of a dynamically created list can be seen in figure 5.5. Figure 5.5: Searching through a list of variables using incremental search..

(41) 32. 5.1.6. The new version of the Rule Editor. Auto-connection of nodes. Since the structure of a valid rule is very strict it is easy to specify rules for connecting new nodes and for keeping the structure valid at all times.. 5.1.7. Quick creation of rules using keyboard. The user may move between individual nodes using the arrow buttons on the keyboard. If the user presses the shortcut for creating a new node, a context menu is shown which is created dynamically and tailored to the demands of the currently selected node.. 5.1.8. Quick creation of rules using mouse. The basic requirement for working with a mouse consists of context menus which was defined for all actions. Add-ons were coded which would allow the user to create rules using only the mouse (besides entering certain values on occasion using the keyboard). The create-node context menu is shown when the user right clicks in the background of the rule view (look in the functionality above to read how it is created), and if a node is currently selected the new node will be connected to it. Otherwise a connection will be created automatically. If the user right clicks on a node, action context menus, which are tailored for the specific rule types, are shown.. 5.1.9. Common functionality (delete, undo/redo, selection, zooming). Operations such as selecting several items, deleting items and being able to undo or redo actions are common functionalities in tools which improve the user experience considerably, hence these functionalities have been implemented in the system. Zooming enables the user to easily get a clear view of the currently opened rule.. (a) A 2-1-1 connection template.. (b) A 1-1 connection template.. Figure 5.6: The two most common rule compositions transformed into templates..

(42) 5.1 New functionality of the Rule Editor. 5.1.10. 33. In-editor compilation of rules. Rules must be compiled before being usable in the game and increase the usability of the plug-in Functionality for compiling rules from within the editor were implemented.. 5.1.11. Template rules for easy access. An investigation of all existing rules in Just Cause 2 showed that two rule compositions were commonly used (see figure 5.6). The most common structure were simple assignments of one variable to another. By using template rules a user could quickly create new rules by selecting a template and then just change the parameters of the nodes to his liking..

(43)

(44) Chapter 6. The new version of the World Locations Tab This chapter provides information on added functionality in the next version of the World Locations Tab.. 6.1. New functionality of the World Locations Tab. New functionality was added by following the list of features specified in section 4.2.2. All new features are discussed in the following subsections.. 6.1.1. Refinement of location and world system. The Location System used in the editor was modified to allow the user to specify default world files other than the common world file. All locations stored in a common folder are loaded into the editor, not only those included in the world file. Locations which are included in the currently open world file, are marked as such.. Figure 6.1: Switching between open world files using a context menu. 35.

(45) 36. 6.1.2. The new version of the World Locations Tab. Multiple open worlds. Functionality was implemented to allow the user to have multiple worlds open at the same time, and switching between them is trivial using a context menu (see figure 6.1). This improves the usability of the tab as the user can for example have multiple worlds opened for testing or backup.. 6.1.3. Common functionality(New/Open/Close/Reload). As a step in handling local world files, common functionality for handling actions such as creating new files, open and closing files as well as reloading the currently open file was added (see figure 6.2). The user would for example want to reload the world file if changes have been made from outside the editor.. Figure 6.2: A context menu implementing the new common functionality of the world tab.. 6.1.4. Usability improvements(Icons/Hierachical Structure). Basic improvements of the user interface were implemented to ease the user experience. The list of locations is created dynamically in a hierarchical structure using a set naming convention. Folders and files have different icons to prevent the user from confusing them with each other..

(46) Chapter 7. Results This chapter describes the user response on the new version of the Rule Editor and World Locations Tab. Both tools were tested using usability testing (described in section 3.1.2) and the final versions accepted after conducting a final acceptance test. Acceptance tests were conducted by having a user test the tool in a real project.. 7.1. User feedback on the Rule Editor. The Rule Editor was tested by a total of five users with very different backgrounds: both hardcore programmers and designers without any programming experience. This was very noticeable due to the fact that different test subjects used the application in different ways. Most noticeable was that the ability to use keyboard shortcuts for most operations was appreciated by some (especially the programmers), while other users appreciated the fact that you didn’t have any keyboard shortcuts at all and just stick to using the mouse for all operations. This feedback showed that the decision to design the user-interaction for both kind of users (pro-mouse and pro-keyboard), and separate the functionality to remove all dependencies on each other, turned out well. The additions of template rules, auto-connection of nodes, the 1-1 rule connection and other features which sped up the production times were very well received by users who had experience of the old version of the Rule Editor. New users who couldn’t make any comparisons mainly felt that these new features were such critical add-ons that they couldn’t imagine going back to the old version. All users commented on the new context menu design, and on how much quicker and easier it was to navigate through large amount of rules. The incremental search functionality was not thoroughly tested since users tended to navigate through the hierarchical structure manually at all times, but test users liked the idea and was sure that it would be of use eventually. Still there existed some criticism on the user interface. An improved debugging system was missed by one expert user, and a common comment was on design 37.

(47) 38. Results. decisions such as the fact that the user can’t define their own shortcuts in an XML file and that the different frames couldn’t be resized by the user. The majority of these issues existed due to limitations of the WTL library, which would require major time-consuming workarounds to be implemented (hence given a very low priority during planning).. 7.2. User feedback on the final World Locations Tab. The World Locations tab worked as a prototype for a new location system and therefore designers and users were involved in the design all through development (in contrast to the development of the Rule Editor). The current version was reviewed regularly, and the comments and ideas from the designers shaped the specifications for the next iteration. In the final review, users were satisfied with the resulting functionalities, especially the feature to not being restricted to just one open world file which would result in a change in how users work with locations. The new features were all well received due to the fact that they would make the work of the designers both easier and quicker. On the other hand, plenty of new ideas on improvements for a next version arose and it is most certain that the current version is not the final one..

(48) Chapter 8. Discussion In this chapter possible future improvements on the tools are discussed as well as commenting on the development process.. 8.1. The Development process. One common problem in coding tools is that you often have to make decisions whether to go for quality rather than short development times, and usually this would result in going for decent quality while minimizing the development time as much as possible. When the plug-ins in the report were coded, time was a minor issue (but still an issue). Some parts were time-critical due to the involvement of other personnel than the master thesis worker while others were under no time stress whatsoever. The projects were carefully planned using techniques described in this report, and satisfactory results were achieved within schedule. Still due to lack of time and experience, some solutions may lack a certain elegance.. 8.2. Future improvements. In the following subsections possible improvements are discussed for both the Rule Editor and the World Locations Tab.. 8.2.1. Rule Editor. The new version of the Rule Editor has been designed with future increasingly demand on the usability in mind. It has support for more complex and larger rules than used in current projects. Still it is very possible that new improvements will be necessary in the future, so the code has been re-factored to allow for instance new node types to be added without much work. There are still some missing common functionality such as complete support for undo/redo and the debug mode lacks functionality to be of real use, so there 39.

(49) 40. Discussion. is still room for improvements.. 8.2.2. World Locations tab. The location and world system are potentially very game-specific, and may eventually go through a complete redesign which may make the new version of the world locations tab very short-lived. On the other hand, this is a common issue in tools design that no tool is ever complete but always more or less under construction..

(50) Bibliography [1] Frank Ackerman, Lynne S. Buchwald, and Frank H. Lewski. Software inspections: An effective verification process. Software IEE, pages 31–36, Volume 6, Issue 3 May 1989. [2] Phil Carter. Liberating usability testing. 25 years of CHI Conferences:a photographic essay, pages 18–22, Volume 14, Issue 2 March 2007. [3] T. Premkumar Devanbu. Re-targetability in software tools. ACM SIGAPP Applied Computing Review, pages 19–26, Volume 7, Issue 3 1999. [4] Alessandra Devito Da Cunha and David Greathead. Does personality matter?: an analysis of code-review ability. Communications of the ACM, pages 109–112, Volume 50, Issue 5 May 2007. [5] Robert L. Glass. Practical programmer: inspections - some surprising findings. Communications of the ACM, pages 17–19, Volume 42, Issue 4 April 1999. [6] Tasha Hollingsed and David G. Novick. Usability inspection methods after 15 years of research and practice, chapter Proceedings of the 25th annual ACM international conference on Design of communication, pages 249–255. ACM, 2007. ISBN 978-1-59593-588-5. [7] Steve McConnell. Code Complete. Microsoft, 2 edition, 2004. ISBN 0-73561967-0. [8] Jakob Nielsen. Conference Companion on Human Factors in Computing Systems, chapter Usability Inspection Methods, pages 413–414. ACM, 1994. ISBN 0-89791-651-4. [9] Jakob Nielsen. Usability inspection methods. John Wiley & Sons, 1994. ISBN 0-471-01877-5. [10] Jakob Nielsen. Why you only need to test with 5 users. [2008-06-12]URL: http://www.useit.com/alertbox/20000319.html, 2000. [11] Jakob Nielsen and Rolf Molich. Improving a human-computer dialog. Communications of the ACM, pages 338–348, Volume 33, Issue 3 March 1990. 41.

(51) 42. Bibliography. [12] Jakob Nielsen and Rolf Molich. Proceedings of the SIGCHI conference on Human factors in computing systems: Empowering people, chapter Heuristic evaluation of user interfaces, pages 249–256. ACM, 1990. ISBN 0-201-50932-6. [13] Jeffrey Rubin. Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests. John Wiley & Sons, 1994. ISBN 0-471-59403-2. [14] Ben Schneiderman and Catherine Plaisant. Designing the User Interface. Addison-Wesley, 4 edition, 2005. ISBN 0-321-26978-0. [15] Graham Wihlidal. Game Engine Toolset Development. Thomson Course Technology, 2006. ISBN 1-59200-963-8. [16] Wiki. Acceptance testing. [2008-07-08]URL: http://www.softwaretestingwiki.com/doku.php?id=acceptance_testing, 2008. [17] Wiki. Black box testing. [2008-07-08]URL: http://en.wikipedia.org/wiki/Black_box_testing, 2008. [18] Wiki. Visual programming. [2008-07-08]URL: http://en.wikipedia.org/wiki/Visual_programming_language, 2008..

(52)

No results found