We originally ideated around the Alexa API that inspired us most: Alexa Web API for Games. We asked ourselves what could we do with all the new possibilities it offers?

Several rounds of ideation later and we had a plethora of ideas.

Two or three of these ideas merged, evolved and eventually became 13 Steps: a mix of 1990s UK kids TV favourite “Knightmare” and popular gameshow “The Chase” sprinkled with a spoonful of nostalgia for the text adventures of 1980s home computing.

The aesthetic of the game is heavily influenced by “Tales from the Crypt” - both the comic and the series - and the narration pays homage to the brilliant Vincent Price.

We had to descope the Audio API (but see "what's next" section)

What it does

13 Steps is a dungeon crawler card game that you play using your voice.

The game combines fiendish logic and vivid visuals with chilling and, sometimes, off-the-wall narration to create a rich, immersive horror experience.

Players find themselves deep underground, pursued by a relentless, unknowable darkness. They must step forward to reach the light. Success or failure depends on the turn of a card as with each step could bring a monster to fight, a weapon to collect or perhaps merely the remains of those who have tried and failed to reach the light before them. And the Darkness is always close behind, ready to swallow you whole.

Players tell the narrator their intentions using phrases like “Step Forward”, “Use Spear” and “Fight”.

The game works as a stand alone voice skill, but our visual UI greatly enhances the experience. By representing the player’s progress and the proximity of the darkness on screen the tension is heightened. Players can come face to face with the monsters they battle as the light demon, glow worm and firefly cards reveal themselves on screen.

How we built it

We started with the game concept itself. Our ideation sessions were framed to focus on that rather than the technical implementation.

Next, we sifted through the ideation elements combining and removing them until we had a strong sense of the core gameplay. We wanted a tight, repeatable game loop that offered a different experience each time and was easy to scale up.

Once we'd got that locked, we simulated the game loop programmatically, tinkering with monster stats, items available and the randomised head start the player gets on the darkness until we had a 35/65 win to fail ratio.

We knew we didn’t want to exclude owners of audio-only devices so we developed an end-to-end playable audio prototype. From there, we could see how to design and develop the visual UI.

We then designed and developed the skill back end and visual UI separately. We scheduled regular calls and exchanged hundreds of messages to make sure neither diverted too far from the other.

One regret is that we had no time for user testing with our target audience. That said, the nature of the hackathon is to come up with something that can then be tested and iterated upon. ...

Challenges we ran into

The game was conceived, designed and built by the two of us in our spare time alongside the day job over a period of just 41 days.

With so little time, the game was built in an agile way, meaning that the design and build of the UI happened as the game logic and skill was being written. This meant putting those elements together towards the end of the project. This was a tricky process and we learned just how difficult that can be. We made sure to communicate regularly to create a shared understanding and collaborate on solutions as these elements came together at the end of the project.

We needed to develop our creative thinking around debugging skills because sometimes the error messages are less descriptive than they might be, Alexa saying only “there was a problem with the requested skill’s response” with no further information now triggers a stress response in our developer. (See also: “an error occurred whilst dispatching the request to the skill”).

On top of that, some of the error messages aren’t what they say they are… "The audio is of an unsupported bitrate 64000", for example, seems to be a catch-all/ default for “this audio file is not encoded in the way Alexa expects”.

Because sound happens in a linear fashion over time, It’s also a challenge to test new iterations in a time-efficient way. The question “how might we go directly to the change we just made rather than go through the whole thing again?” came up a lot.

The difference in speed between local and remote development environments made it tempting to test directly on remote lambda. Also it was a big surprise when the UI loaded rapidly once the skill was running entirely remotely as opposed to via ngrok tunnel. We’d spent a bit of time thinking how to accommodate that long delay in the render.

And running 2 https tunnels over ngrok and npm’s http-server, it’s hard to know if an error is actually an error or something in the chain has blinked when developing locally.

We were also working with the Web API for Games for the very first time after some initial confusion, we quickly got the hang of it.

Accomplishments that we’re proud of

We’re really proud that in just over a month, we built a game that’s challenging to play and rewarding to win!

This game works audio-first and layers the delightful visual element on top of that. If you’ve got an Alexa device without a screen, you get an uncompromised core gameplay experience and if you’ve got a screen you get an even more immersive trip underground. Our approach is one of ‘progressive enhancement’ borrowed from the world of web design.

The conversation design is deliberately limited in order to provide a simple interaction model. We wanted players to know what they could and could not say without having to think about it or constantly reference a ‘help’ or other meta instructions that would interrupt and take them out of the underground world.

The skill handles utterances gracefully wherever you are in the game. Try saying “step forward” when the path is blocked by a monster for example.

A successful quest up the 13 steps and out into the light should take players roughly 10 minutes which our user research shows this is the optimal length of time for a casual game experience.

From a technical perspective, we’re also really proud that we came with no prior knowledge of the Alexa Web API for Games and a short time later have a robust game at the end of it.

We’re also really proud of the UI and the game engine behind it. Both can be expanded and adapted to produce card based games for other brands or concepts.

What we learned

We learned a lot about the Alexa Web API for Games, particularly the huge potential it has, it’s been difficult not to start thinking about our next game whilst building this one.

Coming from purely audio design for Voice, adding a visual element powered by the web API for games meant a lot of new considerations and questions:

  • What makes sense in audio alone as well as as with audio and visual elements?
  • How might we provide sufficient variety of game elements whilst also keeping the scope deliverable in just over a month?

we also test every intent against every interaction point. Because our first interaction is to ask the player "do you know how to play?", it never occurred to us that someone might ask for help at the point so we never tested it. That oversight was revealed at the point of validation when the Alexa console reluctantly informed us that it couldn't pass validation as help didn't work.

We also learned at the point of submission to the certification process that Amazon require prior approval of entities developing kids' skills. We are currently awaiting that. Our skill ID is amzn1.ask.skill.95b7260c-4b28-49d7-9fac-d0cc66b7d116 and the case number for approval is: 7624655481 (and at Aleida devpost's request, I've included screenshots in the gallery showing our submission attempt today and that that is the only blocker). It's kind of ironic as both of us have spent years making kids' content for a variety of platforms.

Lastly, we learned that a person can survive on just 3 hours sleep a night.

What's next for 13 Steps

More monsters! More items! More actions! It would be great to provide more variety and surprise to further engage players, taking them deeper into the underground world of 13 Steps.

With more variety and surprise comes more player investment - players might like to save and resume if they have built up an inventory of interesting items.

As a horror game building in APL for Audio support is an obvious next move. Because of the compressed delivery schedule, we could only imagine being able to dynamically mix atmospheric sound effects with the shrieks and screams of our monsters to make a richer, more terrifying and immersive experience. And this dynamic audio would ensure the Darkness would be able ‘turn up the sinister’ the closer it gets!

The game currently only has one way communication via the Alexa Web API for Games. Introducing a touch UI would allow players another way of interacting and provide two-way communication between the view and the backend.

We’d also like to create a multiplayer mode. That would allow players to compete against one another to see who can stay ahead of the darkness and survive longest.

Ideally, the world building of 13 Steps would spill over into other media: films, toys, memes. The journey starts with the first step

Share this project: