It is my pleasure to introduce a new project I have been working on for the past several days. The Uboachan Dream World MUD is a text-based, in-browser multiplayer game where the users create the content with in-game commands. The focus is exploration, but I plan to add some more dynamic kinds of features later on.
You can play the MUD in your browser at http://dream.uboachan.net/
or follow the link on the sidebar.
This thread is for comments and questions, and eventually I will collect my answers from this thread into a FAQ for new users. Some user guides will be very helpful in navigating the command system, so ask me whatever and I'll try to write some good posts.
I would also like feedback on how easy/difficult/pretty various aspects of the MUD are to use.
Would it be possible to add some separation (e.g. a line of = characters) whenever a command is put in, to make it easier to look at? E.g.
>go rusted door
Kingdok left the room through Rusted Door
Kingdok entered the room
Owned by: Cotton
You are in a harbor on the outskirts of a big city. It's night time, and some insects fly around the pale fluorescent lights. The sea is calm, and the sound of water soothes you. You can see the citylights flickering in the distance, below a full moon. A gentle breeze blows. Although it's cold, you feel comfortable. There isn't a single soul in sight. You feel at peace.
Exits: Rusted Door, Brick Path, Docks
I've been considering something like that, and hopefully it won't be too difficult.
Edit: Done. I'm having trouble figuring out how to prevent all messages from including an empty line though.
This is definitely much better, thanks. The only problem is that it also does it with automatic commands like "look" on entering a room.
can i play as corey
This is nice yes.
Added private messages. Unlike the "say" command, they work with usernames rather than nicknames due to technical reasons. The command is "message <username> <message>". To find out a user's username, either look at them, or if they aren't in the same room, use "realname <nickname>" to look up their username.
Would it be too difficult to implement a soft lock of sorts so that certain exits cannot be touched by anybody (just the owner) but other people still can make doors and the like?
Maybe instead of locking rooms, you lock exits based on room owner?
I'm trying to make a room, but whenever I put in a command like make exit, it just repeats the function of the command every time. What's the step by step process when making a room?
make room <ROOM NAME>
make exit <ID where you want to point> <EXIT NAME>.
Example:>make room Spanish Forum
(the game will tell you the ID of this map, let's assume it's 24)>make exit 24 Bloody Door
This will create a room with ID 24, and then will create a door that will point to map 24 (Spanish Forum). The exit will be called "Bloody Door".
Is there a pinch function to go back to the nexus? It makes sense for people to make rooms with no exit back to where they came from considering how that was in YN, so a pinch function would really help.
Sure, per-exit ownership and permissions is a good idea. I'll put it on the TODO list.>>885
You can use "teleport 0" to go to the nexus, or use it with the ID of any room that you own to go there instantly. I will consider a convenience function just for going to the first room.
Not sure how to place item you've made into a room.
Also I don't get how the decorate exit function works.
drop <ITEM>>make item apple>drop apple
decorate <EXIT ID> <ACTION>>decorate 0 falls through a hole.>go Door><NAME> leaves the room through Door. ID: 0><NAME> falls through a hole.
You can check the exit id by looking at it.>look <EXIT>
EX in nexus:>look rusted door>Rusted Door (5) -> 11
The number inside the parenthesis is the exit ID. Using the previous example:>decorate exit 5 falls through a hole.><NAME> leaves the room through Rusted Door.><NAME> falls through a hole.
Right now there's no way to lock exits with a password or anything like that, right?
I just had an idea along those lines. We could have Keys, which like items can be named, described, and placed, but any number of people can pick up the same key, it goes in a section of their inventory permanently, and some exits can only be gone through if you are holding a certain key. It also has a custom action when opening the exit.
I'll have to add this along with exit ownership. You would make the exit, make the key, and only the owner can drop a key they are holding. Then you lock the exit with the key, use the "seal" command I've been planning to prevent anyone else from making exits leading to the target room, and place the key somewhere in the world (or more than one place) for people to pick up.
My earlier idea I might modify instead is that you have an "affect" command that makes an item into an effect, which means it can be placed by the owner and picked up by any number of people. Then all items, including effects, can have custom actions and abilities, and opening a locked exit would be one of the abilities they could have. This would be more complicated and extensive.
In that case, either regular items shouldn't be allowed to be named key, or something else should set them apart from regular items.
I updated the post. They would be distinguished somehow, at least in your inventory.
Another thing, "npc", interaction seems limited to creating a sort of room and exit in its place. A seperation between room and npc would be nice.
I haven't added NPCs yet. If you're talking about the skeleton, it's someone's clever use of decorate exit to create the appearance of an NPC.
I just added exit ownership. Unfortunately, since there is no data on who made which exit, ownership of each exit defaulted to the owners of the room it is in. Post here with your username, room id, and exit id of any exit you made that you need access to.
It should be noted that the owner of a room automatically has privileges for all exits in that room.
Commands added in this update were seal room, unseal room, grant exit, and revoke exit.
Just thought i'd mention this. If somebody makes a labyrinth to a key, anybody could easily fuck it up by just making a door to the right room. Maybe the lock room function is for this, but i'm not sure.
They could also make the labyrinth even more confusing by just adding a bunch of exits.
The seal room command prevents any exits from being made to that room, except by the room's owner. The lock room command prevents people from making more exits in that room.
I've just added the lock exit and unlock exit commands, in preparation for keys. A locked exit can only be used by the exit's owner, though the owner of the room can unlock the exit if they want.
I have also altered the database and the code so that all usernames are lowercase. Everything involving usernames should be case insensitive. Let me know if anything appears to go wrong in that regard.
I tried to switch the whole thing over to https but there was a complication, so it will remain an insecure page for now.
Right now I could just go into the nexus or any room and clusterfuck it with exits. Sealing a room should also make creating exits in it not possible for anyone but the owner.
That's what locking a room does. Sealing for inbound exits, locking for outbound exits. The synonyms might be a little confusing but I've tried to focus on making short, memorable commands with a minimum of arguments.
Perhaps "seal inbound" and "seal outbound" would be better, since now locking rooms and locking exits are different kinds of procedures, which is confusing.
>>872>I would also like feedback on how easy/difficult/pretty various aspects of the MUD are to use.
It wasn't obvious that the 'submit query' box was the input box for the MUD, rather than some kind of help form, because it is a separate element. I was expecting something to load in the blank space before I tried typing and saw how it worked. If convenient, it would be good to have your history of queries navigable by pressing the up and down arrows.
Could the list of commands in the help message be reorganised please so that rather than being glommed together and sorted alphabetically, they're grouped by e.g. normal gameplay exploration actions, room/exit-making actions, wizard-only actions etc. and within each, sorted alphabetically?
The list rooms command doesn't show anything except for a line of equals signs. Is it not yet implemented? Same with list items.
I'll be coming back, this is cool.
The caves that you access with the blue door in the nexus use the current limitations to fake interactions between items and exits in a cool way. If you 'take flashlight' (which really means to go through the exit of the same name) you enter a room without a blue door and the flavour text says that the door vanishes. You can 'return flashlight' in the same way to get the blue door back. And while "carrying" the "flashlight", you can go explore into new regions.
>>904>It wasn't obvious that the 'submit query' box was the input box for the MUD
I'll change that to "Send" for now. I might also have your cursor go to that box automatically on page load.
>it would be good to have your history of queries navigable by pressing the up and down arrows.
Yes, it would. I'll try to figure that out. It might be deceptively complicated though.
>Could the list of commands in the help message be reorganised please
Grouping commands by category is a good idea. I was starting to think the list was too big. I'll need to revamp the help system a little.
>The list rooms command doesn't show anything except for a line of equals signs. Is it not yet implemented? Same with list items.
In order to not give away surprises, unless you are an admin, these commands only list rooms and items that you own. I should add a message that appears if there aren't any entries.
> The caves that you access with the blue door in the nexus use the current limitations to fake interactions between items and exits in a cool way.
I'll take it into consideration when I do the items update at some point.
Added the "chat" command, which lets you send a message to the general chat. General chat messages are received by everyone who has chat enabled, which it is by default.
To disable general chat for a more solitary experience: "disable chat"
You can also block annoying users, so you won't receive chat messages or private messages from them. Currently if they are in the same room as you though, you will still hear what they say. The command is "ignore user <username>", with the reverse being "unignore user <username>".
Also various small tweaks and bugfixes.
Next I think I will work on cleaning up the help system, since there are an awful lot of commands now. I'll divide it into categories.
Ok, help has categories now. Some commands are in multiple categories.
Unless there are other suggestions, the next major update will probably be either keys or mail.
The "describe" commands now let you insert a paragraph break. Use a double backslash wherever you want to split the paragraph.
Added a telnet service at dream.uboachan.net:37378. Currently, users accessing via different backends cannot see or interact with each other, though they can edit the same world.
Edit: Telnet and websocket users can now interact.
The "look" command now shows item and exit IDs next to their names, and the "go", "get", and "drop" commands now support IDs in addition to item/exit names. This should make interacting with items and exits with long names less obnoxious.
There are also single-character aliases for some common commands:
"hello -> say hello
#hello -> chat hello
.user hello -> message user hello
:dances -> action dances
>big door -> go big door
Currently planned commands for future versions:
> (un)pair key <exit> <item>
Pairs an item to a locked exit as a key, so that a user holding that item can pass through the exit.
> Edit: Finished on 10/10/2018.
> (un)hide key <exit>
Prevents looking at a locked exit from revealing the name and ID of its key.
> Edit: Finished on 10/10/2018.
> (un)decorate lock <exit> <action>
Sets a custom action for when a user fails to pass through a locked exit.
> Edit: Finished on 10/08/2018.
> (un)decorate item <item> <action>
Sets a custom action for when a user uses an item or passes through a door using a key.
> Edit: Finished on 10/13/2018.
> (un)duplify item <item>
A duplified item doesn't disappear from the room it is in when someone picks it up. Any number of people can pick up the item. When anyone except the owner drops a copy of the item, it disappears. The owner can place the item in multiple rooms. When an item is unduplified, it disappears from everywhere except the owner's inventory.
> use item <item>
Currently, just shows the item's custom action if any.
> Edit: Finished on 10/13/2018.
Other planned features:
> Mail system
mail <username> <message>
read mail <id>
delete mail <id>
delete mail from <username>
> A bot-based NPC system, with an in-game manager bot you can message with commands to insert new NPCs into the game and manage them. NPCs are all bots spawned by the manager.
I have begun making the command help messages more useful. Lists of commands given by calling help on a category are now outputted in nice columns. I fixed a related bug which broke word wrapping in the text box for the past few days. I have also elaborated roughly half of the command help messages to be more explanatory and include usage examples. I will continue elaborating more help messages in my spare time until they are all done.
All of the planned features in the previous post are now finished except for (un)duplify item, the mail system, and the npc system. You can also use the %player% marker to put the player's name somewhere other than the front of the line with the action and decorate commands; see their help messages for more info.