Speedbreaker Postmortem

I should have written this a little sooner after posting the project, but better late than never, and I want to start making a habit of writing about my own work, so here we go! This post will be part postmortem and part discussion of my process on the project.

Project Goals and Initial Ideas

This project was intended to help me learn the basics of Unreal Engine 5. I was going through a lot of Udemy courses on Unreal (big thanks to Stephen Ulibarri in particular) and wanted to work on a project of my own on the side to solidify what I learned as I progressed through the courses. I also wanted to specifically learn how to code C++ for Unreal, and most of this project is coded in C++ rather than blueprints.

Before I started this deep dive into game development, I had the tiniest bit of an idea for a pinball themed first person shooter, where in order to do any damage you would have to ricochet your bullets off of the walls. That project felt a little too big for my skills starting out, and after thinking through a few decreasingly complex ideas, I landed on a very basic mashup of brickbreaker/Arkanoid style games and pinball.

Prototyping and Game Mechanics

Since I had no idea what I was doing going in and did not have any sort of default template for the style of controller I needed, it took me a couple days to work out controls that worked well enough. Initially, I had a mechanic inspired by pinball where each map could have 1 or 2 piston-like bumpers that you could control with the spacebar. After some playtesting I found that they weren't very fun and the ball kept getting stuck in them. Instead, I added WASD tilting of the board to move the ball around, which felt much more satisfying.

The WASD tilting to me actually felt like the most fun part of controlling the game after a few iterations of testing different ways it could work. This resulted in me designing a lot of the levels around WASD movement.

Another mechanic that changed a lot over iteration is how you beat a level and the way the game was scored and timed. Initially, I had the idea that when your ball was destroyed, all of the point nodes you had collected would still be gone, and you had a cumulative time for each level. You'd also have 5 seconds added to your level time when your ball was destroyed. Each level's time would be tracked and you'd be shown your best time as well as the least amount of balls destroyed for each level. That felt OK, but not particularly compelling, and there wasn't enough of a sense of urgency. Finally, I had the idea that instead of the timer going up, it would count down from 5 seconds, and you'd only have 5 seconds to complete each level. The only "score" in the final version is the record that is saved for the least amount of balls lost in each world of 10 levels. I think that change in mechanic gave a strong sense of urgency while playing and created moments where you would win a level with less than a second remaining, similar to the feeling you get when winning a close race in a racing game.

Level Design

In 2017, a few friends and I made a free physics puzzle game called Blockdown. In Blockdown, we had 3 worlds with 10 levels each. I decided that would be a good starting point for the structure of Speedbreaker as well, and gave me a nice limit to the number of maps I needed to make. I did not want this game to take longer than 20 minutes, especially because it was simply a learning project I did not intend to market and mostly just wanted to show friends and family.

With a format of 3 worlds with 10 levels each, I wanted to at least layer some new mechanic onto each world in a natural feeling way. The big level mechanics I had come up with were lasers that would destroy your ball, and moving/rotating bumpers (that could also have lasers attached to them). So, in world 1 there are only static formations of bumpers, in world 2 lasers are added, and world 3 includes moving bumpers.

Visual Effects and UI

I chose a vaporwave color scheme and very simple materials so I would not spend a bunch of time just on visuals, when the point of this project was to learn how to put an Unreal game together, not how to make the fanciest effects. That being said, I had a lot of fun putting together the Niagara particle systems used for the lasers and when the ball bumps into things and is destroyed.

The UI went through a lot of iterations. Early on it involved widgets floating in screen space on the side of the map. But when playing the game myself and having a couple friends play it, we noticed that we never actually looked at any of those elements. Eventually I moved more and more of the UI onto the actual game board in 3d space, rather than screen space. I had a lot of trouble getting the main menu and especially the options menu to work like that with widget components, but I'm really happy with the final result. I don't think it makes sense for every game, but for this game where it all takes place on a board that flips around, having the UI attached to the board makes a lot of sense, visually. I also opted to make my own menus instead of using modifying prebuilt menus from Common UI or another plugin. I might not do that in the future, but it was nice to build it myself and see how it all works.

Sound and Music

After watching a few tutorials and playing around with MetaSounds, the new system for manipulating sound effects in UE5, I decided to challenge myself by making all of the sound and music directly in MetaSounds. I didn't even use MIDI for the music, I had each sound effect hooked up to counters that would tell them to only play at certain times, and change the sounds in various ways over time. I'm really happy with how both the sound and music turned out.

What Went Well?

Overall, I think the project met my goals as a learning project. I learned a lot about Unreal Engine, C++, blueprints, MetaSounds, Niagara, and UMG. I didn't get super deep into any of these systems, but I was able to pull everything together into a project that I think at least looks and sounds decent. I also think I did a good job of iterating and "finding the fun". That being said...

What Went Less Well?

I think there is fun to be found in Speedbreaker, but I don't think it's a very good game. That's to be expected since I haven't made too many games yet, and this is the first one I've done by myself, but one experience I had when the project was nearly complete gave me a bit of insight into why the game isn't excellent.

Throughout making the prototype and most of the level design, I never tried out the game with a controller. The first time I actually played it with a controller was after getting it loaded onto my Steam Deck. Immediately I could tell that something was off about the gameplay. Controlling both the paddle and the ball at the same time with a dual stick setup felt really awkward. And even after going back to mouse and keyboard, I realized that the mechanics just don't come together in a very clean or satisfying way. It kind of feels like 2 games competing with each other. On the one hand you have the dynamic of moving the paddle and bouncing the ball off the paddle like a brickbreaker game, and on the other hand you have the WASD controls moving the ball around like Pac-man. In many of the levels, you aren't even moving the paddle around at all except to aim the ball for launch.

I think if I had tried the game out with a controller in the prototype stage I might have identified this lack of cohesion with the mechanics. Not all games need to feel great with both mouse/keyboard and controller, but I think if a game this simple feels odd on a controller, that's probably a good sign that something isn't working.

The other thing that frustrated me is how long the project took to complete. It took me around 5 months to finish, and I had initially hoped to finish it in a month or two. Now, there are good reasons it took this long. I wasn't solely focused on completing the project, I was doing a lot of learning at the same time, and I still do have a full time job that takes a lot of my attention. Still, I'd like to get a little faster at completing projects at this small scale so I can get a lot more practice at designing different kinds of games. I will have a lot more free time in the near future and plan on doing some game jams, which I'm sure will help me a lot with developing speed at prototyping.

Final Thoughts

If anyone read through all this and/or tried out my game, thank you! Even though I'm no longer super excited about the final product, I'm proud of myself for completing it, and now I have WAY better of an understanding of Unreal Engine and how to make games by myself. It won't be too much long before I post some more projects on this page.