From Demleitner et. al, 2026

Intentions, Process, and Coin Flips

The initial spark for Ostrakinda was the first author’s wish to explore coin flipping as a game mechanic. Coin flipping is a simple way of deciding an either/or bet through randomization. It is a simple mechanic that has been applied to games and play in a plethora of cultures and eras. One of the earliest examples is a children’s game in ancient Greece, to which the video game owes its name¹. Being a simple act of play, while also culturally loaded, made coin flipping or coin flips a good starting point for a challenging exploration of this mechanic, and enabling reflection on the design process.

Ostrakinda_ came into existence over roughly four months, spanning initial ideation to refinement of a satisfactory prototype, which is shown in Figure 1. The game’s final archive ² contains a collection of inspirational references of coin flips in other games and cultures, reading notes on research articles and game developer lectures, an export of the designer’s personal Discord journal channel³, documentation on Ostrakinda’s mechanics ⁴, a reflexive journal ⁵, mappings and visualizations, screenshots and recordings of playtests, and finally eleven discernable prototypes ⁶ that materialized parts of the final game.

Creating an MDM archive or repository, that encompasses development material and documentation, concludes the first phase. The second focuses on analysing the archive through GT, a way of thinking and conceptualizing data through qualitative coding and emergent theorizing. Our approach to GT follows an iterative, coding-based grounded theory approach, most closely aligned with constructivist grounded theory ⁷, because codes and the codebook are progressively refined across multiple rounds of analysis.

Grounded Theory, and Material Readings

The initial stage of GT, known as open coding, requires analysis of research materials by way of labelling or coding according to patterns the researcher deems those materials to evidence⁸. Once open coding has concluded, codes are revisited in their capacity as theory framing vocabulary. They are then reprocessed through axial coding, where the researcher collates and collapses codes into larger categories, with a view towards preliminary theorization. Once labelling and axial coding are complete, the process can be started anew with an updated set of codes and a deeper understanding of the materials. This process is iterated until theory saturation has been reached, which is when there are diminished insights obtained from analytical passes.

The GT analysis of Ostrakinda involved two such passes of open and axial coding, and a third pass that focused on analysis of Ostrakinda’s materials. The first pass concentrated on open coding the textual artifacts in the MDM archive, namely, the reflective journals and commit message contents. As qualitative data coding results in the generation of significant secondary data, qualitative data analysis (QDA) software is often used by researchers to facilitate the coding process as well as organise code structures. Popular options for such software are MAXQDA, or NVivo⁹. For the analysis of Ostrakinda, the open-source QDA alternative QualCoder was chosen, shown in Figure 2.

During this pass, the researcher focused on distinguishing between material movements (modifications to materials) and immaterial movements (modifications to how the designer thought about or experienced the design process). Movement as a category was further experimented with through metaphorical extrapolation of different types of movements: walking in circles for moments in which the designer was stuck, pacing back and forth or meandering for different ways of exploring, or sprinting for clearly directed actions that get things done. This resulted in a re-conceptualization of the design process as intentional visiting, rather than an active doing.

The analysis of Ostrakinda needed to accommodate two additional needs, the first concerning Ostrakinda’s chronology. An MDM archive can encompass several types of documents linked to specific moments in time, like journals or the aforementioned messages attached to the snapshot. Coding a section of the research material in QualCoder does not automatically append an appropriate timestamp: this had to be achieved manually by adding dates to the codes, shown in Figure 3, which then enabled chronological sorting. As this step depended on a complete pass of coding the research material, it was done between the first and second coding passes.

The second aspect of researching the material development took place after the GT analysis. The aim was to trace what was developed, when, and to what extent in order to understand the impact those developments had on the design process. Concretely, this involved examining each prototype with respect to three dimensions: the period in which it was developed, the programming language or video game engine employed, and the specific manner in which the central mechanic of the coin flip was realized in each case. To do this, the analysis drew on three analytical lenses: the codebook, the reconstructed timeline, and a first attempt at theorization. The insights generated through this secondary material analysis were then fed back into the assembled timeline and brought into dialogue with the interim findings from the GT analysis, producing a set of emerging findings ¹⁰.

This last step of the analysis was informed by critical code studies ¹¹, which treats code not merely as a functional tool but as a sociocultural artifact worthy of study in its own right. Underlying this methodological choice is a theoretical premise drawn from the work of Peter Naur and David M. Berry, both of whom foreground the relationship between programming and cognition. Naur’s notion of programming as theory building ¹² suggests that code externalizes the mental models its author holds about a problem domain. From this perspective, studying and re-reading code amounts to reconstructing a way of thinking. Berry’s work on the cultural and critical dimensions of software ¹³ similarly argues that the choices made in writing code (including which abstractions are employed, which structures are favoured, and which solutions are reached for) are not purely technical but reflect and shape the programmer’s cognitive and conceptual engagement with the problem at hand. For a study concerned with a design process unfolding through iterative prototyping, this perspective made attending to the material and syntactic character of the code an analytically meaningful complement to the grounded theory approach: the prototypes were not just by-products of the process, but meaningful traces of thinking in and through the medium of programming.

Handling several dimensions of analysis (qualitative data analysis, process chronology, material movements) proved challenging, and the researcher had to augment the capacities of QualCoder with spreadsheets and hand-drawn timelines, as shown in Figure 4. Despite being specifically designed to support qualitative data analysis, numerous QDA platforms fall short in terms of facilitating work with materials that are born-digital ¹⁴.

Designer as Guest, towards Materials as Hosts

Our emergent theory concerning the development process of Ostrakinda is summarized as designer as guest. Although the notion of guest never explicitly appears in vivo in the archive materials, it is an apt characterization of the uncertainty and carefulness the designer experienced in relation to the practice of game design. We find ample evidence in the documentation on the struggles of creating an appealing video game as well as reflections on anxiety. Visiting was thus a fitting description of how this designer experienced their practice, because they did not feel at home.

While grappling with the theme of visiting, the researcher deemed visitor to be an inaccurate description of their engagement with the design materials at hand. Their engagement was not passive, as in visiting an art exhibition, but active, like a visiting guest appreciating and reciprocating in the experiences enabled by their host. The following quote by Donna Haraway on Vinciane Despret’s polite interest closely captures the mindset the designer inhabited while developing Ostrakinda:

In every sense, Despret’s cultivation of politeness is a curious practice. She trains her whole being, not just her imagination, in Arendt’s words, “to go visiting.” Visiting is not an easy practice; it demands the ability to find others actively interesting, even or especially others most people already claim to know all too completely, to ask questions that one’s interlocutors truly find interesting, to cultivate the wild virtue of curiosity, to retune one’s ability to sense and respond — and to do all this politely! ¹⁵

Sharing these findings from the analysis with the MDM research team led to the emergence of a secondary insight. Much of the reflective documentation of Ostrakinda was coded as retroactive sense making, of which the following excerpt, taken from the designer’s documentation, is an example:

Implementing the doubts¹⁶ today was really interesting. I didn’t really know where to attach it to. I wanted something that appeared a bit more spontaneously and not directly linked to an interaction. As in thoughts that might appear while just being. We can’t choose when these appear. And I wanted to have that in the game as well. So the doubts should not be attached to every single time I flip a coin, not even randomly if I flip a coin. But they should nonetheless appear when I’m on the desktop¹⁷ so they get a bit contextualised.

Retroactive sense making refers to the designer’s post hoc sense making of the consequences of material changes they had made. Interestingly, there was close to no actual documentation on the technical implementations they were reflecting on. Most often, new features or milestones were announced in single sentences, and only later expanded on and processed via retroactive sense making.

Bookending the researcher’s emergent theory of designer as guest, the MDM team proposed the addition of design materials as hosts. If design is a situated and embodied practice, then it can likewise take place as an encounter. This finding suggests that insights regarding design and development, i.e. a designer’s tacit knowledge, exist as a by-product of a designer interacting with their materials. This position is supported by design research theory ¹⁸, new feminist materialism ¹⁹, thing theory ²⁰, as well as writing on affordances and enactivism ²¹.

---

Footnotes

1. Ostrakinda has children flip a shell, painted white on one side, black on the other. While the shell is mid-air, the child flipping it will need to call the outcome. Depending on the resulting side of the shell and the bet, the child’s group is either hunter or hunted in a game of tag. ²² ↩

2. thgie. 2025. Ostrakinda. Codeberg.org. https://codeberg.org/thgie/ostrakinda ↩

3. In an experimental phase, each MDM research project member cultivated their own Discord channel journal to entangle documentation, micro blogging, and communication with other team members. ↩

4. thgie. 2025. Ostrakinda/Notes/Coin Betting Mechanic.Md at Process. Codeberg.org. https://codeberg.org//thgie/ostrakinda/src/branch/process/notes/ Coin%20Betting%20Mechanic.md ↩

5. thgie. 2025. Ostrakinda/Journal.Md at Process. Codeberg.org. https://codeberg. org//thgie/ostrakinda/src/branch/process/journal.md ↩

6. thgie. 2025. Ostrakinda/Prototypes at Analysis. Codeberg.org. https://codeberg.org/thgie/ostrakinda/src/branch/analysis/prototypes ↩

7. Savithiri Ratnapalan. 2019. Qualitative Approaches. 65, 9 (2019), 667–668. pubmed:31515317 https://pmc.ncbi.nlm.nih.gov/articles/PMC6741812/ ↩

8. Not all qualitative coding approaches include such a stage: thematic analysis, for instance, makes use of labels or codes that may be predefined in code books. ↩

9. See https://www.maxqda.com and https://lumivero.com/products/nvivo , accessed 27 March, 2026 ↩

10. The documentation of the analysis process, as well as the data that was produced through grounded theory can be accessed at https://codeberg.org/thgie/ostrakinda/src/branch/analysis, accessed 27 March, 2026 ↩

11. Mark C. Marino. 2020. Critical Code Studies. The MIT Press ↩

12. Peter Naur. 1985. Programming as Theory Building. 15, 5 (1985), 253–261. doi:10.1016/0165- 6074(85)90032- 8 ↩

13. David M. Berry. 2015. The Philosophy of Software: Code and Mediation in the Digital Age. Palgrave Macmillan. ↩

14. Enric Granzotto Llagostera, Rilla Khaled, and Kalervo Sinervo. 2025. Tracing Research Through Design with Ponte: Bridging Game Development Repositories and Qualitative Research Tools. In Proceedings of the 20th International Conference on the Foundations of Digital Games (New York, NY, USA, 2025-05-09) (FDG ’25). Association for Computing Machinery, 1–10. doi:10.1145/3723498.3723821 ↩

15. Donna Jeanne Haraway. 2016. Staying with the Trouble: Making Kin in the Chthulucene. Duke University Press. ↩

16. Doubts in this case is referring to a mechanic within the video game. ↩

17. Desktop is a place the player can go to within Ostrakinda. ↩

18. Andy Dearden. 2006. Designing as a Conversation with Digital Materials. 27, 3 (2006), 399–421. doi:10.1016/j.destud.2005.11.004 ↩

19. Laura Forlano. 2017. Posthumanism and Design. 3, 1 (2017), 16–29. doi:10.1016/j. sheji.2017.08.001 ↩

20. Bill Brown. 2001. Thing Theory. 28, 1 (2001), 1–22. jstor:1344258 https://www. jstor.org/stable/1344258 ↩

21. Marta Jorba and Pablo López-Silva. 2024. Mind in Action: Expanding the Concept of Affordance. 37, 7 (2024), 1579–1589. doi:10.1080/09515089.2024.2365554 ↩

22. William Smith. 2013. A Dictionary of Greek and Roman Antiquities (1 ed.). Cambridge University Press. doi:10.1017/CBO9781139794602 ↩