- This is a screen capture of my two browsers logged in. Follow the arrows for when what happened, and you can see the messages delivered to the other player.
Implementation Details
There is now a structure by which items can state that they handle various verbs that the users could type in. I use a JIT lookup to figure out what verbs are available to a player – verbs may be sourced from things in their inventory, in themselves, in the room they are in, or from other objects in the room they are in.
I created some more plumbing so that rooms are now aware of other rooms and can get directions to go to those rooms.
As a result, I added a tell_room driver level thing to make communication easier. However, it needs to be updated to handle different messages, one for the person doing the action, and one for everybody else in the room.
Difficulties
The original mud was a single-threaded thing. So whenever a command was executing, this_player() was “who was the command running for”.
My version is multithreaded. I have to pass around a lot more information – hence the “user action execution context” uaec above. I had to know who the player was, what the verb was that was executing, etc. There were several instances where I was using “this.SendOutput()” and the result was that user “Sunny” got messages intended for user “Bunny”.
I keep running into this problem – that I have to pass around “who the current player is”. This will probably become a generic “execution context” like HttpContext is in web apps.
I also know that the verb system I have in place won’t work when we get monsters. We need the ability to have a monster override a user’s ability to go in a certain direction easily. The way this was done in the past was, the monster would override “east”. In my current setup, this would not work as the dictionary of verbs wouldn’t get refreshed. Then again, I’m leaving this whole verb things as a “Sample Mudlib” implementation, not part of the driver – all the driver does is get a command to the right user object and its done.
I also know that I need to create a MyStdObject that’s specific to the implemented mudlib.
Where Next
Probably the global player list – who – shout – say, emote, tell.
Possibly switch the client to be true HTML rather than monospaced font. Philosophical question if I should do that or not.
And then, the hard bit: Adding polling cycles.
If I can get polling cycles working here, then I’m ready for the space game version.
Code since the last blog post: https://github.com/sunnywiz/dotnetmud2015/compare/7da38a6f…2497ec8
