Using Game Tech Creatively
April 15, 2016
I’ve blogged previously about how I’m a strong proponent of story driving computer game technology and not the other way around. One consequence of this is that I regularly design into my games sequences that I don’t know how I’m going to implement, if I’m going to be able to implement them at all. These sequences usually require improvements to the game technology. However, every now and then I can use existing technology in creative ways to realize these sequences. Such is the case for the little maze I’m adding into the newest Sleuthhounds computer game.
Maze Disclaimer
Most gamers, especially adventure gamers, do not like mazes in games. Developers love them because they tend to be easy to include from a technical standpoint and can really beef up play time. As concerns my game, the maze isn’t really a maze per se. As you’ll see from the screenshots below, it’s a very simple layout. The challenge isn’t in finding the way through the maze, its moving from one end of the maze to the other without hitting any of the “X” marks in the maze, which will cause “something bad” to happen.
The idea behind the maze is that it’s a panel on the side of a piece of equipment that the player must deal with. Within the panel is a small metal bead that the player influences with a magnet to move from the starting positon “S” to the ending position “E”. Where the player positions the magnet controls where the metal bead moves. For example, if the player places the magnet to the left of the maze, then the bead should move left if it’s able to.
The tricky thing with the bead is that I want it to slide through the tracks of the maze in response to where the player moves the magnet. To do this, it needs to know when it reaches an intersection which way to move. Beyond that, the game also needs to know which pixels of the image represent the “track” and which pixels represent “walls”. I really didn’t want to get into developing a full on physics simulation for something that felt like it should be much simpler to implement.
This was a case of not being able to see the forest for the trees. I was so busy trying to figure out a new simple piece of tech to implement that could handle this maze that I didn’t at first realize I already had a system perfectly suited for exactly this task: character walking.
A key component of the Sleuthhounds adventure games is being able to move the characters Jane Ampson and Pureluck Homes around the rooms they appear in. If I’ve done my job right, then players won’t even think about what goes into making a room “walkable”. They’ll just take it for granted and get on with the adventure. In my game engine, making a room walkable involves two pieces.
The first piece needed to make a room walkable is a definition of the area in which the characters can move. Above is a screenshot of the interior of a tent that can be visited in the new game. Below that is the definition of its “floor”. The blue shows the area where the characters can stand. This is surrounded by an orange area that defines a section of the floor that characters can move through when walking but can’t stop in. This is to protect against players getting stuck on the edges of the “stand” area when they’re walking right along the edge.
The second piece that a walkable room has is a “walk tree”. This tree helps characters to intelligently move around obstacles in rooms, such as the table in the middle of the tent. If a character is located to the left of the table and the player clicks to the right of the table, then the character needs to navigate around the table in some way. The game first checks to see if the character can move in a straight line from where they’re standing to their destination point. In this example they can’t, so the game finds the point on the walk tree closest to the player and the point closest to the destination. The character walks to the tree and then follows the shortest path along the tree to the destination.
Now, the interesting thing is if the tree is omitted from a room, then the character doesn’t try to avoid obstacles. Instead the character just walks straight from where they are towards their destination. If an obstacle gets in the way, then the character stops walking as soon as they reach that obstacle. This clearly isn’t great if you’re trying to navigate characters around a cluttered room but this is exactly what’s needed for the maze.
In the case of the maze, the bead is created in exactly the same way as Jane Ampson or Pureluck Homes. Even though it’s basically a metal circle, it’s still treated just like a playable character. The maze then has a walk area as shown above. The path corners are given a wide “walk but don’t stand” (black) area, to make it easier to move the bead around corners. The idea here is that while the player holds the mouse button down, the magnet is active and the bead should move towards it.
When determining the path for the bead to follow, the game first figures out the walk area point (grey) that is closest to where the mouse pointer is. The game then tries to walk the bead towards that point. If the player aligns the mouse with the track the bead is in, then the bead will slide towards the pointer. Otherwise it will get held up on the edges, exactly as one would expect it too.
At the end of the day this tricky new technical problem – sliding a bead around a maze – turned out to be nothing of the sort. It goes to show that when you come to add new tech into your game, it’s best to first take a step back and see if you’re solving a problem you’ve already solved by a different name: serendipity.