The multiplayer code in Imperium has seen a bit of activity lately. A new server has been written to work as the backend server and the old PubNub backend was ditched. Before that I used Photon, but it was a real cluster mess when used from Objective-C, it was quite clear that they did not care one bit about keeping that API up to date. So, an own simple server it was. That server is open source and can be downloaded from GitHub. I will host the backend where Imperium connects to on Digital Ocean.
The main change to the multiplayer code is that previously multiplayer battles were predefined scenarios with a fixed map and fixed units. That meant that there was not too much variation between battles. The new thing is that the player can define own armies which are used in multiplayer battles. These armies are a bit like decks in Clash Royale and similar games. There can be three different armies defined and they can contain any kind of units. When the player starts a multiplayer battle he/she first selects the army to be used and then proceeds to either host a game or join an existing game.
The army selection screen looks like this:
Army selection screen
Select the current army from the buttons on the left, view the contents of the selected army on the right and then tap Play to continue with the multiplayer setup.
Pressing Edit takes the player to the army editing screen where the contents of the selected army can be changed.
Army editor screen
When creating an army there are two limitations:
- the army can contain a maximum of 20 units
- the total cost of the army can be max 1000 credits.
The three buttons on the left select what troop types should be shown on the right side field. The Standard troops (shown above) are normal infantry and cavalry troops. The Artillery troops contains all artillery units and the Support troops are various smaller support teams such as machine guns, mortars, snipers and flamethrowers.
All units have a cost associated with them. An army can cost 1000 credits. The cost of each unit is shown after the unit name.
All units are available as individual units as well as larger formations. The larger formations all come with a headquarter unit and various other units. The larger formations give price discounts as well as a headquarter as a bonus unit. The contents of each larger formation is shown below the formation name.
Some real like issues have more or less prevented me from doing much on Imperium since the last update. I won’t have much time over this fall, but there has been some progress though and I’ll try my best to push out a new test version soon.
The AI has seen a bit of an overhaul and now the foundations are looking very good. The rules that actually make the computer units do things will still need a lot of work, but everything needed to make those decisions is ready. The efficiency of the AI code is also improved and the AI calculations are now spread out more in order to avoid hiccups in the game when the AI is executed.
There is now a new weapon type: howitzers. These are guns that can be used to do direct fire just like the other cannons but they can also be used to provide indirect fire just like the mortars. Their range is longer than that of the mortars, so howitzer units can be used to provide efficient fire support and attack units they can not see themselves.
Headquarters automatically rally units that have routed that are within their command control radius. Now the headquarters can also be given an explicit rally mission that has the headquarter focus on a particular own unit and makes it rally much faster.
The networking component will be PubNub. Originally Photon was to be used, but their Objective-C API is a real mess and very hard to use. It’s basically just a very low level set of calls without any documentation whatsoever apart from a badly designed example application. I wasted a lot of time with Photon in the past and during the summer while trying to get the new version to work. PubNub is much cleaner and the API is magnitudes easier to use. It has not yet proved itself to actually work in a realtime game context though, so we’ll see how it goes. The idea now is to see if the multiplayer could be added to version 1.0 after all.
I haven’t been working too much on Imperium since the spring, I’ve been busy with all kinds of other projects and also been a bit demotivated at the lack of progress. That’s how it goes, but lately I’ve been working a bit on moving the online code to use Photon Realtime instead of my own solution. What I had worked quite ok, but it was only for play on a local Wifi network, i.e. where Bonjour would work for service discovery. My own could would not work at all outside a local LAN. Instead of making a separate solution for Internet play I will scrap my own solution and move fully to Photon.
Photon as a service is still an unknown to me, but many games use it and many have recommended it over the years. However, to make an iOS game with Photon is not the most pleasant experience. The SDK is a mess and the docs are more or less non existing. You can grok quite a bit by looking at the C# docs, but there are no docs available for the Objective-C version. The SDK is partially in C++ and the Objective-C wrapper is very ugly to be honest. For some reason something as basic as named parameters have been removed. Using the Objective-C SDK requires a fair deal of guesswork and trying to understand things based on the single simple demo application that is available.
If the SDK is not ideal I have to applaud the developer support. The support has been quite awesome and all my questions and problems were solved very fast. Without the great support I would probably have dropped Photon in favor of something else, but now I’ve learnt the basics and will try to make it all work.
So far I have basic game selection working. One player sets up the game and the other selects the created game from a list. This seems to work quite ok but there is a lot of state and errors to handle and keep track of. No doubt there still are bugs. 🙂 The next step is to translate my own binary serialization code to something that Photon can use. It would have been very nice if I could simply have used my own NSData serialization code as-is, but that was of course not to be. I need to update it a bit to work with what Photon can serialize. Weird that it can not handle a simple NSData byte dump. Oh well, not a big task.
Phew. Back to work.