Making Surgery Gameplay More Engaging (Week 15 Update)
Overview
We made our Steam store page for RavenHeart Hospital public last week and already have 50 wishlists! We have new details on live events scheduled for next week. This week, I talk some of the awesome things Discord users made for our first Story Jam. We added in a new Scoring System to complement the operation gameplay. I also talk about the tech enabling some complex scripting and collaborating using Google Drive.
Goals
Showcase the game
Important Dates:
Steam Games Festival (Demo Deadline: May 15th, 2020, Event: June 9th to June 15th)- New Update: Our game has been reviewed and is confirmed to be a part of the Steam Games Festival. We are excited to present the game at our first large event. You can wishlist the game on Steam. More details below on events we are planning on having for the event.
Playtesting
Last Friday evening, we published an updated version of the game's demo to itch.io with the new Scoring System, some bug fixes, and a new episode for Annabel, our veterinary surgeon. Hope to hear what kind of scores you earn!
Support User Generated Content
The first Story Jam wrapped up last Saturday. The event's theme was "Start Of the Summer" and the goal was to create a story using the custom scripting format we had. The results were some new characters, and update to existing OC, and a whooping 34-page storyline with a bonus followup. You can see more in the #story-jam channel in our Discord Server
Lily Summer Holiday
Character art by Rebecca Bushko. Lily is a high school student and Dr. Holiday's daughter, shadowing her mother for the summer.
Zachari Skylar
Character art by Rebecca Bushko. Character concept by Discord user CraftmasterMatt. Zachari Skylar is an ace cardiothoracic surgeon. At the beginning of summer, your doctor joins Zachari, Dante, and other characters to combat a scorching heatwave and a mysterious series of fires throughout Charm City.
Scoring System
We add a first-pass at a scoring system for the game and hooked up a Post-Operation screen to share with players the score the achieve and what rank and grade they scored for their work in the operation.
The video to the left shows the scoring system in actions and I'll explain how it works here. For every successful action that a player performs during an operation, the player receives points towards a hidden "score pool". If the player successful completes actions before the chain bonus timer runs out, their chain bonus increases. The chain bonus is multiplied to the sum of the "score pool" the player has successful made consecutively, resulting in the displayed New Score. If the player fails to complete an action in time, the New Score is added to the Total Score and the New Score is reset.
Some examples with numbers. Let's say that every successful action is worth 100 points.
On the first time a player completes an action, the score pool contains 100 points, the chain bonus is 1x, the New Score is 100 points times 1x, so it is just 100 points. The chain bonus time begins to countdown.
If the player completes another action in tome, the score pool contains 100 + 100 = 200 points. The chain bonus increases by 0.5x to 1.5x. The New Score is 200 times 1.5x and is now 300 points. The chain bonus time is reset and continues to countdown.
If the player then fails to complete an action before the chain bonus time resets, their New Score is added to their Total Score, making it 300 points. Their New Score is reset to zero. Their score pool is cleared to contain no scores. The chain bonus is reset to 1x.
There is some tweaking for this system that we will do to make it more fair, such as pausing the timer during operation phase transitions, playing with the length of the chain bonus timer, and having different actions worth different points.
But we are pleases with the result of the system. It achieves the goal of making operations more engaging and more interesting to replay and try to do better. It also builds on the player fantasy of being an ace surgeon performing complex, life-saving operations. In general, this fit our design goal of wanting skill to be rewarded but not required for the game.
New Script Feature - Nested Homogenous Cues
This write up will be a bit technical.
This feature allows for choices to be presented within choices, or for conditional cues to exist within a conditional cue. The script parser is made up of multiple different parsers focused on parsing a particular region of the script. The Cutscene Parser parsers Cutscenes, the Choice Parser parses Choices, and so on. When a parser starts parsing, it is given a new instance of the object is it parsing data into. Before when the parser finished parsing, it would stop referencing the object instance it was using. For some parsing, it helps to have data that is retained all throughout parsing a region and for the parse to be stateful. The problem was that if in the processing of parsing, and region contained a similar subregion, the same parser would be used. This problem manifested itself as an error when parsing continued past of the scope of parsing the subregion. At that point, the parser no longer references any object instance, either for the entire region or subregion.
The solution I am using for now is to instantiate a new instance of the given parser at the same time we instantiate a new instance of the object to parse data into. This avoids the issue of parsers going stale. A future optimization would be to pool the parser instances or to refactor the parsers have better lifecycle methods and have explicit object instances passed in.
Google Drive - Unity Syncing
We have a problem with asset management. Assets can exist in the game's repository, Google Drive and in local computers as they are in progress. On top of that, we have episode scripts that we written in Google Drive that are referencing other assets such as background art and background music. Previously to share music, we had the music posted in a Slack channel and then manually imported into the game. For scripts, they are downloaded into the game's repo and I run a validation script to make sure they are are properly formatted and reference assets that exist.
Managing the names for background music led to a tipping point. Was the name of the files in the game's repo the source of truth? Were the scripts the source of truth when they reference the files? Was it the name of the files as they existed in Slack? One way of dealing with a problem is to constrain it, so we agreed an ideal approach would be to have Google Drive, an easily accessible location for all developers, be the source of truth for the files. We would designate a folder in Google Drive to contain all final background music files and scripts should reference only files that exist there. In turn, the game's repo should reflect the state of this Google Drive folder.
Fortunately, I had already been exploring using Google Drive's .NET API to enable easier importing of data from Google Drive, initially starting with importing scripts. My notion was that we effectively wanted a folder in Google Drive to sync to a folder in our game's resource folder. My thought was to define a file in the game's repo that states where from Google Drive to sync from. Here's what that file looks like:
It's a pretty minimal file, defined in the JSON file format. It defines the ID of the Google Drive folder to check and the type of files to look for, specifically mp3 audio files.
In the image above, you can see the folder as it exists in the game repo. It contains all the audio files imported automatically from Google Drive as well as the ZSync file that defines where to pull data from.
The benefit this approach gives us is that we can expand this to more than just background music. We could automatically sync scripts and other data that currently is being manually downloaded into the game. It means that the game's repo should only contain "final" game assets and assets within Google Drive should be consistent with each other.
Future Plans
Pre-Operation Scene
Right now, the pre-operation scene looks just like a cutscene. We want this sequence to give more information about the operation that is about to occur, give some light information about a patient and their afflictions. I have already begin drafting up and laying out the UI for this sequence.
Steam Games Festival Events
We have two major events plans for the Steam Games Festival. From 7pm to 8pm June 9th, we will do a developer livestream of JT and I playing the game and talking to viewers about the game, answering any questions live. From 12pm to 2pm June 10th, we will be doing a developer Q&A on our Discord Server. We look forward to showing off the game and hearing what people think!
The End
I hope you enjoyed this week's edition of our studio's status update. Each week, we try to bring new and interesting updates about how our studio and game are developing that we think people will like and learn from.
If you have any questions, comments, feedback for me, you can email me, Zappy, at zappy@ravenheartgames.com.
If you like this post, you can see more in the Devlog section or check out last week's post.
If you've been a part of our playtests and would like to chat with other players or us directly, join our Discord server below.
If you are interested in playing our latest demo, you can click the button below!