Dungeon Divers

Dungeon Divers is the BYU student game for 2019-2020. We're still working on finishing it, but will finish it during the summer of 2020. When it is done, we will release the game on Steam.

We had a large team of programmers and artists working on this team. It is certainly not an individual project. I specifically programmed the user interface for the game, including in-game HUD and menus.

When we have a final version of the game, I'll put a video here.

What I did

As the UI programmer, I worked with Unreal Engine 4's widget system to build User Interface elements. This involved learning Unreal Engine's API, working with other programmers to connect the data they added in the game with my widgets, and iterating quickly.

Redesigning frequently

Dungeon Divers was redesigned frequently (the original concept was very different from the final product) and each iteration required new user interface elements. Although this was frustrating at times, I built each element to be easily changed so that the quick iterations could be tested.

Scrapped Projects

Since the game changed so much, there were many things that I spent a lot of time programming that did not make it into the final version of the game. These include:

• Selection outlines: the game originally had a 'select' action which would outline an enemy or character. This required making a custom postprocessing material that would detect the outline of the given object using linear algebra and then only display the outline on the correct players' screen.
• Dynamic cooldown: the final version of the game has almost no 'cooldown' times but in the original version of the game, the player had a lot more weapons and abilities at once, which essentially amounted to a variable but large number of abilities with cooldown times that the player could have at once. I built a system that would detect what actions the player could not perform and display the time left using a dynamic circular bar texture.
• Boss pointer: when the game was split-screen, each player had a pointer telling them where the Cyclops eye was. I built two versions of this: one which is now being re-used as a spear locator around the character and another that operated in screen space. The other one used a world space to screen space projection and then projected the resulting coordinate to an ellipse, which allowed it to flow smoothly and not overlap other elements of the user interface.
• Playtesting main menu: when testing the game, there were many options (such as life amount and time) that did not make it into the final game. These were changeable from a menu so that playtesters could test different versions of the game without having to re-compile it. One of the latest development decisions was to switch the game from single-screen to split screen. This required changing all aspects of the in-game HUD. If a widget was on each players' screen, it needed to be changed to show up correctly on the screen space. If a widget was on all screens, it needed to be redesigned and reprogrammed. Because my code was modular, this was not as difficult of a change as it could have been.

Final Project

• Show screenshots of main menu and explain them
• show screenshots of final screen and explain them
• show screenshots of final redesign and explain them

What I learned

One thing I learned from this project is the importance of good project organization and production practices. The lack of deadlines on our project made it harder to collaborate. When we did have deadlines, they greatly improved everyone's productivity. I was sometimes assigned to add things into the user interface that represented mechanics that were not in the game and then were never added. This was a waste of time and better production practices could have fixed that problem.

I also learned of the necessity of user interfaces. Without me adding an interface representing a mechanic, the mechanic was often unclear to players. Since the user interface communicates the state of the game to players, if something is wrong in the interface, players are confused.

I also learned the necessity of building code that can change quickly and easily. If I did not use proper software engineering practices when writing my code, each refactor (which happened frequently) meant that having code that could be easily changed to fit new requirements was of utmost importance. Avoiding code duplication, for example, meant that when code needed changed, I could change it once and be done.