For those who are curious what I meant about doing something as both bboards and and a web forum, here is a short little example.
Posts made by Sparks
-
RE: Separating UX from Functionality (Design Patterns!)
-
RE: UX: It's time for The Talk
@RnMissionRun said in UX: It's time for The Talk:
@Thenomain said in UX: It's time for The Talk:
Crow about Pueblo or MXP as much as you want, it never made it into Mush-user-style clients because nobody convinced us why we'd want it, and to do that someone has to use it.
The biggest problem with things like MXP is, people would have to switch clients to use it, and trying to get people to use a different client is like trying to sell ice to Eskimos.
Atlantis 1 supports MCP—both internally (the standarized editor package and a few others) and for the plugin API that no one but me ever used, and for scripts. I think two people ever used it.
I'll probably still end up adding a few other things like MXP, MCP, and so on to Atlantis 2, but my expectation that anyone will use them is Not Particularly High.
-
RE: Atlantis Client
Hm. I can genuinely say I've never seen that one. I wonder if something changed on the Ares side? I'll log into BSGU a bit later and see.
(Also, I apparently missed this thread when I wasn't paying a lot of attention to MSB back in April. Oops!)
-
RE: Separating UX from Functionality (Design Patterns!)
@faraday said in Separating UX from Functionality (Design Patterns!):
Personally I'm quite comfortable and familiar with MVC, but most MU coders are hobbyists. Simplicity is more important that design patterns IMHO.
Compare having everything in a single command handler:
class FooCmd def handle parse the input do something emit something (usually to the enactor) end end
Versus having a model, a controller, and multiple views. Self-contained is way simpler.
Fair. I suppose it depends entirely on what you're doing. If, for instance, FooCmd is part of a bboard system, you already need a model for the Boards, for the Posts, etc., and so there's no real harm in making both a "commands" view and a "web" view. Similarly, for chargen, you probably already effectively have a model for the character, so there's no reason you can't just make two separate views into it.
For basic commands, it makes no sense, no.
For systems, which are probably going to include something model-like whether or not you actually design them deliberately as such...
-
RE: Separating UX from Functionality (Design Patterns!)
@faraday said in Separating UX from Functionality (Design Patterns!):
The complexity of supporting two independent views and making sure everything melds together is just... no.
I never claimed to be sane... <_<
-
Separating UX from Functionality (Design Patterns!)
So, since UX design seems to be heavily on people's minds at the moment (see the UX Talk thread), I have a more practical question: what about separating the UX from the functionality?
Some folks don't get bboards (which are modeled after old dialup BBSes in some ways, or maybe Usenet) and would prefer a web-based forum. Others want their posts accessible right there on-game. So why shouldn't we abstract the data? Boil it down into boards and posts, add a reply function if you want to reply directly to a post, and expose the boards and 'threads' on a website?
Then you can have your old-school +bbread or @bb/read type functionality on-game, alongside a phpBB-type web forum. They have the same backing store, the same read/unread flags, the same permissions checks. Just a matter of preference as
Couldn't we do this with other things? @mail/+mail and a webmail interface? One practical example is Arx having +finger type information available on the website as well as on-game, or @faraday putting chargen and combat setup onto the web portal of the game rather than just in-game commands. (Chargen and character application seems a major, major win to move to the web, in particular.)
This is a reasonably common model of development as it is; many will recognize the concept of "models" (data) and "views" (UX). It takes some thought ahead-of-time to separate your backing model from the front-end UX view, but when done right, I think there are benefits to doing so.
(This is heavily on my mind because I'm writing the aforementioned bboard module for Evennia right now, as mentioned elsewhere, and about to move on to a chargen toolkit and some other things. Filling out an Evennia toolbox for whatever future projects crop up.)
Does anyone else think this is a useful expenditure of time, designing things on a pattern like model/view? Are there other patterns you think would work better for a modern MU*-ish game?
-
RE: UX: It's time for The Talk
@HelloProject As far as I know, +mail was actually one of the very first softcoded commands, and as such is actually responsible for the + prefix as well. (Someone correct me if I'm wrong?)
-
RE: UX: It's time for The Talk
@HelloProject said in UX: It's time for The Talk:
I'm just gonna say that I never saw what +mail contributed to anything. It's never been more simple than the hardcoded mail and always just seemed like an annoying new thing to learn. I've yet to see anyone adequately simplify mail in a way that justified having to learn entirely different annoying mail code rather than just keeping annoying mail code I actually know how to use.
I'm not suggesting that I know how to make mail simpler, just not to replace it with something that isn't particularly better and then I have to learn that too.
You're not wrong, but... +mail predates built-in mail, so some folks view the built-in hardcoded mail as learning "entirely different annoying mail code rather than just keeping the annoying mail code I actually know how to use".
-
RE: Cupcake's Playlist
@Tinuviel We've got a burn notice on you; you've been blacklisted.
-
RE: UX: It's time for The Talk
@Rook said in UX: It's time for The Talk:
MUX/MUSH usually accepts 'w', too. Aliases at the server level are a grand thing.
To be fair, Evennia has server-level aliases too, and it will even automatically alias all the helpfiles. It's just that
whisper
is not a command that has those server-level aliases built in. (But you can add your own user-specific aliases using thenick
command.) -
RE: UX: It's time for The Talk
@Thenomain said in UX: It's time for The Talk:
Players will put code on themselves to turn 'where' into '+where' if that's what they're used to, or help people create macros for their client of choice. They will do this in spite of you or what you want.
Truth.
I literally typed
whisp <whoever>=<blah>
, cursed, and then typedwhisper <whoever>=<blah>
on Arx so many types, I just added a 'whisp' command to myself that does whisper for me, using the Evennia command alias system. Not becausewhisper
is wrong andwhisp
is right, but because after years of having MUSH acceptwhisp
, I honestly cannot break that muscle memory. -
RE: UX: It's time for The Talk
@WTFE said in UX: It's time for The Talk:
Or even better just make setting a command!
set <property> <target> <foo>
. And to read itget <source> <property>
and to read it in codeget(<source>, <property>)
and so on.For your command there, is
property
allowed to have spaces? Istarget
? If they are, am I required to put quotes around them? That's not going to be super-intuitive to a lot of non-coders (or at least, people who aren't used to UNIX shells) either.The problem is that computers aren't people. To us, if you have "Captain Aardvark" as a character, and want to set the 'approved' value to 'true' on Cap,
set Captain Aardvark approved true
makes sense. But the computer's going to see that as settingAardvark
toapproved true
on the characterCaptain
, which may not work so well for your chargen approval code.So you go, well, I'll separate the
property
andtarget
... let's doset <target>=<property> <foo>
. But now what if you wanted a space in that property? Well, let's separate THOSE too, and... hey, hang on, now we haveset <target>=<property>:<foo>
, which is the actual MUSH syntax (minus the @ on the front).It's a terrible syntax, but it arises to solve genuine parser problems.
Now, there's probably better methods to do this than stateless single-line commands. You could have, for instance:
edit Captain Aardvark set approved to true set approver Sparks show save done
...which would be like opening a document, tweaking things, and then saving it
Part of the problem arises with MUSH, where commands and code are identical; you want
@set Captain Aardvark=approved:true
because it needs to be a command usable in code, not just for a user. That interactive session might be great for a user, but it's not so hot for code that's basically a glorified batch script.With newer stuff like Ares or Evennia, the code (in Ruby or Python) and the commands (actually entered by the user) are wildly different. That's where we get freedom to come up with wholly new commands and interaction models for even the lowest-level stuff. The problem is, the hobby is still made up of folks who are used to doing things a certain way, and many of us get grumpy when we discover that, hey, it's not
page WTFE=How are you doing?
anymore, but instead, say,tell WTFE Hey, how are you doing?
ortell "Captain Aardvark" Hey, were you up for that scene?
Heck, I've seen people get grumpy at Arx for requiring commas in the mail recipient list, when @mail/quick is otherwise more or less identical in syntax to MUX2.
-
RE: RL Anger
@Misadventure It is a great city. I loved growing up there and worked at Seattle Opera for awhile. But I'll say what I've always said to people ... either know someone there ahead of time or expect to work at making friends. Granted there are so many people there who are people who have moved there, its probably rather different now than it was back in the 90s. Sparks might be able to help with how it is now.
I think there's still some aspect of the Seattle 'chill', where folks are sometimes viewed as chilly/standoffish because they prefer a small number of really deep friendships over trying to make a more shallow connection to every single person. The way I tend to put it is that it takes forever to befriend a native Seattlite, culturally, but when you do we'll tend to help you bury the bodies.
But yeah, the culture has shifted a lot, and there's enough recent emigres that many don't really have that same trouble finding a social circle, I don't think.
-
RE: RL Anger
@Ataru — As someone born and raised here, rose-colored glasses are a reality, you're not wrong... but our housing costs and traffic were sure as hell a lot saner before Seattle became "cool". We've expanded without any sort of sane urban planning, and it's hurting the region badly.
(What drives me insane are the other native Seattle folks who have this whole desire to cling to those rose-colored ideals of the past, and who don't like the change we need for a city this large. "I don't want light rail where I can see it from my house!" "I don't want apartment buildings in my neighborhood!" And so on.)
-
RE: UX: It's time for The Talk
@faraday said in UX: It's time for The Talk:
@Sparks said in UX: It's time for The Talk:
I really think something developers writing games nowadays should do where possible is make a standardized, generic UI library. A standardized method of headers, of footers, etc.
I dunno... in my experience the headers/footers are one of the first things people want to customize when they take my stock codebase and make their own game with it. I don't really see how this will help - especially when dealing with such vastly different codebases.
Ah... sorry, I should clarify. The coder on a given game should make a standardized UI library for that game.
I.e., if I take AresMUSH and make, I dunno, SecretMUSH based around the general setting of The Secret World, I-as-coder should make an effort to provide a library that standardizes the UX.
I'm not saying you with Ares or Griatch with Evennia should provide wholly standardized UX that everyone should stick to because, yes, you're right, gutting it and replacing it (or ignoring it outright) would be the first thing about half of the staffers out there did.
-
RE: UX: It's time for The Talk
@faraday said in UX: It's time for The Talk:
@Rook said in UX: It's time for The Talk:
Legacy code stacked on legacy code. Hack after hack. Until a complete rewrite happens, the codebases will have these inconsistencies. Then of course everyone will bitch that shit got moved/updated on them and their stuff doesn't work.
Oh I agree. That's why Ares is a complete rewrite. We can't go back and undo 20+ years worth of code drift, but we can learn from it. Platforms like Evennia and Ares provide an opportunity to do better the next time around. The question is: What does "better" look like, in way that won't have everyone up in arms because ZOMG it's different.
I really think something developers writing games nowadays should do where possible is make a standardized, generic UI library. A standardized method of headers, of footers, etc. This has the benefit of making a standardized method of how things look, as well as allowing easy tweaking (screen reader support, anyone?), and it has one other benefit: you could easily take this standardized 'feed data into this API' method to generate web-based UIs too.
Because I do feel like one of the major benefits that systems like Ares and Evennia provide is the ability to have a web-based interface to things.
As an example, I've written a nice relatively-plug-and-play bboard system for Evennia. Plug it in, and you have a usual more-or-less Myrddin style bboard on game. BUT it also exposes a /boards node on the Evennia webserver, and if you hit that while logged in on the website, you get your bboards as a web forum. Lists all the boards (and how many unread posts are on each), click into one and you get a nice little list of the posts, with unread ones bolded. Click on a post, it marks it read, etc. Post a message there, it shows up on-game with the usual 'New post' type notification, etc.
I think this will be great, because a player will have the option of using the bboards as if they were a normal web-forum, and never having to worry about the @bb/post et al. And I think the more systems we have that way, the better it will be. Because people are used to websites, and web-forums, and so on.
There's a lot of potential for things like that; I want a job system that works like Asana or JIRA, where I can drag a task into a new bucket visually, and get a quick kanban-style breakdown of the current bins. I want a chargen and application system that can work entirely on the web. Etc.
-
RE: Spawns and How You Use Them
@RnMissionRun said in Spawns and How You Use Them:
@Sparks said in Spawns and How You Use Them:
@Rook nah, I use Windows, Linux, and OSX interchangeably. I wrote Atlantis because I happened to be stuck on a Mac almost exclusively for a while when my PC was broken, and sorely missed SimpleMU. When I was unable to convince Kath to port it, I started writing my own.
SimpleMU was written in Delphi and relied on some external libs for which the source was not available. Reimplementing it from scratch really was the only option.
I know, I know. I had the conversation with Kath. My argument at the time was that a from-scratch reimplementation that was cross-platform compatible would be better future-proofed. Ironic, really, since as Atlantis was the Mac sibling to SimpleMU, I didn't bother to write it cross-platform—there was already a Windows option!—and now people tell me they wish it was on Windows.
@RnMissionRun said in Spawns and How You Use Them:
Kudos for exceeding your design goals by such a wide margin
Thank you!
-
RE: Coming Soon: Arx, After the Reckoning
@Jaded said in Coming Soon: Arx, After the Reckoning:
@Sparks said in Coming Soon: Arx, After the Reckoning:
@Jaded said in Coming Soon: Arx, After the Reckoning:
@Sparks This is the first game I encountered ascii desces in a weapon or item. I find that...strange, actually. So I would not expect ascii art. Just...a good desc.
Well, there's also +shop, where you can walk into a crafter's shop, bring the materials—in the case of a sword, for instance, that's four ingots of whatever material—and provide the desc yourself, but get to use the crafter's dice.
Yes I keep being told that. But also I am horrible at desces. It also does not generate RP for the crafter which I think is one of the perks of searching for a smith or tailor or something.
I actually disagree; I have had some folks come in, RP about having a specific design they want, and then use +shop to do so. Now, usually they do this because they want to make something using all their AP to reduce the difficulty (which is not an option if I make it, code-wise), but we still get RP from such an exchange.
Now, I also get the desire to have an object show up you didn't desc, because it's a little like unwrapping a present; seeing how someone else interpreted your request is always fun. I know Magpie was utterly thrilled with Windward and Leeward, the two blades I made him, because he hadn't expected how they'd turn out.
-
RE: Coming Soon: Arx, After the Reckoning
@DeadEmpire said in Coming Soon: Arx, After the Reckoning:
I'm gonna be honest. I wish people would be happy with just some cool ASCII design. That is way easier for me than coming up with detailed descriptions for 7 separate pieces of the same armor set. Although I do charge a 1000 silver per item fee on custom items.
My friend keeps telling me I'm underselling myself >_>
Edit: To clarify I made the mistake of doing leatherwork, so those complete sets will take a lot out of me!
I honestly think that for armor, people should be okay with a 'set desc' used on all the pieces. Because daaaang.