4 Game programming

4.1 Analysis with programming theories

In Chapter 2 (Programming practice), we discussed the work process of Tribeflame, a small computer game company of six people in Turku, South-western Finland. In Chapter 3 (Programming theories) the most important theories of programming were explained. In this section, we will apply the mainstream theories of programming to Tribeflame’s process in order to see how well they are suited to analysis of a concrete programming process. The purpose of this is not to indicate where the mainstream theories are wrong, but to investigate whether they work as general programming theories. If they are truly general programming theories, they should be able to explain a viable commercial process as provided by the Tribeflame example. If they are not, science demands that we explain to what situations the theories are suited, and what their limitations are.

4.1.1 Software engineering

Looking at the Tribeflame process, we see a distinct lack of the clearly-separated phases that are the basis of software engineering theories. The phases that are common to nearly all theories are specification, architecture (or high level design), design, coding, and test. Of these, the specification, architecture, and design activities at Tribeflame are carried out during the meetings, shown in Figure 2.3, and during the constant discussions and interactions outside meetings, shown in Figure 2.5. As indicated, the activities are spread out over the duration of the process.

Figure 4.1 – Frequency of bug fixing, a part of testing. The axis represents days. The boxes indicate that the activity occurred on that day; the crosses indicate missing observation data.

The same is the case with coding, as can be seen in Figure 2.2. Testing comprises several activities. According to traditional software engineering, bug fixing (error fixing) can be considered a part of testing. Bug fixing at Tribeflame is shown in Figure 4.1. Playtests and external playtests, shown in Figure 2.9, also function as forms of testing. As we can see, testing occurs throughout the observation period except for the first week, and testing is concurrent with the specification, design and coding activities.

Even though the observation period covers but a small fraction of the development of a complete product, we find the activities of all of the phases of traditional software engineering represented within it. Moreover, the activities do not occur in an orderly, separated fashion, so we cannot interpret the development process as consisting of smaller iterations, each containing a complete set of phases, as advocated by some software engineering theories.

The conclusion is that the activities described by the software engineering phases all occur in Tribeflame’s process, but the idea of separating the activities into distinct phases does not help to explain what is happening in the process.

Corresponding to the lack of separate phases is a lack of transition criteria. In software engineering, transition criteria between phases are normally the completion of a document, work product, or artefact. In Tribeflame’s work, there are remarkably few documents, and they do not play a central role. A few concept sketches and similar are important, and these are lying around in the office. But they are not kept up to date, and they are seldom referred to.

Most of the knowledge is transmitted orally or in the game itself. The source code of the game can conceivably be thought of as a work product, but it does not function as a transition point since it is constantly evolving and never reaches a finished state that is signed off.

As we saw in Section 3.1 (Software engineering), the main concerns of software engineering are planning, documenting, and evaluating. We can recall from Chapter 2 (Programming practice) that in Tribeflame planning is done in an impromptu way on temporary flip-charts and whiteboards – far from the systematic planning and milestone-oriented methods promoted by software engineering, such as PERT and Gantt charts.

Regarding documentation, Tribeflame produces almost none. The knowledge is kept in the developers’ memories, in the evolving source code, and occasionally concretized in a few concept sketches.

Figure 4.2 – Frequency of evaluation sessions. The axis represents days. The boxes indicate that the activity occurred on that day; the crosses indicate missing observation data.

Whereas planning (in a software engineering sense) and documentation are not major aspects of Tribeflame’s work, evaluation is prominent. This is often a significant feature of meetings at Tribeflame, as indicated in Figure 2.3. In addition, distinct evaluation sessions sometimes take place, shown in Figure 4.2. Thus, of the three major concerns of software engineering, evaluating seems to be the concept that is most useful for describing what is going on during the process observed, but it only applies to a part of Tribeflame’s work.

As we saw in Figure 2.10, playing other companies’ games during work hours is a frequently-occurring activity. It is hard to characterize this important activity within the conceptual framework of software engineering, as it clearly does not fit into any of the categories of architecture, design, coding, or testing. It could perhaps be perceived as a kind of research necessary for requirements specification. However, specification is supposed to be as complete as possible before starting the design work, and this does not fit well with the ongoing activity of game playing.

Some might say that it is unfair to try to analyse Tribeflame’s process with software engineering terms, as software engineering is specifically oriented toward large projects, and not small teams. Software engineering theory is useful in the right circumstances. In Chapter 5 (Safety critical programming) we will consider examples of software engineering theory being put to good use in practice. Nevertheless, as we have seen above, traditional software engineering theory is inadequate for explaining this example of a small team development process. Since 90 per cent of Finnish software companies are of a similar small size, this is a real challenge to the explanatory power of software engineering.1

From a research perspective, it is not necessarily a problem that software engineering theory might only be applicable to a minority of companies within the software industry.2 From a programming perspective, however, this can have serious consequences. Most programmers learn about software engineering during their education, but not so much about the limitations of software engineering. When presented with a real software process, many will unconsciously perceive it in terms of the software engineering theories they have learned, even when the process is not suited to software engineering analysis, as is the case in Tribeflame’s example. Not being aware of the limitations of software engineering theory then has the unfortunate effect of making the programmer apply the wrong mental tool to his task.

1 In 2010, 90% of Finnish software companies had 9 people or fewer. Rönkkö & Peltonen 2012. See note 2 (page for footnote 2).

2 Though it is of course a serious problem if the limitations of the theory are not clearly understood and presented.

4.1.2 Agile development

The diversity of Agile approaches makes it rather challenging to use Agile concepts for analysing a concrete process, for it is not given which of the Agile approaches should be used. It is immediately clear, however, that on a practical level, Tribeflame’s process corresponds only sporadically to Agile concepts.

To take one example: Tribeflame’s work corresponds to the Extreme Programming practice of placing all developers together in the same room, simply because Tribeflame has only one office room available. But there is no correspondence to the practice that all program code should be tested every day, as Tribeflame does not have an automated testing system in place, much less test cases for all of the code. This, of course, stems from the nature of their product – it is nearly impossible to design test cases that determine whether an interactive computer game is “correct”. Likewise, the practice of programmers coding together in pairs is not followed, as Tribeflame’s developers spend much more time working alone than in pairs. There are more practices in Extreme Programming, but it is clear that Tribeflame’s process does not resemble Extreme Programming to a significant extent.1

In another example, we can look at how well Tribeflame’s work corresponds to the Scrum rules. The three important roles in Scrum are the Product Owner, the ScrumMaster, and the Team. Tribeflame has neither Product Owner nor ScrumMaster. The Team, understood as everyone working in Tribeflame, is of course very important in Tribeflame; but it is not exactly the same as the Scrum conception of a Team. In Scrum, the Team has to be without internal hierarchy; in Tribeflame, Björn and Andreas, as the owners, have the formal decision-making authority, even if they seldom exercise their authority directly.

Those working at Tribeflame do not use the Scrum version of iterations (Sprints); they seldom explicitly prioritize their tasks, and they do not commit to a specific workload each month. Sprint reviews do not have an equivalent either, as there is rather little evaluation of the work process itself. Only once during the observation period did Tribeflame have a stand-up meeting that could be interpreted as something akin to the daily Scrum meeting.

Whereas the concrete rules and practices of Agile development do not correspond to Tribeflame’s process very well, the more abstract concepts of Agile fit much better. As an example, let us compare the process to the Scrum principles: transparency, inspection and adaption.

Scrum demands that the process is so completely transparent that it is visible at all times who is working on what, and that this is repeated verbally every day at the Scrum meeting. Tribeflame’s process is not quite as transparent as that. However, since the developers sit so close to each other and interact so frequently, they are generally well informed about what the others are doing, and they do not hesitate to ask each other what they are working on. Perhaps more importantly, the game they are developing is tested and played constantly, so that everyone knows the current state of the product. This creates a high level of transparency, since there are only a few aspects of the product whose state cannot be assessed by playing the game: namely integration with the distribution channel (Apple’s Game Center), and cross-platform support.

Inspection is closely linked to transparency. Inspection in Tribeflame is also performed by playing the game, both by the developers themselves and by external persons. In addition, there are evaluations (Figure 4.2) and frequent discussions (Figure 2.5) which often include aspects of inspection. That the company instituted daily meetings in the middle of the observation period gives evidence that inspection of the work process itself also happens.

Adaption is very prominent in the work process. There are no detailed, long-term plans; rather, the planning is done as the game progresses from week to week. Features are constantly taken up for discussion at meetings, and whenever a feature in the game is complete it is promptly evaluated in discussions and has an effect on further development. As mentioned above, daily meetings are added halfway through the observation; this shows that adaption is present at the process level, as well as the product level.

Thus, the principles of Scrum correspond well to Tribeflame’s process. The common values of Agile development, as expressed in the Agile manifesto, correspond partly to the process. We recall the Agile values, shown in the manifesto reproduced in Figure 3.7:

Regarding the first value, at Tribeflame, individuals and interactions are clearly much more important than processes and tools, as processes are seldom referred to, and tools are only referred to when necessary. Regarding the second value, Tribeflame’s product is always in the form of working software, and the company produces very little documentation in general, and no documentation that can be called comprehensive. Regarding the fourth value, the decision process at Tribeflame is dynamic and adaptive rather than planned in advance.

The third value is not applicable to Tribeflame. The company produces for a mass market of anonymous players, so they do not collaborate with customers or with representatives of customers in the sense that is meant in Agile development. Nor do they enter into contracts or negotiate them with customers: they have investors, but their role is not quite the same as that of a customer. This value therefore seems to reflect an aspect of Agile development that is absent in Tribeflame.

As we can see, many, but not all, of the values of Agile development correspond well to Tribeflame’s process. With one exception, the Agile concepts are well suited, in contrast to the concepts used by software engineering which, as we have seen, are in fundamental conflict with Tribeflame’s way of working.

However, though Agile concepts are generally compatible with Tribeflame’s process when used descriptively, they have serious deficiencies as analytical concepts. The reason for this is that even though the Agile concepts are based on a philosophical ethical system, as described in Section 3.2.5 (Work ethics), the concepts themselves are primarily part of a prescriptive system of software development. Agile methodologies are possible approaches to productive software development, but they are not well suited to analysing processes that are not Agile or intended to become Agile.

Thus, the Agile concepts offer us no help in explaining the differences we see between Agile processes and Tribeflame’s process. For example, Agile concepts cannot explain why the playing of other companies’ games is so important to Tribeflame. Agile thinking certainly leaves room for this activity, but it offers no guidance in determining what its function is.

Another example is the absence of a customer or customer representative in Tribeflame’s process. The customer (represented in Scrum by the Product Owner) is such a central part of Agile thinking that its absence in Tribeflame’s process is something of a mystery from an Agile perspective.

1 There are 13 primary practices and 11 corollary practices in Extreme Programming. Beck & Andres 2004.

4.1.3 Computer science

As we saw in Section 3.3 (Computer science), mainstream computer science perceives itself as a mix of applied mathematics and formal methods. During the observation period at Tribeflame, mathematics was applied in only two cases, both of which had to do with how the graphics should be moved around on the screen in the game, and used mathematics of a high school level. There were no cases where formal methods were applied, or could appropriately have been applied.

A common view of programming within computer science is that a program consists of algorithms and data structures. The task of the programmer is to divide the program into modules, then use the best algorithms he can find. Tribeflame, like any other software company, needs to select algorithms for its programs. However, it is not a top priority that the algorithms are the best possible – they merely have to be good enough.

As an example: before developing one of their games, the developers were worried whether the main algorithm was too inefficient to run on an iPad. They quickly developed a simple prototype of the algorithm and let it run with a few hundred objects, far more than would typically used in a real computer game. When this test proved successful, they proceeded with development without caring further about the efficiency of the algorithm. No mathematical analysis or advanced methods were employed apart from this simple but effective practical test.

Another common computer science view of programs is to regard them as computable functions. This means that there is some input and a mathematical rule that transforms it into output. This view does not correspond very well to the practice of Tribeflame either, for the reason that it is unknown what form the input and output should take for a computer game. If those working at Tribeflame spent their time figuring out how a game could be represented mathematically, they would not have time actually to make the game.

As we have seen, in computer science there is a pronounced orientation towards the machine, and not towards the uses to which it is put. This perspective is not consistent with the practice of Tribeflame. On one hand, the machine is central to the work, because without it there could be no computer games at all, and the limitations of what the people can do are dictated by the limitations of the machine. On the other hand, though the limitations of the machine are certainly present in everything they do, they are seldom discussed or addressed directly. The discourse at Tribeflame normally focuses not on the machine itself, but on the experience of using the machine. This is not a technical but a human discourse, and it takes place mostly in terms of human imagination and emotions.

If we look at the computer science perception of the work process involved in programming, we see that the correspondence with Tribeflame’s process is mixed. There is within computer science an emphasis on mathematical intellectual elegance in the work process. Since mathematics plays no big role in Tribeflame’s work, this emphasis is obviously lacking in their process. Computer science also emphasizes the individual in the process, almost to the point of becoming personal. Neither does this emphasis resonate with Tribeflame’s process, which is intensively social and cooperative.

On the other hand, computer science emphasizes that the details of a problem only becomes understood through actual programming. This corresponds well to Tribeflame’s process, which is essentially a continuous cycle of discussing ideas and then trying them out in practice: that is, programming them. There is also Naur’s view, that programming is essentially a process of achieving a certain kind of insight. This corresponds well with the ongoing knowledge building in Tribeflame, which we will examine in more detail in the next section.

4.2 Hermeneutical analysis

4.2.1 Short introduction to hermeneutics

Hermeneutical concept

Characteristics

Prejudice

Prejudice is a prerequisite for understanding – it can have either a positive or negative influence.

Authority

These are the sources of reason that are recognized as valid.

Received tradition

All understanding builds upon some kind of tradition, and carries this tradition onwards itself while also contributing to it.

Personal reverence

This is the basis for authority. Since understanding is done by persons, personal reverence is crucial.

Pre-understanding

This is the kind of factual understanding that is necessary for understanding, but leaves relatively little room for interpretation – for example to know the language of a text one wishes to read.

Understanding

In hermeneutical theory, understanding is productive and existential. Briefly put, this means that understanding has consequences.

Hermeneutical circle

A concept that expresses the relationship between, for example, part and whole, or between action and reflection.

Effective history

A concept that expresses the historical nature of knowledge and understanding.

Question

All interpretation and understanding is driven by some kind of question.

Horizon of
understanding

One’s horizon of understanding is the amount of things that are understandable given the present state of one’s knowledge and prejudice. Phenomena beyond the horizon of understanding appear meaningless.

Application

Since understanding has consequences, it is crucial to what end the understanding takes place. The intended application of an effort of understanding has an impact on the understanding itself.

Figure 4.3 – Some hermeneutical concepts used in the analysis of Tribeflame’s game development process.

Hermeneutics is a theory both of how understanding takes place and of what understanding is. In this section, some concepts from hermeneutics will be applied in an analysis of Tribeflame’s work process, in order to interpret what the developers do and to understand better why the work process takes the form that it does.

Figure 4.3 lists some key hermeneutical concepts that will be applied in the analysis, along with some very short explanations of the concepts. The use of each concept and its more precise meaning will become more clear in the analysis itself. The interested reader can find a more detailed explanation of hermeneutical theory in Chapter 9 (Understanding).

4.2.2 The work process

When we looked at Tribeflame’s process we noticed the rhythm inherent in the work. There is a continuous rhythmical shift between working at the individual desks in the periphery of the room, and coming together at the central table to have discussions. At the same time, the rhythmical shift is between working with concentration and alone, on one hand, and on the other hand talking, bantering, joking, and interacting with others. The work that is mostly done alone at individual desks is specific tasks. Through the tasks the game is slowly built. Each task amounts to doing something, trying something out, and getting experience when it is seen if and how it works. In the meetings the experience is discussed and reflected upon. The meetings provide afterthought, which again leads to ideas for new tasks that can be tried out.

Figure 4.4 – The hermeneutical circle depicts the relationship between tasks and meetings. Tasks are usually carried out alone and result in experience. In meetings the experience from the tasks is discussed and reflected upon. Meetings and tasks are mutually dependent.

The relationship between meetings and tasks is shown schematically in Figure 4.4 as a circle that leads from meetings to tasks, and back again from tasks to meetings. Meetings and tasks are dependent on each other. The meetings generate the ideas and plans for tasks that should be carried out. The tasks provide experience of what works and what does not, and serve as input to the meetings to make sure that the discussions are grounded in reality. It would be extremely inefficient to discuss and plan the whole game in detail before attempting to carry it out in practice; likewise, it would be unwise to make a whole game without stopping along the way to reflect on the progress.

This sort of mutual dependence is very common in hermeneutics, and is called the hermeneutical circle.1 The hermeneutical circle expresses that experience and reflection cannot be separated. Neither can be subordinate to the other, and they need to happen concurrently.

Because the hermeneutical circle is such a common phenomenon, it is often also recognized outside of hermeneutic theory, under another name. Donald Schön has analysed the practice of a range of modern professions: engineers, architects, managers, and so on. He writes that the professional oscillates between involvement and detachment, from a tentative adoption of strategy to eventual commitment:2 “The unique and uncertain situation comes to be understood through the attempt to change it, and changed through the attempt to understand it.” 3 We recognize here the structure of the hermeneutical circle as it is observed in Tribeflame.

Figure 4.5 – Over time, the hermeneutical circle between tasks and meetings results in better understanding. Whereas the process is very open in the beginning and decisions are relatively easy to undo, with time it becomes more and more tight and resistant to radical change.

In theory, this rhythmical, circular process goes on indefinitely. In practice, the game is deemed finished at some point. The meetings and tasks do not stay the same but lead to an improving understanding of the game being developed. Schematically, we can picture the relationship between tasks and meetings in the hermeneutical circle as time goes by as the spiral shown in Figure 4.5. The hermeneutical circle is still seen shifting from tasks to meetings and back again, but we also see that the process becomes more focused with time.

Initially, the process is very open. The available alternatives are large and visionary, and the chosen decisions are not clung to with great commitment. But as time passes and understanding deepens, decisions made in the past become increasingly costly to revise because time and resources have already been committed to them. Decisions are still up for discussion – the process is not rigid – but it is no longer so easy to undo them. The process has become more tight, and focused. Schön recognises the same gradual tightening of the professional process. He writes that the professional can always break open his chosen view, but that “This becomes more difficult to do as the process continues. His choices become more committing; his moves, more nearly irreversible.” 4

1 The hermeneutical circle depicted here shows the relationship between experience and reflection. The hermeneutical circle also appears between other concepts. The most common use of the hermeneutical circle is to describe the relationship between the part and the whole in a process of understanding: see Section 9.4 (The concept of understanding).

2  Schön 1983 p. 102.

3  Ibid. p. 132.

4  Ibid. p. 165.

4.2.3 Horizons of understanding

Tribeflame’s process is not simply a matter of planning, optimizing, or construction. It is primarily a process of understanding. At the outset, the developers do not fully understand the myriad details that together make up a successful game. As the work progresses, they slowly and gradually come to a fuller understanding of the central question of their work: what makes a game fun, and specifically, what makes the game we are working on right now fun?

The process of understanding does not start from scratch. Tribeflame’s team is composed of individuals with different and highly specialized competences. Matti and Kati are competent in the area of graphic art; Andreas, Mickie, and Fredrik in the area of programming. Björn is competent in the areas of business economy and programming. They all have a general understanding and personal experience of computer games. All this foundational knowledge and competence forms the pre-understanding that is the basis of the process of understanding. If Tribeflame’s developers did not have this pre-understanding, they would first have to acquire it before the process could begin of understanding the game they are developing.

The understanding process is a social process that takes place in meetings, discussions, and chat between the developers.1 As we have seen in Figure 2.8, “information sharing” in the sense that some information is simply delivered from one person to another is quite rare – the process of understanding is much more interactive. Nor is this primarily a decision-making process. Decisions are usually the outcome of discussions, but the discussions contain much more than the information and deliberations needed to make decisions. Sometimes, the decisions that are the result of a discussion are left unstated. As soon as the developers reach a common understanding, the consequences often become so clear to them that everyone agrees on the common direction.

So how can we characterize the content of the discussions, if it is neither information sharing nor explicit decision making? The developers seek to expand their understanding in the process. At the onset of a discussion, they have a certain knowledge and range of ideas that they are prepared to understand: their horizon of understanding. Through discussions they exchange facts, opinions, and viewpoints, and in that way expand their horizon. The process of understanding is a process of horizon fusion. When the developers’ horizons of understanding fuse, their understanding becomes larger – not by streamlining everyone’s opinion, but by expanding each individual’s horizon.

1 See Section 9.6 (Horizons of understanding).

4.2.4 Authority and tradition

Though the process of understanding is complex and difficult to describe in simple categories such as, for example, the software engineering phases, this does not mean that it is unstructured or haphazard. The process is strongly guided by authority in various forms. The final authority of decisions rests with the owners, Björn and Andreas. They share the responsibility for business decisions, while Björn has the overall product responsibility, and Andreas has the overall technical responsibility. The business decisions rarely impact upon the development process directly, and in this area they exercise their authority freely. Regarding the development, they rarely exercise their authority directly, as we saw in Chapter 2 (Programming practice), with Björn’s reluctance to impose a decision outside of the consensus process. It does happen, however. For example, Andreas has insisted that the programmers use shared pointers, a form of memory management.1

In their daily operation and management of business decisions, there is hardly any conflict between the two. The basis of the unproblematic sharing of responsibility and authority between them is their good relationship – the personal reverence they have toward each other. The authority they have over their employees is based partly on the formal economic relationship between employer and employee, and partly on the personal reverence the employees have for Björn and Andreas in Tribeflame’s small, tight-knit team.

Since Tribeflame’s process is primarily a consensus process, the dominating form of authority in discussions is not that of Björn and Andreas as employers. The work is a teamwork of understanding. Each individual has a specialized role and authority within his field of competence, but the work is not only a collaboration between experts where each has the final say in his or her area: rather, each individual can influence every area of the game and contributes to the overall direction of the development. The primary form of authority between the developers comes from the ability to argue convincingly.

Convincing arguments also rest on authority and, as mentioned above, not merely the authority of expertise. The most frequently invoked authority in Tribeflame’s discussions is that of other games. All the developers have a notion of what a good game should be like, as well as examples of games that they consider successful. An argument about how their own game should be is very often supported by a reference to another game that contains the feature in question, and thus the other game lends its success to the argument.

A few games carry so much authority that a reference to them can almost settle an argument. The most authoritative game is Angry Birds, the most successful tablet game in the world, which is also made by a Finnish company. Cut the Rope is also mentioned often, perhaps because its gameplay is somewhat similar to Tribeflame’s own game. Older games are also mentioned occasionally, for example The Incredible Machine from the 1990s.

The collected knowledge of the developers about how a game is supposed to be forms a tradition with which they became acquainted before they became involved with Tribeflame, and which continues to develop. Tribeflame’s games are built upon, and are a continuation of, this tradition of computer games.

The tradition of computer games is an important source of authority, and this is one reason why the Tribeflame developers spend so much time playing games and talking about them. Another is that the computer game tradition provides the yardstick with which the success of Tribeflame’s games is measured. As long as the developers do not have hard data on their game’s success in the form of sales figures or number of downloads, they have to compare their half-finished game to the existing tradition. For this reason, the fusion of horizons of understanding that goes on in the hermeneutical circle is not only a fusion of the horizons of the individual developers on the team; it is at the same time a fusion of the developers’ horizons and the horizon of tradition.

Thus there are at least two levels of fusion going on in the hermeneutical process of Tribeflame: a fusion of the different expertises that are needed to make a game, and a fusion with the tradition that sets the standard for what a good game is. With this notion, we can explain some aspects of Tribeflame’s process that were difficult to analyse satisfactorily with mainstream theories of programming. Tribeflame’s developers spend a significant amount of time playing games made by other companies (see Figure 2.10), which has the effect both of providing them with arguments and of making them more knowledgeable of the computer game tradition.

They also spend a significant amount of time playing their own game (see Figure 2.9). This has not only the function of finding errors in the programming and graphics, but also gives the developers a sense of whether their game is fun to play: that is, whether they are reaching their goal. Playing their own game is not only a technical activity that corrects the code: it is as much or more a way for the developers to get a sense of the practical application of their game. They are trying to put themselves in the place of the eventual player, and experience the game as a player would.

To experience the game as another person would requires that the developer can suspend his horizon of understanding temporarily, or else his own knowledge will prevent him from understanding the other person’s experience. For example, the developer must try to forget his knowledge of how a certain puzzle is meant to be solved, and approach the puzzle as if he saw the game for the first time, as an eventual player. This is a difficult task, and to make it easier the developers also have other people from outside the company play their game (see Figure 2.9).

The developers experience their game on the basis of prejudice. In hermeneutic theory, prejudice does not have the negative association that it does in everyday language. Rather, prejudice is a requirement for understanding – understanding simply cannot happen without prejudice, whether the prejudice is consciously known or not. Prejudice is simply the fundamental assumptions humans make in order to make sense of things.

However, prejudice can be either true or false. True prejudice will make understanding easier, while false prejudice will hinder understanding. To examine, and correct, prejudice is a central part of the process of understanding. The developers do this by playing their game themselves, but correcting one’s own prejudice is difficult precisely because it is the basis of understanding. This is an area where the developers cannot trust their own competence completely.

Therefore it is of great importance to them to have external people play their game. It provides them with an interpretation of the game that they have not made themselves, and that they can use to correct their prejudice and move along in the process of understanding.

1 The class shared_ptr of the Interprocess library from the Boost collection of libraries for C++ (2011).

4.2.5 Having fun

All the activities at Tribeflame, and the process of understanding that is analysed above, are directed by the application of their product: to play the game and have fun. From the use of shared pointers in the code to the choice of colour scheme for the graphics, and even to business decisions such as an eventual merger with another company – every decision has to be evaluated in the light of the overall goal of creating a game that is fun to play. The developers are conscious of this when they say that the code is just a means to reach a goal.1 This has an important consequence for programming research, in that it does not make sense to study programming in isolation from the context in which it appears. Computer game code cannot be understood without some knowledge of computer games.

The application, in the form of “having fun”, is what drives the activities, but the application in itself is not quite enough to explain the process of understanding fully. After all, if “fun” were completely defined by an existing computer game, all Tribeflame would have to do was to copy that game. All understanding is in essence driven by a question, and for Tribeflame the question is what “fun” actually means. The beginning of Tribeflame’s answer is that “fun” means entertainment.2 This might seem self-evident, but it is not. Consider, for example, that for Björn and Andreas themselves, “fun” means to work, among other things.3

Thus, in essence, Tribeflame’s business is a process of trying to answer the question of what it means to have fun, for the kind of person that would be inclined to play its game; and all of the company’s activities are somehow related to this question. Of course, those working at Tribeflame have to do many activities that do not directly contribute to answering this question, such as administration of the payroll. But the supporting activities are only necessary for success, not sufficient. They are not the critical factor that decides whether Tribeflame will succeed or not in competition with other competent companies.

In the analysis of Tribeflame with hermeneutical theory, we have seen the use of all the essential hermeneutical concepts apart from one: the concept of effective history. Effective history means to be conscious of the role of the knowledge one produces in a historical perspective. During the observation period, Andreas touches upon this question a single time when he muses on the fairness of charging money for computer games.4 His comment brings to mind the question of the moral justification for the game, and of the place of their product – entertainment – in the grander scheme of things. But his is only an offhand comment; an explicit consciousness of effective history is absent in Tribeflame’s process.

1 See note 2.

2 See note 3.

3 Andreas: “Is it already time for lunch?” Björn: “Yes, time passes quickly when you’re having fun.” Field diary, Monday 5th September 2011, 11:47.

4 See note 4.

4.2.6 Summary

Hermeneutical concept

Results

Prejudice

The developers’ ideas of what the game players will like. Corrected by external playtests.

Authority

Business decision authority rests with the owners. Other authority comes from convincing arguments, drawing from expertise and references to exemplary games.

Received tradition

An informal knowledge of computer games from life experience. Rests on a collection of authoritative games.

Personal reverence

The developers respect each other’s competence and personal authority.

Pre-understanding

Skills and expertise in programming and graphic design.

Understanding

A gradual process that slowly deepens over time, and that involves the whole company.

Hermeneutical circle

Manifest in the mutual dependency between tasks that bring experience, and meetings that reflect upon the experience.

Effective history

Largely absent.

Question

The question of what “fun” actually means. All activities relate to this.

Horizon of understanding

Expanded during discussions in the company. Developers’ horizons fuse with each other, and with computer game tradition.

Application

To make a game that is fun to play, in order to provide entertainment, so that the company can stay in business.

Figure 4.6 – A schematic summary of the principal results of analysing Tribeflame’s process with hermeneutical theory.

The process of Tribeflame can be explained as a hermeneutical process, which is shown in schematic form in Figure 4.6. The alternating activities of doing tasks and discussing them makes up a hermeneutical circle in which understanding is built through repetition. The increase in understanding takes the form of a fusion of horizons of understanding, both between the individual developers, and between the developers as a team and the outside world: their customers and competitors.

The hermeneutical process rests on a foundation of pre-understanding and prejudice. The pre-understanding is made up of the developers’ pre-existing skills and competences. The prejudice is made up of their ideas of what a computer game is supposed to be like, and what it means for it to be fun.

The process is guided by authority and tradition. Authority draws on various sources, and derives both from the expertise of the developers and from the tradition of computer games. The tradition is not ancient and static; rather it is living and constantly evolving. Thus, the newest games on the market are also part of tradition.

The process is directed by the goal of the computer game – its application. This is the reason for the process, and as such it influences all parts of the process. The reason – entertainment – is an encompassing perspective that must be kept in mind in order to understand the process and the product correctly.