@arkandel said in Alternative Formats to MU:
In this thread's context though all I'm saying is that the key isn't so far to do away with some features we are familiar with or to do them differently, it should be to provide the technical capability to do so.
I disagree. A platform that tries to be everything to everybody is by its nature going to be either
- incomplete - requiring you to fill in the blanks yourself (e.g. current MUSH servers) or
- insanely complicated. I mean, it's nice to talk about magically-functional Wordpress plugins, but have you ever tried to write a Wordpress plugin? There's a reason why almost all of the decent ones are behind a pay-wall.
So it comes down to what your goals are. With Ares, my goals are 1) Make it easier to play, 2) Make it easier to create a game, and 3) Make it easier to code.
All three of those core goals get screwed if I try to keep every existing feature, plus every conceivable feature you could build with current softcode, plus a web UI on top of that.
Keeping to those goals requires compromises. There are many compromises I've made with Ares. Some of those will turn off some people. I don't really care as long as it doesn't turn off everybody. (Which is why it's not web-only even though I'd like it to be, because that would turn off almost everyone.)
@alzie said in Alternative Formats to MU:
I think there's a confusion here that if we allow backwards compatibility with telnet it's an all or nothing agreement. This isn't true. You could allow a telnet client to connect and make the same commands people have always been used to, but also provide a web client that runs off a restful API. These things are not mutually exclusive.
They're not - Ares has done it. But as @Roz said, that choice has added a lot of complexity to the code that I wish wasn't there.
Just a trivial example, let's say you want to have "Race" as a new chargen field for your space-game-with-aliens. With either telnet-only or web-only you'd only need to touch two things: the command/screen to set it, and the one to display it. But when you try to support both, you now need to have the telnet command to set it, the telnet command to display it, the web screen to set it, the web screen to display it AND the Rest API to allow it to be set via web. And help files for all of that. And oh-by-the-way they're in different languages, because web uses Javascript/HTML and the backend uses Ruby.
And that's just for one extremely trivial command race <race>
. Now multiply that by a thousand or so different commands/features.
Now imagine explaining all that to a novice coder trying to learn a new platform and you hopefully see the problem.