In a series of posts we’ll do “Firebase From Scratch”, an introduction to Firebase and its concepts and ideas. Hopefully, reading this series will give you a firm grasp of what Firebase is and what it can do.
- Part 1: Introduction
- Part 2: Diving In
- Part 3: A Maven Interlude
- Part 4: Games, Services and Tournaments
- Part 5: What’s In a Server Game Anyway?
- Part 6: Activating Games
- Part 7: Actions On The Table
- Part 8: Services
- Part 9: Custom Authentication
When it comes to the server code in Firebase, we divide it into three different things, three different artifacts which all have different responsibilities. In the last episode (see “A Maven Interlude“) we kind of skipped past them, but let’s take a closer look shall we?
Game
This is the heart of the game server side. It is what receives actions from players and decides what is going to happen next. The game is packaged and deployed as a GAR archive; it is easy to remember as Game Archive. When you start out in Firebase land, this is the first kind of server code you’ll write, and for simple games, it might be all you need.
Service
But if you write several games and want to re-use components between them or if you want to “extend” Firebase? This is where a service comes in: A service is a piece of Java code which is shared across an entire Firebase server. It is packaged and deployed in SAR archives – that is: Service Archives. Here’s some examples of what services are really good for:
- A random number generator that can be certified and reused
- User management. In fact: in order to customize the Firebase login procedure you must write a service.
- Any kind of access to a 3rd party system, such as payment gateways and back offices
- Statistics collectors that can be re-used by multiple games
- Etc…
Tournament
Firebase has support for tournament: where many table or game areas compete against each other. The tournament code in Firebase is special: it does not depend on any particular game. So in theory you can write, say 3 different card games, but only one tournament which would handle all 3 games. In order to achieve this the tournament is packaged and deployed separately from the game, in a TAR, a Tournament Archive (and yes, it is unfortunate that “tar” is usually something completely different…)
So to wrap it up:
- Game: This is where you execute game logic when clients send action to the server
- Service: A modular and re-usable piece of code that can be shared between games and tournaments
- Tournament: A tournament controller which manages… er… tournaments
We’re still fairly theoretical, but hang tough: soon there will be code!