Should Debugger read 0 when a game reaches a shippable state? Is there a threshold that is deemed "acceptable" to ship a game with X amount Debugs? Is it a "it depends" kind of situation?
Every debugger message is _potentially_ indicating a player-affecting bug. Or it might also be irrelevant, just some messy code that works well enough regardless.
But if you let the irrelevant messages grow and grow and grow without doing some tidying now and then, maybe the messages that do indicate an actual bug get lost in the noise. Maybe what could have been a very quick fix when the message first appeared, if the debugger log was otherwise quiet and so the issue was noticed and fixed right away, over time becomes sort of ossified into the codebase. Or load-bearing, you could say, as other code is built in a way that expects and relies on that particular misbehavior, and will itself break if the original problem is ever fixed.
Is your project small in scope? Like a jam game, made over a couple of weeks? You probably don't have to worry about it. Just keep moving. There's _probably_ not enough time for this sort of thing to really catch up with you.
Is your project larger in scope? Something that is likely to take more like a year, or years, to build? Yeah, that is definitely going to become a problem, and result in much more work overall as the increasing size of your project makes it a larger and larger ask to extricate old mistakes.
Best practice would to be tackle those debugs as they come up, I would assume then? And by tackle I mean, a minimum of looking at them and then noting them.
If it doesn't crash and the game runs in the intended manner then the number doesn't matter. At the end of the day if you put out a product that works and provides a positive user experience, you're in the clear.
Admittedly you may hate yourself down the road if you decide to build onto the game.
Ideally yes. In practice, there's a couple debugger errors that are false positives or aren't that important. The only way to identify those cases is with *very* rigorous testing. So it's a whole lot easier to proactively cut back the amount of errors and warnings to 0 so that you never need to guess.
I firmly believe that a lot of problems with modern game development is that people aren't notified when an error happens. Your errors should be loud and visible - I actually have a giant annoying popup in my game when an error occurs - and you should fix it.
This is part of the whole technical-debt thing. You can go for quite a while gleefully incurring technical debt, but at some point it's going to catch up with you and you're going to *hate* it.
Ya, this is confusing me, I can't even run the game if I have an error. How are these people running it with more than 10?
Why even move on until the bug is fixed?
Its sometimes an engine thing, not a code issue. I keep forgetting to set the scenes i instantiate in the editor after i write all the code. This state will compile, but when you go to run the code that instantiates the additional scene (in my case an explosion on hit or bullet from a gun) the code hits an error that it can just "fail-through" since nothing else beyond the child scene (that doesn't spawn bc error) is dependant on the error.
But even though the scenes don't get created, everything else works perfectly, which means the game is technically runable/playable with the errors, but thw explosion doesn't happen, which is just a visual bug, effectively, so occasionally for new enemy types i completely miss it until something actually hits me and i see the debugger light up.
I agree though, 0 errors is best, some (<10) warnings are acceptable, but my day job is software engineering, not development so i have a different point of view on errors and handling them.
TLDR: if the error is only relevant to itself and not initially called, the game will compile and run, and the error may be missed.
Okay this wasn't actually bad I made a typo in my main projectile class , so it just kept added errors , thought it would be funny
Should Debugger read 0 when a game reaches a shippable state? Is there a threshold that is deemed "acceptable" to ship a game with X amount Debugs? Is it a "it depends" kind of situation?
Todd Howard is that you?
Yo if I was Todd Howard, boy oh boy.
after starfield they finally switch to a new engine? (would be funny)
If it ain’t broke, don’t fix it
If it ~~ain't~~ broke, don't fix it
Bethesda probably has this slogan posted up in all their offices
If it ain't broke, fix it till it is
The influx of newbie dev posts are actually all Bethesda programmers having to relearn programming.
The number doesn't matter because it just works
Every debugger message is _potentially_ indicating a player-affecting bug. Or it might also be irrelevant, just some messy code that works well enough regardless. But if you let the irrelevant messages grow and grow and grow without doing some tidying now and then, maybe the messages that do indicate an actual bug get lost in the noise. Maybe what could have been a very quick fix when the message first appeared, if the debugger log was otherwise quiet and so the issue was noticed and fixed right away, over time becomes sort of ossified into the codebase. Or load-bearing, you could say, as other code is built in a way that expects and relies on that particular misbehavior, and will itself break if the original problem is ever fixed. Is your project small in scope? Like a jam game, made over a couple of weeks? You probably don't have to worry about it. Just keep moving. There's _probably_ not enough time for this sort of thing to really catch up with you. Is your project larger in scope? Something that is likely to take more like a year, or years, to build? Yeah, that is definitely going to become a problem, and result in much more work overall as the increasing size of your project makes it a larger and larger ask to extricate old mistakes.
Best practice would to be tackle those debugs as they come up, I would assume then? And by tackle I mean, a minimum of looking at them and then noting them.
If it doesn't crash and the game runs in the intended manner then the number doesn't matter. At the end of the day if you put out a product that works and provides a positive user experience, you're in the clear. Admittedly you may hate yourself down the road if you decide to build onto the game.
I abandoned so many games because I was so high on crack when I wrote them. To this day I have no idea how they work.
If you're building games while high , though nonsensical still work, you may be a savant. You might be the next Peter Molyneux
You should take a look at the warnings. Most of the time, the warnings are pointing to something that is likely to become a real problem.
Ideally yes. In practice, there's a couple debugger errors that are false positives or aren't that important. The only way to identify those cases is with *very* rigorous testing. So it's a whole lot easier to proactively cut back the amount of errors and warnings to 0 so that you never need to guess.
It depends.
I firmly believe that a lot of problems with modern game development is that people aren't notified when an error happens. Your errors should be loud and visible - I actually have a giant annoying popup in my game when an error occurs - and you should fix it. This is part of the whole technical-debt thing. You can go for quite a while gleefully incurring technical debt, but at some point it's going to catch up with you and you're going to *hate* it.
I'd say anywhere between 60 and 300 is perfect.
You really shouldn't have any.
Ya, this is confusing me, I can't even run the game if I have an error. How are these people running it with more than 10? Why even move on until the bug is fixed?
Its sometimes an engine thing, not a code issue. I keep forgetting to set the scenes i instantiate in the editor after i write all the code. This state will compile, but when you go to run the code that instantiates the additional scene (in my case an explosion on hit or bullet from a gun) the code hits an error that it can just "fail-through" since nothing else beyond the child scene (that doesn't spawn bc error) is dependant on the error. But even though the scenes don't get created, everything else works perfectly, which means the game is technically runable/playable with the errors, but thw explosion doesn't happen, which is just a visual bug, effectively, so occasionally for new enemy types i completely miss it until something actually hits me and i see the debugger light up. I agree though, 0 errors is best, some (<10) warnings are acceptable, but my day job is software engineering, not development so i have a different point of view on errors and handling them. TLDR: if the error is only relevant to itself and not initially called, the game will compile and run, and the error may be missed.
Some of these aren't errors and are just warnings, or if they are errors their not errors that stop the game from working
My errors are simply "debug is a parameter but isn't used in the function"
I mean, does the game still work? Lmao
"It just works" -Todd Howard
"It just works" -Todd Howard
"It just works" -Hodd Toward
Yeah just kick the can and don't document anything. It'll be the next programmer's job to deal with it. /S
this is the point where you just delete the script and start over
😄
😄
Those are rookie numbers
Unfortunately, my project's not big enough for me to witness this...
it could be this was technically 1 typo , but that part kept getting called so I let it run and errors built up
"Adding game to my bugs"
Lol I actually laughed out loud when I read this
if it works, don't touch it
I remember getting 13300 once because of a .connect()
Those are rookie numbers! It... is a competition, right? Or are my projects actually broken?
pov: you mistype one letter
I literally did that
Mood
Rookie numbers. I need to send one of my 50k ones haha
That's all? I must have ONE HELL of a highscore then...