spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

hm also wenn du eh dx benutzt würde ich gleich directplay nehmen. hab damit gute erfahrungen gemacht... winsock ka ;D

So von dem was ich so gehört habe soll ein riesiger Vorteil von DPlay sein das die Daten die kommen auch irgendwie automatisch bestätigt werden oder geprüft werden.

Da Stimme ich NoName zu kommt drauf an wo für du sie nehmen willst !!!

genau, wofür brauchst Du was?

Schau Dir aber auch mal die Internet-Funktionen, wie InternetConnect und InternetSendRequest usw. an.
Diese sind zwar nur unter Win mit IE ab 4.0 lauffähig, aber diese Funktionen richten sich nach der globalen IE-Einstellung des Computers.
D. h. man könnte ein Spiel bauen, welches genau wie der IE über Port 80 kommuniziert.
Also durch jede Firewall, über Proxyserver usw.

Auf der Serverseite muss mann dann den Webserver bemühen, daten zu verarbeiten und zurückzuliefern.
Aber dort gibt es ja auch unzählige Schnittstellen (PHP, ASP COM usw.)

Naja ich bin ja davon ausgegangen das es für Spiele ist in einer Art Server - Client beziehung. Aber ich habe da nicht viel Ahnung von deswegen will ich mich nicht reinreiten ;D .

Zitat von »"Jens"«

Schau Dir aber auch mal die Internet-Funktionen, wie InternetConnect und InternetSendRequest usw. an.

Mit denen würde man aber kein Netzwerk-/Internetspiel erstellen. Damit würde man vielleicht Dinge wie Online-Highscores implementieren (habe ich auch getan).

Ich persönlich finde DirectPlay 9 sehr gewöhnungsbedürftig. Meiner Meinung nach wird einem zu viel Arbeit abgenommen, sodass man kaum noch Kontrolle hat...

also, Du musst aber! ;D
Denn die Kommunikation zwischen Deinem Client und dem Server musst Du Dir ausdenken!

Dann fang einfach mit der Technologie an, die Dir die meisten veröffentlichten Beispiele anbringt.

Aber ohne "reiten" wird das wohl nicht ganz gehen.

Übrigens ist auch ein Webserver ein Server, wie jeder andere, nur dass dieser auf Port 80 lauert und dieser Port ist sogar von jedem Büro, jeder Institution erreichbar (ohne Risiko(?)).
Deshalb die Idee mit dem Webserver.

Wenn Du auf Sockets baust, musst Du den Server vollständig selber bauen.
Bei Direct Play gibt es vorgefertigte Schnittstellen (siehe SDK-Beispiele)

@David
wieso kann man mit den Internetfunktionen kein InetSpiel erstellen?
Alle möglichen Signale, wie die notwendigen Koordinaten eines Spielers, der Welt usw. können darüber abgesendet und empfangen werden.
Man muss nur am Webserver die entsprechende Webkomponente oder einfach "Webseite" erstellen. Ist ehrlich kein Problem, z. B. mit der Geschwindigkeit eines IIS :huhu: .
OK, mit Tonübertragung ist das etwas anderes...

Gut, es stimmt, der letzte würde auf die Idee mit den Internetfunktionen kommen, aber die Frage nach der besten Kommunikation stelle ich mir schon lange.
Bei einem Onlinespiel möchte ich zukünftig meinen Rechner nicht mehr offen, wie ein Scheunentor machen, sondern die Firewall so lassen, wie sie ist. Und das wollen andere auch.
Also bleibt nur noch der "normale" Standard-Webport.
Also Webserver...
Ist das ein Argument?

Für mich ist das kein Argument. Serverseitige Skriptsprachen sind garantiert zu langsam, um alle Rechenoperationen vorzunehmen, z.B. Kollisionserkennung zwischen zwei Spielern etc.. Außerdem umständlich, wenn man für den Client C++ und für den Server irgendwas anderes nehmen muss.
Und außerdem: Wie willst Du die Daten an den Server schicken? So in der Art wie hier: http://spieleserver.de/spiel.php?position=40,40&energie=100 oder wie? Und das mehrere Male pro Sekunde? Das kannst Du vielleicht bei einem Schach-Spiel machen, aber nicht bei einem Echtzeitspiel.