The technicalities of programming Free To Play games

Hi, my name is Matthew Stenquist and I’m a product designer / UX engineer, and former professional athlete ranked #4 for US snowboarding.

At night I’m an independent game developer. Currently, I’m the head of product and engineering at a startup in Sweden. Moreover, I’ve had my hand in technology and games ever since I could remember, and have been a professional developer / designer for many years and I wanted to share some of my experiences I’ve had F2P. My experience ranges from working on double AA games, to working on five plus mobile games over the course of my career. With them collectively having over 5 million downloads over the course of their lifespan.

In this article, I’m going to cover the basic details of building a Free to Play game from a programmers perspective. I’ll detail some coding techniques for going about making a F2P game.

However, there’s no “one size — fits all” formula to gameplay programming as you can approach each and every aspect from any direction effectively.

“one size — fits all” formula in gameplay programming doesn’t exist.

In games, you have free roam to do whatever you like. In programming, it’s the same. There’s no blueprint to follow, but rather a set of simple rules to obey. You have your variables, constants, floats, and so on. But when it comes to Free To Play game programming, things can be get a little tricky and I wanted to share some insight to the trials and tribulations that I’ve run into along the way as a solo developer / sometime’s non solo dev.

Let’s begin.

I found that hardest things code would be the data heavy stuff at the top, and the user interface stuff at the bottom. Now, here’s why.

Data, DevOps, and Validation requires lots of testing. Data takes some time to setup and get right. Analytics don’t always ping to the receiving server instantly and can have a delay to receiving whether or not your custom event even got registered. And in the worst case, if it didn’t, investigating why can be time consuming and hard to debug.

That’s because this falls under the umbrella of data-science and everything that coms with. It’s hard to test and validate whether or not certain implementations bring value at the opportunity cost to work on other features. But, we do know one thing. For analyzing metrics, and funnels to see our revenue stream. Data doesn’t lie. And that’s why for large scale F2P data is the focal point to ensuring one tweak here and there, either means a yield in higher conversions which equals profit, or losses in revenue.

It’s all about finding that balance and this requires a delicate balance to juggle to get right. Secondly, setting up cloud storage, and testing iAP shop validation purchases in the next big thing to focus on. This stuff is tricky to test because it requires re-compiling your build to test for changes unless you’ve got a Jenkins like continuous integration setup going. Nevertheless, this stuff is tricky to code and get right, and then to test because of all the ways it can go wrong, misreadings, and false negatives.

Players are going to spend our in game currency, purchased with real world currency to access consumables, and so on. So building in our soft and hard currency system is a big focus because at the end of the day we want to monetize our game. Why else would we be building these features then?

Thirdly, we’ll need to set up a DevOps infrastructure. This is crucial if you’re not a solo dev. As a solo dev you can go all wild-wild west on your setup and skip CI, A/B, Jira, and all the glitter and jazz that comes with DevOps. But if you want to properly collaborate with others, having a DevOps infrastructure is crucial to any F2P game’s development lifecycle, and production value.

Now, let’s talke a little about gameplay reward validation in advertisements. This is more of a gameplay programming domain that requires just lots of testing to ensure that when a player accomplishes something and checks off the correct value, that they are rewarded for their work. Just ensuring that our players have received rewards, and logging them isn’t too complex to write but it can be somewhat cumbersome the larger our F2P title is.

Storing Values

Cloud storage and serialization can be hard to implement and test correctly especially when using native libraries. Each OS vendor has their own way of implementation and it’s best to either use a pre-made framework that handles cross platform functionality instead of rolling your own. It’s great to roll your own to learn how these vendors work, but it’s a time consuming task, and generally easier to mount onto a supported API that is used by other developers since there is a community established already.

You’ll still be writing code specific for that api but will save yourself a whole lot of headache down the line.

UI and Gameplay Code

Make sure you gameplay code isn’t being directly affected by your F2P infrastructure. UI code is simple, but can get dense. Building virtual economies, creating randomization, and gacha mechanics takes a lot of finesse and A/B testing.

Your UI code should be clear to read and write, and shouldn't interfere with the crucial infrastructure you’ve built above, but it should also compliment it so both areas communicate with one another.

These things aren’t actually the most difficult to code. The logic is fairly simple, and you can roll with just a simple int, float, or bool to validate a true/false setting, enabled or disabled bool, but whatever you like for the logic requires that when spawning and saving things should be written with clarity, notes, and documentation so that if someone else is reading your code they don’t come over and strangle you to death.

Pass in gameplay code storage amounts clearly.

There’s no need to complicate a virtual economy. These things can start to get incredibly tricky when you start randomizing amounts, and doing lots of statistical wizardry. You should feel comfortable working with curves to build out a virtual world’s economy and mapping it out in excel to see where the challenge curve is, pinch points, and friction lies within the empirical data. However, registering and keeping the amounts should be simple to code as the project scales so you’re not juggling too many different variables.

Lastly, the depths of data science

Now, this last section covers the data science of game programming. It can be an incredibly tough area to get right in coding, and has a breadth of depth that I encourage you to explore. From statistics, to machine learning, all the way to AI data science is the backbone of gathering empirical evidence in whether or not thing can be improved, projecting and estimating whether X feature will work, and creating predictive models.

Now, I’m terrible at math. I whole heartdly destest math and this is one area that I struggle in completely. It’s not my field of expertise or strength, but when it comes to F2P game design, especially if you want to be a top coder designing the economies, and mechanics to a level of detail that reinforces data science, then this is an area that you should heavily focus on.

Now, for me, I use a light spread of this kind of programming in my games. It your basic events tracking for analytics via Fabric, and Firebase by Google. And it’s also monitoring and setting up event handlers that process and record KPI’s that I designate.

This stuff is especially important to learn and code in if you’re serious about your game. Because, you really want to understand and create a mental model, along with other phyiscal models that allow and enable you to make better informed decisions when you patch or create a new game.

So, to summarize everything above. Start with the heavy lifting, and gradually work on the supporting pieces that will develop a solid foundation for you to work off of. Make sure each specific area of domain can communicate with one another and if they need to, to lean on one another. But also make sure they stay compartmentalized to keep things clear and concise.

AAA Game Developer. Product Designer Startup Co-Founder, Former Professional Athlete, Software Developer. TedX/ Keynote speaker.