I am posting this at the start of this week since I don’t know when I am going to stop production to start the evaluation and final video.
First goal this week is to make the unit limiter and mage unit so you have a full hotbar of units that work as intended.
Firstly I realised I forgot to make the summoner enemy actually summon things so I created this.
Which starts in the middle with a loop that picks between 3 units then spawns it at their location and sends a message to them to move.
When they spawn they get the closest location along the spline and add that to the the distance before it starts the same move along spline code as the normal enemies.
I then finished the mage unit which I created but did not implement. This unit will be the last unit I make and enough to fill the hotbar.
For the top path I Implemented burn damage like this:
Which gets the duration of the burn and divides it by 5 so that it runs in ticks instead of immediate damage the caculates the percentage to burn off including the elemental restistance and then applies it.
The lighting summons a projectile with only a Sphere collison inside which runs
I wanted to do some crazy maths or niagra system to make the lightning flash inbetween the targets but its not necessary so im not bothering.
The lighting just collides with the enemies and then depending on the chain amount applies the damage to the correct amount then destroys itself.
I made a win screen that is displayed when the wave code reaches 25 and instead of the start button it creates the widget.
And the buttons
To make the end screen I wanted visuals of the village houses being destroyed.
I then modled a low-poly house
The uvs dont perfectly fill the grid but since im hand drawing the textures I wanted to be able to know what way they are facing.
I then drew this basic texture.
Here it is in unreal:
The code for the loss condition is:
What this does is when a enemy collides with the end box it gets the enemies current health and subtracts it from the houses until the damage is used up. This means it can destroy all the houses immediately or only damage one partially. The map has 100 health split across 10 houses with 10 health.
I thought this was a cool idea so I made it.
When all the houses are killed if the code tries to run again (which it will if the damage is enough to kill the village) if the array is empty it displays the loss screen and allows you to easily go back to the main menu.
I added in sounds for the lightning, fire, income and spawning.
I might have forgotten to mention in other blogs but when a sound had too much empty space I would cut and smooth them in Adobe audition.
As you can see the yellow curve is the volume smooothing down and the white is the selection of audio I would cut out.
Obviously I wouldnt usually cut the part of audio I was smoothing.
However I can’t find any good background music songs and just realised when Im editing the footage I may speed up parts and the song would be distorted so I will just add them in post production.
I also successfully made the 1 hero per type limiter, although I only have one hero made so it just limits that hero to 1 place.
In the placement code I added:
Which locks the placement of new heros when placed and allows placement again when you sell it.
I mashed together a portal material.
I then drew a tiling stone texture.
I had to multiply it in unreal to make it a bit darker.
I then drew currency and essence icons.
I then drew the icons from the placeholder image I randomly stole besides 1 which I will reference in the bibliography.
Firstly I created the price numbers above the units with a similar widget to the damage numbers but with a different animation and setup.
In the widget it has:
In the placement code I added 3 tiny bits of code to incorporate the price within the placing.
This gets the price of the unit during the placement code and sets the cost to be used in the loop where the unit moves to the cursor and checks if it can be placed the whole time.
Within the loop this code below simply checks if It could minus the cost and not go negative, then enable the placement if it could.
Within the placement onto the map code I added.
Which minuses the unit cost (Im using a previously created function but no unit costs essence to place and minus 0 essencce has no effect) and then updates the upgrade UI so that the upgrade buttons display properly.
I then created a upgrade cap because because I manually input the values in a table and therefore if its over the max the value would just be unset or for unreal[0].
Firstly I check for the values setting themselves back to 0
In the text for the upgrade I added which sets the upgrade to a unachievable price (I hope).
Finally in the upgrade button it displays Max instead of the high number and I also fixed a bug with the essence price not disappearing when its empty because it technically still equalled 0 instead of being empty. So I cheked for it starting with 0 instead.
I then made the sell button with a button on my upgrade screen
And the function it runs is:
Which gets the unit price (determined by the stat table since it adds the price of the upgrade onto the placement price) and simply adds it back then deletes itself.
I also just added a tiny bit of code that I left space for in my ‘Z to cancel placement’ code that runs the same function if you use the shortcut instead.
I then started to add some sound effects for the game.
The SW files are the raw files from pixabay, occasionally slightly cut and softened in Adobe audition.
Within the SC files I usually do something like this where I get the SW files and match the volumes so some of them arent way louder then others then add extra variation to them by having a range that the pitch can choose from.
Implementing them Into buttons is easy as I can simply just add them in.
And within blueprints, it is just as easy tho sometimes I might need to go searching between the blueprint interfaced functions to find where I want to put the sound.
I then finished planning the wave structure and enemy stats
And then from this table I implemented what I didnt already have into unreal.
These values are not final as I haven’t fine tuned the spawn intervals and delays to my liking.
I then factored in the damage resistance to the attack maths and also made the damage numbers more customiseable with prefixs and colour.
As you can see in the bottom image the colour is different for the explosion.
This Is what I tweaked in the damage number to account for this.
I then created a system to check if there is a upgraded range and then display the upgrade range when you hover over the upgrade button. I split the code into 3 images.
A summary of what it does it get the current range and next range then if they are different display a new range that previews it. The end is just some visual fixes to make it not glitch when you then press upgrade and there is a new range it will switch to the new range or hide itself if theres not.
I will show a preview of this in the video at the bottom of my weekly blog.
I then fixed the bars to properly display with the path and level and also block out the wrong path instead of closing it.
As you can see the top path has 0 levels and is closed and the bottom path has 2 levels.
The black square on the right is there for If I had time to create a visual change for each upgrade, the icon would also display a drawn icon of the upgrade change.
I also fixed the text to say other path selected and max path:
I made the grey out by changing the detection code to change boolean instead of hiding and showing the widget
Then in the module it shows or hides the darkening overlay based of the last code.
I want the widget component to be visible instead of not hit testable since I want it to stop the players ability to click below.
Then to set the upgrade buttons to the right level I run this at the start of the widgets construct.
This sets the colour refernce from a green and grey styled indicator then sets the indicators to an array in the right order to be used in the script below.
This gets all of the indicators and sets them to grey then depending on the level of the clicked units sets them back to green with the amount being the corresponding level.
The max text is set by which simply runs when it detects its maxxed.
And in the normal unit widget the second path also runs
I then created the money making units in which I thought of two ways to do.
My first idea was to get the amount of groups in the wave then multiply the end of group income with some maths to make sure it generates the same amount after every group spawned.
I planned it fully out but didn’t reallly like how the intervals would be un-even.
I then realised that I was already getting the group amounts why don’t I just get all of the info from the table and calculate the wave time by multiplying the amount of enemies by the spawn interval of the enemies.
This image above is the core of this math where I add together the spawn timings and delays to get a total wave time then divide this by the essence sales that wave (+1 because it waits then fires the generation code so to have 3 even intervals I want it to be every 25% of the wave ignoring the last tick since the wave would have ended)
Before the core is this:
This just determins wether to calculate how many intervals to do based of the normal math or time taken for you to place it in the level. This is so if you place a unit during the end of the wave of half way through the wave they will all generate the same amount of ticks as the unit from the start of the wave.
So simply, if you have good timing you can place one at the start of the wave and miss 0 ticks. If you place it mid wave you will miss a few ticks of generation and if you place it after the last tick would have fired you miss all of them for that unit that wave.
Obviously after the wave end it revert to the normal generation code and will run at the same times of the units with the same path.(1 path generates larger amounts of cash slower where the other generates smaller amounts faster [meaning they tick differently but will still limit correctly])
This is the mid wave code just after the the core code.
Then just after that the actual money tick runs:
This gets the current essence amount then checks whether it could sell the essence for cash and not go negative, If it would go negative instead of selling the correct amout it will sell whatever the current essence is * the sell price (if its 0 you wont gain any cash).
Then finally it checks whether it has done enough sales for the wave (since it technically would try to do a 4th one at the end of the wave from the timing code) and stops the loop when it has done enough.
I will add a video of all these systems I created in the weekly blog.
Firstly I opened the main menu level I created when I first made the project and but the quest board model in it.
The model in which I created in blender with array modifiers and mirror modifiers.
And textured within photoshop, though I did not bother to draw anything other than a flat base colour, as I have discoverd I do not particualirly enjoy texturing and modeling compared to creating mechanics.
I then created a placeholder widget for the quest selection
I then had to work on the actual unit selection logic. I did not create a plan for how I would do this in my plan although I did create a diagram for how I wanted it to look. So I started off by creating the base UI.
Then I created the functionality from there, starting with configuring the units.
Currently Ive only implemented 4 boxes, but you can see how Its easily scaleable for the future
I can simply set the cream image to a image of the info of the unit and the white image to the icon then the boolean “is hero?” will determine the colour of the icon border, staying black when I havent configured the unit yet.
Here is the function from the second image upwards and also the rest of the code within the unit displayer. Which enables click detection and also the selection toggling visuals.
And here is code that recieves the click from the displayer and also sends the toggle function back to it.
The functions at the end of this code are run in the hotbar.
They check the array of all of the hotbar widgets then find a free one and set the icon and unit to spawn. The array is simply all the widget references put together.
The bit of code at the end numbers the hotbar to be correct with the 1-5 key inputs in the game level.
I additionally added a bit of code to remove the unit from the hotbar if the player decided they wanted to press it there instead of from the unit displayer toggle.
Then to start the level I had to use a game instance to save the variables of units and icons that the hotbar had gathered between levels.
It pretty simply just sets the values so I can access them again in the next level.
The start game function at the end simply opens the next level and could be removed for just the open level node.
When the next level is loaded, the hotbar checks If it is the correct level then if it is, loads the stats from the game instance.
This then allows the corresponding units that you selected to display the correct icon then be placed in the game if the icon is clicked.
The First person character also does this before running the rest of the game level code so that the units can be placed from the 1-5 inputs I created in the previous devlog.
As it now has the reference from the game instance to spawn the correct unit.
Im going to create a assorted features blog since most things I do from now on will be random as I find/ think of things to fix/ add.
Firstly I made the inputs for the system being, 1-5 to place from the hotbar, CTRL to bulk place and Z to cancel the placement. I also had to adapt the selection and clicked code to incorporate clicking to place and not hovering over units that are already place while placing a unit.
Click to Open in Fullscreen
Below is a zoomed and updated bit of code within the placement system:
I created this to stop a visual glitch in the range indicators when a unit is already selected and you place a unit.
I used that to create the detection and the actual location to spawn the unit to.
This runs inside of the Parent unit to display the overlapping hitboxes of units in the way of the placement and also to gather the references of obstructions like the road the enemies walk along which will stop the placement and use the code in the image above to change the material to the correct colour
This code is mildly confusing (atleast for me writing it) as it runs half of the code within the unit thats being placed and the other half in the units colliding with it. Firstly ity checks if the road is being collided with, which runs universally in all BP_Unit children but since the placed ones arent moving it doesn’t actually run in them. Then it checks if the component touched is the collison box of the unit and if it is, is it the unit being placed. This code is then not running in the active unit but in the placed ones, since if the overlapped unit is the placed unit its sets its collision to red and adds itself to the obstruction array disabling the placement of the unit. This creates a cool effect of displaying which units are blocking your placement and also when u can place.
I will include a video of this in next weeks blog since the placement system wasn’t fully functioning without the unit selection systems UI input.
Firstly I created the selection system using my flow chart plan on the main unit 8 page.
Click to Open in Fullscreen
I created this in my player blueprint so that It wouldnt be run by the indivual towers and cause problems, however I still needed the actor references of the clicked/ hovered units so I created this in the unit parent.
The main code uses some of these functions to animate the range:
And also this simple function if you noticed a odd looking node in the main code, which gets the needed component references from the actor reference provided to it:
Here is a preview of the selection system functioning and integrated with the Upgrade UI I will make later in this blog.
Now I need to create this upgrade and stats UI…..
UI modules created, Ui set to show and update correctly, stats reworked, starting stats being transferred to ui.
Success in stats to ui, success in upgrades to ui
Kill count and upgrade button colouring when affordable success
Stats displaying properly, unit is upgradeable and closes other path
I firstly created these widget modules that I could put into other widgets like the button to the left.
Then put them all together in the main panel and created a sliding animation for it to appear on screen.
I then created a system to detect what the Unit clicked type was (hero or not) and display the corrcet modules in the main panel correctly.
To do this I had to re-work how I configured my unit stats into a table so it could be easily read.
I only created 3 characters at this point of writing so my table is small. But as you can see it stores the data for each level of the unit when a stat is valid.
I created headers for a ridiculous amount of stats, almost all I could ever need when im creating new characters in the future, though I didn’t properly intergrate stats that were obviously not going to be used yet. I Left a note on functions I would need to update when adding new characters.
I added this chunk of code into my parent unit to get its stats from the table instead of me manually inputing the variables. This also allowed for the Unit upgrading code to be a simple addition to the level then re-running the stat gathering code.
This set the correct widgets to display when needed, and also hides the other path when upgrading a non hero unit. However In future I want to ‘grey-out’ the other path instead of collapsing it but I havent messed with how to do that yet.
Then how I got the UI to display the current stats and also the upgrades is a midly long chain of events.
First where I left a note in the very first image in this blog I put the this function below and above to get the stats then show the panel.
These stats are then set to variables or text in the upgrade panel UI
Further along it then runs what I have called a “upgrade calculator”.
Click to open in fullscreen
This basically runs a loop based of whether it needs the hero module, or the 2 normal unit modules. Then in this loop it gets the stats from the table and uses another function to calculate if there is a change between a stat in the current level and the next level.
This function is one that will need updating and formating based on each new upgrade I add.
It also runs more functions which format the arrays of floats into indivuald strings that then get turned into displayable arrays to send the upgrade widget modules.
Additionally I need to add more formatting like seconds or meters to the range but that Isnt difficult to do so Im just putting it off for now. I actually did format the stat widget module currectly so I do know its not to hard to do.
These then send these stats to the individual upgrade modules which is why there is so many lines at the end of that full screen image.
The upgrade modules then run this to get the values indivual lines of text instead of an array of strings
The split string functions being ran are
Which pretty simply just split the strings onto individual rows then set the text box.
The update Upgrade button function send the stats to the upgrade button of that module and runs this:
Which just formats the values to to text and shows the Essence price if it isn’t 0.
To format the button colour to be red when you cannot afford the upgrade and green when you can I created this.
This may be incredibly messy since I don’t properly understand all of the slate brush nodes but this works so I don’t really mind.
Then also so the button actually functions and whether it can be upgraded based of the colour, when its clicked it runs this.
The function names that it runs is pretty self explanatory but I might aswell show the ones that arent already shown in this blog already.
When the enemy is killed it runs this function which updates the UI if the unit that killed the enemy is actively displayed otherwise it just adds to the indiviudal kill count variable of each unit.
I Still need to create the targeting button and sell button but that might have be in next weeks blog since I am going away for a week starting tomorrow.
Here is a preview of how everything currently functions
Another thing to fix in a later week is capping the ugprades at there max since currently it will upgrade past its cap and reset all the stats to 0 then allow you to spam the upgrade button for free. If i added a upper cap then this would stop.
I firstly continued my unit planning and finished planning 3 units with their 2 seperate upgrade paths of 5. They are relatively balanced with each other and the strength of the enemies although the heroes wil still output alot more dps for a higher price.
I then started the production and created my first devlog to show the progress of creating my own camera system.
I then created my enemies and wave spawning system in this blog. Later in the week I also created damage numbers, health bars and simple deletion on death.
Though I did not use any of them or watch them fully since they were quite long.
I firstly I created some general float variables for the unit stats:
I then created a Collision sphere for the Range of the unit and created a simple piece of code to set the float range to the actual collision radius correctly.
I then experimented with targeting and decided on creating an array to list all enemies in range so In the future I can choose between them for targeting and this may help with chain/ splash damage effects I may create. They also remove themsleves when they leave the range or are killed so that there won’t be any invalid targeting.
One of the events ran by the array code above is:
While this isnt fully integrated with the future UI button that will switch the target between “last/ first/ strongest/ Weakest”, It runs a function in the enemy to send its current stats:
Which I then gather and can use and send the updated health after applying the damage back to the enemy
I quickly realised this was very inefficient though and replaced it with these 2 functions:
(in the Unit)
(in the enemy)
I then tested with creating the pop up on hover but didnt get It functioning properly before I got distracted with re-writing the attack code, so I will write about it next week.
I then re-wrote the majority of my attack code twice and came out with this:
Click to Open in fullscreen
Which functions esactly how I want it accounting for attack speed like I planned on my unit 8 page.
In future blogs I will probably create one called “upgrades” or something alike, in which I will work on the pop up upgrade UI I mentioned starting before and also create the actual upgrade system, ticking off another key feature I need to create.
