Games as Software - Similarities and Differences between the Implelementation Projects

1. Dr. Jussi
Kasurinen
GAMES AS SOFTWARE
– SIMILARITIES AND DIFFERENCES
BETWEEN THE IMPLEMENTATION
PROJECTS

2.  The game development in principle is not different from the
traditional software development.
 In this study, the aim is to
 Assess the video game development from the viewpoint of software
engineering
 Assessing which software development activities are similar…
 … and which incompatible within the game industry context.
 We interviewed 11 companies and conducted a survey to
understand these differences.
 Basically, the project management and development tasks are
similar…
 …but the detailed activities, such as requirements engineering
practices, are noticeably different.
QUICK OVERVIEW

3.  During the last ten years, the game industry has
become a meaningful part of the global software
industries.
 In the year 2014, the video game industry reached a global
value of approximately 85 billion USD
 At the same time the total value of the software industry was
valued at around 400 billion.
 Basically every target demographic consumes
entertainment software; actually the average
consumer is closer to forty than twenty years old, and
almost half (44%) of the customers are women.
BACKGROUND

4.  There is no denying that the game development and
“traditional” software development aren’t similar to at
least some degree; both disciplines include
 project management,
 software development work
 testing activities as a quality assurance method.
 Obviously, the game development also has some
components and assets which are unique to the
industry
 It would seem viable that the methods and models of
the traditional software engineering theory would be
applicable, at least to some degree.
BACKGROUND

5. “How does the game development
process differ from the software
development process?”
“What concepts of the existing
software engineering discipline
could be applied in the game
development context?”
RESEARCH QUESTIONS

6.  Grounded Theory, Straussian approach
 Several organizations
 Several people, viewpoints (40+ professional developers, 11
companies)
 Codification process
 Seed categories
 Open coding
 Axial coding
 Selective coding
 Survey; online survey with 37 respondents (international
audience from some promotions)
 Part of a larger study into Games as Software
 Process models, testing practices, tool infrastructure, business
models etc…
RESEARCH AND DATA COLLECTION
METHODS

7. DATA COLLECTION
Interviewee
role
Description Main themes of the interviews
1 Team leader
or project
manager
The interviewee is responsible for the
management of the development of one product,
or one phase of develpment for all products.
Development process, test process, quality,
outsourcing, development tools,
organizational aspects.
2 Developer or
tester
The interviewee was responsible for the
development tasks, preferably also with the
responsibilities of software testing activities.
Development process, test process,
development tools, development methods,
quality.
3 Upper
management
or owner
The interviewee was from the upper management,
or a business owner with an active role in the
organization.
Organization, quality, marketing, innovation
and design process, development process.
4 Lead designer
or Art
designer
The interviewee was a game designer, or
managerial level person with the ability to affect
the product design.
Development process, design and
innovation, testing, quality
5 Upper
management
or owner
The interviewee was the owner or founder of the
company. Company was a recent startup.
Business model, marketing, customer
relations, 1st and 4th rounds summarized if
new participant.
+ Survey,
various
The interviewee was working in a game-developing
organization.
Processes, tools, methods, marketing,
required skills, management.

8. OBSERVED DIFFERENCES
Games industry Software Industry
-Products are built to entertain, and do not
necessarily have any purpose beyond
entertainment.
-Products are built on purpose, to fill some need,
provide functionality or enhance the overall
process.
-Product design aims to maximize the used
time with the product.
-Product design aims to minimize the needed
time to achieve functionality.
- In testing, high priority in user-experienced
quality, quality defined by users.
-Preferred quality differs between products and
projects, quality based on defined requirements.
-Technical solution only part of the product,
work also in creative narrative, sound
engineering and graphics. The technically
correctness and optimization is not a concern
beyond certain point.
-Technical solution and correctness important,
creative design mostly in user interface design.
Technical solution may be optimized, even after
the original satisfactory level is reached.
-Product features added after launch (DLC
content) common in products.
-Post-production bug fixes and upkeep; tailoring
for new target customers.
-Requirements and design based on abstract
concepts.
-Requirements and design based on real-world
concepts.

9. SUMMARY OF SIMILAR ACTIVITIES
Observed minor differences to the software development
-Project management; generally the project management activities were similar to the software
development projects.
-Technical development; all game products involve programming tasks at some level, which is similar
to the software work even though there are requirements for industry-specific expertise.
-Testing methods; although game industry has emphasis on the user experience, explorative testing
and usability aspects, the testing methods are similar to what the software industry applies.
-Business priority; Even though the game developers feel they are a “creative” industry, the design
decisions and practicalities are usually based on the business aspects.
Observed major differences to the software development
-Design and change management; Design changes constantly, the products may undergo major
changes in late development if any aspect of the design is not appealing to the customers.
-Content development; The creative aspects of development work is not modelled in the current
software engineering models.
-Tools; Some of the game-oriented development tools such as game engines are sophisticated enough
to require specific expertise in game development.
-Quality criteria; Game industry has more emphasis on the user experience and non-functional
requirements than software industry, and the required quality cannot be satisfactory defined with
functional or technical definitions.

10.  Almost every organization applies some form of iterative
development method
 …Although 61 percent of the survey respondents indicated that they do
not have any systematic development method.
 26 percent of respondents identified Scrum
 13 percent “some other agile practice”.
 Usually
 The organizations do not collect metrics or document their activities on
their software projects (2.3 on scale 1 = Fully disagree, 5 = Fully agree)
 The processes are often reactive to the encountered problems (3.6).
 The most important personnel types software developers (4.9 on
scale 1-5, where 0=not important and 5 = very important),
 artists (4.5)
 designers (4.0)
 business/salespeople (3.8)
 testers (3.2)
FINDINGS

11.  Current SE-literature does not offer many tools to implement the
process models with game industry-specific problems in mind
 example the Scrum model is applicable for the development and general
management tasks.
 The game design cannot be realistically finalized before
implementation
 Design iteration occurs during development …
 …and testing.
 in general, the management of the non-technical requirements proves
difficult.
 Overall, the game development process has similarities with
software process, but the principles of software engineering
discipline cannot answer to all game development problems.
 In the future, it would be sensible to offer design tools and
notation languages, which would allow “light-weight” UML-
practices and support the requirements, which are difficult to
express in technical terms.
FINDINGS

12.  Qualitative studies have some limitations in
applicability
 Only game developer’s side of the story so far.
 Reliability and validity
 Researcher bias
 ”The most important part is to show that the research team
actually knows what it knows.”
 However, in any case, qualitative study results are
always context-sensitive. Outside the scope of the
study they should be regarded as recommendations
or considerations.
DISCUSSION

13. ANY QUESTIONS?
For more information, please contact
jussi.kasurinen@lut.fi
Or visit our project homepage
http://www2.it.lut.fi/GRIP/
PR picture of our campus
(Unless I show this our
administration will not
validate my return ticket)