dotnetmud: where to go next

As of https://github.com/sunnywiz/dotnetmud2015/tree/blog20160110, I have the following things working:

• User logs in and provides a name.
• User can move back and forth between two rooms (room directions are hooked up)
• User can ‘look’ to see what’s in the room.  They will see other users there if they are there.
• User can ‘say’ something in a room
• User can ‘who’ to see who all are logged in
• User can ‘shout’ to send a message to everybody regardless of which room they are in.

I am now at a crossroads.  There are many directions I can go.  I’m crossing things out as I decide that they are not the priority:

1. Develop the “mud” as a communication mud more:

• Continue with all the communication stuff –  tell, emote.  
• Add aliases for commands, like ‘e’ for east and ‘ for say and : for emote
• Fix the say and shout so that the original command line is available rather than string[] arg (ie, I’m loosing whitespace)
• add the Id() system so that objects can respond to nouns, so that ‘look <personname>’ works
• Add last activity timestamp to user so that can detect idle time and show that in the who list
• Show which room the user is in, in the who-list.

2.  Add in realms

• Users can.. hook up a pointer to a git url ?  to point at their realm code. 
• Mud sucks the code down, compiles it, loads/unloads appdomains, etc.
• Might have some hidden difficulties here around MarshalByRefObj type stuff.
• Maybe there’s an intermediate stopping point here – where I appdomain-unload-load the rooms that the users use as Lobby.

3. HTML/Pretty the mud

• Right now the text being displayed to the user is all mono-spaced, no HTML allowed.
• I could change that so that HTML was allowed.
• As you enter a room, a picture of the room shows up.  
• People get gravatar icons next to their names.
• Add fun emoticons and stuff.
• Who is shown in a table.

4. Clean up referencing

• Move “driver” stuff into its own assembly.  Gets a DriverObject.  This does ObjectID and TypeURI stuff, and knows about IInteractive, and talks to the Signal/R Hub, but that’s about it.
• Move “mudlib” stuff into its own assembly.  Gets its own MudLibObject which inherits from DriverObject.
• clean up who references who, who finds who.   Use the .config file more to provide the links going in the wrong direction.
• Move some stuff (like “inventory”, and “moveObject”) into the mudlib, rather than at the driver level.   These are text-based game things, and would not be (as) applicable for a Space-2D game.
• Wrestle more with “should I directly map hub commands to the mudlib”, or make all communication with the hub generic.  Latter is more painful, but would work with more gametypes without changing the driver.

4.5 Deploy as a website to Azure

• RIght now, it’s a console app.   Convert it to be a full website, which runs the hub in the background
• I don’t know how Azure’s “free hosting” will work with a signal/r hub which wants to stay instantiated.   May have to put this on a paid plan
• Luckily my work gives me an MSDN account now, and there’s free azure money there that’s use is or loose it.
• Maybe put some stuff in like a welcome page.
• Maybe do some integration with your identity as you log in coming from the MVC side rather than entirely in the mud.

5. Deal with Polling

• For this, I’ll change the client so that it has panels:
• One for “where you are”
• One for “what you see here”
• (future) One for your inventory
• And then an updates window where “stuff” happens.
• The poll cycle will be, once every X, if something has changed, refresh the where-you-are and what-you-see-here windows.
• Additionally, for each user, give them a “how long they have been idle” thing on their short description
• The poll should detect these changes and feed them down correctly.

If I get the above stuff done – definitely 4 and 5 – I think I’ll be in a place where I can start working on my 2D space game.

One day at a time, one session at a time.