Prior Auxiliary Applications

[DavidRieman]

While sifting through the old forums archives #134, there were a number of small conversations about various auxiliary applications adjacent to the WheelMUD server itself. These are all useful ideas to keep in mind, and may be worth creating new Issues to track each one separately. Perhaps when we get closer to v1.0 though. If you want to discuss one of these ideas in particular, it may be worth searching if we already have such a thread, and if not, making a new thread. You can link it back here for discovery. If you have an idea for a new auxiliary application, feel free to link it to this thread as well.

Auxiliary Applications:

• There was an experimental effort to build Universe Manager Lite GUI for world creation, that had some progress and discussions. It was an offline world creation tool that would save directly to the relational DB.
  • Probably not relevant to the newer document-driven DB strategy? Could be a good v1.1+ feature to revisit later, perhaps from scratch. (A modern version would probably share code with OLC to operate on the same principles and libraries as the actual server, but saving data separately. Then export/import code for migrating/sharing data like completed areas.)
• There was an experimental effort to build WheelMUDWebEditor, which was also going to be an online GUI for world creation. The idea was to have a web front-end connected (non-Telnet) to the WheelMUD server to directly build against the server's world data.
  • Don't think any server-side changes ever made it to main branch, and I don't think it ever got very functional. Could also be a good v1.1+ feature to revisit later, probably from scratch as well. (A modern version would probably be an optional library that plugs into the server, for an authenticated GUI editing experience, but relying on the same OLC code as a builder being logged in through Telnet.)
• There was a Remote Administration Console that planned to provide some remote administrative capabilities.
  • Don't recall now if this was some small web page hosted by the server, or hooks that integrated with some other administrative system. Notes suggest this was "done" for v0.4, but it doesn't appear to have survived; Perhaps the tech it used was incompatible with a major refactoring (like the move to .NET Core)?
  • Not sure what capabilities were present/planned. Perhaps at minimum, if we were to resurrect a Remote Administration Console, at minimum: A non-Telnet way to trigger reboots and the like. So even if Telnet connections are failing, there is another alternative to recover? Which suggests having some means to reboot into "admin-only mode" could be helpful as well for troubleshooting.
• There was an experimental effort to mimic the Memetic AI toolkit for C#, to then consider usage in WheelMUD.
  • I don't think that got very functional either.
  • I don't think advanced AI will be likely to be included prior to v1.1, and likely something we wouldn't want to deep dive until around that time frame.

This thread will be locked, since replies are likely to span too many topics. As such, if you want to resurrect such a discussion, please make a new thread and you can create a link here by mentioning #135 in the text.

[DavidRieman]

This thread contains restored content from prior forums; see #134 for details.
(Temporary home; can move to new thread specifically on offline editors if we make on.)

[Aug 2010]

I was thinking about the OLC and in my experience in building MUDs, online creation works great. I can understand the appeal of an offline GUI though and so thought about a compromise. What if our offline editor also provided a telnet program which you configure to connect to your muds build port. Then you would be able to create areas offline if you want but you can also use the GUI to create the areas online on the build port in real time and see what they would look like. I think this offers a nice compromise and shouldn't be TOO much more coding for the offline editor. A simple telnet window is fairly easy anyways I think. This allows you to see a visual map and move to any room in that area by clicking on it.
exa. When I click on room 1234 it would automatically send the command on the build port goto 1234. When I click the create mob button it will do all of the OLC commands necessary but at the same time interface with the database so I can change the properties in a nice easy list view instead of the command line OLC.

I think there are strong scenarios where the offline creator is useful in ways that OLC/OLC-wrapper is not. Some reasons are stronger than others but here are some:

• Building for your own MUD before you go live should not necessarily require having the telnet server up and running at that moment.
• Building while offline or behind a complicated firewall system, etc.
• Building an area that you intend to share between multiple MUDs; IE build a DB or DB script which can be imported by multiple MUDs.
• Building for a MUD you don't know will survive, and if it doesn't, you want to port it to whatever MUD you end up moving to.

IMO a GUI 'OLC wrapper' program (ala WheelMUDWebEditor) could be interesting but it might be best served as it's own program altogether, or a concept to think about in the WheelMUD v1.1+ timeframe.

---

[July 2010] - re: An OLC thread:

First of all, I'm a bit confused by this. Do we really need an in-game editor? I thought the view for Universe Manager Lite is that it would eventually handle all objects. Personally, I would rather have something with a GUI for mud admin (and I think the acceptance rate overall would be higher to non-coders). Or even better, have both, but obviously the logic between them should be the same. If we had both, then I would just use the in-game editor to show off in front of players. Any standard building would be done through UML or a web tool. If we could use your behavior system and add IntelliSense to UML then that would be quite good.

What you've written out [for OLC] is basically like a mini programming language. Anyone that programs will likely love it and non-programmers may find it frustrating. I followed the logic fine though.

Fair points. I think there will be a variety of people in categories with opinions like

• I have nostalgia for building areas through Telnet.
• I'm already in Telnet, can't I just do it here?
• I'd be happy to use a web page if it's easy to use for building, but I can't install anything here.
• I am able and willing to install and use whatever tools will help me get this done as quickly and easily as possible.

Basically, "why not both?"... eventually. Until then (v1.1+) I think we'll want to focus on the one we know all our players could adopt (as they're already connecting Telnet successfully if they're players at all) even if it's not their favorite choice. But if someone really, really wants to spin up an adjacent effort for another Builder App / Experience... let's open a thread and work out logistics because I wouldn't want to be a hurdle to such a thing. :)

[DavidRieman]

This thread contains restored content from prior forums; see #134 for details.

[Mar 2010]

Each of these 3 approaches have their benefits and their drawbacks. Lets look at each, and why I believe that the "web" option is the least bang for the buck.

1. OnLine Creation (OLC): Relatively easy development effort (UI is unnecessary, no "security" issues, no dependencies/installer issues, etc). Stronger community presence. Strong, immediate builder support. Requires online connection.
2. Dedicated Windows app (Universe Manager Lite): Reasonable development effort (we know how to build Windows apps). No community presence. No immediate builder support. Does not require online connection.
3. Web-based builder: Moderate development effort (building web applications is harder than a Windows app, especially if designed to be OS/browser/platform-agnostic). No community presence. No immediate builder support. Requires online connection. Requires a MUD administrator to configure/secure/maintain IIS web services or similar tech / additional firewall config / etc.

A web-based approach incurs a ton of additional risks/considerations over the other options. If you're talking about directly modifying the game world's database, the security risks are huge; one can not trust the client to validate that it has permission to alter a particular room/item/etc, and it is not the role of the DB to do that, so it is the layer in-between that has to do this. Web security is non-trivial. OLC does not expose such risks simply due to the nature of its transmission. Nor does a dedicated Windows app, as they can merely pass a completed area to a person with the capability (and trust) to integrate it properly, etc.

I would argue also that any builder is likely to be logged in at the same time as they are doing development. An integrated solution would also allow communications between the Application and the MUD.

Fair, the builder can choose to be juggling multiple programs with some of these models. I'd like that to be a choice and not a necessity.

---

...I don't believe security on the web to be as dire as you make out. I'm no expert in it, but people do online banking, paypal, etc. on the web. You can have CAPTCHA, IP Approved Lists, scrolling password inputters, image passwords, etc. Again, tie this with the development server concept and it's less risky.

Any idea how many big bucks were spent on just those systems' security implementations? That equates to a lot of open-source resources we could be directing elsewhere. This can be an ongoing, stressful battle too. OLC and UML both have it beat here, since these sort of attack surfaces are not something we have to even think about.

Sure, the cost of being bitten by security issues are reduced by simply not working against the production DB, but you still are opening up the surface on whatever machine that's installed on. How many hobbyist MUDs are out there? How many do you think would bother to set up a second machine other than the MUD server to host such a thing? In addition, the cost of maintaining/integrating separate DBs may be annoying. A builder wouldn't get to see their stuff in action very quickly, even in a 'test' context. Add to that the fact that new players and such need to get their character information integrated to the builder web machine too, you're talking about two-way integrations of database changes, which is non-trivial. As an alternative your web interface may be divorced entirely from your character itself, but now you've compromised some of the community tie-in or opened up to social hacks - how is Bob's web account tied to the Bob player if not via the DB integrations? If they're NOT tied together, then how do we prevent some random person from claiming the Bob web account? Require the player to be online, petition a GM to go make a web account for them...? My head is spinning with the complexities, and we've only just started to scratch the surface.

People LOVE web applications. Many builders may be put off by having to download and install/run an application that did not come from a certified software developer (or regardless of that). You could also then build during your lunch break at work, on your iPhone on the train, etc. You can't beat the accessibility of a web application.

OLC has this largely taken care of already: As a MUD player they can probably already get into a MUD, and if they can, then they already have everything they need.
Basically, yes, a web-based tool could be sweet, but IMO it is the least bang for the buck when comparing against the other editors. UML is a lot of work, and a ton of it is GUI type stuff. Web-based builder would be building on top of crippled GUI controls (let's face it, ASP and such are not as easy to work with as Windows controls) on top of tons of other intertwined features/concerns. Shy of gaining more resources than we know what to do with, I don't think a web-based builder tool should be considered before v1.1+ on the roadmap. On the other hand, if someone comes along who really, really wants to do this and has the expertise in the right areas, I won't stop them.