How to create a game code that can be sold for 40 million dollars?

You may be reading this article because you are interested in learning more about code quality. Or perhaps it’s because the $40 million caught your eye. This value seems very attractive to most of us. Why? Because we perceive it from the perspective of a personal financial situation. For that amount of money you can buy a big house, nice car, eat in the best restaurants, travel around the world (probably for the rest of your life) and many more. Your thinking process changes when you consider this project from the perspective of a billion-dollar company. Now, the decision is based on frictions, alternative costs, salaries of several people involved in the process, investment vs. potential ROI (return on investment), scalability potential and the list goes on. With that said, there are a few important points of reflection.

Value the product from the perspective of the potential buyer, not from your personal finances.

I have observed similar problems while working as a trader. After some time, I realized why my colleagues struggled with scaling their strategies. Even if their results suggested moving forward, whenever someone reached a salary-like daily result, he or she got stuck. We, as humans, have a tendency to compare, thus setting some psychological anchors. Most of us dream about making lots of money, but not everyone is actually ready to do it. If you don’t want to be only a dreamer, prepare a set-up for a big deal.

It is not only you as a seller who thinks about a reasonable price. It is also the buyer. If the buyer perceives you as an “individual”, due to a psychological barrier, it will be hard to exceed a certain financial threshold. It is more advantageous for a seller when it feels like a corporate transaction.

We have to face the fact that it is not about the code, it is about the product. Poor code can only be a deal breaker.

As a developer, I find this very frustrating. It often feels unfair when ugly games with terrible code sell better than polished products with super clean code. In order to understand it on a deeper level, let’s consider the main reasons to pay big for a game:

• Product already has a user base, which should simply return an investment
• Title/series is already well known, so the game has a potential for strong organic growth
• By having all major games in a category, buyer can create oligopoly on the market and in result decrease cost per install (less competition)
• There is a long-term vision for improvements, which will give better performance

From this perspective, businesses focus mostly on potential income. Further development and maintenance is considered a cost. When considering acquisition, investors use a simple equation: the potential income divided by the total cost has to exceed a minimum ROI. Risk is an additional validation here. Less uncertainty means easier decision-making. The cleaner and more readable the code, the less work it requires (lower cost) and the more predictable it is (lower risk).

Let’s remember that a potential deal is not the only reason to keep high quality code. It is just easier to work on the product, especially if there is a chance that some developers will change during the production cycle.

No one will love your code, if you do not make them love it.

During my career I was “fortunate enough” to work on somebody else’s code on several occasions. I also observed other developers working on alien code. For sure, those were periods when the most swearing happened in the office. Forget about appreciation if the code is unknown. On the other hand, working on a new project very often brings a lot of satisfaction and a need to show off brilliant solutions. So, how does it happen that the same piece of code that makes one person proud, makes somebody else sick later on? It happens because of a lack of understanding! The conclusion is simple: if you want to make people appreciate your work, you need to really showcase it. There are tons of good examples on the Internet: blogs, vlogs, presentations, documentations, you name it. Just choose one format and present the best part of your work. By publishing it, you may impress potential buyers with your solutions. Future developers, and maybe even game users, will also appreciate it.

Now we know what the role of the code is in an acquisition deal. The question remains, what has to be done to create “high quality code”?

Prepare an environment for remote configs

Remote config is probably one of the most important things to have in a project. As soon as a new team takes on a project, they will probably want to change several things in the game and check some hypotheses. It’s way easier to think about configs during the development stage rather than later on. Even if you don’t know how to use tools like Firebase, just prepare objects with all configs. If possible, try to define validation rules, it can be very helpful. Interchangeable systems can be quite easily separated from the code and moved to an external solution.

Wrap your game with analytics

There are some basic analytics, like retention or information about in-app purchases, but this is just the tip of the iceberg. Only with good data, can a product team deeply understand what is happening with the game. Well designed events distinguish gut feelings from reality. Combined with remote configs and A/B test possibilities, analytics become a very powerful tool for constant product improvements (without additional releases)!

Separate logic from visuals

Visuals are usually the slowest part to be computed. They can take more than 99% of computation time and because of that, without a proper separation from logic, it’s very hard to simulate a lot of games in a short amount of time. It implies problems in creating solver algorithms, AI, etc. Secondly, with separated logic, it’s much easier to prototype different gameplay mechanics. The only drawback is that it takes a little bit more time to design architecture at the beginning of a project.

Surprisingly, it happens more often than one would think. For perspective, on three separate occasions I’ve worked on projects without separation. As a result, none of those products could be scaled efficiently, so a refactor was required. In one case, the entire project had to be refactored (an additional 6 months of work). Another time, most of the gameplay had to be refactored (an additional 2 months of work). The third case was even more time consuming.

If the refactor cost is so big, why don’t projects start from a proper solution?

• It’s not straightforward and some junior programmers don’t know how to do separation
• It slightly increases the initial development time
• Team is not aware of the problem until it occurs for the first time

None of those reasons is good enough, as the cost of further refactoring is exponentially higher than the initial effort. If you are a programmer, just learn it. If you are a product owner, consciously demand it.

Avoid custom solutions for complex systems

It’s hard to say when it’s more efficient to buy or implement a ready-made solution (like tweener, networking system, tool for localization, etc.) and when it is better to write it by yourself. The most common mistake is to compare the cost of writing (mostly time) with the price of a package. This is a good starting point, but what is very often omitted is future development and maintenance. Some tools need constant updates and it is not always easy to prioritize that later on. Another important aspect is onboarding for newcomers. Specialists would rather learn tools that are used across companies, instead of “useless” knowledge that is specific to a single organization.

It is very advantageous to have confidence during programming. If code doesn’t work, it is usually easier to find a reason with well-known systems. They have good documentation or forums full of solutions for similar problems.

With a well-known system it is also much easier to do technical due diligence during a potential acquisition!

With the above advice I am definitely not saying that custom solutions are always bad. I am saying, however, that you should think at least twice before jumping into implementation. The strength of the human race is cooperation. If someone has already solved a problem and overcome various obstacles, maybe it’s worth applying their solutions and focusing your efforts on something else. You will have plenty of different challenges during game development.

Don’t spread similar code all over the code

At the beginning of their careers, developers learn to not create very similar methods, but to wrap the same code to a singular solution. You would be surprised how many components are not omitted from this perspective. In order to understand what I am referring to, let me name a few examples:

• Input system scattered in plenty of objects that are updated each frame
• Invoking analytic events by string from all over the place
• Localization components “hardcoded” to specific places
• Creating similar assets for UI elements

While writing the code, think from the perspective of a person who is about to replace the entire solution. As such a person, you would love to have it wrapped in one place, so you can easily find all use cases. It’s also easier to distribute teams on a project that is divided into smaller modules.

Keep it in English across the entire project

Thankfully, most of the developers have English name conventions. Unfortunately, I can’t say the same about assets, comments, documentation, etc. First of all, you never know if your buyer will be from the same country, but it’s not only about that. During studio development you can run across highly skilled professionals (both candidates and coworkers) who don’t speak your local language. Do you really want them to feel unwelcome? Do you want to spend your precious time on renaming tons of content?

Try to keep your processes simple

For instance, do not overcomplicate builders and version control tools. During the development, you’ll sooner or later come across repetitive actions or things that are easily forgotten. Naturally, in cases like that, developers try to create tools that help in the process. This is good. One issue is that processes can later change, but those tools remain. This happens either because of lack of time or because of sentiment (especially when there was a lot of effort put into creation). As a result, very strange and complex creatures can be made.

Optimization, optimization and once again optimization

Optimization is important for so many reasons. There are general ones: speed of loading, while working on the project, space for visual uplift, possibility to release on low-end devices, etc. From the perspective of this article, a potential buyer can scale the project without a fear of the refactor preprocess. Even without refactoring, half-baked solutions slow down development in advanced stages.

Organize folders by content, not by people

As a new owner of the project, would you really like to look for something in folders named “Johnny”, “Leon”, “Angelica”, etc.? It’s crucial to set it up professionally at the start, as to avoid confusion with changes in asset management later on. This is important not only because of the number of files that need to change places, but also because of the version control tools (like GIT or SVN).

Final thoughts

Most projects aren’t created with the intention of being sold in the future. Still, a big percentage of successful games change owners at some point. Don’t limit your choices at the very beginning; it’s more strategic to keep your options open. In this article, I’ve focused on tips that are relatively simple to implement. Combined, they can be a gamechanger. I hope you will find them useful and they will help you to succeed with your project!

There are many other best practices that I haven’t focused on here. Some are so well-known that there is no point in repeating them. Some didn’t come to mind while writing this article, and some are simply waiting to be discovered. If you would like to join me on this adventure, you may want to consider one of our open positions in Huuuge Games. We are still on a hyper growth path, so you’ll definitely find a position matching your interests.