Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

Tobiking

1x Rätselkönig

  • Private Nachricht senden

11

21.09.2003, 01:05

Eine sache ist auch das "viele" Server anbieter im Bereich von Half-Life bzw. Counter-Strike ebenfalls Webspace anbieten. Und wenn du denen den Port 80 klaust sind die garantiert nicht wirklich glücklich. Genauso denke ich mal sollte man Port 21 für FTP den auch sogut wie jeder offen hat auch nicht nutzen. Hat schon so seinen grund warum manche Ports festgelegt sind. Also warum nicht wie es jedes Spiel macht entweder den Port frei eingeben lassen und als standart z.B. wie bei Half-Life 27015 nehmen. Solange man alle Ports die benötigt werden angibt ist es kein Problem.

12

21.09.2003, 01:12

Zitat

Bei einem Onlinespiel möchte ich zukünftig meinen Rechner nicht mehr offen, wie ein Scheunentor machen

Wieso musst du deinen Rechner für die Welt öffnen um ein Spiel zu spielen? Das ist doch nur eine Frage der Implementation und deines Protokolls. Bestes Beispiel ist FTP. Passives FTP will unbedingt die Ports 1024 - 65535 offen haben. Sonst gehts nett. Aktives FTP brauch nur zwei Ports.

Also ich würd ja bei WinSock bleiben. Nicht nur das davon mehr Tutorials existieren, man hat auch die volle Kontrolle über das was man machen möchte.

Zitat

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.

Das macht das TCP/IP Protokoll auch. Entgegen zu UDP wird hier ein Byte Stream versendet und keine einzelnen Packet. Dieser Datenstrom wird dann automatisch in die Packete eingeteilt und kommen Kontrolliert auf der anderen Seite als vollständigen Datenstrom wieder an.

Außerdem, ist es sehr Interessant sich ein eigenes Protokoll aufzubauen und dann über UDP zu verschicken. Vor allem hat es den Vorteil das man sein Protokoll voll auf sein Game abstimmen kann.
Wichtig! Ich übernehme keinerlei Verantwortung für eventl. Datenverlust oder Schäden am Rechner ;D

Jens

Treue Seele

Beiträge: 117

Wohnort: Dresden

  • Private Nachricht senden

13

21.09.2003, 01:21

wirklich interessant

wer hat vonn Kollisionserkennung geredet? Das macht alles der Client!
Übermittelt werden nur Positionen und Modelarten.
Und die Kommunikation mit dem Webserver muss nicht immer über Scriptsprachen stattfinden!
Gerade die Kommunikation mit Webservern haben mir die Erfahrung gebracht, dass gerade dieser in der Lage ist, sehr viele gleichzeitige Nutzer zu verarbeiten.

Übrigens geht es nicht darum, Webspace anzubieten, sondern lediglich darum, einen Webserver zur Verfügung zu stellen, der alleine nur als Spieleserver fungiert und zwar für alle, weltweit, die durch Firewalls und Proxys schauen müssen.

Ein Webserver kann allein mit C++-Filtern auskommen. Die Kommnikation ist unwahrscheinlich schnell.
Selbst das aufrufen von fertigen COM-Komponenten in ASP-Seiten würde für diese Kommunikation ausreichen.

Port 21 ist bei (fast) jedem NICHT-Privatanwender ZU!

Wie ich die Daten zum Server schicken will:
Genau wie David es sagte, auch wenn es nach scriptKiddy aussieht ;-) Natürlich mit Sendrequest(...) und vor allen wenns mehr werden, mit SendRequestEx, in PostMethode.
Der Webserver frist es sofort und liefert durch eine entsprechende Komponente sofort die gewünschte Antwort.
1000 Requests pro Sekunde kann man insg. für alle User zutrauen. Das habe ich mal in einem Test vor 2 Jahren gesehen. Dabei wurde keine Aussage über die übertragenen Daten gemacht.
Aber meine Erfahrungen mit einem Tool, welches genau auf diese Art kommuniziert, kann weit über diese 1000 Requests durchführen mit Daten über ca. 256 Byte pro Request.
Reicht das für die Übermittlung aller Spielerkoordinaten?

Um aber auf die allererste Frage zu antworten.
Ich würde vielleicht raten, doch alles über Sockets abzuwickeln.
Sockets sind die Grundlage der IP-Netzwerkkomunikationen.
Aber es ist viel Arbeit, gerade, wenn Proxyserver dazwischenliegen usw.
Das Platform-SDK liefert aber alle notwendigen Infos dazu.
Bis später...

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

14

21.09.2003, 08:42

Kollisionserkennung und Berechnung von Treffern wird in vielen Spielen jedoch vom Server gehandhabt, da es sonst "unfair" würde. Was z.B. wenn der Client A sagt: "Ich wurde nicht getroffen!", aber das auf dem Bildschirm von Client B schon der Fall ist. Wenn es dann an einer zentralen Stelle entschieden wird (Server), sieht die Sache schon anders aus.
Auch wenn es gehen sollte, ich persönlich fände das ziemlich umständlich. Lieber über einen Web-Server die Verwaltung von laufenden Spielen und gerade aktiven Servern erledigen.

Jens

Treue Seele

Beiträge: 117

Wohnort: Dresden

  • Private Nachricht senden

15

21.09.2003, 11:28

stimmt

jetzt fehlt mir gerade das KO-Argument gegen Webserver (als Spieleserver) ein :crying:

Der Webserver kann natürlich nicht aus eigenem Antrieb senden, sondern immer nur antworten. Somit wäre eine Art Polling notwendig. Und das würde sich sicher nicht günstig auf die Gesamtperformance auswirken.

Es ist war, ein eigener Server mit dem Listener und ein paar "Rüsseln", die er pro Connection ausstreckt ;-) ist wohl doch notwendig.
Bis später...

16

21.09.2003, 11:48

Bleib bei WinSocks. Wenn du ein MasterServer für Online Gamer braucht nehm doch einfach ein PHP skript wo sich die Hoster eintragen und was vom Spiel alle 10 sek abgerufen wird.

Das reicht dann auch erstma :)

Werbeanzeige