Interesting bug in Death by Scrolling. Let’s dive in.
This morning I got up to several Mastodon, Forum messages and Steam posts about a crash in Death by scrolling.
ferryman.yack(90) Can't find var CHALLENGE_GEM
Interesting. Never seen that before and why now?
Turns out this bug is in a Daily Challenge, which is why we’re getting a lot of bug reports all at once. That Daily Challenge must have just pop up for everyone.
But why didn’t we catch it before? Both in human testing and in our automated tests?
Here is the core issue. CHALLENGE_GEM is a const. But it turns out that consts that are not defined in defines.dinky (and this one wasn’t) aren’t seen in Dinky code run inside of Yack files. This is a bug in the Dinky compiler.
But to complicated matters even more, the compiler bug is not seen in our dev environment, so it only happens with fully packed release files.
Our automated testing does test all the Challenges, but this is an odd Challenge in that it is completed in a dialog (Yack file), so while the Challenge was tested for completion it was not trigger via the Yack file by our testing unit.
But it does deeper.
After the first release on Steam it was discovered that this challenge only gave 1 Gem, not the normal 5. This was due to this code in the Yack file:
STATS_TOTAL.gems_from_challenges += 1
PLAYER.onGainGem(1)
I had hard coded 1 long ago. So I changed it to
STATS_TOTAL.gems_from_challenges += CHALLENGE_GEM
PLAYER.onGainGem(CHALLENGE_GEM)
So, the first version with the hard coded 1 was the one that went though most of the play testing and testing.
When I changed it to CHALLENGE_GEM it ran fine for me because I was in the dev environment and the automated testing didn’t catch this because it was in a .yack file and it was a Daily Challenge so had odds of about 1/100 of happening means it slipped through.
A lot of 20/20 hindsight.
This is fixed in the new expansion, but I’m not sure I want to push a fix to the Steam release because it is rare and there are risks in just building a new build.
P.S. I am going to do a new build for Steam. Turns out the crashing challenge will reappear on the 22nd.
Comments:
If you used something more modern, you wouldn't have issues like those
I completely understand what you said. I was just curious about specific reasons.
In software - and in games in particular-even the smallest change can break the product. And it's not predictable. It's like a bug in the rear-view mirror that can stop the car the second time you look at it.
To be confident that everything is fine, you have to test everything. Even a single use case can take hours, which makes testing an expensive phase that must be repeated for every release. Even if you change something very small or seemingly stupid, you still have to test it all over again.
Of course, you can structure your game to prevent some classes of blocking bugs. But there are still minor bugs that can break core mechanics, then all the dependent systems, and eventually the game’s aesthetics. And it often comes down to really silly things - like a healing potion that can't be used because an invisible UI element is capturing clicks. At that point, the game is effectively ruined.
Sure, you could say, "Let's ship it and fix it if players report issues." But that means you risk ruining the experience for someone who might have loved the game - and instead you end up with a negative review because you sold them a broken product.
With non-game utility software, users are generally more willing to wait for a fix or a workaround, because they "need" the software. Games are different. A bug can completely ruin the emotional experience the player is having, and there are plenty of other games competing for their time.
So if a developer truly cares, it's perfectly reasonable to decide not to ship a fix for a rare bug - because the risk of introducing something worse is higher than leaving it in. Instead, they may wait to test it as part of a larger patch, or even choose to never push that fix to production if such a patch never happens.
Add comment: