2020/03/15 Status Update

Overview

For this week's update, I run through a technical deep dive into our custom script parser and showcase the kind of data we are crafting for it. I also cover our showcase planning, progress on our writing, and searching for artist support to bring our story and characters to the screen.

Goals

CLARIFYING GOAL: Showcase the game

Key Results:

• Apply to MAGFest Indie Videogame Showcase @ AwesomeCon 2020 (Deadline: March 27th, 2020)
• Apply to GameScape (Deadline: March 31st, 2020)
• Demo at CCBC Tech and Gaming Expo (Event: April 25th, 2020)

A rising concern with this goal is the COVID-19 outbreak and its consequences for large group gatherings and school closures. We are keeping a close eye on this developing situation and understand if some events end up postponing or canceling as a result.

Playtesting

In tandem with submitting to GameScape, we want to build out our pipeline for producing builds of the game and sharing them out to friends, family, and players that are interested in trying it out. As a part of that, we have a mailing list that you can sign up for to stay up to date with future playtest.

Recent News

Episode Scripting

JT completed the first draft of our first episode. It is 32 pages long, consisting of 10 scenes, 16 unique choices, and 2 operations involving 7 patients.

We reviewed the episode together, polished the usage of our custom scripting format, and came away with more nuanced writing decisions we must make for the characters and dialogue. We are happy with the overall direction for the episode and are excited to see more and more of it in-game!

The length of the episode and the amount of writing that JT did makes us more confident that creating a custom scripting format is the right call. It made reviewing the episode easy as we sat down together and read through the script aloud. The script format supports splitting up content, if we wanted separate the first half of the episode from the second half, or split up all the scenes into separate documents.

Artist Search

We have been in contact with an artist for commissioning character poses. This commission will include the characters that appear in the episode we've written as well as one additional recurring character, which we plan to be appearing in an earlier episode.

We are reviewing a contract to formally send to them as well as ensuring we are taking the appropriate business steps to handle a contract properly.

Episodic Scripting Parsing

It's alive!

Below is a snippet of a minimalistic cutscene, as defined in our custom scripting format. I have taken the liberties to highlight and bold some content to help highlight the structural information for the scene as well as add comments and ellipses where there is missing data.

To summarize this scene, a cutscene occurs where two characters are talking back and forth to each other, standing in opposing stage positions. One character, Annabel, poses a question to the Protagonist, where the player can respond with one of four options. How easy was that to interpret?

Structural details:

• Comments
  • We support line comments (// -) and block comments (/* - */)
• Start-End Region Cues
  • These regions define primary data models. They consist of a start cue and close with a matching end cue.
  • Examples:
    • Cutscene Region (*CUTSCENE / *END_CUTSCENE)
    • Player Action - Choices (*ACTION_CHOICE / *END_ACTION_CHOICE)
    • Choose Region (*CHOICE / *END_CHOICE)
• Cue Metadata
  • Cues appear as anything prefixed with an asterisk: (*). Some of these cues require additional metadata or optional metadata
  • Examples:
    • *TITLE: Episode 2-1, defined the title name for the cutscene
    • *ANNABEL, 2, happy, defined the character Annabel moving the stage position number 2 (the details of this aren't too important right now) as well as showing a "happy" expression

Some of the initial difficulties with considering parsing for this data format were that the data mapped to objects as defined in our programming language loosely, and the format can easily describe highly hierarchical data, with repeated handled for some ideas. Dialogue appears both as a "child" element of a Cutscene region as well as "child" elements of a Choice region, which are themselves children of the Player Action Choice Region, which is a child of a Cutscene Region.

As I was working on this, I found that it felt better to have separate parsers for each Region that would parse out information to our model of the data. So the Cutscene Parser would parse Cutscene data from the Cutscene region, the Choice Parse would parse Choice data from the Choice region. I also found that handling the removal of commented information at the very beginning reduced the complexity for each parser by ensuring that each parsing did not have to consider how best to interpret commented lines. This upfront approach also led to trimming any whitespace information, including tabs, from each line and stripping away complete empty lines.

With the data for clean lines, my approach was to try to define the regions into a set of hierarchical data based on cue tokens found. A tokenizer traverses line-by-line and builds a new token node, with the information for the line it is on. If the parser finds a region end cue, like *END_CUTSCENE, it works backward to find a matching region start cue, and adds all of the token nodes in between the two region points as children of the Region. It continues to generate tokens and back-propagating child token data until it finishes reading all of the lines.

With the tree structure of cue tokens, we can feed this data into a token parser, where each of the custom data parsers register to particular cue keywords (includes the Cutscene Parser to "CUTSCENE," Choice Parser to "CHOICE," and more). The token parser traverses the given tree structure, finding registered parsers that match keywords and sends them

information about a node or a child data model that another parser generated for a child cue token, and more.

All of this together leads to the above script and more complex scripts being parsed into useful data models for our game system to use to set up scenes and expected player inputs for different gameplay modes.

Future Plans

Character Art

We are planning to start work on having a full roster of characters and their art for our first playable episode as soon as possible. We plan to share more about this as we work through them.

Accounting Software Search

We want to find an excellent small business accounting software that can handle our needs. We've been experimenting with some options like Xero, but we are not yet happy with its capabilities, especially around managing and filing expense claims for our expenditure ledger. We believe that good software here should save us headaches around tax form filings and stay in good favor with the IRS.

Implementation, Polish, Polish

We have our core game loop working in our game. We've demoed internally a version that includes going to a dialogue scene, playing the mini-game which involves a two-part operation, and then wrapping up with another dialogue scene.

We have work to get the player's selection of choices displaying correctly in the UI, polishing, and cleaning the art for our operation sequences. We have tasks on our board and things that we want to get done in time for submissions date prioritized over polish details that we'd prefer to get players' input on first before tackling

The End

If you have any questions, comments, feedback for me, you can email at zappy@ravenheartgames.com.

If you like this post, you can see more in the Devlog section or check out last week's post

Once again, if you are interested in playtesting builds of the game or future updates, you can click the button below!