Mr_Emre_D hat folgendes geschrieben :

Zum 2d-Shooter: Warum nicht..?

wie beides?
Entweder Client schickt ID, Server schickt verlangte Daten
oder Server schickt Daten alle x Millisek

ODER Auf Abfrage und falls Client sich x-Sek nicht gemeldet hat auf Connection prüfen

Ich hätte da dann noch die Frage:

Wann soll ich "wie" abfragen und senden?

(Client (Server weiß ich inzwischn))
Beim Client hatte ich gedacht, dass z.B. auf "w" an den Server "nach oben bewegen" gesendet wird, der Server verarbeitet dass dann.. auf abfrage sieht man dann ja die Änderung, dies würde dann zu laggs führen oder?

Wenn ich z.B. ALLES in die "onread"-procedure packe, also am ende der onread procedure ein "neues packet anfordere" dann könnte ein verlorenes Packet zu kommunikationsstillstand führen...
Wie soll ich also "regelmäßig" befehle anfordern, ohne ein Overstack oder sonstiges zu erreichen, also warten bis ein Datenpaket angekommen ist

Zunächst einmal hat, sofern du es benutzt, TCP Sicherheitsmechanismen eingebaut, damit Pakete nicht verloren gehen.
Das Einzige, was geschehen kann, ist, dass der Empfangs-Stack überläuft - dann aber gibt der send() Befehl weniger zurück, was bedeutet, dass nicht alles geschickt werden konnte! Es ist ja ein Streaming-Protokoll.

Weiters würde ich das Empfangen vom Verarbeiten der Daten trennen. Du empfängst den Datenstrom, haust es synchronisiert auf ne Queue oder was auch immer für ne Datenstruktur. Ein anderer Thread verarbeitet dann diese Queue. Damit sorgst du, dass der Receiving-Thread nicht allzu sehr stockt.

Achja, wie zuvor schon gesagt - Pakete gehen nicht verloren, jedoch, so wie ich mal hier und da beschrieben habe, kommen Pakete nicht genauso an, wie du sie abschickst!
Sprich, wenn du 100 bytes abschickst (und dir der send() Befehl auch 100 zurückliefert, was bedeutet, dass wirklich 100 bytes abgeschickt worden sind), dann kann es passieren, dass du per recv() 100 bytes empfängst oder auch z.B. 2x50er oder 1x50, 2x25er oder 10*10er Pakete, oder oder oder... das wirste übrigens lokal selten feststellen bemerken; hat mich damals einige Nerven gekostet, bis ich das rausgefunden habe!
Beachte das bitte!

Mr_Emre_D hat folgendes geschrieben :

Sprich, wenn du 100 bytes abschickst (und dir der send() Befehl auch 100 zurückliefert, was bedeutet, dass wirklich 100 bytes abgeschickt worden sind), dann kann es passieren, dass du per recv() 100 bytes empfängst oder auch z.B. 2x50er oder 1x50, 2x25er oder 10*10er Pakete, oder oder oder... das wirste übrigens lokal selten feststellen bemerken; hat mich damals einige Nerven gekostet, bis ich das rausgefunden habe! Beachte das bitte!

genau, deshalb wollte ich abfragen, wann das paket vollständig ist und es dann verarbeiten und dann neu "abfragen"...
das ganze in threads zu trennen halte ich ebenfalls für sinnvoller... aber ich überlege, ob es nicht sehr "laggy" ist, wenn eigentlich NICHTS über den Client läuft...
im Client stehen zum spiel dann eigentlich nur pro taste 1 befehl
z.B.

der Server würde dieses "springen" dann umsetzten und bei der näcjhsten Abfrage entsprechend die neue Position liefern.. nur wenn man das umsetzt, wirkt es als wenn das Spiel immer "nachzieht"..
bis jetzt hat der Client keine Ahnung zu welchem Spieler er eigentlich gehört.. er sendet nur wohin "sein" spieler sich bewegen soll....
Der Server ordnet dem Socket (Client/Spieler) dann entsprechend die Daten zu...

Dadurch will ich das ganze "hacksicherER" machen...

In der Praxis ist es afaik so, dass, wenn du w drückst und du den Befehl an den Server schickst, du deine Positionsupdates weiterhin machen darfst und sollst, damit
dieser Lag nicht entsteht.
Der Server wrid dir früher oder später (im ms Bereich) antworten und dann gleichst du ab, bzw setzt die Position neu, sofern sie zu sehr von der Antwort abweicht!

Btw dein Code ist voller Fehler:
1. du erstellst ein Stream, den du nur bei Fehler (except) freigibst -> Speicherleck
2. du erstellst IMMER ein Stream, auch wenn nichts zu schicken ist
3. du schickst die Daten einfach so, ohne auf meine Nachricht zuvor Rücksicht zu nehmen! (Edit: Ok, kann sein, dass das kein Problem ist, da evt. SendStream() das intern berücksichtigt; ich habe da mit eher Low-Level Komponenten gearbeitet)

1. SendStream gibt den Stream nach senden soviel ich weiß frei!, somit muss ich nur, falls das nicht geklappt hat den stream freigeben
2. Es wird sonst ein "ja, ich bin noch anwesend und lagge nicht"-Stream übermittelt... hierdurch kann die Ping über den Server errechnet werden und es gibt einen "anwesenheitsnachweis" (ja ok, aus meinem Beispielcode geht das nicht hervor)
3. Du meinst, dass man das in kleinere Packete (JA mit C... packtet = Datenpaket) schickt? darum kümmert sich SendStream

p.S.: ich werde mit den Standart-Delphi- Internet-Komponenten ( TClientSocket und TServerSocket ) arbeiten

Mr_Emre_D hat folgendes geschrieben :

In der Praxis ist es afaik so, dass, wenn du w drückst und du den Befehl an den Server schickst, du deine Positionsupdates weiterhin machen darfst und sollst, damit dieser Lag nicht entsteht. Der Server wrid dir früher oder später (im ms Bereich) antworten und dann gleichst du ab, bzw setzt die Position neu, sofern sie zu sehr von der Antwort abweicht!

ok, dass heißt der Client muss wissen welche Position zu ihm gehört... somit muss "im" Server noch einiges an "hack-verteididung" eingebaut werden... wie z.B. Zeit-Check (sendet ein Client zu schnell ?, wenn ja dann kick because hacking

Der Server muss einfach der Master sein. Der Client sendet Daten an den Server (z.B. Stoß mit Stärke XY in Richtung XY) und zeichnet selbst als ob das so in Ordnung wäre weiter. Der Server prüft diese Daten auf Plausibilität und schickt die eigenen berechneten Positionen zum Client. Der Client prüft nun, ob diese von der Anzeige zu sehr abweichen, wenn ja, korrigiert er die eigene Anzeige mit den Serverdaten.

das hieße,
1. Der Client muss wissen welche Positionsdaten zu ihm gehören ! (ok...)
2. Also: Client sendet vom ihm veränderten positionsdaten an Server... UND setzt die bei sich schon
3. Server prüft auf Richtigkeit, übernimmt/ passt sie an
4. Server schickt an Client.. Client überprüft ob eigene "schon neu veränderte pos" stimmen kann

aber wie soll ich das mit den anderen Clients machen?
soll ich die Laufrichtung dann mit übertragen, damit jeder Client es für sich "errschäten" kann?
und z.B. beim egoshooter, wie soll man da das "treffen" veranstalten.. denn
0.1 Jeder Client hätte unterschiedliche Pos-Daten vom Getroffenen.. (aber nahe beinander)
0.2 Wenn der Client einfach "Person X getroffen" an Server schickt, wäre es zu leicht zu hacken...
0.3 Wenn die Clients nur die vom Server zur verfügung gestellten Daten der anderen User nutz und nicht abändert
hat dies
0.3.1 Lags
0.3.2 fehler
zur folge..
fehler insofern, dass man auf Person x schießen kann, weil die pos auf dem Server noch nicht geupdatet wurde...

Das Senden/empfangen habe ich verstanden, aber die grundzuüge was Server, was Client macht muss ich noch verstehen.. soll ich dafür einen Extra thread machen?

IhopeonlyReader hat folgendes geschrieben :

1. Der Client muss wissen welche Positionsdaten zu ihm gehören ! (ok...) 2. Also: Client sendet vom ihm veränderten positionsdaten an Server... UND setzt die bei sich schon 3. Server prüft auf Richtigkeit, übernimmt/ passt sie an 4. Server schickt an Client.. Client überprüft ob eigene "schon neu veränderte pos" stimmen kann

Richtig, wobei weniger eine einzelne Position interessant ist als vielmehr die geplante Bewegung. Denn die kann beim Client dann ablaufen, der Server berechnet das gleiche und im Idealfall kommt das gleiche heraus, wenn vom Server die Antwort kommt.
Der Server schickt ja auch keine Einzelpositionen von bewegenden Zielen, sondern deren Bewegungsdaten. Die Positionen einzeln zu schicken wäre viel zu aufwendig und würde stark laggen.

IhopeonlyReader hat folgendes geschrieben :

aber wie soll ich das mit den anderen Clients machen? soll ich die Laufrichtung dann mit übertragen, damit jeder Client es für sich "errschäten" kann?

Der andere Client schickt das ja zuerst an den Server und der weiter. Die Berechnung sollte nicht lange dauert. Das heißt es bringt keinen großen Vorteil, wenn die Clientdaten ungeprüft zu anderen Clients geschickt werden, kann aber gravierende Nachteile bringen, wenn jemand cheaten will. Deshalb ist das vermutlich weniger sinnvoll.

jaenicke hat folgendes geschrieben :

Der andere Client schickt das ja zuerst an den Server und der weiter. Die Berechnung sollte nicht lange dauert. Das heißt es bringt keinen großen Vorteil, wenn die Clientdaten ungeprüft zu anderen Clients geschickt werden, kann aber gravierende Nachteile bringen, wenn jemand cheaten will. Deshalb ist das vermutlich weniger sinnvoll.

nein ich meine
Client A ---(Position + Bewegungsrichtung) --> Server
Client A setzt Position von sich
Server verarbeitet alle angekommen Informationen (prüft auf Richtigkeit etc...)
Client B fragt alle Daten ab
Server weiß, wann letzte Abfrage von Client B war, und schickt nur Veränderungen !
Server ---(Position + Bewegungsrichtung von A) ---> Client B
Client B setzt Spieler A auf richtige Position und lässt ihn "weiterlaufen"

würde Client A wenn er z.B. immer abwechselnd nach links und nach rechts geht, vbei sich zwar laufen, aber beim Server kaum Änderungen eingehen und beim Client B würde Spieler A nach links gehen, nach abfrage umgesetzt werden, wieder zu einer seite gehen, wieder zurückgesetzt werden... ?

oder ist das ganze in so einem kurzen "abstand" (abfrage, senden), dass man wirklich mitkriegt, dass dauerhaft links/rechts gegangen wird?



Nebeninformation: ich habe noch nicht mit der Umsetzung angefangen ! ich wollte mir in diesem Thread eine genaue Vorstellung machen, damit ich beim programmieren nicht überlegen muss wie ich das mache, sondern direkt mit einer Qualitativ halbwegs hohen Variante anfange.. geht nicht nur schneller, sondern ist oft auch "besser"

Ich würd ab dem 4. Punkt ein bisschen anders vorgehen:

wenn sich ein neuer Client verbindet, dann kriegt er sofort die notwendigen Daten, die er dann darstellen muss (Spielerposition usw)

der Client "fragt" nicht nach Daten; der Server leitet sie immer dann weiter, wenn notwendig - sprich wenn Client A seine Spielerposition geändert hat, so teilt er das dem Server mit; daraufhin teilt der Server allen anderen das mit, somit sind dann alle ca auf demselben Stand!

Edit: Um was für ein Spiel handelt es sich denn? (Nicht Genre; das haste mir schon bereits verraten)

Naja, wie ich bereits erwähnte, habe ich noch nicht angefangen..
Ich werde eine Karte haben, die aus 16x16 Pixel großen Feldern besteht...
Diese wird am Anfang "überprüft" etc.. Ggf. Gedownloadet.. ( warscheinlich auf einem extra anmelde Server? Damit es nicht laggt..)
Am anfang werden es nur boolean arrays sein, die angeben ob dad Feld betretbar ist oder nicht..
Die Spieler sind aber Feldunabhängig, das heißt sie können auch zwischen 2 Feldern stehen...
Ein Spieler hat ein aussehen (gibt paar zur Auswahl), und eine Waffe (haben ebenfalls alle dieselben zur Auswahl).. Bei betreten oder ändern werden diese entsprechend übermittelt..

Nun kann man per wasd oder angepasster Steuerung die eigene spielfigur Steuern und schießen...

Wenn du etwas anderes Wissen willst, formuliere deine Frage bitte antwortenorientierter.

Ein normales 2d Egoshooter halt

Hast du ne Geschichte, ne Idee hinter dem Spiel oder programmierst du nur um ein Spiel zu programmieren?
2d Egoshooter? Iwie passt das ja kaum zusammen - die Egoperspektive hat man ja bei den meisten 2d Spielen nicht - außer bei Moorhuhn. Wirds nun Moorhun-like?
Wird es evt. top-down oder eher sidescrolling?...

PS: Du stellst dir viel zu viele unnötige Fragen. Fang erst einmal an, das meiste ergibt sich sowieso. Und wenn du mal stecken bleibst, fragste eben konkreter nach. Das meiste ist eig. schon abgedeckt; technisch wars ja bisher auch kaum.

Gn8

Ups.. Ich dachte Egoshooter wäre der Oberbegriff der -Person-shooter.
Wie ich gerade nachgelesen habe, ist Egoshooter=First-Person-shooter...
Mein Spiel wird allerdings ein third- Person shooter..
Tut mir leid um die Verwirrung


Und ja vom technischen habe ich alles verstanden überlege nur, was gesendet werden muss...

So... nach vielem Planen nur noch eine offene Frage
Wenn der Server in mehreren Threads arbeitet
- Empfang-Thread der alles auf eine QueQue haut
- Sende-Thread der die "aktuellen" Daten sendet...

Nur 1. Wenn ich 2 threads haben die senden/empfangen, dann wird es sicherlich fehler geben, da ein Server das sicherlich nicht gleichzeitig kann oder?
2. Gibt es dann ja keine Thread-Proceduren (die per message aufgerufen werden) sondern ich müsste irgendwie im Execute ne dauerschleife haben, die das von Person zu Person abfragt oder? und wie ist das mit Person-disconnections? müsste dann ja so aussehen

nur habe ich noch nie mit senden/empfangen in extra threads gearbeitet.. kann man jemand helfen oder links/tutorials dazu posten?

push

Multihreating mit einem Server.. keiner ne Idee?

IhopeonlyReader hat folgendes geschrieben :

Multihreating mit einem Server.. keiner ne Idee?

Eher zu viele Ideen
Das ganze Thema ist schon etwas kompliziert und damit man sowas ordentlich machen (du hast gesagt du möchtest bevor du etwas tust möglichst viel wissen) kann, muss man ganz schön was mitbringen. Der NetCode den wir aktuell bei BitSpace verwenden ist mittlerweile die 5. Iteration verschiedener Konzepte, die ich so über die (letzten 3-4) Jahre auf die Beine gestellt (und wieder verworfen und verbessert) habe.

Ein guter Einstieg ist immer die Tutorial-Reihe von Narses. Wenn du die soweit verstanden hast, dass du zusammen mit TMessageThread z.B. einen kompletten NBFPA-Server in einen Thread verlegt bekommst, hast du schonmal viel gewonnen Das reicht dann für die ersten Spiele auf jeden Fall aus.

Zurück zum Threading.
Die Frage ist, wie viele Threads du überhaupt brauchst. Ein Thread der die ganze Zeit nur dumm rumsteht weil er nichts zu tun hat (oder viel schlimmer, weil er auf ein Lock wartet {Hausaufgabe: Thread-Synchronisation lesen; Extra Credit: Lock-Free data structures. Krasses Zeug, hilft wenn du wirklich große Dinge bauen willst} ) bringt ja eher wenig, andersrum kann ein monolithischer Serverthread auch nur eine begrenzte Zahl Clients bedienen, falls dort direkt Logik abgewickelt wird. Je nach erwarteter Client-Anzahl kann es sogar reichen, Server-Logik und Netzwerk im gleichen Thread zu haben - das wäre dann der einfache Fall, den ich oben als Anfangsaufgabe erwähnt hatte.

Wenn du dann noch etwas über Game-Networking im Speziellen lernen möchtest, hilft auch die Dokumentation der wundervollen (aber etwas teuren) Bibliothek RakNet. Dort wird auch sehr schön in technische Details gegangen, jedenfalls wenn man etwas Vorwissen mitbringt kann man sehr gut zwischen den Zeilen lesen was die intern tun. Nicht alles davon würde ich so auch machen (unter anderem bauen die TCP komplett in eigenem Code nach und verwenden nach außen hin UDP - etwas blödsinnig wenn du mich fragst, den gleichen Effekt würde man auch mit hinreichend kurzen Priority Queues erreichen, genau das tun wir bei BitSpace), aber viele Dinge besonders was die Integration in die Anwendung angeht sind durchaus sehr elegant gelöst (so gut wie das eine reine C-API halt kann )

Und wenn du das alles durch hast, sprechen wir uns wieder - oder du planst das nicht alles 100% durch und fängst einfach mal an. An Problemen lernt sich sowas mMn besser als aus Texten - du solltest nur davon ausgehen, dass dein erster Versuch nicht wirklich ideal sein wird und unter irgendwelchen Fällen (Local, LAN, WLAN, Internet, mehr oder weniger CPU-Kerne...) komplett zusammebricht. Da zeigt sich dann auch sonst die Codequalität, wenn du gut warst, kannst du den Netcode austauschen ohne den Rest einreißen zu müssen

Ich hoffe mal, das hilft dir irgendwie. Man kann auf jeden Fall viel dabei lernen
Viele Grüße,
Martok