So I’ve been working on a game called Sunny for a while, and I’m planning on releasing it in the next month or so. It’s out for beta right now, but I’ve experienced a lot of specific bugs happening in the game that are really hard to narrow down.
What are some of your best debugging tips to prepare a game for launch? How do you solve the silent bugs or the game breaking ones?
Create a TestingTeam and use the Error event to store in a DataStore all errors that occurs while the TestingTeam did their job, so you can analize it carefully later:
local ScriptContext = game:GetService("ScriptContext")
local function onError(message, trace, script)
print(script:GetFullName(), "errored!")
print("Reason:", message)
print("Trace:", trace)
end
ScriptContext.Error:Connect(onError)
I tend not to get many outright errors in my game, it’s mainly silent errors and oversights that I need help with. Although this IS a very good thing I already use in my game!
Oh! yup, you said Silent Errors, sorry for misreading.
Humm…
This is just my pov… Lots of personal testing… and a very trusted and a committed testing team that is willing to record or remember steps to replicate the issue…
Otherwise, double check at endpoints goal parameters?
It depends on the type of bug:
| Type | Solve |
|---|---|
| Consistent: | Read the code, and figure out what is wrong. Maybe a value is nil, or not the right type, or maybe you’re using a method wrong. |
| Inconsistent: | If this started happening after you changed something, think about what could be causing it. It may be invoking an issue in old code. |
| Device: | The bug could only happen on mobile/console devices. Using the studio emulator sucks, you should play on a real tablet or with a real controller once and a while. |
| Latency: | How well is server handling remote data? Is the server doing too much work? The client has more processing power than the server because it’s only handling itself. |
| FPS: | The client is doing too much work per frame. If code takes longer than 1/60 seconds to compute (without yielding), you’ll see frame drops. If you want more than 60 fps, this code has to be efficient. |
| Physics: | If you’re working with some physics instances like AlignPosition, read up on how they work, and also problems people had with them. Most movers on the character are ignored because of the character controller. |
| Networking: | Network ownership controls what player has control over a part’s physics. They always have control over their own character’s physics. Some bugs pop up because of this, when working with some specific things with the character. |
I made up all of these, but you get the idea.
(edit: Errors are your friend. Bugs with no errors are the worst, especially if they show up after changing nothing.)
You didn’t misread it, I edited it because I didn’t make it clear haha
I’m sorry, what exactly do you mean by “double check at endpoints goal paramaters”?
These are good rules to have with debugging, in my opinion, especially the latency one, people rarely talk about server strain!
Could be that I am confused what you mean about “silent bugs” but, I think that you mean stuff that never throws errors but the result is not the expected one.
So, to me, the only way to catch that is double check, if the change that supposedly to happen it really took place, at an ending point/event, just double check if the changes were done or not by having some tables/modules holding the data I want to track. (sometimes english fails for me, hope that makes sense…)