Where Has The Time Gone?

My last entry is soon half a year ago. Too much happened meanwhile, most of it good, some of it less good, and some of it borders on miracles. But I’m just speaking off personal things. The state of the world is an entirely different story that I don’t want to cover neither here nor today. Least to say residing in a place bordering another place overtaken by a fascist administration does not improve mental health.

tl;dr

After handing in my third dissertation-relevant article to the journal, I spent my residency engaging with the research community at TAG 1. That included taking part in the Materializing Design research project 2, and setting up my fourth and last dissertation paper. For the latter I decided to build on what I learned in Montréal, which meant pivoting from a digital humanities approach to design research and research-creation. Generating knowledge through reflecting on creating and practice. I’ll try to lose a word or two about this later on. Besides that I tried to make the best out of being in Canada, including doing a field trip to Halifax.

What I would love to write about today is a first collection of thoughts that I had this week, on my thesis, the written part as well as the defense. I’m in the middle of the analysis for the current text, and I had a moment to reflect as well as figuring out…

…how I ended up here

I will have to write a synopsis as part of my dissertation. I understand it as a kind of mini-monograph, containing literature review, methodological explanations, but also an attempt to bring the four papers together. I couldn’t possibly know where I would end up, just an initial setting of the direction as well as a constant reflection on the status quo of the dissertation and where/how to continue. There is a lot of retroactive sense making involved, at least in my case, which is also what I will attempt in the following. We start with my initial article.

1. Observing the Coming of Age of Video Game Graphics: Exploring the historical development of video game graphics through distant viewing, hermeneutics and image clustering 3

The first paper was an attempt to understand the affordances of what is on-screen when playing a game. But that part got lost in the paper itself, since I wasn’t able to structure my methodological approach towards meaningful insight in that regard. I wanted to understand how a player makes sense of a game through the elements that the game offers. At that point I was missing a proper vocabulary and played around with Dominic Arsenault’s FAVR 4. But I ended up using distant viewing and visual clustering on a large dataset of video game screenshots, which is also what the paper finally focused on.

It was while working on this text that I came in contact with the work of Pierre-Yves Hurel 5 and Damien Hansen 6, and the concept of ludemes. Although I wasn’t able to fully comprehend everything about and around it, the concept quickly grew on me, and I was convinced, that it would allow me to follow the thread I lost in the first article. It was also around this time that I figured out that I have more creative freedom in my dissertation than initially believed, which made me focus on source code. I started to work on two co-authored texts. One with Pierre-Yves Hurel on the intersection of demo-scene and video game development, and another with Arno Görgen on Hartmut Rosa’s resonance theory 7 and video games. The latter became such a well grounded theoretical definition of ludemes (along the lines of my own working definition of the concept) that I wanted to include this article in my dissertation.

2. World-Relations Emerging from Play — How Ludemes Enable the Materialization of Meaning and Resonance in Video Games

While Arno approached resonance theory from Luhmann’s system theory, I added my take on ludemes as affordances, connecting developer intentions to player phenomenology. We then applied our theoretical grounding on our play-analysis of “Exit 8”, a rather simple but effective game 8.

Around here I fully pivoted towards being interested in how developer ideas and intentions manifest in source code. But I haven’t found a good way to go about that, although having myself fully immersed in critical code studies 9. Ludemes carried me along the way. I was obsessed with the idea, that ludemes must enable a translation from the rather abstract and obscure realm of code, into something playable. The playable concepts that video games developers and designers imagine must somehow take form in code, and must somehow then become a playable affordance. Pierre-Yves Hurel already makes this connection between playing and designing games and how this is manifesting in code. Damien Hansen on the other hand added the importance of taking player phenomenology into account, when analysing games.

Working with Arno on this second text brought a lot of this together. Playing the game and developing a ludemic vocabulary out of this auto-ethnographic approach helped me figure out an important piece of tracing this thread from developers to players. What if I search source code for such a vocabulary of affordances? This is what I did in my third article.

3. This Magic Moment of Translation

The title is taken from a thought that I had early on in my dissertation work.

There is this magic moment, when computational instructions result in a phenomenological experience in the user. This moment is a bridge between two fundamentally different systems with their own epistemologies and ontologies. In this process of generating meaningful software from machine instructions, there must be an element of translation.

It’s also an aspect I came across in the oral history interviews we made. Video game developers that went about it in the 1980s sometimes talked about how “magic” it felt, to be able to write arcane code and stuff happened on the television.

I wanted to highlight my fascination of this transfer of meaning between code and aesthetic (as in experience). Although I need to theorize the term translation some more. At the time I based a lot of my perspective on Berry’s Philosophy of Software, where he coins the concept of the computational image that exists in between those two domains. In this regard ludemes were not only pragmatic units of game-play that mediate between software and player, but also units that carry and translate semantic value, from developer to player.

In this third paper I attempted to outline these multiple layers through continuing the thread I started with Arno in the second paper. The methodological approach started with a play analysis, through which I built a ludemic vocabulary of affordances, which I then used to dig through the code. I essentially tried to locate the affordances that I encountered in play in source code. The main take away was that these ludemes are present and find-able in code, but that they are not as concrete as they are offered in play, but often dispersed all over the code base and building their own kind of assembled structures, cloud like, fog like, threads of mycelium.

Getting this third text published in a media archaeology journal helped me to cross the borders I was given by digital humanities and critical code studies. I submitted an abstract to a call for papers on a special issue on the intersection of media archaeology and digital humanities. Meanwhile, I worked on that article with Pierre-Yves Hurel, in which we also scratched the entangled media discourse. Being closer to media studies kind of opened me up to diverge from the given path on positioning myself within the digital humanities for my last paper, and instead chose a research-creation approach.

4. Ostrakinda

Part of that pivoting was motivated by telling myself, that I need to follow my own drive and interest in completing this dissertation. I had a rough plan laid out where to go with the last text, but I felt that I overrated another person’s opinion instead of listening to my own feelings or intuition. Career wise it would have made more sense to follow the path laid out, but I’m not here for the career, right? Right? The main inspiration to follow a practice-based approach came from my engagement with how things are done at TAG. Every PhD student works on a video or board game as part of their dissertation. The research project I was part of during my residency is invested in formalizing and researching capturing the knowledge that is embedded in design and development processes. Both aspects talked to me as practitioner, and made me reflect on programming as craft.

It started to make sense to me, to fill the last gap in the developer intentions to player phenomenology gap with the methodological approach spearheaded at TAG. In my research I worked with historic code until that point and leaned heavily on oral history interviews, and code as elicitation object. In my last case I was able to compare source code for two versions of the same game, programmed by the same person, but 30 years apart. This way of analytically comparing two different code bases was really insightful in figuring out how intentions materialize in code. But I was missing a proper archive or capture of the development process to see how coding practice and expressions or formation of ideas unfold over time. This is exactly what the Materializing Design Method (MDM) tries to tackle, to make the design knowledge that is embedded in a final product accessible through documenting the process. I was kind of sold on the idea…

I started to work on my own video game or video game fragments (as I like to call them) at the end of September 2025 and all the way through until the end of December. My base material was an interest in coin flips and my wish to expand that simple game mechanic into a game that could be interesting. Everything else, regarding game “design” and development happened along the way and is captured in a git repository 10. I called the game “Ostrakinda” which was a children’s game in Ancient Greece, where the kids flipped a black and white painted clamshell. The important part of the development was the documentation and journaling on several levels. I had my own Discord journal channel on the MDM server, and I also reflected on the process in a separate repository branch and the git commit messages. That is part of the MDM process. Development and reflective documentation is the first part of the process. The second is to analyse the archive through grounded theory.

There already have been some very promising results in that regard and a handful of published papers. The potential has been shown and that the whole process is based on a versioning system makes tons of sense to me. MDM simply packs the whole process very neatly and expands meaningful from there. What was missing in my humble opinion is working closer with the materiality of code and assets. Working on top or alongside a git repository also means that the material process is captured, although it is still largely inaccessible to people that don’t bring the needed skills in reading that material. But it’s a great setup for my own approach, in which I first develop a ludemic vocabulary, and go ludeme-hunting with it in the source code.

At the time of writing this journal entry I’m in the midst of a second pass of grounded theory coding my journal and documentation. And I must say that it was tremendously insightful. I have the chance to present and discuss my intermittent findings soon with the MDM research team, and I’m looking forward to that. If what I found holds up, it’s an excellent base for my last dissertation text. Without going into the details I can say that my findings of analysing my own reflecting documentation links very neatly up with the theory I’m working with. All that is left is doing the critical code dive, do the write-up, getting it accepted for publication, and then care about the synopsis.

After that, last step would be the…

Defense

The defense at my university is structured along three hypotheses that I will present and will be questioned about. The presentations are rather short, 5–10 Minutes if I remember quickly, but I also have to send them in written form to the PhD board in advance. Like this they can properly prepare their questions. I had the chance and motivation to ponder on these hypotheses. In the following I just want to word the current draft out, which usually helps me in further fermenting those thoughts (a bit like when you have to turn miso so it’s aerated and then ferments some more).

1. AI will never replace us (because programming is situated)

I choose to keep the tag line of this hypothesis short and contemporary. I’m not really interested in AI discourse, but it enables me to make a point. The core idea here is that programming isn’t an abstracted and purely cognitive act that can simply replaced by a machine. Proper programming is a situated and embodied activity, and AI can only ever just reproduce (copy) the results of that activity. This hypothesis is linked up with my findings from the current analysis for my fourth paper and backed by Naur’s Programming as Theory Building 11, Marino’s take on Kittler’s Code 12, the concepts of enaction 13 and affordances 14 and of course Haraway’s Situated Knowledge 15 and Berry’s Philosophy of Software 16 (specifically his concept of the computational image).

2. We were lucky that games haven’t been taken seriously (because it left us with a plethora of vernacular data, exactly what I needed for my research)

This point should open up into the differences between code written for business purposes and code written as a meaningful human activity. I recognize this difference, and in my research I look at the spectrum between programming as a means to and end and as a mode of expression and identity building as craft. This might somewhat be influenced by my mum being a ceramicist, and how I observed her designing and creating pottery for daily use, but also pieces of art, out of the same skills and know-how.

The initial hook is meant to take up our Ludens research project findings (or the historical fact), that there hasn’t been a video game industry in Switzerland, and that video games for the longest time haven’t been taken serious (as industry, as pastime, as art form, as medium). This means that a lot of these old games that we’re looking at have been created by people for whom this was important enough to invest their lifetime and energy into it, without reaping any direct professional benefits. In other words, it was a meaningful human activity for them. This comes up a lot in the interviews we did. This also means that the source code written has another importance then the one written in best-business practices, especially for the angle I take on programming and source code. I talked about this for example in presentations at UNIL or at the born-digital conference in London.

3. Source code is a record keeper of humanity worthy of its own discourse (since it captures culture and ideas in its own unique form)

This last hypothesis is playing into my critique of humanities not being able to really understand source code, beyond its face value. I believe I was able to sufficiently show that human ideas and intentions don’t only manifest on the level of labelling (variables, functions, classes, etc.) but mainly on the level of structure. That’s somewhat the core idea of my third paper. Ludemes (small memetic units of game play) manifest cloud like in source code, being assembled from several separated locations, but nonetheless being entangled and working together to form a ludeme (like pushing a block).

It’s exactly source code’s structuring of human thought that enables a specific kind of expression that isn’t present (or even possible) in any other media to that extend or scope. We can observe that with choose your own adventures, which exist in printed form. But the level of complexity of branching and dynamic adaption of game or game world itself hasn’t been reproduced in any other media (and they tried).

Synopsis

I’ll revisit this post when I start to write the synopsis for my dissertation. That text will attempt to glue the four papers together, trace the path I’ve taken, and also go into details regarding my data, methods, and the literature I base my research on. I’m really looking forward to writing the synopsis. I have the feeling that I often fall short in the papers to express core ideas and thoughts I’m having, and this is finally the moment to go into those.

See you in a few weeks.


  1. https://tag-milieux.ca/↩︎

  2. https://www.materializing.design/about↩︎

  3. https://openhumanitiesdata.metajnl.com/articles/10.5334/johd.251↩︎

  4. https://www.dominicarsenault.com/publications/the-game-favr-a-framework-for-the-analysis-of-visual-representation-in-video-games/↩︎

  5. https://orbi.uliege.be/handle/2268/247377↩︎

  6. https://books.openedition.org/pulg/18941↩︎

  7. https://link.springer.com/article/10.1186/s40711-023-00191-8↩︎

  8. https://en.wikipedia.org/wiki/The_Exit_8↩︎

  9. https://criticalcodestudies.com/↩︎

  10. https://codeberg.org/thgie/ostrakinda↩︎

  11. Naur, Peter. “Programming as Theory Building.” Microprocessing and Microprogramming 15, no. 5 (1985): 253–61. https://doi.org/10.1016/0165-6074(85)90032-8.↩︎

  12. Marino, Mark C. Critical Code Studies. Software Studies. The MIT Press, 2020.↩︎

  13. https://en.wikipedia.org/wiki/Enactivism↩︎

  14. https://en.wikipedia.org/wiki/Affordance↩︎

  15. Haraway, Donna. “Situated Knowledges: The Science Question in Feminism and the Privilege of Partial Perspective.” Feminist Studies 14, no. 3 (1988): 575. https://doi.org/10.2307/3178066.↩︎

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