**Abstract**

The following chapter presents an experience with academic education in computer games design and development based on game theory, emphasizing iterative development, rapid (paper) prototyping, and game testing. We demonstrate and comment on various educational activities focused on game testing, describing them in steps and including benefits and motivation. Iteration of card game rules, design of a board game, design of a computer game with a paper prototype, and testing of early-access games are supplemented with students' practical outputs in both text and graphical form. The results include feedback in the testing forms: Focus Groups, Playtesting, Usability Testing, and Quality Assurance.

**Keywords:** game design, game theory, game testing, playtesting, education

### **1. Introduction**

In addition to forming a game development basis, Game Theory can significantly affect the development of computer games. Some types of games have been known in Game Theory for a long time. However, some procedures are modified concerning modern technologies, allowing one to quickly solve some (up to now) complex tasks, e.g., independently of the computer graphics use. It is excellent when some principles from this theory are applied in the education process of computer games development, especially in the area of computer science education.

In terms of influence (**Figure 1**), we can observe mainly the following approaches to computer games testing:

• *Direction GTh (Game Theory)* ! *GTe (Game Testing)*: The Game Theory formalism defines the framework of Game Testing. It can determine what to

**Figure 1.**

*The effect of game theory on game development and vice versa.*

focus on during testing, notably with a specific type of game or what testing parameter to use. The formalism can specify possible threats and other aspects when including a SWOT analysis.


**Figure 2.** *Standard process of player(s) interaction in game loop.*

#### *Game Development and Testing in Education DOI: http://dx.doi.org/10.5772/intechopen.108529*

Regarding teaching computer games development, some *GTh* results can help define roles from a *GTe* perspective (e.g. Observer, Playtester, Bugfixer). Each one may have its formal apparatus or different parameters (values, methods of use, or semantics), depending on how the result supported by the theory applies to individual GTe roles, rules, strategies, or incidences.

At the Department of Computers and Informatics FEEI Technical University of Košice, we have implemented the *Design and Development of Computer Games* and related courses for several years. To be successful in implementation, the *CS* students, as future creators of computer games, need to have at least the basic apparatus of Game Theory. As part of the education process, the students become familiar with various methodologies and technologies related to computer games design and development: high concept, market research, storytelling, prototyping, rules balance, MDA, or iterative game development, an essential part of which is *GTe*.

In the chapter, we would like to present the primary forms of this education process, focusing on *GTe*, including some of the technologies used. We will also present some forms and demonstrations of *GTe* performed by students, corresponding mainly to the first two directions. We processed some results with an SUS questionnaire using a 5-point Likert scale.

We will present activity outputs recorded during the actual education process with 3rd-grade students of the bachelor's degree in Informatics in a full-time attendance form of study. We believe the experience presented in this chapter will find its readers. We attach great importance to the fact that these are actual data processed over multiple years and thus can provide a basis for other studies. We will comment on the outputs of student activities from the educational process point of view.

#### **1.1 Iterative game development and testing**

Testing is one of the critical processes accompanying the design and development of computer games. Game designers and developers often confuse or simplify different testing processes, leading to unsatisfactory results, e.g. for students who encounter testing as part of the educational process, it is most often confusion of *playtesting* with *bugfixing* (*quality assurance*) or playtesting with *usability testing* (*interface*). Therefore, in the next chapter, we will formally clarify the testing process and present one of the ways to incorporate various forms of testing into the educational process in computer game design and development.

Well-known literature states that four types of testing are crucial to the design and development of computer games [1, 2]:

• *Focus Groups:* They play a role, especially in the initial stage of game design, consisting of meetings with potential players providing feedback, likes, and dislikes on the upcoming game topic. The literature [1] states that although Focus Groups can be helpful, they are unpopular. The reason is management's fear of "killing" their ideas, so the book [2] recommends switching from obtaining onesided feedback to discussions generating new ideas. Such Focus Groups will allow iterating on existing ideas more effectively. Moreover, it does not have to be only the initial stages of game design. They can also be helpful later, e.g., when designing game levels or planning the marketing of an upcoming game, which is especially crucial in the final stage of game development.


*Game User Research* (*GUR*) intends to improve player experience [4]. *GUR* is a community of UX experts, game developers, and researchers, where the primary research subject is playtesting. In general, *GUR* supports the adaptation of standard HCI evaluation techniques in the playtesting practice, focusing on "entertainment" instead of "productivity" [5]. From the point of view of software engineering methods, *GUR* mainly recommends the *RITE* method [6]. The research applies other sophisticated methods such as *PLAY*, adapting various heuristic methods [7], or using artificial intelligence - AI Players. The goal is to predict player behavior and gaming experience [8].

As already mentioned, testing is critical in the iterative process of game design and development. It helps detect problems early (it is still possible to fix them). But what exactly is an iterative process?

Rapid Iterative Testing and Evaluation (RITE) is a software development method whose main philosophy is to identify a problem as soon as possible and eliminate it. During the last two decades, the *RITE* method has become widespread, especially for products changing rapidly e.g. web, cloud products, and games [6, 9].

It is too late to test at the end of game development. Otherwise, the changes would be too lengthy and costly. The *RITE* method guarantees early identification and elimination of the problem [2]. It is mainly adopted by larger game studios and recommended by the *GUR* community.

There are multiple testing types in game development. Playtesting is key to the *RITE* method, although other types of testing also find their place in individual stages of game design and development (**Figure 3**). From a practical point of view, it is best for playtesting if playtesters can play the game as soon as possible. Rapid prototyping (including paper prototypes) is advantageous if the game is still in the design stage.

A prototype is a simplified but testable game version. Designers create it before they spend money on implementing game elements and features. In general, there are three types of game prototypes [10]:

**Figure 3.** *Process of iterative game design.*


With smaller game industry studios, we encounter risk, so the game is published as soon as possible. In this case, they tend to skip the prototype and playtest only at the end of game development. Many rely on the fact that most game elements are copies of existing elements from other games. This risk results in the publication of many small, imperfect games. Fortunately, the game industry is changing thanks to the GUR community.

For playtesting, which is one of the game testing types, two people are essential:


The Investigator should talk to the players as little as possible to not influence their evaluation and create a questionnaire. The *Investigator* can track the answers' development over time after further iterations. A good *Investigator* should be able to identify playtesters' exit points and not be sad if they do not like the game ideas. The author of [1] recommends a scale of 1–5 instead of 1–10 or 1–7: *Terrible, Pretty bad, So-so, Good,* and *Excellent.*

On the contrary, the *Playtesters* should think out loud while playing, so the *Investigator* can record their thoughts. They should reveal their prejudices and self-analysis. So, in addition to evaluating something positively or negatively, they should also state the reasons. Good *Playtesters* should be able to comment on various game elements like graphics, music, story, mechanics, etc.

### **2. Game testing in education**

As we have already mentioned, in the education process during game testing, we often encounter students confusing playtesting with *bugfixing* or *playtesting* with

*usability testing*. Therefore, in the next chapter, we will introduce multiple educational activities in designing and developing computer games, focused on implementing various forms of testing. The goal is to provide students with an experience and make them aware of the differences. The activities proceed from our personal experience with software engineering students in the course of Computer Games Design and Development. We assume the students have already mastered software engineering principles, including traditional software design, development, and testing.

In the following subchapters, we will present multiple outputs of student testing activities. Testers' opinions and feelings are part of testing (especially playtesting). Therefore, the listed results also contain the opinions and feelings of selected students and may not always coincide with our opinions and feelings.
