10 Jun 2020
Last week I was a little harsh on words. The cause of last week’s bug of failing to find the overlap of two rectangles, could be attributed to the meaning of a word changing. If you recall, the camera has a size; a width, height and depth, but what does that mean?
Before the camera existed there was a view-width and view-height that were the number of tiles horizontally and vertically that could fit on the screen. When I came to find the overlap of the camera and the world I assumed this was the meaning of the camera size. When zooming was added it became possible for the size of what could fit on screen to be larger than the size of the world. To prevent the renderer trying to draw locations that don’t exist, the camera size was constrained to be no larger than the world. The meaning of the camera size changed but the word remained the same.
Would I have made that mistake if the size property was named better? What should that name be? When renaming variables I start with a sentence that is explicit, in this case “The number of tiles that can fit on screen but no larger than the world.” Then I try to refine that down, perhaps WorldConstrainedSize. This name is cumbersome which makes me think the variable is trying to do too much. I feel a better solution would be to keep the size name, not constrain it to the world-size but only apply the constraint when it’s necessary. I’ll look into this further next time I’m changing the renderer.
This week started with the effect that the death of a Dwerg has on those that know them. This is modelled as an instant significant reduction in mood with a long-term modifier proportional to the relationship with the deceased. On Thursday and Friday I added selecting all units with a keyboard-shortcut, instructions for mining ramps to the tutorial, play-testers to the credits and looked into the path-finding performance. On Saturday I got upset by my Dwergs drowning so I added behaviour to flee rising water. To help players get through the tutorial I’ve added a button to show what they need to do to continue the story. The rest of the week was spent on stockpiles; adding ordinal and dual-point sliders and sending the user’s changes from the UI to the simulation. There are a number of jobs left on this but it’s pretty close to completion.
Despite being dogged by paperwork, Frans is putting the finishing touches to the summer music track, you can hear a short part of this in the stockpile video. He’s finished the winter and summer ambiences and is doing some research into the types of birds found in spring and autumn for those ambiences. We’ve found an issue with the attenuation of positional sounds; the spatializer that was adding weight to the sounds was preventing the attenuation from dropping off. We’ve removed that but now the panning is too hard. We’re letting our subconsciouses work on this problem.
For the next week I’ll be finishing the stockpiles and running some play-tests. Frans will be starting fresh on the winter music track and working on the spring and autumn ambiences.
There won’t be a release next week as we are planning on making a free public build the week after and need a bit more time to balance the sound, do some QA and play-test the tutorial.
Enter your email to receive a monthly summary of development progress on Dwerg Saga.