Ronin LeDonne
Game Programmer
Degree Objectives
Bachelor of Science in Game Programming
1. Implement multiple completed games, including 3D games, using common tools, languages, and software for web,
console, PC, or mobile platforms.
2. Design, develop, and implement the architecture and infrastructure needed to support a complete game project.
3. Implement and analyze fundamental data structures and algorithms associated with game applications supporting
gameplay mechanics.
4. Use software development processes to analyze a project problem, and to design, build, and test a corresponding software
solution.
5. Demonstrate development skills using multiple programming languages, development environments, and platforms,
including advanced and/or experimental topics in game programming.
6. Establish collaboration, mentorship, and professional leadership skills by working with other disciplines to deliver highly
polished and completed projects.
​
Objective 1
Implement multiple completed games, including 3D games, using common tools, languages, and software for web, console, PC, or mobile platforms.
Boom Jump
GPE205
Boom Jump is an FPS platformer game created as the final for GPE205. In this game, you use a rocket launcher in order to jump around while also using it as a weapon to destroy turrets. The main goal of the game was to survive and make it to a green goal at the end of a level in order to proceed to the next level.
​
Boom Jump was created in Unity using C#.
​
Ricoshot
GPE104
Ricoshot is an FPS wave shooter created for GPE104. It's a game in which you have a weapon, but the only way to damage enemies is to indirectly shoot them by ricochetting it off of a ball that you also shoot. It's a game about skillful aiming and planning as enemies will try to rush into you in order to damage and kill you.
​
This game was created using Unreal Engine with Blueprint scripting.
Objective 2
Design, develop, and implement the architecture and infrastructure needed to support a complete game project.
Maze Mania
GPE230
Maze Mania is a 3D platformer that was created for GPE230 using Unreal Engine. The project utilizes C++ for scripting.
​
The game includes a main menu. This main menu has multiple items for navigating to the options menu, the level selection menu, exiting the game, and beginning the game. Player options are saved using Unreal Engine's SaveGame classes.
​
The game contains a level select menu which contains 3 levels, but these buttons will be made non-functional and graphically disabled if the player has not completed the level that it has. Player progress is also saved.
​
During gameplay, players can choose to go back to the main menu or reset. If player were to die, then they lose a life and can choose to respawn or go back to the main menu. If they succeed, they can proceed to the next level
​
Stand Your Ground
GPE340
Stand Your Ground is a top-down wave shooter created for GPE340. This project was created in Unity with C#.
​
It features a fully functional main menu with a start game, options menu, credits, and exit application button. During the gameplay functionality, the game features a pause menu in which the player can choose to go back to the main menu, resume gameplay, or edit settings.​
​
The game was designed with a Singleton game manager. This game manager's job is to monitor the game state and provide a smooth way to transition multiple states as orderly as possible as to ensure no two game-states come into contact with one another without express intent from the programmers.
​
The only states that were allowed to overlap is the Pause state and the Gameplay states.
Jumper
GPE104
Jumper is a 3D platformer game in which the player must rocket jump around in order to reach a goal. This game was created for GPE104 in Unreal Engine using the blueprint scripting language.
​​​
The game features a main menu with an options menu, start game button, level select menu, and exit application button.
​​
The game features Saving and Loading settings and the further completed level. The Level Select will take the furthest completed level and enable the corresponding button in the level select menu.
​
The game provides a pause menu in the middle of gameplay, which can resume or exit to the main menu. The gameplay also pauses for this.
Objective 3
Implement and analyze fundamental data structures and algorithms associated with game applications supporting gameplay mechanics.
Stand Your Ground
GPE340
Stand Your Ground is a top-down wave shooter created for GPE340. This project was created in Unity with C#.
​
This project features a drop system in which items in a list are given a weight value in order to affect the likely hood of being dropped when an enemy is killed. How this works is that in the script "DeathDropItem" there are two functions, and a list related to the selection process.
​
The list is the drop table that will contain the list of game objects that can drop along with the weight each item has.
​
The first one "BuildCDA" iterates through the list in order to obtain the total weights of the items involved and to assign a range for each drop. The second one "GetRandomItem" selects the random item. The chance for the item is based on its weight and the higher the weight, the more likely for it to be selected
The player can then use these drops to either dynamically change their weapon during gameplay or to heal depending on the drop. The drop system also supports having a chance to drop nothing based on its weighted value.
UATANKS
GPE205
UATanks is a top-down, shoot em' up game created for GPE205. It was developed in Unity using C#.
​
The game features random map generation in a customizable grid. The grid can be customized on two axis and can be as long or wide as the game engine will allow. The random generation can also be seeded to get a consistent generation layout if needed.
​
Once the prefabs for the rooms are given, the script will generate a room at a custom point at certain intervals in order to cleanly connect all parts. The map generation also features doors on each prefab that will be opened or closed depending on whether the prefab generated is on the edge or not. If it is, then it will close the door relating to the position. If it's on bottom row, then it will leave the bottom door closed while keeping the rest open. This also works for the North, East, and West sides of the map.
Objective 4
Use software development processes to analyze a project problem, and to design, build, and test a corresponding software solution.
Ricoshot
GPE104
Ricoshot is an FPS wave shooter created for GPE104. This game was created using Unreal Engine with Blueprint scripting.
​
Ricoshot has this unique mechanic in which you can only kill enemies by ricochetting bullets off of a ball. I didn't have a way of verifying if an enemy was in view of the player in the development of this mechanic.
​
How I solved this was through the use of rays. I shot a ray from the direction of the ball to the enemy, and if it hit something that wasn't an enemy, then it wouldn't work. This allowed me to really imitate a ricochet as now the hit scan of the mechanic wouldn't be able to just hit enemies through walls.​
Project Katalyst
Internship
Project Katalyst is a Unity game project that I am currently working under as Programming Lead for Lauren H. It's a coop. action-adventure, shoot 'em up that plays similar to Star Fox, but there are 3 players that all have to share the controls.
​​
​The player ship was controlled by 3 players, but the players would be assigned to certain actions, such as up and down movement, left and right movement, and shooting. Not only that, but all players had some control over the other's controls, albeit at a severely reduced amount.
​
I was tasked with implementing this functionality. The way that I was able to achieve this was to introduce a middle-man script called the "InputComparator". The job of the "InputComparator" script was to take in the values of the inputs of 3 players and provide a weighted amount that they were allowed to affect the controls. For example, Player 1 has an 80% modifier of the controls for up and down, while the other players had a 10% modifier.
The player controller, set by the input comparator when a controller is created, would be assigned their player number and then were to pass their information through a struct created in the "InputComparator".
​
The "InputComparator" would be connected to the player ship upon starting and it would use the weighted total of the players' input throughout the level.
Stand Your Ground
GPE340
Stand Your Ground is a top-down wave shooter created for GPE340. This project was created in Unity with C#.
​
This project had two major problems that I tackled and want to address.
​
The first problem was that during the development of pickups, I wanted to include pickups that could change the player's weapons while they were playing. The build at the time could not support that. I devised a solution that imitated how controllers connected to pawn. It was through a script called the "WeaponManager" script. Every pawn that could wield a weapon had it. It would equip and unequip weapons easily through one function and all I had to do for pickups was call this function in order to equip a different weapon. It would also update the player model's hands to be in the correct place for holding the weapon.
​
The second problem was during the development of the weapon and enemy systems. It was actual a product of the first solution in which I just had projectiles remember their owners and not damage them. The problem was that enemies would damage each other. I created two scripts called the "FactionManager" and "FactionComp" script. The "FactionComp" provided the designator for factions of Player or Hostile while "FactionManger" provided an easy way to access the faction enum in that component. This allowed for enemies to shoot through eachother and their bullets in order to overwhelm the player in a bullet hell.
Objective 5
Demonstrate development skills using multiple programming languages, development environments, and platforms, including advanced and/or experimental topics in game programming.
Maze Mania
GPE230
Maze Mania is a 3D platformer maze game that was created for GPE230 using Unreal Engine. The project utilizes C++ for scripting.
​​
The game features an A.I. that was developed using Unreal Engine's BlackBoard and BehaviorTree systems. The enemy A.I. will attempt to engage the player by chasing them and when they are close enough it will attack.
​
Related to that, the enemy attack features a custom punching animation ported from Mixamo. This attack animation was then adapted to the mannequin models in Unreal Engine utilizing the IKRigs system. The animation also had a spheretrace at the fist socket that was enabled for a specific frame in order to give the enemy a vector of attack that could be dodged. This vector was tied to the location of the punch's location through C++.
Bounce Back
GPE338
Bounce Back is a top-down wave shooter with the unique mechanic that you can hit the enemy's projectile back. It was developed in Unity for GPE338
​​
The game features object pooling for the enemy so that I can both limit the number of projectiles fired in higher waves and the amount each enemy can have in play.​
​
It also utilizes scriptable objects and editing Unity itself to include a custom object type called the "BouncyBallData" object and the ability to create this object type in engine. This provides an easy was for developers to create new bouncy balls that the enemy can shoot and for the player to time their hits for.
Objective 6
Establish collaboration, mentorship, and professional leadership skills by working with other disciplines to deliver highly polished and completed projects.
Cliffside K.O.
PDS300 & PDS400
Cliffside K.O. was a project in Unreal Engine that I was part of the development for both production studio cycles. I worked under Thomas E. who was both the production lead and design lead.
​
The game was a 3D multiplayer, beat em' up, fighting game that would have players knock each other off of the map in order to eliminate them. The goal of the game was to capture points towards a team's nexus, in which the opposing team would attempt to destroy the nexus in order to win.
​
I was responsible for the creation of the ledge grabbing mechanic for the hero character, turrets, and laying the foundations for point capturing in the game. The turrets were going to be a mechanic in which players can place buildings that would assist in defending a point.
​
I talked extensively with Thomas on how he wanted to work the mechanics, and I would always try my best to interpret and implement them as best I could. Honestly speaking, this was during the earlier years of my time at UAT and so I could not work the same speed nor efficiency that I wanted to.
​
In PDS300, it was just me and another programmer by the name of Colby G., but by PDS400 the programming team increased to 6.
​
During PDS400, I was able to communicate and work with the programmers in order to tackle problems with our source control and multiplayer functionality.
​​
The source control for the game was broken. Something in the library fold, or the library folder itself, was being inputted into the project and every time someone wanted to push something, it would break. This was solved by a programmer by the name of William W. and we followed his instructions in order to sync all of our source controls to the project's version.
​
Multiplayer was a group effort too. A programmer by the name of Kyle provided the explanations on how to make an action communicate to a server and back. We then followed his example and for each mechanic that was on the hero character that we worked on, and we gave it the ability to work on local multiplayer.​
Project Katalyst
Internship
Project Katalyst is a Unity game project that I am currently working under as Programming Lead for Lauren H. It's a coop, action-adventure, shoot 'em up that plays similar to Star Fox, but there are 3 players that all have to share the controls.​​
​
In the beginning I was just a programmer, but I had significantly more experience now than I did back when I took production studio. During the first meeting, there were a multitude of problem related to the project at the time. The gameplay looked fine, but it didn't behave as Lauren, my boss and project lead, wanted.
​
I identified some problems in the beginning. The game suffered heavy amounts of problems relating to both concept versus implementation and principles of OOP.
The track moved, and not the player, giving the illusion of movement. There was a script called "TutorialTrackMovement", and it was the keystone script. If that was removed, nothing would work as intended.
The player script was functionally both the pawn and the controller so you couldn't have the ship without destroying the controller. Respawning was tied to the "TutorialTrackMovement" script, collisions with obstacles in the level was tied to this script, player orientation to the ship was tied to the script, the camera was tied to the script and problems similar to that. Funnily enough, one of the only parts of the project that I didn't see a problem with was the player's shooting script. It was in it's own script that was on the player ship prefab and it followed OOP fairly well. The only problem was that it was tied to the player controller/pawn script.
​
I was tasked with separating the major functionalities into their own separate scripts so that we, the programming team, could work on the project fully. I worked around 18 hours total that week to fix everything fast because I was the limiter for everyone else's work. I also fixed the input system and provided controller support using Unity's new input system.
​​​
Due to my extensive work on the foundations of Project Katalyst in week 2 of production, Lauren came up to me personally in order to promote me to Programming Lead.​
​
From there I would be talking more extensively with Lauren on the development of the game, development timeline, advice and/or thoughts on interactions between foundational systems, and the general outlook for the project to get a publisher/funding.
​
There's also my coordination with other programmers. We discussed interactions between systems and provided guidance/help for other programmers for their problems. There was this major problem in the beginning with source control and with the help of another programmer by the name of Jess B we were able to identify it as the libraries folder and have it excluded from the push.