Dev Log 1: The Prototype
Here’s something I absolutely should’ve started sooner: a development log on the game I’ve been working on as a solo project since March 1, 2024.
As a high level, this is a top-down mecha action game being developed for PC in Unity. My previous project, Eon, was geared to be a third-person shooter survival horror game, but that quickly ballooned in scope to the point that progressing past the character controller and stealth system I developed was going to be difficult; thus Mechdivers was born (I know, I gotta work on the name). With rapid prototyping and aiming to have something playable as early as I could (something I achieved, might I add), this project has been an excellent test of my programming ability, game design intuitions, and generally planning skills as while I’m being very thorough and forward thinking on many design decisions, I have pushed back many decisions just due to them being trickier than just a preference. Some of the biggest hurdles I’ve faced have been learning ProBuilder for level design and generally learning level design, as well as designing enemy behaviours, and congruent yet digestible scripts that do everything I need them to without issue in specific cases.
Level design in particular has been tricky for me. Surprisingly, my time in university didn’t do a ton in this field, with the bulk of my experience being creating maps in Halo Reach, Halo 4, and Halo 2: Anniversary in the Forge mode. Without an Xbox Live membership and siblings that shared in my love of gaming I took to designing and building maps quickly, and I absolutely loved it. I remember needing to scroll through dozens of custom maps last time I booted up Reach, and despite most of them likely being not very good, it’s the experience I’m working with for this. ProBuilder is no Forge mode, but I’m slowly starting to get the hang of it more and more every time I use it. I’ve got a few level sketches which I’ll keep iterating on before bringing them to life, but in the meantime I’ve been recreating levels from other games to a surprisingly decent effect.
A very rough blockout of Grid 135 Cleanup from Armored Core VI: Fires of Rubicon (2023) [From Software].
Interactions with the environment are something I’m very passionate about, being an immersive sim fan and a lover of emergent opportunities, no matter how small, I wanted to build out the groundwork for different ways to influence the environment through gameplay. Physics interactions are something I’m still on the fence about, but destructible objects and explosives are in and they feel great. Explosive fuel tanks and large fuel silos that can be used to your benefit or detriment, and I’ve added shipping containers that I aim to have item drops from (that script exists too). Destructible objects opens the door for secrets, hidden paths and alternate routes, and generally a lot of creative design decisions, so I’m excited about the possibilities there.
Another big feature I’ve implemented are objectives. The Objective Manager handles things like the current objective, the HUD indicators, and is essentially a container that holds a list of the level’s objectives. Once again using Armored Core as a reference, I added several objective types such as destroying objects, waiting for a timer, activating objects, destroying all enemies in a list (or one boss enemy), and reaching objectives. All of this works seamlessly and is something I’m very proud of.
To wrap this up I’ll talk about one of the first things I added to the game: weapons. I knew from the get-go that I wanted to have a bunch of weapons and for this system to also work for enemies. Without specifics, I started planning out the technical aspects of the design. I decided early to limit the player’s weapons to just two: left hand and right hand, so first I had an identifier for which hand it’s in. In keeping with Armored Core inspiration, most builds in that game have missile launchers of some kind, and for those to function interestingly, I opted to make them shoot up first then straight down at the target. This meant that aiming the reticle would have more importance than just the direction being fired in, but it also meant designing how this would work. The bullet projectile type is simple, just being shot from the barrel in the direction of the cursor, stopping when it hits something to do damage. The missile projectile type however, required a bit more than that. I chose to automate a control point, around 2/3 between the player and the cursor, and when fired, the projectile would travel to that point directly at one speed, then use a second speed for travelling from the control point to wherever the cursor was when fired. Being completely honest, I initially wanted to shoot the projectile in an arc, but found that was a little too much work the given night I was plugging away at this, but I’ve learned to really like this method instead, finding that it gives it a certain dramatic edge (especially when the second speed is significantly higher than the initial speed). From there, I narrowed down firing types and which types would be needed. Currently I have single shot, burst, and automatic, with a fan spread being something I’m planning on getting in later down the road for shotgun weapons, but that might also be its own variable. Single shot does exactly as it says on the tin, burst shoots multiple projectiles on one trigger pull, and automatic makes it so that the player can just hold down the trigger for constant fire. Governing these speeds are two variables: cooldown trigger pull, controlling the time the player must wait before being able to fire another shot, and cooldown shot, the time between each subsequent shot in a burst or automatic fire. Bullets per burst controls the amount of bullets shot in sequence for a burst, nothing crazy there. Splash damage is where things get interesting again. Each projectile’s damage by default is based on impact, so if it hits, it does that amount of damage. However, enabling splash damage is essentially giving is a damage falloff over a set range. I chose to make this independent of the projectile types because I had the great and definitely not scope increasing idea of weapon upgrades, like explosive bullets as an example, so it’s a thing now.
Enemy weapons function almost identically, but with a few changes. I knew that I wanted more weapons and variety for enemies, so instead of the primary-secondary type, I left that out in lieu of being able to add several weapons to an enemy if I want to. Since the enemy in question that’ll use more than two is still being designed, that’s where I’ll leave that for now. Another big point of difference is in the projectile types; where the player only has ‘bullet’ and ‘missile’, the enemy weapon also has ‘melee’ and a very fun one, ‘self-explosion’. Basically, this uses the trigger pull cooldown value for a timed detonation that blows itself up. Using a separate ‘Detonate on Death’ script, which is also used for the explosive environment pieces, this simply kills the enemy and triggers its detonation. The other big addition is the movement speed multiplier when firing value, which is multiplied against the current enemy speed to slow it down temporarily when firing its weapon, which in the case of the bomber enemy, means that once the detonation is triggered, it will stay in one spot until it blows up. This could also be used to boost enemy speed when firing, so there’s lots of opportunities for fun enemy design I’ve left open.
Enemies are still a work in progress, movement behaviours beyond following the player being the biggest pain point right now, seeing as I’m very out of practice with more advanced AI pathing and behaviours, but I want to quickly touch on their combat related settings before wrapping up. Since I didn’t want to jump the gun and immediately start work on movement, I first made a few stationary enemies: turrets and mortars, using bullets and missiles respectively. To initially target the player and turn to face them, the enemies have an awareness range, and within this range they will activate their movement as well. Enemies also have a targeting range, which is then used for attacking. I will possibly end up adding additional ranges for stealth and detection, but for now and my purposes this works excellently. Enemies also have an option to randomize the start rotation, which when reloading the same sample maps for testing can make things more exciting. And one more thing to wrap up are item drops. Right now, that script suffers a lot from prototype code that needs to be rewritten, but functionally this works on both enemies and destructible objects, and it essentially just rolls a chance to drop either a repair kit for health, a primary ammo pack, or a secondary ammo pack. I did think about keeping the ammo separated by projectile type, but figured that having distinct ammo pools for the individual weapons would make more sense for the design of the game.
Now that wraps up my first ever dev log, not just on this game but for any game! I’ve been very excited about this project since I started and considering that I’ve only been working on it in my spare time, which that time is split between working on music for either myself or my band, and spending time with friends and family, I’m extremely proud of my progress already. Now let’s just hope I don’t forget that I started a dev log until the game’s out.
More design posts will be up soon, I’ve been split between doing one for Doom Eternal and Dishonored, but I think I’ve settled considering recent game announcements.
