There are built networking commmands, but they are buggy and suck, so use multisync if you want to use networking. In case you don't know about networking, heres the basics of it. The server can send packets to the clients, but each client can only send packets to the server. Packets the client sends to the server that the other clients need have to be forwarded to the other clients via the server. Packets are a bunch of variables(strings, integers, floats, whatever) that are sent to the server or a client. The receiver of the packet needs to know what kind of variables are in the packets ahead of time and what to do with them. Making the first variable in the packet an ID (say 1 for player movement, 2 for shooting etc.) is good so you can read it and then read the rest of the message based on what should be in it and do the correct stuff with it (i.e. read the variables in the message and position the player if the ID is 1).
Remember it's never good to use sync rate 30 or 60 to control the program speed, use sync rate 0 and use a timer to control the program speed. Here's a good function
Function FrameTimer()
Diff# = ABS(hitimer() - timer#)
timer# = timer()
Ideal# = 1000.0 / 33.0
FrameX# = Diff# / Ideal#
If Diff# > 1000 then FrameX# = 0
EndFunction
Say you designed the game at 30 fps and started to add Timer Movement. In the part of the code with Ideal#, change the number dividing 1000.0 from 33.0 to 30.0. Then whenever you are moving objects or whatever, multiply the amount they are supposed to move by Framex#. If you are using object animations, use
Set Object Speed <insert object number here>,100*FrameX#
to control the object's animation speed. It'll be a little off, since this command only will round your number to the nearest whole, but it works well enough. It's probably a good idea to globalize timer# and Framex#, too. If you have the Matrix1 Utilities (you probably don't, but they are useful, you should get them) you should change timer() to hitimer(), because it's more accurate. Using timer movement is useful because it
A. Makes gameplay amoother when your FPS is high
B. Doesn't make the game slow down at lower FPS or speed up at high FPS
C. Ensures that no player is at a disadvantage when their FPS goes down and they start moving slower in a multiplayer game
Also remember to only send messages when something in the message has changed since the last sent message (i.e. if the player hasn't moved since the last packet informing the server of the player's position was sent, why send another?). NEVER send packets every frame, especially not with timer movement, the server will be flooded with data and there will be lots of lag. You should send movement packets(the x, y and z coordinates of the player, the y angle of the player (and the x and z angle if necessary), and it's state of movement, like whether its walking, or standing still, or running etc.) 20 times every second and most of other stuff whenever they occur(i.e. sending a bullet shooting packet when you shoot the bullet), meaning that the receiver of the movement packet should receive them once every 50 milliseconds, provided the ping(time in milliseconds it takes for a packet to get to the server and for the servers acknowledgment of the packet to get to you) doesn't skyrocket or plummet. Obviously, if you just position and rotate the players where the packets say 20 times a second, movement will be jerky. There are two ways to combat this. One, use extrapolation, or predicting what will happen. An example would be if you took the players position and rotation and moved it in the direction the packet says until the next packet arrives, then position and rotate the player and repeat, doing this based on the players movement state. This is okay, but should really only be used if packet loss occurs. Another way is to use intrapolation, or using stuff that already happened to make smoother movement. An example would be if you received the first movement packet, you would wait for the second, and 50 milliseconds later, the packet would get there with the players position and stuff. You could then move the player from the first packet's position to the second's at the speed it would have had to have been moving to get there in 50 milliseconds. Here's a bit of pseudocode using a second timer called timer2# and a vector, which needs to be initalized with null=make vector3(1)
Packet Gets here at this part
set vector3 1,packet1x#-packet2x#,packet1y#-packet2y#,packet1z#-packet2z#
dist#=length vector3(1)
length#=dist#/50
timer2#=timer()
Do this until next packet gets here
time#=timer()-timer2#
timer2#=timer
Move object object,length#*time#
This will intrapolate the object assuming the packets are coming every 50 milliseconds. In the event of packet loss, you could use the first method, which I explained already. Intrapolation will cause 50 milliseconds of "lag" even if you are running the server on the same machine as the client. But a twentieth of a second is pretty neglible.
This isn't necessarily true when dealing damage to other players. If you shoot someone, and you are right on target, it might reach the server at a time the player isn't in your sight anymore, and won't count as a hit. You can correct this by going back in time. Shot time=Server time-ping-50 milliseconds. Then you can temporarily move the players back to where they were at the time and calculate the hit.
You might wonder why you would go through all this confusion and risk a calculation error when the clients could just calculate themselves and send hit packets to the server when they shoot someone. This would be fine if you are making a game to play with friends, but a mainstream game like TF2 or Counterstrike has a large enough player base for cheaters to be present and they could send fake hit messages to the server to kill people all the time. So, yeah.
For highscores, if you wanted to keep track of your own, you could use a file like so.
open to write 1,"Highscore.txt"
write long 1,highscore
close file
And when you read it
open to read 1,"Highscore.txt"
read long 1,highcore
close file
To see everyone else's, you need a central server with an IP address that doesn't change so people can connect to you. In addition, you need to set up port forwarding on the server's router, you can learn how by going to www.portforward.com. Then you could do something like this, assuming the highscores are stored in an array.
net put long highscores
for x=1 to highscores
net put long highscore(x)
next x
net send
For the Client
net get long highscores
for x=1 to highscores
net get long highscore(x)
next x
Sorry if I left anything out or I typed too much (I'm pretty sure I did). Just a few things, to host a server, just use net host <insert max clients here>. To connect use net connect <insert IP addresss in the form of a string here>. You will need to precede packet receiving network stuff with while net get message()>0 to make sure a message is actually there. Also, the network code in this post uses multisync, if I forgot to put that. If you have a question, just ask. Hope this helps.
cout<<"I'm learning C++, and this is all I know
\n"
