Posts made by faraday

@Thenomain Huh, I never even knew width() existed. How does the client communicate the width to the game?

@Thenomain @Griatch FWIW in terms of builders being mini-coders, the common examples I've come up with where builders might need functions are things like spacing/formatting, weather and time of day. My plan for AresMUSH is to make these things into format codes. I confess I stuck with the existing paradigm of % codes for formatting. Ares is geared towards backwards compatibility more than extensibility.

So in addition to the old standbys like %r for a linebreak, you can have things like %l1 and %l2 for those nifty border lines that turn up all over creation, and %timeofday for the time of day, and %weather for the weather, and stuff like that. (Admittedly the latter two are in the TODO column still, but that's the idea).

Edit to add: Oh, and I stole the %x and %c codes from MUX(?) for ansi control. So %xb toggles on blue.

@Arkandel I wouldn't want to have multiple tabs open for my games, and web page notifications are kind of flakey in my experience. The Slack chat client has a web app - but I far prefer the desktop client. That may just be a matter of personal taste.

I also have to disagree about logging. Existing MUSH clients log without needing to copy/paste anything, and I don't really want my logs auto-posted to a wiki; I want them saved to my hard drive. Not saying you can't do it, but live-update logging to a file on your desktop is not really what web pages are geared toward.

You're quite right that there are a zillion libraries and methods for web development. It's a lot easier than it used to be, but it's still hard IMHO. And I say this as someone who writes web apps for a living

Anyway, as you say - Evennia offers web functionality for those who need it, so props to them. Time will tell if that proves to be the wave of the future.

@Arkandel Oh, sure, in an ideal world who wouldn't want to just be able to go click-click-click and set up a character with a graphical sheet like you do in every video game under the sun?

But when you think about the user experience, IMHO it becomes a little murkier. Right now I can have multiple character windows open across multiple games, yet still have a central client to flip between them and a central notification system. The games all have a different syntax, but fundamentally they all work the same way and I interact with them in the same way. I can save logs to my desktop easily. Replicating those core experiences in a web client is going to be a challenge.

Then consider the coding experience. Somebody has to build these games. Video games have the luxury of having a team of professional developers working on them 9 to 5 (well, more like 9 to 9 to hear some of my game programmer friends talk). MUSHes are lucky to have one hobbyist programmer who also, y'know, wants to play the game. Speaking from experience, throwing together a simple command-line MUSH command is a heck of a lot easier than learning the nuances of any web framework (to say nothing of the cross-browser headaches that plague every web programmer out there).

I'd love to be proven wrong, but at this point - color me dubious.

@Roz It's definitely a barrier for entry, but I think a more user-friendly MU client and better tutorials can go a long way to help with that.

@Arkandel Someone might accuse me of being short-sighted or a dinosaur, but I can't imagine myself ever MUSHing in a web browser. Logging, activity notifications, multi-worlding... to say nothing of making point/click GUIs for every feature from BBS to channels... Sure you could do a fancy web client to support all that but goodness I wouldn't ever want to.

I don't think having a custom app is a huge barrier for entry. MUSHes are a lot like chat clients, and you still see a lot of people using apps for chat.

@Griatch I think the biggest issue is that "builders" kind of straddle the fence between "players" and "developers" in terms of their use of inline functions.

For example:

[center( [ansi(b, BLUE)] [repeat(-, 10)] [ansi(g,GREEN)] , 40,~)]

Gives:

~~~~~~~~~BLUE ---------- GREEN~~~~~~~~~~

Where blue and green are shown in their respective colors.

Perhaps if your markup language is sufficiently advanced it could handle this sort of thing, but that might be more complexity than it's worth.

I think it would be good to stick to the style of interpolation markers that are increasingly common in programming languages, whether that's #{x} or %{x} or ${x} or even |{x}.

That said, I'm not convinced that having a simple shortcut for some of the more common MUSH substitutions like %r would be a big deal. Ares is able to tell the difference between %r and 75% without forcing you to escape things all over the place. Given Evennia's model, something like that probably belongs in a MUSH-specific addon, though.

@WTFE I'm not sure I see that as an "advantage". As you say, checking for the presence of something is a core part of almost any application, whether it's checking for a message or checking to make sure the user didn't forget to provide some critical piece of data. Why would you want to re-invent that concept every single time you do an app when the ubiquitous nil/null check is something everyone's already familiar with?

@il-volpe I don't think the server should be telling a client what buttons to auto-populate. At best it would say 'here are all the commands I have available and the parameters they take'. But that still seems rather primitive to me. What @Griatch describes is more what I was thinking of in terms of new client-server interaction.

@WTFE I was not referring to the existing server bases, but rather the emerging ones like Evennia and Ares that are attempting to incorporate new technologies and paradigms. Sorry if I misunderstood your point; this thread seemed very Evennia-centric.

That said, I would argue that command-line interfaces like Linux/Powershell have not made the sort of stunning "foundational changes" that you're alluding to. MUSHing is, fundamentally, a command-line interface.

Now if you're talking about changing that fundamental foundation, groovy. But as I mentioned, that requires not only a server-side change, but a client-side change as well.

Personally I believe the server should come first. Once you have a server baseline that isn't using 1980's tech and a bizarre variant of a long-dead programming language, you can start talking things like: "OK, how can we extend that server to do cool new things with new clients while still supporting old clients."

I'm not trying to be Steve Jobs here. I'm just trying to take that first baby step.

@WTFE I can't speak for @Griatch and others, but I can say that keeping a near-identical player experience with AresMUSH compared to the existing ones was a very conscious choice made for a multitude of reasons. A few critical decision points:

• As @il-volpe mentioned, there are players who "can't be arsed" to check out a game with an unfamiliar command line. I know people who stick exclusively to MUX or MUSH just because the different channel syntax drives them nuts. Familiarity is essential for adoption.

• @program has its place, but when you look at well-established command line systems (Linux, Powershell, DOS) they are uncommon. And for good reason. There are other ways to implement 'training wheels' that do not require prompting people at every step (especially when such prompts are annoying to veteran users).

• Doing something more interactive with auto-populated buttons and such requires not only a new server, but also a new client - and one that works across PC/Mac/Mobile platforms. MU players are as passionate about their favorite client as Mac/PC users. Having a new server take a route that's incompatible with existing clients is something you do at your own peril.

I can imagine someone saying: "But all this is about existing players, who are dinosaurs. You should be worrying about the hordes of new players MUSHing is missing out on." IMHO, if you apply modern user-centric design principles, it becomes apparent that veteran MUSH players are the most likely audience for a new server.

So it then becomes a question of how to make the game more approachable to newbies without alienating your core users. I think it's possible to do this, mostly by taking a baby step that incorporates important technology necessary to take the next step, and the next, and the next.

It's totally cool to disagree with these design decisions. There is no 'right' and 'wrong'. But to suggest that they were made out of ignorance of the last 40 years of software development is, I feel, uncharitable.

@Griatch Interesting. Yes, I think Ruby helps quite a lot here. Also the architecture of Ares helps too, as heavily-interconnected modules are discouraged in favor of modular plugins with well-defined APIs. And even if you mess up the code by screwing up one of the connections, the underlying engine is as bulletproof as I could make it to this sort of error. Just tweak and reload and everything's good.

@Griatch It's basically what Tyche said. The plugin architecture does most of the work for you so as a developer all you have to remember to do is reload the plugins you changed. Happy to discuss in more detail if you like but I'm not sure this topic is the best place for it. Feel free to contact me if you want to know more.

@WTFE - There are plenty of examples of plugin infrastructures. It's not like we're doing something revolutionary here.

@Griatch Yeah, I think the documentation picture is pretty similar. It's a lot to cover.

The plugins can be hot-swapped thanks to Ruby's dynamic capabilities, but changing the core engine requires a game restart. Hopefully that should be rare.

@Griatch Yes, Ares calls them Plugins, and basically everything except the core connection and command dispatching infrastructure is a Plugin. Movement, poses, multi-descer, channels, chargen - they're all Plugins. Here's some sample code for the silly little Cookies (+nom) plugin.

Documenting how to use it is the biggest chunk remaining on the backlog.

It's built on the idea that coding will either be done through the server shell (telnet/ssh into the server itself) or using a traditional version control/development paradigm like GitHub.

I'm not saying that's superior to being able to tweak code live on the game command line. It's just a different model, with both advantages and disadvantages.

Bit late to the party here but I wanted to chime in with another perspective.

AresMUSH is a MU server I'm developing that's similar to Evennia. It also does not support Softcode, nor are there plans to ever support it.

Why? Because Ares is not intending to replace existing MU servers, but to provide an alternative.

If you're happy with softcode (or are willing to learn), and/or allowing players to tinker with code in-game is a necessity for your game, then Penn/Tiny will meet your needs just fine.

But if you're like me, and would rather gouge your eyes out than look at another line of MU softcode, then an alternative like Ares or Evennia might be a good choice for you. (Ares uses Ruby, FWIW).

Or if you're not a coder, have no desire to be a coder, and just want something that supports basic RP-MUSH features out of the box with minimal configuration - Ares might be a good choice for you too.

Evennia is a much broader platform meant to support a wide variety of server types with different needs. Ares has a far narrower focus for lightly-coded RP MUSHes.

They're just tools. Pick the right tool for your job.