Like a limit for name and description lengths

That data can be valuable.
We can also create a separate log for each user, and record there their exact interaction with the game. Would be nice to detect UX issues.

Pros

• Allows for easy translation.
• Allows for easy copywriting improvements and revisions.

Cons

• Harder to read code. We may need to look at two different files to understand interactions.
• Slower to write code. A huge disadvantage in this early and volatile moment of development.

Now it only checks for substrings. That means that, in Spanish, a room with these exits...

• hacia el oeste (to the west)
• hacia el este (to the east)
  ...the function won't be able to decide between one of them if the user provides "este" as the input, when the user will be certain that he wants to go east.

A world may be created collaboratively, but a creator may want to be the only one able to create and edit things, or share that privilege with only another user.

Leaving all navigation at the exits list makes it easy to skip room description and give all attention to that list. We don't want that!

Various users may want to build their separate worlds in the same server. It would be nice to be able to protect them with passwords.

This is the error log

mud_1           | Traceback (most recent call last):
mud_1           |   File "./server.py", line 106, in <module>
mud_1           |     sessions[sender_client].process_message(message)
mud_1           |   File "./server.py", line 24, in process_message
mud_1           |     self.current_verb.process(message)
mud_1           |   File "/usr/src/app/verbs/go.py", line 17, in process
mud_1           |     elif [exit in room_exit for room_exit in self.session.user.room.exits.keys()].count(True) > 1:
mud_1           |   File "/usr/src/app/verbs/go.py", line 17, in <listcomp>
mud_1           |     elif [exit in room_exit for room_exit in self.session.user.room.exits.keys()].count(True) > 1:
mud_1           | TypeError: 'in <string>' requires string as left operand, not Quitter

A world may be designed as a escape room, with an initial state that may be modified durin gameplay. To return things to their initial state easily, it would be nice to be able to create a snapshot of a world that you can later deploy. Snaoshots could even be shared with other users.

Info to add:

• Project description
• Demo (gifs?)
• How to install in your server
• Roadmap and milestones
• How to contribute
• Architecture
• Contact info

Item and exits lists may "distract" the player and prevent him from reading the room's description and searching for items and exits that are not listed. Maybe we should keep those lists off the room description. Moreover, this way the user won't have to think around the list structures to write names that feel natural within them. Then we can add a verb to show the user those lists of obvious items and exits that he sees. The extra typing might encourage the player to read the room's desciption.

Probably it was latin-1. Traceback here:

mud_1           | Traceback (most recent call last):
mud_1           |   File "./server.py", line 106, in <module>
mud_1           |     sessions[sender_client].process_message(message)
mud_1           |   File "./server.py", line 24, in process_message
mud_1           |     self.current_verb.process(message)
mud_1           |   File "/usr/src/app/verbs/go.py", line 17, in process
mud_1           |     elif [exit in room_exit for room_exit in self.session.user.room.exits.keys()].count(True) > 1:
mud_1           |   File "/usr/src/app/verbs/go.py", line 17, in <listcomp>
mud_1           |     elif [exit in room_exit for room_exit in self.session.user.room.exits.keys()].count(True) > 1:
mud_1           | TypeError: 'in <string>' requires string as left operand, not Quitter
mud_1           | Traceback (most recent call last):
mud_1           |   File "./server.py", line 93, in <module>
mud_1           |     server.update()
mud_1           |   File "/usr/local/lib/python3.8/site-packages/telnetserver/telnetserver.py", line 123, in update
mud_1           |     self._check_for_messages()
mud_1           |   File "/usr/local/lib/python3.8/site-packages/telnetserver/telnetserver.py", line 288, in _check_for_messages
mud_1           |     data = cl.socket.recv(4096).decode(self.encoding)
mud_1           | UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe0 in position 5: invalid continuation byte

Let's catch them all! Posting them here will allow for later refactoring.

It would be nice to implement some data encapsulation. This way, when we make a change in an entity, we won't have to make changes all over the project.

Maybe exits should gain the privilege to be on is own, have descriptions, visibility, and even custom verbs to interact with them.

So that they can be looked at by default.

Right now the way to show items in a room is a bit too clunky. It would be nice to make it more immersive. Also, it would be good that some objects don't show up explicitly in the room, and require a careful read at the room description to find out.

Ideas:

• In-game tutorial before jumping right into the game, just to teach the basic navigation verbs.
• Written guide with building documentation AND tips and a "style guide" to give consistency to creations.

We should make it lean and perfect before diving into bigger features.

The interaction during the creation process could be like this:

Server: Enter verb name
Client: use
Server: Enter the 1ts action to perform when the verb is used
Client: send_to_room You used me! Now I'll transform!
Server: OK. Enter more actions or an empty line if you are done.
Client: create object_123
Server: OK. Enter more actions or an empty line if you are done.
Client: self_destroy
Server: OK. Enter more actions or an empty line if you are done.
Client: (empty line)
Server: Verb added to your object. Write "use your object" to unleash its power.

Using some pre-defined actions, users would be able to create complex behavior. Some examples of actions are:

• Create another object in the same/other room (if it exists).
• Destroy itself or another object if it exists.
• Send something to everyone / people in the same room /etc.
• Create an exit between two rooms

As said in #47
In this case, exits can polyform as items... should they have an inheritance relationship? They start to look pretty similar.

They have the following issues right now:

• You can't edit an object name or visibility.
• You can't delete an exit from a room.
• Exits are edited as part of the room, but they could be edited with a separate command.
• Maybe you would want to edit where an exit leads to, not only its name.

There could be duplicated user, exit, room and item names. How this duplicates will be managed?

Some ideas:

• They may be a special type of item, with a set of consistent verbs you can apply to them.
• They may be able to say random things at random times, by themselves.
• They may be talked to like you do in usual RPG games: a preset flow of phrases that end in a stale repeating phrase. You may even say different things to them, but that would be too complex to create in-game (or not, with states?)
• You may fight with them.

For example, the alias of a room.

User Story

"As a room creator, I want to create items so that I can make my rooms more detailed and interactive"

Tasks

• Define item's data model.
• Update existing data models to handle items.
• Update look verb to show items in room.
• Update look verb so that it can also yield items' descriptions.
• Implement verb for creating new items.
• Implement verb for modifying existing items.

For role-playing games, the game master would need to become invisible and have great control over every aspect of the world, for controlling npcs and events.

We have a new function, possible_meanings, that tells us what the user might be referring to when he enters an incomplete name for an item or exit. The function is used for items, we should use it also for exits.

So that a saved item can be spawned with a single command.

Right now an unhandled exception ends the server for good. It would be nice to catch and log it or to automatically restart the server.