How do you avoid repeating game bugs and errors?

As game developers, quite often, version control ends up being an afterthought. I cannot stress how important it is to enable version control right at the start. In fact, I start all my projects with version control before I do any development work. It’s also important to leverage game engine friendly VC systems like PlasticSCM or Perforce and not rely on traditional ones like GitHub or Bitbucket.

In any professional environment using VCS should be a given, the real question is HOW to use it. What will your policy be on rolling back changes that have introduced new bugs? Will you embrace branches or trunk based development? Will you allow commits without buddy checks? What will your CI system check after a new commit, or will you use a CI commit queue? You will need to determine what trade off you can live with between maintaining your build stability, and keeping your development process low friction.

Version Control is key for any project, but it is critical for large projects that want to scale. Version control is not just about versioning. Your choice of VC and how you use it is going to dictate how you develop the game and how well the team/project scales. In addition, adding VC allows you to do Continuous Integration and Continuous Delivery/Deployment. This is crucial; VC and CI/CD enable companies like Microsoft to manage and scale large projects effectively. In many ways the game industry lags behind other fields of Software Engineering on this. Gaming-specific VCs versus GIT-based ones is not a straightforward choice. There are benefits for both and it needs to be balanced between what the studio needs and what users need.

Effective version control demands strict branch and naming adherence. Protected branches and pre-merge code reviews are pivotal in preventing critical production bugs. Utilizing proficient merge-diff tools is vital. Modern tools easily resolve routine conflicts, focusing on those requiring human intervention. Collaborating on non-human-readable files requires careful task distribution to avoid conflicts, saving time and obviating specialized conflict-resolution tools.

A benefit of VCS from my experience: There was a bug which detected after releasing the game. So, we rolled back to working commit and released the game again. It helps to track changes on the code. Tips for VCS usage: Make commit messages meaningful. Add version tags for commits. For example : v_1.2.3 Make commits atomic: Your commits are of the smallest possible size. Each commit does one, and only one simple thing, that can be summed up in a simple sentence. Add .gitignore file in the beginning.

Coding conventions are extremely important in game development. GameDev is a highly collaborative environment and is also one which is extremely prone to bugs because of the complex nature of games. Therefore, it’s highly important to have standards and conventions. For example, your team might want to focus on an event based programming system and it would be highly problematic if you created hard links between scripts and components. Consider the fact that games need every extra ounce of performance and therefore, coding standards help with setting up optimal systems to eek out every last bit of performance

Having just a documentation of coding conventions is not enough. Because let's face it, one tends to forget conventions once in a while, and no one works with documentation open all the time. It will be so inefficient on development time. Code should be peer reviewed and passed before submitting it. Having at least 1-2 peers who know the systems you are working on, or more importantly, have worked on the same scripts as you have, helps plucking out quite a lot of potential hazards in the code.

Adhering to SOLID principles is crucial. These principles, crafted by experienced programming experts, distill invaluable lessons from past mistakes, guiding us away from replicating those errors. For prototypes, simplicity in language choice is acceptable. However, when crafting production-grade games, discard the prototype once its purpose is fulfilled. Begin anew, selecting technology wisely to ensure scalability and cost-efficient adaptability. Building upon prototypes risks destabilizing the product as it scales up.

Games are very large software projects. They contain a lot of components: Physics,Input,Sound,... If you follow coding standards and conventions you can reduce bugs and write maintainable codes. Writing maintainable codes are very important because game development is an iterative process. Tips from my experience: Each class should have a single functionality. For example, instead of a single huge PlayerController class, divide it into classes such as MovementController, CollisionController, InventoryController. Always follow the code convention of the game engine used. In this way, your game code will always follow the same standard.

It's crucial that you test the code when writing it, and by playtesting code that has been added to the game as early as possible. The old school approach has been to get people in seats to manually test games, but that has been shifting towards more emphasis on automated testing to keep up with the advancements made in other areas of software development. Depending on what development approach you are taking with your Version Control, there are early opportunities available for manual/automated testing using your CI/CD systems. Learning to leverage those effectively can allow you to release game updates on a regular schedule. Failure to do so is one of the main reasons for delays or low-quality releases as testing happens too late.

Testing your code is extremely important. I’ve found a lot of developers who make certain game-breaking changes and, after a module is solved, push the changes directly and then ping me. But when I open up the build, I see a ton of errors and the functionality itself isn’t working. This is especially hard to revert when you have modified scenes as doing a diff of scene data is extremely hard. So even before you start writing complex tests, it’s important to play-test your changes fully to ensure nothing breaks.

Play your game regularly and try to find bugs. Try different use cases. Always playing with the same gameplay style will cause you to ignore some bugs. Also let other people play your game. Add unit tests, which are often ignored when coding a game. This way, you can be sure whether it works or not when there is a change in the code. You will encounter fewer bugs.

Writing testable code is paramount. I've encountered situations where code disregards SOLID principles, resulting in tight coupling, notably in poorly crafted singletons. When a module requires testing, developers often find themselves compelled to launch the entire system, a process that sometimes involves convoluted steps. Such complexities lead to developer fatigue and create opportunities for bugs to creep in. It's crucial to decouple every module, enabling independent execution and testing with mock data.

Major features and functions within the game should be tested at least nightly, given the potential for lengthy processes. This approach stands as one of the most effective means to ensure these critical functions remain operational despite continuous development. By investing in test automation, you not only save time and energy but also allow your QA team to direct their focus towards more valuable aspects, rather than being bogged down by repetitive tasks.

One of the best (read easiest) ways of debugging games is to add a debug log in your script during development. You can take it one step further and add a messaging system on a Canvas that receives and displays debug messages on screen as actions happen on-game. This let’s you know if the game is performing actions as expected, if triggers are being hit, the physics system is working correctly, etc. However, a lot of developers forget to comment out debug logs during production. Debug logs are extremely performance intensive and should not be enabled in runtime. While it’s hard to go in and uncomment every kind of code, one trick that is beneficial is adding preprocessor definitions in your script around debug logs.

Colleagues often resort to guesswork, randomly fixing bugs, hoping for resolution—wasting time without ensuring proper fixes. Identifying the root cause is crucial for lasting solutions. IDE debuggers excel at this, minimizing broad project logging, reserved for scenarios like debugging race conditions. Leverage debugging tools fully: conditional breakpoints, watches, evaluation tools, and value peeking. Log all potential production environment exceptions to a remote server, e.g., Firebase Crashlytics. Ensure these tools initialize flawlessly.

Most common way of debugging is adding a debug log. Also you can add breakpoints and run your game. Always try to identify the source of the bug/error/crash. If you develop a mobile game for Android, you can use Logcat to detect some errors other than debug logs. Use error/crash detection software like Firebase Crashlytics. Check on it often. Try to identify the source of the error/crash by monitoring the stacktrace on bugs/crashes.

Before you start out on this, think about what it is your are trying to achieve: there’s a difference between commenting code and documenting code. Commenting code is when you add some helpful information within a function that explains what the next piece of code is going to do. On the other side, documenting the code is when you provide in-depth explanation for the purpose of a piece of code, how to interfaces with other constructs in the codebase, and finally, the interface of the code. Documentation doesn’t really help find bugs. It helps re-use and utilize your existing code. It helps make it useable for others, and that includes your future self. On the flipside, commenting can help find bugs easier.

I don't prioritize documenting in-house code. Don't misunderstand; code documentation is critical when end users rely on it, especially when creating tools for fellow developers. Keeping documentation current with each release is vital. However, for code accessible to your team, documentation shouldn't be mandatory. If your team struggles to comprehend the code, open dialogue is key. Enhance the code for mutual understanding, even after several years. Documenting code in constant flux is ill-advised. During intense sprints, people may alter the code but neglect documentation updates. This can befuddle future developers relying on outdated documentation.

The answer to the "How" question is the code itself. Therefore, it is unnecessary to add comments about "How" it works. Always add comments about "Why" a code is written the way it is. In this way,whatever is in the mind of the person who wrote the code will be transferred to other developers. Even after a while (for example, 3 months), it will make the person who wrote that code remember why that code was written that way. If you encountered a problem while developing a game and used a "hack" to solve that problem, be sure to mention it as a comment. If you have created a class, add a comment for what purpose that class was created. If you use documentation generator tools like Doxygen, you can easily document your code and export it.

It is important to note that a lot of good coding and debugging practices are connected to large teams or projects. Once you have a few dozen or more individuals working on a project, code commenting / documentation becomes a critical component, especially when it comes to debugging and / or optimisation efforts. However, time spent on drawing intricate UML diagrams or TDD docs that will be read by only a few individuals might be time better spent on development. Conversely, documenting every public function for a nice code doc might also be too much. As part of your development framework, it is important to set out a good strategy around what is your commenting / documentation practice, and work with Programmers and QA to define that.

There are many ways to keep the code quality in a project. Usually in game development there's a big the deadlines are so tight and there's no time for writing as many tests as the project would require, so following the standars of the company would minimise possible issues. Also at this time with tools like linters and static analysis tools to find possible problems is much easier. Also a good review process before releasing any code has to be mandatory. This last years also with the help of AI like copilot the quality of code should be higher

Depending on the project and its requiremtns, strong architectural structure does help prevent a lot of issues and bugs in the code. Forcing code to be in loosly connected data and logic allows for proper and pain free testing of smaller components. This approach does sound like an onion architecture, which can be expensive for some games, it does not have to be. Good architecture is always something that can help mitigate a variety of issues. Team culture and discipline does play a big role in this. Architecture wont fix all your problems, testing, proper debugging, documentation and qa will always be needed. The goal here is to fix a problem once by virtue of code structure

Conduct a root cause analysis on your bug tickets and ensure you label where issues should have been detected. Over time, you'll begin to notice trends, gaining a clearer understanding of areas for improvement. This could lead you to increase unit tests for functions that frequently causing problems or to introduce new testing measures

Deterministic functions with predictable outputs and little to no state reliance is paramount. In practice, write code that COULD be tested, but doesn't need to be if you are confident. Reading the code alone should tell you if the code is correct, save for *some* mental math. Ideally, these functions should also accept ANY input ranges (save for null, NaN, etc) and if they cannot, they should break noticeably via an exception or compiler warning/error. Even if the larger system you've made is incorrect and will not work for a given task, its individual functions should be correct and not need to be corrected, just replaced.