Objective

  • Stop enemies from reaching the red cube.

  • Each wave enemies will progressively harder.

    • HP going up ++

    • Movement speed ++

  • Player will be able to place defenders on platforms.

  • Defenders placed will spawn in as 4 normal heros.

  • Player will have the option to:

    • Upgrade weapons of defenders.

    • Upgrade defenders to Hero.

      • This must be implemented before placing on platform

  • Each defender have their own unique advantage.

  • Defenders will also get additional ways to upgrade other then just damage.

  • Bonus resources: based on chance, ex. 4 of the same defender units spawn.

Normal fire and range

Rapid fire and short range

Slow but powerful and huge range

First Level (First Iteration)

Gradual Changes

Completed

  • Transparent platforms.

  • Removed unit selector, units will be random.

  • Platforms register as green by hovering over platforms where you can place a unit.

  • Platforms register as red when you hover over a space that has a unit present.

  • Start wave button disabled during wave spawn.

  • Refactored and cleaned code.

First Level (Second Iteration)

Adding URP
  • Learning curve with how delicate the settings can affect the game visuals.

  • Adjusting Bloom Intensity and Threshold.

  • Note: customizing and creation of VFX involves a strong skill-set with Blender and Unity VFX.

First Level (Third Iteration)

Issues with 3D Top Down Health-bars

Direct camera angle

Angled camera angle, slightly shift left

Game play example

Sometimes trying to implement ideas and features from 2D, into 3D can be harder to implement.

Problem 1

Health-bars are not facing the player.

The problem we are facing in our 3D design comes from our top down camera, our camera sits stationary facing downwards at a slight angle, shown in Ex. 1. If we add a health-bar to our enemy models and press play, we can see the enemy health-bars are rendered, but are always facing in front of them.

Solution

Pivot health-bars towards our camera for player readability and consistency.

Ex. 2: No Rotation towards camera

Ex. 1: Camera angle facing downwards

Problem 2

The health-bars are misaligning to the enemy model.

The reason this happens is because our models are in the cameras peripheral view, where the health-bar is rotating itself out of place towards the camera because of the angles getting extreme enough to pivot out of place.

Other problems we have are, when the model is placed underneath the camera, the health-bar ends up covering most of the model.

Solution 1: We will be instantiating a health-bar object onto our camera (canvas) window instead of instantiating the game object attached to our models with their own canvas.

Solution 2: Create a 3D health-bar instead, less complex, possible that if tastefully done, will improve overall user experience. I ended up searching a couple 3D samples, will be unable to share here due to copyright laws. Idea is the health-bar is curved around the front of the model. Another idea is having a health-bar that is circular around the model at the base. Will have a couple drafts ready as I learn blender for this.

Solution 3: Create a different indicator instead of a health-bar. Ex. colour of model turning duller as they start to run out of health, effects like pebbles from golem start to crumble off.

*Solution 3 is inapplicable because tower defense is a game of calculations and balancing resources wave after wave. Solution 3 makes it hard for us to gauge the enemies health pool and get a definitive measure of their health if a couple enemies get through.

*Edit: Solution 4: Pi curves to automatically create a smooth curve from point to point.

Solution 2, Quadratic Bezier Curve

Health-bars need adjusting, but it looks way better then before

Health-bar curves are adjustable by our three points

Health-bars are rendered at spawn time graphically using a line renderer with a simpler form of Bezier Curve Algorithm.

For more information check out my "Learning Unity" page.

More information about Bezier Curves

Solution 4: Pi for Health-bar

Instead I went with the Pi methodology of using radians with sine and cosine to map out a consistent flow of points, using a line renderer to plot a line following those points.

For more information check out my "Learning Unity" page.

Upgrading Our Defenders

*Reverting back to spawning single defenders, but still random

Now when you build defenders, instead of 1 selected defender, you will build 4 random defenders on one spot.

I added this feature to spice things up, I remember playing games where random defense was a feature I really enjoyed and changed the way I played helpings the game feel fresher each time giving plenty of replay-ability.

I will be implementing different tiers of defenders.

1 resource = 4 normal defenders, upgrades to weapons won't be as significant or impactful.

1 resource in leiu + 1 resource to build defenders, will spawn super defenders, where the weapon upgrades will have a better multiplier. But they will only spawn 3 defenders, meaning you might be unlucky and spawn 3 quick shooters, which are short range. Might be impactful on the level depending on where you situate the spawn.

Idea so far is: (range, damage, fire-rate)

  • Normal defenders (17, 15, 1)

  • Quick defender (12, 25, 1.4)

  • Long defender (25, 40, .5)

The defenders will need tweaking and balancing.

#TODO: find a structure to hide the prefabs in, or have the defenders smaller and spawn side by side. I personally like the structure more, as side by side does effect the range of the defenders ability to shoot.

Ideas for adding more defenders

  • Defenders that slows units.

  • Defender that pierces units in a straight line.

  • Defender that powers units in their vicinity, this could be fire rate, range. This defender will not be random but apart of the upgrade component.

Defenders 2.0

Normal Sniper

Normal Assault Rifle

Hero Assault Rifle

Hero Sniper

Used a blend of some assets on Unity marketplace, using a prefab and animation local of the mecha, added on a VFX where the bullet prefab is spawned, we call the VFX just before instantiating the bullet prefab. The result is below.

Hero Sniper, locking on and shooting

Hero Assault, locking on and shooting

Hero Handgun, locking on and shooting

Normal Handgun

Hero Handgun

Shop Side Bar

  • Created images for "Hero button" for a better result then text buttons.

    • Extracted the images from prefab units and edited the images using GIMP.

    • When button is pressed, it will check if the player has at least 1 resource, taking 1 resource from the total and highlighting the image background to green for confirmation the next unit built is a hero. Otherwise the background will stay transparent.

  • Upgrade weapons opens up a new windows.

    • Working on the direction I want to take the upgrades with. In progress.

  • Menu and lives image was created by Dall-E, cropped, edited then added to our unity button.

    • Menu button pauses and opens up a new window with options, back, music volumes, etc.

    • Images created main keywords were "retrostyle," "synthwave."

  • Game speed controller has been added to speed up the round.

    • Speed controller is on a toggle system, colour green indicates to player what setting their on.

  • Menu, exit window implemented.

    • Menu Button pauses the game and opens up a menu to audio settings, "Back" and "Quit" Button. All the other controls are disabled.

  • Special Forces & Heroes are on a toggle.

    • Whichever image is displayed is what is being built.

    • System checks if player has sufficient resources to build. If not, a distinct audible sound that they cannot build due to resources is played.

  • Upgrade weapons

    • Checks if player has enough resources.

    • If player has enough, the clicked button will turn green and play a satisfying blacksmith clunking audible.

    • Else, the clicked button will register as red and a distinct audible sound the upgrade did not go through will be played.

Version 1
Version 3

Main Menu

Main Menu
Audio Menu
  • Sliders are adjustable, they directly effect volumes of the sound.

  • "Master," "Music" and "Effects" are buttons and can be pressed to mute instead of adjusting slider.

  • The settings are saved when the "Back" button is clicked and loaded onto main levels.

Audio Menu In-Game
Objective Menu
  • Added audible and visual confirmation for users to verify in their choices to increase user experience.

  • Visually I made the graphics change in a subtle manner, *Note: the subtly was what made the most difference vs' obvious.

    Found obvious change and confirmation took away from user experience. Small and subtle confirmation to relay to user this is your choice had a greater impact.

  • Visual and audible cues to relay to user the choice they are about to make helped by eliminating second guessing if they are slightly off the button or not.

  • No added visuals for clicked, you cannot show visually without lagging the process. Found more satisfaction in snappy response, and the screen that appears after you've clicked should be enough visually.

  • Conclusion: Huge impact on user experience as something trivial like a main menu should be intuitive, easy to use without frustrating user before they even play the game.

Settings are saved on "Back" and "Quit." For later levels and even applies to the main menu.

Main Menu
Version 2
Version 1

Audio Menu

Audio Slider Balancing Adjustment

Had issues regarding audio control sensitivity from the sliders.

The sliders from 80 to 100 had the most impact on the sound produced, making the rest of the slider ineffective.

As our sound controller on the back-end works with DB -80 to 20 (the game is capped at 0 db, past that and the audio quality won't hold), and our slider returns a float value from 0 to 100.

We can consider using if else statements for the values returned from the float of our slider and convert them via slope equation,

y = mx + b

We can use x to represent slider value

  • x1 = 100

  • x2 = 50

y to represent the DB value

  • y1 = 0

  • y2 = -24

Using rise over run we get the value of

  • m = 12/25

Now when we use y = m * (slider value) + 100, we will get a range that will return 0 to -24 to set our audio controller.

Encouraging Player Engagement

Fun meaningful player engagement where they can make direct impact is what keeps a player to continue playing.

Even if the game is based on luck as its initial function, I can create mechanisms for the player to use as a tool and increase their chances for suitability, creating a higher level of engagement.

Ideas to implement and test

  1. Engage diverse game-play to play.

    • Player has different ways to play, or are forced too adapt to new changes and challenges

  2. Increase luck factor.

    • Ability to permanently increase a special spawn?

    • Ability to temporarily increase a special spawn?

  3. Have linked defenders.

    • Give resource bonus?

    • Increase damage?

  4. Added Feature: Heroes cost 2, Specials cost 1 giving players a choice in spawning weaker defenders but with a higher chance to spawn a unique defender and gain extra resources.

  5. Every level a random node is picked that gives players a higher chance to receive unique defenders.

    • The node that is picked will not always be convenient. Players will want to find ways to increase ways to make this ability more efficient. We can build off this by making the bonus nodes up-gradable.

      • Misc upgrades can increase the number of nodes spawned per wave.

      • Misc upgrades can refresh the nodes x number of times per level.

  6. Break up nodes into smaller categories, where one full node (parent node) will host 4 smaller nodes (child nodes). Player will then get set bonuses based on same units per parent node.

Enemies have

  1. Varying speeds.

    • Players cannot just stack one area as enemies have a chance to whiz through.

  2. Armour on higher level enemies.

    • Players can't just infinitely place defenders and encourage upgrades.

    • If the armour > damage, the damage they receive will default to 1.

  3. Invisibility, will keep it here for now as an IDEA.

    • Personally don't like this feature in tower defence, feels lazy and forces players to play a certain way (must create certain number of defender that detects invisible enemies, or must create a sensor tower that detects invisible units for all defenders, which completely takes away from the invisibility feature as it just counts as an additional resource the player must make, which really falls on the game developer as we need to balance out that additional resource.

  4. Flying units.

    • Same idea as invisible units.

    • They are significantly faster in movement speed. The visuals are a good indicator to players

What I want the players to experience

  1. Player could make improvements with defender placement.

  2. Questioning decision to upgrade or place heroes instead.

  3. Surviving, but not too easily and not making them feel helpless in their decision.

  4. Fast paced, to overwhelm players in their decision making but not completely. Faster paced also makes the game more encouraging and bearable for replay-ability to try different strategies.

Game balancing is proving to be difficult, as I don't want the game to feel boring and static, I want a bit of excitement and provide engagement to players.

Solution

Found the feel of the game is significantly better when you aren't constantly having the difficulty in a static fashion. Found the game feels the best with a push pull method. Where you push hard one wave to bring the player to progress in upgrades, number of defenders, etc. Then back off, by raising the difficulty only slightly from the initial push, giving them breathing room to build and regroup themselves.

Constantly stressing the player does not make the game fun, whereas pushing the player into challenges, followed by them overcoming obstacles and letting them regroup building a stronger system, makes the player feel accomplished and fun.

Defenders In-Game

Version 1
  • Originally it was hard to tell which defenders were spawned and to quickly know at a glance how many specials or heroes you had.

  • So I made the models pop with colour and platforms that differentiate from special forces to heroes, making it much easier for the player to identify at a glance.

  • Added colour coded text format.

    • First letter indicates if its a "Special Forces" or "Hero"

      • S = Special forces

      • H = Hero

    • Next set indicates the class

      • SG = Shotgun

      • SF = Sniper Rifle

      • AR = Assault Rifle

      • HG = Handgun

  • To further make it easier to identify the skins from special forces and significantly different to the heroes.

  • Heroes will also have their platform change and glow to indicate to user they are a more advanced defender.

  • When placing heroes, the platform will also glow a different colour then the original, letting players know they are about to spend double the resources to spawn a hero.

Finished Product

Finished Product Ver 2.0