Jan 15th, 2020: DigiPen Senior Research Projects

CANCELED

Jan 15th, 2020 at 7:00 PM
DUE TO POOR WEATHER CONDITIONS WE ARE CANCELING THE MEETING TONIGHT
EVERYONE PLEASE STAY SAFE!! WE WILL RESCHEDULE AS SOON AS POSSIBLE.

Title

DigiPen Senior Research Projects

Abstracts

This talk will feature a collection of senior research projects, presented by DigiPen students:

Templatized Lua Binding by Lux Cardell: In order to integrate Lua scripting into a C++ project, each function accessible to Lua must have a binding function. For a custom game engine project, I bound Lua to allow our design team to iterate and design more efficiently. To this end I wrote a set of templates that generated binding functions automatically based on the data types the functions required. These templates were designed to encapsulate the entirety of the binding process, from popping arguments off the Lua stack to returning an arbitrary number of values. I used variadic templates to allow the template to handle any function signature. In order to interface between dynamic and strict typing, I wrote a generic class that wrapped the basic types from Lua and the user-defined types commonly used throughout the engine.

TypeRT by Michael-Paul Moore: In order to develop a complex C++ simulation, many collections of data must be authored to control behavior during execution. Much of this is driven by the creation of different classes that will each require similar sets of utilities in order to effectively function. Utilities such as: Points of Access, serialization, classification, etc. While engineers can facilitate this functionality on a per class basis, this is time consuming and can often result in duplicated logic. Furthermore, while native representation is required during execution, by allowing the class definitions to reside outside of code we can gain the following benefits: • Accessibility to non-engineers without compiler access • Easily extend feature set on data usage inside and outside the main toolset • Since these class definitions are outside the toolset, they do not require code to be built • Further ensures abstraction from your data from different functionalities To solve these problems we want to utilize a single flexible wrapper class, referred to as TypeRT, to centralize interactions for game data. This creates an environment in which a given functionality only needs to be implemented once and then gained across multiple data types. In the actual talk details will then be given on the TypeRT implementation. Process by which existing classes can be ported will be explained.

Experiences of a Technical Director and Gameplay programmer by Samuel Schimmel: Discussing of my experiences both as the technical director and gameplay programmer of a UE4 C++ project, and as the UE4 C++ gameplay programming TA. The slides for my workshop, footage of the game, and commentary on various gameplay features I’ve implemented using UE4 C++, can be found here: https://www.samuelschimmel.com/unreal/.

Speaker Bios

Lux Cardell: I’m a fourth-year student in the Bachelor’s of Science in Computer Science program at DigiPen. I’ve worked on game engines for the past three years, and in the last year on a physics project calculating the binding energies of hydrogen in weak magnetic fields. Additionally, I competed this year in the International Collegiate Programming Contest, representing DigiPen in the first division. In the game engine I wrote in my third year, I integrated Lua scripting to facilitate a team of designers in creating a game. As the process of writing binding functions for Lua is largely repetitive but highly function-specific, I found a way to genericize the process of writing binding libraries using C++ templates.

Michael-Paul Moore: I am a Senior at DigiPen institute of technology and currently work as an Associate Software Engineer at Monolith Productions.

Samuel Schimmel: I was the technical director and gameplay programmer of the student game Perdition, which was selected to represent DigiPen at PAX West 2019, and is now available on Steam. Perdition was made in Unreal Engine 4, which allows developers to write gameplay code in C++ or using a proprietary visual scripting language called Blueprint. Despite the popularity and accessibility of Blueprint, I chose to write 100% of Perdition’s gameplay code in C++ for performance and complexity management reasons. I’m now the junior project class’ UE4 C++ gameplay programming TA, and present an annual workshop on UE4 C++ gameplay programming. My resume can be found here: https://www.samuelschimmel.com/

A Word From Our Sponsor

Coming Soon!

Resources

Coming Soon!