Dominick Trusko

The Problem: To prove our commitment to game development, the informatics school at Arizona State University mandates all students in the program participate in a "Game Jam". For the uninitiated, a Game Jam is a competition where a team of developers are tasked with making a video game, from ideation to completion, in a limited time frame. For this Game Jam, the time limit was 3 weeks. Teams were restricted to 4 members, but due to the crew's continued excellence in prior assignments, we were allowed to work in a team of 7 under the condition that we developed something far beyond the scope of the course.

Design Considerations: From the beginning we knew we wanted to make a Virtual Reality game. Many of the programmers on the project wanted to work in the VR industry, especially as the Valve Index had launched a few years prior, making earlier SteamVR headsets (Such as the HTC Vive) affordable to college students. I had been working on VR projects since ~2014 on my Oculus Rift Devkit 2, using flashed Razer Hydra magnetic tracking controllers to interface with the worlds I created. I took the lead on the project to prevent potential learning friction, and after discussing potential project ideas we set the following criteria for our VR game.

Besides the VR limitations, we also had limitation placed due to the nature of the project. Even if we had decided against making a Virtual Reality project, these would have still applied.

Another restriction was that we had to abide by the randomly generated categories distributed to the class. These categories were generated using Gunnar Clovis' Game Jam Theme Generator While the original seed is lost to time, we took a screenshot of the list and attempted to ideate off these selections. We definitely took creative liberties regarding narratives to match themes.

Ideation: Given our self-set restrictions, we were extremely limited in the potential games we could develop. There are fantastic virtual reality games that utilize features such as artificial locomotion and wide-open spaces, but given the time constraints and restrictions on enterprise software (Such as VR Inverse Kinematics systems), we decided to step the scale down a lot. We eventually landed on 3 separate designs, then took the project to Meteor Studios, the ASU Virtual Reality development studio, to ask for their feedback on our design documents. We called our three proposal Heresy, Spaceman, and Robot.

Float around a space capsule, trying to diagnose hardware faults from radio instructions and onboard documentation.

Explore an abandoned house, imbuing firearms with holy spells to defeat demons trying to enter the world of the living.

Pilot a mechanical war machine, defeating other machines and collecting their parts to improve the combat-capabilities of your own.

Test Build: Once we had made our final selection, we started getting to work. We started off by making a quick demo to test controls and basic mechanics, this project would be the basis for our final design. To minimize the work required, some design choices were made. Primarily, this version of the game has a very simple user-interface, no weapon switching, and uses a lot of prototyping assets from the asset distribution platform Synty under a studio license one of our team members purchased.

Essentially all of this initial build is lost due to the license expiring. If you were to repurchase the asset packs required you could definitely reconstruct the build from the GitHub Repository. All that survived are the assets I created, as well as a singular video from the debugging phase of development while we were trying to resolve clipping issues. Given this demo was made in 3 days, it was actually rather impressive, featuring a full tutorial, voice acting, and a 3D user interface that moved separate from the player to simulate movement.

Initial Art: As I compulsively save and preserve my own work, almost all art assets used in this project have been retained. This video demonstrates the armor system, as well as the face-shield deploying, which was cut from the final project as removing visibility from the player made the experience significantly less fun.

Here is a dump of initial art that made it into the 3-day demo. It was not a busy weekend for me, and much of it would be reused for the final project so I worked 8+ hours a day to ensure these would be finished in time for the submission on Monday.

Taking inspiration from previous projects, to add enemy variety with very little labor I decided to manually draw all the textures in GIMP, switching out the base colors and dirt maps to create enemy variety from simply loading different materials. While this was extremely important for this demo, as there was no weapon variety, it also carries over into the final game. Its especially helpful in Virtual Reality, where its difficult to differentiate shapes at distance, so the colors worked wonders for making enemies identifiable at a quick glance.

Game Design Document: Because we had to submit a Game Design Document (GDD) to get access to course resources, I produced this to show off to the class. This document covers the majority of the major game themes and features, at least as we believed was possible from the start. This document also goes into basic functions, such as player input for both traditional and VR controls, and a general writeup for how specific mechanics work, both to the user and on a technical side. Some of this stuff never made it to the final build due to performance issues, but for the most part this document remains a fairly accurate representation of the final game.

Art Development: Since my department was art and general management, I spent most of my time herding group members and developing art assets. Below is a dump of development screenshots of individual assets.

Post-Mortem: I learned a lot working on this project. Not only about PLC programming, which was my target area of improvement, but also interfacing with businesses. Talking to individuals along the entire production process from design, sales, and fabrication to learn how to correctly integrate the donated hardware. I am extremely proud of the final project, as it taught me a lot about UI design, PLC programming, panel-design, weatherproofing, and various other skills. We manages to hit all of our target requirements while using none of the budget. I will bring other members from my club in to do some beautification passes, such as sanding the dirty aluminum table to reseal it, as well as add wire-channels to make it easier to move and lower-risk of breaking from long-term usage.