Unfortunately to support that many players would require a redesign of our multiplayer architecture. Currently the server does nothing more than forward packets between clients, it does not understand knights and merchants at all. Clients all simulate the game from the same random seed and synchronize commands with each other. So it's kind of a distributed architecture, every client does exactly the same thing and simulates the entire game, the only thing the host does is have permissions to kick people and choose the map.
This has many advantages:
- Server process is simple
- Easy to code once you have a deterministic game (which we do for replays)
- Lowish delays in command execution (ping between two highest ping players divided by two)
- Works fine with fairly high latency (only affects command execution delay)
However, it means if one client lags or has a bad internet connection, all of the clients will find the game is running slowly because the slow client can't keep up with synchronizing. What we'd need for an "MMO" is a centralized architecture where the server does all of the thinking and receives/sends updates to clients. This means a client can disconnect or have a slow internet connection without screwing up the game for everyone. Coding it is not impossible, but it certainly wouldn't be easy within our current design.
Even once we pass that hurdle, the game isn't really able to simulate 24 players at once on every PC of people who play the game. Modern PCs would probably manage it most of the time.
I'd say it's very unlikely that we'll implement something like that
This reminds me that I have to write that DevBlog article about multiplayer architecture.