@Kestrel said in How does a Mu* become successful?:
[...] A friend of mine is currently working on an MU* project where he's looking to really amp up the 'explorer' factor in what I think is a rather novel way — rather than having a traditional grid designed by builders, he wants to create a self-creating, dynamic player-driven grid wherein anything you can imagine wanting would be automatically generated (and then be explorable) the moment you enter a command like, 'goto bar'. If no bar exists, the system would then simply create a bar with a randomised name/description, and other players would have a chance of finding it next time someone uses 'goto bar' as opposed to looking for that bar specifically by its new name/ID. And similarly this could be used for generating and linking generic backstory town-where-I-grew-up, where you may discover that you actually grew up in the same town as another player, allowing for the opportunity to coordinate.
The idea for this came from his hatred of traditional MU* grid-style walking around and the hassle involved in building. He also said he simply didn't want to build a MUD, but something new.
Hi, I'm that friend. I'm not here to do a sale's pitch, 'the game' is cloud of nothing as it stands - an idea, the most inflated currency on Earth. But I love design talk, so this conversation is right up my alley.
@acceleration said in How does a Mu* become successful?:
This sounds interesting. I'd like to hear more details. It sounds mostly like a convenience thing not too far from existing MUSH/MUX +travel systems that allow player builds. It would definitely offer flexibility, but I'm not all that sure it would appeal to explorer types.
I totally agree, and as Loth points out...
@Lotherio said in How does a Mu* become successful?:
[...] In the early 90s, lots of places enabled @quota on players and they were expected to contribute to the shared environment. Build a bar, make a ship, make cars that moved, make puppets that interacted with players and otherwise build the shared world together. At some point, people decided this created too much clutter or used up too much space, and the quota was slowly reduced until, like most places today, its either turned off or set to like 1 which is reserved for one private room, which must be @dug by staff.
All that 'flexibility' can become a nightmare. My goal with tweaking movement and travel was to reduce the legwork between getting to-and-from RP, without the world feeling small and lifeless.
So the system is, essentially, as @Kestrel puts it. It isn't fleshy, and what additions I've been contemplating aren't fundamental, but I'll put them down for the sake of discussion:
- Restrictions. The locations are generated from templates, of which each area has an allowance for X amount of templates. There are only three meaningful bars in any given district of a city, for example. If a bar stops being visited, it disappears, and a new one might take its place.
- Customization. It's important for RP scenes to have an impact on the world, and for players to fill their spaces with life. So these templates have 'holes' in them for both concrete changes (the name of a bar, its patron, the atmosphere) and transient changes (the tables are broken, the floor is covered in blood).
- Locations = Currency. The idea is that having been somewhere enables you to go back there, without trouble. And this information is transferable.
The final idea is that stories should be told between locations, and so every area has the equivalent of 'walking the streets' of a city. In a forest, you might be walking a path, or through the trees. These transient locations give you a sense of time as you move from one location to the other, and through background algorithms, allow you to encounter other players.
And that's it. That's my wheel that is slightly more round.
