Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Entire forum
➜ MUDs
➜ MUD Design Concepts
➜ New MUD protocol design
Posting of new messages is disabled at present.
Refresh page
Posted by
| Lakedoo23
(9 posts) 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? | Top |
|
Posted by
| Shaitan
(3 posts) 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.
| Top |
|
Posted by
| Nick Gammon
Australia (23,122 posts) 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 | Top |
|
Posted by
| Lakedoo23
(9 posts) 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. | Top |
|
Posted by
| Nick Gammon
Australia (23,122 posts) 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 | Top |
|
Posted by
| Lakedoo23
(9 posts) 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
| Top |
|
Posted by
| Nick Gammon
Australia (23,122 posts) 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 | Top |
|
Posted by
| Lakedoo23
(9 posts) 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. | Top |
|
Posted by
| Fiendish
USA (2,533 posts) 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 | Top |
|
Posted by
| Nick Gammon
Australia (23,122 posts) 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 | Top |
|
Posted by
| Lakedoo23
(9 posts) 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. | Top |
|
Posted by
| Nick Gammon
Australia (23,122 posts) 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 | Top |
|
Posted by
| Lakedoo23
(9 posts) 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. | Top |
|
Posted by
| Nick Gammon
Australia (23,122 posts) 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 | 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.
42,364 views.
Posting of new messages is disabled at present.
Refresh page
top