Overview

Last week was a stricter working week. We focused more on a small subset of significant tasks. We have a rough outline for our first episode of gameplay. JT has been diving into writing out rough drafts for over half the scenes in the episode. I was busy getting the core minigame tech in place with scene transitions. We are incorporating our demo scripting format into the game engine to test the full pipeline of generating scripts and seeing them in-game. We also have a new, exciting goal that is fast approaching!

Goals

NEW GOAL: Demo at CCBC Tech and Gaming Expo (Deadline: April 25th, 2020)

We got invited to the CCBC Tech Expo on Friday! It is an exciting opportunity for us to showcase our game months before the GameScape event. The deadline for GameScape should nicely set us up for having a fully playable demo for this Tech Expo. This event will also give us an early chance to see what setting up and showcasing our game will be like in the real world. We are also very excited to see all of the other projects people are developing in our local area.

Apply to GameScape (Deadline: March 31st, 2020)

GameScape is a portion of the Artscape summer festival that "showcases games and the creative people who make them." We know that for the game we are making, we want to show it to a broad audience to play it and give us feedback. Since we based around Baltimore, this event is perfect for us, in terms of travel-time and minimal setup. The March 31st deadline means that we have about six weeks to get a vertical slice of the game we want complete for submission.

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

Dialogue Drafts

JT is taking ownership of this. I am helping with brainstorming and editing. It works out best for us since I am focusing on the technical aspects of getting a vertical slice down. While I am passionate about brainstorming ideas for our project, JT is excited and more able to focus on developing the details of the character interactions and dialogue. We both care about the story that we tell, but from a time management perspective, this just made the most sense for us.

JT has written the rough drafts for over half of the scenes for our demo episode and is planning to have the first of the scenes roughed out early this week. We will go through the scenes in more depth and review them internally and iterate on them. Afterward, we will be sharing out the drafts externally to get more reviews and feedback.

Core Gameplay Loop Implementation

I wrapped this up towards the end of last week. The main gist of the gameplay is that as a doctor, you talk to other doctors, nurses, patients, etc. and then before operations on the patients in a minigame. This minigame consists of using various tools to deal with the multiple afflictions a patient may have. These afflictions can appear in different areas of the patient's body.

What we have now for the minigame is as follows:

1. Enter an operation
2. Clear out the afflictions that the patient has with various tools
3. Make an incision to proceed to the next operation site
4. Clear the remaining afflictions that the patient has there with various tools
5. Suture and clean up the initial incision

This work involved using a lot of the UI architecture tech that I had written about in the previous blog post. I was pleased with how much of the core tech could work "out-of-the-box" without changing.

I also implemented a light messaging system to handle events propagating out as a result of specific actions and conditions. A system like this is helpful for a few reasons. It can help to decouple code and easily change what code is responsible for handling a given event. The code sending an event does not have to be concerned about who is listening for the event. A message sent as an event can contain as much payload data as necessary or none, and changing the contents of the message is very easy.

Overall, the completion of the minigame core loop helped us to build and prove out more UI tech. We also added some necessary plumbing for orchestrating the way the game runs.

Future Plans

Artist Search

We have gotten some early submissions from the original art test that we sent out. We will be reviewing the submissions and iterating on the art test and reaching back out with feedback. We have also had some candidates find other projects, and we wish them the best of luck.

We have also been thinking about how we are going to handle background art as well as patient / surgery art. For the interim, we are planning to take photographs from our local area and apply filters to them to achieve a stylized look that we want. This solution takes advantage of the fact that we want our game to take place in a Baltimore-inspired setting and the background splashes that we want should look more realistic and detailed. We have talked about using a 3D model for the surgery art and taking 2D still images at the various positions and angles that we need for our operation minigame scenes.

Episodic Scripting Parsing

I talked about the beginnings of this new scripting format in previous devlogs. The goal of this new scripting language is to be easy for non-technical people to be able to create, edit, and review their work as though it were a screenplay. On Friday, we fleshed out more details about the handling custom formatting for narrative dialogue, scene setup, and scripting behavior of our core minigame. There are more conversations about the capabilities we will need from the scripting format, including multiple-choice dialogue. But for the immediate future, I will be taking some time to be heads-down to get the parser for this format working.

The reason for this focus is because it is a heady problem to tackle. The script is implicitly defining a hierarchical data structure with heterogeneous data models in a custom syntax. These properties make testing the functionality of the parser very easy, but the implementation of the parser requires special care.

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!