Week Five

Week five was where I started making the artefact itself. Quite a lot of the coding in making the mechanic will be adding information to the screen so that I can show it off easier.

To start off, I decided to get the main groundwork for the mechanic set up, which involved sorting out how I’m going to inflict this debuff in the showcase video, as well as the damage part of the bleed debuff itself. Despite being the main part of the mechanic itself, the DOT of the debuff will actually be one of the easiest parts to code due to the fact that it’s just messing about with variables (something I’m used to).

The first thing I did was make a new Unreal project using the First Person shooter demo. This is because it comes with a pre-built shooting mechanic that I can mess about with and turn into a demo of the enemy itself. Although the enemy would be a melee character with no ranged capabilities, I felt it’d be easier to show off the mechanic using a ranged weapon.

I changed a few things in the player character’s blueprint, the first of which being how they shoot. It originally had an input event for when the left mouse button was clicked or if the screen was touched on a touchscreen (i.e. a phone), after which it would start the shooting animation and fire the gun. I decided that the animation wasn’t necessary for the demonstration of the mechanic so I got rid of it.The original firing blueprint

After this, I set up a way for the first person character to automatically fire so that I can showcase the mechanic more easily. I set up a custom event loop with a 1 second delay as this is a tried and tested way for me when it comes to repeated actions like a DOT effect.

After setting up the gun that causes the bleed effect, it was time to set up the damage over time itself. I made a cylinder enemy and set up a bunch of variables so that I could set up the the groundwork for the mechanic.When the gun is created, start the auto-firing

This is the start of the custom event loop

The end of the custom event loop, where I can set the rate of fire. 

After this, I set up the basic DOT loop in the newly created cylindrical enemy using the bleed stack variable to decide on the amount of damage dealt per second. I decided that 0.5 damage per bleed stack each second was a slow enough value as a start, but due to health values in TWS:T, it may need to be lowered to the 0.01-0.1 range.

This is the way the custom event loop is started. The Bleed Active variable ensures that the bleed loop doesn’t activate more than once, which would probably cause issues. 

This is the full blueprint needed for the bleed damage.

I then went about putting in a quick way for me to see if the bleed is working, so I just added some floating text above the cylindrical enemy to show me how much health it had.

The number above the cylinder shows the total health of the cylinder.

This is where I finally noticed my first problem. Despite thinking that the code would work perfectly, the health wouldn’t go down. By putting in print string nodes in various places, I noticed that the bullet didn’t even register overlapping with the enemy’s collision box.

As it turns out, though, it was just a dumb mistake on my part as the collision type for the cylinder was set to ‘block all’, rather than ‘overlap all dynamic’, which meant that the bullet was just bouncing off of the cylinder without activating the bleed debuff.





Week One to Three

As week one of the blog is actually three weeks into the semester, there is actually three weeks of work here. In those three weeks, I’ve found a lot out about the game itself and the history surrounding it. I have also gone through several iterations of my idea, before landing on my current idea (which I’ll get into at the end).

The vast majority of gameplay I watched was from a channel called Many A True Nerd, who’s a big fan of not just the total war franchise, but strategy games in general. In addition to this, he has a classics degree, so he knows a lot about the history and mythology surrounding the era the game is set in. In fact, his video on the Aeneas campaign was probably about half history facts, with occasional sections of gameplay in-between.

He currently has around ten hours of videos on the game if you include his four hour livestream on it. This gave me plenty of footage to watch over to get a general sense of how the game operates and what features may be beneficial to the game.

This is the first Video Many A True Nerd did on TWS:T.

Most of his history and mythology explanations are at the start of the videos and he talks about how they differ in-game, which gave me a lot of insight into the way Creative Assembly creates the units themselves. For instance, he says that the myrmidons were a civilisation of people who were turned into ants by zeus. He notes that they clearly don’t have six legs, quite unlike the ant people they were based on, but they do have an immunity to losing any morale at all, which is one way the game sprinkles in some extra strategic options for the player. From watching these videos, I felt as though it’d be best if I stuck to these small unit-specific features as these are the ones that add the majority of the strategy in the game.

As a fan of the Total War series, he goes through some of the changes between the games in his videos. For instance, in his first video he says that light infantry are ‘like small bipedal horses’, as there’s apparently a huge difference in unit speed when compared to other games in the series, where foot unit speed was less varied. He then goes on to explain that this makes sense as the game has a larger emphasis on flanking than in other Total War games. This influences him to use light infantry and chariots to run around the enemy and flank them.

As for deciding on an artefact, I went through several iterations of the idea before landing on the one I have now. To start off, I thought of making it so that arrows or thrown spears stick inside whatever it hits and makes the enemy slowly bleed to death because of it. I felt that this would add a bit more realism to the game, as the game seemed to be trying to ground itself slightly despite all the mythology it alluded to with some of its units. Obviously, not all ‘realistic’ features would improve the game, as it’s not trying to be a simulation of real life, but rather a dramatisation of the time period it’s set in, but adding this feature could – or could not – add an extra layer of strategy to the game.

Having arrows and other projectiles stick out of a character once it hits them has been done many times before in many different games, such as Skyrim, for example.I stuck three arrows in your throat. You're the whelp. : skyrim

Arrows sticking out of people has been done before, as shown above. Though, not many games have these projectiles slowly drain health from that character.

With just this basic premise, I felt that I had an idea which would add to the strategy of the game (i.e. don’t risk leaving the ranged units alive as they could easily wear your team down), though I also felt as though it wasn’t big enough of a feature to take up twelve weeks of development. Because of this, the idea transformed into making all sharp weapons inflict the bleed effect, which would involve telling the game which weapons were sharp and which were blunt. This would add a bit of extra time to develop it, but I still felt as though it wasn’t enough to make it a sizeable enough project.

Then I decided to turn the bleed debuff into a stackable one which deals more damage over time (DOT) the higher the stack is. I also decided to add an idea for debuffs which will be applied to a unit at certain bleed stacks (i.e. at 5 stacks the unit deals 20% less damage or something along those lines). These debuffs could include damage dealt, damage taken, attack rate and movement speed, but I may also choose to add extras if I come up with any and if there’s time left to make it work.

The idea to make the bleed stackable came from the game Risk Of Rain 2, which added a stackable bleed mechanic back in August. In that game, each time you hit an enemy, if you have a specific item you have a chance to inflict a stack of bleed for 3 seconds. If you manage to inflict another stack within 3 seconds, the game adds another stack of bleed onto the enemy and resets the duration of all stacks of bleed. This means that you can theoretically make the first stack last forever if you keep adding extra stacks every 3 seconds. This is a considerably powerful debuff, as it quickly outpaces the player’s damage in the early stages of the game, though it does become less powerful when an additive effect like adding more bleed stacks is far outclassed by other, multiplicative damage boosts.

A demonstration of the bleed debuff in Risk Of Rain 2. The number in red (19) is the bleed damage (dealt 4 times a second) and the number in white is the player’s damage. 

As Total war doesn’t have a constantly scaling difficulty, I will have to make sure that it’s not as powerful as it is in Risk Of Rain 2. This means that having it apply whenever any unit with a sharp weapon hits another will make it too blatant for it to be at all balanced – at least, not without making it deal a minuscule amount of DOT to make it not be overwhelming. Because of this, I decided that it would be more fitting to add it to a special unit type.

In order to do this, I needed to research a bit of greek history/mythology to see if there was anything befitting of a bleed mechanic. At first, I researched if there were any serrated weapons in ancient Greece, but I couldn’t find any solid evidence about it without being sent into other time periods and civilisations. After this, I decided to see if there was a race of vampires in greek mythology, to which I can only answer “sort of but not exactly”, as they’re not a race, but rather a couple of people given vampire-like powers and a creature/creatures known as the Vyrkolakas. As a result, I decided to make this bleed mechanic be specific to a special type of unit based on these creatures, as the game has various mythical representations (minotaurs and myrmidons come to mind), and the vyrkolakas are close enough to vampires for me to be willing to apply the bleed mechanic to them.

As I haven’t yet started the artefact itself, there aren’t any issues worth noting on its development at the moment, but I expect to encounter many issues when start making it. The next week will probably not have as much to write about, as I’m probably not going to start making the mechanic until the week afterwards, where these blogs will probably pick up some steam.

Week Four

Week four was mostly dedicated to re-learning Unreal Engine, as I haven’t used it in a few months for various reasons. I have two game demos (at varying stages of completion) and they have a few things in which will be useful for my mechanic.

There’s a few things I was hoping to find in these old demos, such as the variety of things relating to arrays I made, as I always find a way to make those useful, plus a lot of things related to local and global variables.

As I found out, there was a lot to do with variables and arrays, including a text array at one point, which was used to determine whether or not a ‘password’ you entered at the start of the game was in the top 10 most common passwords list I found once, and set the difficulty to the hardest if it was. If not, the game found out its length and decided on the difficulty from there. (the game demo was made for an assignment with a brief about cybersecurity, so it makes more sense in that context). Interestingly, the difficulty in that demo was based entirely on a timer at the top of the screen, so every obstacle only pushed you backwards, causing you to spend more of that time getting to the exit. Was this good game design? probably not. Is this relevant to TWS:T? also no, but it’s a fun thing to note and the way the timer was done could actually be used in my bleed mechanic, as it’s based in variables and not in a timeline or the in-built timer system someone once mentioned to me back when I was making the demo.

In my other available demo, I looked at how I incorporated music into the level, as it changed based on the health (or rather, mental health) of the player. It provided some clues into how I can efficiently code the effects caused by certain amounts of stacks of bleed, as I think it’ll likely work using a similar set of code, but I could be wrong.

The only real issues I’ll have at this stage is to do with time and certain mistakes I made when making these demos. For example, the first mistake I noticed was that my highly sophisticated “sound demo” level was most likely gone forever, as I never saved it onto my home computer when I was using it back at school. In that level were basically all of my experiments to do with sound, music, free 3d model sites, textures, decals, moving platforms and various other small and unusual coding side-projects (including a ball that played music whenever it was moving, a personal favourite of mine).

In reality, not much real work was done this week, as it was just me looking through old blueprints in Unreal 4 and trying to re-teach myself what I taught myself half a year ago (plus a few things my A-level teachers taught me in the year and a half before that). I would still remember it if pandemic-inspired lack of motivation wasn’t a thing. Anyway, next week is when I’m starting the mechanic, so expect some dead ends, dilemmas and disasters, as all good first weeks have.