How to do Globals
Perhaps you are trying to avoid global variables out of dogma. It is common to have a class with static methods (or a global instance when that is not possible) that can be interrogated about objects. I'll give you two examples:
You can do something similar. Have an object that holds the model of the game and that has query methods. These query methods will return some sort of iterator that hides the data structures actually used, in such way that they can change independently of client code.
"Design Patterns"
Perhaps you think that what I mention above is not not satisfactory. Certainly, there must be a way to do this without globals. And a way that makes sense (and is not passing a huge model object around)...
That would be a form of Dependency Injection. If a Command needs some objects to run, and injector
system must provide them.
That means that instead of having the command query the global state (as it would do if implemented as I said in the first part of this answer), it must publish a description of what it needs to run (perhaps as an interface) and then depending on that (perhaps as a template) what it needs will be injected into it as parameters when doing the call to run it.
To inject that information, it must come from somewhere... hmm... The whole injector
thing is overcomplicating things. Keep it simple.
OOP
Now, should you pass this huge model object around to everything? Not necesarily. You might have encountered the argument that the solution for globals is OOP.
This is how it ends up like: On program entry, you create an object, and call a method on it. Inside that method you do your program logic. And now, instead of global variables, that object has fields, and everbody reads those fields.
OOP, whoopty doo.
A real architecture
You isolate external systems.
Standard input? That is an external system. Have a class deal with them and give you meaningful data. I suppose it gives you Commands. Whatever it is, it should have value semantics. In fact, I would argue it should not give you objects. Yes, you will have a single object of that class, created on the entry point.
Next, you have to deal with the Commands. I understand the urge to make commands smart (the commands knows how to execute itself). However, not, that is not right...
This is a MUD. There is a network. The network is an external system. We need to deal with sending these Commands to the server. You need to have an Observer pattern, so that you can have a class that deals with networking, it takes Commands, and you subscribe it to the class that deals with the console.
See, if Commands weren't values, there would be a problem to send them over the network.
Alright, the server will also have a class that deals with the network, and it will output these Commands. Here is where you need a system that knows how to execute the Commands (Note: nothing wrong with a switch
based state machine to deal with Commands). This will be class that you instantiate passing the model object, and it also gets Commands. Observer pattern again. The class will update the model and generate Notifcations.
Of course, you need communication both ways. From server to client is different... since the client will - I am assuming here - have a limited view of the world, it does not have to get Notifcations of every executed command. Instead, there must be commands the client send that subscribe or unsubscribe from certain Notifcations. For example, entering a room subscribes the channel to the Notifcations from that room. You figure it out, it is your game.
Alrigh, so you got Notifications. And some clients are subscribed to some Notifications. You need another class that deals with figuring out what Notification goes to what client. And that has to talk to another class that sends reponses over the network. Finally on the client side, another one takes the Notifications from the network and renders (writes to standard output).
Why is that good? Because you can swap parts. Did you decide you will no longer have a console, but instead a GUI? You can do that. Did you decide that the network code will run on its own thread? You can do that. Did you decide that the game is persistent and you will be storing everthing to a database? You can do that.
I am, of course, ingoring handling user accounts et. al. So, you probably will not plug the system that takes commands from standard input right away, instead you will deal with connecting to the server and authenticating the user first... afterwards you instantiate that system (see, it makes sense to make it a class).
Bonus: You can deal with releasing resources in destructors. For example, the destructor of the network system will release the connection. I hear they call it RAII? Naming, whoopty doo.