In-Play in endless games? Exploring… Dynamic Ads

Infinite games are incredible. Endless runners, rogue-likes, never-ending platformers, and so many more genres create an immense amount of playtime and offer potentially limitless gameplay thanks to one amazing feature: dynamic instantiation of prefabs during runtime.

For any non-technical readers, a prefab is a package of game components. While a single object might be a building in a city, a prefab could be made up of an entire city block with lights and NPCs that can pop into life when the player needs it to.

Think back to when you played the floor is lava when you were younger. Remember how you would stand on a cushion, step onto another cushion, and then move that last cushion in front of you again as another stepping stone? Procedural generation in games is similar in concept. The next chunk of game world loads as the player needs it, and the one behind them unloads to free up CPU. This process creates a truly unique genre of game, but it also created challenges for our tech team.

“Why isn’t this feature easy to add?”

It seems like it should be, right? We’re already allowing devs to put ad placements in their games that are dynamically bid on during runtime, why can’t those devs just add the same placements as part of a prefab? As part of a game ‘chunk’ that will be loaded during gameplay creation/destruction

The main answer to that is, simply, analytics. Data. The thing that underlies all platforms and allows advertisers to reach their intended audiences, and allows devs to earn the money to keep their business running.

Let’s break it down a bit further though.

A normal prefab in an engine like Unity is a pre-configured bundle of game things. 3D models, scripts, dynamic light sources, etc. That bundle is saved as a prefab and when the game needs to instantiate it – to create that bundle during runtime – it makes a copy of that bundle with a different internal instance ID. When that bundle is destroyed, the ID is too and the prefab is simply gone. Until it’s needed again.

Traditional Admix In-Play banners aren’t built for that creation/destruction cycle because they have unique identifiers attached to them that monitor performance. We built our platform to allow developers to know how each ad is doing, how much revenue it’s generating, how visible it is, etc. But tracking like that is impossible when the banner is created, given a random ID, then destroyed. Well, not impossible but you would end up with long, long lists of data points on the developer platform that would make it hard to tweak, optimize, or even read how your ad placements were doing.

We had to figure something else out.

What we figured out

The actual solution we found was pretty sleek and simple.

The problem, in short, was to create ad placements that could be a part of a prefab and maintain their ID across many creation/destruction cycles.

The answer was to create a placement per prefab so that the ID for that type of placement was consistent and, rather than make it deal with the creation/destruction cycles of prefabs in the traditional sense, we just move it around to where it needs to be.

So, in an endless runner, a chunk of map with an ad in would load, the player would run through it, then the same chunk of map would load again later and the same In-Play placement from the last time it loaded would just zip over to this new location.

But what about performance? If my endless runner is just full of floating, unused ad placements behind the player then my CPU will struggle, right? 

Not at all!

We know that endless runners are great for lower-end devices because they have pretty few assets being handled at any one time thanks to our good friend the prefab. Performance in all games, and especially games like this, matter to devs and players alike. It can be the difference between fun and frustration.

Everything we do at Admix is performance-focused too.

Thanks to another feature called Smart Load, read an article about that here, any ad placement that isn’t visible enough or close enough to the player is switched to an inactive state. It isn’t destroyed, but it’s not using up any of your game’s precious CPU to render either. That means that it can be moved around as the prefab it’s attached to is spawned, performance data for that placement is accurately gathered, and your game is as fun and uninterrupted as it should be.

Win-win.