At the end of the last update, I left you with a preview of the new skill I had just introduced which leads to the creation of a temporary entity: the projectile. This wasn't a trivial feature to add as this dynamically created entity requires, like any other entity, to be sync'd between the server and clients. The difference compared to player or monster entity though is that each player can be shooting projectiles in rapid succession. So as the number of players increases, so does the pressure this puts on entity creation, synchronisation and deletion systems.

As a result, some weird corner case bugs started to appear such as the unintentional / residual establishment of a projectile as a permanent fixture on the map after impact, likely due to the server's failure to send the deletion update to the clients or to the client's failure to receive and process them. There were a couple of other situations where TCP along didn't seem to be enough to guarantee delivery and thus, game state consistency. Seeing as network messages are sent in a different thread, catching timeouts wouldn't be an option or at least not a straightforward option and increasing timeouts even less so as it would increase exposure and vulnerability to malicious attacks in the future (DDoS). At least this was my train of thought going into addressing these low level bugs and I thought it was time to build an acknowledgement & retry mechanism within the application layer for some of the most critical use cases in server-client communication. The other reason why this mechanism is useful is that it can give more knowledge & power to the server in terms of making decisions and enforcing certain policies. For instance, I'm now using this acknowledgement mechanism when repositioning players at the end of a Battle Royale cycle. The server can now reject any new position sent by the client for as long as the client has not acknowledged the repositioning message.

In mildly related news, and thanks to Cymmy, the projectile now has a legit animation! It's a spinning skull with a round shadow underneath of it. The shadow is great as it helps to visually keep track of on exactly what path the projectile really is and where players should stand in order to avoid it. This is what the sprite sheet currently looks like:

She also made a sprite sheet for the explosion upon collision but I haven't worked that one into the game yet. Adding a first range skill was one of my most urgent goals as I knew it would make battles a lot more fun than just a plain melee attack. It helps to reveal player skills in PvP as you need to worry about aiming and dodging at the same time. From a purely mechanical standpoint, it also seems to work well in combination with the strafing the controls allow players to perform while attacking, and I'd say it works particularly well when using keyboard motion.

So with that in working order, and before I would consider organising a live session with more players, I wanted to improve at least one other thing: the Battle Royale algorithm itself. In it's first version, it was relatively dumb: it would only toggle the gates of the "transfer zone" every few minutes and if you missed a cycle or if the battle ended early, you'd have to wait for a fixed amount of time before playing again. Also, the BR systems were not aware of how many survivors were left nor who the winner was. This stat is now kept and displayed in the leaderboards as you can see here:

And so with the Battle Royale mode being less of a drag, I welcomed some kind souls to join me on the NA and EU clusters successively for a live testing session. I counted 10 players total at one point, although a couple of them initially had trouble downloading the client so we may never have had this exact number in real action at the same time. Nevertheless, the server held up and I was able to confirm that my systems scaled to at least that amount of players in live action, as all of them were shooting projectiles and moving relentlessly. I don't have a whole lot of monitoring in place yet (that's coming), but I was able to keep an eye on CPU and Memory load and all of that was fine. I don't have a solid approach for response time or latency measurement in place just yet but the in-game eye test, real-time log viewing, and player feedback all seemed to indicate that everything was running smoothly. I didn't notice any stutter or lag in the way people were moving, attacking or in the way projectiles were colliding, which is all very reassuring and encouraging for the future. My main takeway is therefore that the general architecture and code base seems pretty solid at this point or at least on the right path. By the way, here's a tiny bit of footage I recorded at some point while we were playing, albeit pretty late in the session, as we were mostly just chatting anymore. It still gives you a good idea of what Battle Royale play feels like as of now, and as limited as the state of the game is right now, it did seem like people were having fun!

10-player Battle Royale video on Youtube

Last but not least, I created the base systems for playing sound effects and music, added my first composition ("Dampening The Universe", available here on SoundCloud: https://soundcloud.com/dcransac/projectvisionaries-dampeningtheuniverse ) to be played while looking at the splash screen and I added a couple of early, super basic sound effects to be triggered upon attack and recovery events. If you're interested in assisted music production, you can take a quick look at a live play of the loops involved in that song in Ableton. It records and generates a base arrangement which I can then tweak until the whole track is deemed complete and ready for export:

First soundtrack and Ableton demo video on Youtube

Resulting soundtrack export on Soundcloud

Thats what the arrangement looks like by the time the song was ready for export:

And that does it for today. Until next time!