Embedded Files
Techbrawlogy: Into The RoboDome
Techbrawlogy: Into The RoboDome
Techbrawlogy: Into the RoboDome is a multiplayer split-screen beat 'em up with cartoon-styled characters. Players can cooperate with their team to fight robots, charging up their super meters to perform powerful attacks.
Techbrawlogy: Into the RoboDome is a multiplayer split-screen beat 'em up with cartoon-styled characters. Players can cooperate with their team to fight robots, charging up their super meters to perform powerful attacks.
Featured here are screenshots from the game. You can see Dr. Faustus, the primary antagonist of the game and final boss, some of the other enemies players can fight, and the 3 playable characters (Orrek the Orc, Sylene the Elf, and Karmine the Fairy). I got an opportunity to code a fun boss fight for this game, and I enjoyed it greatly.
Featured here are screenshots from the game. You can see Dr. Faustus, the primary antagonist of the game and final boss, some of the other enemies players can fight, and the 3 playable characters (Orrek the Orc, Sylene the Elf, and Karmine the Fairy). I got an opportunity to code a fun boss fight for this game, and I enjoyed it greatly.
Dr. Faustus (Our final Boss) was a good opportunity for me to really get a lot of creative freedom in terms of actually implementing a Boss fight. I've had to program boss fights in the past, but tight deadline constraints have left very little time for actually making it a polished encounter for the player to experience. Techbrawlogy had a long enough production timeline that I finally got a chance to spread my wings and take my time in implementing a rewarding battle. I had a lot of one on ones with members of the Design team where I pitched specific ways of implementing attacks so that they matched the Design Document they had come up with, and frequently put forth ideas for ways of subtly improving the fight. Ultimately I am very satisfied with how the battle turned out. The music to it is great, the fight feels fair but challenging enough for the scale of the game, and in the end it turned out to result in the least amount of bugs in our entire project, making Quality Assurance for it very easy (Which is a plus for me because I was also our QA Lead).
Dr. Faustus (Our final Boss) was a good opportunity for me to really get a lot of creative freedom in terms of actually implementing a Boss fight. I've had to program boss fights in the past, but tight deadline constraints have left very little time for actually making it a polished encounter for the player to experience. Techbrawlogy had a long enough production timeline that I finally got a chance to spread my wings and take my time in implementing a rewarding battle. I had a lot of one on ones with members of the Design team where I pitched specific ways of implementing attacks so that they matched the Design Document they had come up with, and frequently put forth ideas for ways of subtly improving the fight. Ultimately I am very satisfied with how the battle turned out. The music to it is great, the fight feels fair but challenging enough for the scale of the game, and in the end it turned out to result in the least amount of bugs in our entire project, making Quality Assurance for it very easy (Which is a plus for me because I was also our QA Lead).
Outside of programming our final Boss, I was also tasked with the enemy AI's and spawning behaviours. We went through a few iterations for both of these. After scaling down some of our scope, we ended up with two standard enemy types; Clunks, which were our default cannon fodder style of enemy, and Goliaths, which is a combination between what would have been a weaker ranged enemy mixed with what would have been solely a larger Brute styled enemy type.
Outside of programming our final Boss, I was also tasked with the enemy AI's and spawning behaviours. We went through a few iterations for both of these. After scaling down some of our scope, we ended up with two standard enemy types; Clunks, which were our default cannon fodder style of enemy, and Goliaths, which is a combination between what would have been a weaker ranged enemy mixed with what would have been solely a larger Brute styled enemy type.
In the original design of the game, enemies would spawn a distance away from players, and stop once a specific local cap was reached (per player). This meant that grouping up would result in easier fights as the local cap would be reached for each of those players in parallel, and the grouped up players would only need to fight their local cap's worth of enemies at once. If players split up, then they would end up needing to take on their entire local cap of enemies on their own. However, portraying this mechanic to players was difficult, and because enemies would spawn randomly at the outskirts of the map, the first thing a team would do is split up. This ran counter to one of our primary pillars, which was Teamwork. So we reworked the spawning mechanics into more of a wave system. In the final product, enemies spawn in groups, the size of which increases as you progress through a round.
In the original design of the game, enemies would spawn a distance away from players, and stop once a specific local cap was reached (per player). This meant that grouping up would result in easier fights as the local cap would be reached for each of those players in parallel, and the grouped up players would only need to fight their local cap's worth of enemies at once. If players split up, then they would end up needing to take on their entire local cap of enemies on their own. However, portraying this mechanic to players was difficult, and because enemies would spawn randomly at the outskirts of the map, the first thing a team would do is split up. This ran counter to one of our primary pillars, which was Teamwork. So we reworked the spawning mechanics into more of a wave system. In the final product, enemies spawn in groups, the size of which increases as you progress through a round.
Enemy AI's and stats were heavily rebalanced in the final stage of the game as well. Clunks used to swarm players, immediately pathfinding into them at close quarters and instantly attacking. This became overbearing to a lot of players, and as such, we implemented an extra stage to their attack states. Instead of instantly attacking a player upon reaching them, Clunks would pause a short distance away, and form almost a ring around a specific player. Then they would walk forwards to attack. This gave players more breathing room to react, and slowed down the assault of attacks just enough to make a player feel awesome when they counterattacked themselves. Our other standard enemy type was the Goliath, which went through the most amount of changes in the project. Initially they were just another enemy type, they could spawn at a reduced rate alongside Clunks. But we found that they didn't really feel like an added threat. We ended up turning them into sort of a mini-boss instead. Now only one could spawn on the map at any given moment and there was a longer cooldown before another could be spawned after one was defeated. We drastically increased their health, and made their attacks hurt a lot more, so they would actually feel like a threat, and players would feel more inclined to actually team up to defeat them. When defeated, players would receive a generous XP reward for overcoming the challenge.
Enemy AI's and stats were heavily rebalanced in the final stage of the game as well. Clunks used to swarm players, immediately pathfinding into them at close quarters and instantly attacking. This became overbearing to a lot of players, and as such, we implemented an extra stage to their attack states. Instead of instantly attacking a player upon reaching them, Clunks would pause a short distance away, and form almost a ring around a specific player. Then they would walk forwards to attack. This gave players more breathing room to react, and slowed down the assault of attacks just enough to make a player feel awesome when they counterattacked themselves. Our other standard enemy type was the Goliath, which went through the most amount of changes in the project. Initially they were just another enemy type, they could spawn at a reduced rate alongside Clunks. But we found that they didn't really feel like an added threat. We ended up turning them into sort of a mini-boss instead. Now only one could spawn on the map at any given moment and there was a longer cooldown before another could be spawned after one was defeated. We drastically increased their health, and made their attacks hurt a lot more, so they would actually feel like a threat, and players would feel more inclined to actually team up to defeat them. When defeated, players would receive a generous XP reward for overcoming the challenge.
I also served in several other roles throughout the project. I worked as our Lead QA Tester, and was required in both replicating, and fixing any bugs found. Roughly one third of my logged hours on this project was spent solely on bug fixing alone. I did some UI and Menu programming. I had to pick up any odd tasks for Gameplay programming, such as implementing some attacks and attack combo mechanics. I briefly had to work with shader graphs to implement a HUE shift effect on a player's charged up super meter. I commonly was tasked with setting up animation controllers and animation events on many of our characters. I even voiced two of our characters; The final Boss, Dr. Faustus, and Orrek our playable Brawler character.
I also served in several other roles throughout the project. I worked as our Lead QA Tester, and was required in both replicating, and fixing any bugs found. Roughly one third of my logged hours on this project was spent solely on bug fixing alone. I did some UI and Menu programming. I had to pick up any odd tasks for Gameplay programming, such as implementing some attacks and attack combo mechanics. I briefly had to work with shader graphs to implement a HUE shift effect on a player's charged up super meter. I commonly was tasked with setting up animation controllers and animation events on many of our characters. I even voiced two of our characters; The final Boss, Dr. Faustus, and Orrek our playable Brawler character.
Ultimately, this was my favourite project to work on so far. It gave me a large host of opportunities to fill multiple different roles, which really gave me a feel for what I'm good at, and what I enjoy doing.
Ultimately, this was my favourite project to work on so far. It gave me a large host of opportunities to fill multiple different roles, which really gave me a feel for what I'm good at, and what I enjoy doing.
My work on this project:
My work on this project:
AI Programming
Audio Programming
Gameplay Programming
UI/Menu Programming
Quality Assurance
Voice Acting (Orrek, Dr. Faustus)
Puzzlegeist
Puzzlegeist
In Puzzlegeist, you play as Gray, the ghost of an eccentric junk collector who passed in his sleep. Gray is a lonely poltergeist who is bound to the room he died in. The game is a grid based puzzle game, in which the player must use their ghostly powers to possess different objects around the house, making use of their unique movement patterns and abilities in order to traverse throughout the building and escape. Ghost Hunters patrol throughout levels trying to catch the player.
In Puzzlegeist, you play as Gray, the ghost of an eccentric junk collector who passed in his sleep. Gray is a lonely poltergeist who is bound to the room he died in. The game is a grid based puzzle game, in which the player must use their ghostly powers to possess different objects around the house, making use of their unique movement patterns and abilities in order to traverse throughout the building and escape. Ghost Hunters patrol throughout levels trying to catch the player.
Puzzlegeist was a blast to work on. Out of the projects I have worked on, it overall felt like the most grounded and stable concept we came up with. I would love to return back to this project eventually one day, implement new levels, new objects, and overall turn it into a proper fully-fledged game instead of just a showcase piece. It definitely felt like it had the highest potential to become a proper and marketable game had things been taken further.
Puzzlegeist was a blast to work on. Out of the projects I have worked on, it overall felt like the most grounded and stable concept we came up with. I would love to return back to this project eventually one day, implement new levels, new objects, and overall turn it into a proper fully-fledged game instead of just a showcase piece. It definitely felt like it had the highest potential to become a proper and marketable game had things been taken further.
One of my funniest implementations from this project was actually the flashlight beams for the ghost hunters which are pictured below. Because we had designed the project using URP, it made rendering God-Rays difficult, so to replicate the effect, I implemented a special particle effect that renders overtop of the environment in order to replicate them.
One of my funniest implementations from this project was actually the flashlight beams for the ghost hunters which are pictured below. Because we had designed the project using URP, it made rendering God-Rays difficult, so to replicate the effect, I implemented a special particle effect that renders overtop of the environment in order to replicate them.
I was also tasked with implementing the AI for our Ghost Hunters; the Paranormalizers. As the game runs on a grid-based system, pathfinding was incredibly simplified. When a map is loaded, each Paranormalizer generates a 2d array of points they can walk through, and points they cannot from it. Each Paranormalizer has a scalable amount of points placed around the map that they patrol between. The game uses A* to determine the shortest path to each of these points, and that's the route that a Paranormalizer will move. However, each map is dynamic. Players are able to move objects around, which means that when an object is moved, it has the potential to change or block the route a Paranormalizer will take. If the path to a patrol point is blocked, then a Paranormalizer simply skips that point and continues on to the next. The hardest part to them came from pathing conflicts. Multiple Paranormalizers can appear on a map at the same time. Which means that there's a high likelihood that their routes will intersect with one another at some point. We couldn't just allow them to clip through one another, or worse, potentially enter a stalemate where neither moves because each of them is blocking a space that another wants to move into. So I implemented a system to accomodate for this. If Paranormalizers were to ever reach a point where their paths intersect and accidentally block one another, then the game holds a priority system. Whichever Paranormalizer is registered in a specific tile first, wins the duel. When Paranormalizer #1 wants to move into Paranormalizer #2's tile, and Paranormalizer #2 wants to move into Paranormalizer #1's tile, their AI's will realize this, and one of them will surrender. The one that surrenders will then treat that tile as fully blocked, and recalculate their path to their patrol point with the blocked tile in mind, which causes them to then follow a route around the other Paranormalizer they were intersecting routes with, and peacefully resolve their pathing conflicts. Thus you will see instances where one Paranormalizer will pause their patrol cycle momentarily when another one gets close in order to let them pass, or if that isn't possible, find another route around them.
I was also tasked with implementing the AI for our Ghost Hunters; the Paranormalizers. As the game runs on a grid-based system, pathfinding was incredibly simplified. When a map is loaded, each Paranormalizer generates a 2d array of points they can walk through, and points they cannot from it. Each Paranormalizer has a scalable amount of points placed around the map that they patrol between. The game uses A* to determine the shortest path to each of these points, and that's the route that a Paranormalizer will move. However, each map is dynamic. Players are able to move objects around, which means that when an object is moved, it has the potential to change or block the route a Paranormalizer will take. If the path to a patrol point is blocked, then a Paranormalizer simply skips that point and continues on to the next. The hardest part to them came from pathing conflicts. Multiple Paranormalizers can appear on a map at the same time. Which means that there's a high likelihood that their routes will intersect with one another at some point. We couldn't just allow them to clip through one another, or worse, potentially enter a stalemate where neither moves because each of them is blocking a space that another wants to move into. So I implemented a system to accomodate for this. If Paranormalizers were to ever reach a point where their paths intersect and accidentally block one another, then the game holds a priority system. Whichever Paranormalizer is registered in a specific tile first, wins the duel. When Paranormalizer #1 wants to move into Paranormalizer #2's tile, and Paranormalizer #2 wants to move into Paranormalizer #1's tile, their AI's will realize this, and one of them will surrender. The one that surrenders will then treat that tile as fully blocked, and recalculate their path to their patrol point with the blocked tile in mind, which causes them to then follow a route around the other Paranormalizer they were intersecting routes with, and peacefully resolve their pathing conflicts. Thus you will see instances where one Paranormalizer will pause their patrol cycle momentarily when another one gets close in order to let them pass, or if that isn't possible, find another route around them.
My work on this project:
My work on this project:
AI Programming
Gameplay Programming
UI Programming
Quality Assurance
Flashlight Beams
The Wild Return
The Wild Return
The Wild Return is a side scrolling platformer shoot 'em up, where the player takes control of a new sheriff in town, who must defeat Mad Dog McCoy and his bandit gang.
The Wild Return is a side scrolling platformer shoot 'em up, where the player takes control of a new sheriff in town, who must defeat Mad Dog McCoy and his bandit gang.
The Wild Return was a very small project in comparison to our later ones, merely being a 5 man project developed in our second year of University, however it introduced me to how much fun it can be to code enemy AI's and boss fights. The final boss, Mad Dog McCoy was implemented by me over a single night, and it was an absolute blast to surprise my coworkers with it the next morning.
The Wild Return was a very small project in comparison to our later ones, merely being a 5 man project developed in our second year of University, however it introduced me to how much fun it can be to code enemy AI's and boss fights. The final boss, Mad Dog McCoy was implemented by me over a single night, and it was an absolute blast to surprise my coworkers with it the next morning.
Mad Dog McCoy went through very minor tweaks during development. Initially, he had one giant healthpool. As his health got lower, his movement speed and attack delays would linearly get faster, up to a maximum of twice the original speed. This however quickly showed itself to be way too overbearing to normal players, and I had to quickly retweak him to a new system. In the final product, he has 3 health bars, each representing a stage. All three stages combined together has less overall health than he initially started off with. He starts off normal, then as you reach a new stage, he drops a health pickup for the player, he starts moving faster, and the music picks up in tempo. One of his attacks even ends up shooting more bullets as the fight progresses. He reaches his fastest and most lethal point in his final stage. This mimics the original design, but makes the fight a lot more lenient for players, allowing them to enter into Mad Dog McCoy's most deadly phase with full health due to health pickups, and ultimately means they have to face the speed ramp up less overall during the fight as the fight starts reaching its difficult speed values at a later point than prior.
Mad Dog McCoy went through very minor tweaks during development. Initially, he had one giant healthpool. As his health got lower, his movement speed and attack delays would linearly get faster, up to a maximum of twice the original speed. This however quickly showed itself to be way too overbearing to normal players, and I had to quickly retweak him to a new system. In the final product, he has 3 health bars, each representing a stage. All three stages combined together has less overall health than he initially started off with. He starts off normal, then as you reach a new stage, he drops a health pickup for the player, he starts moving faster, and the music picks up in tempo. One of his attacks even ends up shooting more bullets as the fight progresses. He reaches his fastest and most lethal point in his final stage. This mimics the original design, but makes the fight a lot more lenient for players, allowing them to enter into Mad Dog McCoy's most deadly phase with full health due to health pickups, and ultimately means they have to face the speed ramp up less overall during the fight as the fight starts reaching its difficult speed values at a later point than prior.
Aside from his death animation, Mad Dog McCoy actually didn't have any animations created for him. So I had to get creative with making him move. For himself and the other enemies, I set specific poses for them where they're both crouched and curled into a ball. To move around the arena, Mad Dog McCoy simply enters his curl pose, and then the rotation of his model is controlled through code to make it appear like he's doing a tactical roll forwards. The same sort of effect is replicated for when enemies aim at you, or when Mad Dog McCoy performs his attacks, they're all preset poses that the game-objects jump between.
Aside from his death animation, Mad Dog McCoy actually didn't have any animations created for him. So I had to get creative with making him move. For himself and the other enemies, I set specific poses for them where they're both crouched and curled into a ball. To move around the arena, Mad Dog McCoy simply enters his curl pose, and then the rotation of his model is controlled through code to make it appear like he's doing a tactical roll forwards. The same sort of effect is replicated for when enemies aim at you, or when Mad Dog McCoy performs his attacks, they're all preset poses that the game-objects jump between.
I was additionally able to reuse this same system for our playable sheriff character, who initially didn't have the ability to crouch at all, nor move while crouching for that matter. Which was very vital considering it would be impossible to dodge most attacks if you couldn't crouch.
I was additionally able to reuse this same system for our playable sheriff character, who initially didn't have the ability to crouch at all, nor move while crouching for that matter. Which was very vital considering it would be impossible to dodge most attacks if you couldn't crouch.
Reloading became a tough point of contention as well when we had some playtests. People found it annoying to manage reloading your weapon with everything going on onscreen all at once, and it felt slow and clunky much of the time as reloading would lock you out of being able to shoot again. We ended up reworking this by removing the need to press reload altogether. As soon as the player has spent ammunition, the game automatically tries to start reloading. Once a set amount of time has passed without the player shooting, fresh rounds will start being inserted into the players weapon one at a time with a short delay in between. The player can still shoot again at any time while their weapon is being reloaded, without any need to try and cancel their reload (assuming they still have ammunition left in their weapon left to shoot). This heavily smoothed out the flow of gameplay as players could now run in, take a few shots off at enemies, dodge away and recuperate a small amount, and their weapon would automatically be restocked as soon as physically possible without any kind of interruption to what they're doing.
Reloading became a tough point of contention as well when we had some playtests. People found it annoying to manage reloading your weapon with everything going on onscreen all at once, and it felt slow and clunky much of the time as reloading would lock you out of being able to shoot again. We ended up reworking this by removing the need to press reload altogether. As soon as the player has spent ammunition, the game automatically tries to start reloading. Once a set amount of time has passed without the player shooting, fresh rounds will start being inserted into the players weapon one at a time with a short delay in between. The player can still shoot again at any time while their weapon is being reloaded, without any need to try and cancel their reload (assuming they still have ammunition left in their weapon left to shoot). This heavily smoothed out the flow of gameplay as players could now run in, take a few shots off at enemies, dodge away and recuperate a small amount, and their weapon would automatically be restocked as soon as physically possible without any kind of interruption to what they're doing.
My work on this project:
My work on this project:
AI Programming
Gameplay Programming
UI Programming
Quality Assurance
Page updated
Google Sites
Report abuse