Dynamically assemble and match players
Dynamically assemble and match players
Connect cross-platform accounts & identity management
Grow and commercialize your game
Build a vibrant community
Track player progression and game state across platforms
Track, engage, and retain players
Visualize game metrics
A single player game, to many, also means “a game which is not online”. However the opposite is quite true these days. Games like Spelunky have daily challenges, Saints Row and Just Cause have leaderboards, XCOM 2 has a global stats page and GTA 5 and Red Dead 2, while not predominantly single player games, have companion apps which allows you to influence your single player game in a variety of ways.
There are also quite a few good reasons to have your single player game have an online component, even if it exists under the hood out of sight of your players. So let's dig into them.
Even the best designed, most popular games have certain features / functionality that just don't work for players. Sometimes players will vocalize this and sometimes not. But even when a player base is vocal about something it dislikes in a game, it can be hard to get to the root of the problem.
Is it a gameplay design issue?
Is it a UI/UX issue?
Is it something deeper?
By using telemetry to capture your user’s journey through your game you can identify, highlight and scrutinize the actual player’s journey through your game on a massive scale.
One example comes from when I worked on a survival game, the team were updating the game biome by biome, forest area gets a content update one patch, city area gets a content update the next, etc.
At some point during development we integrated a telemetry service and discovered that players didn't really spend any time at all in the snowy areas of the game. In order to figure out why, we rescheduled which areas were getting updated to put the snowy area last and give us time to collect the data and act on it.
It turned out to be a combination of things, some of which had been brought up by the community but large factors went unmentioned. Most important was that the risk / reward just wasn’t worth it in the end, we came to that conclusion from tracking time spent in the biome, player stats, actions carried out and loot received.
The design team spent some time addressing these issues, releasing small changes along with the other biome releases. When it came time to deliver the big Snowy area release, the team were able to focus on making great content that suited the area and play style it required.
Storing game logic online also gives you one huge advantage. You can add new content to your game extremely quickly and easily.
You can add quests, swap in / out NPC’s (or even create entirely new ones if your game has a character creator!), and daily challenges. You can even run once off events to help drive player engagement. You can retroactively grant players an item they may have missed due to a bug.
All told, there are countless good reasons to store game logic on the server.
Let’s imagine you are creating an action/adventure/RPG game. Your game has gone live and by all accounts it’s doing incredibly well, however, for some reason, a certain percentage of players stop playing when they reach a certain boss.
This boss was perhaps always considered tough by the QA players, but for some reason, the general public seem to be having a harder time with it than normal and the frustration is causing them to just give up.
If you were to address this issue without Server Side Game Logic, you would need to re-balance the boss, perhaps using Telemetry to discover what it was about this particular encounter. Perhaps you notice the time to kill for this boss is particularly high and players either get overwhelmed or just give up.
Perhaps you’re tracking the attacks the boss is doing, and notice that one particular attack is causing a lot more damage than expected, combine this with player telemetry and you might discover that players are missing a particular perk designed to mitigate that type of attack.
Once you discover what the balance issue is, you create a patch and submit to the platform holders for QA, Cert and eventually Release.
This is a costly process for such a small fix.
However, if you had a backend powering your single player game, you can store the attributes of any / all enemies in the game. You can tweak this particular boss's attributes, push that to the Dev / QA environment for testing, then release it to Live once it’s ready.
You could have a balance issue fixed before the first week of your games release is up, ensuring a happy player base from the get go.
You’ve also taken the Platform Holders out of the equation, the costly certification process can now be reserved for major title updates.
Your player’s save data and progress can be easily synced to the cloud, while most Platform Holders already provide this feature, it locks you into their ecosystem.
In the ever evolving cross play ecosystem, you can potentially have players purchasing multiple copies of your game to continue playing on different platforms in the not too distant future. We’ve already seen it with Destiny, Fortnight, and even Civilization 6, Witcher 3 and Divinity Original Sin on Switch.
When another platform sells your game, owns the player account and processes all non-client interaction. Is that player truly yours?
Having your own backend allows you to form a direct relationship with your player base. Your players can still come from other platforms like Steam, Epic, Xbox or PlayStation, but by logging into your platform you own the player record.
Depending on the data you collect, you can market directly to your fan base, you can tailor your marketing efforts specifically to the games they play, or even how they’ve played your game.
You can use this data to customize each message directly, you can even reference their in game activity / achievements to really help forge the feeling of a connection between the player and the game.
Encourage your players to link their social accounts and talk about your game to their followers, implement a rewards system to incentivize players to play your game.
Give your most loyal players access to new features and potentially early access to games/
This is a common misconception, it fully depends on how you want your game to work of course, however, given that you are developing a single player game, you can have players on slightly different versions of the game balancing / available items or quests and not have it be a problem. It is not much different from players of single player games not being on the same title update.
The general integration flow for something like this is relatively simple:
We can empower you to make your single player game more connected. Our services can enable all the functionality we discuss in this post and a whole lot more. We don’t believe there is a one-size-fits-all solution for backend services, so we will help you customize and build the tools you need to deliver a truly great and unique game.
Reach out to the AccelByte team to learn more.