---
tags: Sequencer-dungeon-presentation
---

# Dungeon-crawler game (POC)

---

## Introduction

A rollup DApp for an interactive game. This "kernel" is a program run using <span style="color:green">rollup kernel-SDK</span>, <span style="color:green">sequencer prototype</span> (low-latency node) and <span style="color:green">React App</span> front-end.

---

## Motivation
* It is a second big kernel example after Tzwitter.
* Add a realistic example to demonstrate how to write WASM kernels to <span style="color:green">attract game devs</span>.
* Illustrate the use of a <span style="color:green">sequencer</span> to achieve low latency with a Smart Rollup.

----

## Motivation
* Identifies <span style="color:green">missing</span> tool/UX/etc. for the kernel-SDK, and sequencer prototype.
* Give ways to <span style="color:green">stress</span> test the sequencer (Multi-players: ~10-100 players real-time interaction for instance).

---

## Current features

- Light <span style="color:green">multi-players</span> (2 players) interact with each other in real-time.
- Light <span style="color:green">connection</span> with wallet (hardcode secret keys).
- Exchange <span style="color:green">assets</span>: drop, pick up, sell, and buy item.
- Run on Marigold <span style="color:green">[Ghostnet](https://ghostnet.dungeon.marigold.dev/)</span>.

<span style="color:green">Total: ~4 weeks</span>

----

## Current features (cont.)

- Thanks the sequencer prototype: each action of the player is <span style="color:green">fast</span> (we don't have to wait for 2 blocks to process and verify).
- Those operations at the end will be process and verify by <span style="color:green">the rollup</span>.
- Currently, each <span style="color:green">500ms</span> the Dapp will request the sequencer for the state.
- And it is <span style="color:green">0.5s</span> for latency.

----

## Feedback

- Dapp
- Deserialisation of messages/state from the dApp is <span style="color:green">complicated</span>, because data are encoded in a binary format.
- <span style="color:green">proxy server</span> to help encoding/decoding data from the rollup node.<!-- proxy server is inside sequencer atm, but they can be indenpendence -->
- Sequencer:
- Expose several <span style="color:green">bugs</span> on sequencer: `store_write`, `sub_keys` functions.

----

## Roadmap
- <span style="color:green">Features</span>:
- Connect with wallet (ETC: 1 week/1 dev)
- Dungeon generation (ETC: 2 days)
- Better sprite for UI (ETC: 2 weeks)
- Ticket (ETC: 2 weeks)
- Upgrade kernel (ETC: 2 weeks) <!--(help to improve the deployment)-->

----

## Roadmap (cont.)
- Implement the <span style="color:green">reboot</span> for the kernel to continue consume the inbox when it nearly reach the limit (limit: 11 billions ticks x 1000 ops) (ETC: 2 days) <!--(kernel is limit: 11 billions of ticks; kernel entry call funtion 1000 times/block (11 billion x 1000). Need to implement reboot (flag in the kernel to call again the kernel entry function, count the number of ticks, near the limit reboot the kernel, and continue the consume the inbox)) kernel related-->
- <span style="color:green">Stress tests</span> (ETC: 2 weeks)
<!--user theory limit: 1000 operation/seconds, 100 players x move = 1 times in tx
- 1 rollup node process of 15.000 operations/seconds (theory)
compute the 15000:
(1000 * 11 billions) / 50m / 15s = ? operation/s (~15.000 operations)
40m of ticks to verify the signature and
kernel should not consume a lot of ticks (10milion)
so 50m/operation
- 800 operation/second (instead of 1000 operation)/signature verification
There is issue in rollup node.
- test like 10m tx test where the dungeon-kernel in tezt
-->

----

## Roadmap (cont.)
- <span style="color:green">Maintenance</span>:
- <span style="color:green">Move</span> the implement of dungeon on `marigold/kernel-gallery` to `tezos/kernel-gallery` (ETC: 1 week)
- <span style="color:green">Switch</span> to sequencer product ready (ETC: 1 hour)

----

## Roadmap (cont.)
- <span style="color:green">Maintenance</span> (cont.):
- using <span style="color:green">`NomReader`</span> and <span style="color:green">`BinEncode`</span> trait for serialization/deserialization in dungeon-kernel (ETC: 2 days)
- <span style="color:green">Optimize</span> dungeon-kernel: The number of write/read from durable storage is 2 times/op, optimize to 2 times/block instead (ETC: 3 days)
<!-- 2times/oper right now, optimize 2 times/block
Let say that there are 2 operations to move up the player:
1. Read the player state from the storage
2. Update the player
3. Write the player state to the storage
4. Read the player state from the storage
5. Update the player
6. Save the player to the durables storage
With optimization:
1. Read the player state from the storage
2. Update the player, one time
3. Update the player, a second time
4. Save the player position at the end of the block
Consume less ticks -> more operations -->

----

## Roadmap (cont.)
- <span style="color:green">Communication</span> plan: blog post, video demo, user manual, etc. (ETC: 1 week)
- Release <span style="color:green">full</span> game play on <span style="color:green">Mainnet (observer mode)</span> to hype on Smart Rollup (ETC: 3 days)<!--(observer mode, just listen to the inbox and compute the next state) 10x to commit to layer 1, without commiting -->

<span style="color:green">Total: ~11 weeks</span>

---

## Demo

---

## Links to the project

https://gitlab.com/marigold/kernel-gallery/-/tree/dungeon-game

https://ghostnet.dungeon.marigold.dev

---

## Questions

<!-- TODO: Think of possible questions that can asked, so we can prepare slices answer for it -->

---

<!-- Extra slices -->

## Workflow


---

## The whole game implement in the kernel?

- To show a full development cycle of a kernel. It is possible in the future, to optimise them.
- User experience and user interface is not on kernel.

----

## The sequencer/low-latency node in Rust

- Why do we implement the low-latency node in Rust?
- Rust is favorable to use in the game devs
- At current state, writing wasm module is best provided by Rust compiler (dev experience)
- Rust impose less runtime penalty which help to improve the low-latency goal

----

### The sequencer node in Rust/OCaml

- Can we reuse the kernel wasm dungeon on rust in the low-latency in OCaml?
- It should not be difficult to change the dungeon-kernel in Rust to use the low-latency whether it is written in Rust or OCaml.

----
<!--
## Demo plan

Multi-players
- Bob and alice appear on the map
- Interaction:
(2 players connect)
- Move Bob and Alice
- Bob and Alice each pickup an item
- Bob sells the item on the market place
- Alice buys that item
---
-->