A New Foundation for Play: How We Developed Our Core Gameboard Tech

When we started developing new game projects in more recent years, we found limitations in our gameboard technology used by games such as Lily’s Garden. At the same time, we could also see that the match-3 gaming market was moving towards a very fluid gameboard experience – whilst the post-move visual animations are running, the players are already able to make their next move. This was a limitation in our own technology which we wanted to overcome.

And so a small team of Tactilers set on a mission to rebuild our core gameplay tech in order to increase our gameboard capabilities. We sat down with Lasse, who has been on the team since the very start, and Niels, who joined it a year in, to learn more about the why’s and the how’s of what they’ve been doing and to find out what this new tech enables them to do today.

Starting from scratch

Our ‘old’ gameboard tech was set-up in a way that whenever you made a valid input (i.e. made a match or set off an in-game booster), its logic would instantly get solved. This meant that you had to wait for the visual presentation to complete before you were able to make the next move. You basically had to tap and wait, and this limited us both in the experience we wanted to give to our players and in how we worked on the gameboard from the development perspective. Developing the connection between logic and visuals was often troublesome because time, as a concept, differed between the two parts. This is why our gameboard team decided to build new gameboard tech which allowed them to move time to the logic and give them the flexibility to do a lot of extra things on top of that.

Building gameboard tech, however, is no small feat. Gameboard tech is incredibly complex, simply because there are so many little things and combinations that can happen within it. It took a team of 3 people, including Lasse, several months to get it to the place they wanted it to be. They started off with creating core building blocks, made several different versions, and then started testing. It was very much a trial and error process. “At the beginning, you think there’s stuff that is really smart architectural design, but then you see that in practice it doesn’t really work. We learned a lot just by doing things, testing them and making changes afterwards,” says Lasse. The learn-as-you-go process is still ongoing now, 3 years later, but the rate of change is becoming less common as the team gains more and more experience with each new case.

The best thing is that this new technology can now be used to do practically everything gameboard related – whether it’s a match-2 board, match-3, merge-2, merge-3, or something completely different. This is because it is built on the core concepts of an interactive gameboard, instead of catering to a specific game genre. Building it from scratch gave us so much experience and insight into where we can go with our new gameboard tech. This is important because this new tech will likely be integrated into every new game project we start working on.

The harsh reality of building new tech

New gameboard tech was initially built for a game called Makeover Match. This was a brand new project which we started working on in 2021. As it was on a much smaller scale compared to a game like Lily’s Garden, it presented the perfect environment to build, test, implement and iterate in.

The team invested a lot of time into building this new technology and eventually more and more people joined the mission. It took an incredible amount of work, dedication, consideration and support to get it up and running, but the long-term benefits were worth the initial investment.

After they had the new gameboard tech working in Makeover Match, they decided to take the next step and implement it into Lily’s Garden. This presented a challenge on a completely different scale.

They knew going into it that Lily’s Garden is a monolith and that this would be a big task. Everything gameboard related basically needed to be re-coded from scratch. On top of this, the game had over 10.000 levels, which all had to work after being moved to the new tech, and the team had to be extra careful to not miss out on any edge cases. For nearly an entire year, they had to run Lily’s Garden on both game boards at the same time, to ensure that everything performed as expected. “It was a difficult time,” say Niels and Lasse, “But now we’re so incredibly happy that we did it!”

Once the new gameboard tech was up and running in Lily’s Garden, we were able to focus on using it to build new projects. Having all of our games based on the same core technology enables us to reduce the overhead. Firstly, it is easy for our game programmers to move in between projects because the code architecture is shared. Secondly, it makes it simpler for us to scale and maintain the tech. When we discover an issue in a core building block, we can fix it in one game and then easily update it in all of the other games as well. The new technology therefore provides us with a lot of benefits.

Clear separation between logic and visuals

Despite rewriting the entire system from scratch, the basic principle of having the logic and visuals clearly separated remains. This protects us from visual changes causing bugs in the logic and it’s something we highly value. The main difference is that the logic now progresses in sync with time, mimicking real-time behavior. Simulating time within our logic in this way allows the player to make moves while pieces are still falling (or performing other actions, like exploding).

This clear separation allows us to run our gameboard simulations in a more deterministic manner, which gives us time. It also gives us the ability to execute logic independently and at a higher tick rate, which increases speed. This capability offers numerous benefits. For example, the team now has quick access to logical test scenarios that help protect against recurring bugs. When issues arise, we have developed a tool that lets us replay levels exactly as they were played. All of this is crucial when developing something as complex as gameboard technology, simply because it has so many edge cases (just think of all the combinations a player can make!).

Separating the logic from the visuals also safeguards us in future improvements and enables us to stay agile and keep moving fast. If we want to be able to play the game fast, test new things and move forward faster with technical improvements (such as new AI tools), we do not have the luxury of time to spend on things such as waiting for visuals to play out.

Speaking of making improvements, when it comes to gameplay tech, we need to keep in mind that even the most minor changes can have a massive impact on the gameplay experience. For example, if we speed up booster logic (like making all the rockets go off at the same time), it completely changes the outcome of player moves, which can then alter the difficulty of our levels. So we always have to keep these things in mind when trying to optimize the technology.

What helps us to maintain high quality of everything that we do though, is strictly following the same core coding principles as a team. These include clean code, SOLID, DRY and unit testing whenever possible. In particular on the logic side, we’re trying to keep things neat. On the visual side, however, we try to be a little bit more pragmatic. Here, we try to focus on what will make the levels fun to play and appealing to look at.

Building customized tooling

Building our technology from scratch has also allowed us to develop a range of customized, shareable tools over time. These tools include asset management, improved A/B testing capabilities, better data gathering, level replays, test scenarios, level search tools, level bulk adjustments, and many more.

Being able to share these tools across our teams saves us considerable resources, which can instead be spent on enhancing the core gameplay experience.

Writing this kind of modular code takes a lot of time and it took the team a lot of reviewing, testing and re-writing to get it right. But the team believes it’s worth the effort and once it’s all in place, it gives them the ability to do so much more with this technology long-term.

A great example of that is the fact that all the different game teams can take these core building blocks to construct their own projects. The teams have the freedom to use the core gameboard tech however they want in order to create the logic and the game feel they wish to give to their players. This means that Lasse, Niels and their team do not need to involve themselves into the details of what they are doing in other games and can focus on supporting Lily’s Garden gameboard and the core tech itself. Lasse adds: “We want to give the game teams the freedom to express themselves as they want, and we just support them along the way with these core building blocks. It’s about guiding them, not limiting them.”

Plans for the future

Now that the core building blocks are in place and being used across a number of projects, we can allow ourselves to dive deeper into the visual side of things. This means that if an artist or a designer has an idea, the programmers would like to be able to support its implementation using this new technology.

For performance reasons, the gameboard programmers also started looking into the areas where they have more heavy-performance on the logical side. They are currently exploring using Unity’s Job system*, which will enable them to, at least in some cases, enhance the performance drastically.

To support this testing process, the team started a small book club for gameboard programmers. The aim of it is to provide a space for deeper discussion on how to improve the general look of the architecture when using the Job system and how to integrate it best within the existing tech structure at Tactile.

* Unity’s Job system – The job system lets you write simple and safe multithreaded code so that your application can use all available CPU cores to execute your code. This can help improve the performance of your application.

About the co-authors

Lasse Beck Knudsen has over a decade of experience in game programming, having worked on a variety of projects both in Denmark and in the UK. He joined the Tactile team in 2018 and has since then grown into leading the efforts of all core gameboard related things.

Niels Meijer started his journey in the gaming industry in 2017 back in the Netherlands, where he spent the first years of his career working on city builder games. In 2022, he joined our team and after supporting both Lily’s Garden and Makeover Match productions, he settled on the Gameboard team. A fun fact about Niels is that he used to run a (quite frankly very) popular YouTube channel about Unity development.