Adding multiplayer support to a location-based game, as discussed in the preceding section, will not be easy. In fact, we avoided multiplayer support for our demo game because of the added complexity. Also, it was important to demonstrate that you could still build a functional location-based game without backend servers and multiplayer. In the end though, you are now here wondering how to add multiplayer support to your game.
In the preceding section, we discussed a couple of viable options to add multiplayer support: developing your own server, extending an existing platform and using an online real-time cloud database. These options may be attractive, but before we get into the specifics, let's review the fundamental problems of location-based multiplayer games, as listed:
- Game is continuous: Our game needs to continually save state globally for all players. If you don't appreciate the magnitude of that last sentence, take a second and think about it. When players reconnect, the whole world around them needs to be updated almost instantly, regardless of their last location. Depending on the amount of state you are saving, this could be a difficult problem. This is why we depended on those backend Google services for our game locations.
- Players only need to interact locally, if at all: Location-based games have received a lot of criticism and concern for allowing players to interact with each other, especially for games that target younger audiences. Therefore, you will generally only want to allow your players to interact through places, stores, or other virtual constructs regionally. An example of a regional interaction may be setting a lure on a location for instance. All players would be able to benefit from the lure, but not directly interact with each other.
- Game state needs regional filters: Players should only be able to see or interact with the world within their map area; even our ability to search the Google Places service from a location and radius needed to be further filtered. Ideally then, the game state a player needs to pull should support some form of regional searches. This can be tricky, especially if your experience with GIS is limited. Fortunately, we will identify a solution for this shortly.
Now that we understand the difficulties each of the solutions face, let's review the list of features each solution will need to address in the following table:
|
Features/Requirements |
Develop your own server |
Extend the existing multiplayer server |
Real-time cloud based database |
|
Security (Access) |
Need to develop your own access and user database. |
Use or customize the existing access |
Provides a robust secure platform with multiple options for user access |
|
Security (Data) |
Need to develop your own security mechanism |
Likely supports data protection and player cheating |
May need to customize database structure to support data security |
|
Game State |
Require a backend database to persist state |
Likely already implements a database |
Is a database |
|
Continuous game state |
Full control over database |
Want a server that supports MMO or MMORPG games |
Full control over database |
|
Isolating player interaction by region |
Use |
Would likely need to customize the world to use regions and/or |
Use |
|
Limit game state updates by region |
Managed by |
Managed by custom |
Managed by |
|
Scalability: Adding players |
Need to manage additional servers and infrastructure |
Need to manage additional servers and infrastructure, possibly extra license fees |
Cloud solution made to be extensible |
|
Extensibility: Adding game features |
Development, then rolling out updates to servers and clients |
Development and then rolling out features to server and clients |
Can easily version database and then update clients as required |
|
Data backups |
Need to support this on your own |
Likely need to support this on your own |
Likely supports database backups, but only at a certain level |
|
Infrastructure (servers) |
Need at least one server running all the time |
Need at least one server running all the time |
Cloud supported |
|
Price |
Inexpensive or free, depending on the available infrastructure (servers) |
Price of multiplayer software plus infrastructure costs (server) |
Likely free to start with |
* geohash will be explained further on. Geohash is a method of hierarchically representing spatial data on a grid using a unique ID that is a sequence of characters. This is likely difficult to comprehend without an example, so the following diagram may help to explain this visually:
Diagram showing how geohash subdivides the world at various levels
The grid shown in the preceding diagram is more representative of a tile geohash, whereas we would likely use the more standard Geohash-36, which just means each level is subdivided into 36 sections. Check out http://geohash.gofreerange.com/ if you want to see what the geohash for your address or city is.
Once we can isolate a location or region to just its geohash representation, this allows us to do very fast and efficient ordering of messages by region. For instance, if we know a player is at geohash 9q8y (San Francisco area, CA), then we could isolate all messages that started with that geohash. Therefore, if another player at Alcatraz Island has a geohash of 9q8znn and because the first four characters are different, they would not view activity from the other. The following is a screenshot from http://geohash.gofreerange.com/ that shows this visually:
Showing geohash levels of the San Francisco area
If you look at the map diagram closely, you can see how the geohash grid is further subdivided over Alcatraz. You can actually get down to almost a location point (geohash level 12), but you will likely never need to use that level. In the example, we are using geohash level 4, but that doesn't mean you could use a higher or lower geohash level to control your regional messaging.
As you can see by the preceding table, things generally point to using a real-time cloud database. Of course, you may still have your own bias towards a particular solution but hopefully, you better understand some of the pitfalls of each. That table does try to address the high level requirements but software development is always about the details.
There are a number of real-time cloud-based databases in the market, but only a couple that support direct integration with Unity. First, there is Firebase from Google, which is an app platform that supports real-time database and many other features like analytics, ads, crash reporting, hosting, storage and more.
Second, at the time of this writing, Unity is developing a real-time database that will likely support all the same features as Firebase. Unfortunately, Unity seems to always be one step behind its competitors and that option is currently in closed alpha, which means we will cover how you could use Firebase as a multiplayer platform in the next section.