Making Touhou Fractured Transience

A 2D Platform Fighter with elements of the Shoot'em up genre. Wield the powers and abilities of characters from Touhou, hit your opponent as hard as possible and send them flying in a beautiful yet unhinged Battle of Bullets!

This is my first attempt to publish a full game. Given its reception of over 6 thousand likes on its reveal post on Twitter, 25k views on Youtube, and over 10k wishlists on Steam, I think it is safe to say that the game has beautiful aesthetics and high polish.

Project Info

Role: Programmer, Director/Producer, Lead animator
Team Size: More than 10 people
- 1 Programmer (me)
- 3 Animators (me included)
- 1 Illustrator
- ~10 Musicians
Time frame: 5 weeks (January 2000 - Present)
Tools: Unity, C#, Box2D (Unity), Cinemachine (Unity camera behavior plugin), Aseprite (Pixel art drawing tool), Unity GGPO (GGPO Rollback-netcode Framework ported to Unity), Game 2D Water Kit (Water Shader Asset),

Project Goal/Scope

A full game to be released on Steam with 7 characters and online matchmaking using GGPO Rollback-Netcode

Motivation

I love playing the Super Smash Brothers series as well as Touhou Project, so I decided to combine them. In Smash, the stages in which fights take place are huge, yet it stays true to being a "fighting game" and hence battles are still focused on close-ranged combat.

Colored Red: Unused space

It was from there that I wondered "What if there is a fighting game that focused on long-ranged combat instead?" and that's where the inspiration came from. Given Touhou's origins as a Bullet Hell game, its leniency with fan games, and each character having a unique ability for a wide variety of fighting styles, I saw a potential for a fun game and hence decided to embark on this long journey.

Leading a team

Due to the scope of the project, I decided to ask for help from fellow Touhou fans, by making a post on Twitter (now X). After this, I made a Discord group and communicated there.

For music, since this is a fangame, musicians just need to remix existing tracks than make entirely new ones, and Touhou certainly has quite an abundance of tracks to choose from.

Since there were so many people helping out, I basically let the musicians have free reign over what genre of music they could do, although I also provided a list of must-include track remixes as well as genre wishlists should they feel lost from analysis paralysis. I then compiled the pieces of music the musicians would like to remix and put them on a spreadsheet for reference.

I also appointed a music lead (or actually more accurately, someone volunteered themself) to manage the spreadsheet, take care of the metadata of the resulting album, and mastering of the tracks, due to their experience with managing music circles.

For animation, I set up a spreadsheet for animations to be done along with its brief instructions, although the main communication happens in Discord, and announcements of new assignments are made there. Still, the spreadsheet still proved useful since it provided easy access to previous animations for reference and potential reuse of frames.

Since there were also differences between our workflows for animation, I would sometimes make slides to illustrate how mine works and also engage in a few discussions on the best compromises for passing our workload.

Slides I made to provide tips on animating a character that was considerably more detailed than previous fighters

Setting up for Rollback-Netcode

Rollback-netcode is a networking technique for implementing online play usually for fighting games. It works by letting players play a version of the game with predicted input and re-simulate the game to adjust for wrong predictions if needed, providing the illusion of a zero-latency network.

The requirements of GGPO are listed as such:

Be able to save the current state of the game
Loading of a saved state
Deterministically execute the game without rendering its output

This meant that whichever variables could change needed to be recorded and saved, and the order of whichever scripts ran was very important to ensure determinism.

For storing data, I tackled it by creating a huge struct that has quite a variety of information stored such as its speed, position, collision points, and so on.

This unfortunately also meant that some objects held redundant information that it never used, and I should've probably looked towards principles like the Entity Component System for references to make the system more efficient. Regardless, performance doesn't seem to suffer from it yet even through testing on lower-end computers so I have decided to keep it as is.

As for ensuring determinism, the game first collects all relevant scripts involved in the Rollback process, which are then sorted based on their assigned order, after every update tick, it will run said collected scripts in their appropriate order.

As a bonus for ensuring the game is ready for rollback early, an input-based replay system was also possible early in development, as well as a frame-by-frame mode which also made debugging features to check for bugs in very slow motion possible.

The replay system in action depicts 2 players trying out the game for the first time, with the gameplay data collected from setting up a demo for the game at a Touhou convention