In this update, I'm going to discuss 3 aspects that I've started addressing a few weeks back in order to build the PvM experience: map environment, monsters and persistency. The map environment is an obvious one: we need a different setting and layout than that of the arena-style map and Battle Royale gameplay systems which have been in use up until now. So I started designing a new map which is still extremely raw, but will very soon have a completely fresh look and new sets of tiles. I changed the server's initialization code it so that Battle Royale gameplay systems can be turned off and instead new PvM gameplay systems can be turned on (for spawning monsters, managing monster aggressivity, etc). These new systems rely on dynamic information placed in the TMX metadata which can be applied from the editor, as demonstrated on this next image:

As you can see, "pin" objects can now be dropped on the map, similarly to the way you would drop the puppet guy on Google Maps for entering street view. Then, different properties will be interpreted by the engine in order to pass information such as player starting locations, monster spawns, etc. This is something I'm very happy about as it provides a clean interface between map edition and the game's logic, and gives potential map makers more advanced tools to build the player's experience. The map ends up being not just a patchwork of tiles but instead, it contains logic and defines more and more of the conditions and events which can happen within a given environment. And all that is pretty simple to understand and implement, you don't need to know about the game engine's code, you just need to know the proper conventions that are expected to be followed and enforced. I've also added support for rectangles to define zones such as safe zones, battle zones or custom zones (such as a transfer zone in the Battle Royale's case which has a special meaning), as in this example of the reworked Battle Royale map:

Then came the monster changes. An obvious one is that the monsters needed to aggro, i.e develop a sense of when is a good time to attack the player, proceed to approach and follow the player if necessary, then attack it until it dies or kills the monster, and then go on with their lives (de-aggro) or lose interest if the player goes out of reach or too far away from the spawn's location. You can see a little bit of that in this short video clip, although at the time of recording this, the ants were not actually able to hit the player yet (it is now the case):

Monster respawn & aggro video on Youtube

The third aspect of my efforts to support PvM relates to an important aspect which I kinda wanted to get out of the way sooner rather than later: persistency. If you're a non-technical reader, you may want to skip the end of this update. Persistency and serialization are a big deal and a wide subject to cover as they touch upon just about every layer of the stack. A database type needs to be chosen, serialization and deserialization of game entities need to be implemented, a database management server needs to be deployed in every stage of the deployment map (that includes local dev environments as well as the kubernetes clusters), etc, etc. I was able to build all that in a matter of about a week, although I was largely slowed down by some issues relating to JPMS and my choices to enforce modularity in all components of the game's architecture.

While there isn't too much to show yet in ways of screenshots or UI workflows, I did implement a storage layer based on MongoDB and Mongojack and I'm already relying on it for the storage of player characters, error events and various other operational aspects. That week I spent on this topic also wasn't solely dedicated to persistency itself, I built an entirely separate stack on top of Jetty 11 and Jersey 3 to create a new type of server, which I called the "federator" instance (1 per cluster) and on which I've deployed a first set of synchronous services. With the game's core client-server interactions being largely asynchronous and non-web, I believe it was important to dedicate a separate stack to the handling of synchronous communication, especially for handling non-functional and more standard web-related aspects which can then be off-loaded from the primary game servers. Federator services will be used for handling things such as login and account management, but also for higher-level game-related technical tasks such as bouncing players from server to server as they make progress and change zones. This is illustrated by the following architectural diagram which more or less represents the target of my cluster's architecture:

If I simplify a bit and focus on just the red and blue kubernetes pods, which represent 2 different zones in the game, the federator will be responsible for bouncing players between the corresponding pods:

This is a continuation of the implementation of my instanciation & distribution strategy for handling load and expanding the game areas in a scalable way. I'll definitely provide more details about this in the future as I believe this is going to be one of the top differienciating factors between this game and other ARPG and MMO-RPG games: we'll end up offering a kind of hybrid experience between a traditional MMO-style persistent world and a D2-style instantiated world while still scaling to thousands and thousands of players if necessary.

I'm not there just yet but I started laying some of the foundations for that as part of this initial effort to bring persistency to the game and deploy the first few synchronous services within the Federator instance (namely account creation & login for now). (edited) This is about all I have for today. In the next couple of weeks, I'll be looking to improve the experience of navigating obstacles in the PvM environment as well as possibly improve the rendering logic and some of the interactions between the graphical information displayed to the player and the underlying physics of the game environment.