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)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.