Game: How to implement Multiplayer?

[ErosOlmi]

I did some test in the past with Petr using TCPUDP module to play a little game over Internet and over LAN.
Over LAN problems were mainly related to latency. For some aspects, speed to handle network packets was not enough.
Over Internet problems were related to security because router/firewall/personal firewalls blocks incoming packets if not started from inside.

I do not say it is impossible to play over Internet but we have to study how.
HOW can be simple or complex depending where we want to go. In its simplest way, it requires you to open a port in your router (and firewall if resent) and redirect all traffic of that port to the LAN PC. It is called NAT (Network Address Translation). Some routers call it "Virtual Server" configuration. In its more complex way it requires a gaming server to be in the middle of all players but this is a much more complex situation not worth to talk in this development session.

Ciao
Eros

[ISAWHIM]

TCP, only for setup and initial sync... (Also for reconnect.)

Always use outgoing ports that are above 1024.

UDP, (Blind packets), for spewing out a time-stamped location and action-list. (More like a time-line script.)

Ignore PING, most routers/ISP will (Block, Drop, Ignore) even if listening for one.

Occasionally send an, "I am alive" packet.

Most TCP has a forced time-out, and will kill a, "Stay alive", even though it has not requested a "Close". (Less of a problem on a simple router/switch for local.

You have to have the program "Assume", that the remote player is doing the last thing he did, until corrected by an incoming packet. If he is running forward, he keeps running forward, but slightly slower, until the incoming packet says... Hey, I am at (XZY)@12:00:01... You have to transition mild changes, and bump harsh changes... The further the distance of correction, the more harsh the corrective action. (Movement is only a suggestion. No need to send EVERY frame, only 1/10 from the remote player. Packets should NEVER be assumed to arrive in order.) You still use intercepting collision on the remote player, so the auto-pilot movement does not carry the player through walls or other objects. The corrected location will have also been through the collision, on the remote players computer.

You only need one UDP port open. You can actually use a common allowable non-blocked port... like port 81. That is HTTPS, and is usually never blocked by most ISP, and packets are usually not scanned, since they are likely encrypted, and not containing a valid blocking header. (ISP's use a filter to detect incoming packet headers, and certain "Unknown" potential viral packets get randomly dropped. Plus, UDP has a lower priority to a network hub, than a TCP.)

TCP uses a HAND SHAKE, and has a special "Packet Ration", and "ReSend" function. It does this automatically. It is horrible for instant data, as all data is buffered until a certain packet size is reached, or a time-limit expires. When a packet is missing... it will request a resend of the missing packet, holding the remaining buffer data hostage until it gets it. (If it never gets it, the connection gets terminated due to an error.)

IPX/SPX is better for games, it is like UDP on steroids... but has data limitations. (Great for LAN.)

These are just some things I learned while playing with my own servers, and while setting up live connections. (Nine times out of ten, I could use the junky VB OCX for simple solid connections for hours and hours, without much problem.)

A browser will open up 1-10 ports for incoming objects. It does not depend on one stay-alive TCP, and will even open a UDP for some web elements like streaming data files. A nifty tool called TCPVIEW.
http://technet.microsoft.com/en-us/sysinternals/bb897437.aspx

The creator has TONS of other neat tools. Great for a developing aide.

[ErosOlmi]

Just for the record ...

HTTPS usually works on port 443

thinBasic has a basic TCPUPD module already in place. We can think to implement it a bit for the client side and the puposes of this contest.

[ISAWHIM]

But port 443 is heavily scanned, while 81 is not. (UPD 81 for HTTP, and common HTTPS alternative. Not blocked by most internet routers. The ones regulated by ISP's on the backbone. Old choice to make doom and quake and private servers run, when ISP's began blocking and dropping 80 and 443.)

You said you had problems with connection and lag and dropping. You didn't say much else. (That is usually a common start-point, besides a hardware issue.)

FTP and WINDOWS TIME port are another good port to jump into. (Those are not heavily scanned. They use hardware scanners on a backbone to intercept viral breakouts and reduce unwanted server traffic. Games are unwanted on most backbones, as well as streaming video and audio. You can pay to get into a whitelist, but that is not a common practice. Usually, they rent a portion of the backbone bandwidth for large services.)

Looking around the net, a large portion of ISP's are blocking those also...

(It has been years since I have had to use anything other than port 62,000 for anything.)

Even injecting a dummy header, like a HTTP GET request might get you through. (Just ignore that on the return packet.)

I still think the largest hurdle for most people to contemplate, is that a connection is not quite real-time. (Where you see BOB, is not always where BOB is, and BOB doesn't always see you, where you are, on your computer. The important thing is... if you hit BOB on your computer, BOB sees you hit him on his... no matter where he is, and you are.)

Races are the same way...

On your screen, you finish "Physically" before BOB on your screen... but in reality, BOB finished before you. (The time-exchange holds the confirmation.) No winner is shown, until all players have reported the times. The "Estimation" of where BOB is, at any given time, should put him within a few pixels of his correct location. But one computer should not manage as a HOST, because that causes a yo-yo lag, and a dependency on confirmation of all data, before you show any reaction on your side. It becomes a folding paradox... your position can not be sent correctly, because you are always waiting for the other computer to tell you where you told it you were.

LOL, looks less complex on paper, with a timeline drawn.

[ErosOlmi]

Jason,

yuo have great ideas and knowledge but in this community we are usual to talk with some fact at some point.
After some words we come out with a fact.

A fact is a piece of thinBasic source code. Nothing else.
If you have something to show use, show as with a piece of "fact".

A fact could be your piece of code taken from Petr initial study on AI and improved to work on a LAN.
Maybe starting from the LAN concept we can more it on a WAN on internet.

I would forget a server side version for the moment because it would require an year on development only for that.

I will waith for some facts.
In the meantime, a tcpudp chatting example can be found at: http://community.thinbasic.com/index.php?topic=494.0

Ciao
Eros

[ISAWHIM]

Sorry, the title said how... I was just offering ways (Methods) that I have worked with and around.

I am not sure how to provide code that would demonstrate multi-player mode of a game that doesn't have a single player mode yet. (I don't have a proxy, WiFi, dial-up, Satellite, or any other laggy connection to test or show a sample. The code would not be the same for a loop-back or a home network.)

Chat code connections will not help you develop the game code connections. Chats are not time sensitive and people type slow, and send little information in that transfer.

I will be silent on this topic in the future. I will not be able to provide the "Facts" you need. I thought the "code" forum was for code, and this "general" forum was for "Concepts". My mistake. I am still learning, I apologize again. (Just seems that I am getting yelled at for not knowing things that I should. :'( :-* )

http://skullbox.net/tcpudp.php
http://www.devmaster.net/wiki/UDP_vs_TCP

If I have free time, once the AI and game physics are complete, I will be happy to pry into the TCP/UDP modules and outline a method of transport protocol. But I will have no way to test it. I can test the code that interacts with the game, as if I am connecting to a faulty connection, but that would only be a simulation of a bad connection. (TCP has a mind of it's own.)

[ErosOlmi]

My post was not to silent you but just to be practical. I mean, theory is perfect but at some point we need a code to test, implement or just put in the bin because we discover problems not able to face at the moment.

A piece of code, even if not working perfectly or just 50%, is a good way to start. When games are developed, every single new idea is first tested with prototypes on single aspects. Even if we still do not have the game, if we will want to go multi player in some game, we need to test the single aspect not with a complete ready application but with a script to test feasibility or just show problems to solve.

Your ideas are very interesting. The idea to keep it locally moving and get info from the net only when available is very clever and to be considered to avoid lagging.

Ciao
Eros

[ISAWHIM]

Only being silent on this topic... until I can contribute code... ;D