Also, I don't recommend that you make an online game in bGT. Its not meant for it, and the network object sucks.

but UP is made on the same bgt, and I want these games, too.
;server on my computer will.
;please tell me how important.

You will probably end up using Enet, though, when all is said and done.  Other languages may provide better networking, but TCP is really bad for realtime online stuff.
And lag is hard.  Lag is the reason we don't all have online games.  If you aren't using reliable packet transmission, you can assume all clients are 250 milliseconds behind the server minimum.  They may not be, but be conservative because many will be.  If you are using TCP, double this, at least from the server's perspective.  Other forms of reliable packet transmission may or may not run faster in terms of when the client and server can see state.
If you are not making an FPS, it's manageable.  Card games are fine.  SoundRTS is fine.  As soon as you say FPS, you need to start thinking about it though.  There are many solutions to it.  One simple one is the one Quake 3 uses.  This page is in English, and I do not know where to find translations or if such even exist.
Unfortunately, though, higher level wrappers are nearly impossible.  This is something where most games write their own because there's not really one model that works universally.  Your higher level networking stuff usually speaks a specific protocol or looks like twisted or Node.js, both of which are useful but decidedly not small or quick projects.  The one BGT is providing is already a higher level than most games work at.  The only thing that can be said here I think is that queues of messages are common: separate the networking into a thread and have it send deserialized messages on a to-be-processed queue and take deserialized messages for serialization and broadcasting on an outgoing queue.  But even this is not universal, and it may not even be particularly common.

Visual basic 6 is worse than BGT.  Visual basic 6 requires a bunch of special steps to run on a modern system and died something like 10 years ago.  If VB6 still runs in 5 years, I'll be very astonished.  I'd bet on it being completely dead by Windows 10 or whatever comes after. 
If you're not going to use BGT for this, something which may not be a good idea for Jonikster given his questions, use Python or C# or VB.net or even java.  These technologies have foreseeable futures for which people will be able to run your stuff without difficulty.
But seriously, look at all the problems people periodically have getting Swamp running.  If you use VB6 for new projects, you deserve everything that *will* happen to you over the next few years as the technology you're using continues to be deprecated.

It's not BGT.  They're all about that slow.  Sometimes you can get faster, and many players will usually be down around 100-200 MS even with TCP, but that's only for people near your server geographically and on good high-end internet plans.
Basically, the speed of electricity (which I believe is less than the speed of light), bouncing off satellites, packet loss, routers needing to hold your packet in a queue while they run software on it, etc.  Ping various web sites.  That's about the time with TCp.  It's roughly half for unreliable packets, roughly and not always and with caveats.

I'm not saying you can't.  I'm saying most players.  I have been very careful to use the word most players.
I am on university internet and therefore get 2 or 3 MS to Google who, judging by this number, probably has a datacenter near me.  If you're on a university network, you're most likely on the very backbone of the internet.  If you also ping places that are on the backbone like you are and if they're geographically close, yes, you can get some very impressively low numbers.
But most people aren't on this kind of internet, let alone most blind people.  Most blind people probably don't even have top-of-the line home internet.  And I'm pretty sure that any project you're considering can't afford to buy space in the best datacenter you can find, let alone put a server in every country.  If you plan to be playable around 150-250 MS lag, you'll hit a whole lot of people.  If you plan to be playable around 30-50 MS lag, you'll hit very few people.  If you geographically limit the game, you will hit few enough people you might as well not bother.
And if you assume you can always and only use unreliable packets for everything, well, meet the people with 75% UDP packet loss for whom you probably have to switch to TCP or purely reliable UDP if they're even going to play at all.
Ping to my VPS in a datacenter in Denver from my highest-end-possible college backbone internet in Florida? 70 MS.  It would not be possible for me to upgrade my internet to this level without inordinate amounts of money if I were in my home.  It would not be possible for me to upgrade the network situation of my server much if at all for likewise inordinate amounts of money.  If you can shell out $100 or so a month, you can get an actual private server in a datacenter and etc, but few of us have that and you'll need another $100 or so a month to get your home internet up to an equivalent in most places.  Some places like Kansas have gigabit internet for reasonable prices, but these are few and far between and they still don't mean that your round-trip time is low.
I'm sorry to disillusion you but yes, if you do this, most players will be a quarter to a half second behind.  Shared timestamps are not possible.  I've looked into that too.  If you do something like SoundRTS it barely matters.  If you do something like Swamp, you need to put all sorts of stuff in place to make sure the game remains playable.  This is where a lot of the cheating that Swamp does in regards to what's synced and what's not comes from.

well, from what i've witnessed and making a multiplayer game my self, if you do it just right it won't be amazingly offle either. If your players can deel with like a 200 to 300 ms ping, well then you could probly do it. It's not fun though. I remember when I released survive the wild, the 200 ms held till about 10 players, then broke to a vialent 3 seconds. But I find that with bgt, what causes the loss in fps's is most people decide not to be smart, and when they fire a machine gun, it sends a packet, which the server then has to return to the rest of the players. So saying, if you had a lightning fast machine gun that can fire once every 50 ms, what would have to happen, your game would send something, then the server would take that, and if the bullet were to hit someone, it would have to send a packet with something like a pain sound, as well as the firing sound. Do you notise how in rtr, sometimes if a player goes offline or there game goes messed up sometimes you just hear them shooting non stop when they really are not? I think in rtr, he sends like start shooting, stop shooting, or something a little more dynamic than a packet every 50 ms. Because that is what causes lag. Not to mention, the server has to have a loop, nested in a loop, nested in a loop, sometimes over and over again. In the server you have your main function whare stuff get's set up, then the looptakes over. Well, you need to have it look at players which you'd have to store in an array, and it'd have to see what goes on with them and health and stuff, so if there health was 0 they'd die, it has to check the main stuff like connecting players, it has to check items if you were to have those, etc all in different loops. And you have to therefor make sure the loops are being called correctly. Oh boy i'll never forget the time I had to decrease lag on my server, well, I sort of called a loop twice, and it caused a stack over flow. But the problem was, server updating. My host has a thing that can chat me runtime errors and restart the server so I can fix the error and the server doesn't stay down. Well that kinda fails when you cause a stack overflow or some other odd error on startup. Yay for me being spammed like heck with skype chats. Peobly ran the host machine insain. lol. But that could cause some issues for you to is server updating, not really if people will beable to host there own servers, but, if you host one, it's an exe file. Unless you can forward ports, you'd need a host, and a way to update the server. And sometimes coming up with that, ain't fun. And also camlern was right about the locational and internet speeds, it could be both players or servers. So I think if the network object is used just right and the server is coded correctly, and you have a good way of hosting servers and not spamming your players with packets, then I say give it a try.

Welcome!
So I speak in detail.
1. I have bgt, and only bgt.
2. I have a server on my computer;
3. All sound files, etc are stored in kleenta the game;
4. Each player is recorded in the class of users;
5. When it comes into play, the object receives its activation via, for example, variable.
And here is how it's all done, the server, etc. I Do not Know.

Ooooooo. Can you imagine a racing game with that? I am making a simon game bassed off BGT's memory train tutorial and I'm not liking what I'm hearing. Because I want to do a multiplayer mode that will go up to four players. So if I can't do it, then All I can say is screw it. And remove the multiplayer item from the main menu.

Hi
Sorry for bringing back this old post. Someone posted a topic about online games in bgt, and I have a question about this. That's why I brought back this post.
If I make an online game in bgt, What can I make in bgt without a huge lag? Everything except for fps's?