- a digital game is not a film, comic, or book
- what a digital game is, is intricately linked to computing, which in turn is linked to telling computers what to do, through coding
- a turing-complete machine can simulate any other machine given enough time
- of course that’s theory and in practice it looks quite different
- a computer can’t do much without embodiment
- a computer is a machine that can create good enough experiences [@birkenIllusionAlsVersprechen], that people enjoy, but the “good enough” changes with context
On these terms, the core operations of a computer do not reflect a universal “truth” about the relationship between the individual and the machine; rather, these operations offer a blank scaffolding that is designed merely to accommodate any specific user’s intentions. Much as a typewriter only produces what the typist wants to write, a computer only reflects the information that a user wants to process. If there is an essence to programming, it only emerges as a reflection of the user’s intentions, which they express by inputting information. [@phippsIfYouCan2024]
Games and productivity software differ fundamentally in their architecture and code structure due to their distinct purposes. While games focus on creating engaging, real-time experiences, productivity software aims to reliably process and manage data.
- At their core, games are built around a tight main loop that updates dozens of times per second. This loop constantly checks player input, updates the game state, handles physics and collisions, and renders new frames. In contrast, productivity software typically uses an event-driven architecture, where code executes in response to specific user actions like clicking buttons or submitting forms. This is an interesting point old text-adventures, where gameloops worked rather event-based. But it validates my hunch, that the gameloop is an important piece of what makes a game a game.
- State management also differs significantly between the two. Games maintain continuous, frame-by-frame state updates for elements like physics simulations, AI behavior, and animations. Productivity software, however, deals with discrete, transaction-based states, focusing on database operations and document saving.
- Input handling reveals another key distinction. Games continuously poll for input, often handling multiple simultaneous inputs with timing-sensitive responses. They might even buffer inputs for complex combinations or sequences. Productivity software typically processes input through events, handling operations sequentially through form submissions and menu selections.
- Time management varies as well. Games work with delta time between frames, managing fixed timestep updates and frame rates for smooth animation. Productivity software primarily uses wall clock time for scheduling tasks and managing operation timeouts.
- Error handling philosophies diverge significantly. Games tend toward graceful degradation, providing visual feedback for invalid actions while continuing to run. Productivity software emphasizes strict validation, transaction rollbacks, and detailed error logging to maintain data integrity.
- Applies to more contemporary video games and software: The user interface architecture differs too. Games build around render loops, sprite management, and scene graphs, while productivity software uses component hierarchies, layout managers, and data binding systems.
These architectural differences stem from their contrasting goals. Games prioritize immediate feedback and continuous interaction to maintain player engagement, while productivity software emphasizes data integrity and reliable workflow processing. This fundamental difference in purpose shapes every aspect of how their code is structured and executed.