by Chus Rivel

ASHES Blackout Protocol began as an in-house design, and as an almost inevitable next step after the intense development work of our previous projects. It is rooted in the universe of Phoenix New Horizon, and this is its story.

From Phoenix to ASHES
For us, the best part of Phoenix New Horizon was the development itself. Together we managed to pull together a hugely ambitious team, one capable of hitting some big milestones, and we did it with incredible humanity and a sense of fun that has turned Thursday into the big day of the week: no matter how often we see each other otherwise, we all know that, whatever happens, we will be around the table on Thursday to play and to talk at length, without being afraid of getting things wrong.

After the warm reception of Phoenix New Horizon, and while we were working flat out on Orloj: The Prague Astronomical Clock, an idea started coming up at the table more and more often: going back to that universe. We didn't want to make an expansion; we wanted a completely new game.

Orloj was still being illustrated when we were already jotting down ideas and setting out the key points of what this title had to be, a game that was born as a prequel from the very first moment. As a starting point, we found it really interesting to design something built around an alarm and an evacuation of the Earth, like The Downfall of Pompeii, Anachrony or Evacuation.

And if the first game in the saga was called Phoenix, the prequel could only be called Ashes. We liked giving it a more technological edge by turning its letters into the acronym of the evacuation protocol used after the nuclear catastrophe: Artificial Shelter & Human Evacuation Sequence

For anyone who doesn't know Phoenix New Horizon: the game takes us to a retro-dystopia in which humanity has survived by taking refuge underground after a nuclear war. It begins at the moment civilization comes up from the depths, ready to recolonize the Earth by carrying out the Phoenix Project, a network of regenerators capable of making the planet habitable again.

ASHES had to take us to the moment right before that. We wanted players to build shelters, rescue survivors on the board and work toward one big common goal: developing the Phoenix Project. Without knowing it, we had just defined the three main actions of the game.

First Contact

That was when Jorge brought us a first draft that helped us pin down a lot of the ideas we had been throwing around. It barely worked as a game, but it hid some very interesting concepts that ended up surviving the whole development: a vehicle to interact with the map, the Phoenix Project as the scoring system, a resource crafting system and, of course, radiation. If we were in the middle of a nuclear emergency, we wanted the game to have radiation.

That first prototype already had a pick & delivery system, a mechanism we have never been especially keen on at Perro Loko Games and one that tends to put a lot of players off. Even so, it fit the theme perfectly and we were sure we could give it a twist. Over time it became one of the parts of the game we are proudest of and, in fact, we think plenty of people won't even spot it as a traditional pick & delivery.


A shot of the first prototype
Setting a New Starting Point

Of all the ideas we had been writing down, there was one we fell in love with from the very first moment: ASHES would be a worker placement game in which the workers could die if they didn't get their anti-rad dose. That idea ended up becoming one of the pillars of the design.

We also settled on the elements that had to connect ASHES with Phoenix New Horizon: managing commandos as your workers, and completing missions as extra actions during your turn. It was important that any player could tell at a glance that both games share the same universe.

A full evacuation has to be a titanic project for humanity and, the way we see it, a shared one, so we had our first challenge right there: several parts of the game had to feel cooperative, but under an atmosphere of tension and survival. That led us to two conclusions. The first: rescuing survivors would be a common good even though we were all competing for it. The second: building the Phoenix Project had to benefit the other players indirectly.

If rescuing survivors is a common good, losing them had to hurt the players, and that idea turned into the happiness track, which for many versions was almost useless until we found the real engine of the game.

The Engine of the Game

While the rest of the design kept evolving game after game, there was one feeling that wouldn't go away: the action engine still wasn't convincing us. Phoenix New Horizon had a central mechanism that had surprised the community, and we felt ASHES needed to find its own.

After discarding several proposals, we got to a first serious version of the engine: an action programming system split into two zones, the outside world and the colony. Resources were produced in the colony and the workers were safe there; actions were carried out outside. At the end of each round you had to supply anti-rad doses to every worker who had been left exposed.


The prototype in the picture is version 7.0 of the game; you can see the action programming system on the right-hand side of the board
Although that proposal was eventually dropped as well, it turned out to be surprisingly useful. For months it worked as a temporary engine that let us develop the rest of the game. It was fascinating to see how we could later swap the engine out without it affecting the rest of the components too much.

Across all those versions, one of the ideas that would end up defining ASHES completely started to take shape: survivors would be a resource shared by every player. Rescuing one wouldn't only make your colony grow, it would also increase the number of actions available to you. In other words, ASHES would end up being a worker placement game in which you have to go out and rescue your workers. Getting new ones would be part of the competition too.

We were convinced that a big part of the game's character was right there, but it was also the source of some of the worst headaches of the whole development. Snowballs appeared hard to control, turns got too long and games ran on longer than they should. To fix it we took an important step: we dropped the shared area where the actions took place and moved that system onto the personal colony board. Action spaces there would be limited, and any extra rescued survivors would go into a separate flow made up of the shelter cards.

And then, finally, everything started to click.

Rescue survivors to turn them into your workers, then decide which ones stay active in the colony and which ones find shelter inside it. Without realizing it, we had gone back to the original idea of the two zones, outside and inside, but now in a much more natural way.

The system was easy to understand, it let the rest of the game shine, and it made rescuing one more survivor always feel like an important decision. That was when we started to feel that ASHES finally had an identity of its own.


How the colony board of ASHES Blackout Protocol evolved
Active Survivors, Essential Survivors, and the Final Picture

Normally, once we have a working engine, we like to pin down what the final picture of the game looks like and what we want to see on the table when the game ends: how many spaces will be filled, how many objectives completed, how far each player will have got. In a way, what we're working on at this point is the satisfaction you get from looking at everything you built during the game. To get there, we sometimes have to slow the engine down or speed it up until that final picture works.

If the survival of humanity is the ultimate goal in an emergency, it helps to have survivor profiles with different roles within the dynamics of the game. So we defined two categories, essential and active, deliberately neutral names chosen to avoid associations that might be uncomfortable. As a visual cue, the two are told apart by color, with yellow for one of them because of its association with radiation protection suits, a visual code that is widely recognized in the world of safety and protection.

Both would help us fill up our shelters, but only active survivors can work outside the colony. On top of that, saving essential survivors would be easier for the players, which let us speed the engine up and fine-tune the final picture of the game.

One of the main challenges with this game was that it only has three main actions (Build, Rescue and Develop), and that could easily start to feel repetitive: we had to break the sequence.

Phoenix New Horizon was a really interesting design exercise as a game with a single resource, fuel, so in ASHES fuel had to play a big part again. This time it would be used to move the evacuation vehicle and carry survivors to the shelters.

But moving the vehicle around the board wasn't enough on its own. We wanted every move to be an interesting decision, and that's how the idea of the area tiles came about: as it travels across the map, the vehicle triggers main actions and turns movement into much more than just getting from one place to another. The board stopped being somewhere you pass through and started to become a key part of the game, and all of a sudden you could find yourself thinking:

"I'm stuck... but if I move over here I get fuel, I trigger this action and I can still stretch my turn out a little further."

You weren't only watching your own colony any more. You were also keeping an eye on the central board the whole time, making sure nobody else rescued the survivors you needed or claimed that action you had been setting up for several turns.

That was when we felt the vehicle had stopped being a thematic element and become one of the most important pieces in the game. Movement wasn't about going from one point to another any more: it had turned into a way of building little spatial combos in which both the route and the order of your actions mattered. It was one of those days when you get up from the table thinking: "Now we're talking."


The prototyping process
The Asymmetric Factions

When the game was already pretty well tuned and we were starting to feel comfortable with it, we had another one of those ideas that seem fantastic... until you have to develop them.

We'd had a great time creating asymmetric factions in Orloj, but with ASHES we wanted to go a step further. Our goal was for each faction to really change the way you play, not just hand you a small advantage at the start.

If Phoenix taught us that balancing a game built around a single resource could be maddening, ASHES showed us that doing it with twelve different factions was, quite simply, a small hell.

We reckon we've tested them over more than eighty games. On top of that, we played countless solo games with every single one of them to check that they all worked exactly the way we wanted.

I'm convinced that once the game hits people's tables, someone will say that one of the factions is broken.

I'll give you the answer in advance: they probably all are.

Or, to put it another way, they're all very powerful.

The difference is that some show their full potential from the very first game, while others need the player to know the game much better to get the most out of them. And funnily enough, those are the ones that scare us the most when they fall into the hands of an experienced player.

The Team


ASHES is a completely collective game, and that wouldn't be complete without Jorge Tabanera, who climbed into the van with us from the very first moment.

Working with him is an absolute delight. He understands exactly the world we want to build, the feeling we want to get across and the visual tone we're after. He blew us away the first time we saw the cover, and he has managed to create a color palette that gives Phoenix and ASHES a very recognizable shared identity.

It's hard to imagine this game without Jorge. He is as much a part of the development as any of us. Even if he still loses every single game.

But this game wouldn't exist without you either.

It might not look like it, but we read every comment, every review, every post and every message we get. We watch all the videos that show up on YouTube and we take note of everything (our German and our Korean have improved a lot over these last few years).

The rulebook has been revised with enormous care, taking in a lot of the improvements we learned while making Orloj. We have also put a huge amount of work into making the board easier to read and all the information clear and intuitive, while keeping the visual language of Phoenix.

We honestly believe ASHES is the most demanding game Perro Loko has made so far. It is a game that, with barely four rules, keeps you thinking about how to optimize every single decision.

You don't need to have played Phoenix to enjoy it, but if you did you'll find plenty of nods that we hope will put a smile on your face. Will there be a third part to this universe?

That's in your hands now.

For now, all we hope is that you enjoy ASHES as much as we have enjoyed creating it and playing it.


Evolution of the box cover