This two week stretch was a very interesting exercise. The most challenging, frustrating, and rewarding so far.

Going back to the start of Week 5, the plan was to create a prototype skill that used a complex rules system. When planning out the project, I’d envisaged this initially being an old school roleplaying experience like Dungeons and Dragons, but the decision during the project was to go with the following, working from parts of Alexander Swords’ excellent Forest Paths framework:

The player/captain hunts, negotiates and fights to claim bounties and gain wealth and notoriety.

I then refined that down further into the essential experience of:

The tension and excitement of helming a ship during a space battle.

Prototype development focused on the combat experience, because if this wasn’t enjoyable as the most visceral and high-stakes part of a player’s experience, then anything else surrounding the combat wouldn’t really matter. There’s a temptation to spin out a bit of a saga about the two weeks, but your time is at a premium, so let’s go with brevity as much as possible here.

The Challenges, And What Didn’t Work

Testing Speed and Identifying Error Causes

Initially it was difficult to determine where things were going wrong, and testing initially involved deploying an updated skill version & using browser-based testing tools. This was slow, and often took several attempts to find the underlying reason for an error. This being the most complex Alexa skill attempted to date, it was not surprising to hit these issues, but still costly time-wise.

Teasing Apart Layers - Is It Fun?

I found it difficult to separate the core game experience from thinking about the (missing) aesthetic layer for the prototype, versus thinking about a more simulationist model of what ‘made sense’ for a space combat, when the core question should have been Is It Fun?. Reading Art of Game Design in parallel along with the systems design consults was definitely informative, but it wasn’t possible to apply that learned information along the way.

Writing placeholder dialogue, even for the combat barks, was challenging to frustrating without having the time to sit down and think through the fictional conceit for the ‘character’ talking to the player, and anchoring them in a more realised world. I expect that challenge to be less time-intensive the more I go through the experience.

No Time For Play

With even the constrained prototype being created, it was difficult to find the time to play the prototype to get a sense of its ‘fun factor’, when time was being taken up with implementation.

OK, so that sounds like a lot of griping about a problem I created for myself, which is absolutely not the case. It’s more opening a very big door, and taking some impatient first steps. So let’s talk about…

Learned Lessons, And What Worked Well

Starting With The Language Layer

As a compass to set an initial direction by, looking at the language layer of what is being created worked really well. Find juicy verbs in the fictional space a skill is playing in, look for ways to realise them.

Forest Paths Relationship Between Actions And Resources

This is something I need to revisit and expand on. I look forward to going through the Forest Paths process in more detail rather than just skimming nuggets from it.

Why is this relationship so useful? Because it gives useful design levers to pull. For example, if you can employ evasive maneuvers in combat, it should cost some of your resources in exchange for the benefit (like fuel) The cost gives an action weight and consequences.

Adjective Ladders

Great advice received from Ben Scerri - rather than conveying information in hard to contextualize numbers, using escalating adjectives to give a sense of relative magnitude (eg. large, huge, massive) This was put to work in the prototype expressing hull damage levels (none, light, critical) and also internally to the implementation of the opposing pilot’s mindset (confident, panicked, dire)

Going Back To Narrative Roots

Whenever there was the chance to think of design decisions in terms of the underlying narrative experience, this simplified and clarified things. For example, in more tense sci-fi fiction where battles occur, a ship typically takes three shots from a ship of the same size before a combat is done:

• the first shot shows the battle has stakes, and heightens tension. Everyone shifts into a more focused, intense mode
• the second shot shows the opponent is deadly, and the crew may not survive the encounter. Critical damage.
• the third shot is the one that ends things.

So taking this narrative experience into account, it was straightforward to evaluate whether the relationship between weapon damage and hull strength was correct.

The Development Process

At the end of Week 5 I posted about a development process that seemed sensible going forward, including using a Trello board to track individual pieces of functionality. At first, the Trello board seemed like it might have been overkill, but it all worked together very well, especially with the use of annotation sets and a very basic Lambda function implementation for testing. Being able to ensure that the right intent is going to get invoked resolves a lot of potential confusion up front.

Separating Out Responsibilities

One thing that caused some tension during implementation was where the implementation of actual logic should go. A number of intents saw Lambda functions get bloated out with what could be regarded as ‘game logic’ rather than Alexa implementation logic.

Why does this matter? It’s all about testability - that chestnut that comes up again and again. It’s quicker, more precise and less onerous to test underlying Python clases implementing ‘game logic’ than it is to test that same functionality implemented in a Lambda function, which comes with all of the boilerplate of dealing with Alexa runtime infrastructure.

Late in Week Six a separation of responsibilities came to mind that will be used in future prototypes:

Lambda Function	Python 'Engine'	Python Objects
Gets parameters from request Gets current state Determines function to be performed --> Calls function <-- Gets result of function call Renders result	Performs one or multiple steps Determines event chain Returns event chain	Performs atomic operations

One point to note about this is by dealing with a list of events ratehr than pre-generated text, or implementing game logic in the Lambda function, it makes testing a lot simpler, and makes the shift from text-to-speech to fully-voiced experiences smoother, requiring less rework in test cases.

Text Assembly - Avoid Contractions

Avoiding contractions for proper nouns, like a ship’s name, when putting sentences together is a really good idea to avoid having to record multiple versions of a name. For example:

"engines on the Sunstar"

versus

"the Sunstar's Engines"

Closing Up

That’s more than enough text for now. I’ll talk about what’s next for this prototype in a follow-up post. Stay safe, be well.