Dawn is a 3D platformer for Windows where players guide a druidic creature named Ash through a beautiful environment to bring life and light back to a dead tree at the center of the world.
Players must use Ash's power to grow plants and activate objects to create paths through the environment.
I took the opportunity to explore new avenues during this project, taking on a variety of different roles to expand my palette and breadth of knowledge as a developer.
I decided to tackle a lot of tasks I hadn't on previous teams to make myself more well-rounded and gain experience in other auxillary duties developers have.
Source:
Closed Source
Date:
December 2016
Team Size:
18
Languages and Technologies Used:
Unreal Engine 4, C++, Windows CLI, Innosetup, Perforce, Git, Slack
I created, iterated on, and polished the vines in the game. This included everything from making them work, to making the leaves pop out, to making them
easy-to-use for designers.
I created the vines using a spline and an array of spline meshes. I had attempted to use one to start with, but the spline mesh would only conform to the beginning and
end points exactly, taking all of the middle points in as weights. In order to make this look good, I used some interpolation math to dynamically resize each of the
endpoints of the meshes while the next two segments of the vine grew, making the tip slowly grow throughout the segment and finally flesh out and expand to its full
form. Then, I added a set of tools for the level designers that showed how the vines would look grown inside of the engine via the construction script. I then took
another teammate's physics-based leaves, and rendered them in the constructor preview of the vines, making them easy to view and place in the level, which sped up
development for the designers by a large amount. This was only achievable by continued iteration with members of the design team, and I learned a lot about communicating
with them and trying to make them a tool that was not only what they wanted, but was also easy enough to use that it made their workloads easier.
Menus and UI
During the tail end of development, I created and polished a reactive menu system, complete with keyboard/mouse and XInput controller support.
The project was nearing completion, but about a week out from our milestone, our menus weren't up to snuff. Mostly built as a work in progress up until this
point, the menus weren't responsive to changes in the UI and had no support for controllers, which our game used as our primary input method. Despite the tight deadline,
I stepped up to the plate, reworking and reimplementing the whole system from something unshippable to what our game currently uses.
I was not only able to refresh on a lot of mobile and web development skills that I had, but I later drew upon my experiences with the engine's UI when planning out
what UI development would look like in my own engine.
Build Engineer
I created our nightly build system on a seperate development machine that ran every night after development, getting the latest assets from Perforce, compiling, and
creating an installer with the resulting output.
Surprisingly, I enjoyed working as the build engineer a lot more than I expected, partially due to the autonomy and freedom I had to improve the build process and pipeline.
The process of building our pipeline mirrored game development's iterative development, as I found weaknesses and choke points that I wanted to address while I continued to use the system.
I began with a lot of research on Unreal Engine 4's command line support, starting off with an initial .bat file that chained the tools together. I added some progress statements
that I eventually built a SlackBot to tell the team leads about the build's health and status (See BuildBot section). I hooked the script to run nightly via Window's built-in
task scheduler overnight. I then hooked up RDP on the new machine so that myself and the lead programmer could access the build machine remotely, which was instrumental when
issues came up unexpectedly or we needed to run an emergency build. I seperated out the build script into modules that could be called easily, seperating the steps into a
Nightly, full build that rebuilt our entire engine from source to account for any changes we made, as well as a quick build that focused on the core assets. I also created the
installer for the game using Innosetup, which was built as part of the toolchain automatically, then dumped inside the build folder on a server all of the team members could access.
Audio Programming
I helped the team create a pipeline for audio, compiled and integrated the Wwise plugin for Unreal Engine 4, and hooked up all of the audio events
required for the game.
After discussing the audio direction with the Game Designer, the team decided that Wwise would be the best direction for the team. As a result, I worked
on researching and implementing the plugin, while smoothing out the pipeline to make it easy for non-programmers to use. Since we were building our engine
from source, I built the plugin from source as well, which allowed me to make performance changes regarding attenuation when we had framerate issues. I also
implemented the majority of the in-game audio event triggers, and taught others on the team how to use the tools we had and how to install and maintain the soundbanks.
After the project, I worked with the game designer and gave a presentation to the next class on how to integrate Wwise for their own projects.
Build Bot
While working on the nightly build system, I decided to create a Slack bot for the team chat to display build status in real-time and print out any and all information associated with the build.
During the initial setup of the build, I had realized I had a lot of time on my hands while waiting on build verification, and made a proposal to the team's leadership
for me to create a Slackbot and command-line integration in order to keep the leadership team informed on how builds were going. I used SlackCat to print all of the build's
command-line output to slack, and put all of it inside the nightly build .bat script. All of the build output would be output into a text file, then uploaded to slack as the
build progressed each night. If there were any failures, the bot (affectionately named "Buildie") would private message each of the members of the leadership team along with
the respective error codes, and a translation if it was one we had experienced. This was one of my favorite parts of the project, as it allowed me to leverage a lot of skills
I hadn't used often during Guildhall, while stretched me to learn new things about the Windows CLI and the Slack API.
Localization
I was responsible for researching and implementing all of the localization support the game would need.
The team and I were able to translate the game into 5 different languages as a result!
I integrated Unreal 4's native solution for localization and focused on smoothing the pipeline for non-programmers on our team, as well as for non-developers
who were responsible for doing translations. By creating a series of .po files to house the specific translations for each language and loading them into the engine,
I was able to change and swap text on the fly inside of the application without having to use branching or language switching for each text field. I also wrote code
to implement a runtime language switch in C++ that I later hooked up through blueprint menus that you see in the gif here!