Purely from a systems design POV I've been pondering about better scaling architectures than monolith for OT servers, such as microservices. But of course, the overhead of splitting a monolith might make full world updates take an unfeasible amount of time. However, it might be possible to "instance" each slice of the map separately, fitting nicely with your new map format as well, in order to distribute the world processing (see
this presentation of Guild Wars 2 architecture). I suppose you could call it a pseudo-open world classic-Tibia experience if you limit map instances to one, that would also allow full blown WoW-like instancing if you so desire. You could have PVP and non-PVP players on the same game world, allowed to trade with each other on market, send parcels and messages, but locked to different instance types. The possible drawbacks would be loading screens/reconnecting every time a player changes instance (like for example, taking a boat from Venore to Thais or entering Cyclopolis, if it is a different map section). Then again, one might question the need for this level of optimization for a sub-100 player server, but I digress.
It's possible in the future, but the first step should be to have something working on a single core. Anyway, I would rather go with splitting map simulation into multiple cores within one process. This should allow people to buy cheaper hardware, because currently if you run TFS you need a fast single core, so it's usually a costly dedicated machine (at least for bigger servers), and most of the other cores are wasted. And if we split the map by islands that are not connected with each other at all, it doesn't look that hard to implement. It could even be detected automatically by the server during startup by analyzing the map, assuming the islands are not connected by water. But some big islands, first of all the mainland, would still have to be simulated in one thread, including connected islands (Fibula, Draconia, Isle of the Kings). Splitting one island into multiple threads would be a little bit harder, because you have to handle edges, but would still make sense. On the other hand, running separate processes on separate machines for each island looks like an overkill. I don't see any use case for that, unless your map is really really huge. Or have a lot of instances, but if you want to instantiate the whole world multiple times, why don't you just create multiple game servers?
You could have PVP and non-PVP players on the same game world, allowed to trade with each other on market, send parcels and messages, but locked to different instance types. The possible drawbacks would be loading screens/reconnecting every time a player changes instance (like for example, taking a boat from Venore to Thais or entering Cyclopolis, if it is a different map section).
I don't understand this part. If you want PVP and non-PVP players on the same world but still separated, there should be two instances of the world running in two threads, right? And you can never change the instance. Or did you mean that each of these instances will then be split by islands? Well, this gets quite complicated, I'd just run two fully separated game servers.
Are there any updates to push to the engine repo? I'd be happy to learn Rust and contribute on my free time. Let me know if there is any issue on the engine/map editor I could help with.
Well, I think I have to build the foundations first. But you can start learning Rust now, it'll probably take you at least few months anyway.
I'm still working on the map editor, but it goes slowly, because I'm lazy and procrastinate too much.
So far I have a proof of concept of this Tauri+Web+Wasm architecture working, including rendering some simple things to canvas from Wasm or parsing files in Tauri and sending them to Wasm. It's not that ideal, Tauri is still very new (they just released 1.0), so for example I used a Websocket as a workaround to send these binary data parsed from files, because JS <-> Tauri bridge only allows sending JSON data for now.
Recently I started learning OpenGL, because the plan is to write a map renderer in WebGL and embed it on the website (as a Wasm module). That's the next step.
Regarding the UI, I was playing with
SolidJS, and it looks very promising. Writing components is very similar to React, but it works completely different under the hood (for example no virtual DOM) and is even faster than Svelte. It also works together with the Wasm module quite well. There was one issue, though - JS code uses the project state stored on the Wasm side, and the variable that represents it on the JS side was not updating itself after it was updated on the Wasm side. I managed to fix it, but it's a quite ugly workaround, and I'm not sure if I can leave it like that.