Interview: Zhakami Zhako, VRChat Aviation Indie Developer

There are only a couple of people whose work has made me reconsider what was possible in a game. One of these people would be Zhakami Zhako, an indie developer who basically redefined the way I looked at VRChat (VRC) world development. We had the chance to talk to him about his development endeavors in VRC, the systems he has developed and what his plans are for Project Fairy, the Yukikaze fan-game he has been developing in VRC for the past two years. How has he developed what can be summarized as a full-on desktop-compatible indie game inside of another game? Let's find out! First off, we’d like to thank you for accepting our interview request. Could you start by introducing yourself and telling us a bit about what you do? Hello. I’m Kim S., also known as “Zhakami Zhako”. I’m just a programmer with some odd… habits. I do programming stuff, as well as home door-to-door PC maintenance and Unity in my free time. What is your background as a software developer? Anything you would consider noteworthy? I’m a graduate of Bachelor of Science in Information Technology, and basically been with the industry for 4 years and counting. Currently I’m working with my second company and I’ve been developing Web-based apps (like React.JS, Vue.JS), API servers (involving Spring-boot, Node.JS), mobile apps that’s usually based on Javascript (AKA React-Native & Native-Script) and microcontroller related systems (like Arduino). I would probably say that the fact we’ve released two games (just very simple ones), built a wallet system, as well as a job finder app and a catalogue app which has been quite an achievement for me. How and when did you get into VRChat? Were you always interested in creating content for VRC or did something motivate you to do it? It was back then around 2020 when the COVID pandemic arrived and we were stuck at our homes doing nothing. Although I’m not that sociable, I always wanted to try out VRChat to try and meet new and all kinds of people. It was quite sluggish at first; trying to blend in, finding your first preferable avatar and like real life, trying to find your group. After a while, I met a couple of people (HolyKnightAD) who introduced me to Sacchan. At the time, Sacchan was working with his first few iterations of his flight System, SaccFlight. At first you can only fly arcade style with basic controls like Roll, Pitch, Yaw using the left and right analog sticks (Or WASD on desktop) and holding down Trigger (or shift) to control the throttle plus you didn’t have health nor gun damage. Even at the early state of the system at the time, it mesmerized me. I never thought that this kind of content creation was possible in VRChat; let alone programming something like this in VRC. After a while, a few friends (HolyKnightAD and Zweikaku, VRC World Creators) started making their own aircraft worlds. That made me think: ‘If I make my own aircraft world… It has to be a bit different.’ So I chose Yukikaze as a theme. I started researching how to get models, if there are free models, and how to extract things. It made me start learning how to use Autodesk 3ds Max, Blender, Unity, even hex editing just to get certain contents from the main game itself. Ever since then… I’ve been somewhat competitive but never properly released worlds. But here I am right now. You are quite the fan of Yukikaze, the sci-fi aviation book and anime series. How did you get into the series and what would you consider to be the best entry point for someone trying to get into it? Back then when I first encountered Yukikaze, it was just a random game that I found on the internet. I gave it a try and “holy crap, I love the Super Sylph”. Albeit the game felt rushed, there was something in me that kept telling myself “Man, the game feels rushed or unfinished. I wonder what if it had more.” I started to look for everything that’s related to the game. I saw that the anime actually exists; I’ve watched it for the action scenes (since I was a kid back then) but there were some things that I couldn’t understand. It would depend on one’s preferences. Starting from the anime then to the books has some sort of a different impact compared to reading the books then watching the anime. I’m pretty sure some people who have read the books then finding out that an anime of it exists definitely would make people feel excited about it and try to expect things like what happened on the book to be in the anime. Whereas watching the anime first, then reading the book would give you a different approach like... finding out why this happened in detail, what happened further in detail and what were the thoughts of each character when this and that happened... as well as being surprised when the anime had a different interpretation and delivering a different outcome compared to the book. Personally, I have a different impression since the order for me was playing the game first, watching the anime, then reading the books. I had zero idea of what Yukikaze was all about, zero knowledge of Japanese (since the game was 100% in the Japanese language) and used context clues in order to interpret what was happening around the game. Then I watched the anime and understanding what was happening, and ‘extending’ further on what happened after the last mission of the game, then reading the book to see more in depth details of what exactly is happening inside the crazy world of Faery. It even surprised me that the DACT mission of the game between the player and the Fand-II had further interesting scenes that happened in the book, and never was shown in both the anime and the game. As well as what happened to the “Public Information” mission where Fukai and Randy got themselves into a different dimension of a JAM area, (*spoiler alert, Randy lost his arm*) (P.S. I don’t find the interaction between Maj. James Bukhar and Lt. Fukai as gay when i first watched the anime as to how others interpreted it. I find them as buddies taking too much care of each other) I would probably like to talk about the canceled missions of the original game at some point. There were some interesting findings on unused content, unused audio files and the mission titles that I’ve found; especially “FRX99 DACT”,“ASAT”, “In Earth Air”, “Scramble”, “Operation Omega”. Your flagship project right now is Project Fairy, a Yukikaze fan-game inside of VRC. How did this project start and for how long have you been developing it? It started back in 2020 when I was developing the AI’s and the Trigger system in Project Fairy and as I went along, I kept re-watching the series again as I worked with VRC World development. When I began this project, I only wanted to create a world that has planes and free flight. But as I’ve progressed further and the more I ‘wanted’ more things in it, certain questions came popping in left and right. Like “what if I make users experience what the people in Fairy experienced when fighting the JAM?” and “can I recreate scenes from the anime?”
I began by making a world that has a dialogue system (aka the trigger system) and the AI’s, which is the current public world called "Fairy Air Force" . Albeit that I’ve released it, it felt like I’ve rushed it, or rather... it felt too janky. Sure, the idea was to play cooperatively by spawning AI’s around and fighting an ‘enemy’ Banshee, however... people did not seem to appreciate it at the time. And ever since then, I haven’t updated it for almost a year. Synchronization sucked at the time, networking was too janky, and it felt too heavy on performance. When that happened, I changed my perspective. I wanted to make it into a single player world. The plan back then was to make it a concept world, rather than a “first episode”. Despite being a concept world, I wanted to give it my all. I began imagining the hangar of the SAF. Lights turning on and making a dramatic entry; as based on how the anime depicted it. Then I began looking into the concept art of the anime, the concept art of the SAF underground hangar... then began modeling and texturing the hangar. Personally, I don’t have skills when it comes to modeling. I’m still learning. UI elements such as the HUD, indicators and other things were made from scratch with a mix of Photoshop and Blender. The hangar at first was meant to be some sort of a hangout or sightseeing place at first, since I did not know what to do with it. Or rather, I did not have the rest of the systems to make it work or the skills to detail things further especially the elevator. Until magically, Sagi-chan (VRChat aviation focused aircraft modeler) appeared out of nowhere, asked me for the concept art papers and ultimately gave me a very detailed hangar elevator. I’ve taken clips from the anime, mix and matched and improved the trigger system for the dialogue and extended it further. And that’s how I’ve managed to create the scene of the intro. As I progressed on this… I’ve been writing scenarios, dialogues and story for Project Fairy. This has been in development since late 2020. I have big plans for Project Fairy, but that’s not limited only for Yukikaze related content, but for SaccFlight in general as well. What is your current scope for Project Fairy? Currently, there are two missions that are being worked on. But we’ve somehow written some other missions based on the novels and the anime. Actively developed is the prologue, which is more or less a ‘feel’ of the game, then the next episode which is based on the first episode of the anime but with a mix of the interpretation of the first book. Some of the episodes that are already written are based on the first encounter of the gray sylph, the first encounter with Col. Guneau and his ‘Knights’, the canyon chase with the gray sylph, Banshee 4 examination, as well as flying with the POV of other pilots. Personally, I’m more excited about recreating the canyon chase scene in the anime. The writing is in the works, but development hasn’t started yet. The way each episode would be handled would be per world. (e.g. 1 world = 1 episode). Having multiple episodes with each world may be possible, but it can weigh down a lot in terms of world size (megabytes) and performance hits (the amount of scripts!) Aside from Project Fairy, you have developed several sub-systems for SaccFlight and Unity. Could you tell us a bit about some of these systems?
There were a couple of phases before I managed to make subsystems for SaccFlight, namely the arcade SaccFlight and then the new SaccFlight phase. During the early days, there were no afterburners. I had to make an afterburner module where you had to double tap your trigger (or shift) in order to enable the afterburner. HUD’s were too simple back then; I wanted to make a working HUD based on my own system. I made my own HUD system. And the thing I was most proud of during that time was the missile system. I managed to make a simple target selection, lock on, fire missiles and fire flares for countermeasures. However, this was only made available in the Fairy Air Force world during the early days of SaccFlight, as it was too customized to transfer to the prefab SaccFlight system. However, to this date, I still use the same missile / weapons system that I’ve made from the early days, only then with some improvements. Old system aside, I’ve been sharing the gauges-controller that I’ve tailored for Project Fairy to the developer friends I am closest with. It’s a simple controller that translates whatever the situation of your aircraft into animation parameters and values in order for you to use, customize and apply on each of your aircraft. Basically you just input the minimum / maximum value of your gauges on each gauge type, animate the gauge according to the min/max value, and call it a day. It’s very simple to the point that most of my friends are using it now. It covers the ADI, Fuel, Speed, AOA, Altimeters, Radar Altimeter, Pull up indicators, G’s, Mach and other things. Basically if you have a model that has these kinds of gauges, you wouldn’t need to dig through programming just to make it work! AI Systems are also made. Project Fairy wouldn’t even be a solid project without the AI’s. AI scopes from stationary, to ground moving, to aircraft units. They’re very customizable to the point where you can set waypoints, set targets whether who and who not to attack, attack range, the number of weapons that it can have (like turrets, missiles, guns), the speed, flight characteristics (for the fighters!), the amount of missile salvos per minute (yes.), the time to to change between targets, as well as formation characteristics. Aside from fighter aircraft configurations, naval vessels are also possible, as well as airships. Adding multiple turrets on each AI object is also possible. A Damage System is also available. It is a little nitpicky when setting it up, however you will need to set up these fine details in order to achieve a working damage system. Basically you can have burning individual engines (up to 2 at the moment), losing wings (left and right!), and even control surfaces (flaps, ailerons, elevators, canards, etc.) Another system that I’ve made tailored specifically for Project Fairy is the dialogue system. It’s essentially one of the core components of Project Fairy in order to achieve the story mode. But, despite designing the dialogue system, I do not know how other games (like Call of Duty, Halo or Ace Combat) actually achieve their dialogue systems or event systems. It is very, very customizable and dynamic in a sense that you can call an event if an AI gets destroyed, you cross an objective, a condition is met, and other neat things to achieve a scripted event. And lastly, one of my proudest achievements so far is the system that may blow other creators' minds. A floating origin shifter system. I call it Open World Movement Logic (OWML) . It’s a system that basically allows us to move further than the 40km boundary of VRChat (or perhaps Unity itself), all the way to… whatever you can imagine. Your only limit is your imagination, and ironically… Optimization . And since we’ve broken that limit… We’ve also developed a navigation system that’s just a simple TACAN navigation system. Example 02 - Example 03 The biggest and most impressive of the features that you have developed so far is the Open World Movement Logic (OWML) script for Unity. It solves some of Unity’s inherent issues with floating point precision calculations in large maps. Could you tell us a bit about how it works and what went into making it? Basically OWML works in a way or form on how origin point shifting works in theory. If you travel a specific threshold away from the center of the world space, it moves the “map” according to the area or coordinates you’ve traveled, then teleports you back to the center of the world space; thus avoiding further floating point precision errors. As this is tailored for SaccFlight, the way OWML works whenever you enter a chunk will call a synchronization fix in order to make other players synchronize seamlessly (and happens locally). OWML is not only limited for the aircrafts, it’s also tailored for the players. As you travel on foot (or SaccFlight avatar fly), it will move the map accordingly as well once you’ve entered a chunk. In order to synchronize players, we use a method where we ‘fake’ sit a player on a seat (which is called stations), but as the other player is moving around, their position also updates accordingly; thus even if you’re somewhere on the center of the world space, for the other player’s view you will be where you are supposed to be. Other games like Kerbal Space Program (I’m assuming) use a form of origin point shifting , but the execution may be a bit different. The early version of OWML that is currently in Project Fairy works in a way that it moves the world *all the time*. It activates once you’ve crossed the first waypoint or once you’ve used one of the scene selectors. The current version that’s stable and synchronizes with all the players moves the map according to the threshold. The reason that I’ve come up with the threshold instead of moving it the whole time is due to a synchronization problem with Sacchan’s Synchronization method between players, that might affect the flight physics plus the amount of extern calls (and function calls ) when you enter a chunk. However, this threshold can be customized as you set it up on your instance. In all honesty, It was only an idea that I’ve come up with, and never found out that it was actually a method or an application to a theory. Will you release the OWML script as a public prefab for Unity? If so, what are your plans for its distribution? At some point in time I will definitely release it as an extension for SaccFlight since this is tailored specifically for VRChat, VRChat’s Networking and SaccFlight itself. A general purpose use for Unity itself can be made however with some changes but the same methods can be used. There may be other systems out there in the unity store for all I know that use origin point shifting, but I barely have surfed through the asset store or other systems in unity to know. Since you are using SaccFlight for Project Fairy, will you be using all of the subsystems that you have developed to further improve the project? Definitely. Some of them will be shared publicly. As for the others, people may need to contact me as it may need further setup as most of the subsystems are tailored for my needs in Project Fairy. Why did you decide to make Project Fairy in VRChat instead of a standalone project? One reason would probably be for people’s accessibility. VRChat is free, the worlds can be publicly accessed by everyone whoever has VRChat. Another probably the built in functionalities of VRChat, like its VR Engine itself (albeit it’s still basic Unity VR, it’s already good enough). A running standalone project would be much more preferable for most people but I would say it’s like the ‘testing grounds’. If it’s a successful project, we can convert everything into a standalone project as is; as VRC is running on UdonSharp, which is a scripting engine that also uses Unity’s C#. Whenever Project Fairy reaches completion, how will people be able to access it? It will also be free to access, correct? Of course! As long as it’s in VRChat and as long as VRChat is alive. Unless, admittedly ambitious; if I am permitted to sell such a game. But that’s just wishful thinking for now. Again, this is a hobby project; I do this in my free time. About the Interviewer Santiago "Cubeboy" Cuberos Longtime aviation fanatic with particular preference towards military aviation and its history. Said interests date back to the early 2000's leading into his livelong dive into civil and combat flight simulators. He has been involved in a few communities but only started being active around the mid 2010's. Joined as a Spanish to English translator in 2017, he has been active as a writer and the co-founder of Skyward ever since. Twitter | Discord : Cubeboy #9034