The feedback Iāve gotten from the demo has given me reason to change and add multiple things pertaining pretty much everything. Itās a lot of pure text that goes into some depth in what Iāll be changing and why.
First some small things:
- Sounds and models fit eachother, except for the alarm sound. Will change that to a Horn or Trumpet probably
- The playerās healthbar needs to be more obvious. Will be making it bigger
- The weapon UI is bound to 1920x1080. Gotta make that dynamic for different screens. And learn how to properly do that.
Then the big guys:
- The game lacks variety.
Ā Ā Ā - The enemies arenāt varied. I will firstly add some enemies with speed, health and attack differences to see how it will affect weapon-drop-balance, and later work in more differing enemies.
Ā Ā Ā - The weapons arenāt varied or distinct. Possibility for changing this is changing the length of the weapons, and showing the differences in damage and durability in the UI
- The lack of being able to do something once you are without a weapon. Iāll be implementing something I thought of before for that, and that is being able to pick up a really shitty stick-weapon if one rolls through bushes when one doesnāt have a weapon. You can still fight, but youāll have to go out of your way to a bush and get very little in return, making managing your resources (weapons) still important.
- Weapons are too plentifull. After just a bit of playing you amass a large amount of weapons on the ground from the grunts. If balance was right, 1 weapon should cause 1 dead enemy. Now you can hit a lot of enemies with 1 weapon, causing the 1weapon:1enemy to skew to 1weapon:666enemy. This can be helped in multiple ways:
Ā Ā Ā 1. Lower the amount of grunts. This would mean these enemies would have to be replaced by other enemies. This would mean the player gains less weapons because one swordswing would cause less damage with less enemies packed together.Ā
Ā Ā Ā 2. Continuing with the replacing (or adjusting) of the enemies. Having enemies that take more swings (or specifically special attack swings) to kill would burn through the playerās weapons quicker, causing their worth to be more of a 2weapon:1enemy. Grunts however can still be 1weapon:1.5enemy for example. This would cause the player to stockpile on weapons first by prioritising grunts. This again would cause a nice dynamic where the player has to decide based on the weapons at hand wether to attack the grunts or attack more dangerous enemies first.Ā
Ā Ā Ā 2addendum. Another way to balance the 1:1 is to have some enemies not give weapons at all. For example, bowmen have no sword weapons, nor do wardogs.Ā
Ā Ā Ā 3. Lower the droprate of weapons. This would mean that, instead of 1 enemy dropping 1 weapon, enemyās weapons either drop by a chance %, or there are conditions that make the enemy not drop their weapon. The most obvious condition would be getting killed by the playerās special attack. This wasnāt in my original vision however, as I want players to be able to see weapons as disposable, and that breaking one weapons brings you the next weapon.
- A way to regain life would be nice. I actually had thought of this before the demo, but forgot to implement it. I want the special attack hitting give the player health back. Forgetting to implement it mightāve been good though, as the player can freely use the attack, and it hits many many enemies, giving you a gazzillion health.
- And lastly thereās still the problem of herding (there was a playtester who literally said it was like herding sheep... and no, they donāt read this blog). This might be removed by more diversity in enemies (and their movement speed and patterns), forcing the player to go into the enemies by prioritising going after specific enemies (see last post), or denying acces to kiting enemies by AoE-likeĀ ācrowdācontrol used against the player, which is probably something I wonāt be doing for now, but will keep in mind. Just having a tree suddenly fall and block a path around enemies could also cause one to stop kiting, or having more narrow spaces to move around in.
Also, shouldnāt forget this, there are some feedback-to-the-player things that should be added as they are lacking.
- As said above, the weapons and their differences arenāt explained. They feel the same.
- Grabbing weapons. Itās not obvious a weapon has been grabbed, it just appears in your inventory. More diverse weapons to pick up should help make it more obvious, and a sound of picking something up should also be played. Possibly the UI-part where a new weapon is put can light up if I wanna get fancy.
- Weapons breaking. A loud sound already plays when your weapon breaks, but thatās it. A visual cue in the UI with some kind of breaking animation overlayed on top of the main weapon should make it more obvious when your sword is gone, and possibly some kind of (particle) effect in the game. Also having the empty inventory spaces actually turn red or grey can give that little bit more quick visual information in the UI, knowing that youāre not playing with a full inventory any more.
- Getting damaged. Currently, the feedback for getting damaged is a bloody slash sound effect, the red invulnerability halo, the HP-bar shooting down, and the blood particle effect. Ways to make getting damaged more obvious would be adding a sound effect (a person in pain), making the invulnerability better with actual blinking or a white colour, the HP-bar showing the damage using one of them white bars that show āthis was where your HP wasā, and have the blood particle effect for the player shoot out further, harder and more red.
- Enemy health. I first didnāt know how necessary it was for the player to have this information, but if there are going to be multiple enemies itās going to be useful to have another way of prioritising who to go for.Ā So Iāll give enemies a HP-bar above their heads.
- Kills. The enemy getting killed needs to be more obvious that they are dying. The current death animation will get sped up so they fall to the ground like a brick (and changed when I get to use other models). Also, an extra death-scream can help.
What Iāve done with the enemies and why (and what Iām going to do)
So in the earliest part of development I had made the enemies go straight after the player using the Move functionality of their character controllers. It turned to the player and moved forward. This however did not take any sort of obstacles into account. And for that, you need a navmesh, so I made the enemies use a navmesh.
What also was the case during the first iterations of movement, was that the enemy didnāt straight up go for the player. They had to be within a specific range before their movement was triggered. For the wave enemy I changed this, because theyāre supposed to just rush the player.
Now, there was a problem with my vision and with the movement of the enemies, something that I explained in this post. It talks about how I want the player to have more of a feeling of being surrounded and to add to that, to have to fight an army on your own, instead of the enemy being herder like I displayed in the video of the post. Before I worked on the actual implementation of the waves-demo, I searched up some similar hack-n-slash games to the idea Iām working off of, and looked at the enemies and how they stood and moved in the world.
I did my research based on gameplay videos which I found from looking up top tens for Hack and Slash games. Complete explenation in the read more because it is quite a bit more:
Musou games.
For Musou games, the grunt enemies spawn often from thin air at suitable locations all around the player, often outside of the focus of action. Only if you pay attention youāllĀ see them simply fade into view. For the wave-based demo this made me decide on putting the spawnpoints all around the player, and made the enemiesā spawnpoints stay outside of the field of view from the player, hidden behind cover.Ā
Enemies are also very passive, and stay standing at the sidelines. You are essentially fighting two enemies, whilst the rest is standing around being meat for the grinder.
Nier: Automata
I then took a quick look into some Nier: Automata gameplay. I didnāt find army-sized enemies, but from what I saw when fighting multiple enemies is that if there are multiple, they arenāt very mobile, or only in sporadic short bursts. For the enemies in the demo, I decided to decrease their movement speed harshly. This would cause them to become less easily herded together.
At this point I also realised that, for Nier and for the musous, it was the player that went into the enemies and got themselves surrounded. They were motivated to fight and put themselves into a risky situation. Wether that be getting the job done quicker, being able to easily overpower the enemy, or what. So I thought about good motivations for getting in there yourself. For the demo this meant that I made the wave timer very low. The optimal playstyle would become to kill as many enemies as quickly as possible. Killing multiple enemies is also something thatās motivated by the durability system, but more about that in the next post. For non-wave based gameplay, I decided on something else that I thought of partly due to the feedback I got from the demo.
Grim Dawn
I looked at a bit of Grim Dawn, and saw that enemies came in from multiple places or spawned in when a trigger was hit. The trigger here was hitting an enemy, but simply entering an area could be the trigger. This would also be more natural for army men, to stick together. For the demo this isnāt as relevant, but for the eventual game Iāll be using triggers in areasĀ to trigger multiple enemies in that area, or the spawning of enemies outside of the area. It would mean making longer and multiple levels, so it aināt in the wave-based demo.
Least to say: itās better than
A lot of games
Also, something that is in most games as well as it exists in real life: you have multiple enemy types, each having a different priority to attack for the player. Like bowmen. I thought of this whilst thinking up the base game, but hadnāt been able to put them into the demo.Ā
These priorities will cause the player to move as I, the developer, wish (which is inside the enemy forces). So if I can make a super annoying bowman, then the player will be likely to run through common sword enemies to get to them first. Or the enemy type can make the player less focused on the common sword enemies by heading to them fast and demanding attention, causing the player to not be able to herd the common enemies. Iāll be experimenting with this.
So to sum up the things that can be done to help cause a feeling of being surrounded by the enemy (whilst still being playable):
- Spawn enemies around theĀ
- Hide spawn points
- (Grunt) enemies should have low mobility and some passivity
- The player should have a motivation to place themselves in situations where they are surrounded
Ā Ā Ā - This motivation can be caused by prioritisation of specific enemy types
- Multiple enemy spawns or movements can be caused by a trigger in order to suddenly overwhelm with numbers.
Thanks if you actually read through all this. Itās mostly meant for me to organise my thoughts, but I appreciate any readers. If you have suggestions for creating a more cutthroat, surrounded, and all-alone-fighting-many battlesystem, Iād love to hearĀ āem!
So Iāll be talking first about how I got up to the demo. Next post will be about why I changed the enemy and the post after will be about what Iāll be doing next using the feedback I got.
- Walkanimation problem: somehow the skinned mesh renderer deactivated during the walk animation. I didnāt find a solution, and simply copy pasted the animation to a later point in the timeline and it worked.
- Spawning enemies: for the spawning of enemies I simply made a couple of SpawnPoint gameobjects, placed them in good spots spread out on the map, and attached a script that spawned small skeletons to them. There is a parent object with a parent script that makes it so all child spawnpoints spawn what is expected for the wave. It spawns double the wave-number as the amount of small skeletons.
- The sword inventory UI was not working right before the demo. At first it did work right, but for some reason it started to not work properly anymore. I tried changing the invoke to a coroutine instead, and then to simply activating immediately, and the to just stuffing it in the Update(). That last one worked, though itās probably quite a bit heftier on the computer. For the demo it worked, but Iāll look at it once more later and probably change the conditions for triggering ChangeSprite(), because that should be the problem.
- Models for environment: I simply plundered the asset store for free assets. Itās currently not my focus. Just like the music and some sound effects (though Iām keeping quite a few of those sound effects, they work well).
- Walls: the walls are uninty cube primitives that deactivate their mesh renderers on Start(). This way they still allow for the NavMesh to be baked whilst still being invisible walls. NavMesh bakes based on mesh renderers you see. Also I lost a lot of time finding out what went wrong with my NavMesh when I simply forgot to set the objects to static -_-
- I made a text object for the waves to be displayed on. It also counts down to the next wave. Also, you can die now as the player. It has a āyou diedā text object and everything.
Ā - The bleed effects now trigger at the right time. Invincibility currently shows a redĀ āhaloā on the enemy/player to make it obvious, though Iād much rather find some way to have it show as a flicker or a white overlay. Gotta keep searching for how to do that (for multiple, different meshes/objects).
- Added object and script to restart scene.
- I had changed the enemyās speed to be slower.
Thereās probably more to put here, but these were important.
Just made my animations, but Unity is being an ass about properly displaying them: the skinned mesh renderer deactivates itself inexplicably with the walk animation. Also there is something wrong with how the roll is called. Gotta fix.
Also there are now problems with the inventory so maybe itās because I moved the GameObject under the new model, so Iāll be checking those out too.
Also also, Iām working on some particles that will activate when one gets hit.
Working on the special attack (which is mostly the standard attack sped up and multiplied).Ā
The animation loop doesnāt work, multiple hitting of the enemy doesnāt work, and the first special attack you do is 4 instead of 3 swings: Iāve got some cleaning up to do.
Code Readmore:
Something that bothers me is the enemy staying invulnerable after the Hitbox has become disabled:
OtherHumanoids is a list that gets added to with the OnEnter Collision GameObjects. And I just realized what might be the problem writing this: the list aināt adding things right.Ā
Imma try something else entirely for invulnerability.
Anyways, hereās the current SpecialAttack code snippet:
More later today with a hopefully fixed special attack.
I changed the movement of the AI to one using a navmesh. The codeās simply one from the main Unity NavMesh tutorials. I only changed some of the numbers in the agent, and I have the angular speed change to 9001 while moving, but 0 while attacking (the enemies kept turning slightly whilst attacking, and thatās a nono). I also disabled the navagent when the enemy gets knocked back by your attacks so it wouldnāt walk forward.
Also been working on making a first level. It looks a bit meh, so Iāll be trying to think of how I want it to look instead of just slapping assets down for next time.
I'll probably just make a field with an endless mode as the first level I make, just to test out the fun-factors.
Got the Inventory visualized in my UI, as well as a simple healthbar.
Inventory elements are prefabs and can be added or taken away according to the amount of weapons I eventually decide on that will be allowed in your inventory. Currently thinking of five, but no limit to picking up swords is set in place yet.Ā
The colour shows wether your sword has low durability.
Also, I now have a dodgeroll. The animation isĀ āRunningā from the assetstore asset, but itās practically a quick speedboost to where the mouse is pointing. You are invulnerable during the roll, and you pick up any weapons you roll over. Still gotta do the whole animate thing for my model.
Codes in the readmore:
Sword UI-elements (all use the same code, but the NumberInInventory is changed in the inspector according to which position the UI-prefab takes in in the inventory. Also, I gotta change the names of the objects.
The dodgeroll is as follows:
The code makes sure the playercharacter looks at the mouse, then the player moves towards the mouse, making sure the player can pick up swords from the ground. It also resets the invulnerability timer in case the player just got hit.
Enemies drop their weapon when they die, and all their components get destroyed, so itās just the dead body lying there. Iāll probably eventually write some seperate script to have that disappear after some time.Ā
With the whole picking up weapons thing I found some bugs pertaining the list function. It bugged out when there were no weapons in the inventory for some parts, so I put (different) if-statements where the weapons-list gets called:Ā
āif (list.Count > 0)ā instead of āif (list.Count != 0)ā
Iāve tested out the game with an amount of enemies similar to what I want in the eventual game. I fixed an animation bug which was as follows (and can be seen in the previous video actually): as the enemy is attacking the player, and the player hits him into the knockback animation, the enemy then does another attack animation whilst not actually attacking.
Anyhow, some things I saw while testing:
The enemies come too close to eachother.Ā
The enemies are too easily herded together.
There is no sense of being surrounded because of this, and thatās something Iām going for.
There is a bug where the enemy sometimes turn whilst attacking even though theyāre supposed to stand still facing one way whilst attacking.
Iām currently implementing death and weapondrops. Youāll see some of it later today.
Still working on Piece of Madness. Gave the enemy States. Made it so it move towards the player when they are in a radius, then they attack when the player is in striking radius.Ā
The animation for attacking isnātĀ working perfectly, and I have already worked quite a bit on them. I made it a bool and not a trigger for accessing the animation, and I gave the state switching some endlag. It works good enough for now. Iāll worry about it more when Iāve got non-placeholder animations going.
Code things:
This up here is the State Machine Iāve got going for my enemies. I might give the player a StateMachine as well if it proves useful when implementing the dash, the special attack or death, but for now Iāll leave the player as is and not unnecessarily complicate things.
Hereās how I implemented the windup timers and new method of calling the attack animation. Itās used by both player and enemies.
Also, the enemy movement script is super simple and will have to be changed would I want to add elevation (which isnāt planned):
Been working on my game. And since I havenāt done this yet, Iāll explain what my game will be.
It will be a topdown hack and slash with a durability system done right.Ā
Your character is too strong to keep his weapons in one piece, so after a couple of swings it will break. You pick up the weapons from your defeated enemies by dashing over them so you can continue fighting. Also, you have a special move in which the player does a flurry of attacks, which will heal you and deal extra damage if they land, but will also immediately break your current weapon after the attack.
Hereās some video of the player damaging an enemy (itās at the bottom of the readmore). It deals damage, plays a knockback animation and breaks your weapon (itās the floating one. It will be attached to the sword transform when there are non-placeholder graphics).
Now CodeStuffs:
I ran into some troubles with the hitboxes. I wanted to have the hitbox, a seperate object+circle collider, be called from the main StandardAttack script thatās in my abstract humanoid class, but it seems like collider triggers only send messages to their own gameobjects. Now I have an extra script that does the OnTrigger stuff that will be put in the Hitbox gameobject.
There was also a problem with the Hitbox OnEnterTrigger triggering, before the Attack Type could be read, leading to errors. So I put reading that on the OnEnable(), which solved it.
Also, here is the code within the abstract humanoid class for getting hit and for receiving knockback. The knockback will be differently overridden wether itās for an enemy (which will be hit backwards by a strike) or the player (which will become simply invulnerable, but have nothing else happen so you can immediately continue to act).
Some more coding. Changed weapon switching a tad and made the way inheritance is gonna work. Tried another method first, but I thought when doing what I was doing things were too troublesome, so Iām making something else.
Added automatic weaponswitching when the player has overused their weapon. Fixed a problem where I first checked wether the weapons[0] in the list wasnāt null, but it called on weapons[0] doing that, which gave an error. So now it simply checks the length of the list to see if you have any weapons, which is the same thing practically.
Iāve also been making an abstract class for the enemies+player
Things didnāt work as I wanted it, so I googled a tutorial to see what I did wrong. Didnāt make it monobehaviour and give it a ScriptComponent to work with.
Still working on it, and I still gotta see what problems itās gonna bring.
So today Iāve been working on making the beginning on what the attacks would be. Not the inventory as I said I would: I wanted the attacking done first so I can later code when durability breaks the weapon, the weapon also changes to the next in line as I intend it.Ā
Thereās not much visual yet but have a screenshot:
But Iāve tried to explain as I was working on it in stages what I was thinking and trying to do.
At first I made it so there were two bools inside the enemies where both have to be true before they get the effects of an attack: a bool for if they are inside your range (which is a trigger-hitbox) and a bool for if you are using the attack button.
The idea of two conditions is alright, but the execution how it is as this script gives you makes it so the enemy only gets hit if you quickly move the trigger onto them after pushing the mouse button.
So what I did was make a list of the enemies which is gone through every swing and has the bool for GetsHit changed.
Explaining it like this makes it sound horribly inefficient though, and now Iām doubting using the use of two bools. Itās probably a better idea to have a single bool and have the other condition be within the player whether the enemy gets hit or not by the attack.
So, after a thinky think, I decided to do something even simpler: disable the trigger when the player isnāt attacking. It makes everything much easier and I am a bit annoyed I didnāt think of that at the start, but hey, it does what I want it to do now.
Also changing the collider getcomponents so it wonāt get called constantly.
This post is mostly made for myself: itās just text about what Iām currently doing. Itās not very clear in what is what, so just wait a while before I post something more wholesome.
In order to improve my coding Iāve been learning some intermediate gameplay scripting from the Unity site.
Gone through Properties, and how and where they should be implemented in-code.
Refreshed my mind on Statics.
Theoretically learned what Inheritance is (which I was already a bit familiar with due to my history with GameMaker) and what Lists and Dictionaries are. Iāll have to implement them still, so Iām doing that next with an inventory of weapons to see how it works.
First Iāll make some diagrams with what I want for myself first, and then Iāll make a Weapons Class and inventory. Tomorrow, that is.
And now itās tomorrow (I forgot to post it) and I made a simple List Inventory for weapon classes. It's better than a Dictionary for what I want to do, because you automatically cycle through your weapons anyways. Also put up some simple visuals using free assets from the asset store. Will put up a little movie showing the weapon switching this sunday or monday. Whenever itās done. And also Iāll post the premise of what Iām making.
discoholicmusic
vaporwave
prguitarman