![]() |
#1 |
Scout
Join Date: Mar 2019
Posts: 30
![]() |
Multiplayer Variants Network Manifesto
First off, apologies to forum moderators, as this thread would mainly concern multiplayer variants devs. I chose this forum because it's a neutral ground, hopefully it will serve us well. Thanks.
TL;DR ===== We can't unify server codebases, and probably can't unify client codebases (yet), BUT WHAT WE CAN DO IS: unify the network protocol itself. Longer version ============== I think we didn't have a proper talk in 10+ years, so I want to catchup with you guys. I've been reading PWMA and TomeNET patch notes, and I've browsing your code, so I *think* I kinda understand what's going on in your projects. So, while PW was busy refactoring the code and brining everything up-to-date with Angband 4+ (still think that's insane amount of work, *_*), and TomeNET continued to introduce astonishing MMO features to the game, MAngband devs have been busy... doing what exactly? If you compare 2 last major versions, there have been no significant game-play changes. Same monsters, same spells, same mechanics... So what was going on? We were working on a good common network codebase, that MAngband variants could use and prosper from. The end-goal is to make the protocol so fluid, that we remove client incompatibility once and for all. Has this work been done? No, we still have miles to go. But an important, first, step has been made: we have removed about 70% of protocol rigidness. An example is in order. Let's say you're developing a PWMAngband variant, and decide you want some kind of talk-to-NPC feature. Then, you realize, that a new network packet is needed. Well, easily enough, you add a PKT_ define, write some Send_dialog_option/Receive_dialog_option functions, and, *boom*, you're done. Time to realase a new version. Also, *wham*, you've broken compatibility with your own game, and your parent variant. With no way of going back. And thus you have another TomeNET ![]() (And yes, I've noticed the 9000 'if server_version()' checks in tomenet, so I know there *is* some compatibility within single game, and, we've recently started doing the same thing in mang (see 'if client_version'), and it's horrible!) Now, this situation is completely insane! I don't know of ONE network protocol, that doesn't support some kind of extension mechanism. You don't need a different web-browser to connect to different sites (ahem) or a new IRC client for each IRC server (although their "protocol" is semi-random with crazy lack of standards). I know we all have good reasons to make *this* or *that* change to the protocol, and those reasons can come up unexpectedly, but we SHOULD NOT and CAN NOT shift this burden to our PLAYERS. (In fact, I believe we shall drop everything and work on this FIRST, and only then move on with whatever plans for our games we have in mind.) So, in my mind, this works like this: every client (mangclient, tomenet.client, pwmangband-client) can connect to every server (mangband, tomenet.server, pwmangband). We still develop our clients separately, and they each have unique features (maybe to be brushed off over time, cause it surely can be a single program), so players are free to choose their favourite. And it's OK, if some feature would only work with a correct combo (i.e. tomenet.client<->tomenet.server to see *weather*, other clients simply lack this cool feature). So players would be advised to used specialized clients. But they definitely should be able to JOIN any server, run around a bit, and decide if this game is to their liking. (And I'd prefer a unified metaserver too, but let's cross this bridge when we reach it) Again, I don't mind separate metas, and variants with hardcoded server addresses, I'm just saying we're doing a great disservice to our players. I mean, are we competing? We're basicaly a fork of the same game with 90% (nowdays, less so) shared code. Also, a similar thing happened in Angband history, all the different ports (DOS, OS/2, Win, UNIX variants) were separate forks, to be then merged/unified under common protocol (Z-Term). Now, admittably Z-Term is whack, and our goal is somewhat harder, but it's definitely doable. I mean, every other network protocol managed to do it. The dream goal is to publish a "final" version of the standard, so that new games, in new languages, can continue to be developed in this ecosystem. That's it. So, in a nutshell, the proposal is: - generalize our primitives, and use that, instead of being overly- specialized. - add "infinite" extension mechanism so we can add any new network packets, and clients could support them at will. What has been done in MAng: - PKT_STRUCT_INFO packet (and schema) for tranferring structs such as player class. I've seen PWMA uses it (THANK YOU!!!), but the structs themselves are incompatible (mainly due to V), so we'll have to re-think those. Ideas welcome! - PKT_STREAM packet to stream cave data (line/char) in a unified way. Clients can subscribe/unsubscribe to streams, negotiate their dimensions, pick RLE methods, etc. - PKT_INDICATOR packet which replaces all the PKT_FOOD, PKT_FEAR, etc, in a generalized way. - PKT_COMMAND packet which replaces all the PKT_QUAFF, PKT_EAT, etc, in a generalized way. So this covers like 70% of our basic needs, but there's still lots of hardcoded stuff, like shopping, etc. On the part of the extension mechanism, there's been NO CODE written yet, but I think it should be something simple, like: - At connect time, server sends a number of PKT_EXTENSION "weather" "Some info" Clients have a map for those, so they known precisely what they support. So they send PKT_EXTENSION "weather" "Yes-please-turn-it-on" From then on, Server starts sending PKT_WEATHER packets. Client asked for those itself, so it should be able to parse them properly and not choke. In addition, let's say client wants to SEND some PKT_WEATHER packets (ill example). Again, since this extension has been announced as supported, it can safely send it it. At this step, server authors can differentiate between variants and versions (say, PKT_INVEN is different in MAng150 and MAng153, this mechanism can safely express this). So I would probably name the new inven packet something like "mang153-inven". Or maybe, I'm doing some tomenet hacking, so I'd simple add a "tomenet-weather" extension. HOWEVER, at some point in the future, we can consolidate those into common groups, and then (if we want to), move it from extensions territory to PROTOCOL PROPER (and yes, we'll still have to break protocol from time to time, but we should *always* stride to make it more generic, while doing it, not more specific). (I will experiment with this approach, comments welcome). What else I have in mind: - We're not developing an ARCADE server-compatible protocol. We are developing a network protocol to play roguelike games of the Moria family. That means range of 'q' to quaff commands, Which Item (a-e) inventory management, inscriptions, macros, etc. If you think about it from this perspective, it should be extremely doable. - PWMAngband, and TomeNET devs: *PLEASE* drop your old netcode and adopt the new one from mang. It will a) make your games legal from FOSS/LICENSE stand point, b) clean up 12 layers of UDP-to-TCP mess, c) remove silly bugs like NET_VERIFY FAILED d) add some useful patterns so the logic is not all over the place. I don't ask to adopt our network protocol (although, I would really appreciate it, like I said, from handshake to actual gameplay, it has been designed with extensibility in mind), I'm just talking about the base netcode and sockbuf i/o. (Also, if you want to re-license it, or something, just ask, it's all doable). - From my end, I'm *really interested in collaboration*, don't want to impose any design decisions on you guys (some of mang150 ideas were good, some weren't), and am willing to add PKT_ definitions to mang, which it doesn't need at all. - For example, I'm going to work on the accounts packets (designed after PWMA or TomeNET, or maybe can design something better?) and add those to MAngband, although we are not planning on adding "Accounts" as a feature *ever*. - If we go through with this, at some point, we all will have to release a client/server pair that *completely* breaks protocol compatibility within our own games. Yup, every single player in each community will have to upgrade. BUT, from then on, it's paradise ![]() OK, I think this was long enough, if you are not convinced by now.. ![]() Please contact me (and each other), let's do it!!! Contact me right here, on Discord https://discordapp.com/invite/U5B65Rh, or name a place and I shall be summoned. Last edited by Flambard; February 5, 2020 at 22:03. |
![]() |
![]() |
![]() |
#2 |
Knight
Join Date: Mar 2015
Posts: 755
![]() |
*sign*
It's time to unity our strength, to overcome our differences and to give a new breath to the genre which we all love so much!
__________________
https://tangaria.com - persistent online multiplayer roguelike game tangar.info - my website ⍽⍽⍽⍽⍽⍽⍽⍽⍽⍽⍽⍽ My chars @ angband.oook.cz youtube.com/GameGlaz — streams in English ⍽ youtube.com/StreamGuild — streams in Russian |
![]() |
![]() |
![]() |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Display Modes | |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
[video] 'Tangaria' - multiplayer roguelike adventures | tangar | AAR | 48 | January 17, 2021 22:34 |
Multiplayer Variants | DavidMedley | Variants | 3 | December 25, 2019 15:08 |
Manifesto | Nick | Development | 50 | July 7, 2013 02:17 |
Turning D&D 3.5 into a Multiplayer Roguelike. | Drevasa | Idle chatter | 9 | August 13, 2007 06:29 |
Sangband Manifesto | camlost | Variants | 32 | July 2, 2007 15:14 |