Danny Bui

Eldritch Appetite

The final game project that I worked on at Futuregames. The purpose of the final project was to create a game that was playable on mobile devices, which aside from controls that are different from the usual mouse and keyboard or controller, would have us put more emphasis on optimization to make it run smoothly on mobile devices. It was here where I used the knowledge I have learned up until this point to make the project go as smoothly as I could, cooperating with team members I hadn't worked with before.

• Read More

One More Dead Than The Other

The second game project of the education. This time the team was significantly larger, including additional programmers outside of our class, as well as artists. The game initially had a larger scope during the planning phase, but some of the planned content had to be cut from the project as advised by the teachers/mentors midway. This led to a number of my contributions not making it into the final product. Regardless, it was a good experience since it was the first time I got to work with artists during this project.

• Read More

Cloudbreaker

Cloudbreaker was the first group project I got to work on during my education at Futuregames. The project started right after our introductory course in Unity. This meant we had to learn game development as we went on with the project, including learning how to work together with other disciplines. In this case, we worked together with UX/game designers as well as project managers for the few weeks we worked on the project. Lots of lessons were learned from this project, from the realization of how fast a project can escalate, to how much effort it took to make everything work together. After this project, I started trying to structure code properly in order to prevent things from going out of hand, since by the end of it all, it got hard to make even the smallest changes.

• Read More

Gilded Depths

This project was done during Brackeys Game Jam with a very small team of two programmers and a sound designer with the theme being "Diving Deeper". While the other programmer handled the enemy AI and level design of the game, I was responsible for everything else in the project. Although they weren't very refined due to time constraints, I got to work on a lot of different areas during development, trying out new things in the process.

• Read More

Moving In

A network related project that was assigned to us by the school. This one was shorter than the others and we had little time to prepare for it. As such, the quality will seem to be significantly lower than the other projects I've worked on as we put a lot of focus on getting it to work over the network, which we had no prior experience working with beforehand. This was taken into account and was expected by the school.

• Read More

About Me

My name is Danny Bui. I'm a Unity C# developer studying at Futuregames. During my time in the education I've had the chance to try out and learn a wide variety of game development related skills, and am still striving to learn even more. I have a bit of a habit to make sure that I understand the things that I'm working on, since I like to work with intent instead of stumbling about on accident. This tends to lead to me trying to come up with my own solutions to problems, but I'm in no way opposed to using other solutions if needed.I've been a generalist while working on projects, being able to work on different areas if needed. That said, I've taken an interest in AI programming, aspiring to create lifelike characters in future projects. This is something I've been exploring during a bit of my free time while I'm not working on anything school related. I've experimented a little bit of each of FSM, BT and GOAP, as well as implementing pathfinding using A*. I would love to get more opportunities to learn more about methods used to create game AI.

Tools I Currently Use

• Unity
• Unreal Engine
• C#
• C++
• Blueprint
• HLSL
• Shader Graph
• Github
• Perforce
• Trello

Other Tools I Have Tried In The Past

• Python
• JavaScript
• Java
• Godot
• Pico-8
• Jira

I borrowed the code for procedually generating mazes provided by Holistic 3D's course for AI on Unity the Unity tutorial section. With that, I attempted to implement the A* algorithm into the maze on my own with just knowledge on how the algorithm functions so that it would find the path from start to finish based on the maze's layout. I also added visuals in order to track how it's finding it way through the maze.

This was a simple game I made as part of an assignment for us to make a game that's playable on a mobile device. It plays similar to a rhythm game, where you have to time the incoming circles with the squares in order to score points. If you miss the timing, the health goes down and goes up whenever you time correctly.

I tried to implement my own scenario while I followed Holistic 3D's tutorial on behavior trees. The simplicity of the structure for behavior trees made it easy to design the behavior of the AI that I'd like to use it in bigger projects in the future.

Another small game I made as part of an assignment, this time it was for a game design course instead. The gameplay is that the player will have to enter one of the doors that's open, indicated by whether the door is lit up or darkened. When the player enters a door, all adjacent doors will open or close depending on its previous state. When all doors are closed, the final door will open up where the player will win when they enter it.

I had also done touched upon shaders a little bit. I mostly did these things in HLSL, while also trying out Unity's shader graph in the process. I got to learn how to make different types of simple shaders, which was a pretty fun process on its own.

My first ever game project. I wanted to make a game in hopes that it would increase the chances of getting accepted to the education. With this, I took my time to learn the process of developing a game, although rudimentary, from the ground up. I got to learn what went into making a game and what parts were necessary in order to make something playable. In the end, it took me a couple months of working on and off in my free time after work, making everything in it aside from the sound.

• Arrow Left

Cloudbreaker

Contributions:
• Player Controls & Behavior
• AI Behavior
• Scene Management
• Camera Movement
• UI

Cloudbreaker was the first group project I got to work on during my education at Futuregames. The project started right after our introductory course in Unity. This meant we had to learn game development as we went on with the project, including learning how to work together with other disciplines. In this case, we worked together with UX/game designers as well as project managers for the few weeks we worked on the project. Lots of lessons were learned from this project, from the realization of how fast a project can escalate, to how much effort it took to make everything work together. After this project, I started trying to structure code properly in order to prevent things from going out of hand, since by the end of it all, it got hard to make even the smallest changes.

• itch.io

Player Controls

The player is able to move along the plane without the ability to jump. Additionally, they can roll with a brief moment of invincibility, as well as attack the enemies with regular attacks or an ultimate skill to wipe out nearby enemies. A hitbox is created whenever the player attacks and its size is changed depending on which attack they're performing in a combo, which they can perform just by clicking multiple times in a succession. In the video to the right, the hitboxes are visualized for debugging purposes. There's also a brief cooldown between the attacks in order to prevent the player from attacking too fast.

AI

Since the game needed enemies for the player to go up against, I took the liberty to write the behavior for the different enemies. I had made a few different patterns that could be used for different types of enemies, but we ended up with just having three different enemies, two of which are practically the same close range enemies with slightly different values from each other, while the last one attacks from a range.I wrote the code for the enemies as a state machine. Since it was my first game project, I wanted to quickly write the enemy behaviors in order to show the rest of the team if they were happy with how they worked. This lead to me make the code go through different methods within the same class, identifying which state it is in through an enum. I did it this way because I thought I would refactor the code and make it so that instead of using an enum and different methods to keep track of the states, I would have different classes as states, having the functionality of each state within each class instead. That never came to pass, and I soon realized how quickly the code devolved into a mess using the former method as the code for each enemy grew in scale. I had to learn it the hard way.The method of navigation for the enemies to find the player was done using the help of Unity's navigation mesh in order to let the enemies approach the player while getting around obstacles.

Camera Movement and Scene Management

The camera movement isn't anything complicated. The functionality for the camera was that it would follow the player from a fixed distance, where we could adjust the offset to what we feel is right for the game. Once the player has reached the requirement to clear the current level, the game would stop all movement for the player and all enemies while panning the camera slowly towards the exit to show the player where they should go to advance to the next level, and then back to the player again.As for the scene management, I wanted to make it the transition between the scenes smooth, but I stumbled upon some bug with the editor that prevented me from creating a fade to black effect on the screen whenever the game loads into a new level. This bug would persist until I restarted the editor, and I still do not know the cause of it to this day. So I settled with making it so the player would ascend upwards to a new level whenever they interacted with an exit.

UI

While I wasn't responsible for making the upgrade system for the game, I took it upon myself to create the upgrade screen for when the player finishes a level. The screen would fade slightly and then pop in a set of three cards that the player can choose from. Once selected, the upgrade UI would disappear and the player can proceed to the next level.There were supposed to be more upgrades to choose from to add some form variety between each playthrough, while randomizing which cards would be displayed on the screen. In the end, we only had three upgrades to choose from, so there's not much of a variety in the final product.

• Arrow Left

One More Dead Than The Other

Contributions:
• Camera Movement
• Puzzle Props
• Dialogue System
• Animations

The second game project of the education. This time the team was significantly larger, including additional programmers outside of our class, as well as artists. The game initially had a larger scope during the planning phase, but some of the planned content had to be cut from the project as advised by the teachers/mentors midway. This led to a number of my contributions not making it into the final product. Regardless, it was a good experience since it was the first time I got to work with artists during this project.

• itch.io

Camera Movement

Over the course of the project, I had to change the camera's functionality multiple times before we could settle with one that ended up in the final product. At first the camera was supposed to pan over several rooms when the game was planned to be a number of rooms in a row. Then it was decided to be four rooms in a square shape, so that the camera would have to rotate between the rooms while it's being in the middle. Lastly, we ended up with just the camera keeping track of one room while switching scenes when proceeding to the next one. For all of them, I wanted the camera movement to be smooth while also being able to keep track of both players at all times.

Dialogue System

Since at some point I ran out of work during the project, I tried to find work for myself so I had something to do. Although not particularly necessary, I went ahead and added a dialogue/subtitle system that could a bit more character to the game. These subtitles could be modified in order to trigger at specific points, such as after solving a puzzle or just automatically after a certain amount of time has passed. The subtitles themselves could also be modified so that the timing for each line could be different from one another. Overall I'm happy that I added it into the game, with my only complaint being that it was somewhat tedious changing the timing of each individual line when I wanted different timings, so there's still a lot of improvements that could be done in that regard.

Puzzle Props

As the game is a puzzle game, we had to create different props that the player could use to solve the puzzles. They were originally meant to be physics based puzzles, but even that premise was eventually scrapped and we settled with having the environment change based on animations. The props showcased here were among the props that I had worked on, but didn't make it in the final product.The wrecking ball was not made with any programming from my part. It was made using the joint components that are included in the Unity engine and I was able to replicate the swinging ball effect with its help.I did however work on the functionality of the moving platforms. The platforms were meant to move just like how a scale would when each of its platforms hold a certain amount of objects on either side. As I worked on it, I realized that moving platforms were not as easy to implement as they seemed on the surface, that is making the platforms move along with the objects on top so that they wouldn't jitter or otherwise behave in an unnatural way. I realized afterwards that the most consistent way of solving this problem was to set the platforms as the parents of the objects, that way the objects would move alongside the platforms without having to worry about gravity which could affect how the platforms behave.

• Arrow Left

Gilded Depths

Contributions:
• Player Movement
• Camera Movement
• Sonar System
• Shop System
• UI
• Sounds
• Editor Scripting

This project was done during Brackeys Game Jam with a very small team of two programmers and a sound designer with the theme being "Diving Deeper". While the other programmer handled the enemy AI and level design of the game, I was responsible for everything else in the project. Although they weren't very refined due to time constraints, I got to work on a lot of different areas during development, trying out new things in the process.

• itch.io

Player Controls

Since the game was planned to be an underwater exploration type of game, I wanted to make the challenge to be to control the submarine through the water with the hindered movement. In order to achieve this, I decided to make the game mouse only, letting the player control the submarine by holding left mouse button at a direction from the submarine and having it accelerate in that direction.Although the difficulty of moving through water with the submarine was intentional, it seems like I had overdone it and it would affect the experience for the players trying the game out. A little bit more tweaking was needed to make the game more enjoyable.

Sonar

I believe it's not uncommon for submarine gameplay to have some sort of sonar or radar in order to find items that are nearby. My take on it is for the submarine to create sonars to make hidden treasure visible and possible to pick up. To create the sonar effect, I created a simple rim shader to attach onto a sphere. The effect was as I had desired. As the circle/sphere expands, it checks for any type of collision with treasure chests nearby, activating the illuminating effect of the treasure chests as well as making it possible for the player to pick up.

Shop and Upgrades

At first I thought we would make it so the player could pick up upgrades during exploration, so I made them using prefabs that you could place around the level for the player to collect. These upgrades would upgrade the submarine depending on what type of upgrades they were set as. In order to reduce clutter in the inspector, I decided to try my hands on editor scripting so that the anyone editing the upgrades could adjust the values of variables without having to think about which ones are relevant for the type of upgrade they need. I made it in a way so that whenever you changed the enum, or type of upgrade it was, the editor would change to display only the relevant variables to change for the user in the inespector.But later on we would have a shop instead that the player could spend money on in order to upgrade the submarine, so the editor scripting ended up not being as relevant, and we could have gone for another approach instead.

• Arrow Left

Moving In

Contributions:
• Player Movement
• Player Interactions
• Network interactions

A network related project that was assigned to us by the school. This one was shorter than the others and we had little time to prepare for it. As such, the quality will seem to be significantly lower than the other projects I've worked on as we put a lot of focus on getting it to work over the network, which we had no prior experience working with beforehand. This was taken into account and was expected by the school.

Player Controls and Network Interactions Part 1

The game doesn't have any complicated movement. All the player does with their character is to move horizontally on a plane, and interact with furnitures in order to pick them up or put them down. Two players can interact with the same furniture simultaneously, making the furniture move between both of them. The problem was implementing this behavior to work over the network, while having to take latency into account.At first I had made the first version playable locally with two players simultaneously, which I would then turn into one playable over the network. It was then I realized that there were a number of limitations I had to take into account while working with the network solution I was using, which was Netcode for GameObjects (NGO).

Player Controls and Network Interactions Part 2

When making the controls work offline, my solution to the interactions between the player and furniture was to set the variables for their interactions to null whenever they stopped interacting with one another. NGO prevents you from doing that, setting network variables to null. So I had to come up with a workaround in order to emulate the same behavior to work through the network as I ran out of time before the deadline. The result was less than elegant and the code ended up being more convoluted than I had liked with all the RPC calls I had to do within the code.

• Arrow Left

Eldritch Appetite

Contributions:
• Item system
• Interactions between game elements
• AI
• UI
• Tools

The final game project that I worked on at Futuregames. The purpose of the final project was to create a game that was playable on mobile devices, which aside from controls that are different from the usual mouse and keyboard or controller, would have us put more emphasis on optimization to make it run smoothly on mobile devices. It was here where I used the knowledge I have learned up until this point to make the project go as smoothly as I could, cooperating with team members I hadn't worked with before.

• itch.io

Item System

The item system was a big part of the game, as it was required in order for a lot of the other components to function. The items needed to be spawned at certain intervals, while also making sure that the game wouldn't go too long without spawning the item that the player needs to complete their objective, which very well could happen.There were several different item types, so they all needed to be accounted for as well. We needed to make sure that new types of items would get unlocked as the player progressed through the game.All of this would also get tied to the UI, so that the player can keep track of their current objective. The game will randomly choose the item types and the amount of each type to demand from the player and show it on screen.

Interactions between game elements

While the item system was an important part of it all, I needed to make sure that components of the project would work properly with one another, as well as make it adaptable so that code from my team members could use them as easily as possible. Doing this, I made sure that it would work between the gameplay and the UI so that it could update with all the different objectives that the player could get, and at the same time made some room for things to happen visually as well. Which is how the flying items in the game came to be.

AI

I had worked on a number of different types of AI that could have been used in the game. In order to make them work, I had used the behavior tree model, which I got from the Holistic 3D behavior tree course. In the end, only one of them made it to the final product due to lack of art assets that could have been used for them.Of the ones that couldn't make it, one was meant to be a food item that would run away from the player if they got close. The second one was meant to be an animal that would move the items on the stage around. The last one of them was meant to be some sort of guard dog that would chase the player if they entered a certain area that they guarded.

UI

The UI was made to change depending on whether or not the cat god was on screen. It would be static with fixed positions while it was off screen, while being dynamic and following the cat god if it was off screen. It was also directly tied to the item system, where it would change immediately as the food items are delivered onto the god's plate.

Tools

There was an aspect of the project where we'd have to set spawn points for the items to spawn from. Setting them out with different at different sizes would not only be tedious without being able to see the radius would not only be tedious, but would also be prone to mistakes where the items could spawn outside of the play area.So I made sure that you could see the spawn areas in the editor so you could change them around without having to do that in play mode, which would also remove the changes made there as soon as you stopped it.