Henry Chronowski
Portfolio
Project maintained by henrychronowski Hosted on GitHub Pages — Theme by mattgraham
ModBots
- Team of 21
- April-September 2021
- Role: Technical Lead
ModBots is a multiplayer action rogue-like where players cooperatively fight waves of enemies in a generated arena, looting better weapons and equipment as rewards.
This was the first game released by my studio, Earthbreak Games, and was an experiment and learning experience for the students who worked on it. I personally served as the studio lead throughout development and publishing onto Steam, as well as the Lead Programmer. We worked in Unreal Engine 4, utilizing the Advanced Sessions plugin to take some of the networking workload off of our shoulders, and developed with the sole intent of bringing the game to publishing. My primary technical responsibilities (when I was granted the free time to not be acting in a management/leadership role) were to build and maintain the arena state generation and modification tools as well as maintain asset integration pipelines.
Arena System
For ModBots, to keep the player coming back we needed an environment that did not get stale on the second startup. The knee-jerk reaction to this issue these days is to work with procedurally generated levels, but due to the limited time that we had to fine-tune a system relying only on a procedural algorithm to create fun and balanced level layouts the risk in going with purely procedural was simply too high. After doing a great deal of research and reading about the level-creation pipeline used in the development of the game Due Process we arrived at building a semi-procedural system that took the maximum amount of work off of the level designer while still giving them the ability to tweak the finished levels, ensuring that they are up to par.
My goals in developing the system were to make something that designers were comfortable using while maintaining as much customizability as possible, striking a balance between usability and functionality. At this point I had minimal experience in developing tools for Unreal, so I worked to develop a system that would act as both the tool and the game object, adding the logic to create and modify the arena to the arena itself. In order to achieve this I built the necessary functionality for the generation and modification of the arena into a base C++ class, then used editor callable events in a child Blueprint class to create a UI for the designers to interact with built into the details panel of the object. I chose this approach rather than directly implementing the arena in C++ as I honestly did not want to deal with the setup of details panel customization, as I needed to rapidly get a usable tool for the designers to start working with or risk impeding their workflow.
Overall I would consider the tool to be a middling success. Its usability was not as great as I would have liked, and this made it harder for the level designers to get their vision into the game, but with the timeline that we were working with I am pleased with how it turned out.
Retrospective
If I’m being honest, looking at the game in isolation it was a failure. It’s a buggy mess, not exactly fun, and horribly unoptimized. In context though, building an excellent game wasn’t the goal of the project, the goal of the project was to get the experience of having to work to push a product all the way to publishing, and in this the project was a resounding success. We embodied the maxim of “fail fast, fail often” more heavily than I thought possible, and came out of the experience miles better developers than we entered because of it. Having gone through my senior year and capstone now, I don’t think that I could have accomplished half of what I did without the experience I gained in this project.
One thing that I have walked away from ModBots trying to implement in every single project I do now are clear pipelines. As students, we did not really have the opportunity to switch from a prototyping stage to a production stage until this project. Because of this we weren’t familiar with the notion of having defined ways of going about certain actions and processes, with the emphasis being placed more on speed than efficiency (A theme you can see throughout the above paragraphs). Going into the challenge of pushing a game through to publication with this attitude caused numerous problems, both interpersonal and development based. If we hadn’t realized this, stepped back, and solved the issue by creating a set of discrete pipelines for everything from asset implementation to how designers notified programmers of revisions the game simply wouldn’t have been published. Taking this experience forward and building solid, extendable pipelines at the beginnings of projects since has been a literal lifesaver.