Software Architecture In Game Development

There are many ways to create implicit coupling in your game project, including the codebase. For example, if you copy-paste some logic in your code, that's an implicit coupling. The easiest way to spot this kind of coupling in your project is to ask yourself this question: "If I change this, do I also need to remember to change something else somewhere else?". If your answer is yes, then there is an implicit coupling between these different parts. The danger with implicit coupling is that it's not tracked by any system, such as a compiler; thus, we rely on the developer's memory or attention to maintain this relationship. The last thing we want to do in game development is to take away the developers' attention or fill their memories with unnecessary information. This reduces their productivity. Also, relying on the developers' memory or attention is not a reliable approach for game development. Humans often make errors, and this is the root of many nasty...

As game/software developers, our job is to understand the system-under-develop, which is a game in our case, and then codify that knowledge. We can think about it as writing down or reporting what we've learned or discovered after researching a science subject. The same way we want our report to be understandable by the next scientist, we want our codebase (codified knowledge) to be understandable by the next developer. The only difference is that the language we use to express our understanding can be a bit weird to some people sometimes. This is because our codebase has a secondary user called compiler, and it doesn't understand the human language very well. Regardless of what medium we use, our goal stays the same, sharing our knowledge effectively. The key thing to keep in mind is that the primary user of a codebase is a human, not a machine. So, we need to pay attention to how human perceives things. For example, abstraction is what our minds are comfortable with and how t...

Have you ever wonder why we end up with large classes or methods with hundreds of lines, if not thousands. Surely, we don't start out with the intention to make them that large. We are even fully aware of this issue, but what happens that we do it anyway?  I would argue that possibly the strongest reason for this issue is naming. Here's why! If we want to break long methods or classes into smaller ones, we need new names for those small ones. On the other hand, naming requires a lot of cognitive loads and can be challenging, so we tend to avoid it. Instead, we keep piling more code into existing methods to bypass naming. Naming is one of the hardest yet most important things to do in software development, but it doesn't have to be painful. Naming is a skill, and with some practice, we can acquire it.  Our primary goal I'm going to explain how I do naming but first, let's step back a bit and see why we need to pay attention to naming. When we write code, our primary ...

Structuring our files in a Unity project can be challenging. In this post, I'm going to share my approach. There is no single method when it comes to structuring our files, but there is a single reason why we do so. I believe understanding this reason can help us a lot to choose the best method for a given scenario. Think of a situation where you have a few hundred files in a single folder. How difficult would it be to find a particular file among them? Pretty hard, right? Well, that's why we need to structure our files! We do so to make it easier to find them later. One approach is to subdivide the files and put them in subfolders based on their type, then their features. So we will have something like this: Project Scripts Player Movement.cs Attack.cs Enemy Pathfinder.cs Attack.cs Prefabs Player Character.prefab Weapon_A.prefab Weapon_B.prefab Enemy Dwarf.prefab Elf.prefab Materials Player Outfit.mat Weapon_A.mat Weapon_B.mat Enemy Dwarf.mat Elf.mat This approach works fine i...

Hi. My name is Behnam, and I'm a game developer. After some years of programming, I've found that I have a great interest in software architecture and anything that makes my life easier when developing a video game. I've been following software architecture talks and tutorials for a few years. The reason I'm starting this blog at this time is that recently I realized things began to make more sense to me, and now I have something to share. Also, I want to crystalize my thoughts by writing about them, which helps me learn them better. By sharing my knowledge here, I'm hoping that I can help other people to have an easier time developing video games by having a better architecture for their codebase. I'm also hoping to get feedback from other professional developers and improve myself. The target audience of this blog is intermediate developers who can comfortably create small-size games but struggle with anything more significant than that. I want to make it clea...