Minor progress this week. I have some time off from work over the next two weeks and look forward to getting more done.
- Added screen shake on hits. Continuing down the game juice road, every combat hit results in a screen shake now. I think it looks good, but wonder if some people may find it excessive or unnecessary. In line with the “sword and sorcery” theme, I want combat to feel exciting, and somewhat over the top. I’ll leave it in, but may dial down the effect. As with the blood particle effects, I want to vary the magnitude according to the amount of damage done.
- Distinguished missed hits from zero-damage hits. Whether the attacker hits or misses is based on the attacker’s chance to hit and the defender’s chance to evade. When a miss occurs, the text “Missed” appears instead of a damage amount. The damage from a successful hit is based on the attacker’s attack damage and the defense’s damage absorption. The amount of damage done is displayed when a successful hit is performed. A zero-damage hit occurs when the defender fully absorbs the hit. Previously, a zero-damage hit was being displayed as a miss, simply because this was easier to code. But, this didn’t accurately reflect what was happening. I needed to distinguish misses and zero-damage hits to play the correct sound effect (a whoosh vs a weapon hitting armor), whether to display damage and blood particle effects, and to degrade the attacker’s weapon and defender’s armor. I also wanted to communicate to the player whether no damage was being taken because of evasion or damage absorption.
- Moved player gold count back to the main screen. The player’s gold count was initially displayed on the main screen. I moved it to the inventory screen at some point to simplify the main screen UI. However, acquiring gold is so closely tied to the gameplay and the theme (treasure is a primary motivation for exploring the dungeon) that I moved the count back to the main screen.
- Researching Unity animation with relative positions. I want to make combat animations more complex. To do that, I want to move combat animations out of code and into Unity animations so that I can leverage existing engine/editor functionality. There doesn’t seem to be a straightforward way to move a game object relative to its current position in a Unity animation. A common recommendation is to create a parent object so that the child can move relative to the parent. It’s not an ideal solution, but it’s the best one I’ve found.
Next week, I’ll continue adding game juice to combat. This will likely be the focus for the remainder of December.