I want to make Multiplayer FPS that using
irrlicht engine .I want to ask admin that
this engine is provide Multiplayer support ?
I think using irrlicht to make my project-That
is Multiplayer FPS game.
Question about Multiplayer?
irrlicht is a graphics engine NOT a game engine, hence there is neither multiplayer nor audio support.
Make your own using HawkNL or Rakknet.
Make your own using HawkNL or Rakknet.
Raw data for raw nerves
My main PC: Athlon XP 2800+, 512MB RAM, ATI Radeon 9700 Pro 128MB, Win2k SP4
My secondary PC: Pentium III 500 Mhz, 256MB RAM, TNT2 64, Gentoo Linux
My main PC: Athlon XP 2800+, 512MB RAM, ATI Radeon 9700 Pro 128MB, Win2k SP4
My secondary PC: Pentium III 500 Mhz, 256MB RAM, TNT2 64, Gentoo Linux
Depending on how you want it designed, it might be fun to write your own. More modern multiplayer networks (for FPS style games specifically) have network setups that allow the server to move backwards in time through the events in its memory and judge when person A shot person B. There is also the half life type where the client judges when something happens, and the server has no choice but to trust them. its why when you play counter-strike, people can shoot at you from across the map, hell they dont even need to be facing you. The most secure method (but rarely used) is simply relaying your mouse and keyboard movements to the server and letting the server decide whats going on.
When creating the packet design, the best way (that ive found) is to design the packet like this:
(WORD) Packet Length
(BYTE) Packet ID
(...) Packet Data
Giving the packet length first (including the header length, which is 3 bytes), allows you to account for broken packets, and the packet id lets you easily decide what the rest of the packet contains. I suggest TCP for this, but a UDP model isn't entirely out of reach, infact it can be better if your wanting to handle low to moderate latency.
If you happen to choose UDP, make sure to send 3 of each packet, and have the receiving end (client or server, whichever it may be) use the most common in the 3 that are sent. UDP doesn't need a constant connection, but the tradeoff is that random bytes in the packet, or even an entire packet can be lost in the transfer. Make sure the server keeps track of whats going on, and kicks anyone off who gets out of sync with the rest of the players. Aside from that.
A variation of the UDP model is to not use a server at all, and have the players all linked only to eachother. This is more complicated client side though, the client would need to keep track of what each player would see, and go through each players mouse and keyboard movements in real-time.
A TCP model is probably easier. Anyway, sorry for typing a bunch of pointless crap, I needed to kill some time and i'm sure it was educational for some of you. =P
EDIT: With a UDP model, it would also be wise to have a packet send a checksum of itself, incase there is the rare chance that none of the 3 packets sent are correct.
When creating the packet design, the best way (that ive found) is to design the packet like this:
(WORD) Packet Length
(BYTE) Packet ID
(...) Packet Data
Giving the packet length first (including the header length, which is 3 bytes), allows you to account for broken packets, and the packet id lets you easily decide what the rest of the packet contains. I suggest TCP for this, but a UDP model isn't entirely out of reach, infact it can be better if your wanting to handle low to moderate latency.
If you happen to choose UDP, make sure to send 3 of each packet, and have the receiving end (client or server, whichever it may be) use the most common in the 3 that are sent. UDP doesn't need a constant connection, but the tradeoff is that random bytes in the packet, or even an entire packet can be lost in the transfer. Make sure the server keeps track of whats going on, and kicks anyone off who gets out of sync with the rest of the players. Aside from that.
A variation of the UDP model is to not use a server at all, and have the players all linked only to eachother. This is more complicated client side though, the client would need to keep track of what each player would see, and go through each players mouse and keyboard movements in real-time.
A TCP model is probably easier. Anyway, sorry for typing a bunch of pointless crap, I needed to kill some time and i'm sure it was educational for some of you. =P
EDIT: With a UDP model, it would also be wise to have a packet send a checksum of itself, incase there is the rare chance that none of the 3 packets sent are correct.
For networking, i really like http://www.sharky-x.de/zoidcom/
