Networking for Dummies?
Blitz3D Forums/Blitz3D Programming/Networking for Dummies?
| ||
| It's time for me to look into multiplayer networking over a lan (it doesn't need to run over the internet for now, trust me on this), but I know nothing about network protocols, so... Blitz implements DirectPlay - that looks pretty comprehensive. So do I even need to bother looking at the TCP or UDP commands? Can someone explain simply the effective reasons for having three different systems. I guess the most complicated thing I will need to do is (predictably) alert each PC as to the movements of players on the other PCs. Thanks. |
| ||
| What systems are you referring to? Am I correct in saying that DirectPlay can use TCP/IP or IPX protocols (as well as modem-to-modem and serial, I think)? |
| ||
| 'What systems are you referring to?' The 3 systems that Blitz implements: DirectPlay, TCP, UDP. For simple multiplayer connectivity over a lan is DirectPlay enough? Do I need to bother with TCP or UDP? |
| ||
| It depends on how fast you need it to be. If you're just sending a few bytes, like just the X,Y position of an object, than DirectPlay is fine. However, if you plan on sending larger amounts of data back and forth, than you should definately go with UDP. The only drawback to using UDP is that you cannot assume that every message you send will arrive. TCP is usually used for web protocols like HTTP and SMTP, but it would work for a game as well. TCP packets will always arrive at their destination, but are a little slower than UDP. |
| ||
| TCP is connection-oriented. every packet has a confirmation UDP is connectionless.. it is a "best-effort" protocol. |
| ||
| John, Save the heartache and get BlitzPlay Pro 2 which uses UDP. It has some really excellent features, and allow you to just get the game sorted, rather than worry about all the other networking aspects. I had a simple cube in a maze game working within a day over a network on a client/host basis, based on Surreal's already given host and client programmes. The other neat trick is the fact you can run stuff on one machine as long as it has a network connection. Therefore I can run a Host and a couple of Clients on one PC to check it all works okay, before I get a second PC set up. Check out the info available from Surreal for BP, if you don't want to spend too much in case it's not what you want, then the lite version is very reasonably priced too. IPete2. |
| ||
| BlitzPlay is great. I used it for True-Vol which sends some pretty massive amounts of info, and it has packet reliability. It was also much faster than DirectPlay. |
| ||
| ..the lite version is very reasonably priced too I'd say free is fairly reasonable, yes. |
| ||
| LineOf7's Yes so would I! lol, ha ha ha! I just bought the full version (Pro) and didn't check the lite version price - sorry. IPete2. |
| ||
| Thanks to you all - a nice, simple explanation. And of course you're right. It makes sense to use someone else's already tested work :) |
| ||
| For $15 I'll let you use the code to my tank attack game which has very good and easy to understand networking code that is built on top of BlitzPlay Pro. (You'll need Blitzplay Pro to make it work.) Don't expcet tons of support, but you shouldn't need it anyhow cause my code is nicely formatted and commented. Here's a free sample: Disclaimer: BP Pro changes a lot, so code may require minor updating to work with new versions of Blitzplay. You also won't be able to compile the code without the shadow, gui and particle systems it requires, which are not free. This is for learning how a real networking game is built. Not so you can compile a free version of my tank game to play around with. :-) |
| ||
; ------------------------------------------------------------------------------------------------------------------- ; This subroutine gets input from the net and performs actions based on it. ; ------------------------------------------------------------------------------------------------------------------- .Get_Network_Input ; Update the network. BP_UpdateNetwork() ; Parse the messages. For Msg.MsgInfo = Each MsgInfo Select Msg\msgType Case BP_PLAYERHASJOINED NET_PlayerHasJoined(Msg) Case BP_PLAYERINGAME NET_PlayerInGame(Msg) Case BP_PLAYERHASLEFT NET_PlayerHasLeft(Msg) Case BP_HOSTHASLEFT NET_HostHasLeft(Msg) Case BP_PLAYERWASKICKED NET_PlayerWasKicked(Msg) Case BP_PLAYERWASBANNED NET_PlayerWasBanned(Msg) Case 1 NET_ClientPositionUpdate(Msg) Case 2 NET_ChatText(Msg) Case 3 NET_WeaponFire(Msg) Case 4 NET_HealthUpdate(Msg) Case 5 NET_TeamChange(Msg) Case 6 NET_PlayerDataRequest(Msg) Case 7 NET_PlayerDataUpdate(Msg) Case 8 NET_StartGame(Msg) Case 9 NET_GameInProgress(Msg) Case 10 NET_ClientStartedGame(Msg) Case 11 ; PositionUpdate packet broadcast request from client. NET_BroadcastGameplayPacket(Msg, 1) Case 12 ; WeaponFire packet broadcast request from client. NET_BroadcastGameplayPacket(Msg, 3) Case 13 NET_PowerupTouchedByPlayer(Msg) Case 14 NET_PowerupSpawned(Msg) End Select ; Delete the message now that we've dealt with whatever was in it. Delete Msg Next |
| ||
| One last note. There's a lot of stuff you may not have thought of yet which my code would show you how to do best. Things like handing computer players on the same server as regular players, and remote players with the same code as local players. And how to minimize network traffic with simple methods to a level that even a 56K modem can be a server for 16 players at once. |
| ||
| Well, it sounded like a good offer, except for: a) $15 for wrapper code b) the need to buy BlitzPlay Pro c) the need to buy your 'shadow, gui and particle systems it requires, which are not free' ...the problem being that they might be slightly at odds with my own shadow, gui and particle systems. But thanks for the offer anyway. |
| ||
| You don't HAVE to buy my shadow and particle systems to LOOK at the networking code and LEARN from it. :-) And I can't give away BP Pro, it's not mine to give away. :-) But I can reccomend it highly! It's HUGE. Would require a ton of work to implement everything it does, yourself. Well worth purchasing! And hey, I put a lot of work into that code. :-) It's not a wrapper. It's to learn from. But if you want to make a lot of mistakes and spend weeks asking people how to optimize your networking code and going over hundred of bugs in the process... :-) I seriously considered giving it away free, but I don't want someone releasing a clone of my game that is nearly identical before I release it myself. I already released some code to make a ball bounce around and I see some folks have made similar games to my boing game before that got done. :-) Also, it's dangerous to release networking code cause people can then hack your game more easily and make it no fun to play online. So by charging I can at least limit the number of people who see it to a small number. :-) But hey, your loss. :-) Oh and "the problem being that they might be slightly at odds with my own shadow, gui and particle systems." I only meant that to compile and run the game as is you'd need those. You can't just take the networking code as is and expect it to work with any old game. It's to learn from, not to take whole hog and plug into something else. :-) The networking functions of the game don't require those systems at all. But they do call functions that do use those things just because those functions are what do the gameplay. |
| ||
| Ah, I understand what you're getting at. Thanks for the offer. Can I put you on hold for a while? I _must_ get the rest of the product finished (final character voice recordings [hey, Mum! the mike's on, now!]) and I've still got the music to write. When as a single player it's down and solid then I can afford time to look at networking/multiplayer, though I do suspect that this will be one of the first questions I'll be asked if I go out to try and sell it. Anyway, cheers, sswift, and thanks for the offer. |
| ||
| Sure, and the offer is open to anyone. I just don't want thousands of copies of it out there. :-) |
   |