
๐น๏ธ Play the Game
Click here to play the full game - then scan the QR code or share the generated session URL to invite other players!
Tutorial Overview
This tutorial is structured as a progressive series of steps, each building upon the previous one. Youโll start with a simple asteroid simulation and end with a fully-featured multiplayer game:- Step 0: Basic asteroids (non-Multisynq)
- Step 1: Synchronized asteroids with Multisynq
- Step 2: Interactive spaceships with player controls
- Step 3: Shooting mechanics with blasters
- Step 4: Collision detection and asteroid destruction
- Step 5: Ship-asteroid collisions and debris
- Step 6: Scoring system
- Step 7: View smoothing for 60fps animation
- Step 8: Persistent highscore table
- Step 9: Mobile support and final polish
Each step includes full source code and a live demo so you can see the progression and test each feature as you build it.
Game Features
The finished game includes:- Multiplayer synchronization - All players see the same game state
- Player-controlled spaceships - Arrow keys or WASD for movement
- Shooting mechanics - Space bar to fire blasters
- Collision detection - Blasters destroy asteroids, asteroids destroy ships
- Scoring system - Points for destroying asteroids
- Persistent leaderboard - Highscores survive code changes
- Mobile support - Touch controls for mobile devices
- Smooth animation - 60fps rendering with view smoothing
- QR code sharing - Easy session sharing between devices
Step 0: Asteroids Floating Without Multisynq ๐ชจโ ๐ชจ
๐ Step 0 Resources
x
, y
) and angle (a
) properties, along with delta values (dx
, dy
, da
) for movement:
The
%
operator ensures objects wrap around the screen edges - when they leave one side, they appear on the other.Step 1: Asteroids Synchronized with Multisynq ๐ชจโก๐ชจ
๐ Step 1 Resources
- Model: The synchronized part (
Multisynq.Model
) - shared computation - View: The display part (
Multisynq.View
) - local rendering
- Model Class
- View Class
Critical concept: The computation looks exactly the same! No special data structures are needed. The only change is
this.future(50).move()
instead of setTimeout()
.Future Messages
The key innovation is thefuture()
method:
move()
method to be called again in 50ms, but synchronously across all clients. This is how you define an objectโs behavior over time in Multisynq.
Session Joining
The last few lines connect to a Multisynq session:Step 2: Spaceships Controlled by Players ๐น๏ธโก๐
๐ Step 2 Resources
Player Management
The game subscribes to join/exit events to manage players:Ship Controls
Each ship subscribes to input events from its specific player:View Input Handling
The view publishes input events to control the ship:Key insight: Publish/subscribe in Multisynq is used for view-to-model communication, not for synchronization between devices. The synchronization happens automatically!
Step 3: Firing a Blaster ๐น๏ธโกโขโขโข
๐ Step 3 Resources
Blaster Creation
When firing, the ship creates a new blast moving in its direction:Blast Lifecycle
Blasts automatically destroy themselves after a timeout:The
wellKnownModel("modelRoot")
pattern provides access to the main game object from any model class.Step 4: Break Up Asteroids When Hit by Blasts ๐ชจโก๐ฅ
๐ Step 4 Resources
Collision Detection
The game runs collision detection in its main loop:Asteroid Destruction
When hit, asteroids split into two smaller pieces:Performance insight: Even with hundreds of moving objects, thereโs no network congestion because positions are computed locally and synchronized automatically!
Step 5: Turn Ship Into Debris After Colliding with Asteroids ๐โก๐ฅ
๐ Step 5 Resources
Ship Damage State
Ships track their damage state with awasHit
property:
Visual Debris Effect
The view shows exploded ships with scattered line segments:The
wasHit
counter determines how far each line segment has drifted from the original position, creating a realistic explosion effect.Step 6: Score Points When Hitting an Asteroid with a Blast ๐ฅโก๐
๐ Step 6 Resources
Blast Ownership
Store a reference to the firing ship in each blast:Scoring System
When asteroids are hit, the firing ship gets points:Score Display
The view displays each playerโs score and highlights their own ship:Players can easily identify their own ship because itโs filled instead of just outlined.
Step 7: View-Side Animation Smoothing ๐คฉ
๐ Step 7 Resources
Why Smoothing?
- Model: Updates at 20fps (50ms intervals) for reliable synchronization
- View: Renders at 60fps (16ms intervals) for smooth animation
- Solution: Interpolate between model positions for smooth rendering
Smoothing Implementation
Use aWeakMap
to store rendering positions separate from model positions:
Rendering with Smoothing
Use smoothed positions for rendering:The smoothing factor of
0.3
works well for 20fps simulation with 60fps rendering, but can be adjusted for different scenarios.Step 8: Persistent Table of Highscores ๐ฅ๐ฅ๐ฅ
๐ Step 8 Resources
Understanding Persistence
- Automatic Snapshots
- Explicit Persistence
- Multisynq automatically saves session state
- State persists when all players leave
- BUT: Code changes create new sessions
Player Initials
Add an input field for player names:Highscore Management
Initialize highscores from persistent data:Scoring with Persistence
Update highscores when players score:Important: Design your persistence format carefully! Include version numbers so future code can interpret data from older versions.
Step 9: Support for Mobile etc. ๐ฑ
๐ Step 9 Resources
Mobile Features
- Touch controls for mobile devices
- WASD keys in addition to arrow keys
- Visible thrusters for better feedback
- Wrapped drawing for seamless screen edges
- Spawn protection to prevent immediate destruction
Wrapped Rendering
Objects near screen edges are drawn on both sides:Advanced Game ๐๐ซ
๐ฎ Even More Features
Thereโs an even more polished version with additional features at github.com/multisynq/multiblaster:
- Emoji shooting - If your initials contain an emoji, you shoot that emoji!
- Advanced graphics - Enhanced visual effects and animations
- Better mobile UX - Optimized touch controls and responsive design
Key Takeaways
๐ฏ Multisynq Patterns
๐ฏ Multisynq Patterns
- Model-View separation - Business logic in Model, rendering in View
- Future messages - Use
this.future(ms).method()
for timed actions - Pub/sub for input - View publishes events, Model subscribes
- No network programming - Synchronization is automatic
๐ง Game Development
๐ง Game Development
- Collision detection - Simple bounding box checks work well
- State management - Use properties and flags for game state
- Performance - Hundreds of objects with no network overhead
- Persistence - Use
persistSession()
for data that survives code changes
๐ฑ User Experience
๐ฑ User Experience
- View smoothing - Interpolate for smooth 60fps animation
- Input handling - Support keyboard, touch, and multiple control schemes
- Visual feedback - Clear indicators for player actions and state
- Cross-platform - Works on desktop and mobile without changes
Next Steps
Explore More Tutorials
Learn other Multisynq patterns and techniques
API Reference
Detailed documentation of all Multisynq APIs
Join Discord
Get help and share your creations
Build Your Game
Start building your own multiplayer experience
Remember: This tutorial shows just one way to structure a multiplayer game. Multisynq is flexible - you can adapt these patterns to fit your specific game design and requirements.