https://world.officialstupid.me

Our social 3D world was peaceful—too peaceful. To add some excitement, we decided to implement Thunder Mode, a survival challenge where players dodge procedurally generated lightning strikes. However, adding a complex “game mode” to a social engine often leads to “spaghetti code” and performance death.

Here is how we built a high-performance, modular weather system that creates zero load on the server and stays silky smooth on mobile.

1. The Strategy: Complete Modularity

The biggest mistake in web game dev is cramming every new feature into the main animate() loop. Instead, we built thunder.js as a Self-Contained Module.

When you load the script, it automatically injects its own CSS, creates its own HTML overlays (Health bars, toggle buttons), and manages its own internal state. If we remove the script, the game still runs perfectly.

The “Zero-Server-Load” Logic:
We don’t sync lightning positions through the server. Instead, each client calculates its own “personal” lightning. This means the server only handles player positions, while the heavy math happens locally on the user’s device.

2. Visual Optimization: The “Double-Layer” Bolt

Initially, we used full-screen blue flashes and camera shakes to simulate thunder. Result: FPS dropped to 10 on mobile. CSS background changes trigger “layout reflows,” which are expensive.

We pivoted to a purely 3D visual approach using a Two-Layer Bolt system:

1. The Core: A thin, bright white TubeGeometry.
2. The Glow: A thicker blue tube using AdditiveBlending.

code JavaScript

// High-performance bolt geometry logic
createBolt(x, z) {
    const pts = generateZigZagPoints(x, z);
    const curve = new THREE.CatmullRomCurve3(pts);
    
    // Core (White) - 4 radial segments (square tube)
    const core = new THREE.Mesh(new THREE.TubeGeometry(curve, 16, 0.04, 4), coreMat);
    
    // Glow (Blue + Additive Blending) - 6 radial segments (hexagonal tube)
    const glow = new THREE.Mesh(new THREE.TubeGeometry(curve, 16, 0.2, 6), glowMat);
    
    boltGroup.add(glow, core);
    return boltGroup;
}

// High-performance bolt geometry logic
createBolt(x, z) {
    const pts = generateZigZagPoints(x, z);
    const curve = new THREE.CatmullRomCurve3(pts);
    
    // Core (White) - 4 radial segments (square tube)
    const core = new THREE.Mesh(new THREE.TubeGeometry(curve, 16, 0.04, 4), coreMat);
    
    // Glow (Blue + Additive Blending) - 6 radial segments (hexagonal tube)
    const glow = new THREE.Mesh(new THREE.TubeGeometry(curve, 16, 0.2, 6), glowMat);
    
    boltGroup.add(glow, core);
    return boltGroup;
}

3. Progressive Difficulty

A static game is a boring game. We implemented a difficulty scalar that increases every second you stay alive. This variable controls four things simultaneously:

• Spawn Rate: From one bolt every 2 seconds down to four bolts per second.
• Warning Time: The red “danger zone” circle stays on the ground for less time.
• Max Bolts: Increases the cap on how many bolts can be on screen at once (up to 15).
• Spawn Radius: As you survive, lightning fills a wider area around you.

4. Integrating GLB Death Animations

Manual character rotation looked “fake.” We wanted to use the professional animations built into our GLB models.

The Challenge: If you simply play the death animation in a loop, the character keeps dying and standing up repeatedly. To fix this, we implemented a State-Change Check.

code JavaScript

// Inside the main animation loop
const isHit = thunder.isDead || thunder.isKnockedDown;

if (isHit) {
    // Only trigger the animation ONCE when the state changes
    if (lastAnim !== 'death') {
        deathAction.reset().setLoop(THREE.LoopOnce).play();
        deathAction.clampWhenFinished = true; // Stay on the last frame
    }
    anim = 'death';
} else {
    anim = 'idle';
}
lastAnim = anim;

// Inside the main animation loop
const isHit = thunder.isDead || thunder.isKnockedDown;

if (isHit) {
    // Only trigger the animation ONCE when the state changes
    if (lastAnim !== 'death') {
        deathAction.reset().setLoop(THREE.LoopOnce).play();
        deathAction.clampWhenFinished = true; // Stay on the last frame
    }
    anim = 'death';
} else {
    anim = 'idle';
}
lastAnim = anim;

5. Framing the Chaos: UI Positioning and Depth

To improve the user experience, we made two major aesthetic adjustments:

• The 40% Rule: We adjusted the camera’s look at target to Y=3.5. This tilts the view slightly upward, pushing the character selection slider to the bottom 40% of the screen. This keeps the characters visible but leaves the top of the screen clear for the environment.
• Atmospheric Clarity: We thinned the fog by changing the far distance from 75 to 150. This makes the world feel larger and gives players more time to see the environment while they are dodging strikes.
• Expanded Roster: We expanded the character pool, supporting a full lineup of models from 01.glb to 09.glb, giving players more ways to express themselves before the storm hits.

6. The “Wasted” Loop: Delayed Restart

Survival games need a moment of impact. When a player finally loses all health, we don’t show the menu immediately. We added a 2-second delay where the camera lingers on the fallen character before the “START AGAIN” button fades in. This makes death feel meaningful and gives the player a moment to breathe before jumping back in.

The Result

By keeping the code modular, we managed to:

1. Maintain 60 FPS: By avoiding CSS-based screen effects and using low-poly 3-sided tubes for bolts.
2. Improve Visuals: The additive blue glow looks far more “electrifying” than a simple white line.
3. Keep the Engine Clean: The main index.html only needs one or two lines to “talk” to the Thunder System.

Next time you see a red ring on the floor, you have exactly 0.8 seconds to move—Good Luck!

https://aistudio.google.com

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

Moving a 3D character on a smartphone usually means cluttering the screen with ugly joysticks and transparent buttons. For our multiplayer project, we wanted something better. We built an Invisible Gesture Controller that turns the entire screen into a touch-sensitive pad.

The Strategy: Mapping Keys to Gestures

Our game engine already listens for specific keys like W (Walk), Shift (Run), and Space (Jump). Instead of rewriting the engine, we built a “Touch Wrapper” that translates finger movements into these virtual key presses.

1. Browser Normalization (CSS)

To make a web game feel like a native app, you have to kill the browser’s default behaviors. Without this, the phone will try to zoom or “select text” while you are trying to play.

code CSS

/* Add this to stop mobile browser interference */
body { 
    touch-action: none;          /* Disable pinch-to-zoom and scroll */
    user-select: none;           /* Disable text highlighting */
    -webkit-touch-callout: none; /* Disable long-press menus */
    -webkit-tap-highlight-color: transparent; /* Remove blue tap boxes */
}

/* Add this to stop mobile browser interference */
body { 
    touch-action: none;          /* Disable pinch-to-zoom and scroll */
    user-select: none;           /* Disable text highlighting */
    -webkit-touch-callout: none; /* Disable long-press menus */
    -webkit-tap-highlight-color: transparent; /* Remove blue tap boxes */
}

2. The Touch Logic (JavaScript)

This is the heart of the mobile support. It handles rotation, toggle-walking, sprinting, and vertical swipes for actions.

code JavaScript

let touchStartX = 0, touchStartY = 0, lastTapTime = 0;

function setupMobileControls() {
    // CAPTURE START POSITION
    window.addEventListener('touchstart', (e) => {
        touchStartX = e.touches[0].clientX;
        touchStartY = e.touches[0].clientY;
    }, { passive: false });

    // ROTATION: Horizontal slide
    window.addEventListener('touchmove', (e) => {
        if (!isStarted || !localPlayer) return;
        let dx = e.touches[0].clientX - touchStartX;
        
        if (Math.abs(dx) > 5) {
            localPlayer.rotation.y -= dx * 0.01; // Rotate character
            touchStartX = e.touches[0].clientX;  // Reset baseline
        }
        e.preventDefault(); // Stop page "bounce"
    }, { passive: false });

    // TAPS & SWIPES: Logic for Walk, Run, Jump, and Camera
    window.addEventListener('touchend', (e) => {
        let dx = e.changedTouches[0].clientX - touchStartX;
        let dy = e.changedTouches[0].clientY - touchStartY;
        let now = Date.now();
        let isDoubleTap = (now - lastTapTime) < 300;

        if (isStarted) {
            // SWIPE UP -> JUMP (Space)
            if (dy < -50 && Math.abs(dx) < 50) {
                keys[' '] = true;
                setTimeout(() => keys[' '] = false, 100);
            } 
            // SWIPE DOWN -> CAMERA VIEW (V)
            else if (dy > 50 && Math.abs(dx) < 50) {
                toggleCameraView(); 
            }
            // TAP LOGIC
            else if (Math.abs(dx) < 10 && Math.abs(dy) < 10) {
                if (isDoubleTap) {
                    // Double Tap: Toggle between Running and Walking
                    if (keys['shift']) {
                        keys['shift'] = false; keys['w'] = true;
                    } else {
                        keys['w'] = true; keys['shift'] = true;
                    }
                } else {
                    // Single Tap: Start/Stop Walking
                    if (keys['w'] || keys['shift']) {
                        keys['w'] = false; keys['shift'] = false; // Stop
                    } else {
                        keys['w'] = true; // Start Walk
                    }
                }
                lastTapTime = now;
            }
        }
    }, { passive: false });
}

let touchStartX = 0, touchStartY = 0, lastTapTime = 0;

function setupMobileControls() {
    // CAPTURE START POSITION
    window.addEventListener('touchstart', (e) => {
        touchStartX = e.touches[0].clientX;
        touchStartY = e.touches[0].clientY;
    }, { passive: false });

    // ROTATION: Horizontal slide
    window.addEventListener('touchmove', (e) => {
        if (!isStarted || !localPlayer) return;
        let dx = e.touches[0].clientX - touchStartX;
        
        if (Math.abs(dx) > 5) {
            localPlayer.rotation.y -= dx * 0.01; // Rotate character
            touchStartX = e.touches[0].clientX;  // Reset baseline
        }
        e.preventDefault(); // Stop page "bounce"
    }, { passive: false });

    // TAPS & SWIPES: Logic for Walk, Run, Jump, and Camera
    window.addEventListener('touchend', (e) => {
        let dx = e.changedTouches[0].clientX - touchStartX;
        let dy = e.changedTouches[0].clientY - touchStartY;
        let now = Date.now();
        let isDoubleTap = (now - lastTapTime) < 300;

        if (isStarted) {
            // SWIPE UP -> JUMP (Space)
            if (dy < -50 && Math.abs(dx) < 50) {
                keys[' '] = true;
                setTimeout(() => keys[' '] = false, 100);
            } 
            // SWIPE DOWN -> CAMERA VIEW (V)
            else if (dy > 50 && Math.abs(dx) < 50) {
                toggleCameraView(); 
            }
            // TAP LOGIC
            else if (Math.abs(dx) < 10 && Math.abs(dy) < 10) {
                if (isDoubleTap) {
                    // Double Tap: Toggle between Running and Walking
                    if (keys['shift']) {
                        keys['shift'] = false; keys['w'] = true;
                    } else {
                        keys['w'] = true; keys['shift'] = true;
                    }
                } else {
                    // Single Tap: Start/Stop Walking
                    if (keys['w'] || keys['shift']) {
                        keys['w'] = false; keys['shift'] = false; // Stop
                    } else {
                        keys['w'] = true; // Start Walk
                    }
                }
                lastTapTime = now;
            }
        }
    }, { passive: false });
}

How the Gestures Work:

• Rotation: Sliding your finger left or right updates the localPlayer.rotation.y. It’s sensitive and smooth, allowing for quick 360-degree turns.
• The “Tap to Move” Toggle: On a keyboard, you hold ‘W’. On mobile, holding your finger down is tiring. We changed it to a Toggle: Tap once to start walking, tap again to stop.
• Double-Tap to Sprint: Just like Minecraft or other mobile titles, a quick double-tap switches the state from Walking to Running (Shift).
• Swipe Down for Selfie: We mapped the Camera Flip (V) to a downward swipe. It’s an intuitive gesture for switching perspectives.
• Swipe Up to Jump: A vertical flick triggers the jump physics instantly.

The Result

By using gestures instead of buttons, we kept the screen 100% clean. This maximizes the immersion of the 3D world and makes the game feel like a premium mobile app rather than a website.

Next time you log in from your phone, try the swipe-down to see your character’s face!

https://chat.deepseek.com/

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/