Thousand Year Old Vampire: Difference between revisions
No edit summary |
|||
| Line 1: | Line 1: | ||
{{Infobox | {{Infobox software | ||
| | | name = Thousand Year Old Vampire - Web Helper | ||
| | | developer = Michel Vuijlsteke | ||
| programming language = Python, TypeScript | |||
| | | operating system = Cross-platform (Web) | ||
| | | genre = Solo RPG digital companion | ||
| | | license = Custom | ||
| | | website = <code>https://tyov.yusupov.cloud</code> | ||
| | |||
}} | }} | ||
'''Thousand Year Old Vampire | '''Thousand Year Old Vampire - Web Helper''' ('''TYOV-Web''') is a browser-based adaptation of the solo role-playing game ''Thousand Year Old Vampire'' by Tim Hutchings. Rather than presenting the game as a digital board game or a rules spreadsheet, it treats a campaign as a long, accumulating chronicle: a vampire begins with a handful of memories, gains new experiences, loses old ones, and leaves behind a life story made of fragments, scars, names, and vanished centuries. The application is built as a '''Django''' backend serving a '''Vue''' single-page frontend, but its real achievement is literary rather than merely technical: it turns bookkeeping-heavy solo play into something that feels legible, mournful, and continuous. | ||
== | == Premise == | ||
''Thousand Year Old Vampire'' | In ''Thousand Year Old Vampire'', the player does not manage hit points, armies, or territory. Instead, the player manages '''memory'''. A vampire may survive for centuries, but cannot perfectly retain those centuries. New experiences force older ones aside. Friends die. Languages decay. Identities are traded, abandoned, or forgotten. The drama comes from watching the self narrow and distort over time. | ||
TYOV-Web | TYOV-Web preserves that central idea. A player creates a vampire from mortal beginnings, plays through prompts generated by dice rolls, writes narrative responses to those prompts, and organises the resulting fragments into memories. Over time the character collects skills, resources, marks, and known companions, but those are unstable possessions. The most important question is never simply ''what happened?'' It is ''what can still be remembered?'' | ||
== | == How Play Works == | ||
The application follows the structure of the tabletop game closely, but presents it as a guided story engine. Character creation unfolds in six stages: mortal life, mortal relationships, skills, resources, a defining early experience, and finally the turning into vampirism. Once play begins, each turn revolves around a prompt. The player reads the current prompt, writes at least one experience in response, manages any consequences on the character sheet, then rolls a ten-sided die and a six-sided die to discover the next destination in the prompt list. | |||
That movement is what gives the game its broken historical rhythm. A positive result on D10 minus D6 pushes the vampire forward; a negative result drags the story backward into earlier themes or alternative branches. Prompts are also divided into variations, so revisiting a number does not necessarily mean revisiting the same moment in the same way. | |||
The memory system gives the application its emotional pressure. A character can normally hold only '''five active memories''', and each memory can contain no more than '''three experiences'''. When that limit is reached, the player must decide what to lose. Some memories can be moved into a '''diary''', which acts as an external repository, but diaries themselves are only resources, and resources can be lost. The result is a game about narrative curation: the player is constantly deciding which version of the vampire's past deserves to remain visible. | |||
Special prompts can alter that rhythm. Some disable experience-writing for a turn. Others allow the vampire's name to change, permit the editing of old experiences, reduce or increase permanent memory capacity, or end the chronicle entirely with an epilogue. TYOV-Web exposes these rules clearly during play, but the rules never overwhelm the fiction. They exist to sharpen it. | |||
== An Example Unlife: Karmis == | |||
The most compelling way to understand the application is through one of its stored characters. One campaign in the database follows '''Karmis''', formerly '''Ekurzu''' and before that '''Naram''', across roughly three and a half thousand years. | |||
He begins in Bronze Age Mari as a temple scribe: precise, observant, and deeply embedded in the religious and political machinery of the city. His mortal life is defined by clay tablets, whispered intelligence, and courtly danger. He falls in love with Hessa, is shaped by the mentorship of the high priest Ibbi-Zamri, and is eventually turned by the ancient vampire Ashurban the Veiled. In one of the campaign's defining cruelties, Ibbi-Zamri becomes the first person Karmis kills after the turning. | |||
The early centuries of his unlife are marked by exile and shame. He flees with Ennatum, struggles to master the hunger, tries to imagine restraint as redemption, and fails. One of the campaign's most effective lines comes from this period: he builds walls and plays flutes in the wilderness, but it is "never penance, only a cage with softer bars." Eventually he devours Ennatum during a sandstorm and carries that loss into the long middle stretch of the story. | |||
From there the campaign moves through one civilisation after another. Karmis passes through Akhenaten's Egypt, the imperial roads of the Achaemenids, the scholarly world of Alexandria, Roman frontiers, monastic Europe, Mediterranean trade routes, and the violence of the early modern Atlantic world. His roles change less than the world around him does. He remains a scribe, witness, forger, archivist, and careful observer of institutions that never last as long as he does. | |||
The campaign also shows how the game's systems create character rather than merely recording it. Karmis gains skills such as ''Silent Cartography'', the ability to trace unseen paths of influence, and ''Ash-Tongue'', a talent for insinuation and social survival. But he loses others as time damages his identity. He once knew how to decipher ancient texts; later he no longer can. He once believed he could control the beast within; later even that confidence disappears. The mechanics translate immortality into erosion. | |||
One of the campaign's richest relationships is with '''Thooni''', a scholar who recognises the name ''Ekurzu'' not as legend but as continuity. After her mortal death, the relationship persists in altered form: a spectral Thooni begins appearing in the margins of Karmis's diary, leaving fragments in languages he can no longer read. TYOV-Web handles this elegantly because its model of a character is not limited to a living cast list. People can be present, absent, lost, remembered, or transformed into symbols the protagonist can no longer fully interpret. | |||
By the late Roman and early medieval portions of the chronicle, the cost of the memory rules becomes brutal. Karmis loses so many memories that even the event of his own turning is no longer available to him. He relies on diaries and external records to stabilise himself, yet those too are vulnerable. A carved chamber called ''The Walls of Forgetting'' and a later monastery diary both disappear. The application does not treat this as simple inventory loss; it feels instead like a second death for pieces of the self. | |||
In the final act, Karmis witnesses the Atlantic slave trade and begins keeping a ledger of names drawn from shipping manifests and punishment records. A later response captures the moral exhaustion of the character with unusual sharpness: he no longer imagines himself purified by restraint, only redirected by purpose. He feeds on slavers and calls it justice, yet recognises that the blood tastes the same. This is the kind of line the application is built to preserve: not just event logs, but accumulations of ethical fatigue. | |||
His last great companion is '''Mirelde of Bracha''', who becomes mirror, partner, and eventually historian. By the time the epilogue arrives, the story is no longer told in Karmis's own voice. Mirelde writes the closing judgment on him: not as a monster laid to rest, but as "just a man who remembered too much, for too long, and chose, in the end, peace." That shift in narrator is exactly the sort of late-game turn TYOV-Web makes easy to sustain, because it keeps the campaign legible even after the protagonist himself has become unreliable. | |||
== Why the Application Works == | |||
What makes TYOV-Web effective is not that it digitises every rule, though it largely does. Its strength is that it understands which parts of the original game are dramatically important and places those at the centre of the interface. | |||
The main play screen is organised around the prompt, the character sheet, and the memory display. The prompt is always the immediate literary provocation. The memory display constantly reminds the player of pressure and loss: active memories, diary memories, and forgotten memories sit in visible relation to one another. Skills, resources, marks, and known characters are editable in place, which means the character sheet grows and collapses alongside the fiction instead of feeling like a separate administrative surface. | |||
The result is a frontend that behaves less like a dashboard and more like a writing desk. Players move between the prompt text, the experience form, and the fragments of the vampire's surviving life. Even when the application is doing something purely mechanical, such as validating whether the player may continue, the effect is narrative: it is asking whether the current moment of the story has been fully accounted for. | |||
== The Frontend as Chronicle == | |||
The client side of TYOV-Web is a '''Vue 3''' single-page application written in '''TypeScript'''. In practical terms, this means the entire experience unfolds without page reloads; in literary terms, it allows the game to feel continuous. The player logs in, sees a home screen of active and archived characters, enters a creation wizard for new vampires, and then spends most of the campaign inside a single evolving game view. | |||
That view is supported by a set of focused screens: a login page, a home dashboard, the six-step character creation flow, the main game interface, an ending screen for completed chronicles, an archive view, and a story view that presents the campaign as a timeline. Around those are a collection of smaller windows and dialogs for editing characters, skills, resources, memories, and experiences. These are important not because there are many of them, but because they preserve the sense that a campaign is always open to revision, annotation, and reinterpretation. | |||
State is held in Pinia stores for authentication, gameplay, character creation, and theme. That is an implementation detail, but in this case it serves a visible purpose: it keeps the player's character, current prompt, pending changes, and validation state coherent at all times. The interface never feels as if it has forgotten where the player is in the life of the vampire. | |||
== | == The Backend as Memory Keeper == | ||
Behind the interface is a '''Django 5''' application with a REST API built on '''Django REST Framework'''. The backend models the campaign in the same terms the game itself cares about: '''Character''', '''Memory''', '''Experience''', '''Skill''', '''Resource''', '''Mark''', '''GameCharacter''', '''Prompt''', and '''PendingChange'''. This is not especially glamorous architecture, but it is disciplined. The data model is close to the language of play, which makes the whole system easier to reason about. | |||
The most interesting design choice is the use of '''pending changes'''. TYOV-Web does not immediately finalise every action the player takes. Instead, new experiences and character-sheet adjustments can accumulate as provisional edits until the player chooses to continue the story. Only then are they committed atomically. This makes the system feel less like a CRUD application and more like a drafting process. A turn can be assembled, reconsidered, and only then sealed into the chronicle. | |||
Authentication is handled by JWT tokens, and character data is scoped to the authenticated user. The backend exposes endpoints for the game state itself, dice rolling, story continuation, and CRUD operations on memories, experiences, skills, resources, marks, and known characters. In the article, however, the important point is not the shape of the URLs. It is that the backend has been designed to support a narrative workflow rather than a generic records system. | |||
== Audit Trail == | == Audit Trail == | ||
One of the application's strongest features is its audit trail. Each time the player advances to a new prompt, TYOV-Web captures a complete snapshot of the game state: prompt transition, dice roll, character sheet, memories, and the set of changes applied on that turn. In effect, the application keeps both the ''current'' vampire and the ''history of how that vampire became current''. | |||
'' | |||
This matters for more than debugging. In a game built around forgetting, a turn-by-turn archive becomes part of the theme. The player may choose to lose a memory inside the fiction, but the application still preserves the fact that the loss occurred. The vampire forgets; the chronicle does not. | |||
== Development and Deployment == | |||
= | TYOV-Web is developed as a two-part web project: Django on the server side, Vue on the client side. In local development the repository can be started with a PowerShell bootstrap script, which creates the Python environment, installs dependencies, runs migrations, and launches both servers. In production, the frontend is built with Vite and the backend is configured through the usual Django environment settings, including a production mode selected with <code>DJANGO_ENV=production</code>. | ||
Testing exists on both sides of the stack. The backend is covered with '''pytest''' and '''pytest-django'''; the frontend uses '''Playwright''' for end-to-end coverage of the creation flow and core game loop. Those details are reassuring, but secondary. The more meaningful point is that the project has been built as an actual maintained application rather than a one-off prototype. | |||
== Reception Within the Project == | |||
As a fan-made implementation, TYOV-Web is best understood as an act of interpretation. It does not try to replace the tabletop experience with spectacle. Instead it asks what a web application can do well for this particular game: preserve long-form writing, reduce clerical overhead, make memory pressure visible, and retain the full history of a life that the protagonist can no longer fully remember. In that sense it is not merely a helper app. It is a machine for turning play into biography. | |||
== See Also == | == See Also == | ||
* ''Thousand Year Old Vampire'' by Tim Hutchings | * ''Thousand Year Old Vampire'' by Tim Hutchings | ||
* [[Django (web framework)]] | * [[Django (web framework)]] | ||
* [[Vue.js]] | * [[Vue.js]] | ||
Revision as of 11:33, 12 April 2026
Thousand Year Old Vampire - Web Helper (TYOV-Web) is a browser-based adaptation of the solo role-playing game Thousand Year Old Vampire by Tim Hutchings. Rather than presenting the game as a digital board game or a rules spreadsheet, it treats a campaign as a long, accumulating chronicle: a vampire begins with a handful of memories, gains new experiences, loses old ones, and leaves behind a life story made of fragments, scars, names, and vanished centuries. The application is built as a Django backend serving a Vue single-page frontend, but its real achievement is literary rather than merely technical: it turns bookkeeping-heavy solo play into something that feels legible, mournful, and continuous.
Premise
In Thousand Year Old Vampire, the player does not manage hit points, armies, or territory. Instead, the player manages memory. A vampire may survive for centuries, but cannot perfectly retain those centuries. New experiences force older ones aside. Friends die. Languages decay. Identities are traded, abandoned, or forgotten. The drama comes from watching the self narrow and distort over time.
TYOV-Web preserves that central idea. A player creates a vampire from mortal beginnings, plays through prompts generated by dice rolls, writes narrative responses to those prompts, and organises the resulting fragments into memories. Over time the character collects skills, resources, marks, and known companions, but those are unstable possessions. The most important question is never simply what happened? It is what can still be remembered?
How Play Works
The application follows the structure of the tabletop game closely, but presents it as a guided story engine. Character creation unfolds in six stages: mortal life, mortal relationships, skills, resources, a defining early experience, and finally the turning into vampirism. Once play begins, each turn revolves around a prompt. The player reads the current prompt, writes at least one experience in response, manages any consequences on the character sheet, then rolls a ten-sided die and a six-sided die to discover the next destination in the prompt list.
That movement is what gives the game its broken historical rhythm. A positive result on D10 minus D6 pushes the vampire forward; a negative result drags the story backward into earlier themes or alternative branches. Prompts are also divided into variations, so revisiting a number does not necessarily mean revisiting the same moment in the same way.
The memory system gives the application its emotional pressure. A character can normally hold only five active memories, and each memory can contain no more than three experiences. When that limit is reached, the player must decide what to lose. Some memories can be moved into a diary, which acts as an external repository, but diaries themselves are only resources, and resources can be lost. The result is a game about narrative curation: the player is constantly deciding which version of the vampire's past deserves to remain visible.
Special prompts can alter that rhythm. Some disable experience-writing for a turn. Others allow the vampire's name to change, permit the editing of old experiences, reduce or increase permanent memory capacity, or end the chronicle entirely with an epilogue. TYOV-Web exposes these rules clearly during play, but the rules never overwhelm the fiction. They exist to sharpen it.
An Example Unlife: Karmis
The most compelling way to understand the application is through one of its stored characters. One campaign in the database follows Karmis, formerly Ekurzu and before that Naram, across roughly three and a half thousand years.
He begins in Bronze Age Mari as a temple scribe: precise, observant, and deeply embedded in the religious and political machinery of the city. His mortal life is defined by clay tablets, whispered intelligence, and courtly danger. He falls in love with Hessa, is shaped by the mentorship of the high priest Ibbi-Zamri, and is eventually turned by the ancient vampire Ashurban the Veiled. In one of the campaign's defining cruelties, Ibbi-Zamri becomes the first person Karmis kills after the turning.
The early centuries of his unlife are marked by exile and shame. He flees with Ennatum, struggles to master the hunger, tries to imagine restraint as redemption, and fails. One of the campaign's most effective lines comes from this period: he builds walls and plays flutes in the wilderness, but it is "never penance, only a cage with softer bars." Eventually he devours Ennatum during a sandstorm and carries that loss into the long middle stretch of the story.
From there the campaign moves through one civilisation after another. Karmis passes through Akhenaten's Egypt, the imperial roads of the Achaemenids, the scholarly world of Alexandria, Roman frontiers, monastic Europe, Mediterranean trade routes, and the violence of the early modern Atlantic world. His roles change less than the world around him does. He remains a scribe, witness, forger, archivist, and careful observer of institutions that never last as long as he does.
The campaign also shows how the game's systems create character rather than merely recording it. Karmis gains skills such as Silent Cartography, the ability to trace unseen paths of influence, and Ash-Tongue, a talent for insinuation and social survival. But he loses others as time damages his identity. He once knew how to decipher ancient texts; later he no longer can. He once believed he could control the beast within; later even that confidence disappears. The mechanics translate immortality into erosion.
One of the campaign's richest relationships is with Thooni, a scholar who recognises the name Ekurzu not as legend but as continuity. After her mortal death, the relationship persists in altered form: a spectral Thooni begins appearing in the margins of Karmis's diary, leaving fragments in languages he can no longer read. TYOV-Web handles this elegantly because its model of a character is not limited to a living cast list. People can be present, absent, lost, remembered, or transformed into symbols the protagonist can no longer fully interpret.
By the late Roman and early medieval portions of the chronicle, the cost of the memory rules becomes brutal. Karmis loses so many memories that even the event of his own turning is no longer available to him. He relies on diaries and external records to stabilise himself, yet those too are vulnerable. A carved chamber called The Walls of Forgetting and a later monastery diary both disappear. The application does not treat this as simple inventory loss; it feels instead like a second death for pieces of the self.
In the final act, Karmis witnesses the Atlantic slave trade and begins keeping a ledger of names drawn from shipping manifests and punishment records. A later response captures the moral exhaustion of the character with unusual sharpness: he no longer imagines himself purified by restraint, only redirected by purpose. He feeds on slavers and calls it justice, yet recognises that the blood tastes the same. This is the kind of line the application is built to preserve: not just event logs, but accumulations of ethical fatigue.
His last great companion is Mirelde of Bracha, who becomes mirror, partner, and eventually historian. By the time the epilogue arrives, the story is no longer told in Karmis's own voice. Mirelde writes the closing judgment on him: not as a monster laid to rest, but as "just a man who remembered too much, for too long, and chose, in the end, peace." That shift in narrator is exactly the sort of late-game turn TYOV-Web makes easy to sustain, because it keeps the campaign legible even after the protagonist himself has become unreliable.
Why the Application Works
What makes TYOV-Web effective is not that it digitises every rule, though it largely does. Its strength is that it understands which parts of the original game are dramatically important and places those at the centre of the interface.
The main play screen is organised around the prompt, the character sheet, and the memory display. The prompt is always the immediate literary provocation. The memory display constantly reminds the player of pressure and loss: active memories, diary memories, and forgotten memories sit in visible relation to one another. Skills, resources, marks, and known characters are editable in place, which means the character sheet grows and collapses alongside the fiction instead of feeling like a separate administrative surface.
The result is a frontend that behaves less like a dashboard and more like a writing desk. Players move between the prompt text, the experience form, and the fragments of the vampire's surviving life. Even when the application is doing something purely mechanical, such as validating whether the player may continue, the effect is narrative: it is asking whether the current moment of the story has been fully accounted for.
The Frontend as Chronicle
The client side of TYOV-Web is a Vue 3 single-page application written in TypeScript. In practical terms, this means the entire experience unfolds without page reloads; in literary terms, it allows the game to feel continuous. The player logs in, sees a home screen of active and archived characters, enters a creation wizard for new vampires, and then spends most of the campaign inside a single evolving game view.
That view is supported by a set of focused screens: a login page, a home dashboard, the six-step character creation flow, the main game interface, an ending screen for completed chronicles, an archive view, and a story view that presents the campaign as a timeline. Around those are a collection of smaller windows and dialogs for editing characters, skills, resources, memories, and experiences. These are important not because there are many of them, but because they preserve the sense that a campaign is always open to revision, annotation, and reinterpretation.
State is held in Pinia stores for authentication, gameplay, character creation, and theme. That is an implementation detail, but in this case it serves a visible purpose: it keeps the player's character, current prompt, pending changes, and validation state coherent at all times. The interface never feels as if it has forgotten where the player is in the life of the vampire.
The Backend as Memory Keeper
Behind the interface is a Django 5 application with a REST API built on Django REST Framework. The backend models the campaign in the same terms the game itself cares about: Character, Memory, Experience, Skill, Resource, Mark, GameCharacter, Prompt, and PendingChange. This is not especially glamorous architecture, but it is disciplined. The data model is close to the language of play, which makes the whole system easier to reason about.
The most interesting design choice is the use of pending changes. TYOV-Web does not immediately finalise every action the player takes. Instead, new experiences and character-sheet adjustments can accumulate as provisional edits until the player chooses to continue the story. Only then are they committed atomically. This makes the system feel less like a CRUD application and more like a drafting process. A turn can be assembled, reconsidered, and only then sealed into the chronicle.
Authentication is handled by JWT tokens, and character data is scoped to the authenticated user. The backend exposes endpoints for the game state itself, dice rolling, story continuation, and CRUD operations on memories, experiences, skills, resources, marks, and known characters. In the article, however, the important point is not the shape of the URLs. It is that the backend has been designed to support a narrative workflow rather than a generic records system.
Audit Trail
One of the application's strongest features is its audit trail. Each time the player advances to a new prompt, TYOV-Web captures a complete snapshot of the game state: prompt transition, dice roll, character sheet, memories, and the set of changes applied on that turn. In effect, the application keeps both the current vampire and the history of how that vampire became current.
This matters for more than debugging. In a game built around forgetting, a turn-by-turn archive becomes part of the theme. The player may choose to lose a memory inside the fiction, but the application still preserves the fact that the loss occurred. The vampire forgets; the chronicle does not.
Development and Deployment
TYOV-Web is developed as a two-part web project: Django on the server side, Vue on the client side. In local development the repository can be started with a PowerShell bootstrap script, which creates the Python environment, installs dependencies, runs migrations, and launches both servers. In production, the frontend is built with Vite and the backend is configured through the usual Django environment settings, including a production mode selected with DJANGO_ENV=production.
Testing exists on both sides of the stack. The backend is covered with pytest and pytest-django; the frontend uses Playwright for end-to-end coverage of the creation flow and core game loop. Those details are reassuring, but secondary. The more meaningful point is that the project has been built as an actual maintained application rather than a one-off prototype.
Reception Within the Project
As a fan-made implementation, TYOV-Web is best understood as an act of interpretation. It does not try to replace the tabletop experience with spectacle. Instead it asks what a web application can do well for this particular game: preserve long-form writing, reduce clerical overhead, make memory pressure visible, and retain the full history of a life that the protagonist can no longer fully remember. In that sense it is not merely a helper app. It is a machine for turning play into biography.
See Also
- Thousand Year Old Vampire by Tim Hutchings
- Django (web framework)
- Vue.js
- Single-page application