Gregor Woitczyk · Popetto
I want to understand how things work. Their parts, their rules, how they fit together.
From that understanding, I build software, systems and workflows that work reliably and leave time for new ideas.
Software & systems AI & automation Creativity & responsibility
01 / Approach
Yesterday, today, tomorrow and beyond. Four perspectives from my practice: understand, stabilise, transform and automate.
One approach. Three projects of my own.
Harpin is my TypeScript interpreter for stories written in Twine’s Harlowe format, created for a narrative game using Phaser. It connects text, choices and game actions while leaving presentation to the game.
Select a point. Motion pauses. Read the step ↓
Beam = project progressFour perspectives on the same project. These steps make tasks and decisions from my work concrete; PDCA helps organise them. In practice, each step can take several rounds. About the PDCA cycle ↗
Identify the parts, rules and connections.
For a game, a story is more than a sequence of sentences. It contains passages, links, conditions and instructions. Harpin starts with that structure.
In the project: The parser distinguishes text, links, jumps, variables and other instructions.
A view of the components behind the narrative text.
The parser reads the source file and assigns its elements to passages. A line of dialogue remains text, a link has a destination, and a control instruction gets its own type.
In the project: Dedicated element models represent the different components.
A story whose progression can be examined programmatically.
I need to be able to inspect what a parser has understood. Harpin can export the parsed story as structured JSON, allowing source and result to be compared.
In the project: The example workflow reads a source file and writes the processed structure.
An inspectable translation from text into a data model.
Stories, passages and elements get explicit interfaces. The later execution layer does not have to keep rediscovering the meaning of the original text lines.
In the project: Parser and execution use the same story and element types.
A shared understanding for the next processing steps.
Build a dependable foundation.
A dialogue must not race ahead before it has been read. Harpin makes interruption explicit: selected element types pause progression until the game continues it.
In the project: The element types that trigger interruptions are configurable.
A rule defining when the tool waits.
The interpreter tracks the current passage and next element. An interruption is explicitly resolved before processing continues.
In the project: Passage, element position and interruption state are part of execution control.
A defined place to continue after each pause.
When examining a flow, one step is often more useful than the whole story. Harpin supports processing individual elements and running until the next interruption.
In the project: Single-step and continuous processing are separate execution options.
The progression can be examined at specific points.
The interpreter needs to report what is happening. Harpin provides defined callbacks for events including text, links, interruptions and the end of the story.
In the project: The TypeScript interface describes the events and the data they carry.
An explicit connection between story progression and the game.
Bring things together, reshape them and make them understandable.
The story should be written in its authoring format while the game retains its own presentation. Harpin provides a layer between Harlowe source text and in-game progression.
In the project: The project was developed to bring interactive stories into a custom runtime.
Both tools can retain what they do well.
The parsed story becomes a shared data structure used by the execution layer. The connected application decides how a sentence looks or a choice is presented.
In the project: Parser, data model and processing are separate components.
Narrative and presentation can be changed independently where their interface permits.
A small example story makes the connection tangible. The included example run shows text output, speaker changes and background changes in sequence.
In the project: Example code and its recorded output show the processing of the same story.
A small enough flow to assess how the parts connect.
Not every game action belongs to the narrative format itself. Harpin also recognises custom metadata and passes it to the application, for example for speakers or backgrounds.
In the project: Custom macros and their callback extend the handling of the standard elements.
A shared flow with room for the game’s own requirements.
Hand proven routines over to tools.
Display text in sequence, switch passages, pause and resume: these tasks recur in narrative games. I collect this routine in the interpreter.
In the project: Harpin provides shared processing for different story passages.
The technical flow does not need to be rebuilt for each scene.
The interpreter reads the next element, processes it and invokes the corresponding application callback. The story supplies the sequence; the game supplies the presentation.
In the project: Processing routes text, links and instructions to their respective callbacks.
Repeated wiring becomes a shared tool.
Automatically processed stories still need observable stopping points. The example resolves pauses and lets the flow be followed through to the reported end of the story.
In the project: The example connects interruption, continuation and completion events.
The automated progression remains observable.
Harpin exists as a standalone TypeScript library. Its reusable progression logic is intended to free attention for dialogue, choices and the effect of a scene.
In the project: The package exposes the interpreter and its types for integration.
A tool of my own in service of a creative idea.
Another perspective
Problems do not stand still. While I work on a task, the situation changes. Like a solar system in motion, the helix shows both: the path of the task and my work around it.
Select a point. Motion pauses. Read the step ↓
Orbit = project progressFour perspectives on the same project. These steps make tasks and decisions from my work concrete; PDCA helps organise them. In practice, each step can take several rounds. About the PDCA cycle ↗
Identify the parts, rules and connections.
For a game, a story is more than a sequence of sentences. It contains passages, links, conditions and instructions. Harpin starts with that structure.
In the project: The parser distinguishes text, links, jumps, variables and other instructions.
A view of the components behind the narrative text.
The parser reads the source file and assigns its elements to passages. A line of dialogue remains text, a link has a destination, and a control instruction gets its own type.
In the project: Dedicated element models represent the different components.
A story whose progression can be examined programmatically.
I need to be able to inspect what a parser has understood. Harpin can export the parsed story as structured JSON, allowing source and result to be compared.
In the project: The example workflow reads a source file and writes the processed structure.
An inspectable translation from text into a data model.
Stories, passages and elements get explicit interfaces. The later execution layer does not have to keep rediscovering the meaning of the original text lines.
In the project: Parser and execution use the same story and element types.
A shared understanding for the next processing steps.
Build a dependable foundation.
A dialogue must not race ahead before it has been read. Harpin makes interruption explicit: selected element types pause progression until the game continues it.
In the project: The element types that trigger interruptions are configurable.
A rule defining when the tool waits.
The interpreter tracks the current passage and next element. An interruption is explicitly resolved before processing continues.
In the project: Passage, element position and interruption state are part of execution control.
A defined place to continue after each pause.
When examining a flow, one step is often more useful than the whole story. Harpin supports processing individual elements and running until the next interruption.
In the project: Single-step and continuous processing are separate execution options.
The progression can be examined at specific points.
The interpreter needs to report what is happening. Harpin provides defined callbacks for events including text, links, interruptions and the end of the story.
In the project: The TypeScript interface describes the events and the data they carry.
An explicit connection between story progression and the game.
Bring things together, reshape them and make them understandable.
The story should be written in its authoring format while the game retains its own presentation. Harpin provides a layer between Harlowe source text and in-game progression.
In the project: The project was developed to bring interactive stories into a custom runtime.
Both tools can retain what they do well.
The parsed story becomes a shared data structure used by the execution layer. The connected application decides how a sentence looks or a choice is presented.
In the project: Parser, data model and processing are separate components.
Narrative and presentation can be changed independently where their interface permits.
A small example story makes the connection tangible. The included example run shows text output, speaker changes and background changes in sequence.
In the project: Example code and its recorded output show the processing of the same story.
A small enough flow to assess how the parts connect.
Not every game action belongs to the narrative format itself. Harpin also recognises custom metadata and passes it to the application, for example for speakers or backgrounds.
In the project: Custom macros and their callback extend the handling of the standard elements.
A shared flow with room for the game’s own requirements.
Hand proven routines over to tools.
Display text in sequence, switch passages, pause and resume: these tasks recur in narrative games. I collect this routine in the interpreter.
In the project: Harpin provides shared processing for different story passages.
The technical flow does not need to be rebuilt for each scene.
The interpreter reads the next element, processes it and invokes the corresponding application callback. The story supplies the sequence; the game supplies the presentation.
In the project: Processing routes text, links and instructions to their respective callbacks.
Repeated wiring becomes a shared tool.
Automatically processed stories still need observable stopping points. The example resolves pauses and lets the flow be followed through to the reported end of the story.
In the project: The example connects interruption, continuation and completion events.
The automated progression remains observable.
Harpin exists as a standalone TypeScript library. Its reusable progression logic is intended to free attention for dialogue, choices and the effect of a scene.
In the project: The package exposes the interpreter and its types for integration.
A tool of my own in service of a creative idea.
02 / Work
I am Gregor Woitczyk. I develop software, run systems and invent worlds. I want to understand how things connect – and what that understanding makes possible.
Software · Infrastructure · Operations
I develop applications, interfaces and the infrastructure behind them. With Linux, containers and Ansible, I turn recurring operational work into executable steps with results we can check. Development, testing and operations belong together.
AI · Automation · Process control
With Aven, I am developing tools to coordinate people, AI agents and their work. Aven CLI is the local runtime; Penbleth builds on it. Within ALINA, I also work on connecting and running local AI models.
Explore AvenCIRCUMRADIUS · Medical devices
I am co-founder and technical director of CIRCUMRADIUS, the medical device manufacturer formerly known as Die Hobrechts. My work on RADIUS and experience from several audits connect software development with traceable decisions and processes that have to work in everyday practice.
Games · Rules · Interaction
Game development is part of my work, from Motorsportmanager to Die Wimmelburg HD, which I worked on as a co-founder of Die Hobrechts. With Harpin, I also develop a tool of my own that connects written stories to controllable game progression.
Writing · Worldbuilding · Conlanging
With Gelariad, I am developing an imagined world for stories. Through conlanging, I explore sounds, word formation and writing systems. Rules, history and language need to fit together, even when it all starts with an invented idea.
Recognition
03 / Perspective
I work with dependable intermediate results. Like tested climbing anchors, they support the next move. A cause I understand, a working prototype, a reliable process: each makes it possible to move on and adjust the route as I learn, without unnecessary rework.
I want to build things that work without continually demanding our time. That leaves room for what comes next.
04 / Contact
Tell me what you are working on: a system that keeps needing attention, an unclear process or an idea you want to bring to life.
