Building a World

There are lots of ways to compose 3D worlds for games. You can use a DCC tool (like Blender or Houdini or whatever) to build a monolithic world or level and just export the whole thing and have the game engine display it. You can build reusable components in the DCC and have the game engine assemble them coherently or you can just generate all assets as you need them (the Asteroid Blobs entry in this jam does this).

As with everything, I took the middle road, but simplified even further. As far as the environments are concerned, Steam+SPARK is more 2.5D -- it uses 3D components (modeled in Blender), but arranged using a grid, so I wouldn't have to deal with fitting oddly shaped things together. I've done enough stuff with grids (Slime Leak and Harmony) that this was an attractive approach. Both of those games stored a grid filled with indices to the type of tile needed, which was looked up and drawn as needed. I do the same thing here, but with cubular 3D components. Here's the layout for Elektra's bedroom/workshop:

'(5 3)
'(1 1 5 2 0
  0 0 0 4 0
  0 0 0 3 0)
First it specifies the size of the grid (different scenes may need larger or smaller sets), then what components should be placed in each grid cell. Component 0 is a cube of bedroom floor, complete with carpet. Component 1 is a the same, but with a wall on the north edge. 4 is the open door and so on. This is just like what I did before with pixel tiles, except I index into a list of 3D components instead of sprites.

Side note: I'm just using a plain list for the grid, relying on my knowledge of the width to index through it. That makes access easier than using a true 2D array. It also means I need less syntax characters so I can just use the editor to design the scene without too much in the way.

The components are built to a standard size of one metre square, although they can be infinitely tall or deep. My convention is that the floor is at Z = 0. No ramps or stairs in these worlds! Elevators only! This made everything fairly easy to construct quickly.

However, it would still get onerous to create every possible variation of tile and manage it. So I have the concept of props that can be placed anywhere on the grid:

'((BED (0 0) 180)
  (BED (0 1) 0)
  (DESK (2 2) 15))
They can also be rotated -- the BED is two tiles, but it's the same component, one of them's just rotated 180 degrees so that they look to be joined up. I rotated the DESK 15 degrees just to show that I could.

Unlike my previous games, I have a new dimension to deal with -- the path that the character can walk on. The "engine" doesn't really understand about collisions or intersections. Instead, I have to tell it where the player can go. For now, I do this with a "path map". The one for the bedroom looks like this:

'(0 1 1 1 0
  0 1 1 1 1
  1 1 0 1 0)
So, the character can "walk" on any grid square that has a 1. Notice that I had to leave holes in the path for the BED (both of them) and the DESK.

This is a somewhat onerous and a potential source of bugs -- prop is moved, but path isn't updated. However, many successful games have used similar approaches. However, it's rather a pain for the level designer and I think the computer should at least handle routing around the props -- it's not like it doesn't know where they are!

Get Steam+SPARK

Leave a comment

Log in with to leave a comment.