Recently I was given the task of designing and implementing a mini-game within the larger game environment of 3Scape.

3Scape is an open world 3D building environment that uses realistic physics, and I’ve been designing the UI for its main creative space. Designing the UI has kept me in fairly familiar web design territory. But, designing a 3D game with very few conceptual constraints and very fast and hard technological ones has been a brand new world for me.

The assignment was simple: design something fun for our users to play. I gave myself the secondary constraint that the game should help new 3Scape users practice some of the skills they would need to build in 3Scape. I love the idea of level design and progressive disclosure to ease a user into an experience and teach them the skills needed to play a game or use an app. So, I thought I might try using this mini game as a controlled “first level” of 3CSape where they might practice using some of the skills they would use in the main creative space. For example, they might want to get practice spawning parts, snapping them together, scaling them, and moving them around the scape.

The technical constraints were plenty. We’re using ammo.js, a JavaScript port of the open source physics engine Bullet Physics. This physics engine has to be integrated with the rest of our 3D modeling software, and not all of the functions in ammo have been integrated. I couldn’t do anything that required the time of our developers, so I could only use what was already there. The game could be whatever I wanted, but I had to be able to make it myself.

I knew I could use JavaScript to periodically check the X, Y, and Z positions of parts in a scape. I also knew I could dynamically add parts to a scape, and make them roam around.

I wanted to give the player a reason to build without telling them how to do it. Puzzle, fill in the piece, connect the dots games seemed simple enough for me to code, but were too prescriptive and seemed to deviate too much from the open world spirit of 3Scape. I had two other ideas that seemed like a better fit: build to protect something, or build to corral something. I knew I could make parts that would randomly roam around the scape, so either option could work.

I thought I could make a special part, like a jewel, that you had to protect by building walls around it. I thought maybe I could create a special kind of roaming part (I’ll call them colliders) that would be the enemy. Any time one of these colliders ran into parts of your wall, that part of your wall would disappear. For instance, if you built a wall of cubes, and a collider ran into one of the cubes, that cube would be removed from the scene. If the enemy ran into the jewel you would lose, so you would have to quickly build and patch walls around the jewel to prevent the colliders from running into it. If you could protect the jewel for a given time, you would win.

As I forged ahead, I soon discovered that there wasn’t a way to check which parts were colliding with other parts. So, after talking with my boss, we decided I would have to move ahead and change the rules of the game.

Instead of the roaming shapes deleting parts from the scene on contact, they would simply push them around. The scene would have to change to allow parts to be generated on a floating plane, and if the jewel was knocked over the plane the player would lose. If they could keep it from being knocked over for a period of time, they would win.

3D Game Design