Optional Realities & Project Redshift
-
@Derp said:
Some of the suggestions made just seem like adding features simply for the sake of adding features, even if they don't actually improve upon anything. Sort of like this idea of buttons for all the commands. What does that accomplish that your welcome screen on a mush can't? 'Hi player, we assume you're new, here's what you need to get started.'
Huh? It accomplishes the difference between this:
And this:
The top one is better software, the bottom one the largely preferred software. No doubt this is in part because the instructions on the top one, like the welcome screen of a MUSH, are soon scrolled away and you've got to memorize instead of just sort of peer around the window and poke things until you find the command you want. Or the one you used last time and forgot, dammit.
And indeed, I'd have buttons for the to-room RP stuff. Or, well, an input box that that let you toggle between say, pose, emit, or raw-to-MU. Other stuff in drop-downs that you can bring up or turn off. Everything ought to tell you what the actual command is, same way a lot of software will display the hotkeys for commands next to the command's dropdown.
I've been playing these games, across a pretty good variety of codebases, for some twenty years. Yet I still can find ones where I simply cannot be arsed to check out the game because I don't know the command lines for simple shit, like reading their damn bb. I already know what a MU is, and I already know that I like them, yet I cannot be arsed. This is probably why new users are dragged in by existing users; they can only be arsed when a personal friend hypes the games to them. It's simply too much work to just check it out for the heck of it. Bunch of buttons to poke? Less work.
I am pretty sure that users, mostly, sort of like exploring by clicking buttons to see what can be done, but they don't like reading documentation, taking tutorials, or memorizing command lines.
-
I take it back. A couple of people have paid attention to the past forty years. Just not the ones making the server engines and/or the actual games.
-
So it's been a few weeks since I finally got myself signed up to the OR community site, and I've started some posts, and I've caused a little ruffle, and I've made some decent points, and here's my review:
Having a discussion on Optional Realities is like having a discussion with a young dog. There is a lot of silence coupled with what feels like tilting one's head and looking confused. I'm choosing to believe this as adorable.
The board has this 1-to-5 star rating system that is horribly outdated by modern social discussion standards. It's anonymous, as well, reducing it to counting the stains on a hotel mattress for all the good it does. It was explained to me that this system was to make sure that good posts were rewarded and "shit posters" are tagged. In practice, it's just as useful as WORA's old voting system.
The Optional Realities administration says they will discuss my suggestion to just go with a modern up-/down-vote system, or even just up-vote as positive reenforcement. Again, I get the sense that I might as well be throwing my suggestion into a slot over a suspiciously cylindrical container, one that is likely to be picked up and disposed of once per week.
It doesn't feel cozy, like some small communities can be. Its strongest personalities seem to be those we already know here: @Volund and @Griatch, as well as someone named "Unironicshitposter", which I find ironic since I don't see him shit-posting. Maybe I've just missed that phase.
I can't fault a new community for being new, but I can't find its soul nor its culture.
-
We know its culture already. Sales. At least one of its principals has come out and said that.
This whole debacle reminds me of a tea chatter place I frequent. Now I make no secret here that I'm a huge aficionado of tea. This means I tend to know my shit and, more importantly, I tend to know what it is I don't know. (I personally find the latter knowledge more important of the two.) I hang out in a forum of like-minded people: people who like teas (and tisanes) and want to learn more about them.
Into this forum comes someone who suggests we join another forum of people who've been around for longer discussing tea. Several of us eagerly go to join other tea lovers and expand our knowledge and social base.
Uh…
Problem is: in our small tea group we've got people who can meaningfully express the distinction between a <deep breath>Castleton Estates TGFOP 1st Flush Darjeeling</deep breath> and its 2nd flush kissing cousin, explaining why they prefer the "inferior" 2nd flush in most circumstances to the rarer and more expensive 1st flush. And we've got people (well, OK, me) who are currently exploring the bewilderingly huge world of pu'er tea. And we've got a guy now tackling all the weird traditional tea-like beverages like "rooibos" (still have to track down a good source for that to try it out) and making reports on progress. Other problem is: the other "longer, better-established" forum consists of people whose idea of talking about tea is "I just found this place near my home that sells TWINNINGS Earl Gray!"
That tilting the head and looking confused thing? That was my impression when one of us started asking about favourite estate-grown teas and tea-growing regions. There was absolutely zero engagement across the divide because, although we were both "interested in tea" we were interested in radically different subsets of the topic of tea. We drifted off back to our own forum where we were happy and left the others over on their forum where they were happy. We had smug thoughts about their shallow understanding of the topic they purported to love and they probably had their smug thoughts about our pretentiousness.
I'm getting this vibe from the OR crowd, only … they kept coming BACK to tell us about themselves after it was pretty clear we weren't compatible. At least they've cleaned up that part of their act. So far.
-
@WTFE said:
There was absolutely zero engagement
Over-extended analogies aside (first ducks and now tea), the non-staff of OR made the biggest case for me to try it out. I was excited to see what the Evennia Folk were energetic about, and there is a little of that over on the OR communities as well.
I do have to remember that I can be hyper, that I like my interaction to be immediate. When I'm involved in other projects, though, the last thing I want is someone yapping in my ear for my attention. For that, I respect the Evennia folk not jumping immediately because they have in a very short time shown that they are willing to engage.
Sales.
So I decided to test the product. I suppose @Jaunt had a point that I was doing a lot of nay-saying about a product I knew nothing about. It's not a very good point; advertising, not shaming, is supposed to get you to want to try it. But it was a point. I think I've been fairly clear that it was a tangentially related group whose word-of-mouth drew my attention, but grass-roots campaigns are effective.
If I were to talk with zero-percent negativity, to give Optional Realities only constructive criticism, is that I think they're overextended, that they hope for the community and want to build that community through common dialogue spurred through their articles.
I think these articles are part of the problem. They are a product, and one I don't feel most of the authors are passionate about. They come off as separate from the community boards, and a community centers around interactivity and involvement. If the administration isn't showing interest toward the community, they can't expect anyone else to fill in the gap. It has happened, but they have to be damned lucky to find people with that passion.
I'm going to continue reading and posting there from time to time, because you all know that I do like to talk, and many of you know that I do like to learn the way similar people see the world differently.
-
@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.
-
-
See it would be "uncharitable" if any actual advances had been put into MUSH code bases in the past 20 years. Let me count the advances I've seen:
- Some MUSH code bases have primitive RDBMS interaction capabilities now.
- Some MUSH code bases have Unicode capabilities inserted.
- Some MUSH code bases have the ability to sense if a kinda/sorta HTML-supporting client is attached and can kinda/sorta support it.
That's about it. Over 20 years. Now look at the huge foundational changes that have taken place in computing in that same time period. In every field (with the possible ironic exception of development tooling) there have been huge strides in making things accessible and friendly for users. In that same time period MUSHing has not taken even a baby step forward.
So if calling out this painfully slow maturing process is "uncharitable" then I guess I'm just Steve Jobs reincarnated. (The joke here, such as it is, is that Jobs is (in)famous for not contributing to charity ever.)
So it then becomes a question of how to make the game more approachable to newbies without alienating your core users.
See, it's statements like this that cause me to make cracks about ignorance of 40 years of advances. On the computer system I'm using right this very minute I have a GUI-based file manager open and a command line shell in the same directory. For a certain class of operation (selecting a set of files quickly and doing something simple to them) the GUI file manager is better. For another class of operation (selecting single files or large batches based on patterns and/or performing complicated operations on them) the command line is better. There's two views and two approaches to operations on the same thing. (And, I might add, doing things a whole lot more complicated than what a MUSH does.)
And that is one example of many just on the desktop in front of me right now.
The notion of having multiple views and interfaces on a problem domain is ancient technology. It goes back well past the first MUSH ever being written. Want to cater both to your newbs and your grognards? Just ... do it. Give the whiny grognards their idiotic (1- Lisp) language and their primitive interface. And give the newbs a modern interface that doesn't suck. Given how trivially simple the grognard interface is to implement (it's almost the embodiment of Worse Is Better after all) it shouldn't be too hard to slather a grognard interface atop a sane core that presents a sane interface to a client based on modern principles like "discoverability" and "theming" and "not sucking matter out from behind the event horizons of galactic black holes".
-
@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.
-
I agree that there's lot to gain from a hybrid between past and future. In this respect Evennia is not really mired in the past though. We do support telnet and the interfaces of yesteryear but Evennia is protocol agnostic and not dependent on these legacy protocols directly (you can turn off telnet completely in settings if you don't want to use it, by default it's one way to connect among many). It is its own webserver and our websocket client can be customized as you see fit.
Admittedly we could (and will hopefully soon) offer better gui building blocks out of the box in this respect, but a game dev knowing javascript can basically put whatever gui functionality they want in front of their Evennia server.
.
Griatch -
I have literally no opinion on Evennia beyond not really liking the name much. (Although it's light years ahead of PennMUSH, RhostMUSH, TinyMUX, etc.) I have no idea what you're doing with it or where you're going with it except from a few things I've seen here and there as you guys talked about it. What you just said sounds like you're going in the right direction, however.
-
The server must indeed come first, agreed. If that doesn't work well, then no fancy UI will save it.
@WTFE said:
I have literally no opinion on Evennia beyond not really liking the name much.
Hah, I'm not a huge fan of the name myself but as some point I just had to just decide to accept it and move on. I completely blame the original creator of Evennia for that one. I don't think he ever expected his experimental little hobby server to grow to what it has become.
.
Griatch -
Hey! You got your Evennia Conversation in my Optional Realities!
-
@Thenomain said:
Hey! You got your Evennia Conversation in my Optional Realities!
Sorry To go back on topic, I personally enjoy the articles on OR - and I'm not just saying it becaue I've written a few. Longer articles on game development is not common when it comes to MU* games and I'm quite happy to see someone taking a stab at pulling it together. Clearly, if you have no interest in making your own game (and those articles are also often targeting the mud side of things) most of them are not for you.
Doesn't mean they have no value though. I might not agree with all in there but in the same way I enjoy editorials in a newspaper I enjoy reading the OR articles. Besides, they are written by people on topics they find interesting and the very observation of what people choose to write about is in itself informative.
.
Griatch -
The articles are fine.
Optional Realities suffers the problem of not knowing what it wants. The main page gives the opinion that you go for the articles and talk about them, or talk about the games that OR advertises, but I don't see that happening.
I blame the articles in part because most of them are not written to entice dialogue, and partially because the conversation it does create goes nowhere; I've read and I've tried. I can think of a series of game design articles that encourages the former and gets the latter:
There's your game design blog. Now, it's video game design, but they have a few things going for them that OR does not:
- They're professionals. This alone may give them the time and opportunities to be more passionate about their chosen field, but without engagement I don't think any community is going to thrive.
- They include all forms of online gaming. They know MMOs came from Muds so don't rule Muds out. They don't rule anything out.
They don't have one thing that OR and Soapbox does:
- By Mudders, For Mudders.
This is no personal vendetta against OR or anyone on OR. I've wished OR was more inclusive since day one, but instead I'm trying to review them on their own merits and by their own goals. I will try to write a second review based only on the articles, but it will have to wait some time.
-
So I read three articles and replied to each on Optional Realities.
In summary: One was enjoyable and conversation did spur from it. One was bland and eh. One baffled me to the point of frustration. My response to this last one edged on the unreasonable, but there's only so much BS I can take in my day.
I'll keep at it, but I said I'd read them on their own merits. I'm giving them a C- so far. I'm hoping I just hit a bad spell for them.
-
@faraday said:
- Doing something more interactive with auto-populated buttons and such requires not only a new server, but also a new client
Does it really? I was imagining maybe that the MU server had a text file, settable by the owner, which the client grabs and reads -- the content tells it what buttons to auto-populate. New client, yes, but that file would be something one could add to any game.
Buttons should all be closable, re-open 'em from a drop down if you want them again, like Photoshop toolbars and menus.
-
@il-volpe said:
@faraday said:
- Doing something more interactive with auto-populated buttons and such requires not only a new server, but also a new client
Does it really? I was imagining maybe that the MU server had a text file, settable by the owner, which the client grabs and reads -- the content tells it what buttons to auto-populate. New client, yes, but that file would be something one could add to any game.
Buttons should all be closable, re-open 'em from a drop down if you want them again, like Photoshop toolbars and menus.
I don't even think this would require a new client, in that case. Mushclient already supports plugins written in whatever it is that you write mushclient plugins in. Betcha you could already get it to recognize something like that if you made the syntax universal.
-
If all you want is for the client to send normal commands when you click a button, then you only need to change the interface of the client or use an existing client with a customizable interface offering buttons. On the outgoing end you can also let the client do regex-matching in the server's outgoing data (such as is common for extracting "prompt" info from the flow of text and display that in a fixed location).
With tighter out-of-band connectivity though it can be beneficial if the server also supports some form of Out-of-band (OOP) protocol. Examples for its use is for the server to update the client also without player input (the classic example is to update the graphic of a health bar) or other custom output not necessarily easy to regex out of the flow or is specific to a particular type of client (like non-text media, server-directed splitting of data to different client gui elements etc). There are a few telnet subnegotiation-based OOP protocols like AMCP/GMCP and MSDP; for webclients JSON is likely the easiest.
.
Griatch -
@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.
-
@faraday I am sure you, and many others, know much better how this ought to work. I just think it should exist, and come like that outta the box. It also should have some sort of connection to a MUDlist such that you can essentially click 'add this game' and away you go.