Here's the screenshot:
http://img339.imageshack.us/img339/1793/mudmanuserinterface3ach.png
Some highlights:
Note the lack of prompt spam. Only the latest prompt is displayed, and it's right next to the input box. When you send a command, the prompt dims a little, then lights up again when you get an updated prompt (indicating the MUD is ready to receive your next command).
The latest room description always stays on screen, so you never have to scroll up or send a fresh LOOK command to review it. I think this helps maintain a sense of your surroundings.
The "compass" indicates which of the "standard" directions you're able to travel from the current room. The number pad can be used to send the common travel commands. I say "standard" here because some MUDs have exits like "house, shop, gate, castle", and those aren't well-communicated by any graphical compass.
I'm sending talk to a separate block as well. I've defined talk as any messages with both quotation marks and "say, yell, or shout".
The block at left shows lengthy text, like help content, shop lists, and lore. In Achaea, such text is usually followed by "type MORE to continue". These chunks of text are problematic because they like to gradually scroll off-screen as new text arrives. By sending them to a different block, I can keep them on screen for reading and still pay attention to any new text arriving without having to scroll constantly up and down.
Finally, having eliminated prompt spam and sent room descriptions, chat, and lengthy blocks of text to special areas of the screen, the main text area displays only the happenings going on around me - combat, arrivals, departures, and non-combat actions like inventory management and emotes.
Now I can neatly prioritize my thinking based on areas of the screen - I focus mainly on the output directly above my prompt, and look to other areas as the situation permits.
So what's left?
Some things need doing:
- Including some pre-configured custom interfaces to install with the app.
- Allowing for import/export of custom user interfaces like the pictured UI.
Others need fixing:
- Dialogs are functional, but look like crap (not pictured above).
- Dropping very old text to avoid running out of memory.
- Disabling logging for very short play sessions (cleans up the log list).
- Eliminate unnecessary whitespace in all output areas.
- Wrong moves in design mode can get the user stuck.
See how short that list is?! I'm excited. Finally, I have to test. I'm thinking maybe 10 hours of standard play in each of Achaea and Aardwolf will be good enough for an alpha release.
Please share any feedback you have!
Also one addendum - recent questions not addressed in the screenshot... Yes, you can define scripts, macros, and triggers. Yes, you can change the background image and the color scheme. Yes, you can rearrange the user interface without knowing anything about regular expressions (but you need them to create NEW blocks to receive text).
I think this looks very nice. But I'm curious what you're using to define scripts, and when/if you'll add out-of-band support. Regexp support is fine but in the face of new protocols (including those that IRE uses) it seems like a step backwards.
ReplyDeleteThanks for the compliment, George!
ReplyDeleteI'm not trying to solve all problems - I have to pick and choose. I personally don't think out of band is worth the effort. I know that some MUDs use it heavily, and I'll just have to live with not well-supporting those MUDs.
Scripts are simple, no branching logic - just parameters. Example:
get @1 from my backpack
drink from @1
put @1 in my backpack
Where @1 is the first parameter.
Optionally, triggers may be defined as regular expressions. When they are, the capture groups are passed as parameters. So you can say "when somebody attacks me, attack that somebody back", but you can't say "do the above, unless the attacker is scary, based on the level difference".
The protocol decision is about implementation effort versus pay-off (I don't want to code and test special OOB protocols, when each such protocol only adds one or two MUDs to my support list).
On automation, I'm not a big fan. Those who enjoy automation for the challenge of automating have other client options, and are likely capable of building custom clients for themselves. For those who feel automation is necessary because the MUDs they play aren't designed well, they should give that feedback to the admins, find another MUD to play, or choose another client.
While I certainly don't question your right to decide the direction of your own client, I think you're underestimating the growing significance of OOB protocols; it's certainly not just "one or two MUDs".
ReplyDeleteAardwolf and Achaea (the two muds you're thinking of spending 20 hours testing your client on) have a combined average of 564 simultaneous players (according to MudStats), and they both support ATCP/GMCP - and they both promote clients that support their protocols.
Add on Aetolia, Lusternia, Imperian, Avalon and Elephant and you're up to an average of 805 simultaneous players.
Then there are the 17 muds that currently support MSDP, 15 of which also support ATCP. Realms of Despair should be joining that number in the next few days, and it's one of the larger muds with an average of 154 simultaneous players.
So that's 23 muds that support ATCP, with a combined average of well over a thousand simultaneous users. Or to put it another way, over 10% of all mudders play a mud that supports ATCP.
Kavir, I think you may have misunderstood my perspective (or more likely, I wasn't clear in explaining it). I agree that OOB protocols in general are a huge deal in online text gaming. However, individual protocols each impact a relatively small portion of the population - in your example, ATCP = 10 percent. So I could spend weeks or months developing and testing support for ATCP in my client, and all that work would only benefit 10% of my potential user base. When I deliver features like color scheming or logging or auto-connecting, those features benefit ALL users. Granted there are many features which can only be enabled via OOB protocols, I don't think that implementing any one is worth the effort, considering that my goal is to bring new players to the genre rather than enable power users.
ReplyDeleteIf somebody new to text gaming tries my client and then downloads a more powerful or server-customized client, that's a GOOD thing in my view, because that person has become a serious text-gamer, recognizing the value in text gaming enough to spend time researching and learning another client. That's a win, even though they're no longer using my app.