Something new, something old
It feels like it's been such a long time since the last update I've posted about Indexing Your Heart as a project. Suffice to say, a lot has changed with the game since the last prototype build I published back in April of this year, and it's about time I state where the project is headed.
It feels like it's been such a long time since the last update I've posted about Indexing Your Heart as a project. Suffice to say, a lot has changed with the game since the last prototype build I published back in April of this year, and it's about time I state where the project is headed.
Coming home (to Godot)
When I started working on Indexing Your Heart in 2021, I envisioned making a game that fused two genres together, leveraging all that the Godot game engine offered to me at the time. During that time, I had switched between multiple languages: Kotlin, C#, and GDScript, but I still stuck with Godot as my engine of choice.
In the summer of last year, I decided to pivot towards using SpriteKit and utilizing what Apple offers for apps and games on Mac, iPhone, and iPad while I re-discovered the game I wanted to make:
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.
When WWDC23 happened this year, something completely unexpected occurred: Miguel de Icaza, co-founder of the GNOME project, Xamarin, Mono, etc., created a brand-new Swift binding for Godot using Godot 4's GDExtension system. I challenged myself to try recreating Indexing Your Heart using de Icaza's bindings, and I was impressed with how far I could take the project. The binding has improved over time thanks to new features Swift 5.9 introduced, such as macros and parameter packs, and I couldn't be more pleased with what I can do.
I am happy to report that, at the time of writing, Indexing Your Heart has fully returned to the Godot game engine, using SwiftGodot as its core for game scripts. I've been able to successfully push out builds for macOS and iOS directly to TestFlight as well (albeit internally), enabling me to keep developing the game more efficiently.
Besides being a user of SwiftGodot, I've also been contributing to the project where I can to make the experience even better for game developers. When Swift macros launched publicly, I brought over some macros that I've developed, such as @SceneTree, #initSwiftExtension, and #texture2DLiteral. Additionally, I wrote some of the tutorials for getting started using DocC's built in tutorial system, which has been getting more updates thanks to the community. While de Icaza and I don't always agree on API design choices, it has been a pleasure to work with him and a group of passionate developers on making the marriage between Swift and Godot a reality. Our Slack workspace has been bustling as more developers join and get involved with SwiftGodot. Overall, I'm excited to see where SwiftGodot goes and couldn't be any happier.
[aʃaiʔaʃakasusate]1 (A new story)
While I liked the SpriteKit-based prototype as it existed, a few factors kept nagging at me. First, the story didn't really tie well into the puzzles I created, feeling disjointed and irrelevant. Furthermore, I struggled to design good puzzles using the Paintbrush system because there were little to no restrictions on how to draw a line. Finally, I didn't get as many downloads of the prototype as I hoped, and this led to many parts of the game being unchecked, such as the writing of the story. A quick conversation with Matthew VanDevander, the creator of Taiji, made this last point glaringly obvious.
At first, I tried to rewrite the existing story to better fit with the puzzles and provide much needed clarity. However, I soon realized that the game's design was limiting what I could do, and it would've been extremely difficult to make it work the way I wanted. So, I went back to the drawing board and reconsidered the game's design as a whole.
I sifted through my current notes, game design documents, etc., until I stumbled upon a set of bonus puzzles I planned out that utilized a conlang I made a while back, [ʔaʃaʃat]. Suddenly, I realized that I already created a system with its own rules and constraints: a language. Furthermore, a language can be tied into a story quite easily, because languages can be a part of people's identity. [ʔaʃaʃat] was the key to making Indexing Your Heart work.
I spent the next few months reworking the game alongside the codebase. Instead of drawing lines with Paintbrush, I created keyboards and number pads for entering words and numbers in. Additionally, I threw out the story in favor of a new one with just two characters, one of them being a native speaker of [ʔaʃaʃat]. I won't spoil too much of the story, but it's definitely pivoted from a romance story to one of self-discovery, reflection, and coming to terms with one's own identity.
A new code hub
I’ve been a GitHub user for as long as I’ve done software development. GitHub provides a lot out of the box, and I’ve had no particular issues with the service. However, with Indexing Your Heart, I’ve been slowly migrating everything over to GitLab (hosted at https://gitlab.com/Indexing-Your-Heart), which has helped streamline development to some degree thanks to better organization.
Having all of the tooling for the game in one place is great, except when that one place becomes unreliable or inevitably shuts down. GitHub hasn’t had this happen in a way that affects the game yet; however, I would prefer to have some redundancy in place to ensure the project remains alive. Thankfully, Git is decentralized by nature, so I can simply add another remote and push the code somewhere else. GitLab also makes it easy to mirror to a GitHub repository2, allowing me to have the game’s source code in both GitHub and GitLab. I have yet to set up all the repositories this way, but I am grateful I can have the game in as many places as I can.
With that said, I did run into some challenges with such a migration. While moving the source was trivial, I realized that GitLab’s CI tooling was lacking for what I needed, especially since I’m not a premium subscriber. Nonetheless, I turned to CircleCI to fulfill the role of my CI jobs, ranging from running unit tests on the game’s modules to building frameworks for testing. Some of my tests require running on an Apple Silicon Mac, though I should be able to re-enable these once CircleCI rolls out M1 runners to free users. Nonetheless, CircleCI’s system works well with GitLab, and I couldn’t be more pleased.
Finally, I’m looking forward to an upcoming GitLab feature: federated merge requests. Currently, if you wanted to make a merge request to the game’s source code, you need to make an account on GitLab.com and submit it there. However, some proposals and merge requests have been made to change this so that anyone can make a merge request in GitLab, regardless of where their account is. This will effectively use the same system that powers Mastodon, PixelFed, and others in the “fediverse”: ActivitiyPub. I’m excited to see this feature roll out, as it will make contributing to the game more accessible than ever before.
The next prototype
I hope to get a new version of the prototype with the new codebase out soon, ideally by mid-November. I've been continuing to make improvements as I test the game on physical devices to make sure it's decent enough for a public test like I had done prior. At the time of writing, I have a couple more things I'd like to implement before releasing it (such as save states), but I should be on track to get it in everyone's hands soon.
