Timeline for How can I structure my game like a "classical" program?
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 22, 2023 at 1:32 | comment | added | Kevin | @Zsar My suggestion is, rather than giving up now because of a hypothetical issue in the future, pick an engine, plow on ahead, and start learning. Once you acclimate to the development paradigm, you'll probably find that it's easier than you expected. However, take note that while Unity and Unreal let you debug your own code in Visual Studio, it sounds like Godot only lets you debug your own code in their proprietary debugger. But since it's open source, you could theoretically modify the debugger or write your own. | |
| Dec 22, 2023 at 1:25 | comment | added | Kevin | FWIW I've been working with Unity for over 7 years and don't have an enterprise license with access to the engine source code. It's never been a major issue. Sure, sometimes there are engine bugs, or things that seem like bugs due to unclear documentation. Major bugs usually get fixed in a matter of weeks; sometimes, by the time I notice the bug, there's already a fix for it. Otherwise, I'm almost always able to find a workaround, often in much less time that it would take to go through the engine/editor source with a debugger. As for my own code, Unity lets me debug that in Visual Studio. | |
| Dec 22, 2023 at 1:19 | history | edited | Kevin | CC BY-SA 4.0 | added 2 characters in body |
| Dec 22, 2023 at 1:17 | comment | added | Kevin | @Zsar Let's say you're using any closed-source software for content creation. Photoshop, Premiere, Final Cut, Pro Tools, InDesign, whatever. Eventually, something may behave in an unexpected way, and you can't debug it because it's closed source. So you either work around the issue or you file a bug report and hope it eventually gets fixed. Anyway, Godot is open source, so you can theoretically build the tools from source and run them in a debugger. | |
| Dec 21, 2023 at 21:28 | comment | added | Vilx- | @Zsar - Yes, this is unfortunately a bit of the situation here. Although a bit better in the case of Godot, because it's open source, so you can actually compile it yourself and try stepping through it, but it's not really the intended way to go. Bugs in the engine will be relatively rare. By default assume it's working correctly and it's you who's done something wrong. The lack of good documentation however is a real problem, that I agree with. Although Godot does have something useable there, even if it is far from perfect. | |
| Dec 21, 2023 at 11:56 | comment | added | justhalf | @Zsar usually after checking that you've done everything correctly on your part, the next step in such cases would be to file a bug report to the game engine, describing the repro steps. | |
| Dec 21, 2023 at 10:53 | comment | added | Zsar | (FWIW: This is not meant to critique of your answer - it certainly sounds plausible to me: Such hubris is not unheard of in middleware design and I have encountered it often enough in e.g. the form of libraries with zero documentation: "You do not need to understand what happens, just use the public functions, those are self-explaining!" - I do and they are not, but every now and then a developer thinks so. And to be fair, it probably all is indeed self-explaining to its creator .) | |
| Dec 21, 2023 at 10:50 | comment | added | Zsar | Once (not if) one of the tools, say the sprite animation state machine, behaves in an unexpected way, how am I supposed to proceed, if I cannot debug it? Cry? Start over? Switch engines immediately? How is this use case modelled, considering it is guaranteed to occur sooner or later? The error is almost guaranteed to be miniscule and trivial to fix (as most errors are), but how to spot it, if the means to spot it are taken away? Finding the source of an error is almost always the - much, much - harder part. | |
| Dec 21, 2023 at 0:54 | history | answered | Kevin | CC BY-SA 4.0 |