Why GameDev
I spent four long and fulfilling years studying biomedical engineering with the aspirations of becoming either a researcher or doctor. However, as I reached the end of my program, I realized that there was something lacking from my career options in that field: the freedom to reliably make ideas into a reality. Most novel biomedical engineering ideas in the real world take decades to even have a chance of becoming a usable product that will help people. This is especially true in my field of interest at the time, tissue engineering. Many people spend their whole careers researching ideas that may never human use for decades more. While I respect the research in these field to no end, I can’t see myself in those shoes.
I want to have the ability to materialize my creativity. I want to be able to grow these seeds of creativity, whether they be mine of not, from sow to harvest. Thats what I enjoyed most about my engineering education, and it’s what I’ve found the most compelling about game development. I can have an idea for a game and have a functional prototype ready in days. I can help a team push out a game in years rather than decades. While these goals will never be as monumental as my old aspirations of vascularizing engineered tissues or figuring out how to grow cartilage, I’m okay with it. I would rather have a hand in making the games that people can enjoy. Whether they’re games for just me, or for the whole world, I can be sure that they’ll make life a bit better for someone.
BountyHeart
Over the 2021-2022 school year I had the privilege of working on BountyHeart as part of USC’s Advanced Game Projects as one of the engineers. It was my first truly multidisciplinary game project, with over 25 total students working on it. BountyHeart is mobile game that fuses match 3 combat with rogue-like progression. I knew this mashup had potential right from the pitch, and we were able to turn this concept into a game that I honestly love playing.
BountyHeart gave me a chance to be a lead in coding many components of the game. I was in charge of the tutorial, map, UI implementation, dialogue, and audio implementation. Through this work, I was able to see how to design these components so they work with each other and the other systems within our game. I was also got experience making the work on these systems delegable to others on the team through either clean coding and documentation and through tools that allow easy modifications to the systems without needing to touch the code.
Some of the most valuable experience I got from this project was working with the people who specialized in different parts of the game. As the lead for both UI and audio implementation, I worked with the art and audio teams pretty often. I learned how to efficiently take their vision of the game and recreate it in our game. Some tasks were an easy conversion of Figma mockups or sound clips and implementing them as is. Some of the more interactive features like the large match effects took a lot more back and forth, quickly testing what it would look like in game and getting their feedback on it. This cross discipline communication helped us get the game to a state where all the art and audio matches what our artists and sound designers wanted.
BountyHeart was also my first foray into officially publishing a game to mobile app stores. I was in charge of managing the build on both the IOS and Google Play stores. I got to know the publishing pipeline well as well as how to manage playtesting through each of these app stores. It always feels great to see your own game on an official app store and I’m glad I was part of the process getting it there.
BountyHeart was a great place to put my coding skills to practice and to get experience working with a multidisciplinary team. I truly am proud of what my team and I were able to accomplish with this game.
CycloHex
One of my strongest reasons to study GameDev is freedom. I view freedom as the ability to change on the world that I interact with; the idea of not being bound by “I wish I could do that”. As someone who plays a lot of games, I express much of my freedom through my control over games. I love being able to modify games and the ways that I play them. But most importantly, I love being able to take the concept of “I wish this game existed” and just make it exist, and thats exactly what CycloHex is.
Towards the beginning of the pandemic I played a lot of Clubhouse 51 Games with my friend remotely. It was a lot of fun, but we got really into the game Hex. We would play for hours and hours and it never really got stale. For such a simple game, there was a lot of strategy to unpack. One day I had the idea of having the game board loop like a PacMan level so a point on one side connects to the corresponding point on the opposing side. It was kind of hard to picture in my head, but after some discussion with my friend, we couldn’t decide whether it would actually be fun or not and it would be too hard to play it manually. After a few months of the idea rattling around in my mind, I decided that I had to make CycloHex a reality.
The goal was to make the game function with online networking so I could play with my friend despite the pandemic. I got the base game working within about a month and continued to add new features as the inspiration came to me. I got networking up and running with my own network protocol and a dedicated server running Fleck on an AWS EC2 instance. I created an AI with alpha-beta pruning and iterative deepening to create enough of a challenge to beat me every once in a while. I added some indicators to show what tiles are connected and what general direction to go in since the game can be pretty hectic at times. At some point, I realized that maybe this game could be more than just something to play with my friend.
With the ease of publishing from Unity, I decided that it might be good to publish on the IOS Store, Google Play Store, and Steam. After adding a tutorial to explain how the game works, I decided to tackle Steam first. It was quite an ordeal to get all of the necessary preparation for Steam. From figuring out how their command line depot system works to learning how to edit videos for the store page trailer, there was a lot to learn. However after a while of struggling, I got CycloHex on Steam (https://store.steampowered.com/app/1882950/CycloHex/).
CycloHex embodies what I love about GameDev. It exists because GameDev gives me so much freedom to make what I want in the way I want it.
Prime Engine Extensions
Though much of my game development experience is with C# and Unity, I do have strong experience working with C++ in custom game engines. Prime Engine is a low level component based 3D C++ game engine that I worked with. Working with Prime Engine gave me the chance to really explore how game engines work. I got to work with custom memory management and specialized data types that make use of it. I worked with the singleton-based event system to create and receive custom events. I was able to use Maya to create levels and used the custom Python-based tools to load them into the game. I was able to put my 3D math fundamentals into practice directly working with the engine’s representations of transformations and quaternions. All of this culminated in my two extensions of the engine: navigational meshes and mesh-sphere collision.
My NavMesh was used to allow efficient pathing of an object to a given position around moving obstacles. The shape of the NavMesh was created procedurally from the terrain mesh. I created an algorithm to evenly split the terrain mesh’s triangular faces until the largest edge was smaller than the obstacle’s radius. This lets me easily calculate which triangles are obstructed by the obstacles without overestimating too heavily. I used A* on the graph of triangle centers to make a general path to the target, and used a string-pulling algorithm to refine the path to be shorter. This allowed me to make the NavMesh shown in the video above.
The mesh-sphere collision I implemented was based on the penalty method of physics where forces were applied based on the amount of overlap between objects. The crux of this method was figuring out the amount and direction of overlap between a sphere and an arbitrary mesh. This was done by finding the displacement between the sphere and each relevant triangle of the mesh and summing them to get the overall reaction. From there, the proper reaction forces could be applied to properly simulate physics. This is demonstrated in the video above with multiple obstacles bouncing on the terrain mesh while the player character traverses the NavMesh.
Chroma Maze
I’ve always loved a good challenge, so when USC’s Global Game Jam 2021 came around, it was the perfect chance to really put my game dev experience to the test. We were given around 2 days to make a game on the theme “Lost and Found”. I decided to go solo and make a maze game to “find” a “lost” treasure and escape with it (maybe taking the prompt a bit too literally). With some inspiration from Shapezio’s color mixing and the effect of using old 3D glasses, I came up with the idea of the game shown above, Chroma Maze. The gist is that hitting crystals changes the color of the light in the room, rendering some walls of the maze traversable and changing the layout of the maze.
Two hard-fought days in the trenches of Unity got me to a playable prototype of my game, fully functional but a bit rough around the edges. I was able to cobble together some levels to make the demo playable and presented the game to everyone. People seemed to like the idea of the game and I was proud that I got it done in such a short time frame, but I was still a bit dissatisfied that I only had about 5 levels, and only 3 of them were much of a challenge.
About a month later, I came back to the game armed with my new knowledge from my algorithms class with the intent to make procedurally designed levels. I was able to translate each maze into one large graph, and find the shortest path to any location with some clever usage of BFS. This let me randomly generate levels and sort out the ones that are solvable. I was able to expand on this idea to make the level generation that I have in the game now, with multiple difficulties and “endless” replay-ability. After a bit more polish, I got the game to where it is now: a game that I would enjoy playing even if it wasn’t mine. I’m proud of what the game has become, and I’m excited to push the game even further to a mobile release someday.
RandImg
RandImg is an app that presents pictures in a random order, similarly to a screensaver. I ended up making RandImg because I have a second monitor and I like putting up pictures on it while I’m only using one screen. However, I was unsatisfied with the existing options. No image viewing apps that I found were able to both present images like a screensaver and search multiple folders. I make sure RandImg could handle both of these tasks and added in a few other features as well. RandImg can recursively search subdirectories, automatically cycle through images, and sort through images based on tags in the file names. While I do think there may be more people who could benefit from RandImg, I designed it primarily for my own use case.
RandImg is a testament to my ability to work through problems on my own. RandImg was made in the .NET Framework using C#. I had one class that taught a bit of .NET through Visual Basic and one class that taught game development through Unity with C#. Those are my only exposure to the environment used to code RandImg. Most of the knowledge used in making RandImg had to be self-taught while making the project. I had to immerse myself in the C# and .NET documentation for hours to figure out how to use it well, but I think the results speak for themselves. I was able to figure out everything I needed to know to make this app from hard work and the internet, and I know these skills will be crucial in any coding work in an unfamiliar environment.
RandImg can be found here: https://github.com/Aobatake1515/RandImg.
Custom Networking Protocol
One of my recent projects was devising a new application-layer network protocol. It uses UDP to transfer data between a server and clients with synced clocks. The motive behind this protocol was that many time-sensitive games need to have both sides of a connection know when actions are happening on the other side. This is why synced clocks are important and included in the protocol. The other main issue for time-sensitive games is that packet resending in TCP is very slow. UDP does not resend packets, but using it means that many useful features of TCP need to be re-implemented on top of UDP. The protocol I designed used a sliding window protocol similar to TCP, but does not stop for missing packets. This allows packets received out of order to be stored and re-ordered as long as they arrive before the receiver reads them. The protocol also uses a custom DFA to control the state of the connection, implements time-outs, and uses a custom protocol data unit to store data.
This protocol was used to network a very simple twin-stick shooter tech demo, shown above. In this implementation, the client sends inputs to the server and the server sends back the whole state of the game. The clients do implement some simple interpolation to smooth out the movement, but does not use any movement prediction. While this “game” is clearly lacking and unfinished, it does its purpose of showing the protocol in action. This protocol has a lot of potential and could definitely be used to network a more complete game.
This protocol implementation was written in C++. Winsock was used to handle the sockets and send packets. The Chili Framework was used to handle the graphics and inputs for the game (https://github.com/planetchili/chili_framework).
Engineering Background
While I am no longer studying biomedical engineering, much of what I learned will remain useful in game development. The most important trait that I’ll retain is my teamwork. I’ve worked on teams for much of my undergraduate work, including two biomedical design projects. In both projects, my team of 3-4 members worked together without any major issues. We were able to produce quality work that’s shown on my old website (aobatake1515.wixsite.com/website-1). One of these projects also had an industry client that we worked with, so I have experience communicating remotely with clients.
My engineering background also provides me with a solid understanding of physics. Even though my major was biomedical engineering, many of the topics I studied are from mechanical engineering. I have studied statics, mechanics, fluids, materials, and more. This makes me a great fit for any games that need to deal with accurate physics simulations or any other situation in which physics is used in a game.
The last main trait that will be useful is data analysis. I’ve had to analyze and visualize lots of data in my undergraduate program, and this experience will continue to help me understand data and convey it to others effectively.
Presentation Skills
When I began college, public presentations were one of my greatest weaknesses. I was always nervous and couldn’t recover from small mistakes. As I’ve practiced and performed presentations throughout my time in college, I have gotten much better at controlling by posture and speech and am improving on my ability to move past mistakes gracefully. Many of these improvements are from the help of peers and just from having more experience under my belt. I now feel comfortable and confident giving public presentations, which is a skill that will be relevant at some point for almost any life path.
The video shows my team’s presentation for the Capstone design project discussed above. I am on the camera’s right side. While this presentation wasn’t perfect, I think it shows my confidence in presenting well and demonstrated that I can move past a few minor slip-ups.
Get in Touch
21318 Kent Ave
Torrance, Los Angeles County 90503
USA
3106979547
aobatake1515.itch.io/