Tell me more ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.
up vote 3 down vote favorite

I am working on a MUD engine and I want to do it a little differently then all the MUD games I played. I find a "cycle" system very boring. One of the idea I had is to make every clients socket working in their own Thread. I am aware that it wont end with hundreds of player but I would like to know if there are problems creating "alot" of thread in a single process.

Or, what other strategy I could use if I want to make it (eg. combats) in "real-time".

I hope you guys understand the question.

Thank you.

share|improve this question

3 Answers

up vote 7 down vote accepted

MUD cycles are generally not there because the server has trouble processing everything within the available time or serving network requests fast enough. They are there because spamming commands as fast as possible should not be a valid tactic.

Simply have a cooldown / charge-up timer associated with each ability. Depending on your social design this might also include "move" and "speak", or not.

Generally, having more than one thread per core for network processing in a game is pointless. If you are packet-processing-bound, then a thread per core will be maxing out your system - more threads would just starve the others of CPU time they need. If you are not packet-processing-bound, a thread per core is small enough that it won't affect the rest of the system via too many context switches.

share|improve this answer
Exactly what this person said :) – speeder Oct 8 '10 at 0:38
2  
Damn enter thing... Anyway, I saw once a MUD without cycle, and it sucked, because some players would make some wierd macros on their client, and when you went to PvP with them, they would easily pummel you do death by sheer command flooding, even if they were weaker, they sometimes would hit you several times before you had the chance to even read what was going on. – speeder Oct 8 '10 at 0:40
Hmm I see the point there but adding different commands an inner lag (combat command 3s, movement lets say 2s, and socials 1s) I believe it would fix that problem. The other battles texts will constantly display. Some players will hit more / faster depending of their stats. Thats my thought of what I would like to do – Cybrix Oct 9 '10 at 14:16
that was the idea behind the whole thing. I just can't figure it out if it all runs in the same single thread. It looks like a big loop to me to see if any player have a command buffered and then execute it. But what about the regular attacks commands (similar to "white damage" in WoW)? – Cybrix Oct 9 '10 at 14:20
Run your game logic update at some fixed FPS, e.g. 30. Damage that occurs every 2 seconds occurs every 60 frames. It's just a normal game loop, but without the render() call. – Joe Wreschnig Oct 9 '10 at 15:22
up vote 2 down vote

You could allow combat commands as they come in and then add a time delay after commands based on how long they would take to execute.

Dragonrealms uses this method for combat as well as many other actions, it is called Roundtime there. Heavier weapons get a greater time and you can reduce it, but not eliminate it with strength and agility.

share|improve this answer
That is exactly my idea behind. But I thought I would drive it with multi-threaded clients. But now I hear its not a good suggestion suggestion :P – Cybrix Oct 9 '10 at 14:18
why use threads beyond what you may use for sockets/communication? – lathomas64 Oct 9 '10 at 16:11
up vote 0 down vote

Networking is serial in nature anyway (at least until you get into multi-Tbps fibre-optic lines). Having one thread for network I/O separate from game logic and maybe some autonomous agent threads makes sense. Everything else is overkill.

share|improve this answer
If you've got multicore machines I would recommend more than one network thread (up to one per core); while each socket is network-limited, reading the client requests and constructing the game-state / RPC-response packets to shove back into the sockets is almost perfectly parallelizable. – Joe Wreschnig Oct 7 '10 at 17:59

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.