Mutant Pizza

Hello Otherworldly Beings,

I’m back with a second entry to the rapidly developing two-player game of cat-and-mouse that I’m currently calling Escape the Entity. Last week I discussed the birth of the game and early playtests to break ground on the design. We laughed, we cried, we fought, we hugged, but most of all, we read a series of paragraphs interspersed with lists and visual aids.

For those who need catching up, check out my prior design journal entry here.

In this entry, I’m going to discuss the feedback I received from playtesters—some of who were fellow board game designers, some of who weren’t, but all of who were board game enthusiasts—and the steps I took to address their remarks.

I’m going to run down a condensed list of my notes and talk around each point. Let’s get to it!

On the general comprehension of rules and strategies

As I discussed in my first journal entry, Escape the Entity is a two-player cat-and-mouse game. One person plays as the Ship, which must visit four planets before their opponent, the Entity, devours the craft four times. Let me elaborate on the theme.

The Entity plagues this sector of the expanse, hastily consuming any ship that dare leave their spaceports. The Entity dwells in the vacuum of space and has the ability to create various anomalies that is uses to trap its metallic prey.

This Ship comes equipped with new tech that allows it to withstand the Entity’s attacks. It’s mission is to deliver that tech to these planets and hopefully drive away the Entity altogether.

When the Ship visits all four planets, it wins! When the Entity devours the Ship four times before it can visit all four planets, it wins!

The Ship uses energy to change its heading and move along a course. It uses Tech Cards to thwart the Entity’s obstacles. The Entity rotates between two states, one where it makes Blips and recalls anomalies and another where it replaces Blips with anomalies, or the Entity itself, and uses the various abilities that come with these phenomena.

When the Ship moves or is moved to the same tile as the Entity, it’s automatically devoured one time unless the Ship can play a Diamond Hull card, which prevents one instance of it being devoured.

A lot of these concepts were easy to grasp up front. However, there was a lot of feedback centered around the Entity.

• Knowledge of the Entity’s “toolkit” for playing is complex and front-loaded; you have to learn a wide assortment of pieces and their behaviors up front to be effective
• Anomalies are oddly conditional, with frustratingly unexpected exceptions to their behavior

I’ve got a plan to address these issues.

• Streamlined rules for anomalies to eliminate all conditional behaviors and make any exceptions expressed up front on cards
• UI improvements to further illustrate the mechanics centered around a particular anomaly
• Anomalies will be unlocked in piecemeal, with the Entity only gaining a few to start with and having to earn upgrades as they succeed more throughout the game

I’ve been working on an upgrade tree that I’ll get deeper into later on in this article, but here’s a quick snapshot to illustrate the point.

I’ve organized anomalies around tiers that are unlocked as the anomaly devours the Ship. Certain anomalies will get upgrades. Some will be able to spawn other anomalies to the board (dotted lines).

At the time of this posting, I’m still iterating on this system and haven’t yet developed a prototype. But that and subsequent playtests are soon to follow. We’ll see how this addresses the info front-loading of the Entity’s play.

On character abilities and gameplay

Overall, people have been having a blast playing Escape the Entity. That’s quite promising for such an early prototype on a game that I whipped up from scratch in a manner of hours. I’m lucky. That kind of success on a game doesn’t come easily or often. However, players were still expecting more from the game.

That’s a good thing, I promise! I’ll tell you why.

There’s a difficult philosophy to master in game design: less is more. Especially in the early stages of design, it’s best to only develop the core mechanics and systems of a game before proceeding to some of the more grandiose concepts. Why? The foundation of your game, the core gameplay, the basics of pacing, the initial playtime, and the goals and obstacles that define the main tension of the game need to be strong before more can be added on top of their frame. It’s always best to make sure the plumbing is solid before adding another bathroom.

Playtesting my first prototype showed me that my general systems work. The Ship plays, by using energy and Tech Cards to take various actions. The Entity—which is a vastly different beast, mechanically speaking—plays with a tempo pacing and spawning Blips and anomalies and such on the board in attempts to trap the Ship. All of. that works.

The players wanting more means there’s a lot of fun stuff here and they want even more of that. Nice!

One of the ways I’m addressing that and the general front-loading issues with the Entity is through an expanded system of spawning and upgrading anomalies to terrorize the Ship.

I know this seems like a lot but the goal here is to give all of these anomalies simple, straightforward abilities which can then be upgraded to do more—killing two birds with one stone.

I haven’t yet explored what I can do for the Ship but I have a few ideas to spice it up a bit. I’m likely going to move away from a static “devour four times” goal and give the Ship health points instead. This way, anomalies or the Entity can damage the Ship and I can give the Ship opportunities to repair itself.

I’m not going to change the general energy use and movement mechanics much, but I am going to add more Tech Cards so the Ship can play things for clutch saves against the Entity’s various attacks.

In my next entry, I’ll discuss concepts for adding more flavor to Ship gameplay and, if I’m able to cut a new build for this prototype and playtest, I’ll provide my learnings.

Until next time, otherworldly beings…