Games [Tower Defense][RTS] Deterrence - Devlog

A tower defense mixed with real-time strategy where you repel attacking sentient AI robots until they give up.

​

Pseudo Gameplay
You'll have an object to defend just like most other tower defense games and there will be secondary objects to defend, landing zones. If you lose a landing zone, you won't necessarily lose the game, but they're important because they give you $upplies! $upplies will be used to purchase defenses, units, upgrades, repairs, and call in off map strikes such as air strike, artillery strike, and tactical nukes.

​

$0 Budget Terrain Textures
Making textures for terrain is pretty straight forward work, but I found that getting pictures of the ground on an overcast day is best. The overcast allows for the ground to be lit and have no shadows. Next part is the guess and check work, find the best photos and make them square while keeping an eye out for anything that stands out which would make textures look repetitive. Whatever photo you take, you'll always have seams when you put them side by side; I found a nice online tool that will make your textures seamless here.

​

An Easy RTS Pathfinding System
This easy pathfinding system I've put in the game is very similar to Dijstra's algorithm. The unit will move on a grid. The unit will test for a collision with a block before moving to the next grid point. The unit can only rotate to 1 of 8 directions that lead to neighboring points.

​

The whole path is mapped out in a single frame within a loop. With this method you can see the path without traversing it and see the distance of that path made. Next I added four different rotation patterns to plug into the pathfinding method: Always clockwise, Always counterclockwise, starting with counterclockwise and alternating, and starting with clockwise and alternating.

​

Of the four paths made, the one with the least points is chosen. And finally, before the unit begins it's journey, the path is refined by getting rid of junk points. This way, only key points without a block between them exist.

​

If you would like to follow me on my game dev journey, don't forget to subscribe or follow on social media!

Facebook - https://www.facebook.com/DeterrenceGame/
Twitter - https://twitter.com/DeterrenceGame
Instagram - https://www.instagram.com/deterrencegame/
Discord Server - https://discord.gg/CjAybsdq
IndieDB - https://www.indiedb.com/games/deterrence

 

Destructible Trees
I opted not to use Unity's terrain trees for this game because the terrain tree colliders didn't work with my units pathfinding system. Instead, I just used game objects for trees which also gave me more freedom to do what I want with them.

​

To make the trees destructible, the trees have a reference to a destroyed tree prefab which inherit the transform of the tree that instantiated it. The destroyed tree prefab has a rigid body for physics and a script with an explosive force scenario to play out.

​

It is also a good idea to put trees on they're own layer and disable the trees from interacting with the block layer in the physics settings. This way you don't get trees that collide with the invisible block layer.

Easy Bump Mapping
To get the desired look for my landing zone tent, I went with a solid color and a height map. A height map is a gray scaled texture where white represents bumps. I use the brush free handed and then soften what's been drawn to make the bump more smooth. This texture can be imported into Unity and converted to a normal texture through gray scale.

​

Now that the LZ model is complete, I import the LZ model into unity to see how it looks. After adjusting all the materials, you can now see an awesome looking tent in Unity.

​

 

Modeling the CH-47
The most important part to modeling the chinook was reference images. Without them, the model would be have incorrect proportions and I wouldn't have gotten very far.



To texture the chinook, I tried the high resolution model method since I didn't have an actual chinook to capture pictures of. The high resolution model method will have all the finer details of the model created with geometry, then I would render an image of that model to paint on the lower resolution game ready model.



Making the propeller blades a separate object was important for the spinning effect I would add later in Unity.



To finish up the chinook, I took the color texture and began to change the RGBA channels for metal, smoothness, and a gray scaled normal map to be interpreted by Unity.




Modeling the Soldier
This was my first character model ever, I learned quite a bit and actually impressed myself with this one. I thought texturing the soldier would be incredibly difficult, but the method I used was simple and powerful. I would create the shapes I wanted to paint on the model with an image editor. I used those images to paint the color and height textures. They turned out pretty good in Unity.



As this was my first rig in my life and in Blender, I had to a bit of trouble getting the bones to work. If your character is built with one half and mirrored, then you should know that the bones on each side should have the same name (case sensitive) and end with .L or .R for their side. Also, it's a good idea to add a few more loop cuts to your limbs to prevent them from folding completely flat.



Unit Select Ring
The unit select ring is bascially a projector. If you've ever tried this, you'd know that Unity has a standard asset package that comes with projector shaders, and you'd know that those shaders aren't for opaque images. In order to get the projector opaque, I took the light projector shader and changed the blend to "SrcAlpha OneMinusSrcAlpha" and commented out all the fog related code. The trick to using this shader is to know that opaque black is transparency and all color data to be drawn is completely transparent.



RTS Drag Select
You're probably thinking drag selection is as simple as just testing if the unit is between the Xs and Ys of the rectangle, which would work if the rectangle is not on an angle. In this game, the camera can rotate 360 degrees and tilt 180 degrees making the drag select programming a real drag. With the help of an online search I was able to get it working with a very awesome math technique you can find here.



It works like this: you find the area of the rectangle using an uncommon formula that works for any rectangle at any angle.
Rectangle Area = 0.5 * Abs|(yA−yC)⋅(xD−xB)+(yB−yD)⋅(xA−xC)|



Next you use the unit coordinate to make four triangles with the rectangle. If the sum of all the triangle areas are equal to the the rectangle area, then the unit is inside the rectangle.
Triangle Area = 0.5 * Abs|(x1(y2−y3)+x2(y3−y1)+x3(y1−y2))|



If the unit was outside the rectangle, then the sum of all the triangle areas would be greater than the area of the rectangle.

 

​

Prologue
This is my first time implementing RTS unit movement and I am no expert, but I have learned the basics that hold true in many AAA RTS games. Most of the information I go over in this devlog can be found here and here.

Performance
The RTS unit pathfinding method can destroy a games frame rate if not used wisely. Having a large group of units and having each unit in that group use their own pathfinding method to go to the same place is a performance killer. Also there may be units that find an alternate route making the group split, which may not be what the player wants. This problem is simply solved by designating a leader. The leader would find the path and all other units will use the leaders path.

​

One factor that can adjust the pathfinding work load is the spacing of grid nodes that units move on. By increasing the spacing, you are effectively reducing the amount of processing power to find a path between the unit and the destination; by doing this, you also sacrifice pathfinding in tight spaces. The RTS map and pathfinding grid should be made with each other in mind for the best performance.

​

Unit to Unit Collisions
The pathfinding method will only take into account the terrain and structures the unit must move around, but since units are constantly moving and changing positions, their collisions are calculated as they move along their path. In this game I implement a collision prevention check to stop units from walking on top of each other. To make it work, each unit has a priority based on their distance to their goal. The unit closest to it's goal will be given the right of way.

​

There are also instances where I would allow units to pass through one another when getting into formation. I also tried resolving collisions that were not prevented, but that would result in a huge chain reaction of collision resolving in a tightly packed group. From the research, the best way to handle unit to unit collision is to have a grid that all the units shared to predict and resolve collisions with one another.

​

I'm just settling with my single collision prevention method for now since this game is a tower defense at it's core and this is my first time implementing RTS style movement.

Formations
Formations are important to allow units to flow in a group and prevent units from having the same destination point. A well thought out formation should take into consideration the terrain and structures by forming around them without splitting the group.

​

 

​

Handling Enemy Units
The easiest and most optimal way in my opinion for player units to check for enemy units in their surroundings is for player units to have a static list of enemy units to check distances with. When an enemy is created, it will add itself to the list and vice versa. If the enemy is in range for a unit, then the enemy is added to the units local 'enemies in range' list. Further layers will be added to prioritize what enemies to attack first.

​

Player unit movement will take in an additonal variable storing the command given by the player. With attack move, the unit should pause it's path to engage enemies in range before finishing the path. And with a regular move command, the unit should finish it's path before engaging any enemies in range.

​

Heads Up Display and User Interface
I've decided to go with the old fashioned bottom heads up display that most RTS games use. The tricky part about using this with Unity's canvas was the scaling. Using the expand with screen option would work for the heads up display, but the drag select would be thrown off.

​

So I opted to just keep the canvas at a constant pixel size and wrote my own scaling script that also keeps the aspect ratio of the canvas elements.

​

A* Pathfinding
The A* pathfinding tutorial by Sebastian Lague can be found on YouTube. There were a few modifications I've made to the script to fix some issues I've found with A* pathfinding. I noticed how the A* pathfinding would fail if the target node was an unwalkable node, so I made a quick method to search for a nearby walkable node to find a path to. This way if a player commands units to move towards an unwalkable cliff, the units will still move to the general area.

​

Another problem with the A* pathfinding is islands. If the start or end points are surrounded by unwalkable nodes, then the path will fail. Determining if either one is on an island using a flood fill method can be expensive on the CPU depending on how large the island is.

​

One can simply try to solve this problem by finding islands when the grid is created at the start of the game, but that still won't find islands created by the player building walls. If anyone has any solutions, let me know

Sebastian Lague A* Pathfinding Tutorial - Here

 

​

Adjusting Paths for Unexpected Obstructions
To finish the pathfinding for units, units needed to find their way around buildings. Not just at the moment the path is created, but also during the path's execution to account for buildings created by the player after the path was made.To make buildings work with the pathfinding system, the buildings had to be grid snapped to the pathfinding nodes, and buildings width and length will be measured in whole nodes. For instance, this small bunker is one by one.

​

The pathfinding system was expanded to include a second buildable layer for units to find paths around. As buildings are built, the pathfinding grid will be updated and vice versa.

​

Units were then programmed to look for buildings between themselves and their next path node. If their path was in fact being obstructed by a building, the best way around it would be to find a new path which was expensive on the CPU. To limit pathfinding calls, buildings were listed for having already been accounted for and if the unit was in a group, the unit would notify the leader who will find a new path for the whole group.

​

In the case that an area is completely walled off and the pathfinding fails, a second pathfind will be made ignoring buildings and that path will be truncated where buildings are found. This way, units will still have a path towards the walled off area; solving the issue of islands with an extra pathfind instead of other more
CPU intensive methods.

​

RTS Minimap
I found a really simple tutorial on how to make an RTS minimap in Unity by Alessandro Valcepina. At first glance, I thought that using a second camera for the minimap was a lazy and CPU intensive way to do it. But it turns out with the correct settings, this was a simple and light weight way to build a minimap.

​

I expanded on the minimap to register clicks and convert the minimap coordinates into game world coordinates by simply using proportions. With this, I was able to make the minimap move the camera anywhere on the map with a simple click.

 

​

Landing Zones
The landing zones are now selectable and have the ability to collect supplies and units from chinooks. The landing zone UI will show two groups of items. The left group shows the items currently on the chinook and the right group shows what items the chinook will pickup upon return. When the player wants units, the units will be added to the pickup list. Any blank space will be converted to supplies when the chinook returns for pickup. Players can also cancel units by simply left clicking on their icon in the pickup list.

​

Unit Selecting UI
Unit selecting UI will be work like traditional RTS games. Selecting a single unit will give an in depth look at the unit and selecting multiple units will show icons with healthbars for each unit selected. When multiple units are selected, you can select a single unit by clicking on its icon in the UI. At this time, the UI can only fit 20 unit icons, so the limit of units that can be selected at once is 20.

​

User Interface
The RTS user interface uses a lot of components including drag select, heads up display, minimap, and command menus. Having all these components work correctly in any resolution while keeping their aspect ratio was challenging in Unity. Having the canvas scaler do the scaling would interfere with the drag select working with the mouse position and the aspect ratio couldn't be kept.

​

So I wrote a custom scaling script to attach to each component. The proportional scaling was as simple as multiplying the original dimensions by the new resolution divided by the native resolution. To maintain aspect ratio, the orginial dimensions are multipled by one resolution axis and then adjusted towards their anchor. This script works for all the common resolutions, but for 21:9 and 32:9, the script will simply use proportional scaling.

To make the minimap, I used this tutorial by Alessadro Valcepina. To expand on the minimap to register clicks, I simply checked if the mouse was hovering over it by checking if the mouse was within its rectangle and if the mouse button was pressed. I did not use Unity's event system for the user interface because only one component can use the event system at a time.

​

At the current moment I am not using sprites for the progress bars and health bars, so I don't have the option to use a fill method. Instead, for the fill bar I set the pivot to 0 (left) and use the width to increment. Later, I will definitely give them sprites for good looks and make the coding much easier.

 

​

Sandbag Walls
Sandbag walls will be basic early game defenses that can be built by all soldier units. They will have the ability to garrison 2 soldiers. I'm also thinking about adding the ability to upgrade the sandbag walls with a mounted machine gun to buff attack and double layered bags to buff defense or hit points.

​

Constructing Buildings
Building construction will be done by soldiers. Basic buildings like the sandbag walls can be built by any soldier, but more advanced buildings like bunkers and towers will only be built by engineer soldiers. Buildings can have more than one unit constructing it to speed up production and units can stop building at anytime the player chooses.

​

Building UI
Buildings will have the same stats as units shown. Buildings will inheret the attack and range of the units that occupy it or the building could have an upgrade that buffs a stat(s). For instance, if a building has two general infrantry units occupying it, then the building would have their range and attack x2; defense and hit points are not inhereted. Buildings will have a garrisoned units section where you can see the icon of units currently garrisoned in the building, and the player can left click on those icons to ungarrison the units. The building command menu currently has 'ungarrison all' and 'attack' buttons. The building attack button will command all garrisoned units to target a specfic enemy unit as long as the enemy is in range.

​

Making Units Construct Buildings
The build command works like the move command. The placement object will give the selected unit(s) the build target. Once the path is complete, the unit will switch to the build animation instead of the idle animation. Each unit will call the build target's build method making it possible to have multiple units to speed up construction. The build method will simply progress using Time.deltatime. Once the time reaches the buildings build time, the building is complete.

​

Making Buildings Garrison Units
Buildings have a capacity variable that determines how many units can be garrisoned at once in the building, if the capacity is larger than zero, the UI will display the garrisoned units section. Buildings will have a list of units it holds and assign each unit a position for each slot. Garrisoned units will have their colliders disabled to prevent selecting; and while garrisoned, all code except the enemies in range check is disabled and the unit follows specific instructions for being garrisoned.

​

 

interesting

 

​

Engineer Soldiers
The engineer soldiers will be able to build advanced buildings. They're equipped with shotguns that make them short range so they won't be very good in most combat situations. The supply cost on engineers will be high so that the player should strategically guard these units.

​

The soldiers will all use the same soldier model, but have different equipment for different stats and to tell types of soliders apart. Later I may also amend the textures to differentiate the soldier more.

​

Bunkers
The bunkers will serve the same purpose as the sandbag walls. They will do everything the sandbag walls can, but have more hit points and defense. These buildings will be considered advanced and can only be built by engineers making them mid to late game defenses.

​

UI Cursor
In addition to the cursor changing for move and attack move commands, the cursor will now glow when it's hovering over a selectable unit or building.

 

​

Unit to Unit Collisions in Unity Software
To mimic Starcraft 2 unit collisions, I gave the units capsule colliders and rigid bodies. In the unit code, I would adjust the mass of the rigid body so that moving units have greater mass than standing units.

​

By adding physics to the units and allowing them to nudge one another, this created problems with group movement. In many cases, units would be nudged so far from their path that a block would come between the unit and its next node causing the unit to get stuck. To solve this, the group movement was modified so that node offsets are much closer to the leaders nodes, box and sphere checks were used instead of raycasts to find blocks between nodes, and instead of simplifying the path, all the nodes are used to keep units on path.

​

Towers
The tower will be a mid to late game defense like bunkers, but they will lack in defense. The towers will instead give units a range bonus. I plan on towers having upgrades to their structure like steel, and concrete to boost their hit points and amount of garrisoned units. Also towers should have the ability to add a mounted machine gun just like bunkers and sandbag walls.

​

 

Simple RTS AI
To get enemy units moving, I created a simple enemy controller that acts like a player (aka artificial intelligence). The enemy controller will need to move groups of units all around the map, so a nested group class is needed to give commands to separate groups of units.

​

In order for the AI to tell these groups of units where to go, points of interest would need to be laid out on the map or defined in some way. Since this is a tower defense game, the enemies need to move towards the objects the player is defending. The enemy movement will use the same pathfinding as player units.

​

To add depth to how enemies move, the points of interest on the map are connected together in a waypoint system. This way, enemy units can have paths with multiple points of interest or paths that approach a point of interest from another direction (flank). The enemy controller will simply tell each group to move on to the next waypoint once the current waypoint is reached. If the current waypoint is a Landing Zone, then the group will wait until the landing zone is under enemy control before moving on.

Capturable Landing Zones
The landing zones will be a very important part of the game. Landing zones will be where the player gets supplies and calls in more units. The landing zones won't be able to be built by the player nor will enemies be able to destroy them; Instead, they'll be control points. A landing zone can be under player or enemy control, or be neutral.

​

Control works like most control points in RTS games: Units must be present at the control point to capture it. A landing zone with both enemy and player units on it will be contested and there will be no transfer of control. If units are moved away before the transfer of control is complete, control will return to the current team or fall back to neutral.

​

In the case that an enemy gains control of a landing zone while a chinook is delivering, I am still contemplating what to do. If you have any ideas, let me know in the comments.

 

​

Using Unity Animation Events
Since the enemy robot's animation shows the unit firing twice, I decided to also use events for each fire animation that would call the enemy unit's fire method. This gave me a lot of wiggle room to make units shoot in different ways and also made it very simple to calculate unit DPS (Damage Per Second). So, I decided to make player units follow this structure as well.

​

Calculating DPS using Unity animations required grabbing the RuntimeAnimatorController of the units Animator. With the RuntimeAnimatorController, I can find the fire animation by name and then simply use the animation length and number of events in the animation.

​

Unity animation event functions don't support methods that have multiple parameters, so, to get around this, I made a method with a string parameter and pass multiple parameters separated by a comma in a large string. With this trick, I can use animation events to spawn diverse enemy groups at any start point in the level. Doing it this way will make it easier to build levels by using the animations like event timelines and using the extra functionality that comes with animations.

​

Starting To Feel Like a Game
Now that enemy units can deal damage to player units and buildings, and can move towards points of interest; Play testing is now starting to feel like playing a game. I'm starting to balance stats and list of functionality to implement is dwindling. The game is approaching an alpha stage and by my estimate I believe there will be an alpha version of the game within the next 2 months.

​

 

maybe the 2 realtime lights in that robot, is a bad idiea

 

I have it set to baked and only to light up the Unit layer and gave it a small range, but I'm not exactly sure if the light is actually baked because it does light up other Units in real time...

I'm not aware of any other ways to make fake lighting.

 

​

Outline Objects in Unity Engine
I found a really simple tutorial that outlines game objects on specific layers by Will Weissman that can be found here. But I didn't use this method to outline my RTS units because it very basic and there is no way of knowing if an object is obscured. Will Weissman's method would be for simple point and click or FPS game objects.

​

I needed an outline method that would only show outlines when the unit is obscured by other objects. I managed to find a free package in the Unity Asset store. Quick Outline has 5 different outline modes and one of them was exactly what I needed. You can find the Quick Outline asset here.

​

Game End
I tried to make something like Starcraft 2 end prompt. For now, the menu will have three options: main menu, retry, and quit; regardless of the game end condition. For a defeat, the camera will focus on the primary building to defend so the player can watch it collapse as the end game prompt transitions into view.

​

Command Menu Info Boxes
When the players cursor hovers over a command menu button, an info box for that button will show. The info boxes will show the command name, command type, cost, etc. The info boxes will be using a color code and have a standard order to make them legible at a glance. Later I will have info boxes change color and info dynamically to show unmet requirements for a command such as insufficient supplies.

​

 

​

Building Damage
Same as when a building is under construction, building destruction will change meshes to show damage and have 2 phases. In blender, I use the knife tool to cut holes in a copy of the building and fill them so that they crater. The new model will use the same material, I simply take the newly made faces and remap their UV coordinates to an area that makes sense. Alternatively you could also find a blank area on the UV map and paint a specific destruction texture.

​

Building Destruction
When it came to destroying buildings, I thought of how Company of Heroes buildings would collapse into rubble. I chose this concept over Starcraft's approach to just blowing them up because I'm going for some realism. The building collapse needs 2 pieces: An animated building falling and a particle system for dust. Once the building reaches zero hit points it will spawn the building collapse and rubble. The dust particles will obscure the building so that it gives the illusion the building is collapsing into rubble.

​

Making Textures for Buildings
I found that pattern textures such as brick, sheet metal, and other sidings don't work well with the seamless texture tool I found, but it works great with dirt, grass, mulch, etc. You can find the seamless texture tool here.

​

Surprisingly, making brick and other sidings for buildings can be done with simple free tools. All that's needed to make them look good is a height map. To help with height maps, I use Project Dogwaffle version 1.2, a freeware version of Project Dogwaffle. You can find Project Dogwaffle here. It has a lot of great features, but is really old.

​

Another awesome tool that helps me with digital art is Artweaver. Artweaver is free to use and has a lot of awesome features like layers and editing photoshop files. you can find Artweaver here.

 

​

Additional Unit Behavior
Units needed a way to automatically attack their attackers if idle and alert nearby friendly units if they're idle also. I'm referring to the same behavior as in Starcraft 2; those units would run towards their attacker automatically. This would make management easier for the player and the units would behave as if they had a brain. Although there may be scenarios where the player may not want this behavior, so, in the future I plan to make a hold position command.

​

Tweaks and Polish

• Unit fire animations no longer use lights and the muzzle flash graphics were enlarged.
• All units garrisoned in a building now have the same origin for detected enemies in range.
• Changed the texture color of the engineer to make the unit more distinguishable to the player.
• Chinook rotor blades now have motion blur.

​

Unit Deaths
To complete the units, I added a way to instantiate game objects that would represent their death. Each death object was given a transform from some part of the unit instantiating it. Doing it this way would allow me to make many different ways a unit could die to accommodate all types from mechanical to biological units. For soldiers, they would instantiate an object that would play a death animation and instantiate a weapon that would use physics gravity.

​

For robots, they instantiate body parts that use physics and instantiate an explosion that gives the body parts an explosive force.

​

 

​

Custom Terrain Shader
I don't know how to program a shader, but thankfully Unity has a package to make shaders in a GUI environment called Shader Graph. To start off, I needed to recreate a standard terrain shader in shader graph. I managed to find a tutorial on how to do this in shader graph by Léo Chaumartin here.

​

Once I had a complete terrain shader, I could add and edit it to stop textures from repeating. First, I added a procedural noise to blend with the final result of the textures. This would give the overall terrain light and dark areas.

​

To get the textures to stop repeating, I needed to rotate the UVs of each individual tile somehow. I managed to find a shader graph tutorial by Ben Cloward called infinite hex tiling. I followed all the instructions of his tutorial and I was left with a bunch of sub graphs that I used to replace the UV and sampling nodes in the terrain graph.

​

Water Shader
There are many water shader tutorials out there, I decided to go with PolyToots tutorial that can be found here. To make my own normal map asset for the water, I used the freeware version of Project Dogwaffle. In Project Dogwaffle, I rendered a black and white plasma noise, then to make the tiling seamless, I ran the texture through a seamless texture tool, and finally, I imported the texture into Unity and converted it to a normal map through gray scale.

​

 

​

Making Trees for an RTS Game
Real-time strategy games have a lot happening on screen due to the view from above. In order to have a bunch of game objects on screen at the same time, the level of detail (LOD) needs to be low. I started with CG Geek's low poly tree tutorial which works fine for mid level detail, but not low enough for a RTS games because the game would be unplayable with many of them on screen.

​

The performance is terrible mainly due to the leaves being transparent textures which take more processing power to draw. In order to fix this issue, I needed to draw less transparent textures. In order to draw less transparent textures, I would need to make the tree branch texture bigger to cover more area. Then I made a new branch by combining planes at different angles together into one object.

​

The resulting tree had much fewer vertices and branches, but still gave the tree enough foliage. I can now have the screen filled with these new trees and still maintain a frame rate near 200 FPS.

​

Laying Doodads Faster
Populating the game world with a bunch of environment doodads can be painfully slow with the traditional drag and drop prefabs method, I really need a tool to get this done much faster. I found a cool toolkit tutorial by PitilT that makes prefab spawning much easier. At the moment it's very basic, so I look forward to more tutorials by PitilT to expand on toolkits.

​

 

Making Trees Optimal
Continuing with CG Geek's Low Poly Tree tutorial from last week, we learned that the tree as is - is not optimal. The performance problem lies in how the tree is being rendered. When the tree is imported into Unity, the tree has hundreds of child objects for each branch and each object requires more processing power. I found that when combining meshes into one object, performance was better. So, the amount of vertices does not have as much of an impact on performance as the amount of meshes.

​

To make CG Geek's Low Poly tree "Game Ready", I found a way to instantiate all of the particle system branches as real objects. Then I would combine all objects together as one mesh. Now, when the tree is imported into Unity, we get one object that takes two materials. Performance is now optimal since there are much fewer draw calls.

​

Making Useful Tools for Development
I expanded on my prefab spawning tool to give it all the features I need to build maps faster. I found a really awesome four-part lecture by Freya Holmér that's jam packed with info on how to build tools in Unity. I turned my simple one click tool into a fully featured painting tool that works with the Unity Editor.

​

 

Environment

​

My aim for the environment is to be as realistic as possible to the best of my ability. Since this is a solo project and I'm not a graphics expert, this means I'll be shooting for double 'A' standards. The environment at this moment can be destroyed, but the behavior of the destroyed objects is limited, and newer behavior will be added towards the end of the project as it's not a priority to get the game to a playable demo. This log pretty much marks the completion of the nature assets and I plan on adding man-made environment assets such as utility poles, houses, fences, roads, etc.

​

Creating Nature Assets
To make the foliage textures for my plants, I used a colored construction paper as a green screen and press the leaves under a book overnight to make them flat as possible. The flatter the leaves are to the paper, the easier it will be to remove the background color because there will be no shadows. Also, the ambient lighting should be filtered for the same reason and to reduce glossy surface light.

​

To make the textures for the terrain, I took photos of the ground around my house. It's best to do this on a cloudy day as the ambient light will be filtered. Next, I would crop the photos so that they are square and run them through a seamless texture tool that can be found here.

 

​

Modeling Destructible Bridges
To make the bridge models, the bridge dimensions must have an aspect ratio compatible with the pathfinding grid nodes. Scale can always be fixed later. To create the destructible bridge, I copy the original model and cut it up using a knife tool. It's important that the destroyed model and original model have the same origin, scale, and UVs.

​

Once I had my pieces for the destroyed bridge, I separated them by selection which created 2 objects (meshes). And finally, the newly created objects have holes that need to be filled and once filled, the new faces needed new UV coordinates.

​

Programming Destructible Bridges
In order to create pathways across unwalkable rivers, each pathfinding node needs its own block collider so that the bridge can edit the nodes it resides in. To make this easy, I simply had the pathfinding grid add these blocks for each node that was below sea level.

​

If units were present on the bridge at the time of destruction, the destroyed bridge will destroy the units referenced by a collider that records units touching it.

​

Finally, the destroyed bridge will change its mesh to the destroyed bridge mesh and instantiate the broken piece at the same position and rotation. As long as both models have the same origin, scale, UVs, and positions, the transition will be seamless and appear to break.

 

​

Man-Made Environment Assets
To give the game world a lived-in feel, I added more man-made assets like utility poles and houses. These assets can be destroyed like most other doodads on the game field. Houses and other civil buildings will be useful to the player as soldiers can garrison them for cover.

​

Indie Legion Feedback Fest 1.5
I will be working on a simple level in preparation for an alpha demo to submit to the Indie Legion's Feedback Fest. You will be able to find the alpha demo for Deterrence on itch.io sometime between September 8th and September 17th.

​

Healthbar Shaders
I started this week with shader tutorials by Freya Holmér and found a tutorial on making a healthbar entirely in shader code. I thought this would be good for unit healthbars on top of units on the field. To make the shader work for that use case, it also needed to be billboarded, so, I found another great tutorial on billboard shaders. And finally, to make these healthbars work, they needed to always draw and also have a render queue above the unit outlines.

​

 

I won't be posting here anymore due to all the "Access Denied" error messages. You can find the devlog over at indieDB.