Geometry Dash On-Chain Game

Arcade Transitional

game-appecs

Transitional example: This example uses an older Cougr pattern and is preserved for compatibility reference. For the current recommended approach, see snake.

Purpose and pattern

This example demonstrates a rhythm-platformer fixed-tick runner on Soroban with Cougr ECS concepts. It remains transitional while the arcade examples converge on the canonical snake GameApp architecture.

Public contract API

Function	Parameters	Return type	Description
`init_game`	`player: Address, level_id: u32`	`()`	Initializes a player level.
`jump`	`player: Address`	`()`	Applies the current mode input.
`update_tick`	`player: Address`	`()`	Advances the level simulation by one tick.
`get_state`	`player: Address`	`GameStatus`	Returns Playing, Crashed, or Completed.
`get_pos`	`player: Address`	`(i32, i32)`	Returns player position.
`get_score`	`player: Address`	`u32`	Returns distance-based score.
`get_mode`	`player: Address`	`u32`	Returns current mode identifier.

Architecture overview

contract entrypoint
  ├─ reads game state from Soroban storage
  ├─ applies input or tick systems
  └─ writes updated state back to storage

Player physics, mode, obstacle, and status components live in components.rs; motion/collision behavior lives in systems.rs.

Storage model

Storage class	Data	Why
Instance storage	Per-contract game state where used by this example.	Keeps small arcade state close to the contract instance.
Persistent storage	Player- or world-scoped state where the example needs durable keyed state.	Keeps game progress available across invocations.
Temporary storage	Not used.	The examples favor deterministic recalculation over ephemeral caches.

Main gameplay flow

Call the initialization function to create the starting state.
Submit an input action such as movement, jump, flap, rotation, or shoot.
Call the tick/update function to run deterministic simulation logic.
Query public getters for score, position, active state, or terminal status.
Stop when the game-over/completed condition is reached, or reset/reinitialize where supported.

Cougr APIs used

ComponentTrait and custom component modules document the ECS data boundary.
SimpleWorld, SimpleQueryBuilder, GameApp, ScheduleStage, or SystemConfig are used where this transitional example has already adopted the maintained runtime shape.
Auth, privacy, ZK, and standards APIs are intentionally not used; these arcade examples focus on deterministic game logic.

Build and test commands

cargo test
stellar contract build

Known limitations

Transitional code may preserve older storage or scheduling patterns for compatibility reference.
No authentication, matchmaking, real-time rendering, or production randomness is included.
One contract instance generally represents one game or one keyed set of player games.
For new work, prefer the canonical snake module split and GameApp tick wiring.

Cougr Documentation