As promised in my August post I cleaned up the code for my relay server and uploaded a first version to GitHub under the name ConquestRelay. It is meant for hobby game developers prototyping their own online games, but still lacks a lot of functionality found in professional network layers.
In order to start with the ConquestRelay server just follow this link to the GitHub page and either download the whole package as a Zip file or clone the project to your desktop. It contains a copy of the websocket-sharp library, a folder with the relay server itself, and a Unity example project.
So what’s this server good for anyway? As you may have read in my previous post I am currently working on an online game which I meant to host on a server in the Amazon cloud. However, since I do not own a Unity Pro license I cannot compile a headless server which is necessary for those cloud servers that do not feature a GPU. Therefore, I was looking for a solution where I could host the game on my PC at home while being able to connect to it from anywhere, even with mobile devices. The solution I chose was to use WebSockets, and a relay on my cloud instance which connects game server and clients (cf. the diagram above).
Running the ConquestRelay server
As long as you are using Visual Studio (I am working with Visual Studio Community 2013) compiling the project should be easy. Just open the ConquestRelay.sln file and compile the websocket-sharp library as well as the relay server itself. Since the server only waits for incoming connections of game servers as well as clients, there is no need to configure anything. It currently listens on port 443 which is used for https connections, and should therefore be open in standard firewall configurations. For a first test on your local computer this isn’t relevant anyway, so just start the ConquestRelay.exe you just generated.
The folder Unity contains an asset package with an example game server and client. After importing this package to Unity you will find three new scenes, GameServer, GameClient and ClientLobby. Build the GameServer scene and run it. Then open the ClientLobby scene. Make sure it is configured as scene 0 in the build settings and the GameClient scene is set as scene 1 (cf. screenshot above). Now run the scene in your editor. You will get a “list” with one game server which is ready for new players. Click the join button which will connect you to this server and instantiate a new, empty player object. From here on it’s mostly up to you. If multiple instances of your client connect to the server, each one will spawn a player object for each other client. Now you can start implementing the insides of your players.
Where to start coding
The main class for your game in Unity is WebSocketBase. It connects to the ConquestRelay server and provides methods for remote procedure calls (RPCs). It parses system messages from the relay server, but all communication between game server and game clients is done in derived classes (WebSocketServer, WebSocketClient, and WebSocketLobby). The method ParseMessage() is central here.
RPCs are passed as strings, where game commands start with the “Cmd” prefix, followed by the command name and any parameters, separated by blanks. The ParseMessage() method is essentially a sequence of string parsers analyzing these messages. Once you have added a command to this list you can call it using the RPC(), ServerRPC(), or BroadcastRPC() method.
ConquestRelay and the Cloud
In order to run the ConquestRelay server in your own cloud instance there is not much you need to do. Upload and start it, then make sure port 443 is not blocked by the firewall. This should be all you need to do. Then note the IP address of your cloud instance and enter it in the Awake() methods of your WebSocketServer, WebSocketClient, and WebSocketLobby classes. For the beginning this should do the trick even for mobile devices.
Lots of open issues
As I said above, the ConquestRelay server was only a means for me to get my game running at all, and an exercise for getting acquainted with WebSockets. Naturally, this leaves a lot to be done, and the software is far from being usable in serious projects. Just a few things that obviously need to be addressed:
- Binary instead of string messages.
- Some kind of security, since now everyone can use your relay server once he finds out your IP address.
- Variable IP addresses in case you restart your cloud instance.
- Handling of disconnects and reconnects.
- Performance optimization, although this method will probably never be suited for online FPS or RTS games.
- Documentation. 😉
And so on. But if you just want to make your first steps in online game development without any budget at all, give it a try. I would be happy if I was able help.