try to write code without AI? we’ve come full circle. Advice about debugging is good, automated testing would help but i don’t think that’s popular in game development.
RE: Automated Testing: I've seen it both ways. There are some studios that do a lot of testing(I know Rare does TDD and Tim Cain talked about asking programmers about proper testing when they were interviewing people at Obsidian), and Unity itself actually does provide tooling for this, like: https://unity.com/how-to/automated-tests-unity-test-framework
But for the most part, the places where you have bugs are not easy to test, and the tests you'd write are subject to change so often it can become a waste of time to go too far in that direction.
I like writing unit tests for the obvious - asset loading, OOB stuff, sanity checking on numbers, etc. After that things mostly get into 'easy for a human to verify is wrong but hard to write tests for' territory.
my 4:
-Realize that for the most part, you shouldn't be relying on unity to manage the execution order of your scripts.
-Realize that the features in Unity's editor are designed towards a workflow where a programmer and a designer are working together on a project, not one where the designer and programmer are the same person. Most things the editor does can be done quicker and more easily by a reasonable programmer, and the cost you pay for doing things using the editor is a lot of bloat, indirection, and general mess.
-Realize that Unity has 3 kinds of features - The ancient stuff you are not 'supposed' to use anymore, the features that you are 'supposed' to use instead but that introduces a bunch of edge case problems and that were abandoned for the *new* new stuff, and the external tooling that unity bought the rights to sand incorporated into the engine when they couldn't solve the problems with the previous features.
-Realize that Unity is half a decade behind C#'s current feature set.
The end result of this is that ultimately, you end up only plugging into a game object using mono behaviors once(because you have to) and then for the rest of the program you mostly don't use Unity's drag and drop editor interfaces ever again, which has profound implications for what your code looks like.
mmaldacker@reddit
try to write code without AI? we’ve come full circle. Advice about debugging is good, automated testing would help but i don’t think that’s popular in game development.
realmslayer@reddit
RE: Automated Testing: I've seen it both ways. There are some studios that do a lot of testing(I know Rare does TDD and Tim Cain talked about asking programmers about proper testing when they were interviewing people at Obsidian), and Unity itself actually does provide tooling for this, like:
https://unity.com/how-to/automated-tests-unity-test-framework
But for the most part, the places where you have bugs are not easy to test, and the tests you'd write are subject to change so often it can become a waste of time to go too far in that direction.
I like writing unit tests for the obvious - asset loading, OOB stuff, sanity checking on numbers, etc. After that things mostly get into 'easy for a human to verify is wrong but hard to write tests for' territory.
OrkWithNoTeef@reddit
no AI no debugger no googling
just you, the docs, and lots of print statements
realmslayer@reddit
my 4:
-Realize that for the most part, you shouldn't be relying on unity to manage the execution order of your scripts.
-Realize that the features in Unity's editor are designed towards a workflow where a programmer and a designer are working together on a project, not one where the designer and programmer are the same person. Most things the editor does can be done quicker and more easily by a reasonable programmer, and the cost you pay for doing things using the editor is a lot of bloat, indirection, and general mess.
-Realize that Unity has 3 kinds of features - The ancient stuff you are not 'supposed' to use anymore, the features that you are 'supposed' to use instead but that introduces a bunch of edge case problems and that were abandoned for the *new* new stuff, and the external tooling that unity bought the rights to sand incorporated into the engine when they couldn't solve the problems with the previous features.
-Realize that Unity is half a decade behind C#'s current feature set.
The end result of this is that ultimately, you end up only plugging into a game object using mono behaviors once(because you have to) and then for the rest of the program you mostly don't use Unity's drag and drop editor interfaces ever again, which has profound implications for what your code looks like.