netzwerk spiel
-
tori1117 schrieb:
grundlagen der netzwerkprogrammierung
Dann guck dir die SOCKETS API an. Entweder Berkeley Sockets (Unix) oder WinSock (Windows). Sind beide sehr ähnlich aber halt nicht 100% gleich.
Das ist die grundlegendste Sockets API die es überhaupt gibt. Da lernst du wie das mit Netzwerk überhaupt funktioniert. Andere APIs wie Boost.ASIO oder diverse Sockets Klassen in anderen Sprachen sind im Prinzip nur Wrapper um die Sockets Funktionen. Die grundlegenden Konzepte bleiben die selben.
Was sich natürlich (z.T. massiv) unterscheidet ist wie die einzelnen Funktionen heissen und aufgerufen werden. Speziell wenn es um asynchrone Aufrufe geht.
Du kannst natürlich auch eine High-Level API ala Boost.ASIO, die POCO Netzwerkklassen, Qt Netzwerkklassen etc. verwenden. Wie gesagt, die grundlegenden Konzepte sind gleich. Allerdings kann es etwas schwierig sein da direkt einzusteigen, weil einem eben die ganzen Grundlagen fehlen. Je nachdem wie gut diese Grundlagen in der Doku der High-Level API dokumentiert kann das dann eine kleine oder grössere Hürde sein.
ps: Ich würde dir aber empfehlen auf jeden Fall die ersten Schritte zu machen ohne dabei ein Spiel zu programmieren. Beides zusammen ist ziemlich sicher zu viel, dann kommst du nicht weiter, verlierst den Spass und schmeisst es irgendwann ganz hin.
Mach lieber erstmal einfache kleine Test-Programme. Ne kleine Konsolen-Mode Serverapplikation und nen ebenso kleinen Konsolen-Mode Client dazu, und damit ein paar Daten rumschicken. Nur zum Ausprobieren.
Dann kannst du da Schrittweise mehr Funktionen einbauen. Und wenn du das Gefühl hast das einigermassen intus zu haben, dann mach ein kleines Test-Projekt für ein Spiel. Mit irgend einer einfachen Grafik- oder Game-Engine (SFML, Cinder, ...). Und wenn du das wiederrum einigermassen gut intus hast, dann kombiniert die beiden.
-
danke für die tipps
-
Vor den grundlegenden Sockets ( z.b. WinSock ) sollte man keine Angst haben. Hatte ich auch, hab mich lange gesträubt, mich dann aber überwunden und mich damit beschäftigt. Es gibt diverse Beispielsourcen im Netz, die dir helfen können, den Umgang mit Sockets zu erlernen. Ist wirklich nicht schwer, aber man sollte schon einige Erfahrungen in C++ und C haben.
D.h. lerne erstmal C++ und auch C und dann beschäftige dich mit Grafik und Sockets und evtl. auch Threads und allem was dazu gehört. Spannend werden Sockets auch erst dann, wenn man effizient höhe Datendurchsätze bewältigen will
-
Marthog schrieb:
Das sehe ich nicht so. Es kann sehr helfen, ein Ziel als Motivation zu haben, man sollte sich aber bewusst machen, dass es nichts wird und sollte nicht zögern, zwischendurch alles wegzuschmeißen und mit dem neuen Wissen neu anzufangen und man sollte auch bereit sein, das ganze Projekt irgendwann aufzugeben.
Die Realität sieht leider anders aus. Schau dir ein beliebiges Spieleentwickler-Forum an: Sehr viele Anfänger können kaum C++ und scheitern andauernd an trivialen Problemen aufgrund mangelnder Sprachkenntnisse. Sie verschwenden tagelang mit Debugging, Experimenten, Warten auf Antworten im Forum -- aber Hauptsache, sie haben ein wenig Zeit mit dem Lesen der Theorie "gespart". Traurigerweise sieht es bei einigen Fortgeschrittenen nicht mal viel besser aus: C++-Stil der 90er, kein Plan von RAII, und so fort... Die Argumentation ist jeweils "es reicht doch, um Spiele zu machen".
Eine Bibliothek wie SFML kann man nicht vernünftig benutzen, wenn man nicht wenigstens die C++-Grundlagen beherrscht. Klar muss man dazu nicht jedes Detail der Sprache kennen und lernt während der Entwicklung eigener Projekte weiter.
Marthog schrieb:
Von komplizierten Themen, wie Netzwerke rate ich auch ab
Es stimmt, dass Netzwerkprogrammierung relativ viele Low-Level-Kenntnisse erfordert, die bei Spielen anfänglich umgangen werden können. Dennoch wird die Komplexität von Spielen oft unterschätzt, gerade wenn man zuvor nie etwas in die Richtung gemacht hat. Siehe dazu auch But can you make Pong?
-
Seien wir mal ehrlich, ein Grossteil der Komplexitaet ruehrt doch daher, dass TCP konzeptuell einfach scheisse ist.
-
Kellerautomat schrieb:
Seien wir mal ehrlich, ein Grossteil der Komplexitaet ruehrt doch daher, dass TCP konzeptuell einfach scheisse ist.
Stimmt. Die Wissenschaftler hinter TCP haben das Protokoll primär aus Langeweile derart komplex gestaltet. Ist wahrscheinlich deswegen, dass sich TCP in der Welt kaum bewährt hat
-
Lies dir einfach mal die Beschreibung von SCTP durch, dann wird dir erst bewusst, wie kaputt das Internet ist.
-
Natürlich gibt es etliche Probleme, gerade im Bezug auf Sicherheit. Aber ich wage zu bezweifeln, dass ein Protokoll, welches dies alles zusätzlich berücksichtigt, viel simpler aufgebaut wäre.
-
Darum gehts nicht. Niemand will einen reinen Datenstrom, das macht einfach keinen Sinn. Nicht mal bei FTP.
-
eventuell SFML, liefert 2D, Sound und Netztwerk
-
Kellerautomat schrieb:
Niemand will einen reinen Datenstrom, das macht einfach keinen Sinn.
Was willst du denn sonst? Die Datentypen mitschleifen, die dann vom Layer drunter geparst werden müssen?
Außerdem ist TCP dafür da, dass die Daten korrekt ankommen. Wenn das nicht gewollt ist (Stichwort Streams) oder reicht, dann nimmt man halt was anderes (UDP zum Beispiel).
-
nwp3 schrieb:
Kellerautomat schrieb:
Niemand will einen reinen Datenstrom, das macht einfach keinen Sinn.
Was willst du denn sonst? Die Datentypen mitschleifen, die dann vom Layer drunter geparst werden müssen?
Außerdem ist TCP dafür da, dass die Daten korrekt ankommen. Wenn das nicht gewollt ist (Stichwort Streams) oder reicht, dann nimmt man halt was anderes (UDP zum Beispiel).http://en.wikipedia.org/wiki/Head-of-line_blocking
http://en.wikipedia.org/wiki/SCTP
-
Die bekannteste API dafür wird wohl Boost.Asio sein.
Nein, ist es nicht.
Ansonsten: http://beej.us/guide/bgnet/
-
Nexus schrieb:
Kellerautomat schrieb:
Seien wir mal ehrlich, ein Grossteil der Komplexitaet ruehrt doch daher, dass TCP konzeptuell einfach scheisse ist.
Stimmt. Die Wissenschaftler hinter TCP haben das Protokoll primär aus Langeweile derart komplex gestaltet. Ist wahrscheinlich deswegen, dass sich TCP in der Welt kaum bewährt hat
Der TCP Standard ist per se nicht kompliziert. Er ist nur schlecht. Gut genug um überlebt zu haben, aber schlecht genug um ordentlich zu nerven. Und warum der Schluss "ist voll erfolgreich, muss also gut sein" totaler Unsinn ist muss ich hoffentlich nicht erklären.
Zurück zu TCP... das komplizierte bei TCP ist nicht Absicht bzw. im Standard so kompliziert vorgegeben. Es sind die ganzen Workarounds/Optimierungen/... die nötig sind um die vielen Schwachstellen von TCP zu umschiffen. Und das natürlich ohne die Kompatibilität zu älterer Hardware zu beeinträchtigen.
Das ganze Window-Scaling ist furchtbar, Congestion-Control ist ne eigene Wissenschaft. Die (vorgeschriebene!) State-Machine für Connections ist auch totaler Käse (Beispiel: wenn man am Server TIME_WAIT vermeiden will muss immer der Client auflegen -- was z.B. nicht mit dem Auflegen des Servers nach Ablauf eines Timeouts vereinbar ist).
