Oh, welcome back. I hope your week was well. Here are the minor changes:
- Reduced the total move types from twelve to ten.
- Added the option for swing combos (works with every weapon move).
- Re-implemented combat move queuing.
- Changed how entities take damage from weapons (more functionality to individual weapons).
- Changed how entity stamina is drained from weapons (less cluttered).
- Added MotionBlur.cs, replacing the original sword motion blur. Cleaner, re-usable, faster.
In Pilgrimage of Embers, weapons are animated dynamically to give each a unique moveset. There are limitations, but the upside is a diverse and flexible combat system. The video above shows the animations I completed this week. From start to end, they are:
- Tarnished Shortsword. Small damage, but quick.
- Palewood Rapier. Decent damage, and quick.
- Villagekeeper's Shield. Defensive, though can have offensive move.
- Stonestrike Halberd. Large damage, but slower with more telegraphing.
- Primitive Spear. Decent damage, but somewhat slow. Two-handed, though has defensive capabilities.
I should stress that the goat is temporary. It's just the best animation I have currently!
I made two bigger changes to entities this week, those being attributes and statistics.
Attributes are for items, skills, weapons, spells, etc. to set, adjust, or retrieve the value of. Examples:
- The Defense skill sets the "SkillsPhysicalDefense" attribute to a specific value. Then, this value is retrieved when a sword hits the entity, reducing the damage taken.
- The entity's equipment sets the "EquipmentWeight" attribute to the total weight of all equipped item. This is then retrieved by the entity for adjusting its speed.
Statistics are, for now, player-only. The player will be able to view his or her statistics in the options UI. There are five in so far, but will add plenty more as new ideas come up. These include total deaths, beings killed, embers collected, most embers held, and most embers lost.
Object Interation Changes
The visual changes can be summed in just by the picture. If the player is near an object that can be interacted with, an arrow will smoothly rise and fall over top of it and a particle ring will emit outward.
As for the "behind the scene", I reversed what class does what. Before, each individual object would check if an entity is nearby and activating an object (boolean). If it was, then it starts the interaction. In the case of a flower, this "interaction" means the flower gets picked and placed into the entity's inventory. However, this would not be friendly to multi-threading at all (planning for the future, here!). Now, the entity class will check for nearby usable objects, and if there is one, the indicator will appear and the player can interact.
Regardless if it's better for performance or not, it's a smarter way to structure the code.
If you have any ideas, constructive criticism, or just want to tell me how much you dislike my game, you can: Send me an email, tweet @TheShyyGuy, comment on the Facebook page, or respond in the comment section below.
Do you want to support this ambitious project? Here's what you can do:
- Become a Patron here!
- Tell your friends and family about Pilgrimage of Embers!
- Retweet, repost, and share the content that you like!
From Enckling, with love.