In most multiplayer games, when a player disconnects, their character simply vanishes. This makes the world feel empty and temporary. We decided to change that by building a Persistent Ghost System.

Now, when you leave our world, your avatar stays exactly where you left it for 12 hours, serving as a digital footprint of your visit.

The Problem: The “Empty Room” Syndrome

3D social spaces feel lonely if you aren’t there at the exact same time as someone else. We wanted a way for players to “leave their mark,” allowing the world to look populated even during off-peak hours.

The Solution: Ghost Conversion

We implemented a server-to-client bridge that handles “ghosting” in three tiny but powerful steps.

1. Server-Side: The 12-Hour Timer

Instead of deleting the player data on a disconnect event, the server rebrands the player. We change their ID to a ghost_ prefix and start a long-running timer.

code JavaScript

// On Disconnect: Convert to Ghost
const ghostId = "ghost_" + socket.id;
players[ghostId] = players[socket.id]; // Keep the data
delete players[socket.id]; // Remove the active socket

// Set the 12-hour expiration
setTimeout(() => {
    delete players[ghostId];
    io.emit('player_left', ghostId);
}, 12 * 60 * 60 * 1000);

// On Disconnect: Convert to Ghost
const ghostId = "ghost_" + socket.id;
players[ghostId] = players[socket.id]; // Keep the data
delete players[socket.id]; // Remove the active socket

// Set the 12-hour expiration
setTimeout(() => {
    delete players[ghostId];
    io.emit('player_left', ghostId);
}, 12 * 60 * 60 * 1000);

2. Client-Side: Visual “Offline” Cues

To make sure active players can distinguish between live users and ghosts, we added visual shaders. When the client sees an ID starting with ghost_, it automatically:

• Sets the model to 50% opacity.
• Appends (OFFLINE) to the name tag.
• Forces the model into an Idle state.

code JavaScript

if (id.startsWith('ghost_')) {
    child.material.transparent = true;
    child.material.opacity = 0.5; // Visual hint that the player is gone
}

if (id.startsWith('ghost_')) {
    child.material.transparent = true;
    child.material.opacity = 0.5; // Visual hint that the player is gone
}

3. Physical Presence (No Ghosting)

Even though these characters are “offline,” they aren’t just holograms. We kept the Collision Detection active against them. You cannot walk through a ghost. This creates a sense of solid, physical history in the world—if a group of friends stood in a circle before logging off, that circle remains as a physical barrier for 12 hours.

Why it works

• Anti-Cloning: If a player logs back in, the server automatically finds and “kills” their old ghost before spawning their new live character. This prevents the world from becoming cluttered with clones of the same person.
• Memory Efficiency: By using a simple Map and setTimeout, the server handles the persistence without needing a heavy database.
• Social Proof: New players entering the world see a crowd of characters, making the project feel popular and alive.

Conclusion

Persistence doesn’t always require a massive database or a 24/7 server farm. With just a few lines of logic and some clever ID prefixing, we turned a temporary room into a persistent world where your presence actually matters.

Next time you log in, say hi to the ghosts of the players who came before you!

https://chat.deepseek.com

Building a Smooth Multiplayer 3D Character Selection World

In our latest development sprint, we transformed a basic 3D multiplayer space into a polished, interactive character hub. We focused on three main pillars: User Experience, Animation Flexibility, and Physical Presence.

Here is a breakdown of what we’ve built.

1. The “Carousel” Selection System

Instead of a traditional 2D menu, we moved character selection into the 3D world.

• Mouse-Scroll Interaction: Users can cycle through characters by simply scrolling their mouse wheel.
• The Centering Effect: We used linear interpolation (Lerp) to smoothly slide the selected character to the center of the screen while rotating it, giving the player a 360-degree preview of their avatar.

2. Dynamic Animation Mapping (Fuzzy Search)

Different GLB models often come with wildly different animation naming conventions. A Robot might have RobotArmature|Walk, while a human might just have Walk.

• Keyword Matching: We implemented a “Fuzzy Search” logic that looks for keywords like Idle, Walk, Run, or Jump.
• The Skeleton Fallback: Some models, like our Skeleton, are missing specific animations (like a Walk). We built a fallback system that automatically detects a missing Walk and replaces it with the Run animation, ensuring the character never “glides” in a T-pose.

3. Social Interaction: Proximity Waving

To make the world feel alive, we added a social layer.

• Proximity Detection: When a player stands still near one or more other players, the system triggers a “Wave” or “Thumbs Up” animation automatically.
• Social Immersion: This small detail transforms the space from a lonely void into a social gathering hub.

4. No More “Ghosting”: Collision Detection

In early versions, players could walk through each other like ghosts. We solved this by implementing a Circle-Circle Collision system:

• Physical Boundaries: Every player now has a collision radius.
• The “Push-Back” Logic: If two players get too close, the math calculates the overlap and gently pushes the local player back, giving everyone a solid physical presence in the world.

5. Enhanced Camera & Physics

We kept the core gameplay tight with:

• Jump Physics: Gravity-based jumping with force and landing detection.
• View Toggling: Players can press ‘V’ or Right-Click to flip the camera between a standard third-person follow and a front-facing “Selfie” view.

Technical Highlights:

• Engine: Three.js (WebGL)
• Networking: Socket.io for real-time position and animation syncing.
• Assets: Optimized CC0 GLTF models.

What’s Next?
We are looking into adding customizable textures and a chat system to further enhance the multiplayer social experience!

Looking for the logic?

The secret to the animation flexibility was this helper function we developed:

code JavaScript

function findAction(mixer, clips, keywords) {
    const clip = clips.find(c => keywords.some(k => c.name.toLowerCase().includes(k.toLowerCase())));
    return clip ? mixer.clipAction(clip) : null;
}

function findAction(mixer, clips, keywords) {
    const clip = clips.find(c => keywords.some(k => c.name.toLowerCase().includes(k.toLowerCase())));
    return clip ? mixer.clipAction(clip) : null;
}

This allows us to drop in almost any GLB model, and the game “figures out” which animation is which!

https://chat.deepseek.com , https://aistudio.google.com , https://claude.ai (free)

The backbone of our 3D world is built upon a highly organized file architecture and the use of the industry-standard GLB (GL Transmission Format Binary). Because the game needs to load massive amounts of data—meshes, textures, and complex animations—simultaneously for up to 100 players, the way these files are structured is critical to performance.

Here is a breakdown of how we managed the GLB assets and the project’s file hierarchy.

1. The GLB: The “All-in-One” 3D Container

We chose GLB over traditional formats (like OBJ or FBX) because it is the “JPEG of 3D.” In our game, each character (01, 02, and 03) is a single binary file that contains:

• The Mesh: The actual 3D body of the character.
• The Textures: The colors, skins, and materials embedded directly into the file so they don’t get lost.
• The Skeleton (Rig): The internal bone structure that allows the character to move.
• The Animation Library: This is the most important part. Each GLB carries its own “clip” library. When the game starts, our script scans the GLB for specific names like “Walk” and “Wave”. By packaging everything in one file, we ensure that when a player joins, the character doesn’t appear “naked” or “frozen”—everything loads in one single network request.

2. The Project Architecture

To manage the relationship between the 3D assets and the game logic, we implemented a strict “Root-Public” structure. This separation ensures that the 3D models stay secure and the game runs smoothly.

The Root Level:

• server.js: This is the “brain” of the world. It doesn’t handle graphics; it only handles “coordinates.” It tracks where Player 01 is and tells the other 99 players.
• package.json: The manifest that ensures the environment has the correct tools to sync the players.

The Public Folder (The Game’s Front Door):

• index.html: The “Canvas.” This file contains the Three.js engine that renders the world. It is the only file the user actually “sees.”
• player/ (The Asset Vault): We created a dedicated sub-folder specifically for our 3D models. Inside this folder live 01.glb, 02.glb, and 03.glb.

3. Dynamic Path Management

A key feature of our management system is how we handle file paths. Instead of hard-coding every character, the game uses a dynamic loading system.

• When a user clicks on a 3D character during selection, the game stores that character’s filename (e.g., “02.glb”).
• The script then looks into the public/player/ folder and pulls that specific file.
• This structure allows us to add 10 or 100 new characters just by dropping a new GLB into the folder and adding its name to a list, without changing a single line of the game’s core code.

4. Technical Normalization

Inside the file structure, we managed a major challenge: Scale. 3D artists often export models at different sizes. One GLB might be 100 times larger than another.
To manage this, we built a Normalization Layer into the loading process. Every time a file is pulled from the player/ folder, the game “measures” the model’s dimensions and automatically scales it to a standard height. This ensures that in our file structure, every GLB is treated as a uniform “Player” regardless of its original size.

Summary of the File Map

code Text

/Project_Root
│
├── server.js             (Multiplayer Logic)
├── package.json          (Server Config)
└── /public               (Visible Game Files)
    ├── index.html        (Three.js Engine & UI)
    └── /player           (The 3D Asset Folder)
        ├── 01.glb        (Character 1 + Animations)
        ├── 02.glb        (Character 2 + Animations)
        └── 03.glb        (Character 3 + Animations)

/Project_Root
│
├── server.js             (Multiplayer Logic)
├── package.json          (Server Config)
└── /public               (Visible Game Files)
    ├── index.html        (Three.js Engine & UI)
    └── /player           (The 3D Asset Folder)
        ├── 01.glb        (Character 1 + Animations)
        ├── 02.glb        (Character 2 + Animations)
        └── 03.glb        (Character 3 + Animations)

By using this clean, modular structure, we created a game that is easy to update and incredibly fast to load, ensuring that the 3D “High-Key” studio experience is seamless for every player who enters the world.

https://chat.deepseek.com and https://aistudio.google.com

GLB – https://pixabay.com/3d-models/search/glb/