Want a less interactive experience? Scroll down
My passion is designing creative, interactive experiences using web and game technologies, while making the development experience as friendly as possible!
“Every good game has a fishing minigame.
But this game is a fishing megagame.”
Upcast Blue is a fishing metroidvania where all items are fish! You play as an unnamed protagonist whose father had never permitted them to leave the cove of an unexplored island. However, with their father no longer there, they decide to explore the island, learning more about their family and helping people on the island.
The game revolves around fishing and using your fish to solve puzzles in a metroidvania fashion. The game includes many systems, including an items system—which includes fishing, fish, and inventory management—interactable objects, achievements, and input action UI. It is also heavily stylized, with use of toon shading and postprocessing effects.
The game relies on diegetic UI for most UI except those required for accessibility. The inventory of fish is represented by a bucket in game. Your logs, the lore, and quests are all stored in a journal that you physically take out.
I directed and worked alongside ~7 programmers and tech artists to implement and optimize the game's systems and shaders. I also communicated with our other teams to meet the game's creative vision and to increase performance, and made sure systems were fun and accessible.
To simplify the game's systems logic, I created an archtecture for adding items, interactables, fish, and quests relying heavily on Unity ScriptableObjects, OOP principles, the subscriber pattern, and dependency injection.
I chose and worked with modern Unity technologies like Unity's new Input System, Universal Render Pipeline (URP), UI toolkit, terrain system, and navmeshes. I constructed surface shaders, postprocessing, and terrain shaders using ShaderLabs and ShaderGraph that matched our games lighting model using URP-style practices. Using UI Toolkit, I implemented styles designed on Figma to create menus, input indicators, and an animated notification system. For the input indicators, I designed a system to connect the new Input System with UI to accessibly and dynamically represent input actions based on context, that also served the purpose of disambiguating contexts with multiple possible inputs.
This was the first game I have created that was open world, and with it came the performance problems inherent to open world games. To fix these, I requested and implemented LOD models, added static batching, and implemented custom shaders with simplified lighting logic. In addition, I utilized Unity's profiling tools to narrow down and optimize slow systems, like fish AI, that bottlenecked performance. These optimizations increased build framerates from under 60 FPS to over 120.
We also decided to use a few tools I had not used prior. For sound, while it was likely a bit overkill, we used FMOD, and I learned to implement dynamic and random sounds with distance attenuation. We also used Unity's Timeline tool to play a cutscene, where we encounted errors since FMOD had no support for Unity's video player.
This prototype follows an unnamed protagonist as they traverse through the rooms of strangers by using their ability to teleport to whatever computer they are connected to. What makes this game unique is the medium: you interact either via a 3D isometric world or through the computer's terminal. When you interact with many objects in the game, it hides the window and opens a new terminal window that you can use to interact with the game world.
This game demonstrates basic Unity skills like lighting, shaders, pathfinding, scene management, multicamera rendering, and advanced input control. It uses URP and the new Input System. It also demonstrates my ability to architecture and implement modular Rust applications. The application shows general knowledge of operating system design as well, with an implementation of a filesystem and various GNU commands.
I decided to use interprocess communication (IPC) to make the two mediums interact. The Rust terminal client is spawned as a separate process to the Unity game, and they use TCP sockets to communicate. I also considered using pipes, but TCP seemed cleaner cross-platform (pipes on Windows are not my favorite!). The current format is to send C FFI structures across TCP as bytes and use a simple header system to determine message size. However, I am learning the hard way why you should not do that, and am considering switching to a preexisting format like BSON.
There is always more to learn with Rust, and I learned about how awful lifetime management is with mutable references. I initially designed the terminal client like I would a C++ program. However, since there are many interworking parts that need to simultaneously mutate state, I ran into problems shortly. Thus, I decided to use interior mutability using Cells.
Another minor thing I learned is effective scene management with Unity. The typical workflow for beginner scene management is one scene for the menu and one for the game. However, I decided to architect the game using additive scenes and a scene for each room. I also learned about and messed with Unity's area lights and light probes.
This game is also an excuse for me to get better with Blender.
This game is an endless runner made for ACM Studio's 2024 Studio Jam! The theme was "break the cycle", and we chose to break the cycle of trolley problems. I created most of the game within the first 48 hours, with the remaining time going to adding sound effects. The game uses Unity 6000 and makes heavy use of Cinemachine camera controls and audio.
The main skills I demonstrate are my ability to quickly prototype and create a clean game, demonstrating my proficiency with all aspects of Unity, from animations to camera controls, to UI (screenspace and worldspace). I ensured that UI was visible on all target aspect ratios and resizable when I could make it.
Scope is always an issue with game jams (and games...), so with this one we tried to keep it low scope while allowing ourselves flexibility. We scoped in active items that the player would actively use, but ended up scrapping them to polish other aspects of the game. In addition, we added things like extra sound effects and a cute death screen that were not in scope.
The game jam went really smoothly! The only problem was that WebGL does not support audio mixer effects (unfortunately 😔)
This is a minesweeper clone with support for custom board sizes, custom themes, a solver, and primitive support for scripted gamemodes using Lua. More importantly, it is a minesweeper clone made in C, SDL, and WinAPI, using SDL for windowing, rendering, and input, and WinAPI for resources and menus.
The main purpose of this minesweeper clone was to demonstrate my ability to write premade gameplay logic in a language that does not have advanced features like events, OOP, or containers (I only used arrays!). This project also demonstrates my ability to use low level frameworks like SDL and WinAPI to successfully implement a full game.
This minesweeper clone uses a manual but dynamic layout system (after trying Facebook's yoga and realizing it was overkill). I also demonstrate a minesweeper solver that treats the board as a system of equations (each number is the sum of its surrounding cells) using an RREF algorithm to find the solutions. While this algorithm is certainy slower than it could be with parallelization and other optimizations that a real math library would surely have, the point was to demonstrate my ability to write such an algorithm in C.
I developed a C coding style to organize structures similar to Vulkan's, where "methods" are defined on structures by passing them in as a pointer, and using the naming convention "Structure_Method". Using this coding style, I was able to translate C++ organizational structure (except OOP) into C. I also learned how to use menus in WinAPI using resources (which, unfortunately for my current linux-using self, made the application no longer cross platform). I also learned the structure of the embedded Lua scripting.
This is a Chess clone that uses RayLib and C, and currently includes all chess game logic and rendering logic for pieces and a move visualizer.
This shows my proficiency with C. It uses an object-oriented structure similar to the one I used for MineSweeper. It shows proficiency in OOP design and resource management.
It requires a small custom layout engine and complex logic for piece behavior. In addition, for assets I wrote a small python script to preprocess metadata for slicing and combine it with raw image data to embed PNGs into the application.
It was built to be modular, with the intent that the rules of the game could be easily extended or modified using Lua.
Website for the National Heritage Resource Center under the Center for World Languages at UCLA. The website has content for heritage language researchers, educators, and speakers. It serves many articles managed by an in-house CMS and also displays events from sister centers.
I optimized this website for SEO, accessibility, and devices. The website has the appropriate metadata, passes lighthouse accessibility tests which requires semantic HTML and appropriate sizing and attributes, and works at multiple viewprot sizes.
In this website, I prioritized user experience and interactivity. I designed the entire website on Figma beforehand, making use of its present feature to share the design with NHLRC directors. I did all designs with the user in mind, creating different UX pathways for each of the target audiences, notably visible on the home page. I tried to minimize difficulty in navigating the website, deciding to use a meganav and using breadcrumbs, subnavs, and table of contents when applicable. Unlike with CWL, I tried to use larger spacing and larger text to create a more obvious hierarchy.
To make the site more dynamic, I created an animation system using the IntersectionObserver API to create viewport-enter animations. I also tried using the BEM organization for CSS to create more organized components, which I still use when writing CSS.
Website for UCLA's Center for World Languages. Consists of a home page and various subpages serving event information and news articles, which uses an in-house CMS for content. I was responsible for the creation of the frontend from scratch using HTML, CSS, and JavaScript, and optimizing the website for mobile, SEO, and accessibility.
This was the first website I worked on under UCLA's International Institute. I started web dev using vanilla JS/HTML/CSS/PHP, but then started using frameworks that abstracted away most of the native browser code (eg. tailwind, react). CWL uses ASP WebForms and only CSS styling libraries. Thus, I had to get better with vanilla web tools, and used it as an opportunity to learn best practices with modern JavaScript, CSS, and HTML.
One of the more important things that I learned was accessibility standards. I learned how to structure HTML documents semanticaly to be read by a screen reader, and how to achieve many effects without the use of JS. I also did a lot of research into accessible typography, spacing, and colors.
Mobile support was very important for the website. I incorporated the relevant metadata and media queries in order to optimize for mobile.
I also learned about CSS features that had not been available from when I was a dev before. Some of the ones I particularly liked were CSS grids and variables, which I used extensively.
I also was tasked with making the website more SEO friendly, which required learning about HTML metadata tags and other metadata protocols like OpenGraph. I also here realized that generating content with client side JavaScript hurts SEO and decided to not rely on it.