Cursor rules for building an isometric topdown MMORPG with Node.js server, Three.js client, MCP architecture, combat system, spawn system, and collision handling.
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.
Rules and conventions for building an isometric topdown MMORPG with multiplayer networking, combat system, and world management.
This skill provides comprehensive rules for developing a Node.js-based MMORPG with:
1. **World Structure**
- World is 200x200 units divided into biomes
- Each biome has unique density and scale for trees, rocks, and bushes
- World objects do not overlap (collision verification during generation)
- Houses, fences, and special structures are temporarily removed
2. **Monster Spawns**
- Spawn areas distributed by biome with different quantities, levels, and respawn times
- Only goblins currently implemented
- Automatic and balanced respawn per region
1. **MCP (Model-Controller-Presenter)**
- **Model**: Server-side, contains all game logic and entity state
- **Controller**: Server-side, interprets inputs and orchestrates high-level logic
- **Presenter**: Client-side, responsible only for rendering and inputs
2. **Authoritative Server Rule**
- Server is the single source of truth for game state
- Client sends only intentions/commands, never final positions
- All game logic, collision, and validation happens on server
1. **Network Events Format**
- All events use `category:action` format (e.g., `player:move`, `monster:spawn`)
- Events defined in `shared/constants/gameConstants.js`
- Communication pattern: "client sends command, server processes and returns state"
2. **Player Synchronization Flow**
- Initial connection: Server sends unique ID via `player:init`
- New player notification: Server notifies all via `player:joined`
- Existing players sync: Server sends info via `player:existing`
- Movement commands: Client sends commands via `player:move`, server updates and notifies via `player:moved`
- Disconnection: Server notifies all via `player:disconnected`
3. **World Entity Synchronization**
- World initialization: Server sends all world objects and monsters via `world:init`
- World updates: Server sends only entities near player via `world:update`
- Entity processing: Client uses specific presenters (MonsterPresenter, WorldObjectPresenter)
```
/client - All client-side code
/server - All server-side code
/shared - Shared code and constants
```
1. **Camera Setup**
- Isometric view using OrthographicCamera
- Camera follows player maintaining isometric perspective
2. **Entity Visual Representations**
- Players: Blue cubes with green cone indicating direction
- Monsters: Red cubes with orange cone indicating direction
- Trees: Brown cylinder (trunk) with green cone (foliage)
- Rocks: Irregular gray sphere
- Bushes: Green sphere
- Houses: Cube with triangular roof
- Fences: Thin, elongated box
1. **Movement Mechanics**
- Movement based on velocity, not absolute positions
- Default speed defined in PLAYER.SPEED
- Inputs processed every frame, positions updated by server
- Movement relative to isometric camera orientation:
- 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)
2. **Rotation System**
- Character rotation calculated server-side based on movement direction
- Movement direction determines rotation angle in 45-degree increments (8 directions)
- Isometric view rotation angles adjusted so character points opposite to movement:
- W (front): move Northwest, point Southeast (1.25π radians)
- S (back): move Southeast, point Northwest (0.25π radians)
- A (left): move Southwest, point Northeast (1.75π radians)
- D (right): move Northeast, point Southwest (0.75π radians)
- W+D: move North, point South (1.0π radians)
- W+A: move West, point East (1.5π radians)
- S+D: move East, point West (0.5π radians)
- S+A: move South, point North (0.0π radians)
- Server sends calculated rotation with position update
- Mouse used only for aiming abilities, not character rotation
1. **Implementation**
- Managed by `CollisionSystem` on server
- Uses collision layers to define which entities collide
- Collision matrix defines interactions: players collide with monsters and world objects, but not with each other
- Specific collision radii per entity type:
- Players: 0.5 units
- Monsters: 0.6 units
- World objects: variable by type (trees: 0.8, rocks: 1.2, etc.)
- Collision resolution pushes entities out of each other
- Debug system via `DEBUG_COLLISIONS` environment variable
1. **Spawn Management**
- Managed by `SpawnSystem` on server
- Spawn areas have configurable parameters:
- Unique area ID
- Monster type
- Central position and radius
- Maximum number of monsters
- Minimum and maximum monster level
- Respawn time
- Server initialization immediately creates all monsters in all areas
- When monster dies, `die()` method notifies GameWorld, which schedules respawn
- Respawn occurs after configured time, creating new monster at random position within original area
- Safety system periodically verifies correct number of monsters in each area
1. **Core Combat**
- CombatSystem manages all damage interactions
- Different ability types (projectile, area, zone, mobility)
- Four implemented abilities:
1. Fireball (projectile): ID 1
2. Teleport (mobility): ID 2
3. Ice Spikes (area + slow): ID 3
4. Meteor Rain (continuous damage zone): ID 4
- Damage has multipliers based on entity type
- Damage zones process ticks at regular intervals
2. **DamageZone**
- Created by abilities like Meteor Rain
- Applies damage in regular ticks (tickInterval)
- Uses `while` loop to process multiple ticks if deltaTime is large
- Maintains control of entities already hit in current tick (alreadyHit)
- Automatically removed after duration
1. **Server Loop**
- Runs at 20 ticks per second (50ms)
- State updates sent only when there are changes
- World state sent only for entities near player (optimization)
1. **XP Synchronization**
- Always sync level, xp, nextLevelXp, and name between server and client in all relevant events (JOINED, EXISTING, MOVED, RESPAWN, LEVEL_UP)
- Client must update player.userData and HUD immediately upon receiving server events
- Central HUD uses SVG with translucent gray background polygon and dynamic golden stroke for XP
- XP progress controlled via stroke-dasharray and stroke-dashoffset
- HUD never shows undefined values; visual fallback always present
- XP border background always visible, even without progress
2. **UI Display Patterns**
- Always display monster and entity names in UI using localized NAME field from configuration, never internal identifier/code
- Example: 'Zumbi da Névoa Negra' for BLACK_MIST_ZOMBIE
1. **Data Validation**
- Always validate received data before processing
- Use try/catch for critical functions
- Handle errors explicitly to avoid crashes
- Validate numeric values to avoid NaN
2. **Asynchronous Event Handling**
- All geckos.io event handlers must be wrapped in try/catch
- Error logs should be descriptive for debugging
When project requires multiple entry points (e.g., institutional landing page and game SPA):
- Serve `index.html` from root at `/` (landing page)
- Serve `client/index.html` at `/play` (game SPA)
- Middleware aliases `/src/*` to `/client/src/*` to ensure JS/CSS assets work without changing HTML paths
1. **Adding New Ability**
- Add configuration in skillsConfig.js
- Add ID in ABILITY_IDS in gameConstants.js
- Implement logic in CombatSystem.processAbilityUse
- Add visuals on client
2. **Modifying DamageZone**
- Ensure `while` loop is used for tick processing
- Clear alreadyHit set after each tick
- Use detailed logs for debugging
3. **Implementing New Status Effects**
- Add definition in gameConstants.js
- Implement application in CombatSystem
- Add methods in Monster and Player to process effect
- Implement visual feedback on client
1. **Logging**
- Categorized logs by system in format `[SYSTEM] Message`
- DEBUG_COLLISIONS = true to visualize collisions
- Extensive logs for ability and damage zone tracking
2. **IDs and References**
- Use ABILITY_IDS from gameConstants.js for ability references
- Verify monster types via MONSTERS constants
- Validate all IDs before processing
```javascript
// Client sends command
socket.emit('player:move', { keys: { w: true, d: true } });
// Server processes
player.updateMovement({ w: true, d: true });
const rotation = calculateRotation(movementDirection);
// Server broadcasts
room.emit('player:moved', {
id: player.id,
position: player.position,
rotation: rotation
});
```
```javascript
// Client sends ability use
socket.emit('ability:use', { abilityId: ABILITY_IDS.FIREBALL, target });
// Server processes in CombatSystem
processAbilityUse(player, abilityId, target) {
// Validate cooldown and mana
// Create projectile or zone
// Apply damage
// Broadcast events
}
```
```javascript
// CollisionSystem checks all entities
checkCollision(entity1, entity2) {
const distance = calculateDistance(entity1, entity2);
const minDistance = entity1.collisionRadius + entity2.collisionRadius;
if (distance < minDistance) {
resolveCollision(entity1, entity2, distance, minDistance);
}
}
```
Leave a review
No reviews yet. Be the first to review this skill!
# Download SKILL.md from killerskills.ai/api/skills/pvp-rpg-isometric-topdown-mmorpg/raw