Code: https://github.com/sunnywiz/dotnetmud2015/tree/blog20160106
Heading back home today, vacation is about over. For my little pet project, its been a nice little run. Here’s what I got done:
- Two different browsers
- Logging in as two different users
- Input_to() is implemented to get the user’s name.
- I have a standard room object to house the players
- the players each have their own mud-object
- I’m currently hardcoding the verb/action stuff, only does look()
- Using Signal/R as the transport between client (browser) and server
Server side tour:
Mudhub
This is the Signal/R Hub. It currently only has two methods / routines / channels – SendOutput and ReceiveInput. It deals with new players connecting.
It tries to offload everything it can to Driver.
Driver
Driver is what used to be the driver (efun) level stuff in the old LPC muds. Its where these kinds of things live:
- What’s the list of players?
- send a message to a user
- find me an object matching a string X (eventually)
However, Driver does not pretend to know what kind of mud you want to write. So for that purpose, it relies on IGameSpecifics – which I only have one implementation of – to deal with things like “what object do players use” and “what to do with a new connection”.
IGameSpecifics / SampleGameSpecifics
As mentioned above, this is effectively “master.cs” from the LPC days. However, there’s not a lot of stuff in it about permissions, and stuff like that, as we’re not yet compiling C# code on the fly.
MudLib
These are all the things that would go into writing your own mud. I have a standard room and user object, and a single room (Lobby). The code for “look” is currently built into User, that will need to move out sometime.
Where to go
There are many places left to explore in this little codebase:
- Standard rooms don’t yet have directions going to other rooms. That’s probably the most important next thing.
- Putting in a verb structure so that players, rooms, and objects in a player’s inventory, all get a chance to put in their own verbs. (there’s many ways to optimize this, I’ll probably brute force it the first time)
- There definitely is NOT any on-the-fly compilation going on. Everything is precompiled.
- I don’t have a method in place to covert a reference like “/core/Lobby” to an actual in-game object. I have to make some design decisions there. Do objects claim URI’s, or do I use the URI to detect where the code is at, or .. ? This affects the next thing –
- There is no database backend or persistence. And there probably won’t be, because that’s not where I want to go, this is a sample.
- There are player disconnections to be handled as well, and reconnections.
- Once a verb structure is in place, there’s going to be ID() stuff where swords can say that they are the sword that needs to be picked up, for example.
Uh oh, time to go. Lunch with the family.
