[Home] [Downloads] [Search] [Help/forum]


Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUDs
. -> [Folder]  MUD Design Concepts
. . -> [Subject]  New MUD protocol design

New MUD protocol design

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page


Posted by Lakedoo23   (9 posts)  [Biography] bio
Date Wed 30 Jan 2013 06:30 PM (UTC)

Amended on Wed 30 Jan 2013 06:33 PM (UTC) by Lakedoo23

Message
So I started toying with creating my own mud server modeled after the mud Majormud. Yeah there is greatermud, but it has the same issue as with all mud recreates it uses the old telnet ansi, vt-100 protocols. So I decided I wanted to make the server and the client at the same time BUT the client can be created by anyone as well for custom interfaces.


I created a library file that is imported and shares the class data between the client and the server to allow for easy character information transfer.

Right now I can effectively serialize game data into a byte array that is transmitted to the client and then de-serialized back into the class structure from the server. To me this seems much simpler than encoding all the vt-100 and ansi protocol information since we have really moved away from that technology but still want to play those fun mud games:)

Here is a snippet of the code to show how simplistic it is / can be.

Right now I have the capability to chat with other uses and provide player data such as position, hitpoints, mana and such no real logic yet.

Server side code serializing the player data.


private void TransmitServerDataProc()
        {
            byte[] genericRead = new byte[1024];
            GameSharedData.SharedMemory.CommunicationType communication = new GameSharedData.SharedMemory.CommunicationType();
            try
            {
                while (true)
                {
                    if (PlayersConnected.Count > 0)
                    {
                        if (CommunicationManager.ChatLog.Count > 0)
                        {
                            communication = new GameSharedData.SharedMemory.CommunicationType();

                            communication = CommunicationManager.ChatLog.Dequeue();
                        }
                        foreach (KeyValuePair<int, PlayerConnectionType> players in PlayersConnected)
                        {
                            if (communication.Data != null)
                            {
                                PlayerManager.PlayerData[players.Key].PlayerChat = communication;
                            }
                            byte[] playerData = ServerUtilities.SerializeToStream(PlayerManager.PlayerData[players.Value.PlayerID]).ToArray();

                            // If the player has a command incoming lets read it.
                            if (players.Value.playerStream.DataAvailable)
                            {
                                int commandBytesRead = players.Value.playerStream.Read(genericRead, 0, genericRead.Length);
                                ReadCommand(genericRead, commandBytesRead);
                            }

                            try
                            {
                                players.Value.playerStream.Write(playerData, 0, playerData.Length);
                            }
                            catch { RemovePlayerOnline(players.Value); break; }

                            //Cleanup

                            PlayerManager.PlayerData[players.Key].PlayerChat = null;
                        }
                        communication = new GameSharedData.SharedMemory.CommunicationType();



                        Thread.Sleep(100);
                    }
                    else
                    {
                        Thread.Sleep(1000);
                    }
                }
            }
            catch { }


        }




On the client side the data is simply deserialized and displayed, no need for parsing or interpreting.



 GameSharedData.SharedMemory.GameDataType gameData = (GameSharedData.SharedMemory.GameDataType)DeserializeFromStream(ms);


      App.Current.Dispatcher.BeginInvoke(new Action(delegate
                           {
                               _inputGUI.txtPlayerName.Text = gameData.CurrentPlayer.PlayerFirstName;
                               _inputGUI.manaBar.Maximum = gameData.CurrentPlayer.MaximumManaPoints;
                               _inputGUI.manaBar.Value = gameData.CurrentPlayer.ManaPoints;
                               _inputGUI.healthBar.Maximum = gameData.CurrentPlayer.MaximumHitPoints;
                               _inputGUI.healthBar.Value = gameData.CurrentPlayer.HitPoints;
                               _inputGUI.experienceBar.Maximum = gameData.CurrentPlayer.ExperienceTilNextLevel;
                               _inputGUI.experienceBar.Value = gameData.CurrentPlayer.CurrentPlayerExperience;

                               try
                               {
                                   if (gameData.PlayerChat.Data != null)
                                   {
                                       if (gameData.PlayerChat != null && gameData.PlayerChat.Data.Length > 0)
                                       {
                                           _inputGUI.txtCurrentStatus.Text += (gameData.PlayerChat.PlayerName + " " + gameData.PlayerChat.PlayerChat.ToString() + " : " + gameData.PlayerChat.Data + "\r\n");
                                       }
                                   }
                               }
                               catch { }
                           }));





Now I realize this removes the use of telnet clients, so is this a taboo thing or kinda removes the feel of a mud?
[Go to top] top

Posted by Shaitan   (3 posts)  [Biography] bio
Date Reply #1 on Wed 30 Jan 2013 10:08 PM (UTC)
Message
I don't see moving away from telnet clients as being necessarily a bad thing, and you can definitely maintain the feel of a mud while accessing it in a different format.

I'm working on a mud engine over at apathydrive.com that is all web-based that definitely still feels like a mud. The instance I have running there is coincidentally even using Majormud data.
[Go to top] top

Posted by Nick Gammon   Australia  (22,973 posts)  [Biography] bio   Forum Administrator
Date Reply #2 on Wed 30 Jan 2013 10:14 PM (UTC)
Message
In principle that should be OK, of course you now have to write both a client and a server.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Lakedoo23   (9 posts)  [Biography] bio
Date Reply #3 on Thu 31 Jan 2013 02:09 AM (UTC)
Message
Shaitan, I checked out the mud at apathydrive, very cool any pointers for newbie mud server maker? This will be my first attempt at making something of this complexity or any chance at a peek of the source?

After looking at the this type of protocol it is really limited to C# and java realm but I am thinking if just make the data in a xml format and send it think REST and SOAP does that for more generic data transfer this is more flexible for other languages, I believe that world of warcraft does or use to do the data exchanges like this.
[Go to top] top

Posted by Nick Gammon   Australia  (22,973 posts)  [Biography] bio   Forum Administrator
Date Reply #4 on Thu 31 Jan 2013 05:41 AM (UTC)
Message
You could look at the source of Mangos if you want to see how WoW implements that sort of thing.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Lakedoo23   (9 posts)  [Biography] bio
Date Reply #5 on Thu 31 Jan 2013 02:07 PM (UTC)
Message
Here is a quick video of what I got done in about a day, little easier than I thought, but this is the easy stuff right now:)

http://www.youtube.com/watch?v=nAzPs290VBg
[Go to top] top

Posted by Nick Gammon   Australia  (22,973 posts)  [Biography] bio   Forum Administrator
Date Reply #6 on Fri 01 Feb 2013 06:13 AM (UTC)
Message
What you have looks pretty good, but I would be thinking about making the whole experience more like an MMO. For example, instead of "text" exits, have them as clickable items (eg. at the bottom, or on a minimap).

And have an inventory (eg. like WoW) where if you open it you can mouse-over items to see what they do, drag them around, right-click to equip them, and so on.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Lakedoo23   (9 posts)  [Biography] bio
Date Reply #7 on Fri 01 Feb 2013 04:00 PM (UTC)
Message
My thoughts exactly Nick, I wanted to get the infrastructure of the server and client working well, I want to make a mix of MUD experience with more MMO interface type design with alot of text for the main game display and then the client would support all the modern convinences in a game since I am getting player and general game data every 250 ms should make mapping, tracking monster health, party health and such alot easier on the client side.
[Go to top] top

Posted by Fiendish   USA  (2,514 posts)  [Biography] bio   Global Moderator
Date Reply #8 on Sun 03 Feb 2013 10:07 PM (UTC)

Amended on Sun 03 Feb 2013 10:08 PM (UTC) by Fiendish

Message
Quote:
250 ms

Any thoughts on speeding that up? Aardwolf cycles data to players at ~8 Hz, and I think it makes a noticable difference over 4Hz when doing things like running around.

https://github.com/fiendish/aardwolfclientpackage
[Go to top] top

Posted by Nick Gammon   Australia  (22,973 posts)  [Biography] bio   Forum Administrator
Date Reply #9 on Mon 04 Feb 2013 10:53 AM (UTC)

Amended on Mon 25 Nov 2013 11:37 PM (UTC) by Nick Gammon

Message
I did describe a system, quite some time back, where a lot of stuff was cached at the client end. For example, a room description. Rather than having to send room descriptions every time you enter the room (or LOOK) the client could see if the description was already there and pull it from the cache.

I have a reasonably lengthy demo video here:



That shows room descriptions (and mob descriptions) cached and stored under a "hash" which uniquely identifies them. The idea of the hash is that, if you ever change the room description (for whatever reason) the server will give it a different hash, and thus the client won't server up the older data.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Lakedoo23   (9 posts)  [Biography] bio
Date Reply #10 on Mon 04 Feb 2013 04:02 PM (UTC)
Message
I did up the rate to 10 hz, for the rooms, items, monsters, spells etc, for the most part I have the exact same methods that load that information on the client and server, the server simply passes a integer associated with the appropriate item, spell, room etc so there isnt a massive amount of information passed.

I like hearing these suggestions mean I am doing something right since alot of these have been implemented.

I do have a mud question, not sure if I should post in programming or just put here.

Still trying to wrap my head around fighting multiple players on one mob.

My thoughts right now would be to have a dicionary of monsters each of those monsters has a unique identifer, so when the user initiates a fight it would then look up the unique number in the dictionary I guess then potentially 1 or more users could do dmg to this one unique version of the monsters, havent coded up anything yet but sounds like it might work.
[Go to top] top

Posted by Nick Gammon   Australia  (22,973 posts)  [Biography] bio   Forum Administrator
Date Reply #11 on Mon 04 Feb 2013 07:57 PM (UTC)
Message
I agree. I think each mob needs a unique number (a GUID if you like) so that it is clear who is fighting what. Particularly if there are 5 kobolds in the room, you need to know which one everyone is attacking.

In addition you need another number which distinguishes one mob from another, by type (eg. kobold warrior) in case your quest is to kill 5 kobold warriors.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Lakedoo23   (9 posts)  [Biography] bio
Date Reply #12 on Tue 05 Feb 2013 04:50 AM (UTC)
Message
Thanks for the video link Nick, very cool stuff and definitely things to plan for, I love the little mapper window to the left as well, does it map the rooms as you move or does it just reveal the map as you move through like a fog of war type thing? I am curious how it handles levels on the map like when you move up or down I was thinking about adding a z dimension to my rooms per-say to make it a little easier when mapping.
[Go to top] top

Posted by Nick Gammon   Australia  (22,973 posts)  [Biography] bio   Forum Administrator
Date Reply #13 on Tue 05 Feb 2013 05:35 AM (UTC)
Message
It maps as you move using a cool algorithm that attempts to draw outwards from where you are, stopping if there would be an overlap.

It does handle up and down, however frequently they would cause an overlap.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


37,674 views.

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

[Home]


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at HostDash]