Some of my game projects were silly. Some were buggy. ScareScraper was, in my own words, horrendously cringe. I had a lot of fun building all of them.
I used Three.js, React, Electron, Firebase, and A-Frame across these projects. I built horror demos, a Splatoon-inspired multiplayer prototype, a Star Wars game, and an arcade environment. Each one gave me different problems to work through: physics, animation, enemy behavior, cameras, shared player positions, and how to structure a game across multiple levels.
ScareScraper: three levels of questionable horror
ScareScraper was a horror jumpscare game. The 3D game was built in Three.js and packaged as a React app with Electron. It got as far as three demo levels.
It was a big project for me because so many systems had to work together. I wrote my own physics, fog, enemy AI, animations, a game loop, and a system for creating and managing levels.
All of those pieces had to belong to the same playable experience. Physics affected how you moved and interacted with things. Enemy behavior gave the world something to react to. Fog and animation set the mood. The game loop tied it together over time.
The level system added another layer. I wasn't just building the contents of one scene. I needed a way to organize the whole game across its demo levels.
I remember it as silly and cringe, and also as a lot of hands-on practice. Three demo levels gave me plenty to build and plenty to learn from.
The multiplayer prototype
For my Splatoon-inspired project, I used Three.js and Firebase to put players in a shared space. People could log in, and the game tracked where each player was so everyone could see the others move around.
We also added physics. The game never got finished, but seeing another player move around the same space was a real result.
That raised a different problem than moving a character on one screen. Each player had a local view, while the shared data described where everyone else was. The app had to connect those two so somebody else's movement showed up in your scene.
I'd call it a multiplayer prototype. The parts that worked (login, shared positions, visible movement, and physics) are enough to explain why it belongs in my development history.
Flying around a buggy Star Wars world
My Star Wars game let me fly around, land a ship, and climb into other vehicles, including an AT-ST. It was unfinished, buggy, and a lot of fun.
The Three.js code includes imported 3D models, ship movement, several Ewok levels, terrain, vehicle controls, shooting, sound, gamepad input, camera follow, and some collision experiments.
Camera follow is a good example of the work hiding behind a simple-looking feature. Moving the vehicle is only part of it. The camera also has to stay in a useful spot as the vehicle turns. The code places the camera at an offset from the model and points it back at the vehicle.
Collision was another area I experimented with. One of the later levels uses raycasts around the vehicle to check for nearby trees. It's an early approach, visible in the source, and it fits how I remember the game: ambitious enough to be fun, with plenty of rough edges.
Building an arcade you could walk around
The arcade portfolio was another way to use a 3D environment. It had a character you could control, a camera that followed it, arcade models, and videos playing on surfaces inside the scene.
The video screens used Three.js video textures. That meant ordinary video could become part of the environment, showing up on a 3D screen instead of in a player somewhere else on the page.
The outside area had lighting, animated trains, and clickable objects that led to other parts of the site. The arcade code also had experimental Firebase player syncing. These were all attempts at the same thing: making a website you could move through and interact with.
The smaller experiments around them
Alongside the bigger games, I built A-Frame and VR scenes, vehicle displays, Star Wars lobbies, and a space-themed Three.js environment. Most of them were small experiments: loading a model, placing a camera, setting up lights, or getting something to animate.
A lot of what I learned came from building things I wanted to play with. I got practical experience with what makes an interactive world behave, and I kept finding reasons to try another scene or another mechanic.
ScareScraper's jumpscares and the Star Wars game's bugs are part of that story. So is the fun I had making them.