The worst part of solo game dev..
HTML-код
- Опубликовано: 5 фев 2025
- One of the hardest parts of game dev is fixing a bug you can't reproduce that only a small fraction of your players experience. Here's a cautionary tale about an elusive bug I've fought for the past 3 months in my upcoming game Hexagod.
Hexagod Demo: store.steampow...
#gamedev #indiegame #aarimous
My Games:
Steam Page: store.steampow...
Chess Survivors: store.steampow...
Social Media:
Twitch: / aarimous
Bluesky: bsky.app/profi...
Discord: / discord
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
One of the hardest parts of game dev is fixing a bug you can't reproduce that only a small fraction of your players experience. Here's a cautionary tale about an elusive bug I've fought for the past 3 months in my upcoming game Hexagod. Checkout the demo for Hexagod on Steam: store.steampowered.com/app/3059390/Hexagod/
Never heard of it before. But looks interesting so I'll check it out.
There's a lot of exaggeration on game dev youtube, but you are 100% correct that the worst part of any software development, are bugs you cannot replicate.
I did think... "is this title clickbait", but like these bugs do suck the most. Thanks watching the video and leaving a comment :) Good luck on fixing your bugs!
I feel your pain, I just got done fixing some really obscure bugs myself!
RUclips just gave me this godly of recommendation to your channel. Informative video, and good commentary. You got my wishlist for Hexagod Aarimous!
You have really solid content. I always enjoy what you have to share
Thank you and I'm glad you are enjoying the videos!
...2015...a decade old...?
oh fuck.
good video btw
Wow, that's a rough one, for sure. Glad you (hopefully) got it whipped now :)
The other thing that's worse is when you can't replicate the issue, and then you make changes and add logging, push that to the user and the logging fixes the issue because it slowed the program down just enough to make the problem go away
Hey! Just wanted to say thanks for these awesome videos man! Since I've (again) started working on a small game since last week I've been watching some of your videos and they've been super nice to get some guidance but it's also really fun to look at some of your code and how you implemented things to get some technical inspiration for my own code.
Hexagod looked cool before but as a turn based roguelike it looks really interesting, I will definitely play it when it comes out! :D
Also, sorry for the unsolicited request but just in case you're looking for possible future video ideas I'd love to see how you handle scaling your game for different resolutions and screen ratios and keeping it looking good and not messing up the looks/graphics. It's obviously dependent on the project but it's what I seem to struggle with the most and it would be interesting to get your insight.
PS Your cats are really cute
Glad you enjoy the vids! Cheers :)
Sorry for those pesky bugs. I'm glad you made it through! 😁 🎉
never ever ever ever check floats for exact equality, you’ll only get headaches. always check with a delta, or check greater than or less than (with equals) if it doesn’t actually need specifically equals
yeah, sounds like comparing two floats without any margin/delta.
conveniently godot has is_equal_approx(a, b) and is_zero_approx(a) for this exact purpose !
Definitely was bashing my own head against a wall with my own bug last night. Sometimes it just takes walking away, and coming back with fresh eyes. Gamedev is hard. Cheers!
Those bugs are the worse. I squashed a bug this weekend after 3 days (8 realtime hours) of messing around.
The bug was basically that my Pause menu and GameOver (Win Screen) would break in Build mode only but was okay in Edit Mode.
The error was happening because Unity seems to manage OnDisable/OnEnable differently (or slower?) in a Build than in Editor.
Switching to Start() fixed it (and I had to tweak some things around that but now it works)
Yeah, my last job I was a tech lead on a support staff. Which basically meant I had to deal with customers who had these exact sort of non-reproducible very customer specific bugs. But maybe we should try just not writing bugs in your projects ;)
@Aarimous haha yeah! How dumb of us to go and write bugs!
Woof! So glad you were able to fix it.
I often add in a catch-all type statements in my code to (hopefully) smash bugs before they happen.
if work_to_complete >= 99:
work_to_complete = 100
But sometimes they are just impossible to replicate or fix. Even big studios will do some workaround to make the game crash gracefully or reload stuff if they can't fix it.
This matters only if the bug is not fixed:
I'm not very familiar with Godot, so I'm not entirely sure if this applies, but it's possible that floating-point imprecision is causing the issue. Once you switched from time-based calculations to turns, these imprecisions might have started to matter. If you haven't already, you could try comparing the results to an approximate value to see if the problem persists.
The worst part of solo game dev is being solo
No lies were told. The worst part of solo dev is fixing bugs by yourself (or at all) 😅
Things like this are why I use raylib instead of an engine. At least then I can find out exactly what is going on under the hood and understand the issues with some digging. Has its cost tho..
It seems you ran into what is just a fundamental problem with floats/doubles. The IEEE 754 floating point standard is about making very fast calculations for science and simulations. This is just baked into the standard and all languages that implement IEEE 754 have the same problems with those data types. The canonical broken example is that 0.1 + 0.2 does not equal 0.3.
Good point. It also seemed to functionally work fine when the game was realtime and thus adding work each frame (using delta) worked, but then having a discrete amount of turn processing time broke it all. Thanks for sharing!
I think your old solution would work if you used _physics_process instead of _process. It runs at a fixed rate per second (adjustable in godot settings, default is 60/s) rather than once per frame. Or at the very least, it would be less variable between hardware
To be fair my system is old but not that crappy can play most new games. Hence, I'm not bothering to upgrade ;) .
Fair fair, I was more or less talking about my old crappy laptop but realized I could have been talking about your comp as well. Anyways, thank you for your help debugging this all :)
I had a bug that users reported, and I could never reproduce it even with great steps from them. I ended up rewriting the whole system adding in a bunch of failsafes. I can't say for sure I fixed it. But i dont get users contacting me anymore so I guess its fixed? wack
What is a tween?
From the Godot docs: "
Tweens are mostly useful for animations requiring a numerical property to be interpolated over a range of values. The name tween comes from in-betweening, an animation technique where you specify keyframes and the computer interpolates the frames that appear between them. Animating something with a Tween is called tweening."
docs.godotengine.org/en/stable/classes/class_tween.html
Or you can just skip fixing it and take the few negative reviews on the chin.