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.

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.

  • 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.

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

Wrap your game with analytics

Separate logic from visuals

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 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

  • 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

Try to keep your processes simple

Optimization, optimization and once again optimization

Organize folders by content, not by people

Final thoughts

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.

We’re a gaming company on a mission to build the world’s largest real-time casual gaming platform empowering billions of people to have fun & play together.