This article will be updated as I add parts to the game.
Last update was on the 30th of October 2020
In this blog post, I will talk about the technological choices I made and go deeper in some technical details about the game.
Unity
The game is based on the Unity engine which allows you to export on all platforms, from PC/Mac to consoles via mobile platforms.
I made that choice because I know Unity quite well and I like coding in C#. But to be honest, everything is not perfect in the Unity world.
Love / hate relationship
I love Unity because it’s very easy to get started with, there are plenty of online tutorials and examples, and the assets store has some good gems. All this gets you to pass the prototype phase pretty quickly.
I hate Unity because they have different ways to do the same thing (usually they buy some popular asset, integrate it in the software and that’s it, they do not remove the part it replaces). They also sometimes remove features without giving anything in replacement (last example with the networking part).
Physics 2D
When I started the game, I thought “it’s going to be easy because Unity has all the needed tools including a good 2D physics engine”. But after a while playing with it, I found a bunch of blocking limitations.
First, it’s very hard to customize, you can play with physics materials and change the mass, friction, and all those variables, even the gravity scale itself. But still, in the end, it’s a bunch of variables that you’ve changed here and there. You get easily confused and it’s not even practical to test.
Second, and that was the blocker, the Physics engine is non-deterministic. It means that given a set of inputs (i.e.: force, mass, and start position) if you play it two times, you will probably not have the same output. Unfortunately, this is not compatible with Artillery Royale Gameplay. If a player at some point has a good aim, now the right force and play the same move again, they should get their bullet at the very same spot.
You will see that the deterministic part is even more important because of network implementation.
So I took some time to re-implement basic physic equations but kept some of Unity existing pieces like colliders and collision resolutions.
About the destructible map
I found a great asset on the store that allows you to take any Sprite and make it destructible. I bought it without even thinking and at first, I was in love.
But after some prototyping, I found out that because the asset was working on pixels and not shapes it would never render the way I wanted.
So I made my own destructible map which is based on Sprite Mask and custom polygon colliders, all of this is easily done with Unity and a bit of shape math.
Map generation
See detailed article here: Map generator
Network
Custom solution
I made some new prototype with a new solution of my own, tailored for that particular game. Indeed, being a turn-based game, I will go for a “turn replay” mechanism: the idea is to record the turn of the player (with a specific optimized stream format) and broadcast it to the other player in near real time. This will also allow keeping a record of any game for later replays.
You can now see how important it is to have deterministic physics, so I don’t need to record every movement in the replay stream.
See the detailed article here: Network