Imperium uses some game data that could be fairly dynamic. This includes things like the single- and multiplayer scenarios, engine parameters and all AI behavior scripts. Initially all this data was included in the normal game bundle. Easy solution as there’s really nothing to do but to load then data when needed. It’s also not very dynamic. To tweak a parameter, improve the AI slightly or just fix some issue in a scenario I would have to create a new version and submit it to the App Store. There it would be subject to the normal app review delay, making any form of quick turnaround impossible. Clearly not ideal.
To solve this I added an asset server to the normal multiplayer server. This game server runs on some hosted server and will be used for multiplayer games. It was quite simple to add some extra requests to allow the server to also serve asset data from a set of known files. The game would upon startup request a list of available assets. Each asset in the list would have a version and Imperium would compare the version to a local version and request a new version if the server had a newer one. Easy to set up and manage. The server side would just be a simple text file containing the asset index which could be easily updated as new asset versions were created. The problem with this solution is that the server is not really 100% done yet and requires some work in order to scale and be robust enough. That requires time that I don’t have right now.
In order to not have to work on the server asset handling I moved the static assets to Apple’s iCloud and access them via CloudKit. The conversion was quite easy and the code is now a lot simpler. The simplicity is mostly because I don’t have to worry about network communication myself, that’s handled by CloudKit. I also do not have to worry about scalability or stability of the server, that’s also handled by someone else. The asset downloading is perhaps a tiny bit slower now, but there will not be too frequent changes anyway so that’s a hit I’m willing to take. For single player games my own server will not be used at all for now, it will be back in the picture when it’s time to finish the multiplayer side. The game will download only changed assets by using a similar version attribute. Each game keeps track of the last version of assets it has downloaded and just asks CloudKit for any new assets with a higher version. Sometimes the result is empty, sometimes it’ll get some assets.
The drawbacks of using CloudKit is that the asset handling is a bit more cumbersome from my point of view. Uploading assets has to be done via Apple’s CloudKit dashboard and there is no easy form of automation available that could, say, sync the assets that I have locally with those on CloudKit. There is a web service that can be used to build such a thing, but it’s far too low level for this to be a viable task for me to do now. So assets will have to be manually click-click-click uploaded when they change. Not a terribly big issue once the game has been released, but while developing it’s a bit annoying.
But there’s been progress at least, some minor part has been finished. 🙂
The original tutorials for Imperium were not too great. Or specifically the third one was a bit buggy and it was easy to do something that confused the tutorial and messed up the progression. That tutorial has now been redone and it’s much less fragile and easier to play. The game will still require all three tutorials to be played through before allowing any online or campaign games to start. That’s just to make sure that all players have at least some form of grasp what the game is about before jumping into online battles without any idea how to play.
There has been a possibility to put updated content on the server and have the game download that when it starts up for quite a while. Now I however changed the system so that a lot of the real game content is always downloaded from the server instead of being shipped with the game. When starting up for the first time all scenarios, campaign data, AI data as well as all help files will be downloaded from the server and saved locally on the iPad. From then on each start will check if there is some updated data and download if available. This allows for trivial distribution of new scenarios, update old ones, tweak the AI and write new help documentation without having to do an App Store update. The server side resource system is also very simple to handle, so I see this as a very nice improvement.
As normal, if you want to play the game is it is now, get in touch and I’ll set up a TestFlight version for you. So far there have been absolutely no interest for any of the test versions I’ve released over the years. I assume that’s an indication that this type of game really isn’t interesting to anyone, or that Imperium simply looks boring or bad. I assume it’s the former.
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.
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.