On the shoulders of (obscure) giants

The main inspiration and emulation target for DriftSteel was the titel Critical Mass by Sean O'connor, an indie game for windows released in the late 90s. My dad introduced me to it, we had the whole Sean 'Oconnor collection on our home PC growing up. Critical mass provided the idea for a space combat/strategy game that used a simultanious turn based system where actions were planned ahead and then executed. Where DriftSteel differentiates itself from Critical Mass is its implimentation of innertia. Rather than moving on fixed rails, objects build up velocity and can rotate independently from their heading.

Given the obscurity of Critical Mass I struggled to convey the concept to potential teammates and the program instructors in a way that was concise, clear, and snappy. In search of more recent games with similar mechanics I found Gratuitous Space Battles, but even that was an obscure game few had heard of.

Ultimately, we settled on describing the game as "Asteroids, but turn based". That got the idea across much better, even if Asteroids wasn't our main emulation target

Feedback is key

The mechanic of simultanious, turn based, inertial gameplay isn't very intuitive. Player see a ship on the center of the screen and expect to be able to play it like asteroids. It took a lot of playtesting and revisions to make the game understandable to players.

An important aspect is the colored velocity prediction line, and making it curve accurately when taking into account the player's thrusters. In addition, we needed to add extra text to the screen to explicitly state which state the game is in. More subtle forms of feedback are also present, such as the change in saturation while the game is paused to make the player and enemies pop out from the background, or the way the melody of the background music gets louder while the action is happening before dialing back while the game is paused.

A core mechanic is lining up shots correctly as your missiles inherit your velocity when fired. When arming a missile we pulled a simple dev hack to spawn a ghost missile that uses the exact same movement code as a real one to convey where the shot will land. Sometimes the simplest solution is the best.

Most actions can be triggered both by keyboard input and through clickable buttons on the UI. Some playtesters just wanted to click on things, especially when they were confused, where as others preferred to keep their hands on the keyboard.

Subtle hints are good, but sometimes you just need to spell it out plain and simple

As a sophemore year project it’s been several years since I worked on DriftSteel. My memories from the time aren’t as sharp and many of the documents written at the time were stored on OneDrive through a .edu email address that I no longer have access to. This post mortem will be much shorter and lighter on details than the others.

DriftSteel started off with the idea of remaking Critical Mass by Sean O’connor, but the process of explaining that well enough to put together a team was easier said than done given the game’s relative obscurity. During the team formation process I was only just barely able to fill out the team roster with the minimum number of programmers, and I wasn’t able to attract any dedicated designers. My team consisted of fellow students who didn’t have strong social connections and weren’t the first pick to get on to the larger teams. I had prior experience with C++ before coming to DigiPen but others were picking it up for the first time. Most of my teammates I met for the first time in the Plato Lecture hall when I pitched them on the game, and while we weren’t friends before working together on this scrappy project built ride or die friendships that I’ll treasure for the rest of my life. We really felt like underdogs, trying to prove the value of this obscure, novel form of gameplay.

This was one of my favorite games growing up, but absolutely no one I've ever talked about has ever heard of it

I didn’t expect to get artists on the project, arriving late to the secluded room to deliver our pitch. We’d scrambled to throw together a power point presentation to pitch them on the game only to find out that the projector wasn’t available and we’d just have to talk it out. I tried my best to explain the setting: a field of debris in space that one of my teammates described as “Steel driftwood” that then got shortened to “DriftSteel” to become the game’s title. I explained that the player would be flying in ships and fighting other ships with major influence from the TV show The Expanse, but suggested that we could fight other things like giant bugs ala Nausica Valley of the Wind. I didn’t expect that to resonate with anyone, but not five minutes after walking out of the room we had a team of three artists asking if we were still hiring.

We originally wanted to get much more up close and personal with the insectoid enemies

But for the final game we only showed the bugs from the outside. Art by Dirk Mccoy

Having a small team worked great for me. I clicked with nearly everyone and we were able to bounce ideas off of each other well without too much deliberation. I threw together a unity prototype to show off the basic mechanics and visualize some of the artist assets. In this prototype I had the turn based physics, and the indicator line showing where the player would end up after hitting “Go” to pass the turn. It really wasn’t much, but when it came time to explain the concept to the course instructors it helped immensely. Still, in that early stage there were plenty of doubters. One of the professors didn’t seem to grasp the value of the gameplay style and thought the game should just be real time. I stood my ground in the meetings, saying that I looked forward to proving him wrong.

We had an excellent pre-production where we made multiple choices that helped the game succeed. From the start we decided that all collisions would be circle to circle only, which greatly simplified our engine. All art assets would be drawn with the understanding that they’d have a circle collider, so they avoided shapes that would have too many unnatural overhangs or that were overly convex. We also intended to let the player zoom in and out dynamically (though this did not make it into the final game) and thus decided that all sprites should have unique silhouettes that would make them readable from a distance. One of the mistakes we did make was committing to use RapidJson for data deserialization. We only had a handful of third party libraries we were allowed to use, and other libraries were available, but not knowing any better we took the recommendation from the course instructors. As sophomores still getting used to C++ we struggled greatly with the ins and outs of RapidJson, and ultimately ended up utilizing a second Json library that was much easier to use to patch up the parts of the engine we were struggling to cover using just RapidJson.

The process of building the engine early on was a bit of a struggle. In earlier projects we were given frameworks to handle window management and graphics drawing, but for this project we were on our own with OpenGL. Initially we fell behind, watching teams on either side of us get their triangle on screen well before us. We also struggled to lay out our architecture until our assigned TA sat us down and cleared up the confusion. We managed to get a textured polygon into the engine moving around a mere thirty minutes before the first milestone presentation. As stressful as that was, we still had a strong understanding of the design we wanted to implement and the prototype in unity to base it on.

A photo of most of the team. Our last member hadn't joined at the time this photo was taken

The earliest existing photo of the unity prototype

Excuse the programmer art of it all, but our final game ended up remarkably close to our innitial mockups

Debug view drawing the circle colliders

Screenshot taken minutes before walking into our milestone 1 meeting

Midway through the first semester Jared Gardener’s team fell apart and he asked to join ours. Jared is an incredible programmer, and an even better generalist. We were doing okay up until that point but Jared joining and lending his talents took the game from good to great. He brought along his own easing function library, as well as a knowledge of audio composition and OpenGL shaders that we never would have had for the game otherwise. I wish I had taken more photos of the time, the only one I have of us two was taken years later after graduation.

Me on the left, Jared on the right

(Post Graduation)

While there was constant forward progress, we also ran into some stumbles as a team. We were required to have a tech lead, a producer, and a design lead, and all of them had to be held by separate people. Both tech lead and design lead had to shuffled around. Earlier on we had just assigned them to whoever stepped up so that we could fill out the requirements, but it took some time working on the project to see who would be best for each role. One of our programmers was consistently falling behind, committing broken features to the repo and clearly not understanding how to contribute to the project. When I sought advice from my peers and the professors I was told the best thing to do would be to let him go from the team. Within GAM 200 there were rules about how and when someone can be “fired” from a team, and with the deadline approaching fast I would need to make a decision. I didn’t feel right about letting him go, he had been one of the first to sign on to the project and had even suggested the game’s title. He believed in DriftSteel, and so I had to return the favor and believe in him. Against the advice from some professors I decided to keep him on the team and take personal accountability to getting him caught back up with the rest of us. It limited some of the scope of what we could achieve because I had to devote my time to mentoring him and pair programming much of the work assigned, but I think it was the right call in the end. He’s one of my closest friends now and went on to make amazing projects at DigiPen. I don’t know if that would have happened if we had let him go and forced him to find another team to take him on.

We had initially designed the game with three distinct parts, approaching a derelict structure, finding a black box, and then being chased out of the wreck by a bunch of enemies. Unfortunately, we had to scope back in the second semester. Making the complex levels we wanted to make with only circle to circle collision wasn’t possible, and expanding our collision to include circle to line would require extra tech. We were capable of creating that tech but we didn’t have the time to do it with all the other priority features still waiting to be implemented. The game was reduced to instead being a simple wave survival game. I threw together a very simple level editor, not one that we could ever release to the public, but one that did its job to help us build out the one level (before we had been placing objects in the scene by manually tweaking transform values in the json with VS code, so even a rudimentary tool was a massive increase in efficiency).

Our scene format was very simple, merely storing a list of objects and then a list of their positions. While far from optimized, it made implimenting a an editor for it trivial

When playtesting we found the game to be polarizing and divisive. For some people it clicked, and they became evangelists for the game, for others it just didn’t make sense and they found it frustrating. The last third of development went towards finding every hard edge and confusing point we could and sanding it off to improve the player experience. While I think we reduced many of the worst pitfalls, the truth is that the game’s appeal is niche, and like any other niche game there are some people who it just won’t appeal to.

If DriftSteel was a commercial product, I’d definitely work more aggressively to broaden the game’s appeal. As it exists, the game’s tutorial is serviceable, but not extraordinary. Explaining the game’s appeal is also something I struggle with, it feels like I need a whole ten paragraphs to explain what makes it so cool. Thankfully, that’s not the scope of the project. DriftSteel was a learning experience, and when viewed that way I can say that it was very successful. I learned a lot about cooperating with a team, managing different people’s skill sets and abilities, and how to be resilient even when things aren’t going well. As a designer I learned how to synthesize, communicate, and verify my ideas through playtesting. As a programmer I learned the fundamentals of how to implement an engine with component based architecture, as well as serialization and polymorphism. While it’s normal to look back at a project and think about the things I could have done differently, the truth is that I’m very satisfied with how DriftSteel turned out and any regrets I have are just cool ideas we never had the time to get to. It’s definitely a formula that I’m tempted to expand upon on my own time with the skills I’ve sharpened in the years since the project’s conclusion.

The game is currently playable on the DigiPen game gallery, and I’m working on getting the boxes checked to have it uploaded to steam as well. You can try it out if you’d like.