First, the story has been completely rewritten to now come from Chelsea’s POV. This is crucial since you now play as Chelsea instead of a nondescript character. Likewise, I’ve introduced a new non-binary character: Sam, who takes the role of the previous “MC”.

Paintbrush, the puzzle system, now uses a more reliable approach to validate puzzle solutions. Although the idea of using machine learning to validate puzzles sounded fun, it was impractical in practice. Paintbrush now utilizes the Protractor gesture recognition algorithm. This approach should be less time-consuming to iterate and develop on, and it will increase performance by reducing the need to use machine learning.

Next, the “random solve mode activation” glitch has been resolved after discovering a race condition problem regarding player movement. This should make entering and leaving solve mode much more reliable.

Finally, some other small bugs in Caslon and the game have been resolved and should be much better.

I’ve released an updated version of the prototype directly on to TestFlight for iOS and iPadOS, and the macOS version is currently under review by Apple for TestFlight. In the next milestone, I hope to tackle some of the bigger problems with the prototype, such as the lack of a tutorial and adding assets to the game to give it a more polished feel.

If you haven’t signed up for the TestFlight program, you can get started here: https://indexingyourhe.art/prototype.

TL;DR - The prototype has launched for iOS. It’s very rough, but demonstrates the technical aspects of how the game will function. Try the prototype at https://indexingyourhe.art/prototype/.

A paintbrush and a canvas

I’ve done a lot of work since the last devlog, where I showcased a number predictor using SpriteKit and Core ML. The basic project for this became the foundation for one of the biggest parts of the game: the puzzle system (aka Paintbrush). I won’t go into details as to how the puzzles work, as that would spoil the solutions, but the general idea of using a CNN to predict what solution the player has drawn works pretty effectively. It took about 900 images with slight augmentations in Create ML to get it working solidly; however, there’s still a bit of leniency in the code that will need to be addressed.

I’ve found that Paintbrush works really well for iPads with Apple Pencils, though drawing with your finger or cursor on a Mac also works as well. There’s no boundary like there is in _The Witness_, though I do have some code that prevents the player from drawing outside the panel. I still have to tweak Paintbrush some more to be better with validation, but I’m still pleased with the result.

Likewise, I’m happy with the current setup for maps. Typically, when I make games with SpriteKit, I use the built-in tile map node, SKTileMapNode. However, I’ve found this node isn’t all that performant and can often cause memory leaks. Furthermore, making levels and maps using it can be painful, especially when working with tile sets; tile sets have to be generated in the SpriteKit tile set format, which takes a lot of work to set up if you have hundreds of tiles.

Recently, I discovered a framework that brings support for tile maps created with the Tiled map editor called SKTiled. After creating a tile set with the Tiled editor and mocked a simple tile map to use in SpriteKit, I wrote a small scene to import the tile map, and it works really well. I was able to cut down boilerplate code I usually wrote for parsing tile maps and still have the flexibility of the levels. I still need to measure the performance cost of SKTiled, but I’m loving this new approach already.

A quick conversation

The story is the other big aspect of this game that I’ve been fully developing, and it was the very first thing I did before doing any work on the game’s code. This helped me focus a lot on the character development and the general direction of where to take the game.

Generally, my experience with writing stories for games comes from writing visual novels like Unscripted. As such, I wanted to ensure the game has a solid experience as a visual novel in addition to Paintbrush and its Witness-like behavior. This includes a lightweight scripting system that is performant and expressive.

Enter Caslon, the visual novel component of the game, and Jenson, the file format for the game’s dialogue. Both were designed to be lightweight, flexible, performant, and expressive in nature. I based the Jenson file format loosely off the Dialogic timeline format, which stores its data as JSON. To make it lightweight and performant, I’ve compressed the files using the Brotli compression algorithm and store the compressed data as a Base64-encoded string. The tiny file size also helped my code read the files more quickly, making loading them a breeze. The current story, in its scripted form, takes only 77 KB, which is even smaller than the Markdown source files they came from. If you’re interested in playing around with the Jenson format, I recommend checking out JensonKit at https://github.com/Indexing-Your-Heart/JensonKit.

After building the Jenson format and converting the story files, I worked on creating a basic visual novel scene (aka Caslon) that took advantage of those files. It’s a relatively basic scene that displays dialogue and menu options, when necessary. However, it works pretty well and behaves similarly to what Dialogic and Ren'Py offer. I’m pleased with the results and look forward to testing the support for loading images once I can conjure up some assets to use.

A cleaner workspace

I focused a lot on making the game’s codebase as portable, modular, and testable as I can. Though I haven’t written unit tests for some of the game’s functions yet, I tried to separate most of the concerns and subsystems into their own separate Swift packages, which get imported into the main game. Caslon and Paintbrush live in their own packages, and Shounin, the game project, imports the rest. Given the modules and how I structured the project, I can safely say this is the Swiftiest game I’ve written, literally. I hope to further improve the codebase as the game grows.

Even though this is just the prototype version of the game that shows what the game will feel like, I am really proud of what I have accomplished. I’m looking forward to hearing how others find the prototype and see where my target audience is.

Check out https://indexingyourhe.art/prototype/ to join the TestFlight program and try the prototype today. I also highly encourage joining the Discord server at https://discord.gg/CXxnVhX to join the conversation.

The crafter’s hand

In the previous devlog, I had discussed the possibility of moving away from Godot in favor of Swift and SpriteKit:

I've always been enamored with developing apps for iOS and macOS since I learned the Swift programming language years ago. […] I'm torn. I could make Indexing Your Heart in Godot, tune it for the various platforms it will win on, reach a wide audience, and be happy. Or, I could make Indexing Your Heart the game I want it to be with the absolutely best integration at the risk of a small audience.

To say that I thought a lot about this is an understatement, but, suffice to say, I've bitten the bullet and switched. As of a few days ago, I created the starter project for Indexing Your Heart in a multiplatform game template, using SwiftUI and SpriteKit, localizations and other goodies included. I’m excited to take the next step in shaping the game to my next masterpiece.

Setting the stage

Next, I mentioned that I was reconsidering the core gameplay loop:

[…] I’m very much reconsidering the genre of this game to be a puzzle game. And instead of trying to come up with good puzzles in a short timespan, I’ll keep working and reiterating until it feels just right. If it takes five years, then so be it. As for what the puzzles might entail, I have a few ideas floating around, but I’m not 100% sure at the time of writing this.

I did a little more than reconsider it; I spent nearly a week focusing on a brand-new gameplay loop. I’m still working on fleshing out some of the more intricate details, but I can at least give you a small snippet from the specification I wrote up:

The game will heavily focus on two primary aspects: [Marty’s] inner fears and anxieties she faces on a regular basis, and [their] growing relationship with the other main character (MC). On each day, players will play as [Marty] while she prepares for her date […] However, each level will focus on a specific fear or anxiety that [they] faces on a regular basis, such as the fear of not being accepted into society. These fears and anxieties will manifest as obstacles for players to overcome with a series of puzzles tuned for that specific anxiety.

This new gameplay loop was based off an idea I wrote up in a draft back in May that I’ve since fleshed out in more detail. I’m really excited about this new approach, as I’ll get to play around with some interesting ideas as the game progresses. I don’t want to spoil everything just yet, so I can’t provide much for the time being; however, I can’t wait for everyone to play around with these new ideas.

To act gracefully

Finally, I spent some extra time working on a brand-new Code of Conduct. If you recall, from the very first blog post about this game, I mentioned how important it was for me to license the code under an ethical source license:

I make a good handful of my projects open-source because I believe in contributing back to the open-source community as appreciation for all the help I get, [and], like myself, I want to be able to help others in the same way, whether it be game modders, translators, or other members of the open-source community. However, I realize that there are quite a few components to my game that, if misused or abused, can seriously hurt people, especially those in the LGBTQ+ community.

The last point is extremely important to me. I plan to explore a lot of ideas with this game (albeit not as many as Thekla’s upcoming game), and I want to be able to do so in a safe environment. As such, in addition to licensing the code under a license that will ensure this safe environment at a source code level, I have also written up a new Code of Conduct that will ensure this safe environment in the entire project. You can already view this new Code of Conduct in the source code repository, though I plan to make a separate page on the website available that contains the most up-to-date information on it.

In the coming weeks, I plan to show progress on a prototype for some levels and other bits about the journey. Let’s make something great! 🔨🐺

In the previous devlog, I briefly mentioned that I was looking into rearchitecting some parts of the game:

Second, I will be revisiting the premise of the game as a whole and determine how to proceed with the project in the future. While having a mix of a visual novel and an RPG seems fun and unique, I’m not sure if the story is well set up for this approach. Likewise, I’m partially considering 3D games or games designed for mobile devices.

This major task has been looming over my head since I started a new job, and I’ve done lots of thinking about the game and what I want to shape it into. I’d like to share some of these thoughts with you as I finish deliberating, although some of these thoughts may not fully make it into the game.

A swift breakup

The Godot game engine has been an indispensable tool to creating a lot of the games I’ve worked on in the past such as Bug Bounty!, Package Resolved, and The Costumemaster: Reloaded. It’s quick, easy to use, and allows you to make games across platforms with ease. The internal scripting language, GDScript, is very Python-like and easy to pick up. There’s a lot to like about Godot as a tool for making indie games, and I love making games with it.

However, I feel that love is starting to fade a bit, including the general prospect of creating cross-platform apps. While I understand the appeal to create an app that works across platforms with little to no effort, I’ve come to fully appreciate writing apps native to the system it was designed for. Performance, integration, and compatibility are a few advantages I can name.

I've always been enamored with developing apps for iOS and macOS since I learned the Swift programming language years ago. Time and time again, this love has faded and rekindled. Swift 5 and SwiftUI, SpriteKit and Game Center, Swift Playgrounds, and newer versions of Xcode have contributed greatly to this; in fact, some internal tools for Indexing Your Heart have been written completely in Swift. This love has rekindled again as I work as an iOS developer, doing the things I've always wanted to do.

I'm torn. I could make Indexing Your Heart in Godot, tune it for the various platforms it will win on, reach a wide audience, and be happy. Or, I could make Indexing Your Heart the game I want it to be with the absolutely best integration at the risk of a small audience. In a lot of ways, I’m facing the same potential issues I would with the original version of The Costumemaster; however, I feel it isn’t as bad because I’d be designing for iOS first, which has a much larger market share than macOS does. It’s a tricky situation to be in, and I value making a quality product with the best tools and skills needed.

Of course, this doesn't necessarily mean I'm thinking of dropping Godot from my toolbox entirely; a good handful of games I'm developing still use it, and I want those to be as accessible as possible. Furthermore, I may have plans for smaller games that I want to develop with Godot in the future.

It’s been quite a long while since I started developing Indexing Your Heart, feeling confident on where the project would go. With a story nearly ready for revisions and a general idea for the gameplay, I felt that I could get the game done in a reasonable amount of time.

However, as winter break began, things began to slow down. Certain aspects about the game became uncertain, such as sprite artwork, budgeting, and music. Although I had done some work over winter break with importing the story into the game’s codebase and creating prototype sprites with the excellent Mannequin creator, I didn’t really touch the project since February. The typical semester workload made it difficult to focus on the game and what I wanted to do with it in the future.

Fast-forward to today, where I’m writing this blog post on a brand-new Tumblr blog. On my own personal website, I discussed why I made the switch to Tumblr recently:

While I’ve had a blast being able to control every aspect of my website, I’ve found that I’ve updated my website less often enough to warrant using a static site generator like Jekyll. […] I feel confident in my content’s new home. Additionally, Tumblr provides the controls I need for my website and blog, along with a simple interface for writing blog posts like this one.

_Indexing Your Heart_ is still very much on my mind; not a single day passes where I stop thinking about the characters of that story and why I was so excited to build the game in the place. Because of this, I still want to develop the game and plan to finish it (at some point).

So, what’s changed?

In short, a few things have changed with the project going forward:

• First, while it was cool to have custom fonts and granular control over the website, I’ve migrated all content for the website over to Tumblr for the same reasons I listed before. This will guarantee that I spend more time on the game and less time on the website itself. I will revisit theming in the future.
• Second, I will be revisiting the premise of the game as a whole and determine how to proceed with the project in the future. While having a mix of a visual novel and an RPG seems fun and unique, I’m not sure if the story is well set up for this approach. Likewise, I’m partially considering 3D games or games designed for mobile devices.
• Finally, I will be more transparent about the development process and post updates as frequently as I can. Because this blog is now on Tumblr, this should allow me to express my ideas more quickly.

I’m excited to tackle the game that is _Indexing Your Heart_ again and give you all a wonderful experience.

Before we delve into the details of this game's implementation and how it will play out, let me first address the main story of the game. You and Katorin, your closest colleague and friend, have recently finished a huge project at ArcAI Software, the company you work for, and you head to a bar that night to celebrate. After getting plastered with a couple of drinks, Katorin introduces you to the band that was performing that night, The Serif. While the lead singer, Chelsea Roslyn, ran out early to tend to personal matters, you manage to strike a conversation with the band, who Katorin is close friends with. Later that night, a mysterious figure shows up at the door in a hammer costume, explaining that they wanted to hand-deliver some mail to you in order to avoid paying for postage before promptly leaving. Upon opening the envelope, you discover a note with a phone number and a brief explanation of the figure's intent: getting a date out of you. Hesitantly, you text back and accept the offer. The game will follow with you meeting with this mysterious figure every Friday night.

Initially, I had planned to make this an unofficial sequel to Unscripted, where Katorin would wear a candle costume and secretly date you. However, I noticed that I started to get a little tired of the candle costume being reused across multiple projects (namely the Candella project), and I wanted to add something that will surprise people. After speaking with some colleagues and friends, I ultimately decided that I would change the story ever so slightly to keep the main premise, but provide some twists and turns. Thankfully, I had a canned prototype that shared similar story points that I reused, except the admirer was an anthropomorphic coyote.

The Technical Stack

Since I had a blast using the Godot Engine to make a few small games such as Bug Bounty, The Costumemaster: Reloaded, and Package Resolved, I decided that I will use it again for the second time in a major project. The bare-bones prototypes for Indexing Your Heart were initially written in the Kotlin programming language, thanks to the Godot Kotlin/JVM plugin. Despite its limitations and alpha state, I was set on writing a good game with the in-development technology. However, I did realize a few things that made me change my mind:

• First, I'd have to create a Java Runtime Environment (JRE) for each platform. While that isn't terrible in and of itself, it would mean I'd have to rely on CI to make the builds and download them for distribution. Given that the project is not open-source (at least not currently), I'd be looking at some decent times for GitHub Actions to compile the builds.
• Installing various toolchains for Kotlin can be a bit expensive, ranging from installing Gradle to getting IntelliJ CE (or even Ultimate). Additionally, the latest version of the Godot Kotlin/JVM plugin doesn't support the latest version of IntelliJ (at least at the time of writing). I'd be stuck running the previous versions of IntelliJ until the team releases a new plugin version compatible with the version of IntelliJ I would have installed.
• Finally, while I vowed that I would not use C# for games in the future, I realized that the only way I was going to be faster in the language is if I used it more. My friend made this more evident when he started working on a web application with ASP.NET on his device.

Thankfully, I don't need to set up a fancy IDE like I have in the past to jumpstart the project. Simply downloading the Mono version of Godot, the .NET SDK, and the C# extensions for Visual Studio Code were enough for me to get up and running. I only had to spend at most half an hour to get everything set up, including changing the build tool in Godot over to .NET CLI instead of Mono (since Mono support is still a work in progress on Apple Silicon). With all the setup out of the way, I rewrote my existing scripts in C#, which took about a couple of hours.

Since I was coming back to C# in a more supported environment, I also decided to try out the Dialogic plugin for Godot, which provides a nice utility for writing dialogue without the hassle of generating dialogues boxes, writing a custom JSON format, etc. Although Dialogic doesn't have the same niceties that my older system with the DSL did, it will handle a lot of the things that my version did not have, such as animations and sounds. Since Dialogic uses JSON files to store data for dialogue and characters, this also lets me quickly add in portraits and other properties using Python scripts.

A Roadmap to Follow

I plan to release Indexing Your Heart to the public commercially by the end of 2022 like I did with Unscripted, spending as much time as I can focusing on the core aspects of the game.

Currently, there are a few major milestones I have in mind to reach:

• Completing the story writing and visual novel aspects of the game
• Creating the RPG world and experimenting with game balance
• Gathering the assets to make the game look nice
• Starting a small feedback program and getting advice from you, the community
• Implementing feedback into the game and working on translations as necessary
• Releasing the game

There's a lot in mind, and this will be the first time I have set milestones in place (I didn't do this with Unscripted). Thankfully, I have some contributors and friends helping me craft the game as I work on the story. Ideally, I plan to finish off the story by the end of the month (coincidentally, it's National Novel Writing Month at the time of writing) so that I can begin on the more fun aspects with the RPG.

An Important Note on Licensing

I make a good handful of my projects open-source because I believe in contributing back to the open-source community as appreciation for all the help I get from looking at open-source code and using free and open-source tools such as Pixelorama and the Godot engine. And, like myself, I want to be able to help others in the same way, whether it be game modders, translators, or other members of the open-source community. However, I realize that there are quite a few components to my game that, if misused or abused, can seriously hurt people, especially those in the LGBTQ+ community.

After some deliberation, I have decided that, at release time, I will license the game under the Cooperative Non-violent Public License, an ethical source license that lets you download, modify, and redistribute the code to the game as long as the modified distributions don't cause any harm or violence towards others. I know this will be a controversial decision, especially within the free and open-source community; however, I need to take on the responsibility of making sure that my work doesn't get abused in a way that can hurt those that identify with the characters deeply. It's a sacrifice I'm willing to make to ensure safety while also allowing the freedoms of tinkering that have helped me make games like this possible.

I plan to make the source code available to the public around when the story is near completion.

I look forward to sharing more with you about this game as it progresses! Stay tuned for future updates and when I plan to release prototyping builds.