• There is NO official Otland's Discord server and NO official Otland's server list. The Otland's Staff does not manage any Discord server or server list. Moderators or administrator of any Discord server or server lists have NO connection to the Otland's Staff. Do not get scammed!

Proof of concept of a new game engine

Is saving map in a json a good idea? The file would be very large and it would take a lot more time to load than a binary file. But, at least, it would be possible to control this file through git (as you would know exactly which part of the map the contributor would be changing)
If the json files are split in different chunks/sectors, then it can actually be faster than loading a binary file, because you can load multiple files in parallel
 
I'm creating a map editor for this new map format (more details in this post). It'll be written using Flutter.
So far I have spr and dat loading (partially) and drawing items on canvas together with saving them in state. Now I'm having some problems adding zoom.
...
Let me know if there are some features not present in RME that would be useful for you.
Hi, share the source code?
 
But, there is Tauri. And I'm thinking about it. It's basically better Electron with Rust backend (and native WebView under the hood). So I could write map rendering and IO operations in Rust, compile it to Wasm and put it on WebView together with the UI written in HTML+JS+CSS. Of course, I would use a frontend framework, like React or Svelte. Or even Yew. So the plan is to play with it for a while and if it turns out to be a good tool for the job, I'll port my existing Flutter project.
Tauri looks pretty good, hadn't heard of it. I've used both React and Svelte, and Svelte felt more satisfying, as in writing more functional code and less boilerplate. Also, amazing job on the engine, there's a ton of potential in this project. I particularly like your more modern dev approach applied to OT, it seems for most part we are still stuck in 2008.

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.

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.
 
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.
 
Back
Top