How do you update game code for new requirements?

Planning ahead should not be just a pre-production task. It should be involved in every step of your development process. Be it artists, programmers or designers, everyone should be thinking about all the possible changes that could be added at a later stage and implement the current task accordingly. A programmer specific example is, when they are writing code, they should follow SOLID principles to allow scalability and adaptability at a later stage.

What I do is following: Absolutely: 1. Outline the game plan or flow in FigJam for a visual grasp. 2. Discuss logic tweaks and their impact with teammates or stakeholders. 3. Consider how changes align with good principles. 4. Delve into the code, turning plans into reality. 5. Rigorously test to ensure it meets expectations. 6. If everything checks out, confidently roll out those changes!

Important to keep in mind that what is your user is benefiting from updating the code. Product development process should start with a clear requirement of how the user journey should be changing, then comes the solution delivered together with coding.

Ideally, you want the changes to be backward compatible (at least with the previous good version) so in case of major issue you can roll-back a feature without breaking anything. If features are possible to remotely enable or disable at runtime, that makes it possible to do selective testing and progressive deployment of code changes.

It's crucial to make sure new features seamlessly integrate with the existing codebase and preserve system stability when adding them to a game's code. By facilitating the injection of necessary dependencies, Dependency Injection (DI) improves the modularity and adaptability of programming. In addition, Code Refactoring speeds up the process of adding or changing features while improving the quality and readability of the code. This iterative cycle increases the application's flexibility and long-term robustness, which lowers the risk of mistakes.

Version control is the first thing people should do in any project, not even create a new folder first. Also implement a proper VC workflow can save you from hell!

Using version control not only helps in moments when we want to revert to a previously working solution, but is also a great way to create backups of your code on another machine! Anyway, imagine that you suddenly need to build the latest working version for a friend, but you don't want to lose your ongoing, unfinished work. What do you do then? Just learn it first and start using it, just like you avoid starting a fire with stones. There are many other advantages, but these first ones are the most important.

It is not only for sake of improvement, it is basically essential for any form of collaboration in the team at any development, but gamedev especially. Not just developers, design, qa, art team. The better your team incorporates version control into their habit the stronger will be their ability to exchange their work results

"Some popular version control tools for game development are Git, SVN, and Perforce." Git (even with LFS) and SVN are only usable for small or medium projects. Typically game development involves versioning binary assets, builds, debug symbols, etc... and neither Git or SVN are able to handle that efficiently at scale.

It's really important to use version control, whilst toying with a prototype. You never know when you'll need that one really cool mechanics that you implemented ages ago.

Maintain SOLID principles, in particular, make as many discrete functions with verbose names as possible rather than massive functions that are hard to understand. You may find that the code used for latter features is better written than earlier code, in which case incremental improvement and testing each change is a better choice than overhauling all at once.

If you neglect refactoring, your code will eventually become tangled and hard to manage. It's essential to refactor whenever your solution appears to deviate from its original purpose of solving the problem efficiently.

There is always is a certain level of technical debt at every project. We can't make everything ideal at design brainstorming sessions, you unlikely will be able to do everything ideal after years of writing your game. Premature optimization is the root of all evil in 97% of cases and we should not sacrifice features for some improvement that might even not work out. Have a bigger idea in head, move on with actual issues. Put those ideas in scope, implement some improvements when you see a window for those. Features come and go, optimizations happen at various unforeseen in advance scenarios. Deliver to your manager a need for a refactoring when it is needed and before it is late, show why it is important.

Leave the code always a little better than it was, I can advise to use the Boy Scouting Rule principle. - happy coding!

Consider refactor only stable parts, don't bother much about parts that will be changed due to game design tweaking. Do not afraid cut out code that not in use (you always could it revert from older commits).

Setting up testing is important, but what happens to all those test results? Set up daily and weekly automated reports highlighting problem areas (crashes, FPS issues, memory usage and load time increases), follow up on recurring issues, and clean up often - people WILL ignore them if they're always full of stale or irrelevant problems.

It can often be useful to put Debug logs in your code (for example when a collision happens or a function is called), as you play, to make sure the game is doing what you expect. This is especially useful when testing physics interactions (which are notoriously hard to test using traditional programming methods).

Unit tests are not a panacea for all issues, especially when your software integrates with other external third party components. However, it doesn't mean that you shouldn't test your code. Tests, along with debugging, are the most effective methods for identifying issues. Make use of every available moment :)

Consider test not only stable parts of code (i.e. render or physics), but also some script test of art and other game data if it not corrupt or even exists in build. Don't try to cover with test all codebase, it not reasonable, spend this time on more game play polish iterations.

Pick any code standard you like, just make sure all follow it. Treat this as collective code owning, when any of team can switch to other part of code without any hassle to read and understand what was done and continue to develop from there. Maybe it would be good idea make script when commiting to version control to check if all according to standard. Or enforce some lint in you editor.

I would not put it as simple as "follow". Don't take me wrong, coding standards are as important as having a reviewer in journalism or literature - your code is the a form of creative on its own and being made in one style will help a lot at reading and understanding the system. And that is frequently undervalued aspect of development, the better you can understand the easier it is to work with or to integrate new people. Coding standard is important but don't do strict standard just for the sake of being strict.

In today's digital age, a multitude of online resources, including generative ones, are easily accessible. Utilize them, but always prioritize safeguarding your privacy. I've employed this strategy successfully in numerous games. If you skip learning from other's mistakes, you'll continually replicate those errors, wasting your time in the process.

We all want to be a legendary Lone Wolf that achieves the great success in spite of circumstances. That is usually barely possible and a lot of us have failed to do good in pursue of making it all better. Online is cool, but your colleagues are your best help at any occasion. Gamedev is one of the most complicated industries in Development, there are far more aspects to consider when making the game and you unlikely can know it all yourself and the biggest strength comes from sharing. Ask, learn and share.

Most programmers work as a part of a team. It’s incredibly important to have a good pull request or code review process. It not only helps avoid bugs and improve code quality, it also allows juniors to learn from their seniors and for everyone to be aware of how systems work in other parts of the code base you might not be actively working on.

Please consider the impact your changes will have on the existing user base. Even if you've followed the steps and advice above, and submitted an exemplary feature, your work is not done. You may want to document your changes, from both a user and developer perspective. Be sure that any users of the new feature understand the feature's purpose and intended use, how to access and use the feature, how to submit bugs, and who to approach with questions. Depending on the complexity of the feature, you may also want to provide extended documentation for developers who may need to extend your feature in the future. Note the overall technical design, weaknesses or issues, and any future work that you think may add value.

I would add to that some way to test the impact of this new feature, i.e. from a BI standpoint. Consider adding analytics, A/B tests, and KPIs, to measure this feature's success, is it being used? Do users have a particular dropoff at any point in the feature's user story? Keeping this in mind while developing a new feature can help you determine the feature's real-world impact more easily. It can answer both business questions as well as identify technical problems with a new feature.

I can't stress enough the value of using feature flags in development. They streamline both testing and development, making them significantly more manageable. especially, with sizable content, the risk is minimized since you can effortlessly toggle the new code path on and off from the backend. Alternatively, granting control to the player through advanced settings or something similar.