Tank Rush - My First Game - In Development

[keen shore]

Command your tank! Charge onwards to rescue your allies! But immovable boulders, destructible crates and exploding oil drums block your way! Maneuver your way around the obstacles, smash through them, or blow them to smithereens with your gun! Can the front lines depend on you to rescue them? Or will danger put a stop to your charge? Rush on, and triumph!

-Dedicated to my cousin Marcus, who loves tank games.

I've prepared an MVP sketch of how I'd like the game to work. Two notes on it though:

1. The sketch is top-down but the game will be 3D. I made the sketch top down because it was much easier with the software I was using, and it also gives a good view of how the path will work.
2. The coins feature will not be a part of the MVP, but is a backlog feature to introduce incentives to replay the game. I added it in the sketch though because I wanted to reserve the top right space for the eventual coin UI which will populate it.

[keen shore]

I've developed primitives for the player, environment, and key objects. Some notes of mine:

• The tank object is similar in dimensions to an M4 Sherman.
• The obstacles will be oversized relative to what their real life proportions would be. This is so the player can see them easily.
• Looking at the width of the environment, I decided that the tank should not rotate, rather it should move horizontally. Otherwise navigation might become too difficult at high speeds, especially if you can fall off the side. I'm thinking of making it so there are three horizontal positions to move between as you move forward (like in Temple Run).
• If player crashes into a rock, which is immovable, I'm thinking of making the tank back up before the player regains control, because I don't want the tank to move horizontally with no forward movement. It would look terrible.
• I think the tank should have five gears, each gear with its own speed, rather than have speed being a float variable with player controls affecting acceleration. I'm imagining it where the player controls will shift the tank between gears, determining the speed. I'm not sure whether there should be acceleration within the gears, and you can only shift up once you reach top speed for that gear or not. Acceleration within gears may be too complex for what I'm trying to build.
• If the tank has a gear based speed system, there should be a gear UI (probably located in the bottom left of the screen).

[keen shore]

The basic movement controls attached to the player have been developed. I'm very happy with it, the movement looks super smooth and deliberate. I have a few notes on this:

• Movement is similar to Temple Run in that there are three horizontal positions that the player moves between, with player input choosing which position to move to. Player movement input will be through the a, s, d keys.
• A Vector3 Lerp was used to manage the movement of the player. I came across this function through some Googling and it took some time, but I got the hang of it. Lerp will set a Vector 3 movement equal to the distance between two points within a specified time frame. The movement speed is generally distance divided by time.
• Because moving to the center is half the distance of reaching the far side, the player movement speed was slower with the Lerp because it still tried to reach the center in the same time that it would reach the far side. Therefore the speed to reach the center was halved. To make movement speed consistent, no matter where the player wanted to move to, I wrote an if function to test if the player was moving to the center, and if so, the movement speed was doubled.
• Because the player positioning is constrained by the three horizontal positions (and the space in between them), which I defined in a public variable, there will be no need to program any rules on bounds, or set up physical boundary walls. This is already done implicitly through the movement design. The planes on either side of the player in the video will later show background scenes, but they won't be needed to stop player movement.
• I first thought I would have the player moving forward, but I now think it will be better to have the player still and have everything else moving back, to create the illusion that the player is moving. I will later need to figure player input into the movement speed of everything else.

[keen shore]

The player forward 'movement' has been developed. I'm impressed with myself that I've managed to successfully execute my gearbox idea.

• The player itself does not actually move forward. The environment moves towards the player, creating the illusion of forward movement.
• Player speed is determined by which gear they've selected. The gearbox is an array of five gears, each gear having its own fixed speed. An upward scroll of the mouse wheel will shift up gears, and a downward scroll will shift down gears.
• Player controls are very easy to manage with a mouse and keyboard setup. The controls are presently the a, s, d keys (operated with the left hand) and the mouse wheel (operated with the right). The player will not need to move their hands, only their fingers, to operate the controls.
• The speed of the player is not realistic for a Sherman tank. Top speed is 112 mph, but an actual Sherman will max out at 29 mph. Speed will be optimized later once the environment scaling has been optimized. When the speed is lowered to accurate numbers, I'll shorten the distance between the waves of obstacles, so there will still be the same time between obstacle waves.
• The tank looks too small relative to the city around it. This is a compromise made to quickly prototype with premade assets. I want the city to surround the player, but simply enlarging the textured planes on either side will only make the buildings look too big relative to the tank. I will ultimately need a texture that shows a taller city, with more stories, so I can stretch the planes higher without the tank looking too small. This is not a priority for prototyping at the moment.
• Next steps from here are getting the background to loop around the player (by having it periodically reset its position), and creating a spawn manager for the obstacles waves.

[marble umbra]

I mostly sifted through but w game, one piece of advice, I simply move the tank and loop the position of the tank but then again, I'm not very good at unity lol

[keen shore]

I had seen one example where they looped the position of the background, and thought I’d copy that. I guess it really depends on what the most computationally efficient way to do it. I actually just had an idea about how to loop the tank, and it’d be really simple to implement. Thanks for the suggestion! I’ll have to try out both ways.

[keen shore]

Implemented the following:

• Looped background to create the illusion of an endless charge onwards.
• Created war fog so that the player only has a limited time to react to oncoming obstacles (plus it disguises the resetting background, which would otherwise be visible).
• Added a gun firing mechanism, whereby the player uses the spacebar to fire the gun.
• Scaling was bothering me, so I doubled the tank placeholder size and obstacle sizes so the tank doesn't look too small relative to the background now.

The work isn't done yet, though. I still need to resolve:

• Bullet collision. When the bullet collides with an obstacle, it should destroy it. I've been having issues getting the OnCollisionEnter() method to work. It works correctly for the bullet itself, which will destroy itself on collision, but I'm having issues getting obstacles to destroy themselves when they are hit with the bullet. I'll need to research the method further and work out what I'm doing wrong. After some debugging, I know the issue is with the method itself being not called, and not anything inside the method.
• Player collision. The player will be able to collide with the objects. The crate and oil drum will be destroyed upon collision with the player, but the boulder will not. I'll get to this once I've resolved the bullet collision issues.

[keen shore]

I'm glad to be back to game dev now that I'm back from my work trip. Super busy weekend. Whew. But now, I've resolved my use of the OnCollisionEnter() method! Yay me. Obstacles are now destructible by the gun.

The OnCollisionEnter() method would work from the bullet script but not the obstacle script. I just moved the Destroy() to the bullet script and wrote it to destroy the bullet on collision, and only if the other object in the collision was one of my obstacles, then I'd destroy the object the bullet collided with.

Next step will be managing what happens when the tank itself crashes into the obstacles. When it hits the boulder, it will back up before allowing the player to take control again. When it hits the crate, the crate gets destroyed. When it hits the oil drum, the oil drum is destroyed but player gets damaged.

TLDR: The gun now destroys obstacles that it shoots. Next up, code what happens when the player crashes.

[keen shore]

Rushing to get this project done before the Christmas holiday. Just wrote in crashing.

The tank will now crash into the obstacles. If it crashes into a boulder, it will be stopped. If it crashes into a crate or an oil drum, it will be slowed down to first gear.

Next step will be adding the timer based mechanics for what happens when the player crashes. The player should reverse for a bit (about 3 seconds) if they crash into a boulder. And presently, the shift to first gear after crashing into a crate or oil drum is permanent. The effect for only last for a bit (about 3 seconds).

[keen shore]

Made big strides today:

• Obstacles will spawn randomly in one of the three lanes at regular intervals. You can now charge onwards for eternity.
• Player now reverses for a bit after hitting a boulder, and the slowdown effect of crashing into a crate or an oil drum is only temporary.
• The gun takes ten seconds to reload after firing it.

Next steps:

• Implement difficulty scaling with obstacle spawns. The further you go without a crash, obstacles will spawn at shorter intervals, and more will spawn at once.
• Implement an acceleration system, so speed scales up over time within a gear. At the moment, with instantaneous upward gear shifts, high speed doesn't feel earned. Nor is it realistic. I expect I'll have the speed automatically increase within a range over time for each gear, and only once max speed for the gear is reached, will the player be allowed to shift up. Downward gear shifts will be allowed instantaneously.

How I'm feeling:

• I'm pretty happy with how the mechanics are coming together. I've been more ambitious in my execution than I expected to be when I was planning. It still needs refinement and fine-tuning though.
• Just dodging and blowing up stuff seems a bit boring. In Temple Run, you also could collect coins. Perhaps I should implement coin spawning too? How aggressive the player wants to be in coin collection can also add to the difficulty.
• I'm really going to have to put some effort into this project the next few days if I want it done before Christmas so I can share it with my cousin as a Christmas present. I haven't done any of the sound, animation, SFX or UI yet and this will all need to be done. Realistically, I'm not sure if it will be done in time.

[keen shore]

Lots of major milestones achieved today, plus some minor improvements to things which had been bugging me.

The wins:

• Difficulty scaling. The game will get harder as you progress further. Obstacles will spawn more frequently, and in higher numbers.
• Game over states. The player will reach a game over state by destroying their tank or stalling it. To destroy their tank, the player must first collide with the oil drum, which strips away their armor, making the tank vulnerable. Without armor, any crash will destroy the tank. Generally, it's harder to avoid oil drums and crashes when you're going fast. This is a punishment for going too fast and not slowing down when you need to. To stall the tank, the player must crash while in bottom gear. This is done to discourage players from going too slow, making it easy to avoid the obstacles. Going slow is risky, going fast is risky.
• Acceleration system. The player will now accelerate in each gear, and will only be able to shift up gears once they reach max speed for their current gear. Playing this now, high speed feels like I earned it, and it is also much more of a setback to get slowed down by a crash, because it will take time to build up speed again.
• Graphics update. It's finally time to do away with the primatives. I've used some free assets from the Unity Store, but most of these will probably be placeholders. I'd like to develop my Blender skills and model the tank, as well as the obstacles myself. I'll probably stick with 3rd party assets for the background, road, audio and SFX.
• A little thing that had been bugging me is that I never really liked using a, s, d to control which lane the tank was in. I just wanted two keys, a, d to move left and right, which is a much simpler design. I made the change and now I can shift up and down gears using the w, s keys. The result: the game is now playable with one hand. This just feels easier to play now.

Next steps:

• It's time to add in the audio and SFX. This'll make it feel much more immersive and like a proper game.
• This game is screaming for UI. I really want to know what my speed is, what gear I'm in, how much longer until I can shift gears, as well as whether I have armor or not. I'd also like a counter for how long I've travelled (this has been coded in, but I want it displayed in the UI).

I'm feeling really proud of myself. When I'm testing the game, I'll sometimes just get invested and keep playing the game just to see how far I can go. This is a super positive sign for me, but I'll want to test with players to see if they feel as sucked into it as I do.

[keen shore]

Exciting additions! I've started adding the audio and VFX. Firing the gun feels satisfying now. One of my early testers drove the tank slowly just so they could blow up as much stuff with the gun as they could.

• Smoke and fire effects when the gun is fired. Plus a smoke cloud when something is blown up. Things don't just magically vanish anymore. They get blasted to bits!
• Audio added for firing the gun, trying to fire when the gun is reloading plus separate sounds for crashing into the crates, oil drums and boulders.
• You can now hear the tank engine. It gets higher pitched the higher your gear is. This also helps as an important audio cue when you've changed gears, because the engine will sound different.
• Background music! Epic battlefield score!

Audio and VFX aren't done yet though. Still have to fix the following:

• Need to wipe out the instantiated smoke once the animation has finished playing. Some of my smoke is instantiated with the script that wipes it active (and this gets dealt with properly), but the second type of smoke instantiates with the script inactive. I have no idea why. I'll work it out.
• Want to have an explosion sound when stuff gets blown up, plus I want the smoke to linger a bit. It doesn't do this at present, even when coded in. I think the issue is that the audio and particle effects are being linked to the bullet or object, both of which are quickly destroyed, so there's nothing left to play. I think spawning an invisible object in place pf the blown up obstacle to hold the audio source for the blowing up sound plus the smoke effects will solve this.
• This is starting to really, really scream for some UI. I want to know what gear I'm in! I want to know if the gun is ready to fire!

Best played with audio.

[keen shore]

Two big things:

• Placeholder voice acting has been added. The tank is randomly assigned a commander personality, which determines which voice lines to use. There are three distinct commanders, each with their unique lines. As a placeholder, I provided the voices for all, making the recordings in Audacity.
• VFX has been improved. Smoke remains for a bit after blowing something up or crashing into something. This was done by instantiating a smoke effect upon collision, with different sounds depending on whether it was blown up by the gun, or crashed into (and each object has its own crash sound).

One little thing: there was a bug where the crash sound was distorted when the tank crashed. I fixed the bug. Put the audio playoneshot commands in the wrong part of the script (update function lol, it started a new instance of playing every frame, no wonder it was distorted). The code to play the crash audio is where it belongs now (in the actual crash methods outside of the update function).

Next step is UI. I've been saying this needs UI for a while. I'm just going through the Unity Learn tutorials on building UI at the moment, and once I'm done with that, I'll add the UI to Tank Rush.

Once Tank Rush has UI and a main menu, I'll say MVP is done!

video is better with audio