Finding the ‘Magic’ in Programming Games: A Critical Digital Humanities Approach to Studying Video Game Code

Theoretical Considerations

This understanding of programming and a programmer’s intentions assumes their cultural significance. Early works, such as the foundational The Psychology of Computer Programming,¹⁴ captured the discourse on programming, shedding light on the practice from an operational perspective and incorporating an engineering viewpoint. Notably, programming has always existed as a political force,¹⁵ a leisure activity from which homebrew video games emerged,¹⁶ and an artistic endeavour.¹⁷ Annette Vee’s work on the history of Dartmouth BASIC,¹⁸ a programming language developed in the 1960s, probably best outlines this significance for cultural production. The pedagogical driver behind this specific programming language was neither academic engagement with computation nor enabling a career path as a software developer. As Vee notes regarding the language’s design and pedagogy, the intention was to make computing accessible:

Other authors have also supported the idea that programming and coding are culturally significant. Early on, Friedrich Kittler theorised code and outlined how programming is a continuation of the practice of encoding,²⁰ which is necessary in all forms of communication. The emergence of critical code studies in the mid-2000s has established a practice of hermeneutical and close readings of code as a way of theorising it.²¹ This approach is exemplified by Willumsen’s formal analysis of Passage’s source code.²² She argues that a close reading of source code can generate insights into video games as works that go beyond what their authors claim in public reflections. Critical code studies have since established themselves as an influential and valuable perspective in the digital humanities,²³ especially within the branch focused on studying born-digital works. However, this discourse lacks a formal analysis of what David M. Berry calls the ‘computational image’, a material perspective on the encoding and transmission of meaning in source code:

Sonja Fizek outlines the initial inability to cross disciplines or domains of knowledge, as discussed in the introduction, through a media-ontological perspective.²⁵ She points out that video game images are made up of more than just light; they are also constructed of mathematics, calculated on the fly by a machine and in relation to its operations. This process creates the need for a different kind of visual literacy among spectators (from players to researchers). Thus, Fizek positions video games as aesthetic forms that rely on the tension between representation and computation. Born-digital images that emerge from running games are no longer only representations – they display software operations, but are also operational.²⁶ Thus, in order to understand the thread of translation from machine execution to human experience, there is a need to study the game’s computational materiality, and vice versa. Doing so requires, among other approaches, deep readings of the source code’s different aspects, such as semantics, pragmatics, and structures.²⁷ Without bridging these perspectives, research inquiries might miss out on essential insights regarding how technical constraints shape creative decisions, how programming practices encode visions of play, and how gaming cultures emerge.

Building on semiotics, I approach this problem space through the study of a game’s ludemes, guided by how programmers conceptualise their code and how players access a video game. Ludemes are affordances with the particular function of making games playable. They have various definitions, most often as fundamental units of designing or researching video games.²⁸ Interestingly, Pierre-Yves Hurel and Damien Hansen approach ludemes from the perspectives of sociology and semiotics,²⁹ and Hansen outlines ludemes as fundamental meaningful units of a quasi-video game language, consisting of a mechanical element or rule of interaction (mechanème) and an audiovisual representation (graphème, acoustème).³⁰ These ludemes are then organised into syntactic and recursive sequences, creating the larger structures of the game. Unlike some previous approaches that focused primarily on rules and mechanics, Hurel’s and Hansen’s conceptions of ludemes incorporate both the concrete elements of games and aspects of game makers’ intentions and players’ experiences. Finally, these ludemes are encoded in the game’s computational materiality and highlight how rules and game mechanics can have rhetorical effects.³¹

Like Hurel and Hansen, among other authors, I do not necessarily agree on all the defining aspects of what makes ludemes. Moreover, the lax definition of ludemes may pose a significant risk of becoming a conceptual trick that allows a justification of findings without further inquiry. There is, nonetheless, a valid argument for the productive powers of this concept in positioning it as a boundary object. As outlined by Susan Leigh Star, boundary objects are concepts that are flexible enough to be adapted and understood differently by multiple communities or disciplines while still maintaining enough structure to facilitate collaboration and sharing across those boundaries.³² Bridging insights and approaches in game studies, semiotics, and sociology, these humble units then continue to bear fruit here through critical code studies.

Consequently, I propose a working definition of these small units of gameplay: ludemes are the affordances games offer to become playable, organised into semantic sequences and of a memetic nature. They cover phenomenological ground through their aesthetic representations,³³ are structurally inscribed in source code by their mechanical aspects, and open up semiotic investigations through their semantics and memetics. Ludemes can be learned and known through gameplay, but need to be conceptualised and encoded through programming.³⁴

Contextualisation

Baerlocher’s path to serious game development accelerated when he acquired an Acorn Archimedes computer in his late teenage years. The machine’s capabilities, demonstrated by David Braben’s 3D game Zarch,³⁵ convinced him that a career in video games was possible. This computer system was mainly marketed in the UK and had only limited success in Switzerland, where the game was developed in 1991. Following this acquisition, he joined the demo group Arc Angels during his undergraduate studies and connected with like-minded programmers across Europe as well as the demo scene community surrounding the Archimedes. Baerlocher repeatedly mentioned his fascination with the Acorn’s ARM processor capabilities, demonstrating his knowledge of its architecture and showcasing his technical prowess:

The emergence of the ARM processor family is, in itself, a significant chapter in computer history. ARM is shorthand for ‘Acorn RISC Machine’, where RISC stands for ‘Reduced Instruction Set Computer’, indicating a simpler processor architecture. ARM was developed in the 1980s by Acorn Computers, with Sophie Wilson as the principal architect of its instruction set. The processor architecture was designed to be efficient and simple, and it has since become one of the most widely adopted processor designs globally, powering everything from smartphones to servers. Whereas the first version of Poizone was written in ARM Assembly, the port was realised in Python. There is a fundamental difference between these two programming languages that warrants consideration: their categorisation as low- and high-level, respectively. Low-level languages like Assembly are close to machine code and ask the programmer to explicitly manage hardware resources and memory, giving control but making code harder to read and write. High-level languages like Python, on the other hand, abstract away those hardware details, allowing for a focus on logic and more easily readable syntax, although at the cost of control and efficiency.

In light of my interests in programming as culturally significant, it would be easy to dismiss Friedrich Kittler’s provocative statement that ‘there is no software’.³⁷ His argument need not be read as a dismissal of the cultural agency of programming or programming languages, but rather as an observation on the nature of computing and code that challenges common assumptions about how computers actually work. Contrary to the promises of the software industry, Kittler argues that software does not exist as an independent, immaterial abstraction. All code ultimately depends on, and resolves into, hardware, physics, and electrical processes.

Media archaeologist Wolfgang Ernst continues Kittler’s line of thought, arguing that computation is not just symbolic processing but a material, physical operation carried out by devices, circuits, timing, and energy flows.³⁹ Hardware is not incidental, but shapes what computation can do, how fast it can do it, and how it ages or fails. Ernst’s inquiries connect computing to media archaeology. In this context, computer code does not ephemerally reside in the cloud, but is a concise layer on top of several strata of hardware, connected all the way down to silicon and electronic signals. Building on the archaeological perspectives of Jussi Parikka and John Durham Peters on the material substrates of media,⁴⁰ the digital humanities can profit from deepening their engagement with born-digital objects by considering their situatedness in computational infrastructure and hardware.

At the same time, media archaeology can benefit from embracing the cognitive and operational structures that emerge from code, treating computational materiality as inseparable from algorithmic logic. Seen like that, older computing devices and their source code are useful not just as historical artefacts but also as ways to understand the operational principles of computation and how culture emerged from the practice of programming. Kittler’s and Ernst’s theoretical perspectives on the relationships among ludemic conceptualisation, code, and materiality will inform the following analysis.

Analysis

To follow the semiotic thread between developers and players as it manifests in video games’ computational materiality, researchers need to adopt both perspectives. This approach is attempted through a process outlined in Table 1, with the first phase concentrating on identifying relevant ludemes through a play analysis.⁴¹ The focus is on the game’s affordances for play.⁴² This allows for the generation of a vocabulary of concepts through which the source code can be approached as a catalogue of questions and computational inquiries. The second phase is guided by a distant reading strategy, in which basic text and pattern-searching tools help gain a fundamental understanding of the codebase’s structures and provide an overview of them.⁴³ Completing the analysis is a scalable reading,⁴⁴ in which breakdowns of gameplay and source code help transition into critical close readings and the analysis of findings. All of these will be discussed in detail in the following sections.

When Paolo Baerlocher developed the puzzle game Poizone in 1991, the use of the keyboard’s arrow keys for gaming was already an established method of play. These humble directional inputs were originally developed to move a cursor around a text-based screen. Early computers did not feature graphical user interfaces or the ability to interact with a mouse; instead, they displayed a terminal and walls of text. Consequently, programmers of early arcade game adaptations for home computers had to figure out how to play these games without a joystick, since the hardware was not present in every household. Suddenly, a fundamental aspect from the perspective of play had to be negotiated, and developers had to invest considerable effort in making this kind of interaction work, making it an interesting case to study. In the following, the analysis is restricted to the discussion of this specific aspect of gameplay and its technical implementation.

Play-Analysis and Formation of Ludemes

The analysis begins with setting the stage for Poizone, a block-pushing puzzle game that draws inspiration from the genre-defining Soko-Ban⁴⁵ and especially the arcade game Pengo.⁴⁶ The protagonist finds itself in various landscapes, from frozen plateaus to the insides of an electronic circuit. Where Pengo was rather minimal and Pacman-esque in its approach and aesthetics, concentrating on pushing blocks and evading monsters, Poizone has a refined narrative centred on toxic waste and environmental pollution – an intentional choice by Baerlocher. The challenge of the game increases through each level, asking the player to remove a number of toxic blocks within a given time. These toxic blocks can be of different types, each with its own rules for removal. Some need to be pushed and slide freely for a moment before they crush. Others can only be removed by pushing from the sides, not from the top or bottom.

Figure 1 shows the protagonist, Zozo, pushing the ‘Green Chemical Substance’ block in order to destroy it. Several elements stand out as important to gameplay. Through the penguin avatar, the player can interact with the game world and different kinds of blocks, while a heads-up display informs us of our progress within the game. All of these elements, along with their interactions, can be defined as ludemes. The figure also highlights another critical aspect of ludemes: their memetic properties. Taking inspiration from Soko-Ban and Pengo, the ludic elements and visual language of both these games can be recognised in Poizone, and figure as genetic material from which the latter drew and evolved.

Figure 1

What follows is a thick description of the first few moments of playing Poizone. Figure 2 shows what we see when we start playing. Our protagonist, Zozo, is centred on the screen and looks straight at us. We are surrounded by blank space and various kinds of blocks. From the tutorial, we know that we can – and must – interact with these blocks. On the right side, an interface displays essential information related to the game’s challenges, namely, removing a certain number of toxic blocks within a given time. There are further visual elements, such as small snow-covered bumps and flags. The only action left to do at this moment is to press the arrow keys on the keyboard and move around. We quickly learn that the blocks stop our movement, but not the decorative elements, such as the little blue flag. Walking up to a block allows us to commence the game’s second core action: pushing, which is essential to remove blocks from the game. The tutorial taught us that certain blocks have certain rules that we need to adhere to.

Figure 2

Pushing the blocks the right way destroys them, as shown in Figure 1. Meanwhile, the percentage in the heads-up interface increases, giving us a rough idea of how many blocks need to be removed in order to reach the goal. Destroying the decorative blocks does not affect the counter, but they still play a crucial role. The tutorial taught us that the green blocks need to slide for at least a bit before they can crash into another block to remove it. Not adhering to this rule knocks us out for a brief moment. At this point, it becomes apparent that there are no lives or energy in the game, unlike other games. Instead, lying unconscious, time is ticking away while we are being forced to lie still.⁴⁷ Pressing the arrow keys at this moment has no effect; we are reduced to waiting to awake again before we can continue playing.

This brief excerpt of a longer playthrough of the first level leaves behind a rich vocabulary of ludemes and their affordances. These concepts had to be extracted from visual and written notes made during the play analysis through a process that clusters the observations into small aesthetic-mechanical units of gameplay. Play analysis can be quite bountiful, and the need to focus on specific aspects and details in building a ludemic vocabulary arises. Reducing the scope of research data, the analysis concentrates on characters, objects, and actions that, in one way or another, concern themselves with the game mechanics of moving the player avatar within the game. Table 2 collects those ludemes, allowing the articulation of a set of questions through which the source code is approached in the next phase.

• Player control: How is the player’s wish to move taken into account – where does the program capture and react to player input?

• Avatar representation: How is the internal representation of the avatar created, and how does the program know where Zozo is and in which direction it is moving?

• Internal state management: How does the program enable interaction with the environment, and how does it know where the avatar can or cannot walk?

• Interaction feedback: How does the program communicate its internal state? For example, how does it keep track if a move was successful, or if Zozo collided with anything, and let the player know the result of the initial input?

Distant Reading Source Code and Mapping Ludemes

Rather than attempting to read code line by line as one might read a text, Till A. Heilmann argues for a surface-level, computational method that treats the source code as raw material to be processed and reduced through operational transformations.⁴⁸ His approach begins with basic observations about file organisation, sizes, and types, then progressively breaks down the code into smaller, analysable components using standard command-line tools like grep, sed, and awk. These tools can be found on Unix-like systems and are generally applied for searching, editing, and processing text files. This method is based on the assumption that source code can go beyond manual observation and contains meaningful patterns and structures that can be studied.

This approach might seem underwhelming compared to other computational approaches in the digital humanities, especially cultural analytics⁴⁹ and software-assisted distant reading,⁵⁰ which use machine learning and advanced algorithms to process millions of pages of text or image files. The issue at hand links back to Peter Naur’s Programming as Theory Building,⁵¹ in accordance with Janna Omena’s reflections on technicity.⁵² If the original conceptualisation of the software coming into being is held by the programmers themselves, the digital research toolset needs to reflect that. A distant reading will necessarily inject layers of abstraction between a researcher and the code they are studying, the intentions of which they are attempting to rebuild and interpret. Applying machine learning to source code can provide overviews, but such distant reading methods will only allow for a limited interpretation of the meaning of direct experience.

Heilmann’s methodology involves systematically extracting different elements from the codebase, such as separating comments from actual code, creating comprehensive word lists, and mapping object hierarchies.⁵³ This first step helps in constructing patterns, frequencies, and structural relationships that would become invisible when reading individual sections of code. This methodology aligns with digital humanities approaches to computational text analysis, where systematic extraction and pattern recognition serve as interpretive tools rather than ends in themselves, similar to how query design in database studies treats the interrogation of data structures as a form of critical analysis.⁵⁴ This approach serves as preparation rather than a replacement for traditional code analysis, providing the entry points and structural understanding necessary for the meaningful interpretation of how a software reflects broader cultural and technological contexts.

The grep command in Listing 1 illustrates this approach by searching for where the avatar is referenced in the code. This inquiry for patterns searches for ‘pengo’, ‘pengi’, and ‘penguin’ at the same time, regardless of whether it was written with or without capital letters. In a brief skim of the code, different ways of addressing Zozo – the in-game name of the protagonist – can be observed. Within the code, the penguin is generally labelled ‘pengo’, honouring Poizone’s inspiration and referencing the Pengo arcade game. Since Poizone has a two-player feature, the code also sometimes speaks of ‘pengi’, the plural of ‘pengo’. Zozo can then be found called ‘pengo’, ‘pengo1’, or ‘pengi1’, in different variants with and without capital letters. This variation can be captured comfortably with a grep query, of which an abbreviated excerpt is shown in Listing 2:

Listing 1

Listing 2

By reducing thousands of lines of code to a manageable set of inquiries, the approach enables the identification of sections of code related to the ludemic vocabulary for closer examination. Further, the process allows for a better understanding of the game’s structural foundations and prepares the groundwork for deeper cultural and technical analysis. Tables 3 and 4 index relevant places in the source code related to relevant ludemes and list them for the two Poizone versions.

The table breakdown of ludemic elements provides a basic inventory of the distribution of game mechanics and objects across the codebase. It enables a high-level perspective on how the code is organised and how much of it had to be written for which ludemes. This is a first step towards a structural reading of source code. At this moment, there is no focus on the specific details of the technical implementation, but rather on understanding the mental model the programmer has built during development. This mental model is akin to the theory of software coming into being and relates at once to the developer’s intention and to the technical context, both of which shape how the code is written and structured.

Source code is most often pragmatically optimised. A fundamental aspect of this practice is the modularisation and reuse of pieces of code. This fragmentation occurs through different structures that programming languages offer, such as subroutines or functions, or by splitting the codebase into several files. This process is already evident when tracking the ludemes and listing the relevant code in Tables 3 and 4. In subroutines, for example, the developer simply tells the program to jump to a different place in the code, execute that part, and then return. Since this can be done in various places throughout the program, the subroutine can be reused for tasks that need to be performed many times, such as rendering a block on the screen. This referentiality leads to a dense network of pointers, links, and information flows. If source code is text, it leans heavily toward hypertext, as conceptually outlined by George Landow,⁵⁵ or toward cybertext, as outlined by Espen Aarseth.⁵⁶

To fully grasp the structural relationships among them, a visual mapping approach can be valuable.⁵⁷ While the tables index the presence and location of specific ludemes, they cannot easily communicate the interconnections among them. A relational visualisation transforms this tabular data into a network that highlights the entanglement and distribution of the ludemes in code. Figure 3 illustrates this approach, clarifying how hierarchical dependencies and fundamental structures are expressed. This visual representation makes it possible to identify clusters of related functionality, trace the flow of game logic across different programming languages and files, and understand how seemingly disparate ludemes, such as teleportation and avatar movement, might share underlying computational foundations.

Figure 3

Close Reading the Source Code

This third and final phase of the analysis finally tackles the question asked at the beginning of this section regarding how the game knows where and when the player is allowed to walk. This is just one of the many possible questions, but moving around Zozo in Poizone will guide this discussion as a case study. What is missing in this process is a close reading, comparison, and analysis of the relevant bits of source code in both versions. The inquiry starts with looking into the original Poizone version, programmed in ARM Assembly.

The game is written in a little over 8090 lines of code, contained in one single file, and Baerlocher did not use any video game development framework. Although such frameworks existed in the early 1990s for other programming languages, Assembly-based libraries were rare due to the language’s complexity and low-level nature, making Assembly-based video game frameworks uncommon. The organisation of the code in this single text file mostly happens through a rich application of comments, some of which are quite skilfully laid out. Since source code is essentially plain text without the possibility to change the typography of individual parts, like titles or marking keywords in bold, programmers often rely on special characters and create typographic layouts through whitespace in order to structure code for easier reading. These kinds of layouts can become quite elaborate and decorative, beyond their initial function for readability. The following snippet in Listing 3 illustrates the variables that help the program remember the kind of relationship the avatar has with a given block. Did Zozo push it, and from which direction? These relationships, defined by the programmer, save values in memory and help the program understand what the player intended to do.

Listing 3

Given the amount of code devoted to handling player input and moving Zozo accordingly, compared to other functionality Baerlocher needed to program, this simple task seems rather complex. The difficulty of handling such a common thing arises from the programming language’s need to directly interact with the input and computing hardware, namely, joysticks, keyboards, and the processor. Assembly has no supportive layer in between to address this aspect, resulting in a lot of code that does not align with the direct player experience or the developer’s intentions. Instead, this simple interaction functionality adds lines of code and complexity for managing hardware states. Baerlocher had to go to great lengths to correctly infer what the player intended to do and then convey that directly to hardware memory to remember and act on those choices.

The excerpt in Table 5 demonstrates how moving the avatar on screen in response to player input emerges from the interplay of multiple code components. These are not organised into one single block of code that corresponds neatly to the moving ludeme. Although they appear close to each other in relation to the complete code file, this particular ludeme is scattered throughout the codebase, with relevant parts in different sections and scopes. Some of this code relates directly to how the developer intended the game to be played – how they designed it. Another large portion of the code had to be written to manage the game state and communicate with the hardware.

These ludemes of moving Zozo can be compared to the code in the 2023 port of Poizone. This version of the game is written in Python, a general-purpose language designed to be easier for humans to read, and incorporates modern programming concepts. One of these is better organisation of the codebase through object classes, which is the code equivalent of real-world expressions, as well as moving code that belongs together into separate files. For the ported version of the game, Baerlocher built on pygame, a Python framework that helps in developing video games. The framework does most of the heavy lifting for tracking the game state and communicating with the hardware. Counting the entirety of lines of code in all of Poizone’s Python files adds up to roughly 3200 lines. The code also includes comments, as shown in Listing 4, but this time they are rather brief and used only where the code does not speak for itself.

Listing 4

The fundamental idea behind modularity resides in the idea that certain software operations do not need to be written several times. Instead, they can be implemented once and then reused in other parts of the software. Different programming languages offer various structures to organise the code in a modular fashion. In the ported version’s code, this aspect is evidenced by its file structure. The file poizone.py contains the main game code, for example, while globals.py hosts snippets of code that need to be used in other files, and files named like penguin.py and monsters.py handle everything related to these player and non-player characters. This results in game-related functionality involving fewer lines of code, but it is often spread across several files. Splitting and organising the codebase into separate routines and files helps the developer create more reusable, easier-to-maintain code. It also highlights different ways of conceptualising ludemes and interactions. Compared to the game’s original code, reading player input is far less complicated, and Baerlocher was able to lean on pygame’s offerings.

Following the outline in Table 6, the penguin object class’s update function on lines 279–479 handles all the logic related to moving, including checks for whether we are walking or pushing, whether we are blocked by an obstacle or by the level border, and whether we have run into one of the monsters, among other things. These 203 lines of code are among the largest routines in the ported version, indicating that much of the game logic could not be handled by the framework and was instead tied to the developer’s game design. Having broken down the video game’s source code through play analysis, building a ludemic vocabulary, distant reading and mapping the territory, and finally a close reading, this finding offers a valuable insight. Having the answers to the question of how the program knows whether Zozo can move in a specific direction, as implemented in the penguin class, enables a discussion of the programmer’s perspective and his theory of the software he was writing. Three positions are of relevance to this discussion: the difference in ludeme implementation, the developer’s perspective on game and play, and, to some extent, the player’s experience.

Discussion

Although the two games appear functionally identical to players, they represent completely different computational materialities and technical origins. The original 1991 version exists as raw Assembly code speaking directly to hardware, while the contemporary port operates through layers of abstraction provided by Python and the pygame framework. Every aspect has been fundamentally reconceptualised, from low-level hardware manipulations to high-level, object-oriented structures. The very substance of the game’s existence has transformed. Where once it lived as precise processor instructions that managed memory and registers, it now exists as interpreted scripts that leverage modern libraries. This situation raises profound questions about the identities of born-digital objects. Akin to the ‘Ship of Theseus’ paradox, one might question whether this is still the same game after exchanging all its constituent parts. The ludemes persist in identical form for players, yet their technical substrate has been completely reconstituted, revealing the complex relationship between a game’s experiential essence and its material computational reality.

The code not only differs in programming language or hardware platform, but also in the experience the developer brings to the table, which is especially visible in how the code is organised. In the original game, the entire codebase is in a single file, adhering to the imperative programming paradigm. The ported game has its code neatly arranged across different files in accordance with mental models or functionality. There is also the ported game’s dependence on the pygame framework. Abstracting some core functionality of the game lays bare which code manages game state and supportive functions, and which code is of a ludemic nature. While implementing moving Zozo around in the 1991 version, Assembly code involved talking to and managing hardware, especially memory; the same task was now largely handled by the framework. This shift highlights how certain ludemes are so fundamental that they are naturalised into common knowledge bases like the pygame framework.

Deepening this specific thread enables a first foray into what otherwise difficult-to-access insights the source code can offer us. Implementing moving Zozo around includes checking whether the penguin will collide with another object or character. The game needs to include an authoritative institution capable of determining whether such an event has occurred and directing the involved parties to act accordingly. The program needs to ask, for example, whether the penguin collided with a monster, and if so, knock out Zozo. Interestingly, the code in the ported game was not organised around this question. The Python code is built around mental concepts, such as the main game code, monsters, and the penguin, and it is organised into files and programmatic structures to mirror these concepts. In the ported game’s code, the specific functionality to check if Zozo is colliding is not handled by the main game code, but is attached to the penguin class, which represents the mental model of the avatar. The question the program hence asks is: ‘Do I, the penguin, collide with a monster?’

This aspect is a valuable insight into how the developer assumes the player’s perspective during development and how this is, in turn, unintentionally encoded in the video game’s structures. Pierre-Yves Hurel outlines this process in his research on how amateur video game developers hone their tastes by oscillating between playing games and then recreating the elements they like.⁵⁸ Following Naur and regarding the study of the source code, this observation indicates that the programmer is developing several theories in parallel. The primary theory concerns the knowledge about the software coming into being,⁵⁹ and entangled with it, a secondary theoretical system emerges, which concerns itself with ideas and intentions about gameplay.

The questions raised by the ‘Ship of Theseus’ in regard to a plurality of theories at play force a confrontation with what authenticity means for born-digital objects. The paradox traditionally offers no singular answer but reveals that sameness itself is philosophically underdetermined. Does the game’s identity reside in its ludic function and the experience of play, its materiality of code and hardware, or some irreducible combination of both? Further, it can be argued that authenticity in born-digital objects is fundamentally plural. The original 1991 version maintains authenticity as a historical artefact that embodies the material constraints and possibilities of its era, while the contemporary port achieves authenticity through the faithful preservation of the ludic system and design intentions. In other words, born-digital authenticity is not about material fidelity, but about what aspects of the original we deem essential to preserve. The answers depend on the epistemological commitments regarding what games fundamentally are and how their preservation is assembled.⁶⁰

To finalise the discussion, there is a recognition of code working as a translation mechanism. It is not merely converting human intention into machine instruction but mediating between different technological epochs, programming paradigms, and cultural moments.⁶¹ The memetic persistence of moving around or pushing ludemes across entirely different technical implementations demonstrates how code serves as a vessel for cultural transmission, carrying forward play patterns and interaction vocabularies that transcend their material substrates.

Conclusion

The digital humanities involve not only large-scale computational methods or the digitisation of old sources, but also a fundamental critical approach to all things digital. What is often lost in this discipline’s perspective is the digital technologies’ relationship to media and materiality. The analysis presented in this article demonstrates how digital humanities can move beyond algorithm-based approaches toward more fundamental engagement with computational materiality.⁶² Rather than treating code as a black box or reducing it to surface-level effects, this methodological approach enables researchers to examine how cultural meanings become embedded in technical structures and how these structures in turn shape cultural possibilities. Baerlocher’s inhabiting of the player perspective within the penguin’s object class regarding collision detection exemplifies how cultural imagination becomes encoded in technical architectures. Such findings emerge only through the synthesis of cultural interpretation and technical investigation, demonstrating the inadequacy of purely formalist or purely cultural approaches to understanding computational media. Digital humanities must develop methodologies capable of reading these technical layers as cultural documents that deserve preservation and interpretation.⁶³

Going further, this case outlines how the encoded structures in source code are worthy objects of investigation. In programming, meaning and message do not exist solely at the level of words or lines of code but emerge from deep-rooted structures dispersed throughout large codebases. The presented framework opens a pathway to meaningful readings of these structures by showing their relationality to developer intentions and player phenomenology. Further, the discussed case outlines how historical source code studies must attend to more than surface readings. Source code emerges from this analysis as a unique form of cultural memory that preserves not only functional specifications but also the cognitive and social contexts of its creation. The comparison between Poizone’s two versions underlined how code carries forward ludemic concepts across technological discontinuities while simultaneously documenting the evolution of programming habits. The original assembly code’s direct hardware management and the port’s framework dependencies mark distinct moments in the historical relationship between programmer and machine, between creative vision and technical constraint.

Finally, this study opens a path for further inquiries and validations of structural deep readings in critical code studies. The magical moment of translation between developer intention and player experience, mediated through the complex technical and cultural work of programming, emerges as a fundamental site for understanding how meaning is made and transmitted in computational media. This moment, preserved in source code and reconstructed through ludemic analysis, offers media archaeology access to the cultural work performed by technical systems and the technical work performed by cultural imagination. Through this synthesis of technical and cultural analysis, interactive media can be understood as a participant in broader cultural transmission while simultaneously creating new possibilities for meaning-making, memory, and imagination. The source code of games like Poizone thus becomes not merely a functional specification but a cultural document, preserving, in technical form, the visions, constraints, and possibilities that shaped particular historical moments in human–computer interaction.

Declaration

The author declares no competing interests and was solely responsible for conceiving, designing, analysing, and writing this manuscript. A polished excerpt of the presented analysis, including a high-resolution version of the ludeme-in-code mapping, is publicly available.⁶⁵