Client-Server
Client-Server
Guten Tag allerseits,
Ich möchte hier nur mal ein paar Denkanstöße, Ideen oder Erfahrungen sammeln.
Mich interessiert mal wie man ein Multiplayer-Spiel programmiert....nur erstmal so, rein interessehalber.
Habt ihr dazu vlt irgend welche Infos/Erfahrungen/Tipps/Tutorials/Pdfs/etc...?
Gruß
Ich möchte hier nur mal ein paar Denkanstöße, Ideen oder Erfahrungen sammeln.
Mich interessiert mal wie man ein Multiplayer-Spiel programmiert....nur erstmal so, rein interessehalber.
Habt ihr dazu vlt irgend welche Infos/Erfahrungen/Tipps/Tutorials/Pdfs/etc...?
Gruß
- dot
- Establishment
- Beiträge: 1745
- Registriert: 06.03.2004, 18:10
- Echter Name: Michael Kenzel
- Kontaktdaten:
Re: Client-Server
Ich würde mal sagen das hängt extrem von der Art des Spiels ab...
Re: Client-Server
Dann sagen wir mal es ist so eine art Shoter wo man durch höhlen fliegt und mit oder gegen andere spielen kann.
- dot
- Establishment
- Beiträge: 1745
- Registriert: 06.03.2004, 18:10
- Echter Name: Michael Kenzel
- Kontaktdaten:
Re: Client-Server
Und gegen wie viele andere? ;)
- xq
- Establishment
- Beiträge: 1589
- Registriert: 07.10.2012, 14:56
- Alter Benutzername: MasterQ32
- Echter Name: Felix Queißner
- Wohnort: Stuttgart & Region
- Kontaktdaten:
Re: Client-Server
Also Actionspiel.
Auf jeden Fall mit einer UDP-Library arbeiten (ENet, Lidgren3, ...) damit du realiable und unrealiable Pakete hast (wichtig für schnelle Übertragung, wenig Delay)
Grundregel: Übertrage so wenig wie möglich. Tricksen ist aber auch nicht immer gut.
Der Server sollte ab einer gewissen Menge bewegter Einheiten(hängt vom Spiel ab, bei 1-20 is es imho Wurst) eine Art Culling betreiben und nur an die Clients schicken, für welche die Information auch relevant sein soll.
Du solltest für jeden Spieler eine eineutige ID definieren (obviously), welche dann events verschickt
Was auch noch ganz nützlich ist: Solange der naive Ansatz geht, mach ihn auch :D
Auf jeden Fall mit einer UDP-Library arbeiten (ENet, Lidgren3, ...) damit du realiable und unrealiable Pakete hast (wichtig für schnelle Übertragung, wenig Delay)
Grundregel: Übertrage so wenig wie möglich. Tricksen ist aber auch nicht immer gut.
Der Server sollte ab einer gewissen Menge bewegter Einheiten(hängt vom Spiel ab, bei 1-20 is es imho Wurst) eine Art Culling betreiben und nur an die Clients schicken, für welche die Information auch relevant sein soll.
Du solltest für jeden Spieler eine eineutige ID definieren (obviously), welche dann events verschickt
Was auch noch ganz nützlich ist: Solange der naive Ansatz geht, mach ihn auch :D
War mal MasterQ32, findet den Namen aber mittlerweile ziemlich albern…
Programmiert viel in Zig und nervt Leute damit.
Programmiert viel in Zig und nervt Leute damit.
Re: Client-Server
Weiß nicht genau. Vlt so maximal 8...? Dachte das kann man Variabel halten.dot hat geschrieben:Und gegen wie viele andere? ;)
Auf jeden fall nicht unbegrenzt.
Und wie läuft das alles so ab?
Der server schickt immer ein update der scene/welt an die Server und diese übernehmen dann nur das zeichnen und reagieren auf userInput und die clients schicken dann nur relevante änderung des spielers an den server?
Wer übernimmt zb die kollisionserkennung und ähnliches?
- xq
- Establishment
- Beiträge: 1589
- Registriert: 07.10.2012, 14:56
- Alter Benutzername: MasterQ32
- Echter Name: Felix Queißner
- Wohnort: Stuttgart & Region
- Kontaktdaten:
Re: Client-Server
Die Clients schicken generell mal "Dinge" an den Server (bei Actionspielen würde ich Positionen verschicken, der Server prüft dann für Plausibilität und schickt dann das Update an die anderen Teilnehmer weiter, welche dann die Positionen sinnvoll interpolieren)
Mit Kollisionen, Treffern, usw würde ich genauso verfahren, da du beim Client ein ordentliches Spielgefühl haben willst und nicht dass erst der Treffer nach 2*$ping Zeit auftaucht.
Also Spiel sowohl auf Server als auch auf spielendem Client simulieren und dann den Server bestimmen lassen, ob das jetzt auch alles in Ordnung ist.
Mit Kollisionen, Treffern, usw würde ich genauso verfahren, da du beim Client ein ordentliches Spielgefühl haben willst und nicht dass erst der Treffer nach 2*$ping Zeit auftaucht.
Also Spiel sowohl auf Server als auch auf spielendem Client simulieren und dann den Server bestimmen lassen, ob das jetzt auch alles in Ordnung ist.
War mal MasterQ32, findet den Namen aber mittlerweile ziemlich albern…
Programmiert viel in Zig und nervt Leute damit.
Programmiert viel in Zig und nervt Leute damit.
- Chromanoid
- Moderator
- Beiträge: 4273
- Registriert: 16.10.2002, 19:39
- Echter Name: Christian Kulenkampff
- Wohnort: Lüneburg
Re: Client-Server
Ganz interessante Serie über Multiplayer-Spieleentwicklung:
Part I: Client Side of 64 Network DO’s and DON’Ts for Game Engine Developers
Part IIa: Protocols and APIs of 64 Network DO’s and DON’Ts for Game Engine Developers
Part IIb: Protocols and APIs (continued) of 64 Network DO’s and DON’Ts for Game Engine Developers
Part IIIa: Server-Side (Store-Process-and-Forward Architecture) of 64 Network DO’s and DON’Ts for Game Engines
Part IIIb: Server-Side (deployment, optimizations, and testing) of 64 Network DO’s and DONT’s for Game Engines
Part IV: Great TCP-vs-UDP Debate of 64 Network DO’s and DONT’s for Game Engines
Part V: UDP of 64 Network DO’s and DON’Ts for Game Engines
Part VI: TCP of 64 Network DO’s and DON’Ts for Multi-Player Game Developers
Part VIIa: Security (TLS/SSL) of 64 Network DO’s and DON’Ts for Multi-Player Game Developers
Part VIIb: Security (concluded) of 64 Network DO’s and DONT’s for Multi-Player Game Developers
Part I: Client Side of 64 Network DO’s and DON’Ts for Game Engine Developers
Part IIa: Protocols and APIs of 64 Network DO’s and DON’Ts for Game Engine Developers
Part IIb: Protocols and APIs (continued) of 64 Network DO’s and DON’Ts for Game Engine Developers
Part IIIa: Server-Side (Store-Process-and-Forward Architecture) of 64 Network DO’s and DON’Ts for Game Engines
Part IIIb: Server-Side (deployment, optimizations, and testing) of 64 Network DO’s and DONT’s for Game Engines
Part IV: Great TCP-vs-UDP Debate of 64 Network DO’s and DONT’s for Game Engines
Part V: UDP of 64 Network DO’s and DON’Ts for Game Engines
Part VI: TCP of 64 Network DO’s and DON’Ts for Multi-Player Game Developers
Part VIIa: Security (TLS/SSL) of 64 Network DO’s and DON’Ts for Multi-Player Game Developers
Part VIIb: Security (concluded) of 64 Network DO’s and DONT’s for Multi-Player Game Developers
Re: Client-Server
Uff!! Sehr viel Text^^
Da hab ich einiges zu lesen.
Danke erstmal.
Da hab ich einiges zu lesen.
Danke erstmal.
Re: Client-Server
Ich fand die Artikelserien von Glenn Fiedler immer sehr hilfreich:
http://gafferongames.com/networking-for ... ogrammers/
Der hat auch jede Menge zu Physik und wie man Echtzeitphysik in Netzwerkspielen handhabt.
http://gafferongames.com/networking-for ... ogrammers/
Der hat auch jede Menge zu Physik und wie man Echtzeitphysik in Netzwerkspielen handhabt.