Hacker News new | ask | show | jobs
by ndguarino 1793 days ago
MUD player for ~20 years, (previously) administrator/developer for ~5. First of all, great work on pushing this out and making a usable product, especially one built for people who aren't entirely familiar with writing software (which is often the big hurdle for starting a new IF game or MUD).

I haven't had time to play with it, but I do have three (or 2.5) pieces of feedback based off reading the documentation.

1. Service subscriptions are solid, and using them for multiplayer access is entirely reasonable here. $15/mo isn't actually very much for that, especially since hosting is handled, so that's an exquisitely low barrier to entry for that. That said, Patreon is a big turn-off for a lot of people (including myself, though I'm not necessarily your target audience either).

2. Lack of telnet connection on multiplayer worlds is a big hurdle. Most MUDs/MUSHes/MOOs are telnet-based, and by not making this a way to connect, you are effectively turning away ~30 years of software written, and a good percentage of the people who have grown used to this software. In the MUD I worked on, I still had players using zMUD because it's what they preferred and what they had things built for, despite it not having been maintained for years and not being able to use several features of the MUD as a result (xterm colour, MXP, GMCP and other telnet subnegotiation protocols).

2.5. VIPs (Visually Impaired Persons/Players) and accessibility. This is one of the largest userbases for a MUD or IF game, as other games that are accessible to them are somewhat rare. I cannot speak to how screenreader-friendly your web client is, but telnet access lets them use clients that already are compatible and integrated with screenreaders.

2.75. Players with terrible internet. Many countries have great internet. Many countries, and even parts of countries that would otherwise have great internet, do not. A lot of players I've met in MUDs played them not because they were enthusiasts, but because they were more friendly to slow connections with high latency. Throttling my connection to some test settings I used for testing data flow to a couple players so I could recommend settings to them and test things for them, your client and the initial screen of the game you have on your homepage linked to the "Play" button is 44s.

There is a chance none of these are concerns for you, and that is an entirely fair decision - you can't develop for everybody. But I hope this is useful feedback.

2 comments

Not OP but somebody else who has worked on the platform. Thanks for the feedback! I can't give quite as good of a response as teebes but I'll take a crack at it.

- Patreon isn't the ideal subscription service but it was the most lightweight tool we could find for the job since some users wanted to contribute and it didn't make sense to integrate a full payment platform right now. Is there a particular reason that you find it off-putting?

- Telnet actually came up recently on the Discord. It's something we might do, but would take a fair bit of work and loses out on some of the UI we've incorporated to try to make combat a little more engaging like cool down timers and cast bars. That said, we're not opposed to it if there's enough demand and people would actually use it.

- We've actually had a few visually impaired players and gotten some very useful feedback! There is a 'Use Accessibility Layout' option that tries to optimize the experience for screenreaders, although there is likely room for iteration.

- That's a fair point and may be tough to optimize to the same degree while taking advantage of the more modern frameworks that make the platform (hopefully) more user-friendly. That said, there's probably some refinement that could be done there to at least help a little and I would imagine that once in-game, the packets going back and forth don't put too much strain on the connection.

Always good to hear from people who know the space!

Yeah, Telnet will definitely be a lot of work if you do decide to go for it. For cooldown bars and such, I'll recommend using a subnegotiation protocol for all that (GMCP is the one widely used these days, all the major clients support it to some extent and it's effectively just a 'string + json blob' payload), and my experience is often "if you make it available, it will be built" with MUDs.

I'm extremely happy to hear that visually impaired players are accounted for. It was always one of my personal 'hills to die on' in MUD development.

As for Patreon, it's just personal preference. I just want to be able to put in my card details and go - Patreon makes me juggle Yet Another Account and, if you aren't a Patreon user already, the time to get a subscription is highly increased. Anecdotally, I'm not the only one I know who feels this way. I spent years just avoiding anything that made me sign up for a Patreon account just to avoid the hassle of it, and only caved in to support a friend's project. I know some who will still just see Patreon and run the other direction. It also might just be me, but I have horrible luck with services that integrate with it - it won't link the patreon account or recognise that I'm paying, and I need to get manual intervention on getting the thing I'm subscribing to.

This is an exciting project! Been hoping someone would build a decent modern MUD creator - I played MUDs a long time ago but have been disappointed to see the medium largely stuck in 90s conventions. At least from my perspective telnet is an anti-feature because it limits design possibilities. There's already tons of telnet MUDs out there, I'd try to push the boundaries of what is possible in a web browser instead, and be willing to break some rules and expectations of MUDs. I'd love to see music, environmental effects and rich media, some focus on buttons > text parsing, and generally trying to adopt modern conventions and trying new things.

Accessibility on the other hand is 100% a good thing to implement. Text adventures are more than any other medium theaters of the mind, and any additions you make to them should fall back gracefully to that core idea.

> Lack of telnet connection on multiplayer worlds is a big hurdle.

I believe that MUD developers' fixation on telnet support has been a major contributor[0] to the ongoing decline in popularity of MUDs over the last decade. It's a terrible protocol on which to build a multiplayer game. Supporting it as an option requires some kind of server-side content rendering layer which can be inherently restrictive to your other client offerings.

[0] There are others, yes. Particularly licensing issues and gameplay norms.

It's not really the fault of MUD developers, more the obsessive nature of the players, who each have their own favourite client that is set-up exactly how they like it, and full of huge macros and plug-ins that only they understand. These players will not even try out your new MU* if it doesn't support their client.
I think it is the fault of the MUD developers, because they feel like they must support those players.

The group of people who play MUDs "traditionally" (with a dedicated, telnet-based MUD client) is small and shrinking every year.

The group of people who play lo-fi, retro-style games is large and growing every year.

Why give special treatment to the former group if it hinders your ability to appeal to the latter group?

> Supporting it as an option requires some kind of server-side content rendering layer which can be inherently restrictive to your other client offerings.

It should be no more restrictive than the concept of supporting text rendering at all--which maybe want to be able to avoid?--as, worst case, you could literally just run a text client on a server on behalf of the user.

It's restrictive in that it requires your content to be rendered as a continuous stream of text. That sort of rendering is not suitable for all text games that could be considered MUDs. It's not even all that suitable for the more popular MUDs that still exist.

Now, this is not a hard requirement of the telnet protocol, for sure. ANSI controls exist, as do various sub-protocols, but support for these is mixed across telnet clients and therefore can't be relied on (unless you're willing to say your game can only be played by a subset of telnet clients, I suppose).