About
I'm Sakura Shih.
I'm available to hire for freelance work, and I am also open to full-time positions at professional games studios, or tech companies.
I'm a Software Engineer with a focus on game development, with interests in Tools, Engine, and Gameplay programming. I've been a long-term gamer, and have been passionate about contributing towards game projects since my time as a modder.
​
My various interests within Computer Science encompass the following:
- Parallel Programming
- Graphics Card Architecture
- Low Level Systems
- Game Engine Design and Architecture
- Gameplay Programming
- Graphics Programming
- Game AI Programming
- Tools Programming
- Netcode Programming
​
Contact
Somehow
Game Developer
November 2024 - Present
Somehow is a multiplayer class-based first person shooter in Unity 6.0. With this project, I aim to familiarize myself with Unity 3D workflows, multiplayer/netcode, and design and program a class-based first person shooter, inspired by games such as Team Fortress 2, alternative music, and my love for magical girl anime.
Goosthetic
Tools Programmer / Gameplay Programmer
August 2024 - October 2024
Goosthetic is my first major project in a commercial game engine. Goosthetic is a 3D first person shooter in Unreal Engine 5.2. Within this project, my goals were to gain experience working in a large-scale, cross-discipline team, to investigate Tools Programming as a possible career option, and to investigate applications of data within games.
​
​
I was on-boarded onto this project to provide telemetry support for the designers conducting user research. To design my telemetry system, I used Unreal's event-driven architecture in order to decouple the telemetry system from the rest of the systems that the gameplay, UI, and environment teams had been designing.
I applied the data from this telemetry system to aid designers with user research efforts. With the data I generated, designers could make informed decisions on level design, and encounter design. Additionally, this data was repurposed for the leaderboard systems. For the leaderboard, I implemented code that interfaced with the Steamworks API to grab scores from players' friends lists, as well as saving their data onto a leaderboard system on Steam's servers.
​
Additional development support I've provided on this project include fixing the build to integrate Unreal C++ support.
Friday Engine
Graphics / Engine Programmer
April 2024 - Present
The Friday Engine is a custom 3D Game Engine Project, hosted on my GitHub. The goals of this project were to teach myself the low-level systems behind graphics programming, Vulkan, and game engine design philosophy.
Within this project, I've explored low-level memory management techniques, unit testing, build automation, and 3D rendering within Vulkan. I plan to continue development on this project, with more focus on low-level systems work, further investigating multithreading within game engines, game engine data structures (octets, binary space partitioning, etc.), graphics card architecture, cache optimizations and in-engine tools (level design tools).
​
HexenHold
Engine Programmer / Tools Programmer / Gameplay Programmer
August 2023 - August 2024
HexenHold was my first cross discipline project. On this project, my goals were to build a flexible, fast, decoupled, and lightweight custom game engine in C++, and to build a toolset that would enable designers to quickly add new content to the game.
​
The designers on our team had envisioned a massive scale 2D Tower Defense Platformer. They envisioned hundreds of enemies on screen at once, and wanted to have extreme flexibility when it came to adding content into the engine. We were to also implement tilemap support for Tiled in our game engine, so that designers could focus on using an external tool to quickly generate content for the game while programmers built the game engine. As a result, I chose to adopt a heavily event-driven Entity Component System game engine, with a heavy focus on serialization.
​
For the event system, I adopted the curiously recurring template pattern (CRTP), and used the Publisher-Subscriber model, and subscribed relevant classes through inheritance. This allowed for both the engine systems and gameplay systems to call events, allowed for decoupled code, which prevented later technical debt.
We chose an ECS because it would minimize cache misses, which caused performance hits. We also decided to keep struct sizes and class sizes small, to prevent the CPU from having to look into slower caches or even RAM. I decided to have each system store a vector of each Component the system was supposed to act on, rather than have each entity contain pointers to its components. We eventually designated each Entity as being a hash map that, when presented with a string key that represented each component, would return an index to its relevant component within the relevant system's vector.
​
We focused on heavily serialized architecture within our game engine, because we wanted designers to be able to plug and play content, and to have a flexible toolset built into our game engine. We adopted JSON for this reason. Serialization was a concept that every programmer on the team grappled with for different systems. I worked on building a UI editor with imgui, and provided support for multi scene loading, to allow designers to build UI elements in a separate scene that would then be additively loaded on top of the current scene. I also provided development support to other programmers who built particle effect editors, wave editors (for designing enemy waves) and animation editors.
​
In the spring semester, the game engine was finished, so my role pivoted towards gameplay, optimizations, and designer support.
For gameplay, I implemented a raycast algorithm for a line of sight check, to prevent turrets from attempting to shoot enemies through walls. This tested my skills in linear algebra e.g dot products and line-line intersection. I also focused on refactoring our scripts and clearing tech debt, such as refactoring our player controller from a 4000-line file into a smaller finite state machine, to fix bugs with animations and to better document the code. Additionally, I implemented dialogue rendering within the game, taking lines from a JSON file filled with lines written by our narrative designer, and putting them in a textbox next to the necromancer.
For optimizations, I focused on optimizing physics, my raycast algorithm, and speeding up look-up operations. One of our look up operations was searching for a specific entity in a vector of entities, and iterating through the entire array each time, causing an O(n) lookup operation. I switched it out for an unordered map (hashmap), where the key was the entity name, as hashmaps allow for quick iteration through the container, while also keeping the lookup operation to O(1) time complexity. I further optimized the raycast algorithm by preventing the raycast algorithm from looking outside of its relevant quadrants in the tilemap for each line of sight check. For further optimizations of physics, I focused on speeding up collisions, adding early exit access points within collision checks to abruptly end each collision check when certain conditions weren't met. I also attempted sending the physics collision checks to a separate thread, however this caused animation errors.
The Rolling Dead
Producer / Gameplay Programmer
January 2024 - April 2024
The Rolling Dead was my first major game project. I was the producer and a gameplay programmer on a team of 5 programmers. This game was a top down shooter, with the novel mechanic being that the player could only move through recoil from shooting.
​
In this project, I investigated coding core gameplay mechanics, as well as learning core object-oriented programming concepts.
​
​
The player controller was my main responsibility in this project. I focused on creating the core gameplay systems around firing weapons, as well as the unique movement system we had made. This involved lots of linear algebra, as our movement focused heavily around scaling, normalizing vectors, and applying forces based on those vectors. This project taught me the importance of Single Responsibility Principle, as the codebase for this project became tightly coupled, causing a lot of bugs.
A secondary responsibility I had on this project was focusing on coding enemy AI behaviors. At this time, I hadn't learned about AI programming techniques such as pathfinding algorithms, or behavior trees, so I implemented a naive implementation of AI behavior utilizing Finite State Machines and lots of linear algebra. My coworker, Eli Tsereteli, collaborated on this section of the project with me, and we created unique attacks and enemy variants.
Additional Media
Some more media of things I've done!
