I’ve found that an effective tool for avoiding burnout is to diversify work. After a stretch of mentally demanding and tedious work, I’ll switch over to something simpler and more visual. I spent much of the past two months reworking some fundamental systems and finding and fixing everything that broke in the process. Interspersing some lighter work, such as the Select Class screen and sound effects, has helped me stay motivated.
- Completed a Release 3 feature, Saving and Loading. The bulk of this was completed a month ago (saving/loading the map) but there were some odds and ends I needed to add: deleting saved games after loading and dying, and saving/loading status effects, which are stored in a singleton, the Status Effect Manager. This manager stores the active status effects for each entity (actors and items). Each entity can only have one active status effect per status effect type. The original data structure for storing status effects was a nested dictionary (<Entity<Dictionary<Type, StatusEffect>>>). This worked during the game, but didn’t work well for saving and loading. Because Entity was an instance of an entity and Type was an object type, I was going to write a custom serialization/deserialization converter. When problems like this arise, I’m now trying to apply a “less is more”, i.e., instead of adding something new, can I simplify or remove something that already exists? In this case, I changed the status effect dictionary to a dictionary where each key is the entity’s unique id and each value is a list of status effects (<Guid, List<StatusEffect>). That structure can be serialized/deserialized without any custom code. After deserialization, objects are instantiated or referenced based on the guids and some UI and visuals are updated as needed (e.g., if the player was previously translucent from an invisibility potion, the translucency has to be reapplied).
- Added a unique identifier for each entity. It’s common to have a unique id for each entity, but up until recently I didn’t need them. Saving/loading necessitated this; I needed to serialize references to entities rather that serializing the entire entity each time it was referenced. The solution is simple – a guid is generated each time an entity is created.
- Started on sound effects. I was holding off on this to focus on the core mechanics, but this video (the part about adding “pizzazz” early on) convinced me to start now. I purchased a sound effect bundle from the Unity asset store that will at least provide placeholder effects. The sound effects may be too realistic match the 16-bit retro visual style (didn’t occur to me until after I purchased). I dropped a few sound effects into the game to learn how audio works in Unity, but I need to put more thought into the design. Since a sound effect can depend on more than one factor in some cases (hitting a wooden object with a wooden item vs a metal item, for instance), it’s not as simple as adding an audio clip to each GameObject.
- Still working on hotbar design. I think I’ve got it, but need to test it out with some games that use a similar hotbar design.
Next week, the plan is to work out the details of the sound effect logic and start implementing the hotbar.
Leave a Reply