2025-02-13 12-53-44 - Trim.mkv

Most Recent Pass of Mechguy

Platform :

Tools Used:

Unreal Engine 5

Duration:

Current

Team Size:

Role:

Game Designer

Overview

Welcome to Mechguy! As this is an ongoing and unfinished project, I'll mostly be using this space as a dev blog style breakdown of my iterations, and why im making the changes that im making! The goal for this project is to be an exercise in game feel and proper juice usage. Ill be showing my iterations over time below! Enjoy :)

Update: December 2024 - Februrary 2025

I mentioned last time that I wanted to spend some time to actually complete the full game loop, and make this feel like a (while unpolished at this time) complete experience. I've locked in the notion that a "Mechbuilder" rogue like sounded like a interesting idea, the fantasy of a modifying your own giant robot with cards of sorts seems like something someone should've done by now and I've never seen anything quite like it! So for the last few months of I've temporarily moved away from the game feel side and just wanted to put something together that felt more whole. All the while creating systems that should get me quickly to the point where all I need to do to complete the game is just make content. Here's a look!

2025-02-13 12-53-44 - Trim.mkv

What are we looking at?

A bunch of new features! First of all we have our main menu and character select screen. This was actually pretty easy and was fun to get the camera blends and the new mechs I made using Assetforge! The player can select a specific mech, each with different stats, starting weapons and abilities, and movement stats. This gets locked into the game instance class, and is retained for a whole run until its completed!

Secondly we have our Roguelike map! Im actually very proud of this, as I thought building a system like this would have been significantly more difficult to get feeling right, but minus some bugs i still need to hash out, it behaves fairly well. The most interesting part of this to me was getting to be slightly deterministic, as a fully randomly generated map just isnt as fun as one with some rules. For instance, the map always knows to put a Healing station in the middle of a path, and at the end right before the bossfight.(That node is getting cuttoff in this build but trust me there is a boss node :D) . Additionally, I have an extra sanitization layer where each path determines if it randomly generated a shop (the yellow nodes). If it didnt make one randomly, itll pick somewhere above the halfway point of a path and replace one of those encounters with a shop, just so players always have somewhere to spend their hard earned credits. The random encounter events and the combat events are mostly entirely randomly placed, and those will have more combat and level variance soon.

Next we have probably my favorite thing added in this pass, the mech drop pod sequence.

First pass of the Mechfall

Most recent pass of the mechfall

The Mechfall

This was something I was SUPER excited to give a go on as it was a bunch of different feel related things that needed to be implemented. My first pass mostly involved moving the camera, using niagra particle FX to create the speed lines, and modifying the springs arms camera lag to make the mech feel like it was falling faster.

I still felt like it could feel faster, so after a few days I gave it another pass. With the following things in mind:

Pull the camera in while falling. Selling the emotional reality of a falling object speeding up
Frame the impact, shift the camera to a third person perspective right before the fall. Things going across the screen look faster and more clear than something going on the z axis
Add counteraction motion at the end, this is the followthrough that pays off the speed of falling. This was just adding a little animation to the mech squishing down a bit, i could probably make this MORE powerful for less time to get a better effect
Jam the screen shake and sound at the end. You cant hear it in these gifs, but i added a very light riser sound effect while falling, when the mech impacts the ground, theres a loud beep and the riser stops. The screenshake just makes the camera feel like its having a rough fall too and gives it significantly more weight.

With all these things in mind, I feel like the 2nd feels signifcantly faster, and more weighty and impactful, than the previous, obviously its not perfect yet. I still want to change how quickly the camera catches up to the mech mid fall. But I think this is a strong sell, and creates some excitement for the player when they start a combat encounter.

Update: November 2024

Been a minute since I've updated this, and I've felt the desire to get a bit more explorative and focus a bit more on the bones of this project a bit.

I wanted to get some color in, just so the project was easier on the eyes, as well as do some work so the enemy mechs could actually shoot back :)!

One thing i wanted to make sure was that this project felt good on a controller, and I developed a simple yet effective reticle friction system, just to make it feel a bit stickier to shoot moving targets. This was done utilizing a simple collision volume being projected from the player's camera, that turns the reticle red when its intersects with an enemy, and also greatly reducing the look speed on the thumbsticks. I tried to make this a tad stronger, but accidently ended up with what was functionally "Z-targeting" from other third person melee games, which I dont think was right for this game, but there's more time to iterate on that :).

Im quite happy with how it feels to play on controller right now for this early on, as I think aiming with a controller is something players dont regularly think about, they just know when a weapon or character feels bad to aim with, but not why it feels great in other games!

This system also made it incredibly easy to feed targets into Unreal Engines tracking component, so firing homing missles became a lot simplar as well!

Ill probably spend some more time next month wrapping this into a more complete game loop, I've really been enjyoing a lot of rouglikes recently, and there arent many Mecha roguelikes that feature Real time control as part of their combat design. Maybe theres some space there!

Update: October 2024

Now that i had more than rose tinted glasses to go off, and a some good points of feedback its time to tackle the aformentioned problems i had with mechassaults camera.

Weapon Projectile Framing
Reticle Placement
Sense of Weight

Iteration of Mechguy

Wow that already looks ALOT different, lets do some patch notes! Each of these notes should be in service in attempting to solve some of the problems from our first pass. Theres obviously more to do, but this is just one iteration.

Shifted the camera over the shoulder instead of centered, added the ability to swap which shoulder as well
Added some camera shake to the walk cycle
Added collision response to world environments while at high velocities (this shouldnt be killing the player but i thought it was fun to test with :))
Added a delay on jump press to jump (Note: This is my least favorite feature of those added in this pass, pretty quickly pivoted in week 3, as while this does make the character feel heavier, i think the delay between input and response was far too long at .25 seconds).

Update: September 2024

I have a LOT of nostalgia for the 2002 and 2004 Mechassault games for the Xbox. Giant Mechs shooting crazy lasers at each other, little Matt lost many hours in these two games campaigns. I felt the need to flex my design muscles, and thought I'd take a stab, and revisiting some of the mechanics and fantasies that these games offered.

So what exactly did these classic action games do?

First Iteration of Mechguy's Camera and Movement, based heavily on Mechassault

3rd Person Heavy Mech Combat

Going back and scrubbing through footage of these games lead to a lot of VERY important data points. The first thing to talk about here is the camera framing. Its actually pretty unique, but I found has some issues.

Weapon Projectile Framing
Reticle Placement
Sense of Weight

Weapon Projectile Framing

In the above gif, we can begin to see a bit where this camera and character placement begin to show some issues. For a combat focused game, framing of the action of Shooting is very important. Its one of the core pieces of feedback to player input. Players need their input to register in a very short period of time, and framing the character inside the camera in a way that allows the response to their input to be shown is critical. I believe in Mechassault, their framing causes their weapon's to feel unresponsive (Especially their projectiles). You pull the trigger, and you have to wait for the projectiles to move past the mech before you begin to see their velocity and direction. This is helped a bit by the VFX played on the arms when you do fire, but i imagine if these FX were removed, player sentiment around sluggish shooting would be heighted. Players perception is also pulled away from those VFX becasue they're forced to look up at the reticle, towards the top half of the screen, and the FX play towards the bottom half.

Reticle Placement

Again in the above gif, you may be able to notice the player misunderstand the Reticle once or twice. They launch the auto cannons while the reticle is pointing directly at the other player, but the projectiles head straight into the terrain. Its important (again for framing) that the reticle is above the mech in the way it is. Obviously the player needs to clearly see when their movement inputs are being responded to in the way of the mech turning and changing direction, but this comes at the cost of the reticle being slightly unreliably placed. This leads to some frustration, as players should expect that if their reticle is on target, they should be hitting them, and designers should prevent situations where your reticle is unreliable, as reticle control is the KEY expression of mastery in games where you have one.

A second thought on this reticle placement feeling awkward. In this situation, when players are enganging in shorter range combat. They're forced to pull their camera down to be able to aim at them correctly. This causes a large portion of their screen (and perception) to be pointed towards the ground, which the game dosent typically encourage and cuts yourself off from perceiving more far away combatants. This makes it difficult to make the decision of what to prioritize and make players feel a bit more chaotic and confused on the context of their current fight. Youre forced to soley focus on the mech closest to you. This isn't inherently bad design, but dosent quite fit within the fantasy and would maybe sit better in a melee combat focused game.

Sense of Weight

Thats enough gifs for now, but perhaps the core bit of feedback I have for this game is how the Size of these mechs actually feel to control. If you were to remove all enviromental context from the playspaces. would you be able to tell that these mechs were actually 3 stories tall? I think the answer is no. They move rapidly, they change movement velocity quickly, and aiming them is incredibly snappy. Theres not much going on from any vector to give these characters weight in their own bubble and gives the game a very action figurey feel to it. Again this isnt inherently bad, but I think there are some vectors they could have improved on to make these characters feel like giant 500 ton robots.

Despite these crticisms I still quite enjoyed the game, and based my first iteration (shown at the beginning) mostly off of Mechassaults characters. But I definitely want to tackle solving the problems of the three listed points I had.

Page updated

Google Sites

Report abuse