Replies: 3 comments 3 replies
-
|
Thanks for the feedback! (This thread is referencing this OLC User Story design doc).
Yeah, the intent for the default WheelMUD setup - the tools we give "out of the box" - is that a high-level admin could have permissions to edit things directly, while entry-level builders could be given access only to editing Things that are within assigned "zones" (AKA "areas" to some MUDs). A "zone" Thing would be the actual "Parent" of all things in that zone, with a behavior that would help protect against bad things from happening (such as denying any Player move request into any place within that zone - I'd like it to be safe by default to have builders working on the same game instance instead of requiring a separate "builder port" if possible). The builder could mark the zone as ready for review with a command like "zone submit". An admin or builder with sufficient permissions could see all pending submissions with another command like "zone review", including a summary of any outstanding validation warnings and such. So the zone couldn't be attached to the rest of the player-inhabited part of the world until it was admin-approved. An editorial mode would be neat for zone reviews - showing you one unreviewed Thing at a time, that you could mark reviewed with a single key and repeat that process until all Things are marked approved. Or another key to enter direct editing to revise simple typos or grammar. Or another key to leave a note on the pending Thing. Basically like a GitHub code review comment attached to that Thing ID. Imagine attaching a note to a mob "It's weird that this goblin is stronger than our dragons and that doesn't fit our theme of progression; can we find another mob type to use here?" The builder could list those unresolved notes, address them, respond, and resubmit. That'd give us a nice healthy feedback loop for zones to get iterated until ready for release. Zone review systems would probably make for another nice User Story document. :) (aside: I'd also like validation rules to be easily extensible - so you could write your own code to check details specific to the Game System, like raising a warning if a mob feels "imbalanced" against expectations for their level.)
Yeah, in the past we had at least two separate small efforts that I recall to have "offline world builder" tools built (for native Windows and a web interface in JavaScript IIRC) where the goal was to either be able to connect directly to our same DB directly, or provide import/export techniques - but the main ideas were to give the builder a GUI for world-building. Neither of these efforts got very far and wouldn't be compatible with today's Document DB approach if they had anyway. Another thought would be scripts that take the output format of existing offline world builders meant for other MUD types and somehow import it to WheelMUD. In short, I agree. It's a topic we'll need to revisit later in the roadmap though (currently marked at v1.1+), after we get much more experience working with the Document DB and get a better idea what kind of options would be feasible. |
Beta Was this translation helpful? Give feedback.
-
|
It would be interesting to theorycraft around the idea of using GitHub itself as a core part of the content development pipeline. For example, want to alter a room? Fork the content repo and submit a PR to the appropriate directory (zone) and file (room.json). |
Beta Was this translation helpful? Give feedback.
-
I was world building in the early/mid 2000s before GitHub was a thing. It never occurred to me it would be a good model for the developmental process, but by golly I agree. Something I did not clearly convey: world building with xml was certainly a pain in the ass, but once I did have those 50+ room files for a region in tabs, I could easily cycle through to check for continuity, fine tune, or restructure when necessary as every detail was at a relatively quick glance. Who knows if others would find it as useful as I did. Just my two cents, really. |
Beta Was this translation helpful? Give feedback.
-
|
I think integrating GitHub into a world-building process for a MUD on WheelMUD would involve an alternative to RavenDB for storage. The framework is built to be extensible and configurable in this manner though. For example, one could build a class on |
Beta Was this translation helpful? Give feedback.
-
|
Seems like the best place to put some OLC threads from the Archives, for further clarification and context. :) This thread contains restored content from prior forums; see #134 for details. [July 2010]
Sure, sort of. Say you have an OnOffSwitchBehavior attached to the interior of a tunnel that "fills quickly with water" when the switch is thrown. Normally a room doesn't just suddenly gain "underwater" qualities on the fly but in this case you want that to happen, so your OnOffSwitchBehavior applies the UnderwaterBehavior to the room. (At this point we definitely also want properties of type SensoryMessage on the OnOffSwitchBehavior like "OnCreatesMessage" and "OffCreatesMessage" - and the builder would apply an appropriate sensory message for the act of being suddenly surrounded in water or water draining away.)
No, it is totally dynamic based on the properties of each behavior. Most behaviors/effects will not have a reason to house other behaviors/effects, but will instead contain properties of only fairly basic types (int/string/SensoryMessage/etc.)
Per this user story, it could be simply 'list behaviors' or 'list effects'. Depending on your current telnet client and MUD settings, this may automatically cause paging pauses when there are a lot of things to list.
I think having smart features with the list commands would be sufficient; IE there could be ways to sort the results by the most popularly referenced behaviors and such first, which a builder could then be confident are well tested and likely to be complete, standardized, etc.
Maybe. I was currently thinking the ID would always match the DB-assigned ID. I could see there being MUD administrative commands for allocating a 'block' of Thing IDs to a given builder/zone (by persisting a block of blank Things simultaneously with the appropriate builder permissions attached, or whatnot). But I think instances of behaviors and such are probably best left dynamic, since you can't/shouldn't share the behavior instance itself. If you're building two Swords, they each get their own individual WeaponBehavior instances, even if both their WeaponBehaviors are going to have similar properties, etc. update 2021: These days I think we're more likely to see imposing "total things" or "total complexity" limits on the area being built now, that could be quickly be changed by admins (generally after looking at what's being built so far) - rather than needing "ID blocks" as were more familiar to certain old MUD frameworks of the past.
Yes that's what I was intending to demonstrate. Explicit wildcard system would be a good idea too although in lieu of any wildcards or whatnot being supplied I think a partial text match is probably ideal as the default. Thanks for the feedback! [Apr 2010]
Yeah, we've been moving "lots of specifically coded item types" into the direction you're talking about (as seen in the Interfaces and Behaviors discussion). For example, we no longer have a "Weapon.cs" - if you want to make a thing behave as a weapon, you give it WeaponBehavior and define the parameters. If you want to make it edible, you'd give it like an EdibleBehavior. Want a fun one-off case where you can wield your stale bread like a bat and use it to hit things for comically low damage? No longer have to write copy-pasta code, you just attach both an EditableBehavior and a WeaponBehavior to your Thing, and away you go. CreatePortal.cs is an interim test command that demonstrates creating a Thing and attaching a Behavior to it that has interesting capabilities, on the fly.
I think a game that wants to go this direction, would start building related Behaviors into their prefab templates to force their builders to define these things. One game might want all weapons to consider whether they are burnable/meltable while another team may feel that's not a direction they want for their game. Hopefully even if a game starts bolting such systems on after Things were already designed, as long as things had a good "based on" chain marked up - they'd get notified what items need to be updated when they added such Behaviors to the base prefabs/templates... Assisting immensely with the process of upgrading all existing objects to the new expectations.
Lots of unique ideas there. Indeed I feel the core, compositional "Things have Behaviors" technical design supports such things as possible game systems. [July 2010]
Sure, chaining, or even some sort of tab indentation formatting, may be helpful. We could try to design or experiment with something there. I think, at least for MXP-supported clients, we could even go heavy on hyperlinking. So any time you see some ID referenced, you can click it to view that object and drill in naturally!
Haven't really designed any kind of non-dynamic ID capabilities yet - but it's a good idea to have such an option eventually. As long as it doesn't make the auto-ID system complicated. Maybe we could do something like allow "namespaces" for Things, and can assign a Builder access to use a given namespace. So a builder named Bob could be given the "bob" namespace, and then specify their Thing's ID to be "bob/1" but it would still be attached to the current Zone, etc. Our document storage system(s) should handle such IDs fine. We'll want to think on this again after OLC starts to get up and running.
Yeah word meanings and spellings are going to be an issue with any international game, MUD or otherwise.
No fuzzy logic yet - "light" is a substring of "lightning" so a simple case-insensitive "contains" search will turn up such a hit. Potentially we could build in tech to handle nearby search relevance and typos and such. Eventually. Not sure I'd want such complexities going in the core code base until the v1.1+ time frame, and hopefully it'll be something that can be "plugged in" to the core command targeting systems (not just OLC). So it could be considered by each admin for trade-offs in computing power and relevance and so on, as there are several algorithms one could choose from. [July 2012] In (the original version of) this user story I showed how to create a new object based on an existing object: $ new object from 123 It occurs to me that some builders may wish to provide other builders with preconstructed templates specifically designed for new objects to be based on. For a game expecting there to be a lot of "mounts" created, the experience might set up to be like this: $ new mount $ prop deep Basically I think we can support "prefabs" with some pretty simple mechanisms. A senior builder would be able to simply tag a Thing as a prefab, giving it a unique prefab name (like "mount" in the example). Storage-wise, our list of prefabs is just a pairing of UniqueName,ID. The OLC "list objects ..." command could also list matching prefabs and call them out (on top, maybe with a different color or heading). There could be a "list prefabs" command to filter to listing them specifically. The OLC "new" command would look for matching prefab names when it didn't otherwise recognize the first/only argument; if found it would use the linked ID to base the new object off of. (Note the latest OLC User Story hosted tackles much of this thinking.) |
Beta Was this translation helpful? Give feedback.
-
In-game World Building (OLC)This thread contains restored content from prior forums; see #134 for details. [Feb 2010] This thread is my original proposal for OLC design. While this covers some topics not covered elsewhere yet, note that the OLC User Story design doc is more accurate to our current vision for the parts that it does cover. OverviewThis details a design for an in-game world building system which reduces a lot of the typical overhead/friction that normally prevents players from getting started with world building. Builder CharactersA player named “Bob” could instead chose to login to the same server with character name “builder:Bob” (using their normal password). This will log in with a basic “builder-flagged character” that has the name of Bob. This character has no equipment, can not leave the builder zones, and logs into the basic “Builder Hub” room. They can still OOC chat and do tells and such as normal, but other than that should not be able to go interact with other players or bring players to the builder zone, etc. The builder flag gives them access to a Builder chat channel. They can immediately create a new zone, which is tied to their player ID. A builder can not enter any other builder’s zone unless they have been explicitly granted permission to do so by an owner of the zone. (Administrators of sufficient privileges will always have access to all zones.) A zone-owner can use a command to grant another builder access to their zone, or even to grant co-ownership of the zone as an all-inclusive means to allow collaboration between builders. By default, a builder is only allowed to be owner/co-owner of maybe a couple zones at a time. Each zone could have budgeted limits for allowed number of rooms, items, mobs, and such as well. Builder CommandsCommands can be used to list the area(s) you own, and to list the rooms you’ve created, mobs you’ve created, etc. ‘Goto’ is only allowed for rooms tied to a zone you have builder access to, or allowed if you have administrative privileges. Ideally, rather than having dozens of specialized commands like ‘set-room-title’ we should have a couple flexible commands which set various attributes of given objects. For instance ‘setroom title The Buttery’ would set the title while ‘setroom desc’ would place you in the multi-line editor mode for writing the room’s description. (This multi-line editor mode would be another reuse of the edit mode underlying the ‘note system’ as discussed elsewhere.) Validation CommandAn area verification command will help make the builders’ lives easier.
Tester CharactersSimilar to the builder characters, a player named “Bob” could chose to login with a character name “tester:Bob” to log in with a basic “tester-flagged character” that has the name of Bob. This logs in as a plain character in the core builder room, with similar movement restrictions that builders have. Tester characters have access to no area-altering commands, but they should be provided commands from the game-system-layer for quickly altering the test character’s level and class, setting skills, stats, equipment and such to reasonable expectations for a run-of-the-mill human character of that level and class. An area can be marked as "ready for testing" by the builder(s) of the area, thus allowing any tester character to enter the zone. The intent is to provide a means of testing complicated content before going live with it. For example, wildly guessing at appropriate stats and abilities for a special-MUD-wide-event encounter with an uber-dragon is one thing, but having a few testers pit against it to see what progress they can make before getting slaughtered is better empirical data to tweak from. Publishing ContentAn administrator with area-publishing privileges will first run the ‘verify’ command against the zone. Warnings should either be cleaned up by a builder or receive an exception by an administrator before the zone can become accepted into the official world. The overall zone info itself should be taggable with notes that are only visible to administrators (just as characters and such should be taggable with such notes). An administrator could tag the zone with their exception notes if all verification warnings have been reasoned to be acceptable. The administrator could then mark the zone as ‘testable’ to make it available for testing, or ‘published’ to make it available to players and strip the zone of all builder privileges so it can no longer be modified by a non-administrator. Some ‘glue’ would then need to be added to make the zone actually accessible to players. In many cases, this may be as simple as adding an exit to an existing production room which connects to the starting room of the newly-published zone, or adding a Portal that spawns somewhere in a production room that takes the players to the starting room, etc. Importing ContentOffline/desktop world editors, such as the Universe Manager Lite, can be used to create zones more efficiently than one can through the telnet protocol alone. These tools should be able to generate a single file that contains all needed zone information, which can then be sent to an administrator, who can then import the zone as a new zone in the game’s database. This imported zone will start out in the ‘being built’ state, preferably with the original builder’s character attached as the area-owner. The same in-game verification, testing, iteration, and publishing processes could then be used as the in-game process. If the builder wishes to iterate and provide a new version through their editor tool, the administrator could simply use an area-nuke command to delete the existing ‘being built’ zone and then import the new version. Challenges and ConcernsUsing a single server to host both the game play and world-building activities has several advantages over the traditional approach of hosting two servers with one for play, and one for world building:
However there are some notable disadvantages that need to be considered:
Ed. Update: More mitigations I'm thinking of now would be:
Couple main reasons this is beneficial.
"Necessary" is not the term for such a feature. There are 3 building paradigms listed here. While it's possible to support all 3, that may be overkill, but it wouldn't necessarily be a bad thing. In any case, ya this is just a proposed feature, and wouldn't be scheduled to come into acceptance/action until around v0.8.
Not a need. The current paradigm that I've seen with building is not that it's an "end-game" but more that there is a second server allotted to safe building, or more often for new MUDs, they seek builders who haven't even played the game yet. There is simply too much friction though for the most valuable potential contributors, being those who play and care about your game world, before actually get involved. I'm not suggesting we require every MUD based on this code base to adopt open-builder policies. Admins are free to strip the OLC features, or enable them only on a secondary "builder port" instance anyway, as they see fit, then require administrative approval to any builder accounts, then and add any other friction that they see fit, in order to enact the existing paradigms. I wouldn't do it that way, but as an open source basis for future MUDs, administrators should have options readily available.
Simple text file will work for basic room descriptions, exit mapping, and so on - but falls apart very quickly when you start talking about spawner rules, interesting interactivity, and so on. The format would have to be highly dependent on the game system when you start to talk about mobs and such. There may be some compromise room too: Suppose we added support for some "common" file format that already exists for world building, to import as a "starter shell" of a real zone that the builder can then further iterate on.
Arguably a player can chose ruin their own experience in other ways (looking up this sort of information online, for example) regardless if we build this. Should an administrator remove from play any player who they suspect has read the open source code that their MUD is based on? Probably not, IMO. If they ruin the game experience for themselves, that's their own fault. Same with building, if reading up on the builder guides for proper stat allocations for a mob of a given level ruins some of the magic for them, and they still want to be a player, then they shouldn't do it. Further, a "remove from play" policy is completely unenforcable; nothing prevents them from having another character that they actually play.
Fair. Anyway, personally, I've seen successful MUDs allow active players to do world building too, and there tends to be strong incentive for them to do so: Sometimes in-game rewards given to the builders. Even if not, there is always the inherent popularity feel-good factor, getting mad props from other players for having added a new zone to their game. Balancing content creation rewards versus fairness can result in a healthy clip of content creation. On the other hand: Having a "promotion to builder" model as incentive/reward for being a model helper-type-player has its own advantages too. Hence why administrators should be enabled to make these kinds of choices about which builder paradigms they want to support, instead of only having one choice available, or worse being requried to build the systems themselves from scratch.
It will take some work to build, yes, but I do believe the benefits will be worth it. I think OLC in WheelMUD is well poised to be a vertical slice that can be easily stripped, upgraded, and so on, independently of the rest of the MUD. The builder commands would be organized just like other Command files and isolated as such. Even during Rapid Application Development, where items and rooms and such are constantly gaining new Behaviors, the commands themselves needn't change: They will be aware of and operate with our Behaviors system in a flexible and dynamic way. IE you'd make a Sword object, give it the Weapon behavior, which in and of itself has certain new Properties which are self-exposing to the builder system (via in-code Attributes if necessary), thus you'd be able to specify the damage (regardless of whether your game system uses "damage dice" or any other system) without having to change the core builder commands themselves. Then a builder tacks on the TriggersSpellBehavior (specified by name or whatnot, note that they can list applicable behaviors dynamically with another command) with properties specifying a fireball and percentage chance to proc, and now you've utilized advanced extension features that weren't availabe in the core WheelMUD code base, yet having never changed the OLC code. Can your standard desktop world-building tool make holy avenger swords which randomly shoot 30 die fireballs? Probably not, unless they are built with the same extensibility. By building our world-building tools in a way that is compatible with WheelMUD extensibility model, we certainly can make that sort of thing relatively painless and with no coding knowledge needed from the builder.
A tool like Universe Manager Lite is certainly going to be the best option for any who can go that route. Probably most users would be able to go that route. Some reasons one might not be able to though, might include: they don't run a supported OS, they can only contribute a little at a time, they want to collaborate on the area without having to pass files around, they aren't allowed/able to install programs where they want to build from (say on breaks at work or school or whatnot), etc. For others, I strongly believe we can do way better at user-friendly OLC than your nightmare example. When we get near v0.8, we'll want to look at our world building options again, see how Universe Manager Lite is coming along, and decide if adding an OLC is worthwhile to do as well.
Same with OLC or UML. I've described how content could need review by a higher level builder/admin before being integrated into the game via OLC, and UML doesn't need to operate against a production version of the DB either. Yes, it would be nice if we can have solid "migration" features for content to help support those who want their world building server to be another isolated MUD instance - One key is the instances will need to maintain parity for "tested" content to still be valid (tested against the same code) when the migration occurs. This sort of scenario will just take more thought/design to encourage admins to do well. :)
Interesting ideas. Also will need more thought and specific design.
Fair: They player loses some community presence, not all. (Unless they are using a strict single-window terminal like an old library system or super retro scenario or something on purpose, for such extreme edge cases they'd lose all immediate presence.) So usually, the player can recover some of their missing community by juggling windows/tabs. Often this will sacrifice the speed at which they can communicate, which lessens their community experience anyway from the "nearly face to face" feel of chatting/collaborating realtime in the same foreground window on the same server. (Ed. Update: 3rd and 4th points are going to the #135 thread.)
Thanks!
Spawning an instance of a given thing in-game should be a single command, executable by admins with sufficient priveleges to do so. The OLC designer style commands wouldn't really be needed for such cases, just the list commands to find the ID of the thing you want to spawn an instance of and the spawn command.
|
Beta Was this translation helpful? Give feedback.
-
I took a good look at what you presented; I think it looks fantastic for, as you say, a genre-agnostic building tool. I held the positions of world builder and class designer for a game that exclusively used XML files for every room, object, NPC, etc. It was cumbersome, and with so many moving parts it was easy to miss a field or deposit the file in the wrong directory. However, it did have some advantages in that it allowed me to take out batches of files I could organize and work on in a very tactile way. All to say, my view might be biased because how I built was a bit more technical than most. From the perspective of your OLC, this feels like it has a much easier barrier for entry and would allow developers to jump into the action with very little training. I would hope everything enters a QC directory so senior staff or admin could proofread and give the green light, but that's just a little side note. The only thing I would personally want is a way to import these created files into notepad++ or some other editing program if needed, but overall I think this is very user friendly and much less tedious compared to my experience.
These are my initial impressions and I do have more specific suggestions, but I am not sure if they would break the genre-agnostic nature of your project. Would you prefer I created another discussion thread?
Beta Was this translation helpful? Give feedback.
All reactions