Lappeenranta University of Technology Faculty of Technology Management Department of Information Technology
Master’s Thesis
Risto Laine
VIDEO GAME – FROM SOFTWARE TO EXPERIENCE
Examiners: Professor Kari Smolander D.Sc Jussi Kasurinen
ABSTRACT
Lappeenranta University of Technology Faculty of Technology Management Department of Information Technology
Risto Laine
Video Game - From Software to Experience Master’s Thesis 2012
102 pages, 11 figures, 19 tables and 4 appendixes
Examiners: Professor Kari Smolander D.Sc Jussi Kasurinen
Keywords: software engineering, video game, game design, user experience, creative industry
The aim of study for this thesis was to form a view of video game development in the industry, describe the development processes of studied organizations, evaluate them with software engineering literature and discuss the relevance of ISO/IEC 29110 -standard for video game development. Seven SME companies from South-East Finland were interviewed in four rounds including game designers, testers, programmers, artists and upper management. Grounded theory was applied to the analysis of the data. Current software engineering literature was found unable to explain video games and their development. The studied organizations implement processes, tools and know-how to embrace the iterative creativity to produce the core of video games - experience. This paradox of knowledge management and its effects on the development processes needs further study in order to understand the development processes in video game industry.
ii TIIVISTELMÄ Lappeenrannan teknillinen yliopisto Tuotantotalouden laitos Tietotekniikan koulutusohjelma
Risto Laine
Videopeli – Ohjelmistosta elämykseksi Diplomityö 2012
102 sivua, 11 kuvaa, 19 taulukkoa ja 4 liitettä
Tarkastajat: Professori Kari Smolander TkT Jussi Kasurinen
Hakusanat: ohjelmistotuotanto, videopeli, pelisuunnittelu, käyttökokemus, luova teollisuus Keywords: software engineering, video game, game design, user experience, creative industry
Työn tavoitteena oli tutkia videopelien kehitystä alan teollisuudessa, kuvata valittujen organisaatioiden tuotantoprosessit, selittää tulokset ohjelmistotuotannon kirjallisuudella ja tarkastella ISO/IEC 29110 -standardin soveltuvuutta peliteollisuuteen. Seitsemän Kaakkois-Suomen pelinkehitys-organisaation parissa suoritettiin neljä haastattelukierrosta (suunnittelijoita, testaajia, ohjelmoijia, taiteilijoita sekä johtoa). Grounded theory - menetelmää käytettiin analyysissä. Ohjelmistotuotannon kirjallisuus ei kyennyt selittämään videopelejä tai niiden kehitystä. Tutkitut organisaatiot käyttävät prosesseja, työkaluja ja tieto-taitoa iteroivassa prosessissa tuottaakseen videopelien ytimen – kokemuksen. Tästä tiedonhallinnan paradoksista, ja sen vaikutuksista pelikehitysprosesseihin tarvitaan lisätutkimusta, jotta videopelikehitystä ja toimialaa voidaan ymmärtää.
iii ACKNOWLEDGEMENTS
“I have no idea what I want to do… but I’ll keep on looking.”
My compulsory service at the Finnish Defense Force had ended. I quit ice-hockey - the career of my life. “I’ve always been ok with computers….” was the thought that brought me to lappeen Ranta (correct notation).
I noticed something was off – I have to study, instead of wanting to. To my rapidly declining motivation economics and business provided a small comfort (trust, tacit knowledge, organizations, leadership, open innovation, entrepreneurship, etc.). Still - nothing felt truly mine.
I became an active student: in charge of freshmen in the IT guild (Cluster), student representative (Edari), coach of ice-hockey team (ParruHT). I founded a video game club (LAG) with fellow gamers. I was one of the founders on the student entrepreneurship society (LUTES). I even founded a company (TeRiSolutions Oy/Ltd) with a friend. When things got rough I was lucky to find out that we have a great student health care system (YTHS). When in need, ask for help.
However I still didn’t know what I wanted to do… With this thesis I have slowly become to acknowledge that games are what I want to work with. I am passionate about games. By finding what keeps you naturally motivated, action becomes easy working out of interest instead of necessity. If you are not quite sure, keep looking.
Enjoy the search!
iv ACKNOWLEDGEMENTS
I would like to thank Kaakon peliklusteri for this opportunity. I am lucky to be able to study the industry I am passionate about for my master’s thesis. I hope this is a start for an interesting career. Thanks to Jussi Kasurinen for managing the SOCES project and directing this thesis.
Thanks to Corbin & Strauss for relieving me to my scientific journey without the encumbrance of enforced rules. Much of the same wisdom can be implied on life in general:
“How a person does qualitative analysis is not something that can be dictated. Doing qualitative research is something that a researcher has to feel him- or herself through. – It is up to the individual to make use of procedures in ways that best suit him or her.”
To my family and friends, I love you.
Lappeenranta, 2012
Setämies, Risto ‘Riisto’ Laine
v TABLE OF CONTENTS
1 INTRODUCTION ...... 4
2 VIDEO GAME INDUSTRY ...... 5
2.1 GROWTH ...... 5
2.2 VALUE CHAIN...... 6
2.3 DIGITAL DISTRIBUTION ...... 6
3 VIDEO GAME DEVELOPMENT ...... 8
3.1 REQUIRED SKILLS ...... 8
3.2 PHASES OF PRODUCTION ...... 11
4 VIDEO GAMES IN SOFTWARE ENGINEERING ...... 13
4.1 A GAP OF KNOWLEDGE ...... 18
5 RESEARCH PROCESS ...... 21
5.1 GROUNDED THEORY ...... 21
5.1.1 DATA ANALYSIS ...... 22
5.2 ORGANIZATIONS ...... 24
5.3 INTERVIEWS ...... 26
5.4 JUSTIFICATIONS FOR CHOOSING GROUNDED THEORY ...... 26
6 RESULTS ...... 29
6.1 ORGANIZATION ...... 29
6.1.1 ORIENTATION ...... 29
6.1.2 EXPERIENCE ...... 31
6.1.3 STRUCTURE...... 31
6.1.4 SELF-EVALUATION ...... 33
6.2 DEVELOPMENT ...... 34
6.2.1 METHODS ...... 34
6.2.2 DESIGN ...... 36
1 6.2.3 TESTING ...... 38
6.2.4 OUTSOURCING ...... 41
6.2.5 SELF-EVALUATION ...... 41
6.3 DEVELOPMENT PROCESS FIGURES ...... 43
6.4 ISO/IEC 29110 ...... 52
6.5 SUMMARY ...... 54
7 COMPARISON TO LITERATURE ...... 57
7.1 CREATIVITY IN THE VIDEO GAME INDUSTRY ...... 57
7.1.1 SUMMARY ...... 64
7.2 EXPERIENCE AND GAME DESIGN ...... 66
8 DISCUSSION ...... 68
8.1 TOWARDS ‘EXPERIENCE PARADIGM’...... 70
8.2 FUTURE STUDY – ‘VIDEO GAMES AS EXPERIENCE’ ...... 71
8.3 CRITIQUE AND LIMITATIONS ...... 72
9 CONCLUSIONS ...... 74
2 ABBREVIATIONS AND TERMS
CEO Chief Executive Officer CMM Capability Maturity Model Crunch time Period of intensive working in an attempt to meet a deadline. DLC Downloadable Content ESA Entertainment Software Association Feature creep Increased features during development of video games. FFF Friends, Fools and Family GDD Game Design Document GM Gold Master, a publishable version of the game Gold plating Unnecessary focus on implementing a single art piece or feature during development. GUI Graphical User Interface IPR Intellectual Property Rights MMOG Massively Multiplayer Online Game QA Quality Assurance SE Software Engineering SME Small and Medium sized Enterprise SOCES Software Development in Creative Ecosystems UX User Experience
3 1 INTRODUCTION
The growth of the video game industry has alerted a wide range of disciplines to study its features and effects on society. Software engineering has traditionally viewed video games as software with wide range of graphic and audio assets, thus employing the same methods of traditional software engineering.
The aim of the study was to form a view of video game development in the industry, describe the development processes of selected organizations, evaluate the study with software engineering literature and discuss the relevance of ISO/IEC 29110 -standard based on the study. Seven SME companies from South-East Finland were interviewed in four rounds including game designers, testers, programmers, artists and upper management. Grounded theory was used to analyze the qualitative data in iterative manner.
This study is part of SOCES (Software Development in Creative Ecosystems) project in Lappeenranta University of Technology (SOCES, 2012). The project goals are: to help start-ups to understand game development, help existing organizations to improve the quality of their products through process development and to develop a method for assessing the actual game development process used.
The thesis is organized as follows: Chapter two gives an overview of the industry and chapter three of the development of video games. Chapter four is dedicated to a review of software engineering literature on video game development. The research process: method, organizations, and interviews are presented in chapter five. Chapter six summarizes the results and chapter seven explains them by reviewing more linked literature. Chapter eight discusses the results, future study and debates the relevance of the study. Chapter ten concludes the thesis.
4 2 VIDEO GAME INDUSTRY
As a prelude to video game development the second chapter provides an overview of the video game industry. The importance of video games is motivated providing statistics of the industry’s growth. The dynamics of the market and their effect on the development is viewed through value chain and stakeholders. The chapter ends presenting digital distribution and its’ impact on the video game industry.
2.1 Growth
The average gamer is no longer a lone teenage boy. According to ESA (Entertainment Software Association) the average player in the US is 34 years old and 47% of them are female. In fact, among players there are almost double the amount women over 18 (30%), than boys under 17 (18%). Today video games are being played in 67% of the US households (ESRB, 2012).
The ESA reports reveal the steady growth of video game industry during the 21st century. In the US from 2005 to 2009 the entertainment software industry has been growing over 10% a year (compare U.S. economy: <2%). During that time the direct employment for the industry grew 8.6%. Currently in 2011 the computer and video game companies employ more than 120 000 people in the US. In 2011 the industry reached up to $24.75 billion in sales (ESA, 2012). Expectations for 2016 reach $83 billion with a 7.2% annual growth rate (PWC, 2012).
In Finland the growth has been even more remarkable. From only 15 game companies in 2000 the industry has grown to employ 1500 persons in over 100 companies, with 370 million euro turnover in 2011 (NEOGAMES, 2010). Due to the recent success of Rovio and Angry Birds the industry has reached hyper-growth rate of 22% during 2004-2011. It is worth noting, that the turnover and number of employees grew at an equal rate also before 2010 (NEOGAMES, 2010).
5 2.2 Value chain
The traditional value chain of video game industry can be seen on Figure 1. Developer creates the game which the publisher finances and promotes. A distributor makes the game available through different retailers. In addition the platform owners, like console manufacturers, receive royalties from the sale of each game (Cadin, 2006).
Developer Publisher Distributor Retailer Consumer
Figure 1: Traditional value chain (NEOGAMES, 2010)
Developer designs and produces the game. Smaller studios are subcontracted by bigger studios and publishers, but some independent game companies develop and publish the games themselves. The publisher finances video game projects for both internal and external IPRs. It is responsible for licensing and has power to influence on the projects outcome (Potanin, 2010). The publishers’ main goal is to take care of their investments. Following the trends of the industry provides information for the publisher. Some international publishers also distribute games for smaller studios. The distributor manages marketing and sales of video games. They package and transport the products and provide user support. Distributor handles relations to retailers and sale channels where consumers can buy the video games. Platform owners, whether console manufacturers or software developers, receive royalties based on the use of their products. Some video game developers are mainly platform developers licensing their technology. They use video games to advertise their engines to other developers. At the end of the chain the players’ responses for video games are notoriously difficult to predict (Tschang, 2005). They are vocal and very critical in public about the video games they play (Gaume, 2005).
2.3 Digital distribution
The traditional value chain is changed with digital distribution. The developers can publish and distribute their own products with little to no costs. As a result the value for original developer can increase up to 70% from the traditional 10% (NEOGAMES, 2010).
6
Game Distribution Developer Consumer Channel (Publisher)
Figure 2 : Value chain with digital distribution (NEOGAMES, 2010)
People still buy games from retail and both publishers and distributors have a role in the new digital distribution based value chain. Publishers market the video games. New digital distribution channels have emerged (Steam, Direct2Drive, GamersGate etc.). They provide a marketplace for the publishers to market, while being easy to access for both developers and customers. The digital distributors charge around 15-30% of the sales from the developer (Conversations outside official recorded interviews with managers of the organizations studied in this thesis). The online sales channels have lowered the barriers of entry to the market.
The digital evolution on the market has not finished. Publishers are unwilling to finance risky projects, especially during the economic crisis (2008- ). Playing safe and funding a sequel of a successful IPR instead of a novel video game is regular. As such, a demand for a new source of funding has emerged. Developers, who turned in only slight profit with their previous projects, now reach over to fans for direct financing from digital aggregators. An example of this is www.kickstarter.com which has founded several projects like Grim Dawn (video game) and Ouya (video game console).
As it is easier and cheaper to get video games published, with the contracts being more preferable than before, the small scale funding schemes - like from friends, fools and family (FFF) - are a valid option for the first projects. The development tools have also matured to a point where they are easy to use and fast in production. With these lowered barriers of entry to the market a notable increase in new entrepreneurs can be seen.
7 3 VIDEO GAME DEVELOPMENT
With an understanding of the environment, the third chapter covers the basics of the game development process. The different tasks and skills needed to complete a project are presented. The traditional divide to pre-production, production and post-production is presented.
“Anyone can come up with that idea; you don’t have to be a genius to do that. The hard part is to create… to refine it and develop it into something that is actually fun to play”, Senior producer, DICE (Hagen, 2010)
3.1 Required skills
Design, graphics, sound, programming, QA, management and business are all needed to carry out a successful video game development project. The tasks, products and job titles on different skills needed in a video game development project can be seen on table 1. The list is not complete and should be viewed keeping in mind the words of the lead designer of Massive Entertainment (Hagen, 2010):
“You need a specific combination of people to be able to make a certain kind of game. If you are going to make a game like Tetris, perhaps you don’t need a dramaturge. You should have someone who loves to play with Rubik’s Cube and can engage with those parts. So it’s very much the composition of the group that defines what kind of game we are working on.”, Lead designer, Massive Entertainment (Hagen, 2010)
8
Tasks Products Titles Design Game design, gameplay, style Vision, GDD, Designer: Lead-, Games-, GUI-, Graphics-; Script writer, Map (sound & art -design), level design Leadership builder, Level Editor, Object planner, Storyboard Artist, Illustrator Help others Graphics Visual art Concept art, 3D models, Artist: Concept-, Environment-, Lead-, Technical- ; Creative animations, textures Manager, Art Director, Animator, 3D Modeler Sound Audible art Sound effects, music, Musician, Audio Engineer, Sound Effects Designer, Composer voice overs Programming Implementation: game features, Code, modules, tools & Programmer: Lead-, AI-, Tools-, Graphics-, Gameplay-, Engine-; tools, maintenance, etc. editors Software Engineer, Action Scripter, Platform Designer, Information Architect, Systems Analyst, Database Designer, Server Architect QA Quality, Testing Test results, test QA Manager, Tester, Lead Tester, Localisation Tester, Localisation systems, test approvals Manager Management Keep things together, Leadership, schedules, Head of Development, Executive Producer, Project Manager, make game development possible reports Producer, Art Director, Account Director, Programming Manager, Production Accountant, Production Scheduler, Production Assistant, Creative Director Business Marketing, PR, human resources, Infrastructure, financing CEO, Publisher, Producer, Project Coordinator, Product / Brand administration, and IT support. Manager, Sales Manager Licensing / IPR Manager Table 1: Skills and respective tasks, products and titles of video game development (Crosby, 2000; Doulin, 2012)
9 Designers are the creators of the vision that will become the game. How it plays out, how it feels, what is the style and theme of the art, etc. This information is generally produced into a game design document (GDD). Game design is very complex activity and in order to be successful, the designer needs to possess a multitude of skills: design, management, scheduling, research, etc. Designers are responsible on providing their game vision to team members during the development so everyone knows what the overall goal of is. Designers often carry the responsibility and power when it comes to gameplay related decisions. From concept art in the early stages of development to 3D modeling and animation in the latter parts - visually talented people create the style, objects, landscapes and characters of the video game. They create the visual representation, the landscape, of the game world together with the designers and programmers. As the graphics are needed to create the visual world, so are sound artists needed to complete the soundscape. Sound effects, music and voice overs create a big part of the atmosphere of a game. To complete the immersion the audible elements need to be coherent with the designed theme.
Programmers are responsible for implementing the game features: controls, artificial intelligence, graphics- and physics-engines, etc. Most often they also create the tools for rest of the team: Level-editors for level designers, asset control for artists, etc. They also maintain the development environment. Programmers need to have good communication skills. They need to communicate with the designers and artists of the technological possibilities and limitations.
Testing is the basic method to assure quality in software products. Quality Assurance (QA) is responsible for planning testing, producing the test environments that provide metrics for project management. Organizational skills, thick hide to endure repetitive work and good communication skills are needed for this task. In order to give relevant feedback a tester needs to be aware of all the aspects of video game development. This is a common entry point to the industry.
Management on a video game development project is often a task between publisher and developer. The publisher, as the financier of the project, is keen on keeping the project in budget and on schedule, but the on-site management is the responsibility of the project manager or producer. The producer can be internal from the developer or an external
10 stakeholder from the publisher. The producer is responsible for directing the team during the development according to the business needs. Excellent communication skills are top priority among project management, scheduling, budgeting and reporting skills. As in any company marketing, public relations, human resources, administration, and IT support need to be taken care off.
Without business no company can achieve profit. Without profit no company can continue to work. Business skills and organizational development are critical like in any other competitive business. The video game industry makes no exception.
3.2 Phases of Production
Pre-production (Gaume, 2005) aims to capture the creative vision of the video game. A small team prototype the most important features into a proof-of-concept. Created storyboards, concept art, prototypes, etc., are gathered into a GDD (Kanode, 2009; Macedo, 2011). Pre-production not only reduces errors in later stages of development (Tschang, 2005), but a great pre-production also reduces the amount of non-functional requirements, like “fun” and “good gameplay”, to be sought in the actual production phase (Kanode, 2009). Financing for the rest of the project depends on the work of pre- production. If funded, the game goes into production. However, even though the GDD is created to capture the vision of the game, it is not created to meet the full needs of production (Callelle, 2005). Enough formality is needed to clearly communicate the design vision, without restricting creativity too much for latter parts of development (Tschang, 2005).
In production the size of the development team (often) grows to produce and test all the art, game mechanics and levels in the game. The technical and software design are produced and more formal working methods are implemented to manage the increased work load. Game features and tools, such as level editors, are programmed. Levels are created and all visual and audio art is produced and put in its place. The projects’ progress is monitored with milestones describing the amount of work done. Testing is performed in- tandem with production. While informal testing goes on ad-hoc; formal testing is done after large portions of content have been produced (levels, scenarios, gameplay features).
11 Alpha-testing is the first test where the game can be run with the most if not all the features in place. Beta-testing is done when the game is close to finished to find the last critical bugs and errors before release. (Tschang, 2005)
After release in post-production the game is supported. Updates providing bug fixes and gameplay enhancements are pushed out. This is as important as in traditional software development. Most of the customers are, for the first time, in contact with the product and problems in post-production might become very expensive for all project participants.
12 4 VIDEO GAMES IN SOFTWARE ENGINEERING
With basic understanding of the video game industry and the development process the chapter four reviews software engineering (SE) literature of video games. The aim of the literature view was to form an understanding on how software engineering views video games and video game development. The literature presented in table 2 was selected from a wider range of SE literature reviewed in a non-systematic way as the study progressed.
Reference Title Size Bethke, 2003 Game development and production Book Flynt, 2004 Software engineering for game developers Book Blow, 2004 Game development harder than you think Article Phelps, 2004 Fun and games Article Callelle, 2005 Requirements engineering and the creative process in the video Article game industry Petrillo, 2008 Houston, we have a problem…: Article A survey of actual problems in computer games development Petrillo, 2009 What went wrong? A survey of problems in game development Article Kanode, 2009 Software engineering challenges in game development Article Lewis, 2011 The whats and whys of games and software engineering Article Koutonen, Agile Methods in Gaming Industry: Thesis 2011 a survey into Finnish game studios Table 2: Software engineering literature on video game development
Bethke (2003) states that ‘too often game developers hold themselves apart from formal software development and production methods with the false rationalization that games are an art, not a science. Game developers need to master their production methods so that they can produce their games in an organized, repeatable manner --‘. The book ventures through game development from initial motivation to shipment: tasks, project management and development. He covers the importance of planning and documentation, profitability of video games, overlong projects, feature creep, gold plating, tension between pre-production and production, industry powers of console developers and the changing
13 technology. Like in traditional software, he sees detailed design and documentation with strict management and focus the basis of successful game development.
In a bible of game development, Flynt (2004) goes through his tool box for game development by reviewing a video game demo project: ‘The development process that this book documents started from a set of requirements. It guided the team to consistently design and implement a game according to requirements. The team stayed within budget and delivered on time.’ The book describes the creation of a game design document (GDD), deriving software requirements of it and the development methods. The development organization is analyzed with CMM (Capability Maturity Model). Contrary to Bethkes approach Flynt sees game development encompassing its own culture that consists of much more than just software with the efforts of highly skilled creative individuals with their wide array of work: design, graphics, music and writing. He recommends that developers ‘carefully gather and analyze the requirements for the software system they have been asked to build. -- (and) create a software design that thoroughly addresses the requirements.’ Developers are also instructed to ‘test the system -- to ensure that its design and implementation exactly express the requirements.’ This way designers and developers should establish practices and processes for good co-operation to develop without redundancy and rework. He emphasizes (p.13) to ‘distinguish game creative design and game software design’ and goes to great lengths in describing this process of deriving the software design from the creative design. This way he excludes the game design from much of his theory of development and focuses on the software development methods.
In the same year, the game engine development was studied by Blow (2004). He states that due to rapidly increasing size of projects, the code optimization has been replaced with efforts to get the code to work while bearing some resemblance to the design. The highly domain specific requirements render ‘Games among the most complicated kinds of software we should expect to see’. The development tools are not designed for games and the short five year life-cycle of consoles limits the timeframe for emerging new tools. The multiplatform development causes issues leading to bottlenecks in the production and the engine code requires advanced knowledge together with high quality and performance standards. Software engineering can be useful in engine development, along with
14 mathematical and algorithmic knowledge. However the knowledge of harmoniously combining different algorithms is not available. On top the players have grown more interested in other aspects of the games introducing physics and artificial intelligence resulting in time evolving complex systems. As a conclusion Blow states that ‘Computer games have always evolved toward increased technical complexity to give the players things they have never experienced before. As a result, each wave of games is attempting several technical feats that are mysterious and unproven. Phelps, et.al. (2004) add to the engine development knowledge, by studying multi-language development. They see it bringing much needed modularity and specific functionality, but documentation, memory management, threading and performance to be problematic.
Callelle et.al. (2005) take a wider look at video game development in viewing video game as a ‘special type of multimedia application – an entertainment product that requires active participation by the user’. The ‘multidisciplinary team’ developing the games struggle with the ‘non-functional requirements’ like entertaining, fun and absorbing as they are not understood by requirements engineering perspective. This projects a communication issue between the game designers and software engineers with the lack of common language. They analyzed game development experiences called postmortems for factors of success and failure. They suggest that failures trace back to the transition from pre- to post-production: ‘1) how to transform documentation from its preproduction form to a form that can be used as a basis for production, 2) how to identify implied information in preproduction documents, and 3) how to apply domain knowledge without hindering the creative process.’ They see experience a key factor in identifying issues at each level. They conclude that ‘the software engineering process in video game development is not clearly understood, hindering the development of reliable practices and processes for this field’. Drawing attention first time to game development being something else than just software development and that the uniqueness might require specific methods. The traditional requirements engineering techniques need to be extended to ‘support the creative process in video game development’.
Analyzing the same postmortems Petrillo et.al. (2008 & 2009) start by noting that after 40 years of computational systems study the software projects still suffer from schedule, budget, quality and management/business related problems implying that the situation in
15 software development is far from ideal. By reviewing literature they extract schedule, quality, design iteration problems. Poor methodologies leading to exceeded time and budget constraints and the search for ‘fun’ and ‘core game identity’ leading to agonizing project moments. They categorize the problems to scope (feature creep), schedule (multidisciplinarity generating delays, poor estimates), crunch time (excessive work) and technological (new platforms). On their own study they found unreal or ambitious scope and feature creep most referred (75%). Cutting features (70%), design problems (65%), delay or optimistic schedule (65%), technological problems (60%) were the next highest in frequency. Problems were also raised in crunch time, lack of documentation, communication problems, tools problems, test problems, team building problems, great number of defects, loss of professionals and over budget. They conclude that ‘all the main problems of the traditional software industry is also found in the electronic games industry’. Technology is seen less a problem than the actual management. A difference is found in communication problems within a team: ‘In the traditional software engineering, the team is usually relatively homogenous, basically formed by technicians with skills on computer science. However, in the electronic games industry a multidisciplinary team includes people with distinct profiles --’. Highlight is drawn to Callelles results of requirement elaboration being much more complex due to methods to determine subjective elements as ‘fun’ do not exist. A slight conflict can be found between the 2008 and 2009 papers: in 2008 they state the similarity gives way to implement successful software engineering practices to remedy the problems in game development, while in 2009 this statement is non-existant, but a notion of Callelle is found ‘necessity to extend the traditional techniques of requirement engineering to support the creative process in the development of electronic games’.
Kanode and Haddad (2009) propose the game industry to evolve the current SE methods to their own needs as many of the issues of game industry have already been solved in the software industry. Video games are described as robust and unique: flow, entertainment, multiple disciplines, engaging game play, high consumer expectations, and complexity. Instead of waterfall, games are created in iterations and increments. Prototyping is often used to find the elusive ‘fun’ requirement. The aim is set for ‘rigorous yet flexible application of proven SE processes and practices’. The previous literature is reviewed stating the poor methodology of software development in the industry. They continue
16 accepting prototyping and iterations as inescapable in video game development, but try to limit them to before production. Requirement engineering should be used after the pre- production to gather all the needed requirements to mitigate feature creep. By a successful pre-production an exciting and absorbing game could be created. A pipeline for the diverse assets and new tools to counter the increasing complexity are recommended. The article also mentions project scope (feature creep), publishing (contracting), project management (interdisciplinary, communication), development (agile, GDD, iterations, increments, prototypes) and emphasizes pre-production: ‘The main challenge in the development is the translation of preproduction work to the production phase’. Overall the article views more uniqueness in video game development (iteration), proposing a selection of methods (agility) for the development to help control the issues (feature creep) becoming a problem.
‘The intersection of video games and software engineering is not yet well understood’ (Lewis, 2011). To bridge the gap between software engineering and game development Lewis and Whitehead (2011) cover four aspects: ‘development, design, middleware supporting the creative process and testing’. They try to prove that SE can learn from game development. In game development a project pipeline creation for a strict budget is difficult due to multifunctionality and tight coupling resulting in under-utilization of work force. Larger teams also face management problems from the lack of documentation preventing information diffusion. Agile development methods of SE have helped and by understanding how game development teams tackle these problems design and functionality could be integrated better into SE. Tools have also gotten better for game development. The Blows’ statement for the lack of specialized tools is not valid anymore. As game development is pushing the tools technology onward many of the new tools could be analyzed from SE point of view. In design the game world has difficulties in finding a common language. Design patterns are recommended and formal models could be used to verify properties without creating a prototype. However as games suffer from state space explosion new ways of formal modeling are needed. Creativity support is recommended for the designers as it is hard for human to maintain the whole mental model of the game. The active use of developers computing cycles could help advancing SE. To meet the technical challenges, such as in game engines, a new middleware industry has grown to meet the demand. However many of these products still require extensive integration to be used in game development. In testing games represent emergent software where output is
17 unpredictable. Especially getting metrics from ‘how many players finish the game in less than 5 minutes?’ are outside the current SE knowledge. They end stating that the purely subjective requirement of ‘fun’ is what separates games from traditional software. ‘Fun must pervade the product and be supported by and validated at each stage of the development process.’ (Luton, 2012) Constant experimentation is deemed critical for the success of game projects, and even though fun might not be a core feature of traditional software - it certainly increases its value.
As the last piece of analyzed literature from game development in SE, Koutonen (2011) brings us very close to the topic of this thesis. The aim of Koutonen was to research the use of agile methodologies in Finnish game studios. Video games’ nature as an entertainment product and the problems in its development can be traced back to the seamless integration of work from the multidisciplinary team to produce a player experience. The industry also has unique features that arise from the publisher-developer-consumer interaction. He reviewed the main agile development methods and two specifically adjusted for game development. One method is tailored to suite every phase of production and in the other the game concept is prototyped and then produced with a SCRUM-based development. For the study 20 Finnish SME (Small and Medium sized Enterprise) game studios were interviewed. Development processes mainly followed the models found in the literature, though differences were found: prototype was not always developed in the concept phase nor verified with a publisher, the game mechanics and design might be changed in the production and asset production, game design and mechanics can be subject to alteration even in post-production. Overall agile methods (SCRUM most popular) were widely used and provide mainly a positive impact. The methods were used despite the size of team or production.
4.1 A gap of knowledge
Traditional methods - focus on planning, documentation, etc. - have been proposed multitude of times to the myriad problems experienced by the video game developers (Bethke, 2004; Flynt, 2004). The aim has been to provide the young video game industry guidance from the matured software development industry to help reduce uncertainty by
18 providing processes, methods and tools to reduce iteration during development. However, there are problems in implementing these SE methods to the video game development.
The transition from design to production with video games, unlike with traditional software, exhibits many non-functional requirements to which the literature does not provide a coherent solution (Callelle, 2005; Kanode, 2009). The increasing complexity of game engines, pushing towards the novelty requirements of the market, make video games among the most complex pieces of software even without the non-functional requirements issues (Blow, 2004; Phelps, 2004).
A lot of the problems faced in video game development have been matched with software development (Petrillo, 2008 & 2009). However, with a focus on the resembling parts the differences and their implications have been neglected. Thus, the course of SE does not seem to align with that of the video game industry, calling for tools and methods tailored for video game development (Kanode, 2009). This seems to have come true with the agile SE methods been widely adopted, but modified to the video game industry’s needs (Koutonen, 2011). The cause for this partial fit remains unexplained: the specific need of creativity and its roots in video game development is not thoroughly understood continuing to present problems (Lewis, 2011).
The described deviation of game development to its own unique branch from software engineering can be viewed over the reviewed literature. The early research is hard SE paradigm denying the special features of the industry, products and development. The issue of non-functional requirements and design iteration is either circled around or ignored. Coming to the 21st century, more of the uniqueness of video games is noted. Mainly Callelle et.al open the way for the future study and is referred in nearly all pieces after. The last pieces of reviewed literature accept game development separate from software engineering and acknowledge the gap of knowledge that needs to be filled. The traditional SE methods are used as a basis, but it is also questioned if game development could have something unique to teach the SE paradigm.
The study presented in this thesis observes the current views and practices in the industry with an aim to form a view of the actual development processes in place. If the gap present
19 in the SE literature emerges during the analysis the reasons need to be explored. The understanding and reasoning can lead to new knowledge to better understand video game development from SE point of view, to bridge the gap.
20 5 RESEARCH PROCESS
Chapter five presents the research process of the study. Section 5.1 goes through the method of research, the grounded theory: the features differentiating it and strategies of data analysis. The latter part of the chapter presents the organizations (5.2) and interviews (5.3). The selection of grounded theory as the method of study for this thesis is justified at the end of the chapter (5.4).
5.1 Grounded theory
Grounded theory is a qualitative research method applied first in social sciences and later in organizational studies of different research disciples. A grounded theory, based on the work of Glaser and Strauss (1967), is “a number of conceptual categories organized in terms of relationship. It is an inductive generation of theory from data that has been systematically obtained and analyzed.” In traditional hypo-deductive research the study begins with theory, definition of concepts, proposed relations, progressing to the observations and tests. In grounded theory this is reversed: direct empirical observations precede the definition of concepts and theory (Locke, 2001). The key reason for this is to allow the researcher an open mind to let concepts and theory emerge from the data. The main features of grounded theory are late literature review, sensitivity during analysis, iterative process, plausibility of findings and writing of memos.
Late literature review: Any preconceived theoretical ideas are seen detrimental; limiting the emergence, especially during early stages of research. This allows grounded theory researcher to invent through their conceptualization, bringing focus into patterning of the concepts (Locke, 2001). As such grounded theory ‘allows for the emergence of original and rich findings that are very closely tied to data’ (Orlikowski 1993).
Analysis & Sensitivity: All significant theorizing is strongly based on the researchers own insights during the study (Locke, 2001). The researcher is an analyst being immersed in the data, generalizing interpretations while being theoretically sensitive. Theoretically sensitive means being open to new possibilities and other theories about the data cultivating the results (Locke, 2001).
21
Iteration: There is a ‘continuous interplay between data collection and analysis’ (Urquhart, Lehmann, Myers, 2010). By creating concepts and rechecking data to validate them makes grounded theory useful in developing ‘context-based, process-oriented descriptions and explanations of organizational phenomena’.
Plausibility: The results from grounded theory become generally applicable through the number of empirical observations tied to each category (Urquhart, Lehmann, Myers, 2010). ‘A conceptual category has analytic generalizability when it can plausibly account for a large number and range of empirical observations.’ (Glaser & Strauss, 1967) Through the iteration and number of occurrences the researcher meet confidence can be gained for the results.
Memos: The traditional scientific reliability rests on the repeatability of the study and results. In grounded theory, as a qualitative study, the same set of data can be used to deduct several results (Glaser & Strauss, 1967). With much of the analysis focusing on the researcher instead of tangible methods, writing memos is seen important in describing the actual research as it happened.
A theory from the use of grounded theory can be evaluated by its fit, understanding, generality and control (Strauss & Corbin, 1990). Fit entails that the theory fits the substantive data. Understanding entails that the theory be comprehensible to all involved in the area of study. Generality entails that the theory is applicable in a variety of contexts. Control implies that the theory should provide control with regard to action toward the phenomenon.
5.1.1 Data analysis
The goal of the grounded theory’s data analysis is to: 1) group incidents and name them, 2) compare categories, 3) integrate categories, 4) establish core categories, 5) reach theoretical saturation and 6) motivate a theory with memos. For these steps coding provides the necessary steps.
22 Coding is the act of ‘analyzing data to derive concepts, developing the properties and dimensions of the created concepts to create categories’. (Corbin & Strauss, 2008) There are a multitude of data analysis techniques (analytic tools), that support codifying the data, but in the end every researcher has his/her own repertoire of strategies.
Strauss and Corbin (Strauss & Corbin, 1990) introduced the three levels of conceptualization. Clarification of process is achieved by distinguishing three stages of naming and comparing activity.
1. open coding – find categories 2. axial coding – interconnect categories to a framework 3. selective coding – establish core category or categories
The open and axial coding are done concurrently in practice up to a point where Glaser (1998) argues that open and selective coding are sufficient for clarification.
The researcher analyses the data for concepts in iterative manner. Every concept is rechecked from data; properties are added or removed accordingly. Concepts are formed into categories and their properties are described. The categories are compared and integrated to provide a broader picture of ‘What is going on?’. A core category is formed and connected to other categories to provide a framework describing the process. A theoretical saturation is reached when a category does not change with new occurrences. A theory can be produced, grounded in the empirical data and motivated with memos of the actual research process. (Locke, 2001) ‘A fully integrated grounded theory is a high-level conceptual framework that possesses explanatory power supported by advanced analytical processes’. (Birks & Mills, 2011)
The very base of analysis is questioning. It is used for all kinds of analysis – not only grounded theorists. The range and types of questions does not limit to these. The questions asked will change over the course of a research project as the insight matures and theory thickens. Below is a table of different types of questioning: sensitizing, theoretical, practical and guiding.
23 Type Aim Questions Sensitizing Tune researcher to what data What is going on here? Who are might be indicating involved? How do they define the situation? Theoretical Help researcher to see process, What would happen if…? variation, to make connections How does this change over time? Practical Provide direction and What concepts have been developed? theoretical sampling for the How to gather data? structure of theory How, where, whom to question? Guiding Guide our interviews, Interview questions. observations, documentation and analysis Table 3: Types of questions (Corbin & Strauss, 2008)
Comparative analysis is another stable data analysis method. Two methods, constant and theoretical, provide excellent basis for coding. Constant comparison is used to classify data comparing incident with incident to find similarities and differences (Strauss & Corbin 1960). This is the basis that lets a grounded theory researcher differentiate categories from the data and evaluating them in regards of their properties.
When confused or stuck with data that seems conflicting with the rest of the ‘story’ theoretical comparison can be used to think about an event or object in different ways. Drawing upon something that is known for the researcher or literature, we establish a new meaning in which data has relevance with. (Corbin & Strauss, 2008)
5.2 Organizations
Seven video game development organizations from south-east Finland were interviewed in five rounds including designers, developers, artists and chief executive officers (CEOs). The data was analyzed into categories deriving implications from the qualitative data based on grounded theory presented in the previous chapter.
24 The organizations were identified as small and medium sized (Table 4). Only one of the organizations was working on large productions with a medium sized organization. Four of the organizations develop video games for mobile devices and three for personal computers (PC), of which two also developed for gaming consoles (Table 5).
Organization/production size category Number of employees Small 1-9 Medium 10-50 Large 50+ Table 4: Organization definition by size
ID Organization Production Platforms Future platforms A Small Medium Android, iOS WP7, PC B Small Small Android, iOS C Medium Large PC, consoles Depending on the market D Medium Medium PC, consoles E Small Small Android Other mobile F Medium Medium PC Mobile G Small Small Web-browsers Mobile (embedded web) Table 5: Organization units and their categorization
As the size of the organization is not equal to size of their productions the latter is used as a main classifying variable. A, B, E, F and G are start-up companies founded within a year and working on their first or second production. Only C and D had longer production history. However the C and D were working with different genres within the same company. None of the start-ups had had a major breakthrough in the industry, but few had gained a noted foothold on the market despite their short history. B and G had background in a software engineering company either through previous work history and/or company ties. E and F had background in video game development education as students and teachers. Organization A was a spinoff of the same company which C and D both are parts of. The difference of organization and production size comes from outsourcing of
25 production. This enables the organizations to engage on larger productions than their own size would otherwise allow.
5.3 Interviews
Four rounds of interviews were performed on the previously presented organizations. The themes of the interviews were on round 1: general project information, 2: implementation, testing and development tools, 3: innovation and marketing and 4: game design and creative aspects of the work. The themes, interviewee’s and their roles in the organizations are collected in table 6.
Round Theme Role 1 General information about projects Project manager / team lead 2 Implementation, testing and tester / programmer with testing development tools responsibilities 3 Innovation, marketing Upper management / owner 4 Game design, creative aspects Game designer Table 6: Themes and roles of interviews
Of the interviews E:R3 & C:R4 are interviews of the same person due to change of employment from one company to another. This highlights the close ties the companies have with each other in the video game industry. Some of the interviews within an organization are by the same person, but this does not have implicit effect on the results of this study. From G only three interviews were provided (R1, R3, R4).
5.4 Justifications for Choosing Grounded Theory
Grounded theory is a valid method of study due to its suitability to observe and explore organizations and phenomena. (Seaman, 1999) Locke (2001) reviews the justification for using grounded theory on organizations and management instead of just social situations. All these features can be mapped to concern this thesis focus on video game development.
26 “Capturing complexity: The grounded theory adapts well to capturing complexities of the context in which action unfolds, enabling researchers to better understand all that may be involved in a particular substantive issue.” (Locke, 2001, p. 95)
As detailed in previous chapters the video game development is very complex with multidisciplinary problems. The study described in this thesis focuses on finding the core of video game development through interviews revealing the daily action taking place.
“Linking well to practice: The concern with substantive issues and the ensuing theoretical accounts that this approach generates, have proved especially useful to help organizational members gain a perspective on their own work situations.” (Locke, 2001, p. 95)
The goals of the SOCES project, the thesis is part of, are very closely linked to practice in order to provide assistance for real life issues of developers. Grounded theory can provide knowledge to understand and solve the development problems in practice.
“Supporting theorizing of ‘new’ substantive areas: The naturalistically oriented data collection methods as well as the approach’s theory- building orientation permit the investigation and theoretical development of new substantive areas as they ‘arrive’ on the organizational scene.” (Locke, 2001, p. 96)
Video game development is a ‘new’ area for many of the disciplines, with a deficit of explaining theories. As such the insight provided by the grounded theory method is invaluable in understanding the whole of the subject studied instead of a detail.
“Enlivening mature theorizing: The grounded theory building approach has been used to bring a new perspective and new theorizing to mature established theoretical areas, enlivening and modifying existing theoretical frameworks.” (Locke, 2001, p. 97)
27 Software engineering is stale in its position towards video games as traditional software. This thesis provides a possibility of new knowledge to enliven the discussion of existing theories and methods concerning video game development.
28 6 RESULTS
Chapter six presents results of the study. The organizations view on video game development through orientation and previous experience is used to motivate the organizational choices. The organization structure and its relevance with the implemented development processes are studied. The subjective observations of positive and negative aspects on the currently employed development methods are listed. Finally, the development process figures are presented and the relevance of the ISO / IEC 29110 - standard evaluated. The chapter ends with a summary of the results.
6.1 Organization
Understanding the basics of industry and development forms a basis for studying an organization engaged with them. As the industry is an environment for the company so is the organization an environment for the process. The orientation, experience and structure were studied to form a view of the organizations and their differences.
6.1.1 Orientation
The organizations view of video games was analyzed through market/artistic orientation, whether they see video games as art and the balance of creative/software work on video game development (Table 7).
All organizations have understanding of video game development as a business. The view of video games and their development as an artistic endeavor is either directly acknowledged or implied by the respondents during the interviews. These implications surfaced on various answers as the conversation flowed. Most think development of video games as creative work where software development is a piece of the work instead of vice versa. Differentiating factor is found on the relation of money making and artistic values. Organizations that have strong or very strong market orientation also see video game development creative or very creative. B, E & G have medium market orientation for lacking future vision of the market and customer focus (signs of autobiographical design (Sengers, 2006)).
29 ID Market orientation Games as art Creative vs. Software A Strong Yes Creative B Medium Implied Software C Very strong Implied Very creative D Strong Yes Mixed E Medium Implied Creative F Strong Implied Creative G Medium Yes Creative Table 7: Views about video games, development and industry
Organizations A & F are similar: they both have strong market orientation and understanding of the business reality of their industry. Both follow the trends and develop games that the customers prefer, but also see past the current market. Their view of video game development as creative where software development is only part of the whole seems to arise from this need for novelty.
“Everything starts from an idea of a fun and profitable game. Then one tries to get a broader scope outside own aspirations. To take account of the business logic from the start: what products are already on the market, what is coming up, and try to aim for something even a little bit different.” A, Designer
Organizations C & D, even though closely tied at corporate level, exhibit differences. C views development as a very creative process while D sets software and creativeness equally strong. C also notes that business is always the goal in what they do while in D money is seen as the limiting factor for creativity. Only B views game development as software development with creativity. Even G, the other company with software engineering background, differs. B’s engineering focus is further highlighted by the lack of market vision.
“It is a cruel fact that what you like is not necessarily what the market buys. You have to pay attention to them (the customers).” A, Designer
30 6.1.2 Experience
The organizations experience was categorized in traditional software and video games (Table 8). Both industry and development experience was analyzed when categorizing the organizations.
ID Software Industry and Video Game Industry and Development Experience Development Experience A - Strong + Hobby B Strong Hobby C - Very Strong D - Very Strong E - Edu + Hobby F - Edu + Medium G Very Strong Board game + Hobby Table 8: Organizational experience
B & G have background in traditional software engineering. Both of them lack experience in video game development and industry. The C & D are experienced with video game industry and development due to longer history of the corporation. They have managed a stable work force which has translated into a valid organizational experience. Being a spinoff from the C & D, organization A exhibits a strong experience in video games. E lacks other than educational and hobby background in video games while F has enhanced their educational experience by recruiting more experienced video game developers. The startup companies A, B, E, F & G all have different experience background. There seems to be no relation with experience and the orientation of the organizations.
6.1.3 Structure
The structure of organization was studied comparing size, decision making, communication and maturity level. This categorization is presented in table 9.
31 ID Decisions done Mode of Level of Type of Level of by Communication Documentation Knowledge Maturity A Lead designer / Informal Light Tacit Medium Collective / Employee B Collective Informal Very light Tacit Low C Management Favors informal Medium Mixed Medium + D Management Informal Medium Mixed Medium + E Collective Informal Medium Mixed Low - F Management Mixed Heavy Mixed High G Collective Informal Very light Tacit Medium (Organized) Table 9: Organization structure
A, B, E & G use collective decision making, while C, D & F have management based decision making. Employees in A have the most power in every day decisions being trusted to take matters into communal discussion if needed. G has their ideation organized into workshops.
Formal communication is exhibited by C (favors informal) and to an extent F (mixed), while rest focus on informal communication. Documentation is mainly used in task management instead of design and reporting (medium). B & G do not use documentation during everyday development (very light), while F focuses on detailed documentation (heavy). Direct informal communication with an emphasis on the use of tacit knowledge with light documentation is favored with an interesting exception: the start-up company F uses rather heavy and detailed documentation, while A & E have shifted away from detailed documentation to lighter due to design iteration problems they have faced.
Overall, the level of maturity varies. A & G (medium) rely on their experience of working together to find a natural way to work. B & E have just starting to form their organizations (low). E has some problems due to the unorganized structure and is trying to correct them (low -). C & D have organized into a more coherent whole (medium +), but both find room to improve. As a difference, F is highly structured and formal, even though the start-up
32 team does not have a long development history. Their decision making is management based and documentation heavy compared to others.
“I do what I'm told eventually. If what I'm told to do cannot be done then I will give that feedback, but mainly I don't really decide any of this.” F, Programmer
The collective decision making, light documentation, informal communication and reliance on tacit knowledge imply agile organizations focused on quick decisions making and collective creativeness.
6.1.4 Self-evaluation
The organizations were asked for positive and negative aspects of their current organization (Table 10). The answers reflect the current state and maturity of their organizations from a subjective perspective.
Most positive comments were given about teams & spirit, know-how & experience, agility (flexibility & fast reactions), while communication and ideas had less frequency. In negative comments there were more variance, but the lack of organization, communication problems and lack of resources were mentioned by several organizations. Both of the two organizations that mentioned communication as a negative aspect of the current way of organization also mentioned it as a positive, stating constant improvement. Ideas were mentioned by B & E which also have the lowest organization levels implying false focus due to inexperience.
Overall small teams, good communication and agile organizations go hand in hand while their lack of organization and resources is found problematic. The open and high trust work culture is cherished, but contradicts the simultaneous need for formality and structure. The current way of organizing was preferred up to a point where in the case of growth, the organizations would recruit a whole new team to work on a separate project to not increase the size of the team.
33 ID Positive Negative A Communication, Un-organized (vs. open work culture) Team spirit, Work culture, Experience, Agile B Good team, Idea rich Small team (lack resources) Know-how, Flexibility (Agile), Long gaming experience C Fast reactions (Agile), Communication Work morale (quality), Communication D Flexibility (Agile), Stabile workforce, Not tight roles yet, Know-how, Strong teams finding balance (structure/methods) E Great team, Communication, “Gunslingers” - Un-organized, Know-how, Idea rich Communication (No office), F Great team, Small team (resources) roles fit, performance G Agile, process know-how, Lack of organization goal orientation Table 10: Subjective evaluation of organization
6.2 Development
A view on the organizations and their differences give ground to analyze the employed development processes. The development method and process steps were analyzed. The organizations also drew a figure of their current development process and described it (Chapter 6.3).
6.2.1 Methods
The development methods of the organizations and subjective opinion on the production can be found on table 10. SCRUM (6/7) was most referred method of development. Many of the organizations implied on modified version or aim to find a balance between book
34 and real-life project approaches. Prototyping in all forms, from pen & paper to toy soldiers and software, are widely used for concept creation.
ID Method Easiest phase in development Hardest phase in development A SCRUM Development/Production UI development, (modified) incomplete design B Prototyping Preliminary evaluation Development C SCRUM Evaluation, Testing Kanban (later) Launch D SCRUM Prototyping - E Tried SCRUM Concept / Prototype Testing, Launching F SCRUM Concept Evaluation and development G Goal oriented, agile, 1st game 1st game SCRUM-like, no data no data experience based Table 11: Development implications
Incremental iterations are used throughout the development. After pre-production the further the project goes the less iteration is allowed to mitigate schedule problems occurring from feature creep and gold plating. Feature creep is a common concept in video game development meaning the adding of features at the later stages of the product increasing complexity and needing extra work for the sake of creating a better game in the form of better non-functional requirements. Gold plating is a concept of unnecessary focus on details for the cost of time and money without added value. The latter is more familiar in traditional software development.
The teams seem to consistently find the early stages of production easiest. Whether idea, concept, or a prototype to pitch, to come up with a ‘cool’ game seems to be easy. However, translating this vision to a finalized product seems hard. The development is riddled with the traditional issues of iteration, scheduling and testing. Only A implies development to be easiest in the production and even it has experienced iteration issues. C & D working in the same company have a separate team working on pre-production and concepts (stage-
35 gate (Cohendet, 2007)). This makes them stand out from the rest of the group as they are focused on production based on a proven concept. This also explains partly why neither state development as a problem as it is their main focus.
The implications on development method are consistent with previous organizational implications: all organizations are typical for agile development. They are small, use frequent and direct communication and solve their issues on ad-hoc basis. Documentation is overridden by the need for speed of creating new versions to verify the non-functional requirements. However the level and effective utilization of these methods varies in the organizations. The more experienced the organization is, the more matured the development process seems to be. Teams with solid developing experience (software OR game industry), have more matured processes regardless of their organizations age.
6.2.2 Design
Design is a critical part of traditional software development. The traditional literature blames poor design for the iteration issues in game development. To study design the organizations were categorized by aim, focus, document updates and participation in the design process (Table 12).
The aim of design across the organizations is to validate the idea or concept of the game. Documentation is mainly used to point out the main features of the game like genre (shooter, puzzle…), gameplay (goals, challenges…) and style (characters, environment…). Prototyping is widely used to test the functionality for development issues and to find the ‘fun’ in the game. The created designs and prototypes are used in communicating the vision to team members and external stakeholders like publishers. All organizations have dedicated lead designers who are responsible of the decisions, but the process itself is very collective. The team has a big impact on the design and the outcome of the finished game.
36 ID Aim of Focus of Design Updates on Participate on the Design Design Documents design process A Illustrate Updating takes too much Very light Lead, time in a small company. Collective B Validate Main features Very light Collective C Validate Don’t overdo it Average Collective (emphasized) D Validate Agility – “on the fly” Average Collective (emphasized) E Validate Problems, design features, Very light Collective non-functional requirements F Reduce Graphical style Heavy Lead, iteration Collective G Learn Plan is more than vision, Very light Lead, Agility Collective Table 12: Design in the organizations
”-to guarantee, that the recipient understands what the game is. Not explaining too much, just the five things. They have to be good and simple to get the message through. Afterwards, when you start to build the game, then in reality those five things are the only things, that cannot change. In practice everything else around them will change.” C, Project manager
Big differentiating factor is the updating of design documentation. Majority of organizations update the design very lightly during production. C & D (Average) use and update prioritized task lists and SCRUM boards to manage their larger production teams to see the state of the project, but this has little relevance to the update of design documents. However, F (heavy) focuses on accurate documentation and updates throughout the production:
“I dare to say that, regardless of the scale of the game, one of the first stages of design is to produce a proper document of the game concept. In
37 practice, in a certain way, the game concept document is very much the bible of the game production in that all sections of the upcoming production and the game itself have to be written out on paper.” F, Manager
This conflicts with the experiences of other organizations in the study. Updating the documentation and design through development takes too much time to be worth it. Small teams working with small productions keep the production in control with frequent communication and tacit knowledge rather than formal documentation and explicit information. Keeping up with the game is prioritized over keeping the documentation up to date.
”Previously we had accurate designs, but with newer projects -- we have a base of the game: what kind of environment, etc. - not detailed features at that point. Then with the process, we start by adding a feature, testing it if it works...” E, Designer
”We don’t have any technical design document that has software architecture explained in detail.” D, Project manager
”Design is more than a vision for us. We use everything we learn all the time, so we can change the design daily and hourly. We can change direction in a moment, on the fly, which is the basis of our performance.” G, Project manager
6.2.3 Testing
Based on the literature game development suffers from complexity of their products and lack of solid methods to tackle the issues. The organizations’ testing processes were categorized regards to aim, organization, methods and problems they experienced regarding testing (Table 13).
38 ID Aim Organization Methods Problems A Balance, Separate gameplay and Ad-hoc Resources, “fun” functionality tests. quality/quantity B Gameplay “See how it works” Ad-hoc None C Overall Non-functional QA Automate test for ‘fun’? balanced requirements, software, product platform requirements D Software, “Every coder is a tester” QA Time, Balance Estimation E Experience Component identification, Unit-tests, Communication with play testing Ad-hoc play testers F Experience, Separate gameplay and Management Resources Quality functionality tests, control polish at end G Experience, On-going process Ad-hoc, Resources Usability Test-driven Table 13: Testing in the organizations
Some variation was found within the answers which can be explained by the role of the employee: programmers more worried about critical bugs and designers about gameplay. Overall, the balance is even on organization level. Both are seen as an important factor on the player experience.
Methods of delivering the quality vary. Most companies agree testing being an ‘on-going process’ and happening ‘ad-hoc’. The size of the organization does have an impact: C & D have a dedicated QA manager and testing, of which A comments that in bigger organizations even smaller projects have better resources for testing. Most small organizations exhibit lacking test resources of time and work during development. On the other hand, the agility of small organizations offers them a way to perform regardless of the lacking resources.
“We constantly have a clear picture of what is going on - what has been produced on certain days and how our product is coming along. We can
39 follow in real time where we are with the project and quality control comes more or less without thought.” F, Project manager
As such A, B and G rely on their experience to provide the quality during ad-hoc - development and testing. G also uses test-driven development as does E, while C has rejected it due to iteration of features for ‘fun’ causes too much rework on the test batteries.
”Later, when we want to rush a change and it breaks something else, it’s a huge job to browse the code for errors. Unit-tests solve the issue: if something breaks, the unit test automatically points you to the right direction.” E, Programmer
“We tried test driven development, but concluded that you miss way too easily with the first guess of ‘a fun feature’. Rebuilding huge test batteries for every feature slows down the iteration immensely.” C, Project management
The organizations frequently used outside gameplay testers. However, there were problems regarding the feedback. On some cases the testers did not fall into the target group of the game and on other communicating the aims of the testing proved hard. Testers focused on the broken aspects of the un-finished game rather than what the developers asked for. It seems that handing over a game far from completion and existing mainly in the collective development team vision reduces the quality of feedback from the testers.
Overall the main focus regarding testing is to provide sufficient quality on all parts of the game. As the game comes together one shortcoming can dwindle down a lot of good done elsewhere. As iteration is already abundant, any coming out from lack of quality is seen in vain.
”Quality is the key to speed. It is the only way to do something fast at all. Speed is the result when things have been done with quality.” G, Management
40
“We do not release shit.” C, Management
6.2.4 Outsourcing
All of the organizations used outsourcing in their current and past development projects, enabling them to engage in larger productions than their size would otherwise allow. Audio (sound/music) was the most common asset to be bought outside, graphics coming second. A lot of development tools in the form of programming libraries of physics etc. were also purchased. The biggest benefit of outsourcing was the full utilization of employees. In a video game production a lot of the development tasks are interconnected. Instead of a musician also doing coding, testing or graphics, the talent can be bought outside. This also highlights the utilization of multitalented people in game development. Especially in small organizations you need to be willing and able to work on many areas of the video game.
Important aspect about the outsourced material is that anything that is not fully designed is not outsourced. If something comes back that does not fit the design it is resent back and requested a new. Graphical assets are a prime example: the feel and look are delivered in the form of concept art and an order for ‘same like’ assets is given. In this process the knowledge about the sub-contractor is crucial: what kind of style, quality and quantity they have previously provided. A huge amount of resources and work have to be put into networking to find the right companions in game business.
6.2.5 Self-evaluation
The organizations were asked for positive and negative aspects of their current production process and any problems they face. These are categorized in table 14.
41 ID Positive Negative Problems A Agility even in Bottleneck with graphics Work distribution to later stages (work) coders, Lack of design B Agility Learning (new Soloing with tight platform/tools) schedules C Development, Management / In a tight spot methods and concept Communication processes abandoned creation/ideas D Fast prototypes, Management / Decreasing testing Agility through Communication standards with closing SCRUM-sprints deadline E Good testing Time/Resources Design iteration, SCRUM implementation F Fast prototypes No time to design Scale of production (programming), (ambition) No testing in-house. G Experience Resources Experience Table 14: Subjective evaluation of development
Agility in prototypes and overall production is mentioned most often as a positive. G’s experience falls into this as well as they work in iterative ‘on-the-go’ -manner. C mentions the development overall to be on the positive side together with their concept/pre- production team. E is the only one that brings testing up. On the negative side the lack of resources is the most dominant. Whether graphics production or lack of testing resources a lot of the work is left undone and bootstrapped. B had noticed a negative in the time needed to learn new platforms and tools during their first productions. C & D mostly suffer from management and communication issues. This is clear indicator of their size discrepancy compared to the other organizations. F sees a problem in not having enough time to design as well as they would like. Especially the design that goes to programmers is seen lacking. E has a major issue in development. Their team is small and focused on informal organization. However their lack of office diminishes the positives of
42 communication. They suffer from unorganized development, but are unable to implement SCRUM, unlike any other organization.
The pressure of tight schedules and lack of resources is seen in the answers of B, C and D becoming the main reason for problems. Design is the second with lack of design and design iteration related problems. G is an interesting difference with no direct indication of specific problems on development. However their lack of formal structure with heavy reliance on experience and tacit knowledge makes them vulnerable to loss of key persons. It might also prove hard to recruit to such a high level organization: the high programming talent needed to be able to work and communicate consistently with the existing team narrows down the possible work force. In F fitting the minimal resources of a start-up with the scale of production they have chosen proves difficult. Programmers struggle to provide management the features on the demos they request and until one of the demos hit through to a publisher, providing extra financing, they are stuck.
6.3 DEVELOPMENT PROCESS FIGURES
The organizations were asked to draw a presentation of their actual development process and explain it in their own words. The processes are presented on figures 3-10.
Pre- Testing / Aftercare / Sequels / Design Production production Polishing Updates DLC
Figure 3: Development Process, A
“Everything starts from design. Pre-production is used to test things for the first time. Production. Near the end things get overlapped as testing starts very early. Testing/Polishing means integration (App Store, etc.). Aftercare/Updates for bugs and if we want to update the game. Then as an additional phase if we make new chapters or downloadable content, they are done as separate mini-projects.” A, Designer
43 This follows the traditional video game development cycle presented in 3.2. Notable is the addition of separate design phase before pre-production emphasizing the early development. The process also takes into consideration the possible sequels or downloadable content (DLC). Even though the figure is graphically similar to sequential development methods like waterfall, the production itself includes iteration in the production:
“We decide to make feature A and it’s done. Then we see how it works, and if it does not, we keep iterating it until it works or we decide it’s a bad feature and change or discard it. – there is abundance of rethinking and redoing things inside the production-box.” A, Designer
44
Game ideation (Brainstorming)
Prototype / Proof of Concept
Development *Iteration *Agile
Feedback
Testing
Publishing
Updates, Bug fixes, Additional content
Figure 4: Development Process, B
45 “We start from ideation, throwing ideas what could be the game we will do. Just a rough outline. A small document with key-points--. Then we start prototyping how it works in practice and if it looks good, then we start developing it for real. Pretty agile methods, but with a small team we can test things on the fly. Features come and go, what we can’t do, and more come again. Someone could be terrified how indefinite and informal it goes, but we’ve found that it works. Then we have outsourced playtesting from which we collect feedback to development. Then publish, updates, bug-fixes, additional content, etc.” Designer, B
Again, one can map the traditional pre-production, production and post-production on the process figure. The fast progression from idea to prototyping is notable. Only key ideas are thought of before starting developing the prototype for testing the validity of design. When the main points have been validated the production starts and is again full of iteration with features being cut and added. As is with organization A, organization B also note the post- production with possible additional content.
Sales / pitching Demo, Proto / Pre- Design / ideas Production 1st playable production
Approval processes Alpha Beta GM Release
Figure 5: Development Process, C
“We have had different ways to work with projects. Some progress on their own if everything goes well, but in some projects we have spent a lot of time on pre- or post-production. First comes design ideas that are worked into first playable. Between this comes the sale/pitch of the project. Then a demo in pre-production, and if approved we progress to production. Then comes the milestones alpha, beta, GM. Then there is a platform dependent approval process for consoles and stores. Of course
46 there is iteration inside alpha and beta, but this is very much simplified.” C, Producer
The above process figure of organization C incorporates the business side of the development project with several gate-keepers. Again, there is a separate idea/demo phase which products are evaluated and actually sold to outside publisher, before the game even enters pre-production. Some productions can be made in-house if needed resources are available and the project is deemed profitable. The iteration is specified to cover gameplay features (like melee-combat), which are distinct from transitions inside the game from one part to another which are not changed anymore in production. The iterations of aforementioned melee-combat can as an example last throughout the production finishing only near GM (Gold Master).
CMO CEO CUO
Producer Producer
Tech Lead Art Lead Technical Lead Art Lead
Figure 6: Development Process, D
“I’ll try to explain this from organization perspective. Top level, firm, thinks strategies in long scale: what to focus on and what to do. Then with that knowledge producers are responsible for the success and finish of individual projects. -- key persons are tech and art leads who are seniors and have the experience to dismantle a project to pieces. Then we employ SCRUM. Game project starts from concept and design, which are prototyped. Then in, for example, two weeks we try to sprint the proto with minimal features and check the game for new things that we do not know how to implement and how it works. If it works we send it to demo, where we try to implement most of the functionality and gameplay like controls, movement, animations, etc (just with less content than in the real game). Then after two weeks we review each team, learn from the mistakes and go again.” Producer, D
47
The figure takes a different aspect, but the traditional game development phases can be derived from the description. Notable is the clear divide of business, project and implementation responsibilities in the organization and the focus on constant improvement. The whole organization runs in iterative SCRUM cycles and within each cycle there can be iteration.
No Yes
Works
Idea Implemen- Testing Next processing tation
feature
New idea
Figure 7: Development Process, E
“At start we have ideation-process, where the whole team is present. We think about the features to implement. We make somekind of scrap and check if it works or not. If not it goes back to the ideation where we rethink it until it works and we can move to next feature.” E, Designer
Instead of the traditional phases of development, organization E seems to have a single process encompassing the whole production. Either the figure is from implementation level or then the organization has no project level coordination. There are no pre-production or concept phases, which lead to constant idea processing, instead of implementation iteration.
48
Tool selection Demo Development
Design IDEA Evaluatio Document / n
Planning Testing
Publisher
Launch
Figure 8: Development Process, F
“First we have an idea, from which we create a design-document, or prototype, or both - It depends. Then we evaluate if it is good to make a demo. We also design before and after the demo. For the development of the demo we need to select tools, engine (2D/3D?), etc. If the demo is good we can start to develop it. Design/Planning goes with development all the time. When development has been done we test. Depending on the results we continue developing or pass the game to publisher (if present in the project). Then with publisher feedback we design, develop and test more and publish when approved.” F, Art Director
Even though the organization F is the most structured, the described process figure entails a lot of iteration. The traditional game production phases can be found, but post-production is neglected. This might be because the organization has not published a game and is working on their first title. Different from previous figures tools and technology selection for the development process is also taken into consideration.
49
DESIGN START FURTHER IMPLEMENTING
ROUGH IDEA PLAN TEST WHAT HAS BEEN DECIDE DONE CHANGES
FEEDBACK
Figure 9: Development Process, G
“Basic idea is that we do things, see how they work and if needed, go back and change them. Our system, at the moment, is pretty informal, but we are moving towards SCRUM. When we have an idea we create a prototype. Thinking and testing, if it works as intended, and making changes as needed with the feedback we receive. -- I am mixing design and implementation, cause I do both, and I could not get it drawn out right. In principle you always have to think how designed features affect implementation and test at the same time if the game works technically and as a game.” Designer/Developer, G
Again with no published games for organization G, the post-production is not visible on the figure. The pre-production can be mapped to ‘idea-rough plan’ transition while the loop itself is the production phase. Iteration is obvious.
50 Overall, all the process figures reflect the traditional production phases of video games pre- production, production, post-production, with some notable differences. The organizations that had not yet published a game neglected the post-production routines on their processes. Some organizations have a separate ideation/concept phase before the actual pre-production. The more experienced developers had more matured models encompassing business aspects also in their development processes. When comparing with the rest of the results few points of interest rise up. F, most structured organization of all, does not exhibit same strictness in regards of their development process. It showcases the same iterative and concurrent development as others. E having issues in SCRUM implementation does not have pre-production or post-production activities in their process. Whether this is accumulative or ‘cause-effect’ needs further study, but the iteration issues they are experiencing might be partly due to this lack of basic processes.
51 6.4 ISO/IEC 29110
The organizations were asked for their views on ISO/IEC 29110 software development standard for small organizations (Figure 10) and how they see it fits their production processes and video game development overall. The pros, cons and requested changes are listed in table 15.
The standard is given credit on having all the steps needed in bigger projects. It is seen to provide control and the presentation is clear. This is where the positive aspects about the standard end. Six out of seven organizations state that they do not work like the standard proposes. Only F states that if you use SCRUM you cannot work in a way not to follow the standard. The model is rejected as totally irrelevant or too open.
Video game development process’s features raise in the data: ’ you build a core and build upon it. Learn as you go.’, ‘two week cycles’, ‘full design at start is impossible: plan is never complete’, ‘everything is simultaneous’. The proposed changes come in line with the drawbacks of the ISO/IEC 29110 -model. The phases of the model should follow the process of video game development (chapter 3) if it is to be applied on the industry. As it stands the post-production is totally neglected. Two main features of video game development process are frequented: iteration and simultaneous work. Testing is seen to go on throughout the process. The model is seen to apply if seen in iterations of features. In video game development each feature goes through the iteration of all the phases excluding launch.
52
ISO/IEC 29110 Software Engineering – Lifecycle profiles for Very Small Entities Project management
Project Project Project plan Project assessment planning execution closure and control
Requirement Component Integration Implementation Construction Delievery initiation analysis identification and tests
Software implementation
Figure 10: Diagram of ISO / IEC 29110 -standard
53 ID Positive comments Negative comments Changes A All the same steps Games: you build a Testing throughout. are there. core and build upon it. Iteration. Learn as you go. B All there. For We do things totally Testing throughout. bigger projects. different. Management goes hand in hand with production. C All here. We do same things but Iteration in 2 week cycles. D Provides control. Rigid: “For windows Integration and tests are ongoing. Clear. applications.” Based on the feedback design is Full design at start is iterated and development goes impossible: plan is towards the new goal. never complete In smaller projects few programmers can lead the development. E Ok for big Everything in Post-production. companies. development is Simultaneous. Management ok. simultaneous F Broad – everything No way not to go like Iteration fits. Strong early this with SCRUM design is a must. G Ok. We perform well based - on experience, but it cannot be proven. Table 15: ISO/IEC 29110 -standards evaluation
6.5 Summary
The summary of results on the studied areas is presented in table 16. The features of majority are presented on the first column. There were differences among organizations;
54 the second column presents the minority. The main problems the organizations faced can be found on the rightmost column of the table.
Majority Minority Problems Organizational Small, Medium, structured Resources features unstructured (1.money, 2.time) Knowledge Tacit Explicit Enhancing frequent informal management communication Communication Informal, Documented Work distribution, methods frequent Work space management Development Iterative, Stage-gate NFRs, Process concurrent (Cohendet, 2007) Pressure Testing Ad-hoc Unit-tests, Resources QA (dedicated) (1.time, 2.money) Overall focus Speed, Quality, Matching low resources and Agility Process development explorative development Table 16: Summary of results
The organizations small sizes and informal structures enable them to maximize the benefits of tacit knowledge with their informal and frequent communication. As the only way to validate a game design seems to be trial-and-error through implementation, the creative iteration is embraced and organizations are geared towards it. Instead of heavy documentation and testing procedures that would slow down the iteration cycle, the organizations focus on speed and agility.
‘It is strange how often a killer idea, that everyone thinks is awesome based on the presentation, just does not cut it as a prototype… and there is no way to see it. - - It is also natural for a prototype that the first iteration (obviously) does not score, but something came up and pointed us to the right direction, which we could not have found out without the prototype.’ C, Programmer
55 The pressure from combining tight schedules and lack of resources causes problems in the management of the video game development. The used methods and processes are easily discarded during ‘crunch time’ when the developers are in a hurry to reach a milestone within a deadline. Combined with the constant iteration the quality of the work suffers. Most notably testing dissolves into an ad-hoc process. Only few organizations have dedicated resources for testing ensuring their production quality. These organizations have also implemented a special concept phase before actual pre-production (‘stage gate’, Cohendet, 2007). Outsourcing asset production helps reduce the workload of development team focusing on the creative part of the game production.
The ISO/IEC 29110 -standard is based on traditional software development. The data implies that video game development differs from this traditional view of software development. As such the models relevance seems to be questionable regarding video game development. A model should be created from video game point of view including the phases of production (chapter 3) and the constant iteration and testing.
The results imply that the development of video games differs from traditional software. Instead of trying to reduce the iteration, video game developers try to enhance it to better validate the NFRs of the video game design. The game design issues cannot be solved before implementation of software thus rendering software engineering methods inefficient.
56 7 COMPARISON TO LITERATURE
This chapter provides a summary of an expanded literature review that was conducted to further explain the results of the study. The literature was sorted into two categories dealing with the main features SE-literature did not explain: 7.1 explores creativity in the video game industry and 7.2 the experience aspect of video games. The review is presented in chronological order (not in the order of analysis) for clarity of presentation.
7.1 Creativity in the video game industry
The search for answers initiated from the results of the study software engineering did not explain: creativity in game development and need for novelty as its trigger. The categorized literature can be viewed in table 17. The summary and impact the reviewed literature has on the study of this thesis is presented in 7.1.1.
Aoyama and Hiro (2003) present a different view from the one by SE-literature. They describe video games a ‘contemporary art form’ that ‘occupy an important position in the already fledging creative industries in advanced economies’. Yet, at the time little was known about the industry’s evolution, dynamics or role of ‘creative resources in innovation’. The study reviews and reasons the video game industry’s early stages and the details of Japanese industry providing insight on the changing technologies and competition logics.
57 Reference Title Keywords Size Aoyama, 2003 Hardware gimmick or cultural innovation? Technological, cultural, and social foundations of Industry, Japan, Article the Japanese video game industry Creative industry Gaume, 2005 Nicolas Gaume’s Views on the Video Game Sector Views, overview, Article industry, development Grantham, Getting the Measure of the Electronic Games Industry: Innovation management Article 2005 Developers and the Management of Innovation Tschang, 2005 Videogames as interactive experiential products and their manner of development Product development Article Cadin, 2005 What Can We Learn from the Video Games Industry? Industry, Culture, Article Experience, Creativity Cohendet, Playing across the playground: Knowledge creation Article 2007 Paradoxes of knowledge creation in the videogame firm Dymek, 2008 Content Strategies of the Future: Between Games and Stories Cultural industry Article Crossroads for the Video Game Industry Peltoniemi, Life-cycle of the Games Industry Industry life-cycle, Article 2008 The Specificities of Creative Industries Creative industries Zackariasson, Paradigm shifts in the video game industry Entertainment industry, Article 2008 Strategy Kultima, 2009 “Hopefully everything I’m Doing Has to Do with Innovation” Industry, Innovation Article Games industry professionals on innovation in 2009 Peltoniemi, Industry Life-Cycle Theory in the Cultural Domain: Cultural / creative -industry, Book 2009 Dynamics of the Games Industry Industry life-cycle Potanin, 2010 Forces in Play: The Business and Culture of Videogame Production Business, Culture, Design Article Table 17: Creativity in video games - literature
58 Nicolas Gaume’s views (2004-2005) exhibits the wide difference between SE-literature and the actual developers. The SE models are rejected as ineffective and the whole organization is geared towards creativity. Many of the features Gaume mentions can be derived back to the data of this thesis. He also brings forth a main concept of video games neglected by SE-literature: the experience. ‘video game is an imaginary, perception-linked product. It offers a very intense experience - -’. Games are presented as ‘products of universal pop culture’ which are sold across cultural borders. Each customer (player) is said to look for ‘existentialist experience’ which ‘feeds imaginary’. The extremely short life cycle of games on the market is noted as the development of a game can take years, but most of sales turn in few months from publishing. The industry pushes the boundaries of technology with the constant need for novelty. Linked together with high up-front costs before any revenue can be created makes the industry very risky. Gaume claims a necessity to redefine the old ‘Taylor-inspired production models’ for video games. He sees the manager as a coach that enables the team to create the knowledge that meets the needs of the players. The creators of these games ‘work together with creative teams - - become more and more creative themselves - - and go beyond the strict cultural frame of the engineer’. He sees technology as the limiting factor for creativity in video game development. Gaume sees this management of the interdisciplinary team in the volatile market one of the biggest challenges of the industry. He notes that the development of the video game is actually more pluridisciplinary than interdisciplinary in that the teams and individuals work with several aspects of the game in parallel. The article continues in describing the production of a video game. The ‘creative alchemy’ of pre-production is the constant prototyping of the game. This is compared to a movie director creating a new camera for every movie. Communication is in a key role throughout the development. On production the limitation of what the game will not be are seen critical in limiting the exploration, while things have to be left open as long as possible so that the creative can be used to explore the possibilities. All this has to happen with the player (customer) in mind. Then in post-production ‘given the constantly evolving technology, each game is almost a prototype - -‘ as such the end result is almost impossible to see before the end of production. The tools shorten the pre-production iteration with fast prototyping and speed up the actual production. The management of a pre-production team is described as ‘paradoxical and schizophrenic exercise’ where creativity needs room to flourish but the
59 business demands pressure in on the team. This is the job of the manager – they do not create, but incubate the vision and orchestrate the creativity.
Tschang (2004-2005) raises a question whether a new product development model is needed to address the specific needs of video game development. The paper studies video games from product development point of view presenting the characteristics of video games and problems in their development. He notes lack of new innovation and product development perspectives as functionality has dominated over entertainment value in the last years. He places video games in the ‘emerging creative industry’ as ‘experiential’ products, focusing on the experience provided by the product. He points out features of experiential production, such as frequent milestones and testing, design iteration, multifunctional teams and strong project leadership. Also unique features are pointed out: complex concurrent development, pipelining, integration issues, feature creep and feature iteration. Games are differentiated from other entertainment products, like theater and literature, with their interactivity. This is also pointed out to be one of the main causes for the issue of ‘fun’ and ‘good gameplay’. ‘The complex combination of technology, creative game design and artistic content cause complexity and uncertainty in the development processes.’
Grantham and Kaplinsky (2005) studied innovation management trying to provide game industry with more routinized innovation practices. They conclude that 1) the need for innovation rises from the competition level of the market, 2) innovation needs to be managed as it does not happen by itself, 3) the success factors for the market need to be understood, 4) in order to create sustainable success the process needs to be measured, 5) the measured indicators need to be sector specific, 6) a schema is needed for the innovation management. They provide a schema that can be used to gain information of value chain performance and positioning. However this schema is geared towards business management and is little of use in the actual development process studied in this thesis.
Cadin & Guerin (2006) manage to describe on of the main problems in the results of this thesis – the mixture of exploration and exploitation in video game development. They delve deeper into the ‘experience economy’ explaining three general issues of experience industries, namely interesting to us is the innovation-organization dilemma: if an
60 organization intends to innovate and benefit from the results it has to stimulate the exploration and on the other hand effectively exploit the innovations while minimizing uncertainty by producing repeatable processes. They state specificities of games industry: interactivity, interdisciplinarity and velocity, with the last stating the short life-cycle in the industry (as the trigger of innovation-organization dilemma) which are all in-line with our results. They conclude their analysis with a strong statement: ‘Video games’ role in cultural capitalism could be the same as the one that the automobile industry plays in the conceptualization of the industrial capitalism’.
Cohendet and Simon (2007) provide us with tools to further analyze the paradox of knowledge management in video game development. They focus on management of creativity and expression of artistic values in video game companies, with an eye on the pressure of the economics of mass entertainment. Their research is based on a study of one of the biggest video game developers in the world providing a size difference to our study’s organizations. They describe video games ‘a creative industry cultural product that is a complex mix of technology, art and interactive story-telling’, providing a lush background for video game development. The managers’ role is to ‘harness expression of artistic values and technological virtuosity to meet the constraints of the economics of mass entertainment’. They highlight the paradox of video game development as on one hand there is an ‘artistic mode of flexible and decentralized creative communities’ and on the other hand ‘a strict managerial attitude of tight integration within time, cost and market constraints‘. ‘Too strong integration could lead to a permanent reduction in diversity and creativity; too loose an integration could lead to divergence, chaos, and inefficiency’. Overall they describe a broad view of video game development and its ties to the micro creativity of the communities of specialists, macro creativity of projects, constraints of the economy and the management of the explore-exploit -dilemma in this framework.
Dymek (2008) argues that due to the neo-classical roots of the previous theories a new perspective linking video game medium, ludology, culture, economy and technology, is required for video game industry economics. He sees the cultural economics perspective lacking view of video games as a new type of medium previously unavailable and that the technology perspective exaggerates the focus on technological aspects overlooking the
61 creativity. Video game industry is placed in the crossroads of information technology and show-biz/media/cultural -industries. He explores game related literature narratology and ludology to broaden the view of the industry and matches cultural industry specific features to video game industry: uncertain demand, care for products (’art for art’s sake’), diverse skills, differentiated products and skills, essence of time and the durability of products.
Peltoniemi (2008, 2009) assesses the maturity of the game industry with the industry life- cycle theory. The study further implies of video game industry’s uniqueness from traditional productive industry to such an extent that new methods are needed. She reviews the characteristics of creative and cultural industries: monopolistic competition and horizontal differentiation, hits and misses, increasing returns, gatekeepers, taste formation & experience goods, skewed labor markets, majors & independents. She states that the industry is non-concentrated showing strong growth in new entries and only few exits, implying the software side of the games industry far from mature. Explanations are derived from 1) standardized hardware allowing software to pursue innovation in the content and technology, 2) horizontal differentiation of creative goods means no one game can serve the entire market – room for small innovative companies is always present, 3) the economies of scale are not sufficient to allow consolidation through developing several games inside a single studio, 4) constant need for novelty limits cumulative experience given advantage of the current companies on the market, 5) tendency for hits or misses causes the market shares to vary greatly, 6) increasing returns of the digital products create opportunity of getting rich for new entrepreneurs, 7) Non-monetary rewards of working in the game industry lower salaries making entry barriers lower for entrants and enabling to compete longer without profits. She concludes that 8) ‘The game development sector departs from the manufacturing industries, based on which the industry life-cycle theory was developed, to such an extent that it is not applicable for assessing the maturity of game development’.
The hardships in analyzing the industry are repeated in Zackariasson’s & Wilson’s (2008) article where they discuss the paradigm shifts within the video game industry through literature review. They imply four major shifts: 1) from pinball to electronic entertainment, 2) from arcades to home and hand-held devices, 3) entry of independent game developers
62 and 4) development of MMOGs (massively multiplayer online game) shifting distribution and payment models of the industry. They conclude the industry difficult to assess due to constant changes of the value chain dynamics between the four major players: developers, publishers, console manufacturers, and distributors.
Kultima & Alha (2010) interviewed 28 game industry professionals on their views about innovation in game development. Their results are also in-line with our data: they present dualistic views and the need for specific methods for the industry. The maturing of game industry through innovations turning to incremental instead of genre creating is presented, while the industry has shown major growth in new areas like MMOGs like World of Warcraft and casual games like Farmville bringing in new possibilities for innovation. They conclude that the views ‘reflect the current state of the game industry as it undergoes changes and heads toward incorporating more rationalized, fine-tuned processes and appropriate tools for innovation- -.’ They see that the past views are still present in their data with ‘a view of game developing as a purely artistic endeavor that relies on a handicraft approach and mystical perspectives on creativity, idea creation and the management of creative process’. They state this ‘intrinsic motivation is one of the key factors in creativity’ and ‘the tools and methods of the future should acknowledge this perspective as well’ predicting new agile development tools and methods for video game industry.
As the last piece of literature the Potanin (2010) widely criticizes the game development practices: the powerful role of the publisher, the market volatility, the designers ‘I’ mentality, the communication issues, the salaries, etc. He quotes ‘The ultimate guide to video game writing and design’ by Flint Dille and Jonh Zuur: ‘Games, like most creative works, go through many changes on the road to fruition. However, a unique aspect of the videogame business is that it embraces the process of iteration. That means the development of a title doesn’t necessarily have a gradual ramp upward to completion. Instead, there will be starts and stops, wrong turns, missteps, reversals and retreats, a refocusing of ideas, feature-sets that are abandoned, levels that are cut, and new ideas that come flying in at the last minute, which makes everything better, but may also make everything that much harder.’ He argues that the problem with scheduling arises from ‘a confluence of issues: a lack of mature, experienced production staff and professionally
63 trained managers and an iterative production methodology that encourages change and therefore uncertainty’. Contrary to previous studies he states that considering the volume of unoriginal games being produced indicates publishers and developers are focusing on low-risk titles in the video game marketplace. This however contradicts little as even though more unoriginal titles are being produced by the big publishers and developers a stream of new small developers and publishing channels have surfaced offering novelty for the market.
7.1.1 Summary
Where Aoyama & Hiro (2003) link video games and cultural industry, the interview of Gaume (2005) provides a view from the inside. The complexity of the development is further fortified by Tschang (2005) in his study of post-mortems, where he brings forth experience as a key component of a video game. The ‘experience economy’ is explained in relevance to video games by Cadin & Guerin (2006) presenting the exploration - exploitation -dilemma of creativity management. Grantham & Kaplinsky (2005) do provide a schema for innovation management in video game companies, but the tool is for business level management, and does not have relevance with the actual development process or creativity management on implementation level. On the other hand, Cohendet & Simon (2007) with their study of paradoxes in knowledge creation in the video game industry are very close to management of the actual development, providing tools to further analysis of the results presented in this thesis. Dymek (2008) broadens the view of video games including literature of ludology and narratology to the mix, where Peltoniemi (2008) evaluates the video game industry with industry life-cycle theory. Zackariasson & Wilson (2008) provide a fresh view of the industry with a review of the paradigm shifts in the industry where Kultima & Alha (2010) present a mixture of views on innovation predicting new methods surfacing. Potanin (2010) sets a critical view towards the state of the industry with still many issues.
It is clear that the overall view presented in this category of literature (Table 17) is different from that of SE-literature (Table 2). Video games are presented as a creative cultural industry product in all the articles with a wide range of features (Table 18). This category of literature provided a much needed separate perspective from SE-literature with
64 an overall understanding of the explore-exploitation -paradox that encompasses the whole video game industry.
Reference Cultural / Creative industry Unique Gaume, 2005 short life-cycle, high-tech, pluridisciplinarity need for novelty Tschang, frequent milestones, constant complex concurrent development, 2005 testing, design iteration, pipelining, integration issues, multifunctional teams, strong feature creep, feature iteration, project leadership, experience interactivity, fun, good gameplay Cadin, 2006 experience interactivity, interdisciplinarity, velocity Dymek, 2008 uncertain demand, care for products new type of medium, (’art for art’s sake’), diverse skills, unique combination differentiated products, essence of time, durability of products Peltoniemi, monopolistic competition, - 2008 & 2009 horizontal differentiation, hits and misses, increasing returns, gatekeepers, taste formation & experience goods, skewed labor markets, majors & independents Zackariasson, constant change of the value chain - 2008 dynamics Table 18: Features of video game industry
However, apart from Cohendets & Simons (2007) contribution on knowledge management, better hands-on information on how the problem is solved in the industry is needed. The common factor with the creative category literature and software engineering literature is the common implication of non-functional requirements of ‘fun’ and ‘good gameplay’ to create an ‘experience’.
65 7.2 Experience and Game design
The third literature search for experience in video games provided very lush results. The roots of the experience literature were found and a wide array of user experience -literature led to a daunting discovery. Game design literature can be found in huge amounts providing research and analysis of the design and development of video games from the point of view that is not non-existing in software engineering. The categorization of the literature can be seen in table 19.
Pine II & Gilmore (1996) foresaw the emergence of what they called ‘experience economy’. Like the production of utilities gave way for providing of services, so would service providers be surpassed by ‘experience stagers’. The products would be memorable, personal, revealed over duration and the factor of their demand would be sensations:
‘Before company can charge admission, it must design an experience that customers judge to be worth the price. Excellent design, marketing, and delivery will be every bit as crucial for experiences as they are for goods and services. Ingenuity and innovation will always precede growth in revenue. Yet experiences, like goods and services, have their own distinct qualities and characteristics and present their own design challenges.’ (Pine II & Gilmore, 1996, p. 101)
The described ‘experience economy’ is brought closer to video games by Wright & McCarthy (2004). They saw user experience becoming central to the usability of technology and give way for a view of perceiving technology as an experience. They provide a framework for conceptualizing technology as an experience for a foundation of future work.
With the inclusion of psychology, user experience and game design the amount of literature expands rapidly. The analysis and interpretation of the results of this thesis with the found literature after this point goes beyond the scale of master’s thesis.
66 Reference Title Keywords Size Pine II, 1996 Welcome to the Experience Economy Experience Economy Article Rouse III, 2001 Game Design: Theory & Practice Game design Book Björk, 2004 Patterns in Game Design Game design, patterns Book McCarthy, 2004 Technology as Experience User Experience Book / Article Rollings, 2004 Game Architecture and Design: A New Edition Game design Book Salen, 2004 Rules of Play: Game Design Fundamentals Game design Book Ermi, 2005 Fundamental Components of the Gameplay Experience: User experience, Article Analysing Immersion Immersion Cowley, 2006 User-System-Experience Model for User Centered Design in Computer Games User experience, Article Game design Calleja, 2007 Digital Games as Designed Experience: User Experience, Book Reframing the Concept of Immersion Immersion Lindley, 2008 Game Play Schemas: Schema, Design, Article From Player Analysis to Adaptive Game Mechanics Human factors Schell, 2008 The Art of Game Design - A Book of Lenses Game design Book Canossa, 2009 Play-Personas: Game design, Article Behaviours and Belief Systems in User-Centred Game Design User-centric Gámez, 2009 On the Core Elements of the Experience of Playing Video Games User experience Book Gonzàles, 2009 Playability: How to Identify the Player Experience in a Video Game User experience Article Swink, 2009 Game Feel - A game designer’s guide to virtual sensation User experience, Book Game design Hagen, 2010 Designing for Player Experience Game design, Article How professional game developers communicate design visions User Experience Takatalo, 2010 Evaluating User Experience in Games User Experience Article / Book Howell, 2011 Schematically Disruptive Game Design Schema, Game design Article Table 19: Experience & Game design -literature
67 8 DISCUSSION
The current software engineering literature is not sufficient to provide understanding of the video game development process. However, a slow shift is detected in software engineering literature about video games. The same shift is also found in the creative industries literature of video games.
‘The software engineering process in video game development is not clearly understood, hindering the development of reliable practices and processes for this field. -- The accumulated evidence clearly identifies the need to extend traditional requirements engineering techniques to support the creative process in video game development. (Callelle, 2005, p.1)
‘-- the complex combination of technology, (creative) game design and (artistic) content within video games -- cause complexity and uncertainty in the development processes. - - While the use of more rational development processes (such as formal software development practices from software engineering) could help with these issues, new thinking can also be done in the future about whether new and more appropriate product development models can be developed to address the needs of videogame development.’, (Tschang, 2005, p.103)
‘—the cultural industries perspective provides valuable insights regarding the economic dynamics of the game industry, but is, due to its foundations in neoclassical economics, incapable of taking into account a medium’s unique characteristics --. Simultaneously, the “IT perspective” on video games presents an exaggerated focus on the technological aspects of the video game industry, consequently overlooking, in broad terms, the “creative” and “cultural” aspects of the medium--.” (Dymek 2008, p.420)
68 ‘The game development sector departs from the manufacturing industries, based on which the industry life-cycle theory was developed, to such an extent that it is not applicable for assessing the maturity of game development’ (Peltoniemi, 2008, p.57)
‘Artistic views are not dissolving only for the sake of the rationalization and efficiency. Nor that they should, as intrinsic motivation is one of the key factors in creativity. The tools and methods of the future should acknowledge this perspective as well. We will probably see specific agile development tools for game development in the future--’ (Kultima & Alha, 2009, p.7)
‘Video games’ role in cultural capitalism could be the same as the one that the automobile industry plays in the conceptualization of the industrial capitalism’. (Cadin & Guerin, 2006, p. 254)
These quotes state the need for specific methods and processes for video game industry, its product development and management as the current methods, tools, processes and paradigms are insufficient in the analysis of video games, industry and the manner of their development. However, the shift has spread even wider - it can be found in the contemporary software engineering literature outside video game development. Jantunen (2012) concludes in his thesis:
‘- - current product management approaches are becoming inadequate to deal with challenges that have multiple and conflicting interpretations, different value orientations, unclear goals, contradictions and paradoxes. This inadequacy continues to increase until current beliefs and assumptions about the product management challenges are questioned and a new paradigm for dealing with the challenges adopted.’ (Jantunen, 2012, p.3)
He calls this deepening gap between problems and proposed solutions a paradigm paralysis and calls for a new paradigm.
69 8.1 Towards ‘Experience Paradigm’
The provided evidence from software engineering, creative industry and innovation management literature in regards of the large amount of game design and user experience literature found, with the results of the study lead me to the following conclusions:
I. Video games are experience products a. The sole reason video games exist is the experience they produce for the player. The sensation of ‘fun’, ‘challenging’ or even ‘frustrating’, is the drive of demand on the market. Experience is the core of a video game.
II. SE is unable to cope with the experience and its creative development process a. The current methods derive from the foundations of industrialization where design preceded mass manufacturing. As the economies of scale have shifted with digital products – so has the balance of design and production. b. Current methods focus on functionality, which is only one piece in producing an experience. It is an important piece, but functionality alone does not create the experience.
III. This causes tension between real life problems and proposed methods a. Real life requirements engineering issues are unsolvable with the proposed expert techniques of the current SE literature (Jantunen, 2012). b. Visible also in business and management as researchers are unable to analyze video game industry with the current tools and methods.
IV. A new experience paradigm is emerging a. Video games are an example of an experience based product. Technology has become an integral part of our lives and holds no real value by itself. Instead of enabling, technology has become a limiting factor for social and economic aspirations.
70 8.2 Future study – ‘Video Games as Experience’
As this thesis has pointed out the shortcomings of reviewed literature - to form a coherent picture of video games, development and industry - the subject needs further study. The analysis of current data and results needs to be completed with the user experience and game design literature for further explanations. A new study of knowledge management in video game companies and its effects on development processes is required to deepen our understanding of the complex video game development. A draft model, based on the study of this thesis, is presented to act as a tool for the future study (Figure 11).
Control
Tech
Design Theme
Experience
Interaction Gameplay Art
Immersion
Figure 11: Experience based video game
As stated in 8.1, I: Video games are experience products. The number one aim of a development project should be to capture that experience.
Video game is a complex combination of software technology, artistic assets and gameplay combined to produce an experience. The creation of a video game starts from a game
71 vision encompassing the look and feel of the game and the main methods of gameplay. The gameplay artifact delivers the experience to the player through interaction. Art is created based on coherent theme creating immersion. The technology limits the possibilities of what can be done and ultimately is what brings the video game together controlling the flow of the experience.
8.3 Critique and limitations
No study is without flaws and limitations. This sub-chapter discusses the study specific and grounded theory -related critique and limitations: late entry to data collection, generalizability of results, research bias, torturing of data and pragmatic usefulness.
Late entry: Author started working in the project after third round of interviews was done. By the time there was a large amount of data to be codified. The interviews cover a multitude of subjects providing a wide range of data. Instead of focusing on the development process of video games the data analysis majorly focused on finding the relevant data among the interviews. This lead to overhead on data-analysis and the pressure to provide additional questions for the fourth round came too early. More time could have been used in the first round of analysis to supply more relevant questions to the following rounds. As such the current interviews repeat the same answers. On the other hand , this validates the study by providing proof of fully saturated themes that do not vary with additional data.
Generalizability: The studied organizations represent small and medium sized organizations from a geographically small area of South-Eastern Finland, with many of them being start-up companies. The generalizability of the results regarding maturity, employed methods and processes, problems, etc. are limited to organizations of relevant size and age. The culture of the area might also have an impact on the data. However, the results of the study have some alignment with other studies conducted with larger video game development organizations (Hagen, 2010; Cohendet & Simon, 2007)
Research bias: A researcher cannot be free of preconceptions. Everyone carries with him his assumptions and knowledge attained before the grounded theory research. However
72 neither Strauss nor Glaser meant to find a ‘tabula rasa’ for the researcher. Instead some of the background knowledge is needed on any research project. However, being sensitive for new insights and theories is deemed very important (Corbin & Strauss, 2008). Entering the study with a hobby background in video games and master level studies in information technology the author did not have a clear view of the industry, the development methods nor the scientific literature at the start of the project. With the iteration of data acquiring, analysis and literature review, the results surfaced and matured during the study.
Torturing data: Emergence of theories from data is of importance in grounded theory. Glaser (Glaser, 1998) argues that the data will submit to the theory the researcher is after. If a set of data is ‘tortured’ long enough to prove a theory, in the end enough categories and their relations can be proven. This means that the plausibility of the results could be questioned. If anything can be said and proven is any of it of any value in accumulating knowledge? This directly leads to question the pragmatic usefulness of results from grounded theory. As presented on above the researcher was free of bias and had no need to pursue any single result from the data. The author was free to study and let the results emerge from the data.
Pragmatically un-useful: Due to the nature of grounded theory the relation between reality and the theory is controversial. Even though the theory emerged from the data and is applicable to several occurrences, most of the analysis is based on the researchers own insights. Thus verifying the hypothesis and replicating the results of the study is hard. (Corbin & Strauss, 2008)
All of the critique can be answered, up to certain level, with triangulation. The data was acquired by several interviewees, from several companies, from several roles. The analysis was conducted mainly by the author, but the project members working on specifics had free discussions from time to time. For the experience paradigm claims of the thesis in conjunction of SE-literature, creativity, experience and game design literature were also viewed. As such the theory-base from which the data was looked at varied during the study. With these backups an exchange of time was made by triangulation for more confidence to the data and results of analysis by preventing subjectivity from a single source (Corbin & Strauss, 2008).
73 9 CONCLUSIONS
The results show that the development of video games differs from traditional software. Current SE-literature does not offer ways to validate non-functional requirements (fun, immersive, entertaining, etc.) of the video game design. As the game design cannot be ‘solved’ before implementation – design iteration occurs during development. To counteract, the organizations produce video games in a creative and iterative manner as a collective of, not multidisciplinary team of experts, but interdisciplinary developers who all share one quality – passion for games. The organizations small sizes and informal structures enable informal and frequent communication of tacit knowledge. Instead of heavy documentation and testing procedures that would slow down the process, the organizations focus on speed and agility. Testing is an ad-hoc process with only few organizations having dedicated QA. The organizations are pressured by tight schedules and lack of resources. This causes issues with methods and processes being discarded with closing deadlines. Outsourcing is used to reduce workload of development team. In view of these features, the ISO/IEC 29110 models relevance is questionable due to its foundation on traditional software engineering.
As the software engineering methods are insufficient in explaining the studied processes the tension between problems and proposed solutions increases. The gap of knowledge is visible not only in software engineering, but also in business and management of video games industry. As such, the need for a new paradigm increases to understand the true nature of video games and their development. Video games are designed to produce interactive experience. The constant need for novelty in the industry and non-functional requirements to create a good game create an explore-exploitation paradox of knowledge management. This paradox and its effects on the development processes of video games needs further study.
74 REFERENCES
Aoyama, Y, Izushi, H, Hardware gimmick or cultural innovation? Technological, cultural, and social foundations of the Japanese video game industry, Research Policy 32 (2003) 423–444
Birks, M, Mills, J, “Grounded Theory – A Practical Guide”, SAGE Publications, Jan 19, 2011
Björk, s, Holopainen, J, Patterns in Game Design (Game Development Series) Charles River Media; 1 edition (December 20, 2004), ISBN-10: 1584503548, ISBN-13: 978- 1584503545
Blow, J. Game development harder than you think, Queue - Game Development Queue Homepage archive, Volume 1 Issue 10, February 2004, Pages 28, ACM New York, NY, USA, 10.1145/971564.971590
Cadin, L, Guerin, F, “What Can We Learn from the Video Games Industry?” European Management Journal Vol. 24, No. 4, pp. 248–255, 2006, 2006 Elsevier Ltd. All rights reserved. 0263-2373 $32.00, doi:10.1016/j.emj.2006.05.001
Callelle, D, et.al., "Requirements Engineering and the Creative Process in the Video Game Industry," Requirements Engineering, IEEE International Conference on, vol. 0, no. 0, pp. 240-252, 13th IEEE International Requirements Engineering Conference (RE'05), 2005.
Corbin, J, Strauss, A, “Basics of Qualitative Research – Techniques and Procedures for Developing Grounded Theory 3e”, Sage Publications, 2008
Crosby, O, “Working so others can play: jobs in video game development”, Occupational Outlook Quarterly, Summer 2000
75 Doulin, A, “Building a strong indie game development team”, http://www.gamasutra.com/blogs/AlistairDoulin/20100107/4040/Building_A_Strong_Indi e_Game_Development_Team.php, 23.8.2012
Dymek, N, “Content Strategies of the Future: Between Games and Stories – Crossroads for the Video Game Industry”
ESA1: Video Games in the 21st Century: The 2010 Report, http://www.theesa.com/facts/pdfs/Video games21stCentury_2010.pdf)
ESA2: Video game research, http://www.theesa.com/facts/video-game-research.asp, 17.8.2012
ESRB, http://www.esrb.org/about/images/vidGames04.png , 1.11.2010
Flynt, J, Salem, O. “Software engineering for game developers”, Thomson course technology PTR, 2005
Gaume, N, Nicolas Gaume’s Views on the Video Games Sector, European Management Journal Vol. 24, No. 4, pp. 299–309, 2006, 2006 Elsevier Ltd. All rights reserved. 0263- 2373 $32.00, doi:10.1016/j.emj.2006.05.005
Game Unified Process, http://www.gamedev.net/page/resources/_/technical/general- programming/game-unified-process-r1940, 22.8.2012
Glaser, B. “Doing Grounded Theory - Issues and Discussions.” Sociology Press 1998.
Glaser, B, Strauss, A, “Discovery of Grounded Theory: Strategies for Qualitative Research”, Transaction publishers, 1967
Hagen, U, “Designing for Player Experience: How Professional Game Developers Communicate Design Visions”, 2010
76 Kanode, C, Haddad, H, “Software Engineering Challenges in Game Development”, ---
Locke, K, “Grounded Theory in Management Research”, Sage Publications, 2001
Luton, http://www.gamasutra.com/view/feature/132554/making_better_games_through_.php, 23.10.2012
Macedo, Rodrigues, Experiences with Rapid Mobile Game Development Using Unity Engine, ACM Computers in Entertainment, Vol.9 No.3 Article 14, October 2011
Neogames, Center of Game Business, Research and Development, The Finnish Games Industry – report, 1.11.2012
Orlikowski, W. "CASE tools are organizational change: Investigating Incremental and Radical Changes in Systems Development," MIS Quarterly, (17:3), 1993, pp. 309-340.
Peltoniemi, M, ‘Industry life-cycle theory in the cultural domain: Dynamics of the games industry’, 2008
Pine, J, Gilmore, J, Welcome to the Experience Economy, Harvard Business Review July – August 1998, 97-105
Potanin, R, “Forces in Play: The Business and Culture of Video game Production”, Proceeding Fun and Games '10 Proceedings of the 3rd International Conference on Fun and Games, Pages 135-143, ACM New York, NY, USA ©2010, ISBN: 978-1-60558-907- 7 doi>10.1145/1823818.1823833
PWC, Price waterhouse coopers (http://www.pwc.com/gx/en/global-entertainment-media- outlook/segment-insights/video-games.jhtml
Rouse III, R, Game Design: Theory & Practice, Wordware Publishing, USA, 2001
77 Seaman, C.B., “Qualitative methods in empirical studies of software engineering”, IEEE Transactions on Software Engineering, vol. 25, pp. 557-572, 1999.
Sengers, P. Autobiographical Design. CHI 2006 Workshop on Theory and Method for Experience-Centered Design, April 2006.
SOCES, “SOCES-project at Lappeenranta Univ. of Tech.” (Online). Available: http://www2.it.lut.fi/project/SOCES/. (Accessed: 15-August-2012).
Salen, K, Zimmerman, E, Rules of Play: Game Design Fundamentals, MIT Press, USA, 2004
Strauss, AL & Corbin, J 1990, Basics of Qualitative Research – Grounded Theory Procedures and Applications, Sage Publications, Newbury Park, CA.
Takatalo, et.al., Chapter 3: Presence, Involvement, and Flow in Digital Games, Evaluating User Experiences in Games, Springer-Verlag, 2010
Tschang, T, “Video games as interactive experiental products and their manner of development”, International Journal of Innovation Management, Vol. 9, No. 1 (March 2005), pp. 103–131 © Imperial College Press
Urquhart, C, Lehmann, H, Myers, M; “Putting the 'theory' back into grounded theory: guidelines for grounded theory studies in information systems. “, Information Systems Journal Jul2010, Vol. 20 Issue 4, p357-381-381
Weiß, S, Wolfgang, M, The Potential of Interactive Digital Storytelling for the Creation of Educational Computer Games
Zackariasson,P; Wilson, T. “Paradigm shifts in the video game industry”, Competitiveness Review: An International Business Journal incorporating Journal of Global Competitiveness, Volume 20, Number 2, 2010 , pp. 139-151(13)
78 APPENDIX I
Round 1 Interviews: Team leaders / Project managers
Topic 1: Key figures Q1: In your terms, explain what you do in your organization and how your work is related to game development. Q2: How large is the organization you are working in? How many people work on this organization? How many people work in the company? How many people, including those from outsourced or outside organizations, contribute to your product? Q3: What kind of games do you develop? Large-scale games (i.e those requiring specialized game consoles) or smaller-scale games (i.e. those that can be played through the internet or with mobile systems) and what is your target market? PC market, Internet, consoles, or other?
Topic 2: Development process and Creativity Q1: How do you decide on what product to make next? Who are involved in the creative process? How do you design the game (for example, by prototyping, mockups etc)? Who decides on the themes, rules or concepts included to the game? Q2: How does your organization develop a new software product like full game or expansion disc/DLC, What are the phases of this process? Do they differ between different types of products? How long does it take to develop one major product in your organization? Please describe your development process in a nutshell. Q3: ISO/IEC 29110 defines the following activities as a part of the project management (see Figure 1): Project planning; requirements and plans are created to guide the work Project plan execution; product is developed as planned Project assessment and control; the execution is assessed and controlled to steer the work towards preferred results. Project closure; product is delievered, needs for changes assessed, asset and tool reuse is decided upon. How does your organization reflect to these activities? How much in your development is planned beforehand, how much does your project plan change during the development process? How do you address the change if it occurs? APPENDIX I (continues)
Q4: ISO/IEC 29110 defines the following phases for software development (see Figure 1): Software Implementation Initiation: Resources are reserved Software Requirements Analysis: What needs to be done is decided Software Architectural and Detailed design: The product is designed Software Construction: The product is built. Software Integration and Tests: The product is tested and finalized Product delivery: The product is released to customers/publisher How does your organization reflect to these phases? Does your development method follow some certain model? In general, how formal is your development process? Q5: Name two strengths and two possible weaknesses in your development. Why are these things strengths or weaknesses?
Topic 3: Test process Q1: How is your software tested? What activities are done to test your software? Who decides when the product is tested enough? Please describe the test process of a typical software product in your organization. Q2: What is the main objective of your testing work? (Find the most important bugs or release a non-broken product or something else?) Q3: How large percentage of your testing work is planned before actual testing work? Do you do explorative testing? In your opinion, does this test plan work?
Topic 4: Quality Q1: How do you decide on the required quality of your software? How do you communicate this quality requirement to other stakeholders? In your opinion, does this approach work? Q2: Does the required (or intended) quality change during the project? Why?
Topic 5: Process development Q1: What changes are you currently experiencing and what is causing them? ( e.g. growth of your business, product changes, changes with the customer/target market, analysis of project feedback data or any other such reasons) Has the change been sudden or anticipated (i.e. managed/unmanaged?) In your opinion, is this change good, bad, neutral?
APPENDIX I (continues)
Q2: What are the current trends in the game industry that affect your work, and how? How are you addressing them? Q3: Do you do process development? Do you collect metrics on your process? What metrics/why not? Q4: Have you used some formal process development method (SPICE, TMMi, CMMi, TPI etc…)? What would it require for your organization to do formal process development (or certification program or comply with a standard)?
Topic 6: Outsourcing Q1: Do you do outsourcing? What kind of assets or resources do you acquire from outside? How large percentage of your game is developed primarily “in-house”?
Topic 7: Knowledge management, Tools and Services Q1: What software tools do you use in your development and testing? In your opinion, are they good enough or is there something that could be better? Is there any tool or service, which you currently would like to have but are unable to acquire? How or why did you choose this tool? Q2: Name up to three most important abilities required for game development project. Where can these abilities be learned or acquired? Q3: Is cloud computing in any way applicable for game development in your organization? If yes, how are you utilizing it? What are the advantages and disadvantages? If not, why not? Q3b: What aspects of your work (development and/or delivery of gaming products/services) are/would be most affected by cloud computing? How? Q4: Do the terms “gaming-as-a-service” and “gaming-on-demand” mean anything to you? Please describe.
Topic 8: Other Q1: In your opinion, is your work creative work which also has software development components or software development work with creative components? Why? Q2: If you had to choose, which in your opinion is more important, to make a financially
APPENDIX I (continues) successful, or high quality game? Why? Q3: Is there something you would like to add to this interview? Something you think is relevant but was not asked, or something that needs to be emphasized?
Figure 1 ISO/IEC 29110 Software Engineering – Lifecycle profiles for Very Small Entities Project management
Project Project Project plan Project assessment planning execution closure and control
Requirement Component Integration Implementation Construction Delievery initiation analysis identification and tests
Software implementation
APPENDIX II
Round 2 Interviews: Programmers and testers
Topic 1: Key figures Q1: In your terms, explain what you do in your organization and how your work is related to game development. Q2: How large is the organization you are working in? How many people work in your project? How many people directly affect your work, how many are affected by your work? Q3: What is the target platform of your products?
Topic 2: Development and ISO/IEC 29110 Q1: How does your organization develop a new software product like full game or expansion disc/DLC, and what are your activities in this process? Do they differ between different projects? How long does it take to develop and test one major product? Q2: How do you decide on what to do next? Who are involved in these decisions? In your opinion, does this approach work? Q3: Do you participate on the game design process, or have the ability to affect the decisions made on the game design? Overall, how large effect the design documensts have on your work? Q4: ISO/IEC 29110 (see last page) defines the following activities as a part of the project management: Project planning; requirements and plans are created to guide the work Project plan execution; product is developed as planned Project assessment and control; the execution is assessed and controlled to steer the work towards preferred results. Project closure; product is delivered, needs for changes assessed, asset and tool reuse is decided upon. ISO/IEC 29110 defines the following phases for software development: Software Implementation Initiation Software Requirements Analysis Software Architectural and Detailed design APPENDIX II (continues)
Software Construction Software Integration and Tests Product delivery In your opinion, how does your organization reflect to these phases? In general, how formal is your development process? Would you change something in your current development process? Q5: Name up to three strengths and three possible weaknesses of your organization. Why are these things strengths or weaknesses?
Topic 3: Outsourcing
Q1: Do you use outsourced resources? What kind of assets or resources do you work with? In your opinion, do these assets affect your work?
Topic 4: Test process Q1: How is your game tested? What activities do you do to test your software? Who decides on test objectives (i.e. when the product is tested enough)? In your opinion, is the applied approach working? Why? Q2: In your opinion, do you have enough resources (time/people/etc.) to develop and test your product to a satisfactory degree? In your opinion, how large portion of the “optimal” amount of resources do you have in development and in testing tasks? Q3: How large percentage of testing work is based on the plans or documentation? Do you do explorative testing? Does this test plan work/cover all the important parts that should be tested? Q4: What you consider to be the main objective of your testing work? (Find the most important bugs vs. release a non-broken product)
Topic 5: Quality Q1: How do you decide on the required quality of your software? How is this requirement communicated in your organization? In your opinion, does this approach work?
APPENDIX II (continues)
Q2: Does the required (or intended) quality change during the project? Why? Q3: Are there tasks that are required to be done by some external stakeholder such as publisher? If yes, what activities do these tasks include? Q4: Name up to three changes in your development or test processes which would enable better quality or otherwise improve the organization.
Topic 6: Tools Knowledge Transfer Q1: How do you share information? E.g. Do you use wikis? Email? Post-it notes? Q2: What kind of information is shared? E.g. Technical specifications, Game Design Document etc.? In your opinion, do you get enough data to work with on development or testing tasks? What sort of data do you find most useful in your tasks? Q3: How is communication between the team members done? Do you have instant messaging tools for it e.g. Messenger, Google Talk, Skype etc.? How much information is shared just by talking with people, compared to using some messaging tool?
Preproduction Q1: Describe the tools you use in preproduction phase. For example, do you generate game design document? Do you make prototypes and if so, what kind (paper/software)? How do you consider these designs or prototypes affect the production most (quality-wise, effiency-wise etc.)? Q2: Do you feel that the tools you use support innovation or creativity? Is it easy to test ideas with the tools you use?
Development Q1: Describe the tools you use development phase to make the actual game. Do you reuse material from preproduction (e.g. Software prototypes)? Q2: Do you have any sort of asset manager and if so, what kind? Q3: How is content added to the game? Are there utilities for writers and artists to add content or is it solely up to the programmers?
Q4: Is cloud computing in any way applicable for game development in your organization? If yes, how are you utilizing it? What are the advantages and disadvantages? What aspects
APPENDIX II (continues) of your work are most affected by cloud computing?
Q5: Do the terms “gaming-as-a-service” and “gaming-on-demand” mean anything to you? Please describe.
Work support and management Q1: What kind of work support tools do you use? How do you keep track of tasks? If there is a need for a change in the product, how is this documented and communicated? Q2: Do you collect metrics on your process? What metrics/why not? Do you use any benchmarking programs in your development? Do you get information on performance spikes or overall data? How useful benchmarking programs are in optimizing the game performance? Q3: How do you track project milestones? Do you use any tool for that?
Closing questions about tools Q1: Name two good features of the tools you're using. Is there any room for improvements?
Topic 7: Other Q1: Name up to three most important abilities required for game developer. Where can these abilities be learned or acquired? Q2: In your opinion, is your work creative work which also has software development components or software development work with creative components? Why? Q3: If you had to choose, which in your opinion is more important, to make a financially successful, or high quality game? Why? Q4: Is there something you would like to add to this interview? Something you think is relevant but was not asked, or something that needs to be emphasized?
APPENDIX II (continues)
ISO/IEC 29110 Software Engineering – Lifecycle profiles for Very Small Entities Project management
Project Project Project plan Project assessment planning execution closure and control
Requirement Component Integration Implementation Construction Delievery initiation analysis identification and tests
Software implementation
APPENDIX III
Round 3 Interviews SOCES – Software Development in Creative Ecosystems Round 1 Interviews: Team leaders / Project managers
Topic 1: Key figures
Q1: In your terms, explain what you do in your organization and how your work is related to game development. Q2: How large is the organization you are working in? How many people work on this organization? How many people work in the company? How many people, including those from outsourced or outside organizations, contribute to your product? Q3: What is the target platform of your products?
Topic 2: Development, Creativity and Psychlogy
Q1: How does your organization develop a new software product like full game or expansion disc/DLC, What are the phases of this process? Do they differ between different types of products? How long does it take to develop one major product in your organization? Please describe your development process in a nutshell. Q2: How do you decide on what product to make next? Who are involved in the creative process? Who decides on the themes, rules or concepts included to the game? Q3: ISO/IEC 29110 defines the following activities as a part of the project management (see Figure 1): Project planning; requirements and plans are created to guide the work Project plan execution; product is developed as planned Project assessment and control; the execution is assessed and controlled to steer the work towards preferred results. Project closure; product is delievered, needs for changes assessed, asset and tool reuse is decided upon. APPENDIX III (continues)
How does your organization reflect to these activities? How much in your development is planned beforehand, how much does your project plan change during the development process? Q4: ISO/IEC 29110 defines the following phases for software development (see Figure 2): Software Implementation Initiation Software Requirements Analysis Software Architectural and Detailed design Software Construction Software Integration and Tests Product delivery How does your organization reflect to these phases? Does your development method follow some certain model? In general, how formal is your development process? Q5: Name three strengths and three possible weaknesses in your development. Why are these things strengths or weaknesses? Topic 3: Test process
Q1: How is your software tested? What activities are done to test your software? Please describe the test process of a typical software product in your organization. Q2: Who decides on your test objectives (i.e. when the product is tested enough)? In your opinion, how independent are the development/project teams in design and implementation of their test work? Q3: How large percentage of your testing work is planned before actual testing work? Do you do explorative testing? Does this test plan work/cover all the important parts that should be tested? Q4: What is the main objective of your testing work? (Find the most important bugs vs. release a non-broken product) Would you consider your testing work to be more risk- or design-based? Topic 4: Quality
APPENDIX III (continues)
Q1: How do you decide on the required quality of your software? How do you communicate this quality requirement to other stakeholders? In your opinion, does this approach work? Q2: Does the required (or intended) quality change during the project? Why? Q3: Name three changes in your development or test process which would enable better quality. Topic 5: Process development
Q1: Do you do process development? Do you collect metrics on your process? What metrics/why not? Q2: Have you used some formal process development method (SPICE, TMMi, CMMi, TPI etc…)? What would it require for your organization to do formal process development (or certification program or comply with a standard)?
Topic 6: Outsourcing
Q1: Do you do outsourcing? What kind of assets or resources do you acquire from outside? How large percentage of your game content is based on these assets? Topic 7: Knowledge management, Tools and Services
Q1: What software tools do you use in your development? Q2: In your opinion, are they good enough or is there something that could be better? Do you need a software tool or service, but are unable to acquire it? Q3: Name up to five most important abilities required for game development project. Where can these abilities be learned or acquired? Topic 8: Other
Q1: In your opinion, is your work creative work which also has software development components or software development work with creative components? Why? Q2: If you had to choose, which in your opinion is more important, to make a financially successful, or high quality game? Why?
APPENDIX III (continues)
Q3: Is there something you would like to add to this interview? Something you think is relevant but was not asked, or something that needs to be emphasized?
APPENDIX III (continues)
Figure 1
APPENDIX III (continues)
Figure 2
APPENDIX IV
Round 4 Interviews SOCES – Software Development in Creative Ecosystems Round 4 Interviews: Game designers
Topic 1: Key figures
Q1: In your terms, explain what you do in your organization and how your work is related to game development. Q2: How large is the organization you are working in? How many people work in the company? How many people, including those from outsourced or outside organizations, contribute to the products you design? Q3: What is the target platform of your products?
Topic 2: Development process, ISO/IEC 29110
Q1: How does your organization develop a new software product like full game or expansion disc/DLC, What are the phases of this process? Do they differ between different types of products? How long does it take to develop one major product in your organization? Please describe your development process in a nutshell. Q2: ISO/IEC 29110 defines the following activities as a part of the project management (see last page): Project planning; requirements and plans are created to guide the work Project plan execution; product is developed as planned Project assessment and control; the execution is assessed and controlled to steer the work towards preferred results. Project closure; product is delivered, needs for changes assessed, asset and tool reuse is decided upon. ISO/IEC 29110 defines the following phases for software development (see last page): Software Implementation Initiation Software Requirements Analysis Software Architectural and Detailed design Software Construction APPENDIX IV (continues)
Software Integration and Tests Product delivery How does your organization reflect to these phases? Does your development method follow some certain model? In general, how formal is your development process? Q3: By using similar notation: Please draw and explain (your opinion) how your organization’s process actually works. (You can use different names for the steps, overlap them, etc.) - Does everyone in the organization share this view of the company’s actual process? - Does the actual process differ from the organizations official process? (How? Why?) Q4: Name three strengths and three possible weaknesses in your development. Why are these things strengths or weaknesses? Topic 3: Design process
Q1: How do you design games? How detailed designs your organization produces? Please describe your design process in a nutshell. Q2: What sources do you use most for inspiration? Do you follow current trends (as in what sells right now)? How does the financial feasibility affect your game designs? How about other people in your organization? Do you use game design patterns of any kind? Q3: In your opinion, how closely do the finalized products resemble to your designs? How do your communicate your designs to other stakeholders such as programmers? How closely do they follow your designs? Q4: How do you decide on what product to make next? Who are involved in the creative process? Who decides on the themes, rules or concepts included to the game? Can some external source such as publisher or customers affect these decisions? Q5: Are there any restrictions on your creative work, caused for example by available resources or tools? In your current organization and given unlimited resources, would you change something in your current development process? Why? Q6: Are games art? Why/Why not?
APPENDIX IV (continues)
Topic 4: Test process
Q1: How is your software tested? What activities are done to test your software? Please describe the test process of a typical software product in your organization. Q2: Do the testing results affect the game design, for example cause changes in game designs? How? Q3: In your opinion. what is the main objective of testing work? (Find the most important bugs vs. release a non-broken product) Would you consider your testing work to be more risk- or design-based? Topic 5: Quality
Q1: How do you decide on the required quality of your software? How do you communicate this quality requirement to other stakeholders? In your opinion, does this approach work? Q2: Does the required (or intended) quality change during the project? Why? Q3: Name up to three changes in your organization which would enable better quality. Topic 6: Tools and technologies Q1: Describe the main tools you use in design phase. For example, do you generate game design document? Do you make prototypes and if so, what kind (paper/software)? How do you consider these designs or prototypes affect the production most (quality-wise, effiency-wise etc.)? Q2: Do you feel that the tools you use support innovation or creativity? Is it easy to test ideas with the tools you use? Name two good features of the tools you're using. Is there any room for improvements?
Q3: Is cloud computing in any way applicable for game development in your organization? If yes, how are you utilizing it? What are the advantages and disadvantages? What aspects of your work are most affected by cloud computing?
APPENDIX IV (continues)
Q4: Do the terms “gaming-as-a-service” and “gaming-on-demand” mean anything to you? In your opinion, what do you think about the free-to-play business models? Topic 7: Company-specific questions on processes
<1-3 questions reserved for Risto’s Diploma Thesis-related company-specific questions, based on earlier interviews.> Topic 8: Other
Q1: Name up to three most important abilities required for game developer. Where can these abilities be learned or acquired? Q2: In your opinion, is your work creative work which also has software development components or software development work with creative components? Why? Q3: If you had to choose, which in your opinion is more important, to make a financially successful, or high quality game? Why? Q4: Is there something you would like to add to this interview? Something you think is relevant but was not asked, or something that needs to be emphasized? ISO/IEC 29110 Software Engineering – Lifecycle profiles for Very Small Entities Project management
Project Project Project plan Project assessment planning execution closure and control
Requirement Component Integration Implementation Construction Delievery initiation analysis identification and tests
Software implementation