- Developing in Skill Flow Builder
- Standard Alexa Versus Skill Flow Skill Builder
- Downsides and Limitations
- The Wrap Up
The Skill Flow Builder was introduced by the Alexa team at last year’s Alexa event at the Arcade as a way of creating ‘RPG-lite’ experiences with a little help, compared to standard skill-building tools. Developing in Skill Flow Builder is done by defining scenes, and creating the flow between them. The basic structure of each scene looks like this:
@scene name
*say
content
*reprompt
content
*show
content
*then
scene instructions
So the flow is:
- present information
- get the user response
- do something inside the ‘then’ section
This actually turns normal skill development on its head. Normally an Alexa skill is built up by defining intents,
each of which can be fired at any time. The skill code is then responsible for determining what makes sense based
on the current user state within the skill. In Skill Flow Builder, a scene defines the current context for a user,
and the available actions or valid responses are defined for that context within the *then section, using hear statements.
This makes the experience of creating a flow through scenes in a story much more straight-forward than normal development,
where a skill is developed as a series of intents indicating actions a user can perform, and then the concept of
state and flow through a story would be implemented whole-cloth by the developer.
In order to put Skill Flow Builder through its paces, I I implemented as much as I could of the original Fighting Fantasy gamebook The Warlock of Firetop Mountain It’s important to note here that this gamebook is the copyrighted intellectual property of the original authors - I make no claim on the material here, and am only using it as a source of mechanical challenges to flex Skill Flow Builder with. The big reason behind choosing to implement this gamebook is that the gamebook’s experience for the player is a perfect fit for Skill Flow Builder:
- present context information to the player
- present options for the player’s choices
- get player choice
- move to next scene
The Fighting Fantasy gamebooks also have a simple turn-based combat system, some basic inventory management and some case-by-case exceptions to the rules - perfect for an ‘RPG-lite’ experience.
Developing in Skill Flow Builder
Skill Flow Builder is intended to be used by two different roles - a designer, and a developer. Design is done in SFB Editor, development is done in Visual Studio Code. SFB Editor provides a graph view of the flow of scenes along with a text editor for editing scenes directly, whereas Visual Studio Code is a pretty traditional IDE. The intent seems to be that team members keep in sync via source control, and are editing in one tool or the other. While Visual Studio Code will detect changes made in SFB Editor, it’s necessary to reopen the current project from scratch in SFB Editor to load changes made in Visual Studio Code. Both tools interact with the same project file structure, and edit the same .abc files where scenes are defined and implemented. These files are text files, so a half-way decent merge tool should make resolving conflicts in source control relatively painless (I’m a huge fan of Atom’s git package for in-editor conflict-resolution)
## Installing Tools Install both tools is a straightforward process. The only slight hitch here is that the build and deploy command-line tools for Skill Flow Builder require Python 2.7. There’s also a little work in configuring an IAM user for the SFB deploy process, as the deploy tool creates and configures all of the server-side resources required for the Alexa skill generated.
If you’re installing on Mac, it’s worth noting that Python 2.7 is no longer supported by Homebrew, which means a native install instead. (Time to get that virtualenv going finally!)
## The Experience of Developing
Developing in either tool was a genuine joy once you’re familiar with the syntax. Both tools have autocomplete and provide suggestions
while typing, as well as syntax highlighting. The indenting and autocompleting experience is a little better in Visual Studio Code,
making it much easier to get into a groove while coding, particularly when managing multiple if clauses. in both cases, code is validated in
real time, the most common error being a reference to a scene that doesn’t exist.
Given a choice, coding directly in Visual Studio Code is recommended. The editor is more responsive - SFB Editor lags early and more noticeably as a project grows in size. Both tools experience slowdown when providing autocomplete suggestions for scene names once a project grows in size. I found things started to get sluggish once all 400 scenes for Warlock of Firetop Mountain were defined.
Standard Alexa Versus Skill Flow Skill Builder
So what advantages does developing in Skill Flow Builder provide?
State Management
State is managed transparently for you - the flow between scenes is handled on your behalf, and the developer is responsible for defining the flow from scene to scene, and what actions are available in each scene. This is a complete inversion of normal Alexa skill development, where available intents - the actions a user wants to perform - are defined in isolation, and the concept of state must be built from the ground up for a skill.
This also includes the state management for a player’s individual experience - using flag and the set / increase / decrease commands,
variables can be manipulated tracking the results of a player’s choices. The persistence for those variables - storing them in between
a player’s skill sessions - is handled transparently.
Previews/testing
The SFB Editor tool also provides an interactive testing tool, allowing designers to test the flow of an experience inside the editor. The editor has full support for Amazon Polly if using text-to-speech. The downside here is that preview loading is slooooow.
Support for Rich Audio
Skill Flow Builder also provides support for both recorded voice narration rather than text-to-speech, and playing background music along with either text-to-speech or recorded voice. For this week’s investigation I was more concerned with limitations around rules complexity, so these features weren’t demonstrated.
Go to and return operator <->
The <-> operator is likely to be a large part of any complex experience using Skill Flow Builder. It allows scenes to effectively
become reusable, thanks to being called in a way that creates an implicit return point. Set some flags or variables, pass control
to another scene, and then that scene returns control via a >> RETURN operator. The fact that these calls can be nested, creating
multiple return points in a stack, allows for more complex behaviour. It is this functionality that enabled implementing the
Fighting Fantasy combat system.
Downsides and Limitations
And, then there’s the downsides.
Stability Within SFB Editor
I experienced three separate crashes of the editor during my short time coding in it. Each time the editor would go blank, and require a restart. Handily, there’s a menu option to restart the editor from within the program itself. Going forward, I’d definitely stick to coding in Visual Studio Code and reviewing changes intermittently in SFB Editor. The visual reference of flow between scenes is great, but the tool doesn’t seem to handle constant changes well.
No Complex Variables
It’s very easy to manipulate flags, or simple variables, but there doesn’t appear to be support for complex structures like lists or arrays at the moment. So for example when implementing a story about vampire hunters, it would be possible to check if a player had garlic or a stake, if either was managed as a flag:
if playerHasGarlic or playerHasStake {
// do some things
}
but it would not be possible easily to tell a player all of the vampire hunting items they had in their possession - there’s no structure that supports iteration in order to build up a sentence to relay back to the player.
No Documentation For Custom Extensions
There doesn’t appear to be a reference available currently for creating your own custom extensions, and custom extensions appear to be a source of great potential power here. Going forward I’d invest some time in looking through the full Javascript source code provided with a standard Skill Flow Builder project in order to glean more information around what is possible.
No Templates for ‘hear’ Definitions in Scenes
In a number of scenes when implementing part of Warlock of Firetop Mountain I found an identical choice/command was expected from the player -
‘Go west’ or ‘Open the door’, but it was not possible to reference a standard template for the hear section of the scene indicating
what phrases were being listened for. This creates the need to define the same information in two places, whihc invites the possibility of
inconsistency.
The Wrap Up
Overall, the experience of developing in Skill Flow Builder was a delight. Having the narrative and mechanics sorted, it was mostly getting the prose in an order that gave the player the best experience, combined with intermittent mechanical challenges. I’d love to return to this tool and develop something to completion in the future, but I’d need a solid understanding of how to create custom extensions first, as that’s where any support for complex behaviours would come from.
For those of you looking for the skinny on Skill Flow Builder, either check out the table of contents at the top of the page, or the list below:
Pros
- state managed transparently
- story flow-based development more intuitive than intent-based for certain experiences
- good interactive testing tools
- support for custom extensions developed in Javascript
Cons
- performance and stability within SFB Editor
- no apparent documentation for custom extensions
- no complex variables