🎮
Blade Games
  • Blade Games Whitepaper
    • Blade Games
  • BLADE GAMES OVERVIEW
    • Who We Are
    • Key Partnerships
    • Our Team
  • Dune Factory
    • Gameplay, Play-and-Mine
      • Dune Factory Gameplay Guide
      • Play-and-Mine (Please Wait For New Season)
      • Resources
      • Monster Compendium
    • Private Test (Finished)
      • Must-knows
      • Invite Codes
    • Dune Factory Public Test
  • AI Agents in Blade Games
    • Blade Games AI Agent Overview
    • Our Design Framework
    • How AI Agents Drive Revenue in the Ecosystem
    • Blade Games AI Agent Use Cases
    • Blade Games AI Agent Plan
    • Games Ecosystem That You Can Play
  • ZKUNITY - GAME ENGINE
    • ZKUnity Guide
      • zkWASM
      • ZKUnity
      • Architecture
      • MVC Programming Pattern
      • Demo - a roguelike card game
        • Prerequisites
        • How to run
        • How to play
        • Dir Structure
        • Guide for the backend code
        • Guide for the frontend code
        • ZK Proof
  • Tokenomics
    • Token Utility
    • Token Distribution/Allocation
    • Treasury Wallets Disclosure
  • Important
    • Roadmap
    • Feedback
    • Investors
    • Official Links
Powered by GitBook
On this page
  1. ZKUNITY - GAME ENGINE
  2. ZKUnity Guide
  3. Demo - a roguelike card game

Guide for the backend code

This is a simple guide for the backend code structure, therefore we will not discuss every line of this codebase. Its structure looks like this:

.
├── Cargo.lock
├── Cargo.toml
├── Makefile
├── crates
│   ├── bin
│   │   ├── Cargo.toml
│   │   └── src
│   │       └── bin.rs
│   └── core
│       ├── Cargo.toml
│       └── src
│           ├── config.rs
│           ├── engine
│           │   ├── cards
│           │   │   ├── defend.rs
│           │   │   ├── mod.rs
│           │   │   └── strike.rs
│           │   ├── combat.rs
│           │   ├── mod.rs
│           │   ├── roles
│           │   │   ├── enemy
│           │   │   │   ├── mod.rs
│           │   │   │   └── monster
│           │   │   │       ├── mod.rs
│           │   │   │       ├── robot.rs
│           │   │   │       └── turkey.rs
│           │   │   ├── mod.rs
│           │   │   └── player.rs
│           │   └── state.rs
│           ├── lib.rs
│           ├── test.rs
│           ├── utils
│           │   ├── mod.rs
│           │   └── state.rs
│           └── wasm
│               └── mod.rs
├── rust-toolchain
└── test_cli.sh

The main logic body of the game is defined in the `engine` subdirectory. As you can see, it is a relatively simple turn-based game, which defines cards, roles, combat, etc.

The player and monsters both have `HP` representing their left life. They use handy cards to attack the opponent or defend himself.

There are two monsters: a robot and a turkey.

In `engine/mod.rs`, there is a definition of Engine:

pub struct Engine {
    pub(crate) player: Player,
    pub floor: usize,
}

It seems just preliminary right now, but enough for a demo.

In `utils/state.rs`, it defines the global game state singleton:

#[derive(Serialize)]
pub struct GameState {
    floor: usize,
    turn: usize,

    hero_hp: i32,
    hero_power: i32,
    hero_block: i32,
    hand_of_card: Vec<Card>,

    enemy_name: &'static str,
    enemy_hp: i32,
    enemy_block: i32,
    enemy_action: SkillEffect,
}

The game will use this GameState to manage the state of the instance of this roguelike card game.

Another important component is the `wasm/mod.rs`, it bridges the game and the underneath zkwasm SDK. Let's look into it:

use wasm_bindgen::prelude::wasm_bindgen;
use zkwasm_rust_sdk::require;
use zkwasm_rust_sdk::jubjub::BabyJubjubPoint;
use zkwasm_rust_sdk::jubjub::JubjubSignature;
use zkwasm_rust_sdk::wasm_input;
use primitive_types::U256;
use sha2::{Sha256, Digest};

As you can see, we import some functionalities from zkwasm_rust_sdk.

We will compile this Rust project into wasm target, and the target wasm file will contain some facilities provided by zkwasm.

In the same file, we find:

#[wasm_bindgen]
pub fn zkmain() {
}

The zkmain() is the entry of this game project.

Compile method

Given the output of this backend implementation are some wasm files, how to compile it, and how to export it to frontend is a challege.

We use a Makefile to overcome it. In the `Makefile`, we can see:

wasm:
	wasm-pack build --release crates/core --out-name gameplay --out-dir pkg
	cp crates/core/pkg/gameplay.d.ts ../src/games/roguelike/js/gameplay.d.ts
	cp crates/core/pkg/gameplay_bg.wasm ../src/games/roguelike/js/gameplay_bg.wasm
	cp crates/core/pkg/gameplay_bg.wasm.d.ts ../src/games/roguelike/js/gameplay_bg.wasm.d.ts
	cp crates/core/pkg/gameplay_bg.js ../src/games/roguelike/js/gameplay_bg.js

While we run `make wasm` in the game backend directory, it actually uses wasm-pack to execute the process of compilation. This process will compile wasm files to the pkg dir, and copy those facilities to the frontend directory. Then the frontend code can import these wasm files and call the functions written by Rust.

PreviousDir StructureNextGuide for the frontend code

Last updated 11 months ago