blitz 3d multiplayer

Now something ive not looked into but has anyone got a blitz 3d game working as a network/online multiplayer. if so how well does it work and does anyone one know of any example code for something basic

http://sailing.bansheestudios.com has very stable network code, but a tutorial would be a bit indepth - how about looking at the code base or picking to pieces a network library?

Technically speaking Blitz 3D's network functionality gives you all the funcitonality you could ever need. It has libraries for TCP and UDP. It does not have DirectPlay, but this is definately no loss!

thanks Banshee

im looking for 4 player at the most. not anything to flashy only an idea for a game ive made that runs with a split screen at the moment. i have no idea about how TCP and UDP work with games so is there anything i should read to point me in the right direction?

I just saw in the docs that directplay is in there, so I was wrong on that. I wouldn't use it personally, but it might suite the purposes of a 4 player game.

TCP is easier and more stable, it just isnt as quick as UDP. For ease it's probably the way to go.

I learned TCP networking from looking at a web server example in the code arcs.

ive just downloaded the k-netlib after reading though some old posts, looks really good. i would still like to get my head round the basics of blitz's tcp comands even if i do use the lib. any tips anyone?

It's not 3D, but it uses TCP protocol and isn't very big (compared to a real game): http://www.blitzbasic.com/codearcs/codearcs.php?code=1658#comments

thanks Andres ill take a look.

Anyone know of anything better or easyer than k-netlib for a 3d 4 player game?

would it be worth me learning how TCP works as my game only needs 4 players and is a quite basic deathmatch style game.

It depends, if a person lives on the other side of the world the ping could reach to 500 milliseconds and until that you can't do anything.
For a FPS you can use UDP because it doesn't matter much if a packet get's lost, but for RPG you mostly need every packet to be successfull transferred.
In blitz it's very easy to crash/freeze a server running TCP server so I'd choose UDP.

I personaly like to code the protocol and networking stuff myself so I don't use DirectPlay.

can you give an example of how udp works? ;OP

I've done a lot of B3D networked multiplayer. Here's a 2 and 1/2 year old example:

http://blitzmax.com/codearcs/codearcs.php?code=1149

I was thinking of doing another example because I've implemented some much improved algorithms but this gives you the basic idea. It uses DirectPlay but that's fine for small stuff. You can use something like BlitzPlay which is a bit faster than DirectPlay but truth be told if you code it tight you can get by on DirectPlay if you're not being too ambitious. I definitely recommend BlitzPlay Pro though, it's a very complete library.

Sorry but I suspect that was a bug in your code, i've never experienced any TCP server i've written in Blitz crash, and i've written several. Oh sure the odd MAV from *my* code, but that's all :).

I wouldn't recommend UDP for your first network game, mostly because TCP introduces you to a wider and more versatile skillset for you to use in the future, such as making web stuff :), but also because UDP is a little more complex to get your head around initially.

As far as the benefits are considered, UDP data packets are about 30 bytes smaller than TCP packets which makes them "slower", also a missed packet is resent whereas in UDP it's just dropped. The UDP packet header size is roughly 65 bytes (not sure exactly) and TCP 90 something.

I going to look into TCP and try to get it working without using a lib as its a good thing to know how to do. thanks for the tips peeps.

Here's some links you may find useful.

http://beej.us/guide/bgnet/

http://www.gamedev.net/community/forums/showfaq.asp?forum_id=15

thanks Bill

I HAVE! The reproducable one was using the server on a windows 98 machine and throwing a ton of TCP packets at it (continually writting to it and letting the win98 server app pull from it as fast as it could). Froze up the machine every time.

I've written a few server/client apps myself in blitz, so I am no novice at it (started with blitzplay and re-wrote my own a few times over).


Yeah, that and the overhead work you have to do to make good sense of the data comming in, well, lets just say you will have your own support systems in place to handle it. It's alot of work, but it's worth it in the end.


Not to purposly disagree with you becky, but:
TCP is slower due to the ACK that each packet must get. Send a packet out, wait for a confirmation. if none is sent, resend. Why this is slow is because when the packet enters the client machine, it has to go through its packet buffer and determine if A. it's in order, if there are other packets before it that it is still waiting on, B. if the data is intact (that no data was chopped off during transmission) and C. the means of response.

If the packet is out of order, it must wait for the packets before it to come in (or be resent if they were lost) before it considers that packet as being 'recieved'.

It's slower because it's reliable. UDP requires alot of extra stuff on your end to be able to rely on the data (to a degree of course). It will never (ever) be as relaible as TCP (There are some LANs that have packet loss believe it or not), but it will always be faster.

Banshee, I created an alternative for Shoutcast. It streamed music to clients like Winamp. But if you press pause button so you won't receive any "OK, bytes received" message your server will freeze.

@Andres - did you continue to empty the buffer? It sounds like you over filled the stack.

i read bytes from the file ReadBytes() and then i sent it with writebytes() and when i pressed pause then it froze.

At the beginning i wrote Battle Empire with TCP protocol, but it got too slow with some people online so i wrote the whole network to UDP: http://www.blitzbasic.com/Community/posts.php?topic=59351

i want to make a 4 player 3d 3rd person shooter. each player is a tank you can also play in first person. i want it to work from my house to a couple of friends houses in the same town. they all have good dsl connections. Would TCP still be a bad option or good enough. as most fps's have 16 players + and i would have thought thats why they use UDP

Hi Pete - if you can find BlitzPlay Lite it should handle this fine. It uses UDP and is very easy to use.

TCP is fine for your needs Pete. Of course to a great extent it depends upon your own network coding.

Try out the sailing game I linked with your friends, it has two connection modes - normal and ultralow bandwidth. In normal you should be able to play with 99 friends on broadband, on ultralow bandwidth mode you should be able to get 15-20 players or so into a 9.6k mobile telephone based modem from a yacht sailing around the Essex coastline, and it doesnt suffer from stack overflows ;).

At the end of the day from your perspective you want something simple, TCP is much simpler than UDP. In regards the technical aspects of whether TCP is up to the job - it's more down to your coding than the protocol, TCP packets are a bit bigger, but well written network code need not be impeded by that.

Almost all indi coders make the total mistake of sending data packets at a timed interval, in fact a lot of professionals do this too. This is wrong, in fact, it's plain lunacy.

Say for instance if you send packets 5 times a second, that's every 200ms. Add to that latency of the packet getting to the destination, that's another 50ms say... Now that data as reached the server it must be relayed to the other clients, that's another 50ms. So your data could arrive 300ms after a player changed direction. Send your packets when the state of the control keys being pressed changes and your data will only be 100ms in the same scenario.

The second biggest tip is to also send the control key being pressed and continue to process it. Lets say a player is turning right, do you send the angle of the player a few times a second, or send it once along with the speed of the turn? Eh voila, smooth movement...

These two techniques makes that sailing game play very well in multiplayer with a lot of connected players, the ultralow bandwidth mode will quite happily run lots of players via a 9600 baud modem, and it uses TCP/IP.

Sure OK I am using UDP on my current project, because it is the more appropriate tool for the job and i'm an experienced network coder, but in your position I believe TCP is the best choice.

I can't add much more to the conversation beyond what people have already said, but having played Banshee's sailing game myself, I can attest to the fact the internet gameplay worked spectacularly well, TDP or not.

Granted, it was/is a fairly relaxed sailing game, so depending on what you're trying to throw together you may want to take the pace of it into consideration. But it certainly worked a treat.

I cant thank everyone enough. ill keep trying till i get it.

Matty: ill have a look at blitzplay but i thought it died along time ago ?

Pete, do yourself a favor and just use DirectPlay. You're only doing a 4-player game afterall. DirectPlay which is built into Blitz will handle that with ease. If it's the game you're actually after then there's no need to write your own networking lib based on UDP or TCP ... go more abstract.

?

im still trying all my options and see which one i get my head round the best.

And whats the whole Gnet think about?

GNet is a PHP solution that lists your computer as a server for others to join. If you host a game of FPSNet for example, GNet will upload your gamename and ip address to the Blitz GNet database so that other people playing FPSNet can find you and join your game from the Internet.

DirectlyPlay is what you use to actually send gameplay information back and forth (positions, scores, etc...) and GNet is what you use so that people can find your hosted game.

By "go more abstract", I meant use something higher level like DirectPlay. There's no reason for you to start closer to the root of networking with UDP/TCP stream programming when DirectPlay will handle a 4-player shooter with ease. A good example of abstraction is a car. You don't need to know how all the parts in a car work to drive one. Driving a car is abstracted away from the mechanics and details of it the same way that DirectPlay is abstracted from lower level networking functions.

I think on balance i'd still recommend TCP, because the knowledge learned would be more useful in the future. Learning TCP will lead you into UDP, and also, learning TCP will give you the ability to write internet applications as it's TCP which drives the internet.

DirectPlay still doesn't simplify the important bit, which is learning how to composite a string of variables together and send it. It just simplifies the joining game process - although I find it's simplifications more annoying than anything else*.

*I've not used DPlay within Blitz, but in other languages in the distant past.

Hmmm it's really simple. I don't think using TCP/UDP directly is much more complex but still if it's the game he's after then DirectPlay has been provided and it will get him up and running with the game quickest.

Banshee has a point. i think im going with TCP for this game. where can i get examples of the sort of strings a fps shooter sends back and forward to the server. I guess keydowns and direction/speed?

Position/angle, mommentum, control keys pressed :)
Other data I usually put into a different packet, such as health etc.

For Internet applications you can use PHP like GNet. If you actually needed to use TCP then learn it. In my opinion this is why so few people actually get games done. You're too busy messing with code that is utterly pointless for the project at hand.

If you wanted to learn TCP networking then why didn't you just say you wanted to learn networking (muliplayer = game)? If you want to actually get to the multiplayer game as you suggested then it's a distraction to dive into the protocol when it's already taken care of. Do you want to actually make a game or do you want to wander around endlessly in the code that comes before it.

With the amount of code that it would take to create a new networking lib from scratch using TCP/UDP you could probably write an entire game. Additionally, TCP isn't very fast

Cool if you want to learn TCP programming ... good for you. If you want to produce a game though you're heading South before you go North. In principle, you just threw Blitz out the window and picked up C++.

Just being the devil's advocate ;) Honestly, go for it if you feel that's right for you.

jeremy : so your vote goes to direct play.

yes i am making a game i have a finished version thats split screen but i want rewrite it with online multiplayer as well. so yes i would like to use the easyest option that can do the job well.

All systems will handle 4 players.

DirectPlay: Allegedly simplifies connection, setup and player handling, but just means you write more code in order to deal with it's higher level of abstraction. Grants no performance benefits. Does not simplify the complex bit (the compiling and extrapolation of data), only the bits which are easy anyway (if you can share data between players, you can share player names too!).

TCP/IP: Extremely simple, multi-purpose, stable. Must do your own game initialisation, but you will still be doing some initialisation with Direct Play anyway. The complex bit is exactly the same as Direct Play.

UDP: More complicated to get your head around initially, but once TCP is understood it's actually not that much harder, smaller packet sizes, no guaranteed delivery (unless you code it in yourself) and no packet resends of dropped packets. Once you get the idea, it works in a very similar way to TCP/IP. The complex bit from DPlay and TCPIP (sharing data) is still the same, but now there's a few more complex bits to get your head around too.

Wait a second ... what's complex about packing and unpacking the data. You can use some compression if need be to minimize the number of bytes sent and that can be done in numerous ways but essentially it's this simple ... and probably could be simpler with some optimization.

Dim incoming$( 100 )

If JoinNetGame( GetWord( gns\server$, 1 ), gns\ip$ )
   localNetPlayer = CreateNetPlayer( localPlayerName$ )
   Setup( "Game" )
   hosting = False
Else
   If HostNetGame( localPlayerName$ ) = 2
      localPlayerName$ = Replace( localPlayerName$, " ", "" )
      If GNET_AddServer( "YourGame", localPlayerName$ )
         localNetPlayer = CreateNetPlayer( localPlayerName$ )
	 Setup( "Game" )
	 hosting = True
      Else
         RuntimeError( "Failed to Add Server!" )
      EndIf
   Else
      RuntimeError( "Failed to Create Net Game!" )	
   EndIf
Endif

Sending Player ...
packet$ = X + " " + Y + " " + Z
SendNetMsg(4, packet$, localNetPlayer, 0, False )

Receiving Player ...
While RecvNetMsg()

   Select NetMsgType()
      case 4
         PositionEntity( otherPlayer, GetWord$( NetMsgData$(), 1 ), GetWord$( NetMsgData$, 2 ), GetWord$( NetMsgData$, 3 ) )

   End Select

Wend

;====== GET WORD ==========================================================

Function GetWord$( message$, wordNum )

	For i = 1 To 100
		incoming$(i) = ""
	Next

	i = 1
	part = 1
	incoming$( part ) = Mid( message$, i, 1 )
	i = i + 1
	While i <= Len( message$ )
		While ( Mid( message$, i, 1) <> " " )
			incoming$( part ) = incoming$( part ) + Mid( message$, i, 1 )
			i = i + 1
			If i > Len( message$ )
				Exit
			EndIf
		Wend
		If Mid( message$, i, 1 ) = " "
			i = i + 1
			part = part + 1
			incoming$( part ) = Mid( message$, i, 1 )
			i = i + 1
		EndIf
	Wend
	
	Return incoming$( wordNum )

End Function

;==========================================================================

Everyone probably uses some different compression techniques. Personally, I've seen NAN's come about because of some associated with BlitzPlay so I've written my own optimization routines especially for floats. Overall though sending the data back and forth isn't difficult. I suppose TCP really isn't much worse except you're dealing with a stream. Perhaps let me see how you handle it.

Personally I dont struggle to compose a string or stream of data, but it is one of the more 'complicated' aspects of coding multiplayer as I see it, I believe it is more than anything else what confuses programmers new to multiplayer. It isn't just about the technical aspects of composing the data, but also choosing what data to send, which can be a pitfall for those doing their first network game.

I've not considered compression before for network packets tbh, I always considered that it would cost more time in processing than it would save in data transmission. I do optimise where possible, I combine some data to a binary mask and I send data as bytes & shorts instead of floats, but the .zip style compression routines i've worked on in the past just wouldn't be viable in realtime I feel.

What methods do you use to compress data Jeremy? I never really thought about choosing the datatype to send as compression (ie: sending an int variable that ranges from 0-100 as a byte) tbh, just common sense, is this want you meant or do you literally compress it with a mathematical operation?

i think it would be quite easy for someone to put together an example FPS, say a 4 player game thats well comented. just to show how its done ;O)

how much would one of you charge for a 4 player example with good comenting or a tutorial with example code?

better still it would be very useful to alot of blitz users if someone wrote a detailed tutorial on the subject.

Jeremy: i wpuld have to agree with banshee, i am getting my head round the date transfer part but im still not sure what info to send and what to leave out.

all this is most helpful

Pete

Pete have you seen this (by Jeremy I think)

http://blitzbasic.com/codearcs/codearcs.php?code=1149

opps! yeah i had'nt really looked at it because i didnt know what gnet was at the time. ill give it a good read. i did play ricky smiths mod of this with bots.

there isnt any coments though? but ill try and work out what everything does.