Dungeon-crawler game (POC)
Introduction
A rollup DApp for an interactive game. This "kernel" is a program run using rollup kernel-SDK, sequencer prototype (low-latency node) and React App front-end.
Motivation
- It is a second big kernel example after Tzwitter.
- Add a realistic example to demonstrate how to write WASM kernels to attract game devs.
- Illustrate the use of a sequencer to achieve low latency with a Smart Rollup.
Motivation
- Identifies missing tool/UX/etc. for the kernel-SDK, and sequencer prototype.
- Give ways to stress test the sequencer (Multi-players: ~10-100 players real-time interaction for instance).
Current features
- Light multi-players (2 players) interact with each other in real-time.
- Light connection with wallet (hardcode secret keys).
- Exchange assets: drop, pick up, sell, and buy item.
- Run on Marigold Ghostnet.
Total: ~4 weeks
Current features (cont.)
- Thanks the sequencer prototype: each action of the player is fast (we don't have to wait for 2 blocks to process and verify).
- Those operations at the end will be process and verify by the rollup.
- Currently, each 500ms the Dapp will request the sequencer for the state.
- And it is 0.5s for latency.
Feedback
- Dapp
- Deserialisation of messages/state from the dApp is complicated, because data are encoded in a binary format.
- proxy server to help encoding/decoding data from the rollup node.
- Sequencer:
- Expose several bugs on sequencer:
store_write,sub_keysfunctions.
- Expose several bugs on sequencer:
Roadmap
- Features:
- 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)
Roadmap (cont.)
- Implement the reboot for the kernel to continue consume the inbox when it nearly reach the limit (limit: 11 billions ticks x 1000 ops) (ETC: 2 days)
- Stress tests (ETC: 2 weeks)
Roadmap (cont.)
- Maintenance:
- Move the implement of dungeon on
marigold/kernel-gallerytotezos/kernel-gallery(ETC: 1 week) - Switch to sequencer product ready (ETC: 1 hour)
- Move the implement of dungeon on
Roadmap (cont.)
- Maintenance (cont.):
- using
NomReaderandBinEncodetrait for serialization/deserialization in dungeon-kernel (ETC: 2 days) - Optimize dungeon-kernel: The number of write/read from durable storage is 2 times/op, optimize to 2 times/block instead (ETC: 3 days)
- using
Roadmap (cont.)
- Communication plan: blog post, video demo, user manual, etc. (ETC: 1 week)
- Release full game play on Mainnet (observer mode) to hype on Smart Rollup (ETC: 3 days)
Total: ~11 weeks
Demo
Questions
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.
Dungeon-crawler game (POC)
{"metaMigratedAt":"2023-06-18T05:12:34.033Z","metaMigratedFrom":"YAML","title":"Dungeon-crawler game (POC)","breaks":true,"contributors":"[{\"id\":\"cd528d3a-d940-44cd-b7e0-ba2bfafd4786\",\"add\":11114,\"del\":4924},{\"id\":\"dfe0d643-f332-4081-9df5-91f3c7fd7836\",\"add\":804,\"del\":12},{\"id\":\"09ec042c-67c9-4202-a7df-0f0c8410e4fa\",\"add\":5,\"del\":0}]"}