Im bored

[AlbireoX]

Hey guys ,

After I finish up my current projects, I was thinking of implementing a multiplayer server in...

Node.js.

It would work well with existing mod API plans, and I feel it would be enjoyable to not have to write statically-typed unit tests.

But we need to decide on a protocol, which is...?

 

[Immortius]

What I was thinking of doing for Terasology to start with was using Netty to send protobuf messages across TCP, maybe switching to UDP down the track if required for performance. This would probably make use of the existing Terasology protobuf messages that are used for persistence, as well as new ones for multiplayer (i.e. a Chunk message, some login handshake messages, and so forth).

There is a short multiplayer example unit test in my fork, that just sets up a server and client and has them handshake with a simple protobuf message at the moment. Then I got distracted refactoring the world representation so it could support remotely supplied chunks and multiple players.

You'll have to explain why Node.js though. As far as I can tell it doesn't really integrate with Java, so you won't be able to use any of the existing code. You'll be spending months rewriting Terasology's logic from scratch (minus rendering), and then you'll have this separate server app to keep in synch with Terasology proper. Assuming this is supposed to be Terasology related anyway. Might be better to look into something like https://github.com/purplefox/vert.x , although it is kind of young and obviously non-standard.

 

[Cervator]

If you're bored there are lots of stuff to do that could be more useful for Terasology itself. I do know you really want to tinker with JS stuff, especially Node, but just don't think it will be all that applicable for Terasology outside the limited role JS will likely play in the modding world. Might be better to do a hobby project on the side to scratch that itch, like that vert.x thing

In the meantime or along-side that any spare cycles you've got that you're willing to put in for Terasology would be highly appreciated - I've got plenty of stuff in mind I could really use your help with. Just Xenforo alone is taking forever to tweak solo, some of the templatey stuff can take some tinkering, not to mention the magic we could do related to Github issues, the brainstorming think tank design dei & woodspeople are playing with, and so on - which may involve more JSsy stuff

 

[dei]

What type of server do you plan to write? A full game-server for Terasology or just some kind of lobby-server to team up some clients and initiate a game?
A lobby-server in light-weight node.js no problem, start writing a design-document/diagram and present it here before implementing it.
A fully fledged game server seems a little bit too early. Node.js would as already said be a big problem as the server has to implement the most important things of game logic too (cheating prevention).
Even if modding will be possible in js one day you would have to rebuild/translate much of the game logic from Java to JS.
Designing my new water simulation I also came to many questions concerning multiplayer and I think there is probably much more existing functionality you could conceptually check how they would be integratable with multiplayer. Perhaps there are some that would have to be redesigned/reimplemented (even in singleplayer) before being playable in multiplayer with a reasonable server-load. Concerning Water-simulation think I've managed to find a server-independent solution for almost all simulations: Simulations only run on the clients and their state is communicated to the server on logout. To prevent cheating without requiring the server to run all simulations simultaniously the server will make random/event-based tests if some chunk-based checksums are consistent between client and server. (Every simulation is a very local function of a initial state and a time-difference, so it can be calculated at any desired time) When a checksum is not consistent it kicks the player as a cheater.
Based on this system I think it would even be possible to make the checks on the other clients and only use a dumb lobby-server which can run on a very weak server-box. (would be a huge advantage over MC which nearly needs a supercomputer as server)
To make a long story short: If you're bored and want do something with multiplayer: Analize current game logic and find areas that need a redesign to work as seamless as possible in multiplayer.

 

[Immortius]

Simulations only run on the clients and their state is communicated to the server on logout. To prevent cheating without requiring the server to run all simulations simultaniously the server will make random/event-based tests if some chunk-based checksums are consistent between client and server. (Every simulation is a very local function of a initial state and a time-difference, so it can be calculated at any desired time) When a checksum is not consistent it kicks the player as a cheater.

I'm going to need more detail. I think I know what you are getting at, but I don't think it is quite as exciting as you think, and I may be mistaken.

Checksum based checks are easy to circumvent, you just keep both states and reply to checksum requests with the expected state. In fact, the client can just calculate them the same way as the server does to make the request, and not even maintain it. So forget about them. The moment you depend on clients behaving nicely your security has failed. Either you need an authoritative server, or you throw away any cheat prevention and aim the game for small groups of friends. Or I suppose synchronous peer-to-peer, but then you're limited to sending around inputs and every client needs to simulate everything. So then every machine needs to be a supercomputer, or you're restricted to low player counts.

I can see a lot of benefit in having various world simulations deterministic - light propagation is deterministic based on block state for instance, so only blocks and block changes need to be propagated and clients can determine the lighting themselves. The world still maintains the state too, which is used for authoritative game logic, so while the client can mess with it they are limited to visual changes (they could make all caves fully lit, but they'ld still be dark and do whatever dark caves do).

May be an interesting read

 

[Cervator]

Considering that we often make the clients struggle anyway from all the rendering it might be preferable to demand a server super computer - tho it might be interesting to prepare for a multi-node server setup where you can farm some intensive tasks off to secondary computers. Which if structured right could possibly take advantage of trusted client PCs for small groups of friends playing with no single super PC. Tho latency might easily kill that unless the server nodes are all in the same place.

 

[dei]

Immortius:
But there is no point in faking checksum answers if the winning condition is somehow dependent on these checksums. It would be as good as writing your own singleplayer-mod that displays "CONGRATS YOU WON THE GAME" as soon as it is started.

Cervator: Checks must not be that ressource intensive:
For the design of a multiplayer mode we have to protect any property that is essential for gameplay from cheating and your right, it will be a lot of data. So to check all these values needs a rather big amount of memory (to keep the whole world on the checking side) or a huge amount of cpu to recalculate all the checked stuff.

Instead I propose to check only randomly for random properties in random places. This way the client always has the risk of being caught while cheating but the checking-side doesn't have all the cpu-/memory-Load. Like in real life, you would be able to cheat but at a certain risk of being caught. Depending on the consequences (ban from server, ban from lobby) cheaters will be very rare. One real huge advantage of doing these performance saving random checks on the clients is we wouldn't need to touch the server when modding the game. The server would have to decide on a random base which values are checked (and keep it secret).
A) We have to prevent the following things to be manipulated by cheating:
1. inventory
2. medium and large changes in landscape (very local changes not exceeding 2 continous blocks don't interest us)
3. please complete...

B) But we also have to hide these 'secrets' from ennemy players:
1. inventory
2. not visible, continous changes in landscape (buildings, caves, ...)
3. please complete...

Now to be able to validate game logic while hiding secrets, the only way would be to make the "information to validate" a secret of multiple other players but in a way that every player can validate his part of information. Additionally the server could anonymize the datasource and only map-back the playername if it was cought cheating. This way the server would only have to distribute various anonymized cheating-validation-packages and wouldn't need any validation logic (and thus no installed mods).

For splitting up a player's information we could rely on some kind of conserved-points system: (Or does anyone have another idea)
Basically every game can be reduced in the following logic: The world contains some items (and blocks) of some gameplay-value each (ie. raw stone is of much lower value than a pickaxe) and the player has some of these items/blocks. During the game the player is able to convert some items to other items by crafting etc. and use them to win the game (similar to conservation of energy in physics). Now our "dumb server" could request them from one player and split these values between other players for validation at a ratio only known to the server. He could even give a part of it back to the player it requested it from.

Another idea would be to validate some game logic that is so old that it doesn't have any effects on gameplay (at latest at the end of the game). So some information-unveilling checks could be made at the end of the game. (A player could sabotage the game but not win by cheating)

Would that have potential to work? (I didn't have time so far to think it to an end)

 

[Cervator]

Punkbuster wizardry

Too far outside my normal train of thought, so I dunno. Probably an important topic to consider a design for so we're prepared, but not necessarily to implement soon since anti-cheating would be a way later type feature.

"No point" is a dangerous assumption to make about user motivation/intention, however. "For the lulz" is an ever-present risk, and we can't predict everything

 

[dei]

By the way: Thanks Immortius for the interesting link.

I think we should design anti-cheating before implementing anything for multiplayer. There are so many things in anti-cheating that are dependent on the multiplayer architecture and vice versa. If we start with anti cheating after the multiplayer design already is fixed we get the kind of anti-cheating wizardry that never works right like Punkbuster is (I think it checks some checksums of the game binary)....

Imagine a game server that, once stable, is independent of played mods, game logic updates etc. That would be worth every thought before completly designing multiplayer IMO.

 

[Immortius]

But there is no point in faking checksum answers if the winning condition is somehow dependent on these checksums. It would be as good as writing your own singleplayer-mod that displays "CONGRATS YOU WON THE GAME" as soon as it is started.

There are tons of reasons people would want to mess with the game state (and thus fake their checksums) if that game state is authoritative on their machine. Flying, walking through walls, invunerability. Especially if someone makes a PvP mod, but the fact that you interact with other players is reason enough. If the state isn't authoritative then you are correct, but then there's no point worrying about checksums - if the player messes with their state then they're just deluding themselves and not affecting others. So either way I don't see the checksums as being very useful. It would serve some purpose if changing the client was hard, but the game is open source.

One real huge advantage of doing these performance saving random checks on the clients is we wouldn't need to touch the server when modding the game. The server would have to decide on a random base which values are checked (and keep it secret).

The server can only check client state if that state is also maintained on the server. Which means the server needs to run mods. Which undoes all the benefits, as far as I can see.

Many of these issues are solved with an authoritative server model. The server holds the real state of the world, clients send their interactions, which are checked and resolved on the server and the results sent outwards. The server only sends each client the information relevant to them - so only the player's only inventory, and the inventory of containers they have open, information on the world immediately surrounding the player, visible players and creatures, and so forth.

A simulated/predictive client would also act immediately based on some player interactions, and then correct the actions as the actual results are received. If a player moves through a door which is open on their client, but has actually been closed by another player on the server, then the server will send back a message correcting the predicted movement, and the client will correct for this. If the player uses a potion the potion drink sound may fire immediately on the client, with the effect and inventory reduction coming with a server update shortly thereafter. This prediction is just a bit of smoke and mirrors to improve perceived reaction times.

Additionally some mods (those that don't add new UI or assets) can just exist purely on the server, which is another advantage.

 

[AlbireoX]

Just got internet back.

In the meantime or along-side that any spare cycles you've got that you're willing to put in for Terasology would be highly appreciated - I've got plenty of stuff in mind I could really use your help with. Just Xenforo alone is taking forever to tweak solo, some of the templatey stuff can take some tinkering, not to mention the magic we could do related to Github issues, the brainstorming think tank design dei & woodspeople are playing with, and so on - which may involve more JSsy stuff

I will have spare cycles in a bit, PM me. I'm really interested in the JS stuff, and I don't really care about making it work for multiple platforms anymore.