Tag: escape goat

In-game Level Editor Update

Today I worked exclusively on the in-game editor for Escape Goat.  There is no external editor–no Windows program or special version of the game I use to make levels.  Everything I use to create the built-in game will be included with the product!

My goal is to give first-time game designers a toolset for making something.  This means making things more user-friendly than I normally would.  Usually I just build my editors for stability and speed, but this one’s got to be pretty (enough) and totally straightforward.

 The editor as it existed this morning looked like this:

This version of the editor has been working great so far.  I have single button presses for every action, so there’s no need to use a menu for anything.  This lets me crank out levels and prototype them rapidly.  Though it may be really fast for me to use, I built it and have spent plenty of time with it.  I can’t expect someone new to jump into this and understand it.

Just looking at this screenshot, we have several immediate problems:

  1. There’s text bleeding off the edge in the properties editor, because it’s using the large, in-game font.   Speaking of this font, it’s not going to be very good at conveying button names.  Can you tell that’s [RT] at the bottom?
  2. There’s a lot of wasted space at the bottom with the Thing Selector (the big orange box).
  3. There’s no way to know what each window is at a glance.
  4. The windows are out of alignment, and the Thing Selector doesn’t even have a proper border.
  5. Placeholder text for header and footer needs to be replaced with something useful.
To come up with an improved layout, I started with a screenshot and loaded it into GraphicsGale.  Its built-in grid and alignment made it easy to move and resize the windows along the 8×8 pixel grid.  Not only that, but I could pick a good font size and get exact screen coordinates for all my editor windows.
Did I mention GraphicsGale is the most awesome spriting program ever?  Well it’s also good for mocking up screen layouts.
(Several hours later…)
Here’s how the editor looks now:
Besides being easier on the eyes, it has many usability improvements:
  1. Smaller font can show more text without bleeding off the edge.
  2. Windows can have colored strips at the top for header text, which can be a simple label (Region Map) or a dynamic label, like the Thing Selector which shows the category name.
  3. Graphical icons for Xbox controller buttons.  This makes such a huge difference.
  4. Map dimensions changed from 11×4 to 9×5. Almost the same size in room count, and it fits better in the editor.
  5. Thing Selector shows 3 rows of 8 things at once, which is less overwhelming, and takes up less space.
  6. The “cheat sheet” on the right  is all dynamic depending on where you are in the editor, from the Map Editor to the Room Editor to editing a single gadget within the room.  Each strip shows a button, command name, data field, and graphical icon.
The behavior is almost the same, but it’s much cleaner and smoother now.  I still have to add some more icons for the cheat sheet, but that should be about it.  I’ll post a video soon demonstrating its use, and I hope everyone will find it approachable regardless of their experience designing games!

The Dilemma of Unsolvable State Detection for Puzzles

Last Saturday was the Escape Goat Alpha 4 playtest, and the next big design challenge has shown itself and thrown down the gauntlet.  It’s a hard problem to define, so I’m hoping that writing this will clear it up in my head.  It might also make an interesting story for anyone who wants to see the gruesome behind-the-scenes of game design.

Escape Goat is a puzzle game at heart.  You’re there in a room, pitted against obstacles and mechanisms, trying to reach the goal.  My playtest version of the game had several stages of training, where the player learns the game mechanics, controls, and how the various gadgets operate, before being plunged into a puzzle that takes some problem-solving skills to beat.  The first few puzzles would basically solve themselves in a fun and visual exciting way while teaching you how the game works.  These rooms were fun to build–basically single-button Rube Goldberg machines that make you go WHOA, COOL and that’s about it.  Then come the puzzle rooms.

By their nature, puzzles can enter an unsolvable state if you mess up.  There are blocks that drop and can’t be lifted again, crates that break, switches that stay permanently thrown.  If you do things in the wrong order, you’re cooked and have to retry the room.

The problem is, the game doesn’t know when it’s in that state.  Play testers were poking around in a room for a few minutes trying to solve the puzzle even though it was no longer possible.  This just can’t happen in the release version of the game–the lack of feedback is frustrating and boring.  The player has to get the memo that the room is now unsolvable, and a retry is required.  Detecting and delivering this message is the big challenge I’m facing.

The room in its initial state, when you enter from the top right

 

Let’s look at one room in particular.  This room is the first one where you can actually “lose.”   There aren’t many interactive elements, just the three buttons on the top level.  The green one operates the push block on the left, the blue one lifts the platforms in the middle level, and the red one releases the top (red) platforms.  The proper solution is to hit the buttons from left to right, which transforms the level like this:

Press the green button to shift the lower blocks and create a gap
Press the blue button to lift the blue platforms on the middle level
Press the red button to release the top level platforms and drop the blocks

 

The blue platforms lift to catch the blocks, allowing access to the yellow button on the bottom right, which opens up the passage to the left.  If you hit the red button first, here’s what happens:

Without the blue platforms lifted, the blocks fall too far and barricade the yellow button.

 

The blocks have fallen and are blocking access to the yellow button on the bottom right.  You’re screwed.  You have to restart the level from the pause menu or by leaving the room and re-entering.  But… how can a new player know the puzzle is unsolvable now?  There’s no message.  You’re just left wondering what to do next.

I’ve thought of a few solutions:

  1. Design the puzzles so they can’t enter an unsolvable state.  Well, this would make for a pretty easy game.
  2. Design the puzzles so that something kills the player when they enter an unsolvable state.  This is a better solution than what we have now, but it means inserting a lot of violent gadgets (lightning machines, buzz saws) and having to account for all locations the player could be on the screen.
  3. The game checks to see if it is unsolvable and delivers a message if so.  Checking programmatically is something that would add months to the project, if not years, so that’s out of the question.  But maybe the room could have a bit of hidden data built in to detect for states that would make the room unsolvable.  For example, I could have a hidden block detector checking the area in front of the switch to see if the blocks have fallen there.
I like solution #3 so that’s what I’m going to explore this week.  A related problem is how to notify the player that the room can’t be solved anymore.  Options include:
  1. Kill the player instantly, which would be really jarring.  No good.
  2. Bring up an on-screen text sprite, which is more subtle, but not very thematically interesting.
  3. Have a gadget that activates in the unsolvable state and allows quick restarting of the level, a cool thematic solution but maybe a bit too abstract compared with the on-screen text.
I’ll do some quick tests with options #2 and #3 to see which works better.

Goats are the new Souls

So what have I been doing this whole time, with only a couple website updates in the last several months?

I’ve been making a new game.  Not Soulcaster III (yet), but an all new franchise.

Presenting…

ESCAPE GOAT

The features and story have not been nailed down, and it’s still in prototype phase, but work has been steady on it. As you can tell from the video, it’s a single-screen action puzzle game, with some Metroid-style adventuring and exploration.

What makes it unique? The goal is to give the player the experience of being trapped in a dungeon that has a mind of its own. Machinery changes the world and you must find a way to wrangle with it to reach new areas of the game. You find items and powerups to gain new abilites, which allow new solutions to puzzles. It’s not a linear game where you have to find items in a specific order–rather, you make decisions about which items to get given the paths you take. Many gates and puzzles will be solvable with more than one “key” item.

The mice are also pretty special, but more about them when I get a better grip on their design. I’m still figuring out how best to use them.