Before starting anything, my intentions feel like they're in a superposition. It's a lot, at the same time, and as soon as somebody asks me, I can deliver one version of it. That's not really helping if I have to call the shots. So I was thinking of just rambling for a while¹.

Long story short, I'm interested in people doing designerly or creative stuff with programming and code. And than I'm interested in how these encoded intentions unfold again into something people experience. One of the reasons why I’m so fascinated by this magical moment of translation² from source code to a user/player experience, is because I actually understand the technical aspects of the process. I’m not wondering because I don’t know, I’m wondering because I do know and still don’t understand how this translation can come into being.

I dealt with this problem now for a while and always stuck to theoretical or analytical inquiries. Along the way I encountered other fundamental problems that I had to deal with, for example how critical code studies (CCS) usually resort to surface readings of code. But that doesn't do code justice. Source code is mostly treated as a text in CCS, which means that there’s a lot of focus on the content. But it is also a structure, it has form. And it's structure or form that is under represented in CCS but Is essential to understanding source code, imho.

But I'm still staying in the abstract with those thoughts and I really, really want to be more practical about this. I had planned to dedicate my fourth and last dissertation paper to another variant or perspective of my third paper. But it just doesn't feel right. It doesn't feel like me or how I do things. I'm a practitioner. So I need to figure out how to pivot my research approach and translate my translation studies into research creation.

My third paper was about trying to figure out how this process of translation from one side of the coin to the other works in practice. How can quasi-mathematical descriptions of intentions become player experiences? Two completely different aspects of the same thing, the game. And somehow this must be encoded and visible in the source code. I'm not sure I can make others understand my fascination for this problem? I definitely need to work on making this explainable. I approached this backwards in that paper. Doing a play analysis first, creating a vocabulary of affordances from it, and engaging with the source code through these. That enabled to show me how the developers intentions are simply mapped into a handful of instructions that can be read line by line, but that they are structurally embedded in the code. Ludemes (the affordances) are dispersed all over the codebase, nonlinear, modular, more like clouds or the entangled root system of a forest.

Traditionally, ludemes are thought of as building blocks, maybe a bit like lego. But that is an oversimplification when look at this from the perspective of codes. Even the simplest programming paradigms quickly become nonlinear and modular when they try to describe some real world complexities.

I quickly want to capture another thought that just arose again. One of the larger driving forces behind this research is my conviction that the way software is rooted in programming, fundamentally structures the way we learn to access the world. It's basically what Bogost argues about in Persuasive Games and his take on procedural rhetoric, but pulled further down into digital materiality. The way we design and create born-digital artefacts, the material we can apply and form into software or games, structures our access to the world. Now combine that with the fact that video game studies have actually very little real access or understanding how digital materiality forms their objects and subjects of research. But that is definitely not something I can tackle here.

Enough rambling, yet?

Becoming Practical

I don't have a research question with a socio-cultural connotation, but maybe that would help. But maybe then it also would go besides my actual research interests. I don't know how to decide what kind of game to design/develop for this case. But I'm also mostly interested in documenting my process of designing/developing and especially conceptualising and encoding. So anything that creates some starting constraints could help the process. I was thinking about using a recent minor rabbit hole for this: 🪙 coin flips

I'm not sure how I ended up with looking into 🪙 coin flips and collecting stuff over at are.na, but I think it had something to do with searching for simple game mechanics.

On one hand we have coin flips as representations of binary systems/notation, which pairs up nicely with digital technology somehow. There is an immediate link to the i ching, an ancient Chinese divination method. There are 64 hexagrams, and to draw one of them, it was common to throw sticks or do 🪙 coin flips. This is grounded in cleromancy, divination by throwing stuff. Which connects to the 🪙 coin boys, a meme about kids that let the 🪙 coin decide about everything. "Live by the coin, die by the coin.", their motto, makes their approach to cleromancy rather nihilistic.

🪙 coins. Randomness and fate, mechanics and narration.

I do have a hunch that sticking to coin flips could also yield some interesting insights into the inventiveness and playfulness when creating games. And maybe that could be the socio-cultural aspects that I'm exploring here.

Now let's try to bring all of this into a first 'explanatory motivation statement'³.

What

I'm looking into the "magical moment of translation" where encoded intentions in source code become player experiences. I want to focus on understanding how designerly intentions by programmers become encoded in programming structures and how these then translate into meaningful player interactions, emotions, and experiences (phenomenology). Specifically, I research how ==ludemes== (a game's affordances) are structurally embedded throughout codebases in nonlinear, modular, entangled, and cloud-like distribution patterns rather than as simple linear one-to-one building blocks. This should highlight, how thought and code shape each other.

Gap

My work addresses a fundamental gap in critical code studies, which typically treats source code as text while being unable to dig its structural and formal dimensions. Code is not just content. It is also structure (architecture), form, and process that fundamentally shapes how we access and interact with the world. Building on Bogost's procedural rhetoric, I argue that the material constraints and possibilities of programming and code structure our relationship with born-digital artifacts in ways that game studies and digital humanities have yet to really understand. This also means, that digital materiality fundamental shapes how we can access the world at large through didactics that are inherent to software ontologies. Without grasping how technical constraints operate during the translation from developer intention to player experience, we cannot fully comprehend how digital materiality shapes meaning-making and cultural production.

How

After doing mostly theoretical analysis, I am pivoting toward research creation as a more appropriate approach (for myself) to understanding code-to-experience translation. As a practitioner, I will engage with this process from the doing-things side, documenting how design intentions become structurally embedded in source code during development.

I propose using coin flips as a constraining framework for game development, which works across multiple vectors: technically (embodying binary systems fundamental to digital technology), culturally (revealing tensions between randomness and agency), and creatively (demonstrating how simple constraints can generate complex experiential possibilities). Through this approach, I attempt to build a thread between a theoretical understanding of procedural systems with practical knowledge of how they come into being.

I've spent some moments to look what kind of coin flip based practises exist and found some inspiration in that. We've got the classic coin flip where randomness (or fate) decides on an outcome. That can be a simply decision but also set the rules, for example which team of tag chases the other (which was the case in the Greek childsplay ostrakinda). The Australians increased the odds with Two-up, where two instead of one coin where flipped. This is cool because now we have three different outcomes (heads up, tails, up, both up) and it seems to be quite the thing over there. Than we've got pitching pennies where coins have to be thrown as close to as wall as possible, which seemed to be a popular gambling pastime in some places. And lastly we have Pogs, or the milk caps game, where coin-shaped caps are placed on the ground and pounced upon with a slammer. The game actually existed as a close variant in the Edo period in Japan as Menko (cards and slammers look really beautiful).

Pitching pennies is the only one that involves some skill that can be honed. I'm sure Pogs players have some arcane ways of favouring certain outcomes, but that most likely also just boils down to luck. Which is what I want to look into next: randomness. In the end, coin flip mechanics boil down to create one of the simplest random outcode, either this or that, and then make us react to this. For some it's fun (I won), for others fate (I Ching), and for some it can even be psychological (making decisions).

Creating random outcomes is a large and to some extend interesting topic in computing. Since a computer does math, and everything is predetermined, it actually is not able to create true randomness without external input. That leads to some really funny approaches. There is for example Lavarand ! "The system operates by digitizing the chaotic patterns of warm wax blobs oozing inside an array of lava lamps." Than we have this fantastic project that creates randomness by measuring the radioactivity of bananas and create random numbers from what the system observes.

Most modern programming languages abstract this fact away and hide pseudo random numbers generators (PRNG) behind something as convenient as Math.random(). Low-level languages are a bit more honest about this. Here is a (rather unelegant) PNRG I needed to write to make this work in assembly

.DateTime/second DEI2 .counter LDZ2 MUL2 #1234 MUL2 ADD #0f DIVk MUL SUB

It involves taking the time and multiplying it with a counter that is iterated every frame and then doing some basic math on it to make a bit more random and than reduce it back to either one or the other outcome. That's kind of cool and it worked as intended. I created a cute little generative graphic with it. But looking at the graphic I'm now thinking about how randomness is implemented and how it is perceived. And how my perception changes once I know that it is not true randomness. When is something perceived as random? Or how is random interpreted if we nonetheless observe meaningful patterns (imagine a Tarot spread for example, or I Ching).

The cute generative graphics thingy: https://post.lurk.org/@thgie/115136619493889494

Had a blast play-testing the Q-Up demo and analysing Unfair Flips (thanks L and E 💖 ).

I spent an hour flipping coins in *Unfair Flips, every 1-2 seconds on average, amounting to 2954 flips. I closed my eyes a little towards the end and almost missed the dramatic build-up of having 10 successful coin flips in a row. The game let's you improve the probability of having a successful coin flip, but you start out at 20%. I made it up to 55% and at that point I would have had to spent hours to get to 60% ... or be incredibly lucky. Which I was. I was expecting that it's a bit more evened out to have failed and successful flips. If I calculate that right, the probability of this happening is 0.55^10 is 0.00253 and means a 0.252% chance of that event happening.

The game is really a good experience of probability and they also play with that notion in some messages that float by. I went through all kinds of emotions during play. From bored to anger to excitement and despair. But it needed some dedication to finish. There is not much to hold onto except some self-hatred or extreme boredom. I see the game as a great example of the importance of attaching existential meaning to coin flips in order to profit from this mechanic.

Which is not what Q-Up did. It says to revolve around coin flips, but the actual core mechanic is a skill grid, where main- and support-skills are set up in a way to trigger chain reactions. The chains can be trigger either through failed or successful coin flips, or during flipping. During gameplay the coin flip actually completely retreats into the background is a mere aesthetical application in order to see which way the chains on the skill grid trigger.

Otherwise the demo is already super engaging and I could very well imagine playing the final version. It's mildly addictive, in a Balatro kind of way. And thinking through the skill grid and figuring out great combos that work either way was fun, if you're into stat maxing. But definitely the coin flipping vibes that I'm searching for.

A thread that emerged from bits and pieces of discussion with RK in the Discord journal is anxiety and uncertainty and it links well with my initial thoughts on coin flips. Here is a quote from RK

I’m currently reading Algorithms to Live By: The Computer Science of human decisions and it is exactly about how humans approach uncertainty and how equivalent problems are solved computationally (with the implication that we should all spend more time thinking about algorithmic efficiency in our lives!)

Uncertainty is most definitely a core ludeme for all kinds of games. Not knowing the outcome is an essential driver of engaging with games and play. Game design than is about creating ludo-narrative situations in which uncertainty can be approached through different ways (cognitive, skill-based, luck, and so on). That fits with my working definition of games, in the context of my dissertation.

Games are an aesthetic practice with its own boundaries of time and space that enables its participants the playful and experimental encounter with rules and constraints.

Anxiety on the other hand is a way to react to uncertainty. Uncertainty can trigger anxiety, but anxiety also amplifies the perception of uncertainty. Being affected somewhat by anxiety (most likely learned through untreated ADHD) I see a nice entanglement emerging here.

• Coin flips as devices that can only be either/or,
• although the outcome is uncertain before a flip.
• There is a tension between calculated and perceived probability,
• which opens up the tension between computationality and anxiety.
• And since coin flips are worthless without any meaning attached to them,
• narratives need to be woven throughout and around this mechanic.

I need to follow the uncertainty and anxiety arc, especially since this also allows me to go into personal matters. Also, Ed made a flippable Adricoin, so that's cool.

Coming back from two utterly carefree weeks of vacation, I'm met with a lot of doubts. From experience I know that these fade to the background once I'm on it again, but in the spirit of openness I want to have these recorded in my journal.

I see myself (identify) as a programmer and program solver, and not really as a designer or creative practitioner, let alone a game designer. Of course designers are problem solvers and programmers are creative. I guess what I want to say is that I'm getting motivation from having problems relatively clearly laid out and being able to work towards a solution. But I'm not having a problem right now. And I'm having doubts about what I'm even doing here, with this game project, with this article, with this residency? There is a lot more to this but I'm not finding the right words right now and a lot of thoughts are floating around in my thinking thing.

Guess it's time for a Auslegeordnung (a visualizing spread of the inventory in order to get an overview and being able to see relations, gaps and patterns). Maybe that'll clear my head.

During the Auslegeordnung I figured that I forgot to document some readings I did on the topic of uncertainty. I added the extracts of these to the repository and the mapping. Looking at the visualisation I don't see a larger problem, something that seems to carry societal relevance. But I do see that I'm missing some story here, some world building.

I have a gut feeling that I could use a little setup to test some narrative situations. Just a person walking around doing coin flips and handling stuff this way. Maybe a rough sketch with bitsy?

😱👻💀🎃 It's Halloween and time for reflection. The goal of this week was to have a working Unfair Flips re/demake in bitsy. That I achieved and I'm left with many questions.

The first emerged out of doubt. What am I actually doing here? This question is insofar valid, because I'm not a game designer. I have a profound interest in games, but not necessarily in game making, even though I'm identifying as a programmer. My lack of experience and the fact that this is part of my dissertation launched me into a lot of critical self-examination. Haven't resolved this yet (if ever) but were able to put it on hold by telling myself, that having doubts can also be a good thing. As in leaving my comfort zone. I'm used to fix concrete problems, not create (as in being creative) out of myself. I'm just not used to that and voicing myself always makes me uncomfortable.

Another question is regarding the aesthetics. What should my game actually work and feel like? Working with bitsy limits working on or with graphics massively, but it doesn't make it easier. I know, that that will also take some time to realise. Maybe I will enjoy trying to materialise my intentions and ideas into little 8x8 pixel sprites. I have a fondness for illustration, but haven't found the time nor energy to get back into it. So this might be a chance. But I should definitely study some bitsy games on how they realised games spaces. And I haven't even begun to think about sound...

Implementing the Unfair Flips mechanics in bitsy (or bipsi, a bitsy clone, but I will continue to say bitsy, because it's a drop in for that kind of game) took me around 2h and the rest of the week I worked on narration. I was mainly driven by the questions how and why narration could/should be implemented, since apparently Unfair Flips does very well without much of that. But I don't want the game to resolve around just coin flips. I want to us coin flips to tell a story that links to larger topics of fate, decision, and cleromancy. So this adds another layer of complexities to manage an balance. Unfair Flips works well, but if I add narrative now, does that interfere with game play?

Answering that last question involved connecting the larger topics around coin flips lore to more personal subjects of ADHD and anxiety. That might be limiting the appeal of the game, but it also works great with the bitsy style and community. Bitsy is a common goto for a lot of game makers on itch if they want to tell personal stories. There is something innocence and naivety in that engine, enabling some kind of expression that would be tougher to realise in other formats. My idea was to pick up personal experiences that could be added to the game, like struggling to do things, procrastination, difficulty with decisions or administrative tasks, and so on. The key core mechanic that would tie in that narration would be time as a ressource, which is depleted by doing activities. I'm asking myself, how and why time as a ressource could be an effective game mechanic, besides a basic takeaway that one can't do all the activities. Not sure if that's interesting enough.

I did a small mapping on narration in "Why would anybody play that game?". The visualisation is growing a lot and I think I already have to many moving parts. So for next week, I want to concentrate on making a tiny room where I can do one more activity besides playing Unfair Flips. That would help me to figure out if my ideas and intentions work out (memo: might need to update the why file).

I'm having a lot of fun to tinker with the Unfair Flips demake, now that I have everything setup in bitsy (bipsi actually). There is a light narrative in place. You're a person in a room and you can interact with different things, like staring out the window, overwatering the plant (it can die), or of course play Unfair Flips. But the title of the game is now "Why do we play games, actually?" because I want to highlight the question of passing time through that framing. For example, the plant can also die if you don't check in often enough. But, for now there is no winning condition.

Not sure where to go from here. I will certainly continue a bit building that little setup and maybe I learn another thing or two, but I also deviated from concentrating on coin flips as a core mechanic. I was wondering if I should try some puzzling stuff, but that would open a whole new box, I guess. Unfair Flips became just one of the things to do right now, kind of a sub-mechanic, or a sidequest. But since there is no winning condition, there is also no good reason to apply coin flips towards a goal or game loop.

I'm usually full of ideas and thoughts, but I'm having a hard time making things concrete. The question would be, what do I actually want to say with this game? And following, how do I get there?

Added doubts today. That was the last bit for the current prototype iteration.

These popup after the player did a certain amount of flips, 50 for now, but amount and appearance rhythm are not play tested, just roughly implemented. Can't tell if they have the intended effect yet. I also believe that the doubts are rather on the depressive end right now.

• Does this lead anywhere?
• Should I check if my plant is doing alright?
• My place looks messy, maybe some cleaning is in order?
• What am I actually doing here?
• Did I take my meds today?
• Where is everybody?
• Is this really where I want to be?
• Why does my place never feel like home?
• Should I have taken that other job instead?
• When was the last time I truly relaxed?
• Do I even talk to anyone outside of work anymore?
• Is this what growing up was supposed to feel like?
• Why do I keep putting off everything that matters?

Together with the prompts from the window the overall tone is rather bleak, even despair-ish, and that's clearly not my wish here. But I leave it at this and will see if anybody wants to have a got at it and tell me how they felt about it. Nonetheless, going from nothing, to flipping a coin with a cat, to having this little setup of running around an apartment and interacting with it, even going as far as playing Unfair Flips on a desktop within a week is pretty cool I have to say. I learned a lot in the process and have open questions I want to explore next, especially regarding mechanics.

Bipsi has a bit of a special structure. Usually when writing javascript I would have my files that I include somewhere. The script then cares about connecting to the elements on screen. In bipsi the scripts are attached directly to events, which are the interactive elements of the game, be it the avatar or the things one can interact with, like exits or objects. There is a setup event that can carry initial code. I used that one to have a state object with which I can keep track of the overall game state. I can than get access to it in the scripts in the other objects by calling it. This structure instantly led to a separation of concerns and I structured and organised my code and files in accordance to the interactive objects. Or in other words, the bipsi system automatically pushed me to organise my code around ludemes. Which is kind of an interesting observation. Do game-making libraries, frameworks, engines and tools inherently structure design thinking towards game-making? Of course they do, that's their job, isn't it. But to what extend is this rooted in digital ontology?

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. Doubts should appear when attempting to play the game. I ended up attaching the doubts to the avatar by doing a regular check (every 5 seconds) in which room we are and if we're on the desktop there is a 50/50 chance that a doubt appears. I also styled the doubt text dialogue slightly different to differentiate those from the regular dialogue windows.

It was really interesting for me to realise how the phenomenology of doubts need a different approach to being implemented in code. That's definitely a cool takeaway from this week.

Trying to bring some things together. After implementing a small scenario in bitsy last week I figured that I don't have any core mechanics that motivate play. It's just walking around a flat and interacting with things, and maybe playing some Unfair Flips. So I rowed back and tried to have a good look at coin flips as mechanics.

To warm up to that challenge I started reading this overview by Alexander Brazie, but stopped after he dropped this truth bomb.

Rolling dice is not a mechanic, even though it’s very often confused for one. Dice are just an expression of uncertainty. Rolling dice (or flipping a coin or randomly generating a number) just adds variance to the result of a mechanic.

Of course he is right, kind of. A coin flip in itself is utterly boring. It needs to be attached to something, to some outcome that matters. I think I wrote about that before. The question was then, what to attach a coin flip to, without narrative. How can a coin flip be fun as just a mechanic. Funnily Mo and I had the same thought. In Yahtzee, the variance is kind of the mechanic. And you attach it to a bet. The bet is, that you will be able to achieve a certain pattern within three throws of five dice. If you make it, you get points, and if not, you'll make less points or none at all in a worst case scenario. But the system is set up to be forgiving in the beginning. Which makes it slightly strategic.

A coin flip also starts with a bet towards an outcome. The variance is just drastically reduced and it's kind of less fun in the long run. One coin flip is really fun for more serious outcomes. But they are not very fun if you have to do them over and over again and every single time you have a 50/50 chance of winning or loosing. In the long run it just evens out. And that's where Australia's two-up comes in.

In two-up there are four different outcomes, heads-heads, tails-tails and heads-tails (two times). The first two have a 25% of coming up, and heads-tails a 50%. If a player has heads-heads they win, if they have heads-tails they can continue playing and they loose with tails-tails. This little setup, this slight increase of complexity and variance is seemingly enough to have a quasi religious devoted community, that continued to play the game despite being ruled illegal.

So, I sat down this week and did some calculations and tests with odds. I tried to bring together three things: Yahtzee, two-up and the memory of an idea that got drowned in my busy mind, coins as actions and energy at the same time. I figured out that in no constellation of coins is there ever a higher chance of having a 50% chance of winning. It just goes down. In two-up the lowest chance winning (with heads-heads or tails-tails) are 25%. In three-up the lowest chance of winning can be 12.5% with heads-heads-heads (or three times tails). So I was still stuck with the 50/50 thing until I came up with a scheme that would allow a coin to be bet on either. A bit like in Roulette, when you choose black or red, but you bet on both at the same time. That doesn't make much sense, except for if the wins are really low and the looses are higher then usual. You can play really safe, but you can loose extra.

So in a two-up I could either bet heads-heads or tails-tails with 25% chance of winning each, or heads-tails (tails-head) with a 50% chance of winning. Or, I could bet for heads-either, which would represent heads-heads (25%) and heads-tails (50%), which gives me a 75% chance of winning. Nice.

The next step was to figure out a reward scheme for this setup. The basic calculation is pretty simple.

• If the chances of winning are 50% or lower: (100 / chances - 1) * bet coins, or loose all bet coins
• If the chances are higher then 50%: (100 - chances)% to win a coin or loose 1.5 * bet coins

I coded a little betting simulator for this outlined scheme so I could play around with it a bit. The reward scheme probably needs some refinement, but I already had some fun betting and playing. Having the coins simultaneously as action points and life creates a lot of tension of when I was about to bet on which outcomes. Sometimes playing safe can backfire a lot. If I have two coins and I want to play it safe and go for heads-either and 75%, I have a 25% chance to loose 3 coins and flip into certain death.

Creating the simulator and betting was fun enough to spur my imagination. Suddenly the setup of walking around the flat made more sense again, and I felt the need to make it a bit absurd but still focus on ADHD troubles. I played around with the idea of a roguelite. The core battle mechanic would be this betting system. But the odds could be improved by various trinkets, for example a lucky coin that gives +5% of winning (just don't loose it). I also came up with a little sketch for leveling up or progressing in the game. Succesfully progressing the game would just grow the flat and let you do more things. But that's something for later.

For now I'm quite happy with the tagline: Yahtzee, but instead you have ADHD and battle chores with coin flips.

Next week I will try to bring bitsy prototype and betting scheme together, but I'm not sure yet if that will happen in bitsy. Dragging and dropping the coins around is really fun, and I can't recreate that feeling in bitsy. That environment is limited to arrow keys and swipes. And even if I were to implement the coin betting and flipping bitsy is just to aesthetically limited. I could switch to another retro-ish engine like pico-8, but I don't want to waste time learning it yet (but one day). So I'll either have a weirdly reduced version in bitsy, or a messy thing of my own making. Just found out that I can communicate between bitsy and the website and since the betting thing is javascript I can kind of bring those two prototypes together into a very messy thing.

Let's see.

After having two working/playable game prototypes I want to spend this week with documentation and an attempt at grounded theory. This desire to take the time to go deeper into reflection is because of several observations that feel very relevant to my research questions and intentions. I also have the feeling that I need to sort material and thoughts, similar to how I refactored code last week. Sometimes spending time cleaning up helps a lot with formulating emerging ideas. I already started to document the Coin Betting Mechanic since that one didn't seem crazy obvious. In the following I want to expand on the following points

• The connection between vernacular programming and play
• Refactoring as a way of observing the process of materialising ideas in code
• The potentials and importance of ludemes' aesthetic anchoring in regards to analysing code

Vernacular programming and play

Designing and making a game was a lot of fun. I loved thinking through the various aspects of what engine to use, the narration, core mechanics, then bringing it all together and trying out different things. There was something in juggling the growing complexities that reminded me, guess what, about programming. I had to quickly search what the discourse on that is and found just one paper, but it seems solid and I will read it at one point.

Barik, Titus. “Expressions on the Nature and Significance of Programming and Play.” 2017 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC), IEEE, October 2017, 145–53. https://doi.org/10.1109/VLHCC.2017.8103462.

Programming is the only activity that is able to capture and motivate me to stay focused for hours on end. Everything else needs medical support. Maybe it's because making the game is tied into programming it, but I also really enjoyed designing it (in italics because I don't feel comfortable using the term designer for myself yet). There is something deeply playful in this specific style of programming, but also in creating games (from my limited perspective, guess I would have to say in this specific style of making games). This is an open ended endeavour, without limits in terms of ressources or time, except for what I can deliver. It's exploratory, starting from an intention. And it's vernacular, as in being an amateur. I like making a game, because I like playing games.

This prompts me to question why I actually like programming so much, but I have no answer to that. Which is ok. But finding making games as something similar satisfying is interesting.

Programming is a lot about knowing your pieces, and then bringing them together in a way to resolve a problem. It's not unlike a puzzle, but one with uncountable solutions. It's also not unlike Lego, but in programming you can have all kinds of different scales of blocks and materials. And I always tell people that programming is less about learning something technical and more about knowing how to organise your code in a way that serves you, the problem and the future (as in future you who needs to add a feature or fix a bug). So it's somewhat about dealing with growing complexities. Beautiful code for me is not something like the elegance of a mathematical theory and more about capturing the core aspects of a program and being able to tie them neatly together.

Have to keep an eye on this connection especially in regards to understanding why programmers were inclined to make games in the 1980s and -90s.

Refactoring and materialising ideas in code

After messing around for roughly three weeks, wildly coding and throwing out prototypes, I wanted to bring two things together: a bitsy game and my coin betting interface. The latter should serve as a score battle mechanic for a crawler made in bitsy. To that end I started to refactor my coin betting code so I have it easier to have this two different aspects communicate with each other. I needed to do that because I wanted to touch the bitsy side as little as possible. The bitsy crawler is made with the bitsy interface, which lets me export a version of the game as website. Not having to touch its code allows me to continue working on the bitsy side and export it whenever I have an update without me needing to dive in and change stuff every single time.

I went about refactoring for a good 8-12h in total and, while doing so, became aware of how interesting this activity is in relation to my research. I'm interested in how ideas materialise in code. When doing prototyping, this is not a very conscious activity, at least for me. I have an idea and I figure out how to implement it along the way. I'm always able to make stuff working this way, and at the end of the day I have a playable prototype. But while refactoring I had to really think about what kind of objects I need and how they communicate with each other. How do I organise my code so it makes sense cognitively for me, as well as for the machine?

Working in an object oriented-ish programming paradigm (javascript) is probably helpful, but I guess similar processes happened in procedural languages like assembly or BASIC. It's just not that explicit. I usually don't have that much time to refactor. When being more output oriented, working in the industry for example, code has to be more precise, and planned, and executed. I don't get to think too much about if the code is neatly organised and expresses my ideas and intentions. It has to be functional, not explorative.

Observing these objects coming into being made me relate them to ludemes, kind of seeing how they mirror each other. I have a bag object, for example, which cares about holding and minting coins. I also have a table object that takes on a lot of work right now. But it's kind of central to the core mechanic, as it brings together the UI, the bag, and the coins. It mostly cares about knowing if coins have been bet or not and then informs the player about chances and earnings. I will have to document that somewhere else as well. The objects, as they are right of now, sometimes tackle or bundle multiple ludemes together. But I'm able to make similar observations as in my last paper, where ludemes touch different spots in the code base and go about forming patterns on a higher level. I'll keep this in mind for a grounded theory coding session this week.

Aesthetics, ludemes and analysing code

I define ludemes in the following way.

Ludemes are the affordances games offer to become playable—organized in semantic sequences and of memetic nature.

A core critique by Hansen and Hurel on previous attempts of defining ludemes is that it was mostly done from the perspective or research and design, and ignored the players point of view. The latter doesn't need to understand or even be aware of the concept of ludemes in order to play a game, but ludemes are nonetheless present and spring into action to enable play. That's why I use the concept of affordance. Another fundamental difference in the updated definition is the importance of ludemes' having an aesthetic aspect, as in being attached to graphic and sound. This was downplayed in early attempts of definition, but crucial for the way Hansen and Hurel approach the concept. If you want to include a player's perspective, but not from an analytic or designerly point of view, you must enable a phenomenological take.

While pondering a bit about these things it occurred to me, that this is exactly why I find ludemes for my own analysis of code so fruitful. Code has been studied and defined through engineering, computer science or art discourses, most of it being heavy on the theoretical and conceptual side. Ludemes enable me to think about code not in terms of programming paradigms and code design patterns, but include tangible phenomenological aspects. An analysis through ludemes searches for patterns in code closer to human intentions and less through a utopian lense of what perfect code should look like.

That's enough for now and I guess that captures some of the thoughts I deem important at the moment.

In a common coin flip, you call on the outcome of heads or tails, and attach a bet to it. As in, I call heads and if I loose I will do the dishes. In such a setup, your chances to win or loose are equally 50%.

In the Australian two-up two coins are flipped. The bet is usually money. On heads-heads the player wins, on tails-tails they lose, and on heads-tails (or tails-heads) the player can continue throwing. But now we have a 50% for odds (heads-tails) and each a 25% chance for heads-heads and tails-tails and it starts to become more interesting.

I took this trajectory and setup and expanded it with three aspects.

1. Coins as action and health

We start the game with a base amount of coins that we can use to bet. Successfully bets give us more coins, and lost bets looses coins. But our coins are our health at the same time and having no coins means we lost the game.

2. Heads, tails or either

When betting coins, we can go for heads or tails, or either. The last option means that a coin is both at the same time and we add the chances of each configuration together. If we bet just one coin on either, it would mean that we win with heads or tails, meaning we have a 100% win chance. Betting a coin is the only chance to achieve chances of higher than 50%.

I adjusted the reward scheme accordingly.

• If our chances of winning are 50% or less, then we would get (100 / chances - 1) * bet coins. On fail we loose the amount of bet coins.
• If our chances of winning are over 50% we only have a (100 - chances)% chance to win one coin. But we can loose 1.5 * the amount of bet coins.

These are some example calculations on how that can play out. The chances as well as rewards and looses are directly shown when betting a coin. Like this no calculations have to be done manually. For now I found the scheme working out, with a little bit of good choices and luck I was able to gain coins, but sometimes I also was very unlucky and died quickly.

This certainly needs finetuning and I plan to also introduce items or special coins that alter gameplay or chances.

3. Battle mechanics

When I implemented battling it occurred to me, that enemies don't need to attack since the coin betting mechanic is already able to reduce our coin stash. And I found that very fitting with the theme of somebody with ADHD fighting chores. There is something in this mix of the theme and the mechanics that clicks for me.

Doing chores with ADHD sometimes just boils down to luck. Star constellation and our state of being might be well suited for doing chores, or we might just have to have a nap. And it's not like dirty laundry attacks us. They just wait patiently for us to do them, or fail to do so.

How battling works:

• Bet coins in respect to how much coins you want to mint
• Choose attack or defend as action
• On attack, the minted coins are deducted from the chores health
• On defend, the minted coins are added to your own health

You can also choose to ignore the chore, but will lose a coin.

I failed miserably at last year's December Adventure. But that's what adventures are for, right? Sometimes we have to fail. Not everything can be a heroines journey. So let's do this, again.

At TAG I'm doing research creation, means, I design and implement a game that I study through my research questions afterwards. The thing I'm working on is called Ostrakinda and the game's tagline is "Yahtzee, but instead you have ADHD and battle chores with coinflips". I simply wanted to figure out if coinflips can be a fun game mechanic. During development I started to pivot towards a roguelite or dungeon crawler, which now links to what I want to do during December.

BASIC wasn't very high on my list of languages I'd program in, but it was an essential staple for many of the developers I interviewed for the research project I'm currently part of. But then I came across the Sunflow BASIC implementation by Devine Lu Linvega. I mean, look at this super cute illustration by Rek Bell.

My goal in this December Adventure is to code a little dungeon crawler in the Sunflow BASIC dialect. I hope that this will allow me to learn a little bit about BASIC and how to code more complex programs within a limited and non-structured language. The *.bas files can be treated as listings and manually copied into the the interpeter on the website and, of course, into the Sunflower BASIC rom.

• coinflip.bas is a quick test with randomness in BASIC
• dungeon.bas let's you walk around a simple dungeon… for forever

It was fun to learn that I can't assign strings to variables and following that, how to implement something as simple as a little bit of logic to walk around rooms. Also, I started to program in the Sunflower interpreter, which is super pretty, but I also want to format my code for readability. The interpreter crunches away whitespace and intendations, so I started to program in my editor of choice and just LOAD the *.bas files into Sunflower.

Wanted to implement an action menu to setup a plethora of fun things to do besides walking around the dungeon. Run into some weird problems.

• I don't know how to disable mouse input when asking for player input.
• Strings that are too long crash the program. Very likely documented and I haven't read about it yet.
• The lineheight is to narrow for my poor eyesight, so I fiddled around making line breaks in between and had to shift around a lot of line numbers. Painful to do in the interpreter, where you have to rewrite a whole line if you want to change it.

But, besides walking around, you can also leave the dungeon or flip a coin. I also figured out that ; keeps the program from making a newline after a print. I actually knew that from other BASIC dialects I looked into briefly, but didn't see it documented here (except for in an example) and made some mistakes when I tried it out. Had the feeling it doesn't work.

Walking around that dungeon was nice and stuff, but not very coherent. If I wanted to make something fun to play, I needed to implement some kind of structures. I had a nifty idea on how to represent a map with four numbers with four digits each. That makes a four by four grid and a single digit stands for the room type. 16 rooms with 10 room types already allows for some neat generative dungeon, should suffice for this. It also lets me figet with what the possible actions in a room could be. I'll thinking about generating a second map that stands for the rooms interiors, items, or challenges.

Meanwhile did I run into some issues with the Sunflower implementation of TinyBASIC, some technical constraints by the system. I found out that there is a max length for printable strings, and also a max length in how many line dumbers I can dish out. In hindsight it makes sense, because Sunflower is built on top of uxn and the virtual machine has only that much free memory. TinyBASIC's syntax also demands for the IF/THEN statement whereas Sunflower uses only IF, making the two incompatible. But I will stick to Sunflower because it's really, really cute and @neauoire is super supportive (thanks!).

Holy crap, state management and random generation in BASIC is a really shitty thing to do. But I'm learning a thing or two. Haven't had this much motivation to bite through a problem...

The generation of the room map was easy, just four random numbers between 1000-9990. Each number a row of rooms. The doors connecting the rooms on the other hand. In a former version I just randomly generated some doors on the fly. But that made each room different every time you visit it. And I wasn't very happy with that. I wanted to have some stability in that. So I tried to figure out how I can represent that similarly to the room map, and I came up with the following scheme.

• four numbers, four digits each
• the single digit represents with doors are open
• 1 means the door to the north is open, 2 east, 3, south, and 5 west
• 5 means the doors to the north and east are open, 6 for east and south, etc.
• 9 is north and south, 0 is west and east

There is a lot of juggling going on generating the four numbers because now I have constraints. A room in the top left corner can't have a door to the north or west, because that's just the end of the dungeon. A lot of calculations to pick a random digit from the possible combinations for a room according to its position and then putting that digit in the right position of the door map.

That took me quite a while to do, and at one point I actually wanted to give up. I had the feeling that I wouldn't find a solution that works, and already packed my backpack to go home. But the space I'm in is really nice, so I hanged a bit and talked to people and at one point I got into it again. I'm really happy that this is solved, but I'm also tired now.

This didn't add much in terms of gameplay, but it feels like a nicer generated dungeon and I encountered already some fun configurations in my gametests. Sometimes a dungeon is just two connected rooms, sometimes a handful linked through a loop, and sometimes it's like a big mansion.

Today I read a bit into different approaches to interactive fiction, text-adventures, and prodcedural narratives. I tried to find some inspiration in how to make the best of the little options I have in this limited system. I settled for two interlocking branching paradigms, a time based one that's rooted in moving around the map, and a second one called loop and grow where you encounter the same things after a while, but depending on your action you might have unlocked something.

I also settled for a narrative that frames gameplay. Basically you are in a dungeon, walking around. But the dungeon is actually your own mind locked in an ADHD loop and the rooms are different thoughts that pop up. So pondering (moving around) enables the player to do things, like finding trinkets, or taking a nap, and doing the things enables you to ground yourself again and realise that it would be time to take your meds or find another way of breaking free of the loop.

To that end I also came up with a mini inventory management system that can hold up to four different items. That one was a bit easier after I learned how to encode and manage several states in a four-digit number.

I also added some of my "design" documents to this repo :)

Map Generation

I wanted the dungeon to be procedurally generated, but I only have 26 variables (A-Z) to work with, and each can only hold a number between -32768 and 32767. So I had to come up with an encoding scheme that works with my intentions. I decided on a four times four rooms grid and represent it with four variables with four digits each. That would allow me to have some variance for each room, since it can be of 10 different types (0-9). It's also kind of easy to generate through 1000 + random(0-8999). This also means that the left-most rooms can never be of type 0, but I can live with that.

At first I had each room generate some random doors to the other rooms on the fly, when entering the room. But that felt inconsistent during game play. I wanted to have a stable door situation, but this one was a bit tougher to manage. Since it's a grid some rooms could potentially have up to four doors. I didn't figure out a way to encode that into something I can manage within the constraints the technical setup gives me. I settled down to 10 different door configurations with a max of 2 doors per room. The encoding scheme is

• 1 has door to the north, 2 to the east, 3 south, and 4 west
• 5 would have open doors north and east, 6 east and south, 7 south and west, and finally 8 west and north
• 9 has open doors north and south, and 0 west and east

I had some problem implementing this scheme, especially since I had to check if a room is on a side or in a corner, pick a random number from the possible configurations, and put it into the right spot in the variable, so it would be in accordance to x/y coordinates. But it worked out, with some limitations, and it's actually really enjoyable. It can happen that not the full map is accesible at first, but I have a cute mechanic in mind to deal with that.

No December Adventure yesterday. Had a really, really bad hangover. Still suffering some today, but I merged the state management and the inventory functions into the game and also implemented a taking a nap mechanic. The latter triggers after some movement or in a specific room type and teleports the player to a random new corner of the dungeon. I was thinking about this mechanic because sometimes the dungeons can be quite small (because the door configuration limits the movement to a few rooms) and this allows for breaking through that limitation. That's it for today.

I took a risk and sidequested today.

Guessed I came to a point where I need to do some narrative writing for my dungeon crawler and took the chance to look at ink script, some kind of markdown for interactive fiction. I ended up re-programming the BASIC version of the crawler in ink script. But it's really fun, like writing pseudo code, that can actually run.

The process helped me tremendously in figuring out how to interlock the two core mechanics with the narrative and create a game loop that progresses the player towards different ends. Now I need to fill in the details.

Ink script behaves weird in places, but mainly because I treat it like a programming language, which it explicitly doesn't want to be. But if you give me some scriptability you have to be prepared for me to try some random weird stuff.

On the other hand, I start to understand how interactive fiction people function. All tools embody specific perspectives on creation and this is also the case with ink script and how it allows for narratives to branch and be maleable.

After polishing some edges of my crawler, I started to do some actual writing. It's bland right now, but it helps me get a better feeling for what I actually want. It helps me to actually experience the interactive system I'm creating, and to learn from these prototypes. Now I need to concentrate on the interaction of the objects one can find while crawling and bring those together with the core mechanics and steer potential players towards the possible ends.

And then I try to re-implement all of that in Tiny BASIC, and maybe bitsy.

My morning contained three meetings which means I'm used up for the rest of the day. Videoconferences push me into #ADHD overdrive by being absolutely underwhelming (sensorially) while punishing me since I should stay present (cognitively).

I was able to doodle this chart during a moment I zoned out. It keeps track of the interactions of the things one can find in my crawler. I keep track of a central score on a spectrum, and depending on which end of the spectrum the value is, different combinations of objects unlock different endings.

Today, reflection and documentation. I integrated the thing I'm doing in December as a subproject into the research creation project I started last month. It's a bit messy, but what do expect about a game that is about having a bad fit of the #ADHD. Nonetheless do I have the feeling of constant progress through inhibiting different perspectives. I like what's growing there.

https://codeberg.org/thgie/ostrakinda/src/branch/process/journal.md#2025-12-11

With the first of December I started to participate in December Adventure, a neat little event in which participants do some work on projects they usually wouldn't. One reason for that shift in focus was that I actually plateaued with working on the Ostrakinda game. I reached a level where I felt that something was accomplished, although several areas are still underdeveloped. I felt that I'm stuck in terms of mechanics, and somewhat regarding the narrative details. I made the coin flip a core mechanic and that worked out. But on it's own it's kind of boring and once you get the hang of it, you can play it either rather smoothly or get massively frustrated because you run out of luck. I got actually angry at my game for serving me so much misfortune. But the game was missing mechanic complexity.

So I picked up a thing that I wanted to look at since a while, Sunflower, an implementation of the Tiny BASIC dialect. I somewhat had the hope that I'm closer to mechanics when I'm not offered a lot of support by the software or tool I'm using to create the game. A tool always inhibits a certain perspective on creation, and that it is the case with bitsy/bipsi as well. It's great for making lofi walking simulators with narrative, but it's really hard to make something more complex and dynamic regarding mechanics. So I pivoted to the worst kind of BASIC dialect and tried my hands on a text-adventure.

The thing with Tiny BASIC is that you only have 26 variables to work with and each can only hold onto a integer value between -32'something to +32'something. No arrays, not strings, no floating point. And it also only knows the most basic programming keywords. No functions, no loops, not even else statements. So all you can do is assign a numerical value to one of the 26 variables, do a check on it, branch accordingly in your program, and finally print something back to the terminal. I think the Sunflower implementation is more limited then the standard Tiny BASIC dialect. One thing tho that I'm really happy about, is that Devine implemented that one of the variables is actually a function an returns a random number. That became essential to my dungeon crawler.

I started another shorter journal over at sunflower-coincrawler/journal.md in the main branch. It's not very in-depth, but I also started to keep some other notes floating. The need for such arose, because programming in BASIC is so abstract and chaotic, compared to more recent programming languages, that I needed to keep track of how I solved certain problems. I was able to create a generative four x four dungeon with different room types and a door system that is mostly consistent, but it needed a lot of tinkering to work. And, I will not remember how I solved that problem if I don't keep track of it somewhere.

In a more recent programming language you would probably have a class or object that stands for a room, and that class can have a room-type attribute and some kind of links to other rooms. But I have only numbers to do that here. So I came up with an encoding scheme of four numbers with four digits each. Each digit stands for the room type, and each number for a row of four rooms. The four numbers stacked on top of each other represent the four x four dungeon grid then. It's interesting to note how I need to have a graphical understanding of this in order to make it work.

9234
1096
7139
4509

That's how a dungeon can look like and I only need four variables to represent it. So I'm left with 21 (because R is also occupied). Next I needed to figure out how I can encode the connections between the rooms and I found a scheme where I can have one or two doors per room. The "map" looks the same, but the numbers stand for other things. 1 means there is a door to the north of the room, and 7 doors to the south and west, for example. But there go another four variables.

Once I had my dungeon generated and I was able to walk through it I started to think about what actually happens and I found this moment most productive. There is just something about these constraints that forced me to focus on a bare implementation of mechanics. Of course the player can flip a coin, that was easy with the help of the R variable. But would not have been able to implement a complex coin betting scheme like in javascript, where I can connect to a graphical interface. Instead I looked into different schemes of interactive fiction. How they branch and come together and stuff and I found two that I found fitting for a dungeon crawler. One is called "Loop and Grow" and the other one "Open Map". The former follows a narrative where you revisite things but each loop stuff changes or more narrative unlocks, the other one is narrative that is bound to walking around in place more freely.

And then something happened here that I liked a lot. It's one of this moments that I can't fully recall, like the reason why I wanted to do something with coin flips. Looking at those interactive fiction patterns somehow linked back to wanting my thing to be about ADHD (and somewhat not being interested in having a game where you fight enemies). I mapped the two patterns into a vertical and a horizontal axis. The map is the horizontal one and it enables the players to move around and do things. Doing things connects to the vertical "Loop and Grow" and changing a single value one a spectrum from something minus to something plus (-9 to 9 for example). That value stands for the level of disintegration or integration of self of a person stuck in an ADHD loop. And suddenly, at least for me, mechanics and narrative clicked into place and I was able to work out further details.

At this point I felt like I need to finally do some narrative writing and was really bothered to do so in BASIC. Being already in interactive fiction space I guessed it can't hurt to pick up another tool accordingly. I settled for ink, which is made for writers of interactive fiction. It's like a little invasive type of markup that enables branching and options in a story. But I actually ended up re-programming my dungeon crawler. I like ink a lot. It's like pseudo-code that actually runs. And it enabled me finally to bring the mechanics I developed in BASIC together with some more narrative elements.

It's funny because the hidden nature in these game prototypes is having ADHD and the development is so ADHD. I don't finish anything and just start a new thing. But I still feel that I'm doing progress. I also see how these different tools enable me to do things, or restrict me. My plan is to back-port the things in ink to BASIC, and use that as a basis to bring narrative and mechanic to the stuff I did in bitsy. I just don't if it will be bitsy.

An example of play is in order. We start out the adventure and are greeted with a text as follows:

Wait, what was I doing? I came in here for something specific but now I have no idea what it was. I've been standing here for like two minutes just trying to remember.

I'm in a elevator room. I'm just... waiting, I guess? Moving but not really moving. This in-between feeling is actually kind of familiar—like when I'm trying to transition between tasks and my brain just stalls out.

The game then offers the following actions: "move to another room", "inspect surroundings", or "check inventory". The text provided is based on the room type as well as the level of integration. Inspecting the surroundings might unearth an object. The possible findings for now are a coin (of course), a fidget thing, our favourite blanket, medication, a handwritte note, a youtube video, a yoga mat, a plant, or a timer. These objects on themselves are useable but have different effects. The blanket enables naps, but these push the integration value negatively (which is not a bad thing). The point is that these objects interact. Medication, note and timer for example enable the "took meds" ending, but taking meds without these other items might backfire because we don't know when we took our meds the last time without note and timer. There is also the option to brute force and ending by coin flipping, but that's up to luck then.

Anyways, I feel this was constructive. And that was only 10 days of December. It also kind of links up to what we where discussing in the Games as Research meetings. About how making is conversation with an idea that isn't in the right spot yet. But I start to ramble, and I've written enough for today. My plan is to finish the thing in ink next, and than port those aspects to BASIC. And then I see. I'm also happy since I actually now have three games that involve coin flipping in complete different programming languages and that was also somewhat my goal for this project.

I'm in the train from #Montréal to #Halifax and I will not be to much on my laptop. @neauoire was so kind to show me some tricks with Tiny BASIC (bitwise operations) and that allows me to improve the door situation, and most likely other things as well. Now, tadaa, a room can have up to four doors instead of just two. Hell yeah!

I continued to implement the item interactions, but on the ink side. Fun to concept and make it work, but it doesn't play to nice right now. Part of that is that it's repetitive, to advance you have ot move to another room and then search it. I might leave that out and just offer an item right away. The other part is that narratively, it's a mess. But for now I work with these placeholders to see how that feels like.

It was good to let that thing ferment for a moment. That started a process of simplification in my head. I learned some things, and some other aspects created to much friction. And I was also very sad that coin flips haven't been more prominent anymore in the crawler. So I figured a way to bring that back.

In Ostrakinda I have a visual interface where I can drag and drop coins to bet them towards an outcome. That's very much a mouse (or finger) affordance and wouldn't work the same in a text adventure. So I boiled it down to giving players two choices: the action (either attack or recover) and how many coins to bet. Action and chances combined produce the outcome of either gaining or loosing energy, or reducing the enemies energy. It kind of works and I'm happy with it. Other things I want to simplify is moving around and text, instead concentrating on mechanics of finding items and combining them in a resultful manner.

I started to apply Devine's hint to set bits in a variable. That enabled me to save the state of a two or three coins flip in one variable.

After some consideration I have the feeling that I would like this to feel more like one of these adventure games, that one plays with a tarot deck, like Fool's Journey. There is something neat in mechanics that drive story but leave the space blank for the player to fill in. I might need to find a way to make results and feedback more evocative. But maybe I could draw on the I Ching or something like that.

Day wait what already 17 of #DecemberAdventure

Started the process to merge and mitigate all the different aspects of the crawler into a new assemblage of BASIC. Nothing that seems overly fun, but being able to restructure from the ground up is so satisfying. I'm in the train again, for another 18 hours, so I will not be to concentrate much on anything.

Choo choo!

Had a good run this morning in the train in re-integrating some more of the aspects I already programmed. I left the door situation for now, but I need to fix that again. It's not that cool. But it already works quite well and I'm happy with the outcome. Feels dungeon-ish AND cleaner.

Brought most of the things together and polished it to be with as little bugs as possible. Today I cared mostly about getting it running in the browser, so I can push it to itch.io. It's still a work in progress, but publishing it somewhere helps me get some pressure up and keep doing it. I felt how the motivation to get going waned a bit over the last few days and I hat to stop myself to start a new project on something completely different. A missing center piece is the inventory system and how the items interact with game play. As of now the game has

• procedural generated map (rooms and doors)
• an event and encounter mechanic
• a battle system molded around coin flips
• a narrative engine hanging on the central value of clarity

Next I want to implement the inventory system but keep it simple for now. After that I would love to add more content, to bring some variety into gameplay.

Getting an overview

I have a good list of all my stuff in ostrakinda_process/index.md. Summarized, the following material is present.

• 2 git repositories
  • ostrakinda (24 sep - 11 dec)
  • sunflower-coincrawler (1-22 dec)
• 3 playable game variants that are akin to each other
  • bipsi (js), sunflower (tiny basic), inky (ink script)
• some game fragments and prototypes where i tried out or learned things
• a good amount of process documentation
  • a "why" statement (355 words)
  • a journal with entries from 22 sep to 11 dec (~8100 words)
  • a note explaining the coin betting mechanic (660 words)
  • my discord channel log
  • and finally some reading notes
• some media documentation
  • screenshots and recordings of the game play, including one from Mo
  • some graphical sketches and mappings
  • a collection of references i collected in the beginning of the research

That seems like a good amount of stuff to be analyzed. I just have to figure out how. GT demands that I go into all of my things without question, but GT also lives from several repositories to be used to expand and check on emerging theories. That said, I should definitely do a coding along "designer thinks, designer does". I would like to be able to unearth dersignerly intentions and threads.

Some of the material aspects don't seem essential right now. For example the versioning or the media artefacts. I could imagine, that entangling the time of journal and code could be interesting.

Steps

1. an analysis along GT with a focus on designerly things (thinks, does, questions), AND all applications of codes should get timestamp (date of entry in journal, commit time)
2. an analysis of the code through my own ludemic code studies method
3. tracing the development of the games (their program code and assets) over time and see where and when there are intersections with findings from step 2
4. merging timestamped codes from step 1 and findings from step 3 into a unified timeline

That should give me proper insights into how I worked as a designer, and how that got reflected in the materials at hand, and how these two interacted with each other.

Timeline

• Weeks 6-7 (02-15 feb) GT analysis
• Week 8 (16-22 feb) ludemic code analysis
• Week 9 (23 feb - 1 mar) unified timeline and drafting
• Weeks 10-11 (2-15 mar) writing

Today I start with coding the why.md document as a warm up. Euria gave me the following tipps on how to approach the coding.

• Start with Open Coding.
• Focus on verbs in your coding (e.g., “thinks,” “does,” “questions”) to capture actions and cognition, and consider sub-codes for nuances.
• Use Memos to Document Emergent Ideas.
• Organize Codes into Categories (Axial Coding).
• Use Cases to Compare Designers or Contexts (cases represent units of analysis e.g., individual designers, projects, interviews).
• Use Journals to Track Your Analytic Journey
• Iterate and Constant Comparison
• Theorize (Selective Coding)

I'll certainly go with the first two of open coding and concentrating on verbs. I will also see what I have in terms of notes from our MDM sessions, but after I did some actual work.

Went through why.md two times (aproximately) and then a few times criss-cross. I started with marking my actions through simple verbs, but quickly figured that these can't capture some nuances. For example "researching" could also be seen as questioning or designing in some cases, and it wasn't able to differentiate between did, do, and will do, that is to say, capture the intentionality behind the action. I refined the gerunds by being more expressive, like "moving the researcherly gaze" for these instances:

1: I want to focus on understanding 2: I am pivoting toward research creation 3: I'm looking into

That seems less "objective" but is most likely truer to GT and the reflective nature of MDM. Also why.md was a special document, since it talks a lot about intentions and argues about this and that. I will go throug one of the easier git logs now, and see if the codes change.

Going through git-log-process.txt (which is the git log of the repositories process branch) was easier to work with than why.md. It's more descriptive about what I actually did and thus easier to code. The codes emerge out of the actions. But after a first pass, I have a lot of code that seem overlapping and I tried to take them together a bit. I'll leave it at that and have a go at the other git logs.

I had a tad "Startschwierigkeiten" and it was tough to just sit down and do the coding. Some of my old task-avoidance behaviours kick in. Coding seems too unstimulating for my brain to want to activate any motivation for. But once I was able to look in, I'm in. I worked through git-log-sunflower-coincrawler.txt which is the git log from the December Adventure. I tinkered a lot with the codes, already refactoring them on the go, and organised them into categories such as cognitive, emotional, practical and interpretations. The first three try to contain codes that pertain to my mental, emotional and practical actions or reactions. The last is stuff that I found important, but couldn't describe in a simple term. The codes look like this as of now.

cognitive
    assuming; guessing; pondering
    ideating; brainstorming
    planning; conceptualizing
    reflecting
    wanting; wishing
emotional
    - being unhelpful
    - stressed; strained
    - unhappy; unsatisfied
    + being helpful
    + happy; satisfied; enjoying
    surprised
interpretations
    arguing about importance
    doing actual research
    encountering friction
    moving the researcherly gaze
    trusting the process
practical
    adding; collecting
    deleting; removing
    documenting; mapping
    fixing; refactoring
    hacking; tinkering
    implementing; prototyping
    playing; testing
    researching; learning
    writing

I also color coded them in a way to differentiate what happens in the coded segments, simply by looking at the colors. That is insofar interesting as it allows me to see that, for example, I state what I did, and then reflect on it, or assume as possible future from it. Will continue now with the largest git log file git-log-main.txt. This will be interesting because those commits contain the largest comments yet. The other two logs where much briever and less reflected.

I started to slug off again, my brain is just not able to generate a lot of motivation to go through these files and code them. Maybe I can figure out a way to trick myself into enjoying it. At last, I finished a first pass for the main git log, which wasn't actually that long. I struggle a lot with putting the code into place and not right away switch to refining and reorganising them. I also put an "important" to two codings that seems pivotal to the process. Once where I had a breakthrough and once where I started to reach out. But that's it for today.

In my next session I will continue with the journal and notes I made during development. Not sure about Coin Betting Mechanic.md since that is docu of a specific aspect and I have the feeling it says little about what I did or thought.

I planned to do a better roundup of what happened last week in a summary on friday, but I wasn't able to do that much anyways. The daily entries were enough. This week I tried to schedule coding every morning and I see how that works out. I'll go into the Discord journal now, which I believe will be an interesting task. There is a lot of social stuff going on in the Discord journal, since the audience is clear. Which is not the case with journal.md. On the Discord, I always knew at the time of writing, that my research team potentially has an eye on it. While journal.md is more introspective, the Discord journal is also shitposting or trying to give insights and be a tad performative.

Not sure yet how to take this social dimension into consideration, but maybe I just mark if an exchange was impactful on the development process.

I feel like that there are three distinctive modes of cognitive action that I can see forming right now. Gotta quickly note them down.

- ~~~~~> A, B, C  ingesting,  gathering data
- A ---< X, Y, Z  ideation,   extrapolating data to possibilities
- A, B >~~< X, Y  pondering,  shifting perspective on data
- A, B, C ---> X  theorizing, reducing data to finding

Coding verbs and intentions is ok, but I already see how a second pass will help interpreting these into insights. Looking at my Discord journal it somewhat becomes evident, that I more often described my thinking and feeling, and less what I actually did.

Make that four cognitive modes. The fourth would be to ingest. Might not be overly accurate yet, but certainly an interesting lead to follow. It kind of backtracks to my "initiation, inspiration, and knowledge" pattern, that was important for me to handle developers' data source critically. But it could be interesting to map that out:

• what are the sources and how did the designer interact with them
• what kind of process unfolded within the designer
• how did those processes in turn interact with the material basis of the thing coming into being

Made it 1/3 through the Discord journal and I'm also having a cold. I'm out for now.

I'm continuing coding the Discord log and I had a thought or two about the codes. Categorising them into cognitive and practical doesn't do them justice. Sometimes it's somewhat both. So a matrix could be a nice visualisation to have the codes categorized on a spectrum. Also, I feel that the mode of opening up or reducing is important. Brainstorming is opening up, while realising feels closing down, in terms of having more or less data after the act. I'm also stil very happy with trying to capture happiness and struggles and to see what caused that and how I reacted. Could be interesting to see in a second pass (which I already dread). I think Rilla indicated this:

You could also try the approach of looking backwards from points in the process where you either suddenly made a lot of progress or made an important realization/decision.

I feel like using the categories of immaterial and material movements and treating the thing coming into being like a place could work. In terms of, it's a place that I'm search and once found, I can start to design it.

I struggled a lot with the codes/coding today. It started to became very difficult to easily chose the right code since it wasn't very clear anymore where they differ or overlap. So I tried to find a scheme that works for me right now for the coding, but I'm not sure yet if I will keep it for the analysis. Instead of having a code that roughly clusters around describing something (e.g. reflecting, questioning, realising) I imagined the thing coming into being as a place and the codes as movements in relation to that place. In each code I try to capture two aspects:

• do i have less or more material to work with after the movements
• is the movement targeted to meandering

The cognitive category became immaterial movements and the codes of that category are now:

• aimless wandering
  • ~~~~ neither, meandering
  • assuming, guessing, pondering, questioning, thinking out loud
  • attempts to shift perspective on what's at hand
• checking the map
  • ~~~> reducing, meandering
  • reflecting; questioning; realising
  • targeted act of trying to find a solution in mind for something at hand, something that creates friction
• eplaining the way
  • ---- neither, targeted
  • theorizing; arguing; explaining
  • externalising knowledge to somebody else
  • translating bits and pieces into a better form
• exploring the terrain
  • ---< opens, targeted
  • ideating; brainstorming
  • consciously checking out what's present and using that as the base for ideas on what can be done in this place
• laying down a path
  • ---> reduces, targeted
  • planning; conceptualizing
  • outlining the next steps or a larger plan that will get something done
• looking elsewhere
  • ~~~< opens, meandering
  • inspired; copying; observing
  • checking out other places that help me in knowing what I want and what works (and how)
• searching the signpost
  • ~~-< opens, meandering, then targeted
  • wanting; wishing; needing
  • recognising that there is something missing, or something that needs to be done, without knowing yet what exactly
  • at least the question stands, marking the beginning of a path and leading to further explorations

I made extensive use of the memo function to note down these aspects. Afterwards, coding actually became easier.

Back at it, still working through the Discord journal.

The lines in the daily entries mark a moment where I went to do some actual coding and then came back to the journal. So I finished the Discord journal and hope that I don't have to touch it that quickly again. It's a slow process and it takes me quite some concentration to stay present.

I had the feeling that I could see a slow build up to some very important insights that came together from the discord exchanges, the working group meetings and my own thoughts. All overall the discord journal contains a lot of arguing and explaining. Kind of trying to document what's happening in my head to others. Which makes sense given the social dimension of a Discord journal. It's reflecting and performing at the same time. I'll wonder how that plays out with the rather private normal journal. I hardly ever really describe what I actually did on Discord. Sometimes I mention that I implemented this or fixed that, but never go into any details.

Makes the need to look into the material movements evident. That said, I will not be able to have every code with it's timestamp. If I can't automate that, it will be too much work. But I guess I can certainly timestamp the codings that I marked as important. I have the feeling there were some such moments visible on the Discord.

Out for today. Tomorrow I'll start to tackle journal.md

Friday the 13th. Everything takes longer then expected and that kind of stresses me. But I can't let myself be stressed. The work needs time, and that's just how it is. Sience can't be rushed. I mean, that's what I tell my coachees, so I should follow it myself.

Today, I will go after journal.md, the main document, kind of. Let's see how that goes and if the work so far prepared me to do a good first pass on it.

Worked myself 1/3 through and I had the feeling it's easier here then in the logs. There is more text-flow going on and not just fragments and loose bits. That makes coding much easier. I reworked the codes to reflect the different kinds of "movements" better, and created subcategories for better nuance and organisation. Looks like this right now and feels better then the last code refactoring.

- emotional	 
  - negative 1
  - negative 2
  - positive 1
  - positive 2
  - surprised; astonished
- entangling	 
  - getting feedback
  - rabbit hole
- immaterial	 
  - movements	 
    - exploring
    - pacing
    - strolling
    - visiting
  - restings	 
    - charting path
    - pointing directions
    - retracing steps
    - studying map
- material movements	 
  - contextual	 
    - adding; collecting
    - learning; reading
    - playing; testing
    - visualizing; mapping
    - writing; documenting
  - design and development	 
    - deleting; removing
    - fixing; refactoring
    - hacking; tinkering
    - implementing; prototyping
    - starting; pivoting

I'd like to continue this afternoon and get at least until half of the document.

I have two larger entries left in the journal which I leave for next week. But I got a bit further then I pressured myself into. I had to add a new code in the "immaterial restings" category, which is "getting lost". It's a moment of doubt or not knowing how to continue. Not necessarily a pleasant state, but certainly also productive. A movement stuck in place trying to get elsewhere.

Looking through the coded document I actually realise that I stated a few times what I actually did (as in implemented or produced), just not with a lot of detail. But it helps nonetheless to see the relations between practical and cognitive acts and how they interlock in the process and sometimes become a knot of importance. I'm still mostly focused on what i did and though (and felt at times) and didn't check the material yet for ludemes.

I had to pause briefly and think about if I should include a play analysis in this paper, and I think I don't. The goal is to look at the intersection of design research and critical code studies, and in this specific case, player reception doesn't matter. I can't abstract the ludemes from my own documentation. It probably makes sense if I concentrate on two, max. three different affordances. For example coin flip, luck, and self, or something like that.

Looking forward to finish the first pass next week and then think about how to go about a first reflection and a next pass.

Will attempt to finalize first pass today. Not much left in journal.md and then I have to figure out how to continue.

Quick note: As a next step I should look at the coding report and sift through what that offers me in terms of analytical affordances. And then I would love to alredy sketch a rough timeline of when some of the important moments seem to have happened.

Also, it helps to first read a chunk of text and then code it a first time and not attempt to code it directly.

The journal.md entry on 2025-11-24 is a major reflection on a lot of things that happened. There is a lot of retelling going on, as in trying to summarize what happend, what realisations I made, but also gathering some contextual knowledge that seems important to the summary. I have the feeling that "explaining" things to an anoymous public (myself) is an important step for reflection, since other modes of creating (collecting inspiration, implementing and refactoring, ideation) are less concious and more messy with my ADHD brain.

I have one last, but very long, entry left to go for this first pass. But it's almost three weeks after the former reflectory post.

The last entry was rather summarizing, since I was deep into just coding around during December Adventure. But it ends with a statement where I'm content with the state of things. It seems I had the feeling that I have enough material to work on. There are some insights mentioned in how moving from bitsy to tinybasic and ink helped me realizing some things or work through some problems. One major moment involves being able to make the game more complex and interesting to play in terms of mechanics.

I checked what QualCoder offers in terms of reports and played a bit around with what's there. I finally exported all codes that I marked as important. Then I went through and added the date of each coded segment. That enabled me to create a timeline of important codings, but I didn't take the code itself into consideration yet. It's more a timeline of when important stuff happened during development and design. I then went through every entry and added a note why this seems important. And finally, I went through the git commits log and summarized in what the state of the project was, in terms of materials that were added or worked on. That took me quite some energy and I think I need a break here and let this ferment for a moment or two (until tomorrow).

I will try to reflect the codes today and build a first attempt at theorizing the design and development process. I will at first go along the export of important codes that I made yesterday. While generalising the findings, I would also love to question what makes my design process unique (if there even is such an aspect).

Timeline

• the archive contains work and reflection from end September until end December; with a 2 weeks breaks beginning October and a major project pivot into another repo beginning December
• end September until beginning October
  • exploration of randomness, topics around coins/coin flips
  • exploring topic of anxiety and uncertainty, exchange with Rilla
  • analysing other games, raising the question why we play, actually
  • basic ideas and intentions are put in place (bag of coins, anxiety/adhd)
  • coding some minor prototypes that deal with randomness
• second half October (after vacation break)
  • dealing with doubts and struggles regarding basic intentions but also realised prototypes
  • intending to be more autobiographically narrative (wasn't followed through)
  • learning to work with bitsy
  • demaking "Unfair Flips" in bitsy
• first half November
  • existential but productive reflection on own position and game design
  • struggling with making a "fun" game
  • a lot of postfactum explanations going on here
  • creation of first (but somewhat unsatisfactory) playable prototype by refactoring demake into something of my own making
• second half November
  • ideation around mechanics and finding an interesting solution to making coin flips balanced between chance and choice
  • merging and refactoring former prototype with newly implemented coin flip betting mechanism
• end of November
  • brief exchange with Bea and Vadim and inspiring/productive input regarding coding, puzzling, and creating games
• first half december
  • struggling with narrative and writing
  • refactoring and adding a bit of material to bitsy prototype
  • recreating basic mechanics in tinybasic and ink
  • pivoting to a dungeoncrawler textadventure
• second half december
  • discontinuing narrative writing and concentrating on mechanics
  • refactoring dungeoncrawler, discontinuing work on ink prototype

General Impressions and Takeaways

• I seem to follow an approach in which I try to take various bits and pieces and try to stitch them together, but it doesn't work out as I imagined or intended to, and I start to struggle. There's no real ideation going on and more like a trying to recreate how or what others have done except for that one moment where I run into a systemic problem with the mechanics that I had a lot of fun solving myself, and coming up with something genuine mine/new.
• I'm easily inspired and taken into rabbit holes by a lot of things or what other people are making. Observing seems to be more motivating than doing. Sometimes doing is applied to better understand how other things are done or how other people are working.
• So there is definitive some tension between intention and execution: stitching together ideas, often inspired by others, but struggling to make them feel authentically mine — except in moments of systemic problem-solving (e.g. coin flip mechanics).
• Retroactive sense-making. A lot of the journal entries and reflections are retroactive, rather summarising and postfactum, less intentional and questioning, as if trying to figure out what actually happened.
• Inspiration and creation: easily pulled into “rabbit holes” by observation, which fuels motivation but sometimes displaces direct making.
• Mechanics and narrative: The pivot from narrative-driven bitsy to dungeoncrawler text adventure, then to mechanics-only focus, signals a shift toward systemic play as primary mode of expression.

Reflecting

Given the walking metaphors and sticking with the theme I have one central question arising, which is how does the act of making games become a site for negotiating personal uncertainty, inspiration, and authorship — especially when the process is fragmented, self-critical, and retroactively understood?

From here I see four different clusters of codes that I could continue working with, and helping me to restructure/refactor the codes.

1. Self as Visitor (Identity, Struggle, and Authorship); Designing through internal conflict and self-negotiation
2. Process Dynamics (Movement, Iteration, and Pivoting); The creative process as a non-linear, meandering journey with moments of convergence
3. Externalities (Inspiration, Feedback, and Systems); Being embedded in networks of influence and systemic constraints
4. The Thing as a Site (Visiting, Inhabiting, Leaving); The thing as a territory to be explored, occupied, and abandoned, a landscape of becoming

The session yesterday spurred some further reflection, thinking, and getting insights. Here are some notes I took while on the road.

• This way of postfactum explaining that I found all over the place is actually also something that happens in my head a lot when I'm thinking about things intensely. It is as if I would have a discussion or presentation to somebody unknown that is constantly happening in my head.
• I do have the impression that self as guest would be a better cluster than self as visitor. I like this idea of being a guest and then this opens up a plethora of questions on what kind of guest you are and how do you visit somebody or something. There is also a connection to my "Practice Entanglement" note.
• I should not forget to note down how I came up with the movement-based coding in the first pass, which were constructed of a kind of movement (meandering or directed) and if I have less or more or equal amount of material after the movement.
• And finally, I tried to form a 5th cluster around ludus/ludeme since that is a thing I want to look into in a second passt.

5. The Game Being Thought; How ideas about game design, narration, and mechanics form during the making process.

Overview

Self as Guest

Identity, belonging, and authorship (code towards self).

• doubting self
• claiming autorship
• retro-active sensemaking

Process Dynamics

Movement, iteration, and pivoting (code towards creative process and production).

• wandering
• orienting
• converging
• refining
• pivoting

Contextuality

Inspiration, feedback, and systems (code towards context).

• falling into rabbit holes
• receiving input
• gathering material

The Thing as Site

Visiting, inhabiting, leaving (code towards thing)

• visiting
• inhabiting
• surveying

The Game Being Thought

• noticing ludemes (What small playable unit just became visible?)
• constructing ludus (What kind of space and encounter is this game trying to be?)
• stitching (Is this assembly holding together, or is the join visible?)
• ludemeing (Balancing the tension between mechanics, narrative, and aesthetics.)

Affective

• ease / reflief
• friction / struggle

Clusters / Codes

Self as Guest

Identity, belonging, and authorship.

Negotiating sense of self, legitimacy, and creative voice through the making process, seen metaphorically as a guest at the site of the thing coming into being. A guest arrives into a space that precedes them, operates under implicit obligations, and must continually navigate the question of how much they belong. Marked by self-criticism, retroactive sense-making, and rare moments of genuine ownership.

doubting self

Encounters with friction foregrounding identity rather than the task itself. Feeling stuck, unhappy, or unsatisfied in ways tied to questions of authorship and legitimacy: is this mine? am I doing this right? do I belong here? The anxious guest, aware of their own presence as possibly illegitimate, uncertain whether they were truly invited.

look for: explicit self-criticism; comparing oneself unfavourably to other makers; feeling that work is derivative; paralysis in the face of choices; a sense of not quite fitting or not quite deserving.

claiming authorship

Moments of feeling genuine ownership, and not just relief but also creative agency. Crossing from polite inhabitance into an act that transforms the space into something of their own.

look for: moments of surprise at one's own solution; describing something as genuinely new or one's own; satisfaction tied to having figured something out rather than merely finished it; a shift in register from "I made this" to "this is mine."

retroactive sense-making

Externalising one's own past process, not to explain it to others but mostly to understand it for oneself. The guest reconstructing, after the fact, how they came to be in this room: retracing a path already walked in order to locate where one currently stands. Often takes the form of journal entries that summarise rather than interrogate in my case.

look for: past-tense narration of process events; "what I did was..."; summaries that function as orientation rather than documentation; making sense of a decision only after it has been made; the tone of someone accounting for themselves.

Cluster 2: Process Dynamics

Movement, iteration, and pivoting.

The creative process understood as movement: sometimes purposeful, sometimes wandering, sometimes losing the thread entirely and starting again.

wandering

Neither opening nor closing. Moving through ideas without a clear direction or destination; pondering, assuming, trying on perspectives. Thinking out loud. The connective tissue of the process.

look for: speculative or conditional language ("maybe", "what if", "I wonder"); shifting between unrelated topics; no clear outcome at the end of a segment.

orienting

Recognising that something is missing or needed but not yet knowing what. The moment a question opens, starting a path toward resolution. Precedes more targeted actions.

look for: naming a problem without naming a solution; expressing a want or need without a plan; articulating dissatisfaction as a question rather than a complaint.

converging

Moving from open exploration toward a concrete plan or next step. Reducing complexity into actionable direction. Often follows a period of wandering or orienting.

look for: listing next steps; narrowing options to one; decision language ("I will", "the plan is"); a segment that ends more focused than it began.

walk the walk

Hands-on iteration: fixing, refactoring, and building out what has been planned. The execution phase; implementing and improving rather than conceiving.

look for: describing technical changes to existing work; "I refactored", "I added", "I fixed"; iterating on a prototype rather than conceiving a new one.

pivoting

A deliberate break from a current direction; starting over, switching tools, changing scope. Can be experienced as failure or as creative liberation. Includes both small restarts and major project redirections.

look for: abandoning a tool or approach; starting a new file or repo; describing a change of direction as a decision rather than a drift.

Cluster 3: Externalities

Inspiration, feedback, and systems.

Being embedded in networks of influence like other people's work, tools, conversations, and systemic constraints that shape what becomes possible or desirable.

falling into rabbit holes

Being drawn into someone else's work, tool, or topic; sometimes productively, sometimes at the expense of one's own making. Observation and learning that fuels motivation but can displace direct action.

look for extended engagement with someone else's work; reading, watching, or playing things that are adjacent to the project; losing track of time in research or reference material.

receiving input

Moments of exchange with others like feedback, conversation, collaborative inspiration; sometimes introduces new directions or validate existing ones. Surprise is the affective marker of these encounters: something enters from outside and shifts the trajectory.

look for named exchanges with other people (Rilla, Bea, Vadim); moments described as inspiring or redirecting; ideas attributed to conversation rather than solo reflection.

gathering material

Actively collecting, curating, or mapping resources without yet building with them. Preparing the ground. Includes visual mapping and diagramming as forms of accumulation and orientation.

look for saving references; building lists or collections; making diagrams or maps that don't yet connect to implementation; "I want to keep this for later."

Cluster 4: The Thing as Site

Visiting, inhabiting, leaving.

The thing (game, prototype, document) understood as a territory with its own logic that the designer enters, dwells in, and sometimes abandons. Making as spatial practice.

visiting

Going to other artifacts, games, tools, references in order to understand what is possible, to borrow, or to benchmark. The artifact as a destination that teaches. Observing in order to know what you want.

look for analysing another game; describing what another maker did and how; testing a tool to understand its possibilities rather than to build with it.

inhabiting

Being inside the artifact, being the artifact; not just pointing at it but dwelling in it. Explaining, arguing, documenting: externalising knowledge as a form of occupying and stabilising the territory. Writing and documenting as acts of homemaking in the work.

look for writing about the project for an audience (real or imagined); explaining design decisions; documentation that reads as investment rather than record-keeping.

surveying

Targeted reflection aimed at solving a concrete problem in the work. Studying the artifact to understand where it is stuck, what it lacks, what it could become. Testing as a form of reconnaissance.

look for: playing one's own prototype; reflecting on a specific friction point; asking "why isn't this working?" about something already built.

Cluster 5: The Game Being Thought

How ideas about game design, narration, and mechanics form during the making process.

Tracking the emergence and transformation of design knowledgel; not the doeing but what the designer thinks the game is or should be. Uses my working definitions as its analytical anchors:

Ludeme: the affordances games offer to become playable — organised in semantic sequences and of memetic nature.

Ludus: an aesthetic practice with its own boundaries of time and space that enables its participants the playful and experimental encounter with rules and constraints.

noticing ludemes

What small playable unit just became visible?

A moment where a concrete affordance is identified or named a concrete; a mechanic, a move, a pattern, a constraint; something that could become playable. Ludemes are memetic: they travel, get borrowed, get remixed.

look for naming a mechanic; recognising something as borrowable or portable; isolating one rule and examining what it does; the moment a prototype crystallises around a specific interaction.

constructing ludus

What kind of space and encounter is this game trying to be?

Thinking at the level of the whole game as an aesthetic and experiential space; mood, boundaries, relationship to the player. Not "what does this mechanic do" but "what does this game feel like to be inside." Includes thinking about time, rhythm, and the nature of the encounter the game offers.

look for articulating the feeling or atmosphere the game should produce; defining what counts as inside/outside the game world; thinking about the player's relationship to rules rather than the rules themselves; connecting the game to broader themes (anxiety, uncertainty, ADHD).

stitching

Is this assembly holding together, or is the join visible?

Trying to connect two or more elements, like mechanics, ideas, inspirations, tools, into a coherent whole, and gaining awareness of whether or not it is working. The seam showing is not a failure state; it is analytically significant, marking where authorship and originality are being negotiated. Stitches can hold (successful integration) or show (not working very well).

look for explicit comparisons to other games; dissatisfaction with how elements fit together; "this doesn't feel like mine"; and conversely, moments where something clicks into a unified whole.

ludemeing

Balancing the tension between mechanics, narrative, and aesthetics.

A moment where the maker explicitly or implicitly navigates the tension between mechanics-first thinking (the game as rule-system, puzzle, formal structure) and narrative-first thinking (the game as story, character, autobiographical expression).

look for pivoting between tools associated with different modes (bitsy = narrative-visual; ink = narrative-branching; tinybasic = mechanical); explicit statements about wanting to tell a story vs. build a system; abandoning narrative threads to focus on mechanics; justifying mechanical choices in narrative terms or vice versa.

Affective

These two codes apply across all clusters as valence markers. They describe the emotional quality of a coded segment rather than its function or content. Apply in parallel with cluster codes, not instead of them.

ease / relief

A sense of flow, satisfaction, or resolution. Things working as hoped.

friction / struggle

Resistance, dissatisfaction, or a desire for things to be otherwise.

I reviewed the codes and clusters today and added as much description as seemed necessary. It's note easy to keep it present and some things are overlapping but I gues that is ok. I'm left with the following structure:

• Self as Guest Identity, belonging, and authorship (code towards self).
• Process Dynamics Movement, iteration, and pivoting (code towards creative process and production).
• Contextuality Inspiration, feedback, and systems (code towards context).
• The Thing as Site Visiting, inhabiting, leaving (code towards thing)
• The Game Being Thought Ludemes, Ludus.
• Affective

The first four clusters came out of the first pass and the process of coding and reformulating the codes as a kind of movement. The 5th cluster is specifically about ludemes, and relates to my research. The last is general positive or negative coding on how things made me feel. A lot of that is captured in other codes now, like doubting self which is in the first cluster, but it's handy to have around. I'm positive about the codes now, they seem meaningful and able to capture the process I observed in my documentation. I'm especially taken by the retro-active sensemaking which I was absolutely not aware before. That could be an aspect very specific to my type of making and I need to explore this aspect also in terms of coding and making games (ludemes).

I'm ready for a second pass now but will most likely not complete one next week, since I'm off vacation for some days. I will have to make a planning later today, to get a better hold on my schedule.

Another connection that popped up in terms of theoretisation is Naur's programming as theory building, and Marino's argument "that for Kittler, programming was a kind of theorizing, an activity of philosophical labor". I might be tempted to look again into Berry's computational image and how that links up to what is emerging here, in terms of retro-active sensemaking and coding. I will need remember this during a second pass, but maybe I should just get it going before delving to much on theorising?

Went through why.md and two entries of journal.md. I had a lot of friction getting into the new codes. I had to remind myself again and again where they overlap and how they differ. For example retro-active sensemaking and wandering can overlap a lot, but the cluster is important. The former is about self and often involves summarizing what I did. wandering on the other hand is about the process and coded segments are not linked to what I did, but I'm just stating things and ideas. Likewise gathering material and visiting can be similar. But the first is about topics or readings and the like, and the latter specifically about concrete artifacts, like a game or something. Once I got back into it the coding started to feel better then in the first pass. I sometimes mark larger chunks of text with a code, and then subcode a fragment of it. But I generally stay on a sentence level as it works the best. So far the codes the 'self', 'process', and 'contextuality' categories work very well. Affect as well. I also have been able to identify some ludemeing going on and 'thing' wasn't needed yet.

Will continue tomorrow with coding the journal.md and hope to be able to pick up and continue the work started to today. Sometimes it is a lot about being in the right head space.

Continueing coding journal.md. Coding goes faster this time. The codes work and in most cases they apply easily. I find myself coding larger chunks for some few codes, like retro-active sensemaking or inhabiting. Both codes are about documenting the past or state of things. They are similar, but one is about self and process, and the other about the thing itself. I just marked a code for important, something that I didn't have in mind this time. Might do that again for a 2 1/2 pass.

Reading the Wikipedia entry on "The Concept of Mind", a book by Gilbet Ryle. Basically it's about that mind isn't seperated from matter, but mind is just an expression of intelligent acts. Came to this article via Naur's "Programming as Theory Building", and needed to figure out if I can use this as theoretical foundation, but it's too deep. I stick to Naur instead and trust him, that he did his work.

Feels like too much time since the last session. I will attempt to finish journal.md this morning. Should be possible.

I'm getting the feeling that the difference between "retro-active sensemaking" and "inhabiting" matters. The former is to understand how I ended up in a place, and the latter seems more about stabilising complexities. I just marked a large part of the explanation on how the betting works as "inhabiting", but I have a whole separate note on that topic, that I wrote later. So I guess this betting scheme seems like an important moment in the design process.

Ok… I just realised that I forgot about the "sunflower coincrawler" journal.md and notes.md. I added them now to the QualCoder Project and will code them this pass. That might become interesting actually.

Didn't get all the way through but it was good to get back into it. It's always a bit tough to get started and have all the codes and their implications present. The insight regarding the different types of explanations was important for me and for the future process. I noted some things down for a presentation on my gt analysis next week. I'm looking forward to share and discuss my findings. That will be relevant to mirror and expand them, for the coming writeup.

Finished coding journal.md and continued directly with coincrawler-journal.md, which is the journal I started for the December Adventure "sunflower coincrawler" repository. Coding is pretty stable by now. I don't have the need to change the codes in any meaningful manner. The only change yesterday was renaming ludeming into ludo vs. narra, to better describe what it actually is about. At this point I was also asking myself what the benefit of continueing coding will be, but there is a whole analysis of the coding waiting at the other end. I will at least do the journal files, and the git logs.

I prepared the presentation for intermitten findings today, which was nice to structure my thoughts around it a bit better. They are loosely arranged on a Figma board, and I will lead the meeting participants through it, speaking and explaining, but also inviting them to interact and add their own thoughts and notes. I want to talk about two findings and while formulating the second one, the one that is important for my research, I came by the very interesting concept of "enaction", which is "the manner in which a subject of perception creatively matches its actions to the requirements of its situation". That fits really, really well with the concept of affordances. The two findings are:

• The designer as guest, visiting the site of the thing coming into being.
• Enaction as the implication of retro-active sensemaking.

The first is more about vibes and how I see myself as a designer, or my process of designing and creation. The second is directly related to my research as it pertains to the concept of creating (in my case programming) as a way of figuring out things.

Meanwhile, wandering joined the ranks of retro-active sensemaking and inhabiting, as it goes into the direction of explaining a lot, but rather loose.

Finished coincrawler-journal.md which was shorter and concentrated on actually documenting better what I actually did. There is one reference in it to the main journal.md where I deposited a larger reflection, mid December, but no more pondering after that. It's interesting to see how the journaling/documenting style is completely different in the two journals. Raises some questions on the impact of MDM on design and creation processes.

I'm trying to do a second pass on the git logs and the discord journal today. While working on the git logs, I just realized that I haven't used the "falling into rabbit holes" just yet, after the two journal files. I think it's something that I mainly talk about in the discord journal channel, and now I wonder why.

An important moment is in the beginning of December, at which point I run into too much friction into how to continue with the bitsy game prototype. I wasn't able to make it interesting, neither through mechanics, nor narrative. So, I pivoted to start another project. There is something in this change of perspective linked to the tools or approaches of creation. It's pretty neatly packed here, how the modes of production and the modes of thinking are entangled.

Did the git logs and started with the discord journal for the second pass. It's interesting how a large part in the beginning is about laying out the "rabbit hole" of coin flips. I think I collected a tremendous amount of material in a very short time. Haven't had the need to come back to this later in the process.

It is as if you were flipping a coin Lynes' and Ed's share of games with coin flip mechanics, the thread on anxiety here, and making my mom coin flip gamble with me. Something about probabilities. Something about wagers. Perception matters so much. It seems that Fear & Hunger applies coin flipping in an interesting way (https://www.youtube.com/watch?v=MBJLShO8b6w). What outcome's attached to how many coin flips matters. I'm interested in that connection. Tinkering with the probability (Unfair Flips) is too sarcastic and I imagine would bore me quickly (have to play it yet). Q-Up doesn't seem to take coin flips serious either and uses it simply to make fun of the esports genre by wrapping it in an elaborate narration. I'd be more interested in design patterns that play with uncertainty and perception.

This post is from the 27th of September and somehwat concludes a very dense research and inspiration phase. I handed in my third paper in the week of the 15th September, and I have the feeling that my brain went into ADHD overdrive after that, being thirsty for new input. There is a lot of important exchange and context noted in the discord, that is not present as such in the journal or git log.

Going through the Discord log again I realise how much I struggled with this question of balancing a game that is motivating (challenging) or motivating. I always went back and forth between mechanics, narrative, and overall game feels. Not sure if I have to take that up into the findings? Also, if the Discord exchanges point towards a finding, then most likely towards the memetic capability of ludemes.

Done with the Discord journal. I haven't been as detailed and rigorous as in the repository journal files. I definitely hit theorety saturation, found what I needed in order to progress. The Discord journal started to open up a new box that is also interesting, but not needed for me right now. I made some notes on it here above, as well as in the presentation for the MDM research meeting tomorrow. Maybe I can drop it off and see if anybody is interested in picking that up. I'm nonetheless extremely happy to have bumped into how the exchanges on Discord document the memetic capabilities of ludemes. If space allows, this should definitly a note somewhere in the paper.

I would say that concludes the second pass. I don't feel like a third pass just yet and would love to get into the writeup as well as digging the material. This pass I coded for noticing ludemes and that shall be my vocabulary with which I go through the code and check how they form and manifest. Seems a bit messy right now, but I'm certain that things clear up once I'm working through it.

Scribe L (and some Zoom chat residue)

Adrian identifies wo major findings: First finding: Enaction as the implication of retroactive sense making He was thinking about different ways of explaining things (e.g. thinking through a technical problem via either summarizing, documenting, or thinking/pondering aloud) Enaction as the opposite of “affordance” - it’s about how a subject (the designer) matches their actions to the requirements of a given situation (Proveti, 2006); the design context/environment has affordances that we respond to via enaction Self-conversation/pondering

Rilla:

• Distributed cognition - thinking is distributed across materials and tools; particular ideas are afforded by different combinations of material + tool + context + me
• Spatial metaphors of pivoting, plateauing

Second finding: “The designer as a guest, visiting the site of the thing coming into being” 3 categories: 1) material and immaterial movements (new assets vs something new in the designer); 2) more or less material after (brainstorming = more while planning = less); 3) direction (loop or one step to the next?) He says thinking about the process in terms of movement feels right (not living in the design or having absolute authority over it, but a guest visiting different parts of it

Designer as enactive guest

guest also implies being given an invitation

-What is the role of the guest? What about the host? -What does it mean to be invited or act on an invitation?

Rilla [Q]: What about in a design context where control is distributed (e.g., participatory design). Does this mean that all design is participatory just sometimes with non-human participants?

Adrian [A]: The thinking was influenced by new materialism; doesn’t want to generalize all design as participatory but is thinking about respectful encounters with the non-human (Hannah Arendt added to Figma)

Lyne: Gallop “one never knows (fully) from where one speaks… and one always speaks more than what one intends” (quoted in How to Make Art at the End of the World) Loveless, 2019)

Relationality Rilla: Against a dualism of knowing through the other (relationally) and knowing through the self, it’s more of a continuum

E.g. Vadim seeing code glitches as actors - how and when do we follow the impulse to see aspects of the process/materials as actors.

What is the moment/mechanism of invitation to the designer-guest? Role of control vs lack thereof?

Adrian: Openness - commitment to executing the idea as planned at all costs vs. Taking cues from what is actively happening (to pivot, etc)

Vadim: more organic, a less colonial impulse in design? Talks about Lynch films and what would get in the way of emergence

Rilla: Wondering about sunk cost fallacy. Question of lingering or walking away. Are we forming friendships with materials? Relationships start with the formation of your own language, so are we developing a language with our materials? Big differences between the chat history and the actual relationship - when we remove part of a design that isn’t working are we confusing the part for the whole?

How do the guest and the host “speak to each other”?

Lyne: So…the materials aren’t answering the question because they know, they’re answering the question by figuring it out alongside you. Also re: part for whole confusion - metonymic confusion?

Courtney: Don’t want to sub part for whole and wants to code every line of Adrian being in conversation with his materials but there’s so much insight!

This kind of reinforces what we said about the importance of what is not included in design, but extends it to the analysis itself: how do we find a way to present research in a way that lets these things ”bear witness” and give them a space to say something

Scribe C (on Discord)

"The designer as guest, visiting the site of the thing coming into being" (how Adrian sees his process and himself situated) "Enaction as the implication of retro-active sensemaking." (post 2 passes of GD on the archive)

Starting w/number 2!! A lot of explaining going on in the repo Documentation also, with details why "I struggled with a technical problem". Thinking aloud in a pondering way. Not a summary or retroactive, parsing through ideas. inhabiting, retro active sensemaking, wandering Adrian doesn't talk about what he actually did discussing with himself (retro-active sensemaking, making sense of materials/choices after the fact) a lot of learning and knowing is happening while he is doing recounting arises to externalise the praxis gains during the doing Enaction as opposite of affordance -> matching requirements to situations (John Protevi, 2006) Not looked at the enaction yet, just aware it is happening. Can see the throughline of theories that he works with - informing his approach. affordances, small units of gameplay that are mimetic, which brought enaction to fruition -> will consider when going through the material aspects of the archive

19:20 Rilla: feels aligned with her own design thinking, she asks - is this navigation or a distributed cognition? Designer sharing cognition across materials and tools, making them formative on what you can glean from them. Certain material combinations leading to certain affordances. Adrian: that's in the other finding. Pivoting was important in the design process, where a sense of plateau happened, so I moved to a new project with some of the old project. (Isn't that technically iteration, anyway?) Number 1! making it measurable sketches the axis of movement (immaterial, material / more, less materials / kind of movement ) from this came the "visitor" of design discomfort in claiming authorship interpreted design experience through the lens of a visitor -> uncertainty of design process and title of software dev over game dev

Next step: going into materials! comparison between process and materials, with chronology sit down with one intention and then do The Thing okay, so what actually happened, and then there's the retroactive sensemaking

19:31 Rilla: Indigenous Futures workshop (in Hawaii!) -> that workshop was to work with indigenous folks to tell their stories in future ways. Space + Digital Games + Actual People? Space is to be conquered and colonised. Hawaiians have the perspective that their country was stolen & colonised: what would it mean to do space travel as a guest? Respectful, hostliness, (Hospitality - Phenomenology? Merleau-Ponty and Derrida?) Rilla: Design praxis? The locus of control is promised away from the designer. Participatory design (PD) is there to translate perspectives and weave them harmoniously. The designer is always the guest in PD. Is design like PD for you? Adrian: Influence of new materialism. Different how one works with non-human and human. You don't need a metaphysical vocab, it is just a different approach. Important to him personally these respectful interactions with the non-human. Relationality Trying to avoid confirmation bias on what he already thinks. The designer is always situated and no separation of mind from oneself. The tools are actors with whom he co-creates. "I am the only one reflecting on the thing."

19:43 Glitches and Relationality Pippin works with the glitches in his work. Vadim: Where does the impulse/embracing of the glitch? It is context depending - what he was working on or with. Encountering and incorporating glitches worked with what he sought to evoke. Openness of the mind to for go established practices. Adrian: playing with the materials more, agency of the non-human. Vadim: more organic, in working with the world rather than making it rigid (and colonising).

19:51 Vadim: David Lynch had an emergent process in how he makes. Rilla: sunk cost fallacy? How much time do you throw at something functioning? Relationships form through building a shared language. Resonance across the history of the relationship. Lopping off part of the materials for lack of function akin to thinking of folks as chat logs over being living humans. Mo: art and science of removing, keeping it somewhere for folks to witness? Lyne: testament! How are the guest and the host speaking to each other? Materials as partner. They don't just embody, they witness. Subbing part for the whole + conversation w/the design - metanymic confusion with the design.

These are notes on going through the findings of the second pass, anaylse them towards ludemes, and figuring out which angle to take.

• created mdm archive
• did two gt passes on archive and discussed with research team
• have a good amount of findings (theoretical saturation?)

todo

• extract ludemes and ludus from gt analysis
  • export codings from gt and go through them
  • map codings to get contextual understanding of ludemes and ludus
  • choose one major and two lesser ludemes (coin flip, ...)
• do analysis of material and code (pick one major and two lesser ludemes as examples)
  • use mapping as guideline to investigate material on surface level
  • use case ludemes to dig down in code
• writeup for fdg, and writeup for main publication

fdg

• designer as guest, tactful encounters and visits
• angle: how mdm can help investigating design types

main publication

• memetic qualities of ludemes and their manifestation in code
• discussion: distributed cognition, affordances and enactivism (naur)

Ludemes of Interest (2026-03-17)

• main ludeme: coin flip (bag of coins, betting)
• all ludeme-ish things:
  • coin flip
  • resources: bag of coins, time
  • spaces: homebase, labyrinth (dungeon)
  • mechanics: randomness, probability, gambling, betting
  • larger narratives: fate, decision, cleromacy
  • personal narratives: anxiety, uncertainty, doubts
  • subjects: avatar, cat, plant (why are there no other people)
  • objects: clock, chair, computer, windows, dust, socks,

thoughts

• coin flip needed to be taken apart or put in relationship with other ludemes, namely coins as depletable resource and betting, in order to become interesting. realisation is rooted in implementing coin flips in various situations (website, cat, unfair flip) as well as researching different coin flip approaches (flip, two-up, pogs) (mid november)
• peaked towards last third november when combining bitsy and betting interface, after that mostly exploring the same space through different perspectives with tinybasic and inkscript
• sub-ludemes would most likely overload the text, i can just concentrate on coin flip since there is more than enough material present

Coin Flip Ludeme Timeline

• 19. sept: coin flips as rabbit hole and starting point for game (are.na collection started 1. sept and is loosely mentioned in personal journal); some aspects already researched, like cleromancy, coin boys, i ching
• 24. sept: implementing 8-ball (called rand.js.html first); digging random number generators and how they can be stacked to create odds or narrative (branching), and the importance of perception of randomness
• until end of sept: continued research on coin flips; expanding aspects by randomness and fate, ostrakinda, two-up, and milkcaps, as well as binary notation
• 30. sept: playtesting unfair flips and q-up; visiting them already with ideas and theories about randomness (and its perception) and coin flips as mechanics; taking major inspiration; maybe the seed of "why we play games actually"
• 1. oct: implementing coin flip website; realising that i played unfair flips despite it not being super pleasant
• 2. oct: first mention of bag of coins
• 23. oct: watching stream on unfair flips that validates some of my thoughts on games that are not pleasant to play: "People like algorithms though. They like algorithms that hurt them. So I I it makes sense that they like Cookie Clicker."

• 24. oct: deciding on bitsy and creating the shitty cat prototype; first implementation of a coin flip in bitsy; struggling with narrative
• 27. oct: demake of unfair flips in bitsy; thoughts on javascript and oo and ludemes
• 31. oct: struggle with making coin flip interesting, but wondering why, since unfair flips doesn't seem to have any narrative
• 6. nov: unfair flips demake > 'why do we play games actually' and attempting some world building and "interesting" things to do besides playing unfair flips, but not necessary mechanics
• 7. nov: implementing doubts, mechanics that relate to coin flips (as in how many times flipped); doubts is the result of the longer thread on anxiety and uncertainy; finding narrative too bleak now
• 12-14. nov: returning to coin flip as core mechanic and trying to make that part interesting; actually figuring out what the odds are (in real life, pen and paper); inspired by yatzee and two-up leads to coin flip gambling mechanic; creating a reward and loss scheme; after paper scribles, implementing odds.html and then betting.html; mapping betting (mechanic) with bag of coins (depletable resource)
• 20-21. nov: mergin bitsy prototype and coin betting interface and refactoring
• 24. nov: satisfied with the state reached; reflection

places to investigate coin flips

• coin flip generation in assembler, js, and inkscript
• 8-ball and coin.html
• shitty cat bitsy game
• unfair flips demake js files
• odds.html and betting.html
• why we play games actually prototype (to see difference to unfair flips demake)
• (optional, if that isn't enough) inkscript and tinybasic, where i tried to explore the same space from other perspectives

001 8-ball.html

• actually had some comments in there :)
• although essential for a coin flip, i didn't/don't understand random number generators, but i acknowledge their importance
• 8ball was really just an exercise in figuring out random number generation, but then pivoted towards what to do with the result
• the half-byte construction is silly but it seemed an intriguing way to explore branch notation (there is a note on that on discord i believe)

002 coin.html

• the actual coin flip is a single line that returns a side, based on the comparison of a random number and a probability
• so probability was alread a subject here (is this before or after unfair flips?)
• coin flip first time entangled with grapheme, so a lot of styling and some animation going on, leveraging browser frontend stack
• there is also a history function that I can't remember or document; first indication of trying to think about probability and statistic?
• and finally there is the more button, maybe an indicator for bag of coins?

003 the futility of arguing with a cat

• coin flip was made with bitsy tools (dialog, shuffle lists)
• coin became an object to pick up (findable coins are a subject again in coincrawler)
• first time acousteme attached to coin flip

004 unfair flips x bitsy demake

• builds on arguing with cat prototype; coin needs to be grabbed and coin flip is attached to interaction with cat
• although there is no actual coin object, it's simply a true/false flag in state management to see if player picked up the coin
• introduction of state management, and an upgrade feature that needs to be interacted with in order to do stuff; bipsi has no "ui" all things are done by walking around > coin flip by bumping into cat
• pivot to bipsi because scriptability, and inclusion of a dialogue plugin for the upgrade feature
• all actors become objects (their own js files)

005 why do we play games actually (v1)

• continuation of 004, but with proper room setup
• cat is removed, instead there is a plant now
• unfair flips is played on a computer that has a different interface
• stil no coin object, but a flip file that cares about flipping the coin (what was attached to the cat before); also no visual representation of the coin or the coin flip, just a message

006 why do we play games actually (v2, doubts)

• pretty much the same as 005, but with a new doubts file that triggers messages after a certain amount of flips

007 odds.html

• could most likely have been easier with python, but somehow the mode was frontend
• the flip is very easy here, relying on simple js
• most of the code is forms, statistics, and automation to visualise how the odds play out in the different possible constellations (single, two-up, three-up)
• was a way to extrapolate from a single coin flip into hundreds and tousands of flips to better understand how such scenarios actually play out
• was a reaction to what i did on paper before; probably important to materialise the ever evolving question on how probability is created, but also perceived
• paper version was important to "discover" a pattern when adding coins to the mix (single 50/50, two-up 25/50/25, etc)
• there was also some dealing on how to figure out if the flip results match the betting

008 betting.html

• a bit of styling, but a lot of js otherwise
• all objects are now classes (in bipsi it was files I could inject)
• objects are coin, bag, and table
• had to generate a probability calculator with AI; seemed to be to complicated to wrap my head around in terms of implementation
• coin cares about being flipped and saving that in its own side state
• coins can be dragged around helping with the feeling of an actual object
• bag cares about adding, removing coins to itself, and placing the coins on the table
• table is the actual interface glue that checks where the coins are placed and generating the bet from that, as well as instructing each coin to flip itself on demand, and then comparing the bet with the results; continues to compare amount of coins bet with probility and adds/remove as many coins as won/lost
• there is also a lot of rendering logic in the table that i leaned on afterwards

009 ostrakinda

• merger of 006 and 008
• fixing the lack of coin representation with the betting interface, and vice verse the lack of narrative embedding
• brought bag of coins idea to 008, but also the homebase idea to 007
• could be interesting to think of that as two strands
  • narrative, homebase (also being home alone, like me in Montreal), adhd, uncertainty
  • coin flips, probability, perception of probability, gambling

Closing Statement

I didn't have the feeling that I'm finished with the game, yet. But after a few months of inactivity, it's most likely for the best to give it a proper rest. Nobody bares me from reviving the project later on, but it's also a healthy practice to officially close a seemingly open project. This might already be part of this closing statement, a kind of learning, on giving oneself the right to finish things that don't seem finished. I want to structure this closing statement along a general reflection on process, on what I have in the end — the outcomes —, and finally on some takeaways for future endeavours.

Process Reflection

The whole process felt rather innocent, and opaque. The reason why I started creating my own game for research purpose was two-fold. I was my convinced, that MDM will help me get the kind of data I need to further my research questions. Equally important was that I felt very comfortable with a research-creation approach, an aspect I was missing in my PhD studies. MDM is relatively simple, but I was never quite sure if I was doing it right, whatever that means. So there was some insecurity regarding the correct process. Although I'm sure that there was nothing dedicatedly wrong about how I was doing it. Maybe it was the simple fact of creating for research purpose that create some insecurities. As in, will I have to defend this as real research in my corner of academia.

Besides that the major struggle I had was the friction between doing and reflecting. For Ostrakinda I used a multi-branch repository approach, one branch containing the game in the becoming, the other the process documentation. That meant that I had to switch branches if I wanted to switch between developing and documenting. The struggle didn't lessen after I had both branches checked out, indicating that it is a more fundamental problem I have. I was simply not capable to switch easily or swiftly between these two modes of thinking — one focused on doing, one on reflecting. I have a programmer's practice and writing code as a way of thinking comes easy to me. But, then reflecting on it, in parallel, takes more effort. So often I rather tried out things in code, then in thought. That resulted in the already documented retroactive sense-making, attempts of making sense of what I did after the fact.

The mentioned innocence became evident to me in one point, when I felt like I approach game making like the people I interviewed as parts of my research, which made games in the 1980s. They, as well, often were programmers first, and game designers second. They had the technical skills, but not the designerly ones needed to make an interesting game. I often struggled with the question of how to make a game interesting, which were moments where I tried to find inspiration somewhere else. But I found this struggle productive. In the end the whole process wasn't very personal and as such not tied to some personal outcome. I didn't feel like an artist trying to express myself, but rather as a problem solver trying to make this work. That might have helped me to keep motivation sustained for the duration of development.

Some words on community and practice are in order as well. I love playing games, and already researching games felt weird, let alone creating a game for research. Creating a game is one of these things that sound great as teenager, like drawing comics. But there might be some societal residue on me regarding how I judge these things. I mean, the only way to heaven is through honest work, right? Being embedded in a community where this kind of practice is taken serious, on a sustained basis through regular exchanges, informal discussions, and a sharing of practice, struggle, and works helped tremendously in reframing my stance towards creation for research. Ostrakinda and the process it came out of wouldn't be the same without the community that was already in place. I guess there is a point to make on the situatedness on MDM practice, and that it most likely wouldn't be the same without the lab and the people.

Outcomes

What to say about the game itself? I'm very happy with what I ended up with. I genuinely think that the betting scheme and interface are fun and that I could make more out of the game, if I would find the time and motivation to continue working on it. But then again, it is hard to judge the outcome without having made a clear statement on where I want to get in the process. The only real anchor is that I wanted to make a game that uses coin flips as a core mechanic.

I'm not overly interesting in continued work of the two text-only adventures I produced in the last phase of the design process. It was a fun exercise, but I believe that the graphic embedding of the coin flip is central to what I tried here. And, in the end I'm a frontend developer for a reason. I can do systems, but I have more fun in the overlap of code and visuals. I'm also not a big fan of playing interactive fiction. The mechanics of a UI as well as its close relationship to gameplay are important to me.

Finally, I'm a bit intrigued by the form it took. I wasn't expecting that I stick with the bitsy (or bipsi) game engine, but I like it a lot. I always had the feeling that people told the cutest kind of stories with bitsy, but that it's not much of a mechanic engine. Furthermore, I finally was able to solve that gap by using the bipsi game engine, that allows for scripting. That enabled me to construct a bridge between the bitsy game and my coin flip betting interface, without any hassles of changing the bipsi game engine. In the following I adapted my UI to fit a bit better with the lofi pixel graphics of bitsy, but that was OK for me.

I'm honestly motivated to continue working on that final prototype, but knowing myself and my meandering interests, I'm not sure that that ever happens.

Takeaways

Given some of the struggles and insights of the process I could formulate the following takeaways:

• Chose and stick with a game engine from the beginning. I tried a lot of different setups in Ostrakinda, and I'm not sure that it was very valuable. It enabled me to sidestep some problems and gain different perspectives, but in hindsight I would say I would be able to do so with less technical efforts. For example by simply collect myself on pen and paper again.
• There is so much value in simply doing. But there is also value in reflecting during the process. Working on this game made me realize just how much the doing part is a valid way of researching and getting to know. Documenting and reflecting was harder, and I need to find a way to have a better balance a next time. Maybe having a checklist or a rhythm would support getting from one mode into another. Just going with the flow is nice, but hardly lends itself to a reflected or structured outcome.
• I liked making a game, and I would love to continue doing this in the future, if I find the time. As a leisure activity, but also as a researcherly way of going about producing knowledge. I just scratched the surface with Ostrakinda. The initial question was quite simple, honestly. But I could definitely go deeper with my own questions on programming as culturally significant, or asking questions of societal value. Or, simply because it's a nice leisurely activity.
• Designing and developing a game takes tremendous amount of energy and time. I would love to collaborate in a next project. Doing all these things by myself is cool, but I also had the feeling that I'm not getting anywhere. There is the added benefit of learning together, which I was missing very much this time.

I will let Ostrakinda rest for now. It gave me much, and I regret nothing. Time will tell if I find the energy and motivation to continue this endeavour. If not, rest in peace.