Comprehensive rules and conventions for developing an isometric topdown MMORPG with Three.js, Geckos.io, and Vite. Covers world organization, monster spawns, MCP architecture, collision systems, combat mechanics, and multi-entry Vite configuration.
This skill has safety concerns that you should review before use. Some patterns were detected that may pose a risk.Safety score: 60/100.
KillerSkills scans all public content for safety. Use caution before installing or executing flagged content.
Complete development guide for building an isometric topdown MMORPG with authoritative server architecture.
When implementing the game world:
1. **World Structure**
- Create a 200x200 unit world divided into biomes: SPAWN, FOREST_NORTH, FOREST_WEST, MOUNTAINS, PLAINS, SWAMP, RUINS
- Assign each biome unique density and scale for trees, rocks, and bushes
- Implement collision detection during generation to prevent object overlap
- Keep houses, fences, and special structures removed (temporary decision)
2. **Monster Spawn Areas**
- Distribute spawn areas across biomes with varying quantities, levels, and respawn times
- Currently implement goblins only
- Enable automatic, balanced respawns per region
3. **Client Interface**
- Display FPS and ping in real-time at top-left corner
Follow this pattern strictly:
1. **Model (Server-side)**
- Contains all game logic and entity state
- Acts as single source of truth
2. **Controller (Server-side)**
- Interprets inputs
- Orchestrates high-level logic
3. **Presenter (Client-side)**
- Handles rendering and input capture only
- Never contains game logic
**Critical**: Always follow these principles:
Use the `category:action` format for all network events:
```javascript
// Examples
'player:move'
'monster:spawn'
'world:init'
```
Define all events in `shared/constants/gameConstants.js`.
1. **Initial Connection**: Server sends unique ID via `player:init`
2. **New Player Notification**: Server notifies all via `player:joined`
3. **Existing Players Sync**: Server sends info via `player:existing`
4. **Movement Commands**:
- Client sends commands (not positions) via `player:move`
- Server updates position, calculates rotation, notifies all via `player:moved`
5. **Disconnection**: Server notifies all via `player:disconnected`
1. **World Initialization**: Server sends all world objects and monsters via `world:init`
2. **World Updates**: Server sends only nearby entities via `world:update`
3. **Entity Processing**: Client uses specific presenters:
- `MonsterPresenter` for monsters
- `WorldObjectPresenter` for world objects
Organize code as follows:
```
/client - All client-side code
/server - All server-side code
/shared - Shared code and constants
```
Implement collision using these rules:
1. **Collision Layers**
- Use `CollisionSystem` on server
- Define collision layers for different entity types
- Create collision matrix: players collide with monsters and world objects, not with each other
2. **Collision Radii**
- Players: 0.5 units
- Monsters: 0.6 units
- World objects: variable (trees: 0.8, rocks: 1.2, etc.)
3. **Collision Resolution**
- Push entities apart when overlapping
- Enable debug mode via `DEBUG_COLLISIONS` environment variable
Implement spawning as follows:
1. **Spawn Areas Configuration**
- Unique ID for each area
- Monster type
- Central position and radius
- Maximum monster count
- Minimum and maximum monster level
- Respawn time
2. **Spawn Lifecycle**
- Server initialization creates all monsters immediately
- Monster `die()` method notifies GameWorld
- GameWorld schedules respawn after configured time
- New monster spawns at random position within original area
- Safety system periodically verifies correct monster count per area
Implement combat following these patterns:
1. **Combat System Architecture**
- `CombatSystem` manages all damage interactions
- Support different ability types: projectile, area, zone, mobility
2. **Implemented Abilities**
- Ability 1 (Fireball): Projectile type
- Ability 2 (Teleport): Mobility type
- Ability 3 (Ice Spikes): Area + slow effect
- Ability 4 (Meteor Rain): Continuous damage zone
3. **Damage Mechanics**
- Apply multipliers based on entity type
- Process zone damage in regular tick intervals
4. **DamageZone Implementation**
- Create zones from abilities like Meteor Rain
- Apply damage in regular ticks (tickInterval)
- Use `while` loop to process multiple ticks if deltaTime is large
- Track entities already hit in current tick (alreadyHit set)
- Auto-remove after duration expires
- Clear alreadyHit set after each tick
- Use detailed logs for debugging
Implement rendering as follows:
1. **Camera Setup**
- Use OrthographicCamera for isometric view
- Camera follows player maintaining isometric perspective
2. **Entity Visuals**
- Players: Blue cubes with green cone for direction
- Monsters: Red cubes with orange cone for direction
- Trees: Brown cylinder (trunk) with green cone (top)
- Rocks: Irregular gray sphere
- Bushes: Green sphere
- Houses: Cube with triangular roof
- Fences: Thin, long box
Implement velocity-based movement:
1. **Movement Mechanics**
- Base on velocity, not absolute positions
- Use PLAYER.SPEED constant for default speed
- Process inputs each frame
- Server updates positions
2. **Isometric Movement Mapping**
- W (forward): move in direction (x-1, z-1)
- S (backward): move in direction (x+1, z+1)
- A (left): move in direction (x-1, z+1)
- D (right): move in direction (x+1, z-1)
Server calculates rotation:
1. **Rotation Mechanics**
- Movement direction determines rotation angle
- Use 45-degree increments (8 directions)
- Adjust angles for isometric view
2. **Rotation Angles** (in π radians)
- W (front): move Northwest, point Southeast (1.25π)
- S (back): move Southeast, point Northwest (0.25π)
- A (left): move Southwest, point Northeast (1.75π)
- D (right): move Northeast, point Southwest (0.75π)
- W+D: move North, point South (1.0π)
- W+A: move West, point East (1.5π)
- S+D: move East, point West (0.5π)
- S+A: move South, point North (0.0π)
3. **Mouse Usage**
- Use mouse for ability targeting only, not character rotation
Follow these rules for HUD implementation:
1. **Data Synchronization**
- Always sync level, xp, nextLevelXp, and name between server and client
- Include in all relevant events: JOINED, EXISTING, MOVED, RESPAWN, LEVEL_UP
2. **Client Updates**
- Update player.userData and HUD immediately upon receiving server events
3. **HUD Visual Implementation**
- Use SVG with translucent gray polygon background
- Dynamic golden stroke for XP progress
- Control progress via stroke-dasharray and stroke-dashoffset
- Never show undefined values; always provide visual fallback
- Background XP border always visible, even with no progress
4. **Design Priorities**
- Visual clarity and immediate feedback are top priorities
- Ensure HUD reflects XP progress from game start
Always display user-facing names:
Follow these practices:
1. **Data Validation**
- Always validate received data before processing
- Use try/catch for critical functions
- Handle errors explicitly to prevent crashes
- Validate numeric values to avoid NaN
2. **Asynchronous Event Handling**
- Wrap all geckos.io event handlers in try/catch
- Write descriptive error logs for debugging
3. **Debugging**
- Categorize logs by system: `[SYSTEM] Message`
- Enable DEBUG_COLLISIONS for collision visualization
- Use extensive logs for ability and damage zone tracking
4. **IDs and References**
- Use ABILITY_IDS from gameConstants.js for ability references
- Check monster types via MONSTERS constants
- Validate all IDs before processing
Implement timing as follows:
1. **Server Loop**
- Run at 20 ticks per second (50ms)
- GameWorld.update() calls all systems
- CombatSystem updates projectiles and damage zones
- Resolve collisions after movement, before sync
2. **Optimizations**
- Send only nearby entities to players
- Limit unnecessary updates
- Use deltaTime for FPS-independent calculations
When project requires multiple entry points (e.g., institutional landing page + game SPA):
1. **Vite Root Configuration**
- Set root at project root
- Implement custom plugin/middleware for routing
2. **Middleware Implementation**
- Serve `index.html` from root at `/` (landing page)
- Serve `client/index.html` at `/play` (game SPA)
- Create `/src/*` alias pointing to `/client/src/*`
- Ensure JS/CSS assets work without changing HTML paths
3. **Best Practices**
- Never duplicate files or create workarounds
- Keep build clean and routing flexible
- Document pattern adoption with configuration examples and motivation
Follow these steps:
1. Add configuration in `skillsConfig.js`
2. Add ID in `ABILITY_IDS` in `gameConstants.js`
3. Implement logic in `CombatSystem.processAbilityUse`
4. Add visual effects in client
1. Add definition in `gameConstants.js`
2. Implement application in `CombatSystem`
3. Add processing methods in Monster and Player classes
4. Implement visual feedback in client
Before considering a feature complete:
Prioritize these improvements:
Leave a review
No reviews yet. Be the first to review this skill!
# Download SKILL.md from killerskills.ai/api/skills/mmorpg-isometric-topdown-development-guide/raw