A smaller update than the previous ones. This is mainly about programming than anything else. No videos on this one, but some explanations and basic coding layout notes.
Character Attributes
There is now a CharacterAttributes class that is attached to the character's model. This has the values for health, attack, defense, speed, block, and parry that are found in the design document. There are also functions in there that does the calculations for determining the maximum damage an attack can do. An ApplyDamage function is in the class that takes in that calculated damage, and then alters it based on the defense of that character. Other functions are in place to calculate the total block time and recharge time based on the block attribute. These are currently not in use. There is also a Die function that takes care of basic death things, but will probably change later on.
Base Attributes
There is also a BaseAttributes class now which has public constant values that store all the base attributes. This way they can be accessed from anywhere in code and are not allowed to be altered at any point.
Character Collision
Some changes have occurred in the CharacterCollision class. This is placed on any colliders that will be used as attack regions. Inside this class is a few important functions:
AttackStarted: Called via a BroadcastMessage call from the PlayerController class (and most likely an EnemyController class later on). This turns on the trigger aspect of the collision field when an attack has started.
AttackEnded: Called via a BroadcastMessage call from the PlayerController class (and most likely an EnemyController class later on). This turns off the triggers when attacking has completed.
QueueAttack: There is a new class called AttackVals, which stores the duration of an attack and it's power. Every time an attack occurs this is queued up. This way, when an attack collision occurs, the duration is used to keep the trigger from applying damage each frame, and the attack power value is passed into the ApplyDamage call of the enemy. This allows for varying damages based on the attack.
Gate Attributes
Though we never talked about this, the current gate that is shown in the last programming post video could actually be a gameplay element. In slight preparation of this possibility, there is a GateAttributes class that has some basic similarities to the CharacterAttributes class. It has health and defense values, which are calculated the same way with the ApplyDamage function.
Fixed Camera
Lastly, there is a FixedCamera class. This has been around since the last post, but thought I'd post it here too. The class uses the LateUpdate call in order to reposition itself back to where it should be, and allows for left-right scrolling like in old games.
Next Up…
The next major thing that will probably be worked on in programming is the beginnings of AI. Not sure when this will be started, but it will hopefully be soon.
Differences In the Videos
The last video demo just showed the character attacking, moving, and idling based on player input (or the lack thereof). What wasn't shown is that the player could move anywhere they wanted as well as through solid objects. In this video, you see that the player is actually bounded by walls and objects, can attack, and actually has something react due to the attacks.
Changes Since Last Post
The last post was mostly about player's character control and how it changed the character's state and animation. All of these things were within one class. Now, there is a class called CharacterAnimationController which handles all the animation calls. The PlayerController class has a variable which does the appropriate function calls to make animations occur. This allows for a clear separation of concerns and should allow for player control logic to be in PlayerController and animation control logic to be placed in CharacterAnimationController, to help alleviate any possible confusion. It also allows this to be very flexible, since the CharacterAnimationController class can be placed into any character model and an external controller can access it.
The New Stuff
The new stuff is mainly about collision detection. I will detail what the current logic is, but as for classes and variables, those will probably be left out until the next major post on this subject. The reason behind this is that there will probably be a major code organization change sometime soon based around this stuff and the character attributes of attack, blocking, etc. Also, a small but good change is that the camera has been updated to act like the old games in this genre. It moves only left and right with the character, but not up and down.
First Attempt and What Was Learned
The first attempt at collision detection was a lot of Capsules (a primitive object in which I later had their mesh renderer removed to use their Capsule Collider component) that closely fit to the body of the character. Each one was placed as child to the model's bone's GameObject. This allowed it to automatically rotate and move to the model's animation. This was great since we could have near perfect accuracy. However, it was decided that such accuracy could actually be bad for the type of gameplay we are aiming for since it could make some characters' attacks more effective than others. Though the Capsules were scrapped, we did confirm that we could place other things, such as particle effects, onto the bone of a model and have it act according to the mode's animations. This should allow us to easily have cool effects in certain areas.
The Thing We're Using Now… And What We Learned
Through other attempts and research, the CharacterController component was found. This component, when using it's own Move function, would allow the character to not walk through solid objects. This is now being used to prevent that, but to also be the basis of the collision region of the character (the region that will say when the player is hit). In front of the player is now an invisible BoxCollider, which is the attack region. If the player is attacking and something is in that region, it will be hit by the attack.
A problem that occurred during this is that the CharacterController and the BoxCollider would be colliding during attacks and triggering the colliding functions. This is an issue, since no matter when the player attacks, the trigger would go off, which is a waste and could cause other collision problems. To solve this, I luckily came across the function Physics.IgnoreCollision, which does exactly what it's name implies. It has to be called at runtime though; it will not carry over or save. This did solve the issue, and knowing about this function will most likely help in the future.
When a collision occurs, a message is sent upwards in the collided object with the SendMessageUpwards. Thus if the player hit's an enemy, the enemy has a message sent upwards to apply the damage. At this time, a preset number is sent from player to enemy on the amount of damage to be done. This will later be changed so the calculated maximum damage of the attack is sent, and then the enemy can apply any defenses and changes before actually applying the damage.
What's Next
Things coming up are refinement of this collision detection system, character attributes, and AI. Particle systems will be added somewhere along the way too.
