If you are building games in Unity, chances are you are working largely on the game client. This is the portion of the software that lives on the mobile device, PC, or console, and provides instructions to the game engine about how the game looks, how the features work, and how the player interacts.
If you plan to build any functionality that requires the game to talk across clients to multiple players, or for players to share data and interactions, you are going to need a game server. Typically this means building a separate piece of software that your game client talks to via APIs. As a game maker, this might mean learning a new server programming language, as well as learning API communication and creation, automation, and management of server infrastructure.
Why would you need a game server? Here's a simple example: Loot Boxes.
Imagine an in-game treasure chest ("loot box") containing a random prize for the player. The player is offered the loot box as a reward for progress in the game, opens the box, and receives the prize.
In a simple game with little or no backend technology, the prize is offered, validated, and rewarded on the client side. This is straightforward to code but is relatively insecure to any malicious hackers in the gaming community. If your game is single-player, this might be OK, but if players are playing together or competing with progress displayed on leaderboards, a single cheater can destroy trust with players.
To get around this, functionality that involves rewarding players is moved to a game server with authority over who gets what and how. With the server acting as the authority, the prize is offered, validated, and rewarded on the server-side. This is less straightforward to code but is the best practice and relatively secure against any malicious hackers in the gaming community. Because of this, the benefits of a server-authoritative architecture are great.
To set this up, a development team could write a custom backend server setup, but that would take considerable time and effort, even for experienced teams. Not to mention, the team would need to manage and scale the game server with developer operations (DevOps) experience as the game becomes more popular. Because of the highly specialized skills required to build and operate game servers, Beamable has created C# Microservices to make this entire process really simple for Unity game makers.
Imagine the same loot box example but with the game, logic moved to the server as a Beamable Microservice. The prize is offered, validated, and rewarded on the server-side as a Microservice. The Microservice code sits in your Unity project alongside your client-side code and is written in the familiar and powerful C# language. It is straightforward to code, easy to step through and debug, and is secure against any malicious hackers in the gaming community.
Beamable Microservices Example
As a Beamable Microservice, your custom game logic receives many benefits:
- Highly maintainable & testable
- Loosely coupled
- Independently deployable
- All your code lives in one place — shared between client and server
- Works in your development environment for easy debugging
- Microservice code is checked in alongside your client code to version control
With Beamable Microservices, programming a server-authoritative feature feels like a natural extension of your favorite client-side tools and workflows.
We are proud to announce the initial release of Beamable Microservices. To get started, check out our documentation and give our sample Boss Battle example a try!
First, go and sign up for a free Beamable developer account at: https://beamable.com/free
Then, download the awesome Boss Battle project sample for Microservices here: https://docs.beamable.com/docs/microservices-sample-project
Give it a try and let us know what you think! We'd highly appreciate your feedback on this. What works? What doesn't? What can be improved? Thanks!