MU Soapbox

    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Muxify
    • Mustard
    1. Home
    2. Sparks
    3. Posts
    • Profile
    • Following 10
    • Followers 15
    • Topics 10
    • Posts 976
    • Best 644
    • Controversial 0
    • Groups 4

    Posts made by Sparks

    • RE: Separating UX from Functionality (Design Patterns!)

      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.

      posted in Mildly Constructive
      Sparks
      Sparks
    • 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:

      @RnMissionRun

      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.

      posted in MU Code
      Sparks
      Sparks
    • 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!)

      posted in MU Questions & Requests
      Sparks
      Sparks
    • 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...

      posted in Mildly Constructive
      Sparks
      Sparks
    • 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... <_<

      posted in Mildly Constructive
      Sparks
      Sparks
    • 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?

      posted in Mildly Constructive
      Sparks
      Sparks
    • 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?)

      posted in MU Code
      Sparks
      Sparks
    • 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". 😉

      posted in MU Code
      Sparks
      Sparks
    • RE: Cupcake's Playlist

      @Tinuviel We've got a burn notice on you; you've been blacklisted. 😛

      posted in A Shout in the Dark
      Sparks
      Sparks
    • 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 the nick command.)

      posted in MU Code
      Sparks
      Sparks
    • 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 typed whisper <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 because whisper is wrong and whisp is right, but because after years of having MUSH accept whisp, I honestly cannot break that muscle memory.

      posted in MU Code
      Sparks
      Sparks
    • 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 it get <source> <property> and to read it in code get(<source>, <property>) and so on.

      For your command there, is property allowed to have spaces? Is target? 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 setting Aardvark to approved true on the character Captain, which may not work so well for your chargen approval code.

      So you go, well, I'll separate the property and target... let's do set <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 have set <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? or tell "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.

      posted in MU Code
      Sparks
      Sparks
    • RE: RL Anger

      @Ataru said in 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.

      posted in Tastes Less Game'y
      Sparks
      Sparks
    • 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.)

      posted in Tastes Less Game'y
      Sparks
      Sparks
    • 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.

      posted in MU Code
      Sparks
      Sparks
    • 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.

      posted in MU Code
      Sparks
      Sparks
    • RE: Mass Effect: Andromeda: The Thread

      Well hey. http://kotaku.com/the-story-behind-mass-effect-andromedas-troubled-five-1795886428

      posted in Tastes Less Game'y
      Sparks
      Sparks
    • 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!

      posted in Mildly Constructive
      Sparks
      Sparks
    • 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.

      posted in Mildly Constructive
      Sparks
      Sparks
    • 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.

      posted in Mildly Constructive
      Sparks
      Sparks
    • 1
    • 2
    • 39
    • 40
    • 41
    • 42
    • 43
    • 48
    • 49
    • 41 / 49