I'm a recent valedictorian graduate from DigiPen Institute of Technology with a strong passion for graphics and engine technologies in game development. I'm also a musician, being a classically trained pianist — amongst a wide variety of other instruments — for over 20 years. While studying at DigiPen, I led the programmers in my team, Midnight Hour, in our work on the games Lost in Transit and Gutter Ball as the Technical Lead, and later, the Technical Director.

 We built the engine from the ground up in Lost in Transit, where I adopted a variation of the null object pattern to create a compliant ECS type design. For our later game Gutter Ball, I took an approach that promoted interoperability between C++ and Blueprints in the Unreal Engine to help the team benefit from both workflows (using Unreal's provided reflection system in C++).

 When working in the computer science field, I highly value thinking critically and planning ahead; so systems can be developed with the necessary amount of performance and extensibility the first time around. If there's one thing I've learned from my time at DigiPen, it's that game development requires a great deal of scope management and cutting corners where necessary — these two ideas are often at ends with each other.

 In Lost in Transit, we solved one of these contradictions by writing an engine wide macro for entity components and system calls. This made the code far easier to write, easier for team members to understand, and reduced duplicate code all while incurring minimal performance overhead. Reworking the ECS to be templated would have been a more robust solution, but also would have taken development time away from other sections of the game to achieve the same results.

 One of the two greatest assets that I've developed while working in teams at DigiPen is being able to listen and encourage diverse approaches to problems — it may be cliche, but two heads really are almost always better than one. The other is the balance between ensuring systems are robust and optimized, and keeping those same systems within the scope of the project. Put simply, if a system runs the same, isn't noticeable by the player, and doesn't incur huge technical debt — the only difference between an excessively written system and a system that does everything it needs to, is wasted development time.