I’m opening the discussion for this topic here. What do you guys think? Any ideas for direction?
For others, this would be a generic websocket protocol that would allow for someone to write a client that talks via the websocket and not telnet.
The MUD Coders Guild did start a version of this ~3 years ago now up at https://github.com/mudcoders/ump, but it didn’t get very far.
If we’re doing websockets I think we could pretty easily start with a small check list of things you’d want:
- Uses JSON to send data back and forth
- Similar event structure, with payloads being determined by the event type
- Maybe has a ref for request/response
This is pretty much what Grapevine does so I might be biased.
The last thing we’d want is some kind of known translation layer, as I would guess enough people implementing websockets are using something like Phoenix Channels, or Django Channels, which implement their own protocol on top of everything.
So we’d need to be able to transition out of that into our own protocol, if even possible. As Phoenix channels includes some additional semantics in that protocol that don’t necessarily fit here (such as you need to join a specific channel when connect to the socket.)
I would say that if a ref is provided from the client, that the server should be required to respond in kind. I do like the way that grapevine handles this, but I think that always sending a response for a request that provides a ref would allow the client to at least see that the server acknowledged the message.
As for a transition layer, would it really be that hard to simply always send JSON over the line? That should allow phoenix to still handle the message as usual, and provide an event with the JSON, though it would be sent for a specific channel.
As far as I know, something like Socket.IO, while still utilizing it’s own protocol, still sends the message data in full to wherever it’s destination is. It could then be parsed from there. I’ll try to come up with a bit of a demo to explain this if it seems like it doesn’t make sense.
Yeah, Phoenix is always sending JSON over the line. It’s an array of elements, some of which are only pertinent to us. So we’d just parse what Phoenix sends and pull out the topic (if it matters) and the payload (which might be the whole thing we care about.) It just feels super gross and also needs to be sent back in the same format as the channel name needs to match up on the socket.
For instance, this is what the Grapevine web client looks like across the wire:
Yeah, what I mean is put our data in the payload section of whatever protocol is being used on top of raw websockets. Unless it’s not possible to interop between a raw ws connection and your phoenix end points. I assume grapevine’s API utilizes phoenix, correct?
For Grapevine’s socket API I went lower to get around the Phoenix Channels layer. So it’s a raw handler and everything sent/received is exactly what I want it to look like. So while it’s fairly easy and possible, I wouldn’t expect most developers doing Elixir to go this route.
I’ve thought about dropping to a lower level for ExVenture, so maybe it’ll happen at least in that?
Aha, that explains it. It might be that it won’t be possible to use a protocol like those provide right below ours.
I’m personally going for a mixture of REST and Websockets. Basically:
- All configuration and (relatively) static data is REST. This includes User Management, Character Management, Help, “Encyclopaedia” details - items, skills, etc. This will also include a REST call to get the Websocket URI to use - each URI will be single-use.
- The live game view will be on Websockets. This is everything that the character sees and does.
Will it work? No idea. But it seems reasonable.
I can imagine that would work overall, but the idea of this is to bring together a common protocol for the future of MUDs and MUD clients. I feel like it’s been stagnant, and the attitude has been “why change it” when we are in a new age of tech that would open up so much for the community as a whole.
So that was the original purpose of UMP. And it mostly fell apart because there is so little commonality between games, and you end up with the protocol being display-only, which isn’t much better than Telnet
I think there should be the potential to have a general purpose MUD protocol definition, but any such thing would necessitate having limits on what you can and can’t do using it.
For example, do you represent rooms as a resource in the protocol? What about coord based games? What about games that use non-standard representation of rooms? What about dynamically generated rooms?
Those are all extremely valid points. That’s definitely something we should look at solving.
Posting here to say that the repo linked up above has some movement again!