PennMUSH objects can listen for ... commands? Utterances? Something, and then do something in response. Figure out how that could work here.

There is some attempt at this in the code, with sending messages to things, and other stuff, but it doesn't seem quite right.

Let someone login more than once, playing a different player in each session.

At the moment, players linger where they are after their actor leaves. Should they? Maybe they should go to some designated home instead, or some off-grid holding pen until they are in use.

Implement a PAGE command for sending a message to another player from afar.

Create a way for players to organize play sessions, special events, and other scheduled occurrences.

Nothing is automatically saving off the state of the multiverse as the game runs. That's necessary so that GOD doesn't need to keep popping in to do so.

Handle guest access. Where do they go? What can they do? How can they communicate with players?

Implement a command to kick an actor off the server.

SetAttrCommand can only read JSON files. When setting a script attribute, it's very annoying because JSON doesn't allow multiline strings. Enhance the command so that it can parse YAML, which allows multiline strings.

Basic command autocompletion was added in 07eedcb. Add completion for command arguments that represent players. This should work by looking through the players visible to the player issuing the command. That list should be generated by running a pseudo-command akin to LOOK, but just for getting that player list. So, this would be a command that is run in order to complete a different command.

There was a problem with SSH when "bracketed paste" was turned on in the client. Figure out what is going on there.

There are no rules for which channels a player may join or leave, but there should be, for things like wizard-only channels or channels restricted to distinct groups of players on a team or in a faction or what have you.

I like to use Control-C to stop the server, but then the API domain socket isn't deleted. When the server is started again, the API won't work.

When a new guest logs in, they should be joined to a guest chat channel (or something configurable) so that other players do not need to be located at the guest home in order to interact with them.

There are some chat commands that still need to be implemented. Among them:

• list the available chat channels
• list what channels you are joined to
• list the members of a channel (admin only?)

Implement a softcode system for mail between players.

All actor manipulation commands are restricted to GOD at the moment, but it makes sense for thaumaturges to be permitted to use some if them, if not all.

Implement a command to destroy (delete) things and universes, anything that the BUILD command can build. Think about when destruction should cascade vs. should be blocked; what to do with things that were contents of a destroyed thing; etc.

Implement an actor preference system, whose first goal is to let an actor decide not to receive ANSI color codes from the server.

Write help text for the actor and role command sets, and make sure the help command can provide them.

Let ordinary players (not guests) see who is logged in.

An argument could also be made for Links, but that would probably require a source description AND a destination description.

If RunCommand encounters SHUTDOWN as a command, it will dutifully request server shutdown. That's bad. Make it ignore it instead.

Protect the game runtime from softcoded command scripts using some sort of sandbox. Ideas:

• https://sourceforge.net/p/dw-sandbox/wiki/Home/ (long abandoned)
• https://tersesystems.com/blog/2015/12/29/sandbox-experiment/

Right now, Grounds uses the Java security manager to try to prevent softcode (scripted commands) from unlimited access to the universe. Unfortunately, there are plans to deprecate and remove the security manager completely from the JDK.

https://openjdk.java.net/jeps/411

The alternative is probably to adopt Java Modules. This means that Grounds will be a module, and only export pieces of itself that softcode, or anything else, may access. That's not too bad.

The harder part is using dependencies in a modular way. Many dependencies have already adopted modules, but notably Apache Mina (SSH) hasn't.

Make the IP address for each connected actor available to wizards. This is the basis for other potential controls, including IP bans.

If one actor is already playing as a player, and another actor who may only play as that same player logs in, then the second actor is assigned to the player as well. I'm not actually sure what should happen in this case.

Let a player mute another player. This may require adding sender information to messages that are passed around.