Distributed Trader

[robject]

Suppose I wanted Trader to be a distributed multiplayer game, where there is no central server, but instead each client works with other clients to maintain player states.

This could be a trusted-client model, where clients are assumed to be interested in playing Traveller by the rules. Or state could be blockchain. I'd prefer simple trust.

For example, when I run the client on my machine, and assuming I've allowed external clients to talk to my machine on a designated (possibly obscure, possibly configurable) port and vice-versa, then my client would send state-change packets to any known clients which are online, in some sort of smart link-and-branch "Xmail"esque system perhaps.

I'd only know of clients because someone would tell me they're running the client at such-and-such address. In other words, a whitelist. Maybe not even discoverable. Primitive... and safer that way.

And the protocol would not be something out of the box. It'd similarly be something like primitive messages in JSON... safer that way. PRESUMABLY.

This would allow one thing that's interesting: interactions. You'd be able to buy/sell/trade with others. You'd be able to book passage on another player's ship... even be crew on someone else's ship. You'd be able to send Xmail in-game to someone else, and it would eventually find him or her. It would even be possible to do ship-to-ship combat with another player, assuming that's something that people would want (after all, you could do it in Tradewars).

And it would allow it without the need for a stood-up server.

I'm making lots of presumptions. So tell me what you think about it.

 

[robject]

Here's why I think this can work.

(1) Game state is primarily player-based. That is, artifacts owned by the player is the vast majority of player game state; copies of other player's state can be kept and interacted with, but generally the game state isn't damaged much (???) when other players' data goes stale.

(2) The Map is invariant... and external. Oh joy of joys, that Travellermap is always on, always available, unchanging... and external to the client. As a map server, Travellermap allows a trustworthy base gameboard on which to build and play.

 

[egor045]

From a technical perspective, you might want to look at protobufs. It might also be an idea to look into UPNP so that whoever runs the server doesn't have to mess around with their router. A combination of UPNP and piggybacking on a well-known service should work - XBox Live uses port 3074 TCP/UDP and is probably well-supported on consumer routers.

Your approach works fine where you can trust your players, but would fail dismally if there isn't that degree of trust. Considering the amount of work involved in hardening the service (encryption, authentication/repudiation, match-making, secure centralized storage, leaderboards ...), I really hope you can run it on a trust basis.

Presumably each client is the authoritative source of data for a particular player. You may run into staleness issues with this approach. An example of a potential issue:

Players Alexander, Barbara and Strephon play together regularly, with Barbara and Strephon serving as crew on Alexander's Free Trader. In between regular sessions, Strephon uses his character to play in a game with Lucan. He is now out of sync with Alexander and Barbara. Will this cause a problem?

($employer[-1] wrote game services software and ran online infrastructure for a popular FPS (I managed an ops/SRE team there for a while) - they used peer-to-peer for game sessions with centralised authentication, match-finding, leaderboards, storage and analytics services. Trust didn't really enter the picture, so they rolled their own messaging protocol and encryption. Protobuf wasn't a thing when they developed the original suite, so they had a packed binary format for the protocol using a remote RPC model.)

 

[egor045]

Players Alexander, Barbara and Strephon play together regularly, with Barbara and Strephon serving as crew on Alexander's Free Trader. In between regular sessions, Strephon uses his character to play in a game with Lucan. He is now out of sync with Alexander and Barbara. Will this cause a problem?

Actually this isn't a huge problem. Each game session (or series) gets a probably unique uuid. Strephon 's character has multiple incarnations, one for each session/series.

 

[coliver988]

Sounds like Git - everyone has a copy but syncs to the master at some point to get everyone else's updates.

You know - you could even use Github to do this it sounds like.

 

[robject]

Sounds like Git - everyone has a copy but syncs to the master at some point to get everyone else's updates.

You know - you could even use Github to do this it sounds like.

In fact a co-worker suggested the same possibility.

An earlier post mentioned trust -- and that is implicit: this works on a trust model, period.

A later post mentioned the mixing of game state -- and that is also implicit: cached data about other players will go stale, but that's okay since 90% of game state is about your players, not others. It's conceptually similar to Tradewars in that respect: what other players do isn't very important unless you both make it important, and then only as long as you want to stay in sync. And yes, crew positions may be tricky, but then, that can be remedied by players simply having crew hire on for one jump at a time; if one or the other logs out, crew gets dumped at the next destination. It's a price to pay for not needing a central server.

 

[whartung]

The problem is that it's much easier to make a connection from the client to the Internet than for the Internet to make connections to the client.

There's all sorts of networking shenanigans (from corporate firewalls to ISP routing rules) that get in the way of having Joe User open up a socket on their PC and having some other system make a connection to it -- and this is outside of discovery and trust issues, this is just simple connectivity at all.

You're much better off hosting a shared server somewhere that everyone can connect to, and have it manage message routing to those who are talking to it. The infrastructure is not difficult, and no more difficult that having your clients talk to each other directly.

This can be done easily, and even for free. Google App Engine is free for small applications. Heroku is also free for a small application. Even better, they stall your app if you reach some billable threshold, vs just billing you. Which is nice so there won't be a surprise at the end of the month because your app got rooted by some Estonian bot.

They're also (currently) "always free" vs a 12 month trial.

And, obviously, if you're willing to pony up the $5-10 a month, you can host all sorts of things in all sorts of places.

But, costs aside, you don't want to have clients connect to clients across the wild internet. It more trouble than it's worth.

An alternate method is to leverage something like IRC. There are several servers out there (freenode, IRCNet), and lots of clients available for IRC.

In this case, you can just have users sign up for the IRC, and then the software can make peer-to-peer connections to those participating. I honestly don't know if the server policies will cry foul for this or not, but, honestly, as long as you're not abusing their services, they'll likely not care.

You can also set up a channel for broadcast.

And, finally, if you do something horrible and get kicked off, you can always host your own IRC server and your client code keeps working, so not a complete waste of time.

 

[robject]

Hmm, a simple message router, eh? Sounds light and useful.