How Forager shows us the importance of Game Architecture and best practices.

You may be familiar with Forager, an indie game released in 2019 focused on exploration and building. And you may have also heard about the controversies that occurred during and after the development of this game, ranging from a completely messed up script base to bugs, a huge amount of expansions and even disagreements between those involved in the game's production.

But for our discussion, what matters is how Forager exemplifies the importance of architecture (Game Architecture) and planning in game development.

The tendency is that the more experienced a developer is, the more careful they will be with the way they create their scripts and build game systems. In other words, the greater their concern with Game Architecture will be.

Game architecture is just defining how the different systems and components of a project connect and interact with each other. A close example in real life is the floor plan of a house, which determines the layout of the rooms, the infrastructure and how they work together. This is the basis for building a game and directly affects its quality and scalability.

It is common for more inexperienced developers to leave this planning aside and think that "the important thing is to make it work", which leads to eventual poorly structured arrangements and connections between scripts and systems.

This was the case with Forager. Lead developer HopFrog admitted that he had failed with the core game, and highlighted how the game's code was built in a disorganized manner and with many "hacks", which made it difficult to maintain and add new features.

The situation became so critical that the idea of ​​multiplayer for the game was completely abandoned, since the only way to make it possible was to redo the entire thing. The fragile code base and the high turnover of programmers, who preferred to isolate their tasks from the main code, turned the problem into a snowball that almost compromised the project.

Of course, Forager's case is much more complex. But, as we mentioned, the main point here is to show how a lack of planning, experience and good practices can compromise the construction of a game in the long term.

So, how do you create a good Game Architecture? Well, it depends on many aspects, such as the genre of your project, the platforms on which it will be available, and the mechanics involved. We won't go into this subject in detail here, but we can give you some tips based on our work:

• Keep scripts and systems generic: A good exercise is to ask yourself, "Could the way I'm coding this script, or set of scripts, be used in another game?" If the answer is no, then you may need to think about the way you're coding. Obviously, there are exceptions.

• Separate logic, sound effects, visual effects, and UI control: among the various design patterns, the one that will save you the most trouble is the segregation of functions. If you are creating a health system, do not put the health bar system (HUD), the sound effects control (hit sound, for example), and the particle control in the same script. Separate them into scripts with specific and complementary functions.

• Long-term thinking: It's important to design your game systems with the idea that there may be changes, big or small, to the project in the long term. A good question to ask yourself is "how difficult would it be to implement change X in my project?" If the answer is "very difficult", there may be areas for improvement.

• Refactor and rethink your scripts: Sometimes, we learn new features that can make it easier to understand, use and/or perform the systems we currently have. Or, after finishing a system, we fully understand its needs and thus have ideas on how to improve it. If these are the cases, consider not moving forward and dedicate yourself to refactoring what you already have (you will thank yourself later).

To conclude the subject we want to emphasize the following: don't be paranoid!

Overthinking can hold you back, and especially when it comes to solo projects, it can make the development experience quite unpleasant. The "I'll make it work first and then figure it out" approach has its advantages. In fact, it can be a great idea to use this approach depending on what you're programming.

Keep in mind that once everything is working, you will have a better understanding of the systems, their behaviors, and their needs. This will help you a lot when rethinking and refactoring your game. But never let it snowball.

Over time, it becomes easier and more straightforward to build systems and think about architecture.

Believe in yourself and trust the process.