Delayed… And some Notes on Feature Cost

Escape Goat 2 is going to be delayed.

I’ve deliberated this decision for the past week or so, and ultimately it’s the right move to make. I’m hoping this post will shed some light on things for those of you who’ve been waiting for the game and were hoping to get it just a week after PAX.

There was a point, a month ago, when it seemed feasible. Just about everything was in place, bugs were at a minimum, and it seemed like only level design and music composition were left on my plate. I’m pretty fast at making levels, so even with the inevitable redesigns (and 50% discard rate), it was totally doable.

There was just one thing that hadn’t quite been fully nailed down, and it lurked in the shadows undetected for months: the map system. (Read the next section if you want the grisly details.)

Preparing for PAX, and the day to day business stuff of running an indie game studio, also devoured whole days at a time this month. While I think it’s possible for me to sprint to the September 10 date, it’ll come at the cost of:

1. Less playtesting, and thus less polish on the levels
2. Less time spent on marketing and publicity, and thus lower sales overall

We’ve put 10 months into this project. As much as I want to release it to the world soon, I believe that delaying is the right move to make.

My apologies to everyone who preordered hoping to unwrap a shiny new Escape Goat 2 download on September 10. Please contact me if you want a refund. I’m hoping you stick around though, because this game is going to be a lot of fun.

As of now I’m hesitant to give another launch date. I’m going to save that until after PAX. It would be great to keep it within September, but that’s just an aspiration at this point, not a guarantee.  If you’re at PAX this weekend, be sure to drop by and play the build. And if you are a preorderer, I can apologize to you in person, or try to bribe you with one of our shiny new 1.25″ buttons.

The Biggest Culprit – The Map

The singular innovation between Escape Goat and its sequel is the switch from a hub-based world to a flat world map. The game is still mostly linear, with levels snaking around, but I thought it would be cool to have zones given a place in the world, so you feel like you’re moving around. The map would become a stage select: no need to backtrack, just pick any room you’ve already visited and warp there. There would be branches to select, of course, and secret rooms–many of them accessible only through alternate solutions to the same room.

The first sign of trouble was right after CasualConnect, which immediately followed my announcement of the September 10 release date. I had about 40 rooms in the build, and based on playtest feedback, I needed to reorder a lot of them. This happened a lot in the development of Escape Goat: for difficulty tuning and theming, I would swap level positions and reorder things within a zone. With EG1’s world layout, this was a snap. But with rooms locked into specific positions, things become very rigid. Inserting a room in a series throws off half the rest of the map, which then needs to be reordered.

For about 10 days this month, map organization was where I spent the bulk of my time. I workshopped with my cohorts how things could be set up, and probably five different solutions were designed. (I even considered going back to the EG1 hub layout and abandoning the map entirely.)  What I decided on is kind of a hybrid between the EG1 and original EG2 map system. It standardizes zones into a set number of rooms, so they can’t really be expanded. Zones don’t have paths to one another, but there is a spine of “hub style” rooms along the center which branches to the zones. It will retain the sense of space in the world that I intended, and it is more thematically interesting than the hub system of the first game.

It’s another piece in my body of evidence that the cost of adding a feature to the game goes way beyond the time to program it. In this case, the programming was probably about 10% of the total time this feature cost to implement. The rest of the time was spent solving these problems:

1. When does the player go to the map? (In playtesting, 0% of players abandon a level they get stuck on to try another level)
2. How does the player even know there is a map? (We now show the map between rooms to show level progress)
3. How do we gate the player into the easy, intermediate, and finally hard rooms, so the difficulty curve is reasonable? (We have a sheep/key system like the first game, with a bit more explanation)
4. How does the player know where to go on the map? (We have rooms that aren’t completely solved, but can be solved with the current sheep key count, highlight on the map)
5. How do we give the player a sense of objective? (We have sheep rooms and other special rooms highlighted with a special icon)
6. How does the player know their level of progress in the game? (We have unvisited, but revealed, rooms show up with a special icon in the map)

Bottom line, I think we have it figured out now, at a much greater cost in development time than I anticipated.  The lesson I take from this: Beware of innovations, especially if they seem obviously good: “Maps are always good in games!”