Plamzi - how do you handle situations where creature or item names might be in a language with characters that other players cannot type? How do clients do reliable text processing in the presence of unicode strings? We actually had problems with both of these things before I started stomping out extended ascii at the socket layer.
Well, for Bedlam, I've never bothered with even extended ASCII. There was a time when the ancestor of Bedlam (AnotherWorld) was played predominantly by Scandinavians, but even they didn't bother with it and just made do, I guess.
For Havoc, UTF-8 is something I get more or less "for free" by using a modern server framework with modern browsers. I'm not about to turn down free stuff.
The problems in your example are brought on by the fact that in a traditional MUD people have to type to target most of their game actions. It doesn't have to be that way. A big part of what I'm doing with Havoc and the web app is to make targeting by typing obsolete (in favor of tagging text with unique id's and allowing clickable actions via MXP). Even in an all-text game, in 2014, if you ask your users a Yes or No question, asking them to actually type Yes or No is eminently user-hostile.
… I asked if it's in the pipeline and a dev on the Mudlet forums told me it would be a lot of work to make sure it's supported in the scripting environment properly. I have no doubt that's the case but I don't see why you can't limit it for a phase 1 release and enable rendering only first…
If that was within the last few months it could well have been me… :biggrin:
27 Nov, 2014, alteraeon wrote in the 23rd comment:
Ok, that makes sense. It's hostile to direct client processing, but the hope is to turn the system into a glyph/tagged system where direct client processing isn't required. I can see that working for what you want to do, and it's not necessarily a bad idea in general.