Hello, a few friends and myself are going to make our own graphical mud. Currently, I am the only programmer, and am looking at where to start. I plan on using DirectX for the game, as it will be a simple, 2D, windowed game with chat interface. As for the networking code, I don''t know where to start. I''m thinking about using DirectPlay since it is included with DirectX. Well, however I plan to implement this. Should it be TCP/IP or UDP? It will be real time, but doesn''t have to be super fast. One machine will be the server (mine on a cable modem, for now) and all the clients will connect to mine. The world will be divided up into smaller maps, and each time someone moves their character or does some action, it will send their current map, location on map, what they''re doing, etc.. to the server. then the server will send out that information to everyone who would see this action happen. Does this sound like a good plan, on ideas? Criticism, anything? Thanks -Tim Elliott

well, ill begin this by saying i have no netwroking expierience, so feel free to correct me
your system sounds like it will require alot of band width
a map is quite a large thing, and to send it practically every frame is alot of time
since you said the map was in regions, you might want to send almost all of the information needed for a region to each user in that region, and send updates everytime someone switches regions, and more often if multiple users are in the same region
just some stray thoughts

I must have led you to think something different, the client portion of the game will already have the maps on their computer. It will be just a matter of telling it where it should place another player''s sprite on the map that they currently see. Actually, shouldn''t be very much data at all.

One thing I do wonder about, is how would I handle battles? I mean, the network part of the code. Would it send back and forth every attack, or maybe let a client attack it and only tell the server once something dies? But no.. that wouldn''t work.. because other clients would want to have a chance to help that player slay the enemy or maybe even save their life.. Any thoughts?

I don''t see a problem with using DirectPlay for the networking piece. It works fairly well and you get all of the protocols for the price of one.


Breakaway Games

Battles - yes, having the server keep track seems like the best (easiest, yet still performance OK) idea.

There are more optimized solutions, tho - for example, you could have the server "hand-off" the battle to the first client machine to attack, and from then on the client would act as a "mini-battle server" for anyone else who joins in the fray. Then at the end the "mini-battle server" client could upload the results back to the main server.

Just a thought - and actually, rereading that, it sounds a tad complex... but I''m sure there are many other ways to do this sort of thing too.

Mason McCuskey
Spin Studios - home of Quaternion, 2000 GDC Indie Games Fest Finalist!
www.spin-studios.com

What kind of scale are we talking about on the MUD? 10 people? 100 people? 1000 people? More?

For a small number of people, TCP/IP would be easiest. As your population increases you''ll probably want to switch to UDP instead.

Also, how much to you trust your players? If it''s just you and your friends, then handing off mini-battles might not be a bad idea. However, handing off to clients may open a risk in terms of client-side hacks, such as someone trying to go into "god mode" by sending death signals upstream prematurly.

DirectPlay is a matter of taste. I personally use berkeley sockets for most of my network code, because most of the time the server is running on a *NIX machine.

I got something really good for you if you are going to code
it in VC using UDP. Search for mAngband for Windows. That could help you get going with UDP and Winsock.

Sending the players position every frame ain''t to efficient. Try instead sending ''when'' the player started to move and ''when'' he stops. You could use GetTickCount for this.

Hope I helped you

quote:

---

Original post by Geradian

I got something really good for you if you are going to code
it in VC using UDP. Search for mAngband for Windows. That could help you get going with UDP and Winsock.

Sending the players position every frame ain''t to efficient. Try instead sending ''when'' the player started to move and ''when'' he stops. You could use GetTickCount for this.

Hope I helped you

---

Well, that would probably work, but I would only want to do this if they were going in one single direction, right? Then if they changed a direction, send an update? But actually how less-efficient could it be? I mean, each map would probably only have on at, at any time, a maximum of 10 people. So that wouldn''t be that much data to transfer, and something as simple as movement, could be easily kept in a few bytes..

I plan this game to not be very big, more of a just a project me and some friends will make. Probably only will have max''s of 10 people when we start.. maybe around 50 once it''s more advertised.. but as you see, very small scale. So would TCP/IP be easier to code, or should I still go UDP just in case it does get big. Actually, what is the difference between TCP/IP and UDP?

Thanks,
Demitri

We had a spat about TCP vs UDP last month in the multiplayer forum, you might want to check it out if you want in depth pros/cons.

Basically UDP has lower overhead, but you need to code error conditions yourself. TCP is easier to program, but it''s a one size fits all kind of solution, that can really backfire on you if you have even a small number of flacky connections.

If you plan not to get past that 50 mark, starting with TCP is probably ok. That way you''ll be able to get your game logic going without having to worry about weird special network cases.