There were 19 students who were actively taking the course and they produced 16 Twine games individually (3 did not complete the assignment in time). All groups completed the Deig task and created 8 games.

The Deig games have a playtime between 10 and 20 min. All games have meaningful gameplay in that there are clear goals for the player to achieve and there are consequences to the actions made. On average, a game has 300 dialog lines and involves 4 characters in addition to the protagonist. Figure 7 shows the logical model of an interactable in one of the produced games.

Fig. 7 An example of a logic model for an interactable Full size image

The Twine games produced in the module are more varied than the Deig games. A majority has a linear progression without any repeated passages. Figure 8 shows the simplest (left) and most complex (right) structure of the 16 games. Note that these are models for complete games while the model in Fig. 7 is for one of 20 interactables in that game.

Fig. 8 Examples on the structure of two produced Twine games Full size image

The produced prototyped were play-tested by primarily other students and instructors on the course. All prototypes were high fidelity with respect to the interactivity but there were differences in terms of visual design fidelity. The Twine prototypes were in general low fidelity with the major interaction through a text-based interface. These games were played in a web-browser on a desktop computer. These games resemble game which Friedhoff (2013) claims is typical in the Twine community. The Deig prototypes contained both graphics and audio and were tested in two different versions: initially these games were tested in the low-fidelity player of Deig on a desktop computer. The final games were tested in high fidelity versions on tablets. In this version, many graphics and audio elements have production quality. This type of prototype has been used extensively in play tests conducted in the production of Marvinter (University of Skövde 2017).

In total 16 students (7 females, 9 males) chose to participate in the study. The average age of subjects were 23 years. All eight Deig teams were represented in the material. One of the interview sessions was held with a single respondent, another with a team of three respondents. The remaining six sessions were held with two respondents. The duration of interviews ranged from 16 to 25 min (on average 20 min).

Themes

A general observation from the initial analysis of the material is that the eight groups gave a relatively uniform picture. Saturation was reached after approximately two-thirds of the groups. A number of recurring themes have been identified in the material. These themes can be coarsely clustered where the first four themes are more geared towards the comparison between Twine and Deig, while the last three themes are more general reflections. The first four concern: the author experience; modelling of structure; intuitiveness; and usability. The three remaining themes relate to: game dynamics; implications of audio-visual elements; and programming proficiency.

Author Experience

All teams expressed that there was a clear difference between Twine and Deig when it came to the freedom to write. Twine was perceived as more open where Deig is focused on a specific genre. As one subject put it: “… I want to create an adventure game… I don’t know how to program but I don’t give a shit about it, then [Deig] is the way to go” (S14). Deig was appreciated for the simplicity to write dialogs but several subjects expressed that they lacked the freedom to write long prosaic texts. Several subjects expressed that they found Deig to be more oriented towards games and Twine more towards creative writing. One subject stated that “… you use it in two completely different ways. This [Deig] was much more towards games but when I write Twine projects the feeling is much more that I try to write… something that could be in a book” (S7). This is in line with another subject who stated: “Twine is also somehow a bit more serious and this leads you to write some kind of short story, and you just write straight away and you know that the player will actually read this later” (S11).

At the same time, Deig was appreciated for its focus on dialog and several subjects found that it had helped them to develop their dialog writing skills. All groups reported that they felt that they had created a story in the Deig task. Some groups discussed how the authoring process had been affected by the nature of the tool and that it guided their creativity in certain directions. “The story came to life by itself in some way, I think” (S9).

Modelling of Structure

It was very clear from the interviews that Deig was perceived to be very intuitive for modelling the structure of the story and game. All groups expressed this. For example, when asked for spontaneous reactions to the Deig-exercise, one subject replied: “Actually, my first reaction to this program was: shit this is actually intuitive…” (S3). Another subject responded to the same question: “I found [Deig] to be super agile. Especially considering we have worked with Twine previously, which was much more complicated for creating trees and such things… so this has been a much easier tool to work with… to understand… to see the structure of everything…” (S7). Another subject was asked to describe the difference between Twine and Deig when it comes to modelling the logics of the game: “much easier in [Deig] I think… to have a passage with five, six if-statements becomes super complex [laugh] in Twine… and… in [Deig] it feels—simpler to keep track of” (S6).

A few respondents expressed that they were aware of the potential of Twine to create advanced game mechanics through scripting but they also expressed that it was a complex task: “… if you have an idea then it is possible to do it in Twine. It may not be easy. You should probably not do it in Twine. But you can [laugh]” (S14). Others argued that Deig emphasised a different kind of creative expression than Twine: “… you can focus more on how to structure… mechanics… compared to Twine and similar [programs] where the focus is much more on… like write and write…” (S5).

Half of the groups mentioned limitations in Deig with respect to modelling of structure. One subject found that Deig lacked timing-based mechanics; two others expressed concerns regarding the layout of flow-nodes when the graph grew big. Finally, one subject expressed concerns that logical disjunctions could not easily be expressed.

Intuitiveness

All groups expressed clearly that they appreciated the intuitive interface of Deig and that they quickly had learned to use it. One subject spontaneously stated that “… it feels as in each course we take we get some new program to learn… but this one [Deig] was surprisingly… it was surprisingly quick to learn.” (S3). This opinion was expressed by a large number of subjects. They also found Deig to be easy to work with and that they quickly could create prototypes: “It is possible to do something very quickly without any real programming experience” (S14). It was furthermore perceived to be even quicker than Twine: “… if you compare with like… the game that we actually made now and if you were to do it in Twine. So this was made in a couple of days” (S6). The same subject concluded: “… and if we had made it in Twine it would for sure take more than a week” (S6).

Finally, one clear trend in the material is that subjects enjoyed working and playing with Deig. This is an important quality of a game prototyping tool; it should support playfulness even in the construction phases. As one subject stated: “I enjoyed the program [Deig] very much, it was very fun to play in” and he continues “… I even sat and played with it in my spare time” (S9). It is likely that the perceived swiftness when modelling games in Deig contributes to the fun. Another contributing factor may also be the TTS, which makes it possible to hear the written dialog with different voices.

Usability

Many subjects reported that they lacked features in Deig that they were used to have in similar applications. This can be seen as usability issues. The most commonly mentioned missing feature was support for an undo-function. Other features that were mentioned were spell-checker, support for object renaming, support for snapping in the node graph and better integration between Deig and the exported Unity game with respect to text-layout. In most cases subjects explicitly remarked that they did not consider these limitations to cause any major obstacles: “… small sources of irritation that might grow. Nothing that is game breaking. Nothing that makes it impossible to continue… at least not that I have noticed, but sources of irritation, yes” (S12).

Game Dynamics

Game dynamics is the run-time behaviour that emerge when the game mechanics is acting on player input (Hunicke et al. 2004). A majority of the groups reported that the Deig assignment had given them an understanding for game dynamics. This is something that can be gained from working with Twine as well, but it appears that the characteristics of Deig made game dynamics more apparent to them. The comments regarding dynamics can be divided into two types. The first type of comments related to how introduction of game mechanics and user choice lead to complex logical models. When questioned on what they had learned from the Deig module, one subject stated: “I would say how quickly it gets complicated. How quickly it… kind of… a few choices make everything… extremely so much more… it not just… like writing a script for a movie where it’s just straight” (S7).

The second type of comments are insights on how to write for games where the dialog is affected by game mechanics. For example, one subject stated: “It is possible to develop Twine to be strongly… explorative too, but it is more… it is more complex to do it, while in [Deig] it comes naturally to have an explorative perspective on it” (S11). This subject uses the term explorative to characterize the freedom of players to give input to the system.

Another subject (S3) discussed the situation where a player returns to a character, that she has interacted with previously. The subject expressed that it made a huge difference to the player experience to have variations in the dialog. This could, for example, be to have three or four different greeting lines that the game alters between, when the player returns several times.

Play testing had an important role for subjects to realise the implications of game dynamics. The games had been subject for frequent testing, including internal play testing within the group as well as tests by instructors and other students: “… it is relatively quick to kind of go through what you have, and kind of test and test again, and then invite the others” (S16).

Implications of Audio-Visual Elements

One difference between Twine and Deig that was highlighted by all groups is the presence of graphical assets and multi-voiced TTS. There were remarks that this had both positive and negative implications to the creative process. The TTS was generally conceived to be constructive in the writing process in that it helped to analyse the length and quality of spoken lines. One subject explained: “… even if it sounds very cracked and robot-like. So you still notice if it is too much or if it is too slow or… ‘God this is boring to listen to.’” (S3). Several groups also reported that they were inspired by the characteristics of the voices and that it affected how they perceived their own characters: “… that the voice also affects how you write to that character, so I found it interesting to reflect on this kind of interaction” (S15). Although most comments regarding TTS were positive, some groups also expressed worries that it could have a negative impact on the writing and that there were limitations to it: “… it can also be a problem that… you tend to… it can be the reason many choose to do comedy games just because they laugh so much at it [the TTS]. It could be a bit harder to do more serious games in this manner.” (S12).

Several subjects noted that the presence of graphics made it unnecessary to write descriptions of the environment. It was appreciated that the graphics made it possible to quickly prototype a “real game”, but some subjects did not appreciate how the available graphics guided the stories towards a certain genre. At the same time, they were aware that the alternative would be to create their own graphical assets, which would be much more time consuming.

Programming Proficiency

All subjects participating in the study had taken a course in introductory programming and a course in game design and prototyping. Still, many subjects revealed an inability to analyse and discuss programming concepts. Boolean variables were frequently referred to as “true or false” and several subjects had problems characterizing the node graph and talked about it as “the grid” or as “dots”. Another example is a subject who, when talking about conditional dialog options, expressed: “If all conditions for showing is running at the same time, then you will never have the chance to trigger the condition to remove the alternative…” (S5). Although it may be possible to follow the line of argument, the concepts of running and triggering a condition are not well defined. This indicates a low programming proficiency. Despite this, all subjects stated that they felt that they mastered the mechanical modelling in Deig to a high degree. The subjects who exposed greater programming proficiency expressed that Twine allowed for flexible modelling of mechanics, but they also acknowledged that it may be a complex task to achieve, as exemplified in the quote from S14 in the section modelling of structure above.

Discussion

Both Twine and Deig were perceived to be useful tools for prototyping games but subjects expressed that they saw fundamental differences between them. Deig was perceived to be easier to learn and use for modelling of the mechanics of the game, while Twine offers more freedom for authoring text-centred interactive stories.

The group of students participating in the study had experience from a programming course and from a game design course using GameMaker: Studio. Still, most subjects revealed a limited familiarity with programming concepts and many of them expressed that they found it challenging to use the scripting functions in Twine. Even though Twine offers rich capabilities through scripting, it is in practice unavailable to game writers unless they have sufficient understanding of programming fundamentals. In Deig, all subjects were able to fully comprehend the mechanism to model game mechanics in the course of a week. As a consequence, many subjects reported that they had realised how complex interactive writing can be and that they had realised what the consequences can be when a player is given control of the order of actions. These are very important insights for game writers, and it is notable that many subjects had not got it from their previous work with Twine.

An interesting observation from the interviews is that the presence of graphics and audio, including TTS, affected the writing process, even in a prototyping stage. This emphasizes the importance of integrating the writing process with the other disciplines of game development. Writing in isolation may produce an expression that makes audio and graphics redundant or dissonant.

A general observation from the analysis of the interviews is that all groups made comparisons between Twine and Deig at an early stage of the interview, before they were explicitly asked to compare the tools. In several teams there was no need to explicitly ask for a comparison. This indicates that the similarities and differences identified were not far-fetched but came naturally from experience with both tools. The general impression from the interviews is that most subjects appreciated both Twine and Deig for different reasons.

Limitations

The results presented in this study are based on experiences from a relatively homogenous group of students. They do not represent actual game development practices. It is, however, important to note that that Deig has been used by developers with professional experience to produce games that have reached a large audience and been well perceived (Riis 2017). The results from the interviews resembles, to a large extent, anecdotal observations made during the development of these games. For example, the swift creation of prototypes made possible through Deig was found to be invaluable in the production of the 24 episodes of Marvinter. The majority of these episodes went through several major revisions and restructurings.

A limitation in the presented study is that the students had prior experience of using Twine when they approached Deig. This will affect the learning curve and their perception of Deig. The assignments for the respective tools also differed, which may impact on the comparison.

The interview was conducted by an instructor in the course, which may affect the respondents, even though they were clearly informed that the instructor had no role in the remaining examination of the course. The students were moreover aware that the researcher conducting the study had developed Deig. This may limit subject’s openness to express criticism. The choice of the peer small group interview format will however likely have increased the subjects’ openness to express their opinions and share their thoughts. This format has been found to have this effect when interviewing children (Mauthner 1997).