> For the complete documentation index, see [llms.txt](https://docs.asphodel.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.asphodel.io/whitepaper/architecture/how-we-build-it.md).
# How We Build It
Trying to build monolithic decentralized systems in one shot doesn't work. The process of creating any major decentralized protocol rewards flexibility, transparency, and building progressively in public. Almost everyone who has tried to build 'conventional' games on a blockchain so far has failed.
So our approach to building Asphodel is open-source, modular, and realistic. We're not building Asphodel as a single traditional game - we're building a series of composable parts, individual worlds that together make up a coherent universe. We deploy and test individual components - for real, in production - refine them with users, and establish them as permanent parts of the game. Then we move to build new systems, new features, new areas - and we expand our worlds piece by piece.
Building onchain makes this possible, even comfortable, and it allows us to focus on security and battle-testing each component such that we can lower the risk of serious technical issues or attacks. We can also re-use proven technology and smart contracts to allow us to develop faster while constraining risk.
This means Asphodel currently spans two blockchains, two worlds, and two games. There will be more.
## In Practice...
To give a practical example: the Prologue, the first part of Asphodel to be released on mainnet, serves a few functions.
1. It's a self-contained PvP battle mode that allows players to enjoy our combat systems for the first time, and lets us refine our approach to doing asynchronous PvP on a blockchain. This lets us get this combat system refined enough to expand it into Kamigotchi and to add new game modes to Asphodel on mainnet. From this perspective it is our PvP prototype - it actually began life as a PvP system for Kamigotchi World before we realized it could live on Ethereum.
2. It has its own tournament systems and fuels its own incentives, allowing it to run as a self-contained game indefinitely. It's important to us that the Prologue can run literally forever alongside the rest of the game - it should always be there, unchanged. The simple, classic core PvP mode will always be an option. From this perspective it is its own game - Asphodel itself in microcosm.
3. The Taruchi that winners claim as NFTs can be used as playable characters in other parts of Asphodel - future game modes, possibly in Kamigotchi, and so on. This means the game, despite being self contained, naturally feeds into other game modes and can always do so. From this perspective it is a unique NFT mint mechanism, something like a Darwinian version of Nouns.
We won't expand Asphodel further by messing with the Prologue game mode - we plan to release exactly 3 significant patches/updates before we renounce contract ownership and let it run forever. Then we'll move on to building new game modes that use the Taruchi (and the Kamigotchi) and expand on our battle systems in other ways.
In this way, we can build out a much larger game ecosystem, and one built to last, out of self-contained components - and users can trust that the game will keep updating and expanding *without* the existing systems they love being forced to change.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.asphodel.io/whitepaper/architecture/how-we-build-it.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.