Project Everglades
Overview
Collaboration with Lockheed Martin
Project Everglades was originally an AI vs. AI, competitive, turn-based strategy game. “Players” would build an AI agents outside of the experience using Python, C++, and feed the telemetry files into the Unreal Engine to be rendered and simulated visually.
When Lockheed Martin reached out to partner with the University of Central Florida, they expressed their desire to turn the simulation into a truly playable experience. Our team of 11 graduate students set out to do just that. I was personally responsible for scripting player interaction from inside of the Unreal Engine using blueprints. I had to familiarize myself with the 100+ blueprints code database already written before UCF was brought onto Project Everglades and figure out which ones needed to be modified for player interaction.
Role: Technical Designer
Project Details:
• Team Size: 11
• Project Life Cycle: 4 months
• Game Engine: Unreal Engine 4
Highlighted Contributions:
• Scripted player interaction into an AI vs. AI experience
• Fixed bugs and contributed code to a large preexisting blueprints code database
• Reworked preexisting dependencies to accommodate new art assets
• Wrote documentation for future partners of Lockheed Martin
Player Interaction
Adding this feature to a simulation that was never designed for it proved to be difficult. The simulation’s functionality was spread across 3 different scripting languages (Python, C++, and Blueprints), so there was no single place that player input could be added to turn the simulation into a game.
Collaboration:
A handful of graduate game developers collaborated on integrating player interaction into Project Everglades. A couple focused on the Python side, one focused on the C++ side, and I personally spearheaded the Blueprints side of the code database. After scanning through the entire code database, we determined that constant communication was going to be key. All 3 of the programming languages interacted with one another. If one of us were to tack on functionality into one of the scripting files, it could have an effect on another file in a completely different scripting language. We decided to create a Technical Design Document for internal use that functioned as a guide towards where the important features of the project were housed. Using this document while maintaining clear, constant communication helped us avoid writing game breaking code or creating bugs.
Implementation:
First, I needed to add player input to the “Spectator Camera” blueprint that was currently being used to view the playback of the simulation. The code I wrote turned the blueprint into a true player controller. However, I then needed to collaborate with our UI Designer to make sure the functions I wrote would be able to work inside of the user interface. In addition to selecting and deploying your drones with mouse input, you were also able to cycle through drone groups and deploy them within the user interface. Getting the drones to move based on player input proved to be quite the challenge. The vector locations being fed into the blueprint came from the Python code originally. In collaboration with one of our Python programmers, we were able to achieve the inverse of the process and send the IDs of the target base from blueprints to Python which then fed the location back into blueprints.
Jumping into a Large Code Database
Challenges:
Project Everglades’ code database featured over 100 blueprints inside of the Unreal Engine project. At a glance, it was difficult to determine where specific functionality was stored. About 20 blueprints made up the user interface. Most of the simulation’s functionality was stored in a single blueprint that referenced about 15 other blueprints. Almost all of the code was not commented and there wasn’t any documentation provided that pertained to the Unreal Engine project. There didn’t seem like a clearly defined position to jump in at.
Process:
I started with the “Game Mode” blueprint which housed a large portion of the simulation’s functionality. From there, I followed every thread to its corresponding referenced blueprint. It was a time consuming process that took me close to a week of investigating and note taking to find where all of the functionality lived. I then took those personal notes and started writing more professional documentation based on what I learned. By the second week of the project, I was confidently modifying many of the important blueprints as well as fixing errors that were present before the project was given to us.
Leaving a Legacy
We were told at the start of the project that Lockheed Martin had a giant vision for Project Everglades that would extend beyond my team’s time spent with the project. Given that information we we asked to update and expand the project’s current documentation. My project lead looked into updating preexisting documentation, while I focused on creating new documentation. I wrote the “Unreal Engine Development Guide to Project Everglades” document which will help new Unreal Engine developers jump into the project. Inside the document contains information regarding where important functionality is stored in specific blueprints and which maps are important to testing/building the game.