VB Multiplayer programming

Visual Basic, huh? Hmmm. Well, I''m not going to say it can''t be done, but you''re going to have a much harder time than if you used C and/or C++. Why not use them? I don''t mean to start a holy war here, I know VB has made great strides forward in the last five years, but comercial games are written in C++ for a reason. A MMOG is an extrordinarily complex beastie, for which you almost have to have OO programming skills, and you are already handicapping yourself by chosing a language which is way underpowered for the task.

As for DPlay vs Winsock, let me tell you my experience. DPlay was very simple to set up. I wrote the DPlay networking code in a couple of days and had connections up and was passing data back and forth between my client and server in a couple more.

But, you will find that DPlay is not really suited for a MMOG. It can handle maybe 30 connections, tops, then its going to seriously bottleneck you. If your game is designed to handle that level (or less), then I''d say go with DPlay. But you mentioned you were writing a MMOG, which brings to mind a thousand simultaneous connections, and you will never get that with DPlay. For that, you will need a WinSock IOCP server.

I prototyped my game using DPlay, got much of the 3D engine working, and a few other things. I then went back and wrote a WinSock IOCP server and asynchronous socket clients and dropped that code into my game. I can now (theoretically) handle many thousands of connections on my server at once. I think this is a pretty good way to go, because you can get your game up and running pretty quickly, and once you get to a point where you think you are ready for your real networking code, you can start writing that. If you encapsulate the networking code properly, you can simply pull the DPlay out and drop the WinSock in, and you''re all set

Oh, figure about 1 month to get a working IOCP server up and running. You mention you already wrote a working network, using (I presume) WinSock, but you don''t say which model you were using. From your description, I''m guessing you used blocking sockets with threads? The "one thread per connection" model would cause what you describe (loss of speed, due to constant thread context switching). That experience will come in handy for writing the IOCP server, so its not a total loss The difference with IOCP is that you won''t get that sort of drop in performance with more connections.

Good luck!

Ron

Since Dplay encapuslates winsock, it just cannot be better... perhaps it''s easier for beginners, but even that is discussable.

Hmmmm...
He said "VB" and "programming" in the same sentence.

quote:

---

Original post by Anonymous Poster
and to give you some side information; Most if not all Multi-Player games use DirectPlay8 in the networking code.

---

That''s a false assumption. Most of the mp games, if not all use pure Winsock code.

quote:

---

Original post by Anonymous Poster
An example would be "Aliens vs. Predator Gold Edition".

---

That must explain why AvP netcode is so laggy. Don''t tell me it''s false, I''m an AvP fan.

quote:

---

Original post by Anonymous Poster
Visual Basic vs. C/C#/C++:

---

Oh my god, he is going to launch a vb. vs C++ debate...

quote:

---

Original post by Anonymous Poster
Visual Basic, theoretically, is capable of anything that C++ is. If you''re writting a game using SQL Databases, VB is the way to go.

---

WHY ? It''s as easy to write it in any other langage.

quote:

---

Original post by Anonymous Poster
C++ is denoted as being a High Level Object-Oriented Programming Language. It''s one step above High Level Assembly, where Assembly is one step above Machine, which is, in turn, the true computer language.

---

Hahaha TEH FUN. It''s the opposite actually.
Low level = near to the processor. C++ /asm are low level.

quote:

---

Original post by Anonymous Poster
So as far as this contest goes, C++ vs. VB = Even. 1 to 1.

---

Of course... You are drunk.

quote:

---

Original post by Anonymous Poster
I beg to differ on the Winsock vs. DirectPlay8 conversation going o here. The performance of your game depends on your own manipulation of the API presented, and the resources you have to burn.

---

Not entirely true. It also depends on the design of the API. In this case, were talking about DirectPlay, and DPlay is not and never was designed for handling large numbers of connections. It''s just a limitation of the API, and no amount of manipulation of it is going to get you better than a couple of dozen simultaneous connections. Perhaps this will change in future iterations of DPlay, but for now, that''s just how it is WinSock has several different IO models, some of which are comparable to what DPlay does (asynchronous sockets), some of which are worse (blocking sockets), and some which are better (IOCP).

quote:

---

Most if not all Multi-Player games use DirectPlay8 in the networking code. An example would be "Aliens vs. Predator Gold Edition".

---

Sorry, Purg, this is patently false. Most if not all Multi-Player games use WinSock. I dunno what the specific API AvP uses (I''ll believe you that it uses DPlay), but again, you''re talking about a low number of connections (<30). I believe I said that DPlay is a good way to go if you are going to limit your game to that level of players. Understand, I *like* DPlay, I think it''s a good tool. But the OP asked about a MMOG type system, which implies hundreds or thousands of players, and for that, DPlay is totally unsuitable.

quote:

---

Any machine/remotely hosted Server, from a home-based comp running on a shitty cable/dsl modem will incapable of handling "thousands" of connections anyways. So either way you go, either is fine, depending on the purposes you intend to use them for.

---

The OP asked about a MMOG system. I can only presume he has a connection capable of handling MMOG levels of players. That''s a whole different issue. You are correct that if the programmer is running their server through a dial-up, IOCP isn''t going to get you any better than DPlay would But you''re talking now about a bandwidth limitation rather than an API limitation.

quote:

---

Visual Basic, theoretically, is capable of anything that C++ is. If you''re writting a game using SQL Databases, VB is the way to go.

---

I''m not going to get drawn into a C++ vs. VB debate. I don''t have time for it. We can agree to disagree on this issue if you like. For myself, I wouldn''t touch a MMOG project that wasn''t written in C++ and OO with a 100'' pole. If you think it can be done with VB and procedural programming, feel free to prove me wrong

quote:

---

By the way, Ron. It took me 14 hours of straight pogramming to write a fully functional server and client that were and are still ready to have a 2D tile engine implimented into the client side.

---

Cool. Using DPlay, I presume? It took me a couple of days (I didn''t keep track of the hours, heh) to get a basic connection between server and client using DPlay, and another couple to implement a usable protocol so I could pass useful packets back and forth.

Using WinSock, it took me about three weeks to do the first part (asking *lots* of stupid questions both on this forum and elsewhere ), and another couple of days to pass useful packets (this used basically the same protocol I created for the DPlay version, with some minor modifications, so it wasn''t so hard to do). Now, I was using IOCP for the server, which is by far the most difficult WinSock model to use. If I had used asynchronous sockets, it would have been comperable to DPlay setup time, I think.

quote:

---

I d know that what I wrote could handle up to if not more connections than 500, which is more than enough for any small MMORPG who''s first release is not P2P

---

Umm, I hate to be negative, but I think you''re in for a bad shock if you try to run that game with 500 simultaneous connections. I''m telling you, DPlay isn''t going to let you do that. It''ll either crash outright, or be so laggy on the server end you''ll run through your main loop once every half an hour. Have you tried? Prove me wrong. Run 100 instances of your clients, passing 100 bytes every second each to the server. Have the server respond to each message with another 100 bytes passed back. Do it locally (unless you can find 100 remote machines, hehe). Let me know what the performance numbers are (I''m not kidding or being flippant, I''d really be interested to know). I''d be surprised if your server keeps running past 100 connections.

Ron

FLAME-WAR !
FLAME-WAR !!
FLAME-WAR !!!

quote:

---

Original post by Jebediah
I''m trying to make a Morpg with VB. I have successfully made a TCP and a UDP network but it seemed laggy. I ran a simple test program that ran at 80 fps. When 4 other computers connected (lan) to my server the fps dropped to 21 fps. I doubt this will be acceptable for online play. I am considering trying DirectPlay 8.

Is directplay worth attempting? I have only heard bad things about it. I am going to try it anyways but I can''t find any source code or tutorials.

-Jebediah
Nostalgic Studios
Email: Jebb99@Excite.com

---

BTW, were you using asynchronous sockets? If not, then that''s the reason it was laggy

Asynchronized who now? Such big words. I doubt I was. I''ll hafta look into that after I look up asynchronized in the dictionary.

BTW - I meant Morpg as in multiplayer online rpg. Not mmorpg. Sorry for the confusion. So 32 players is more what I am looking for.

So I think my best bet is directplay. It would probably require less programming then winsock stuff. I''ll play around with Purgatory''s code when I finally get some free time. Thanks for the info ppl.

Basically, a synchronized socket will "block" until it has finished what it's doing. This means that, when you call, for example, connect(), it won't return until it has established a connection. While this is an easier way of creating networked apps, it's definitely no good for developing games.
Asynchronous sockets, on the other hand, allow your application to go on with whatever it was doing before, and will notify you when it has completed a request. This is much faster and nicer-looking, as it means that your FPS isn't restricted to network latency
DirectPlay is asynchronous by default, and handles all the nasty low-level things (like fragmented packets, order-of-delivery etc) for you. Plus it does it at a reasonable speed.
I'd recommend DirectPlay simply because I love the interface, and I haven't had any trouble with it yet.
Good luck mate.

P.S. If you have the DirectX 8.1 SDK, check out the DPSim tool. It rulz.

EDIT: my speling is deradful tioday!

[edited by - ShoelessManiac on June 4, 2003 10:16:07 PM]

quote:

---

Original post by Jebediah
BTW - I meant Morpg as in multiplayer online rpg. Not mmorpg. Sorry for the confusion. So 32 players is more what I am looking for.

---

Oh, well that''s different then. Use DPlay