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.
My main goal for the week was to create the Release 4 feature list. As I mentioned last week, Release 4 is focused on refining gameplay/user experience through small adjustments and improvements. To create the feature list, I started a new game and jotted down ideas as I played. It was helpful to play the game with the mindset of looking for small changes; it enabled me to find problems and opportunities I hadn’t noticed before. This process also revealed that creating the complete Release 4 feature list is impossible. In previous releases, creating the feature list up front was doable because the goals were to create specific systems, mechanics, and content. Release 4 is more iterative and uncertain; I’m going to play, identify adjustments, implement adjustments, test, and repeat.
- Game juice for movement. I’m trying to make moving look and feel better using various animation techniques (a great resource is Jeremiah Reid’s excellent talk on game juice given at this year’s Roguelike Celebration). I want actors to have a slight bounce as they move from cell to cell to indicate that movement is cell-based rather than pixel-based and to make the movement look more interesting. I spent far too much time on this and have little to show for it. I can’t seem to get the animation right – it’s either too bouncy, too slow, or too choppy. This experience highlights a drawback of solo development – the potential inefficiency and subpar results when working outside of one’s areas of expertise. I’m concerned about how much time I will sink into this. Part of the challenge is not having a clear picture of what the animation should look like – I’m adjusting parameters in the code, recompiling, and rerunning the game to see if I like the result. Next week I’m going to either make a custom GUI or move the parameters into a Unity game object so that I can edit the parameters at runtime and iterate faster. The latter isn’t currently possible because the parameters are in actor type data, which is loaded and cached up front.
- Game juice for combat. There’s already some game juice for combat in the way of particle effects, floating damage numbers, and sound effects. I made some small adjustments this week to the floating text. When I originally added this, I had the text rise up and then drop back down, resembling a bounce. I don’t recall why I did it this way; I think I just liked how it looked at the time. But now, I feel that this is unintuitive and unconventional. Why would text indicating damage taken float away and then return to the actor? I changed the animation so that the text now just floats and fades away. I also changed the color from white to red to make it clearer that the number represents damage. I also tried adding a black outline to the text to make it stand out more. But, it didn’t really work because the text uses an NES-style font that looks weird with an outline.
- Map generation tuning. The map generator randomizes generation parameters to produce more varied maps. Sometimes the results don’t pass muster – rooms are too large or small, room density is too high or low, etc. I played around with the minimum and maximum parameter values to more consistently generate higher quality maps. The key takeaways from this exercise were to increase the minimum room size (a level packed with 3×3 rooms isn’t fun) and to more vary room density (the original parameters caused rooms to be tightly packed into the map, virtually eliminating corridors).
- Random name generation. A remaining Release 3 to-do was to flesh out the player info window. This window displays the player sprite, name, class, and stats. The player name isn’t currently set anywhere, or stored for that matter. While implementing the name attribute, I visited the Unity asset store and looked at the available random name generators. None of them jumped out at me. I ended up downloading a free asset that was easy to integrate. The asset is essentially a single script that has a hard-coded list of names. It will work for now, but I’ll need to replace it with a more robust random name generator before the game is publicly released. The good news is that the interface now exists, so swapping out another random name generator should be easy.
Next week, I’ll continue to work off of the list of ideas I produced this week, with the main themes being game juice and map generation.