So, uni’s gone back for another semester, which means once again it’s time to hit the books. I’ll still post here as often as I can (even if only once a fortnight), even though progress is going to be a bit slower for now. That being said, though, I’m still very happy with the amount of progress I’ve made towards finishing Ambience over the past month!
Anyway… recently I’ve been preparing for people to play-test Ambience again (which is always easier when uni’s in session, for various reasons). That’s meant I’ve gone back and revised the game intro and the first few dungeons (including finally making some proper sprites for the scientist Foss!), just to make sure everything’s working okay and looking good.
— Rhombus Ragmuffin (@RhombusGameDev) July 22, 2017
However, as always, things don’t always go to plan. One example was with the intro cutscene, which I completely revamped – and where I also found that the particle weather effects were taking a very, very long time to switch from one to the other.
In Ambience, weather effects and the smooth transitions between them are handled by a “weather controller” object. You can see a few of the important parameters associated with that object as red numbers in the GIF above. Basically, when switching between Ambiences, the object waits until there are no remaining particles from the previous Ambience before it starts creating particles (and other things) for the new Ambience.
The most important parameter here is the bottom right number, which is the number of particles in the room. That number has to go to zero before the Ambience changes – which, as you can see, seemed to take an unusually long time. But why?
To work out what was going on, I changed the Ambience of Dust particles to have a shorter lifespan – meaning that each particle would disappear sooner, while it was still on the screen. That way I could see what happened when the particle disappeared. I found this:
As it turns out, the weather controller object stores two types of particles: one which is created initially (the dust particle), and another which can be created on the first particle’s “death” (or disappearance). Sometimes the death particle is needed, for example for the splashing raindrop effect in the Ambience of Rain. Other times it’s not required, and the death particle takes on a set of “default” properties and, in theory, isn’t used.
But the weather controller object decided to create the death particles anyway, even if they weren’t needed or properly defined! (These are the little white dots you see in the GIF above.) These death particles had their own lifetime, which prevented the change in Ambience from occurring until all these useless death particles had disappeared. Not only that, but the extra particles put a larger load on the processor that it really didn’t need to.
The solution was simple: I just told the controller object not to create any “death” particles if they weren’t needed. The result:
Notice how the number of particles here (28) is much less than the number present in the previous case (226) – yay for optimization!
Finally, I re-extended the dust particle lifetimes so they reached the opposite side of the window before disappearing, and the job was done!
The Learning Curve
The major take-away from this was something I already knew: adding new features sometimes means other features need to be revised. In this case, adding the “death particles” for the raindrop effect – something I did several weeks back, I think – broke the effects for the other Ambiences, all without my knowledge. It was only when I went back and re-did the intro cutscene, which I hadn’t even looked at in a long time, that the bug came to light.
Of course, this sort of thing happens in gamedev quite a lot – but it’s still a good reminder to be on the lookout for new and unexpected effects when you’re adding or changing features.