Adding pieces to the UI puzzle

While the UI is obviously not the most important part of an RPG, my intent is still to keep working on it on and off on and improving it as I go because not only will it benefit players in the end but smarter menus and quick shortcuts help me test the client faster on a daily basis. So I added a few new pieces such as an in-game menu bound to the escape key:

I created a NinePatch in Skin Composer for my drop-down lists. NinePatch is a format which stores information about stretch regions within an image, and enables UI components to scale to the expected size automatically depending on what they contain. Here's a brief overview of what that process looks like in Skin Composer:

I also started working on a new type of progress bar (until now I only used that sort of object for health bars which are just passive). This type of bar will be used as a slider in the Options pane, for instance for adjusting things like sound volume. I haven't skinned this yet though so it looks a little plain at the moment:

Managing multiple worlds simultaneously

But the task that's kept me busy the most over the last couple of weeks has been world management and zone transfers. Up until now, server instances were only able to manage a single world at a time which, under my implementation, also means one map at a time. So for testing, until now I essentially had to restart the server if I wanted to switch that server's map to a different one. In addition to this limitation, the client did not have the ability to switch servers or maps either, nor were portal-type mechanics implemented at the tile interaction level. This is now all done and so I wanted to talk a little bit about how I managed that and what this means in the short term, but I also wanted to reveal a little bit more about the big picture of zone management and the world structure in Project Visionaries. We'll touch on that at the end of this update.

 So my effort basically started with the ability to create and operate multiple worlds on the server. As I mentioned above, I'm intentionally tying Artemis' world object to only one TMX map because of the load management approach I'm going for (i.e how many players and entities can interact with each other at the same time within the same area). But more on that later. I started simple and just spawned a second thread on the server which was dedicated to processing events happening on a second map, and I made it so that the client would pass additional information to the server at login time so that the server knew to which map (and world) it needed to register the player. It required a little bit of additional routing between the network and ECS world layers but nothing too difficult honestly. This step lead me to recording the following simple video footage in which you simply see 4 clients connected to the same server but where 2 players are playing on one map and the 2 other players on a different map:

The next - much trickier - step was enabling player transfer from one world to another. The hard part to me wasn't even necessarily the fact that all entities need to be somehow unloaded, reloaded and in any case synchronized in a safe way at all times. That was pretty much already handled through prior work I did as part of event management, although I did hit a couple of road bumps on the client like an issue involving Artemis' WorldConfiguration making it difficult to recycle the client-side world object. The hard part for me ended up having to do with managing higher-level client-side objects such as UI stages, network client, asset manager, event queues, etc, and making all of them play nice with the newly created world.

So once again I started simple, meaning that I would not allow dynamic map transfer, just simply disconnect and reconnect the client manually instead, but with the added requirement of not having to restart the client process. In other words, I would just be disconnecting by going back to the main menu and then connecting again, but selecting a different map. Once I got this to work, I then added a type of tile interaction (via a temporary portal object) which would trigger dynamic transfer to one of the other worlds running on the server. At this point I recorded this next bit of footage in which the 2 top clients are sitting idly in two distinct worlds and a third client, at the bottom, first appears on one map and then pops back out on the other after clicking the portal:

As far as the portal and trigger itself, I just basically made different colors of portal objects and assigned different map names to them via a string property called "destination" as you can see in this screenshot of the Tiled editor:

As a "map maker" I would then simply place the corresponding portal onto the map:

...and voila! We now have gateways and a hub allowing us to jump to between a bunch of test maps:

We actually had a multiplayer testing session to test this new mechanic last weekend which was actually pretty fun but I forgot to record footage, so here's a video I recorded by myself and which gives you a little tour of some of the test maps (most of which rely on pretty old assets so please don't pay too much attention to the looks of things here, it's not the point):

In terms of performance, what I found and measured so far is pretty promising. The loading times between zones which you can see in the video are for a full disconnect/reconnect cycle between client and server, meaning that you could be sent to a totally different server while switching maps. However, this video was recorded locally so the latency was "optimal" in that scenario. In the playtesting session we did using remote dev servers, loading times were still pretty good in my opinion, even from a distant region (EU to NA or NA to EU), and that's without even really attempting to optimize anything. For instance, not every transfer is going to require connecting to a different server, so in the end, I expect that a lot of these transfers will be even faster than what you see in the video.

PV's next release

With map transfer taken care of, and as part of the next release and deployment in production, I'm planning on re-activating the Battle Royale map & gameplay systems, but this time I will connect it to some improved version of the hub, from which the PvM map will be also accessible. This next release will therefore be a showcase of sorts for both PvM and PvP mechanics and should serve as a good basis on top of which some fun higher-level systems can be built such as experience, inventory, loot and skill trees. So the world will be working more or less like this:

...except for we will be revamping & refining the different maps and systems so that hopefully, the experience starts to feel like that of a rich, immersive and coherent game, not just a bunch of stuff randomly put together. So we'll see!

The big picture of instance management

After making map transfer work I decided it was time to sit down and try to describe in a little bit more detail what the plan is in terms of zone instantiation. I had shared the following slide on our Discord server a while back:

This slide was part of the original design document I drafted back in October 2020, I believe. While it gives a little bit of an idea of what multi-dimensional instantiation may look like, I felt I should try to cover in a little bit more detail how zones (which I use to call Area) are going to connect with one another. So I decided to use Diablo 2's act-based structure as a starting point, just because so many people are familiar either with that specific game or at least with that type of progression. It resulted the following design document (a pdf file) which you can download here:

PV-World Design.pdf

The last two slides are the most important ones and where a little bit of technical incertainty remains. I'm planning on optimizing PV's architecture, infrastructure and code in order to get to what I'm calling "Single-root instantiation", in which every one can sit in the same town and then explore different dimensions of combat zones (i.e different copies of areas with monsters and points of interest regarding adventure). I'm calibrating everything toward the goal of having up to 64 players fighting around 250 monsters simultaneously within the same instance.

I haven't yet gathered all of the necessary performance data to claim that I can get there technically but that's the goal as of right now and I'm fairly confident about it. In theory, town areas should be able to handle more players than combat zones because combat interactions will not be allowed there and no monsters will live there, thus reducing load drastically. Should that not be the case for any reason, I would resort to Multi-root instantiation, meaning that even towns would potentially be instantiated more than once. In other words, multi-root instantiation is plan B but it likely won't be necessary, just due to the way we're going to effectively organize towns and points of interests within town zones.

That's it for this iteration! I hope you enjoyed reading this update. It's likely the next update won't be post until July as I'm going to take a little bit of time off. The new release likely won't be deployed until July either but we'll see what happens!