Kann man ein Realtime Multiplayer machen??

  • VB.NET

Es gibt 24 Antworten in diesem Thema. Der letzte Beitrag () ist von Wipf1000.

    FreakJNS schrieb:

    (vllt hast du ja das ein odere andere Tutorial von LukaSoftware gesehen, bitte auf garkeinen Fall so machen!!!)
    Für Fortgeschrittene Nutzer welche das Zeug nicht nachmachen aber zu 100% sehenswert. Ich lach mich jedes mal schlapp :D

    kai996 schrieb:

    @Rinecamo das hab ich gemacht, damit noch mehr unterstrichen wird wie scheiße FTP is
    Es ist immer das Selbe in dem Forum. Ich habe vorhin schon versucht meine Meinung zu FTP etwas zu unterstreichen. FTP ist nicht schlecht und hat auch nicht wirklich schwächen welche nicht durch SFTP ausgebessert worden sind. Nur hat alles seinen Anwendungsbereich. Du kannst nicht sagen, dass eine Säge scheiße ist nur weil du damit kein Loch bohren kannst. Eine Säge verwendest du eben zum sägen und einen Bohrer zum Bohren. FTP wird nun mal verwendet um Dateien zu übertragen und auf einem Server abzulegen damit sie ein anderer irgendwann abrufen kann. Daher auch der Name "File Transfer Protocol". Es ist aber nun mal einfach nicht zur Kommunikation gedacht. Nebenbei meinen alle mit FTP würde es einfacher funktionieren was so einfach nicht stimmt. FTP macht für solche Zwecke nichts als Probleme weil es eben nicht darauf ausgelegt ist.
    In dem Forum sagt einer FTP alle fangen an zu schreiben "Um Gottes Willen NEIN bitte nicht". Ein paar Posts später tauchen aussagen auf wie "wie scheiße FTP is". FTP IST NICHT SCHEISSE. Alles ist bei falscher Verwendung scheiße. Nen Schlaftablette kann dir helfen mit Schmerzen,... einschlafen zu können. Trotzdem will ich gar nicht wissen wie oft sich Leute mit den Teilen schon das Leben genommen haben.

    Als pass in Zukunft einfach auf was du sagst wenn du schon etwas sagen musst. Und ich denke der TE hat jetzt auch langsam begriffen, dass er TCP verwenden soll. Ein Tutorial für einen Chat hat er auch. Natürlich geb ich hier FreakJNS recht, dass ein Game wieder etwas ganz anders ist.
    Deshalb noch ein kurzer Tipp an den TE:
    Überleg dir eine Architektur und versende keine Strings. Nur als Beispiel könntest du es so lösen:

    Überleg dir eine Datenstruktur der Pakete die du sendest. z.B. könnte dies sein:
    4 Byte AbsenderID
    2 Byte PaketTyp

    Anschließend kannst du z.B. für den jeweiligen PaketTyp wiederum Inhalt encodieren. Als Beispiel betritt jemand das Spiel kommen hinter diesen zwei Standardwerten noch:
    4 Byte PlayerID
    4 Byte SpielerFarbe
    n Byte SpielerName

    ... wie du das gestaltest ist dir überlassen. Es bietet sich aber bei solch kleinen Projekten an zum Beispiel eine Basisklasse MessageBase zu erstellen welche z.b. die ersten zwei Werte immer encodiert.
    Anschließend leitest du die anderen PaketTypen davon ab welche dann wiederum ihre Daten encodieren und decodieren können. Um das ganze noch etwas zu abstrahieren kannst du noch eine Art MessageFactory erstellen welche dir die Pakete encodiert und decodiert. Wie auch immer. Überleg dir etwas anständiges und klatsch nicht alles irgendwie mit Strings und kp. was alles in ne Form rein.


    Bei weiteren Fragen einfach nachfragen.


    Opensource Audio-Bibliothek auf github: KLICK, im Showroom oder auf NuGet.
    @thefiloe
    jaja, LukaSoftware ist schon klasse - bin dir zutiefst dankbar, dass du irgendwo mal was von ihm geschrieben hast, wäre sonst nie darauf gekommen mir auch nur ein video anzusehen xD

    Ich wollte genau auf so eine Architektur wie du sie hast hinaus in "Informatik Facharbeit 2D Netzwerkspiel" gibts dazu auch kleine Code-Beispiele. Würde ein Paket (=> Message) im nachhinein (weiß nicht mehr was ich dort geschrieben habe) so aufbauen:

    MessageID + Daten

    wobei MessageID 1 Byte beansprucht (sollte ausreichen. Eine Enum ist hierfür ein perfektes Hilfsmittel!) und die Daten n Bytes lang sind. n ist aber nicht beliebig sonder je nach MessageTyp fest vorgegeben (das sind btw alles Klassen, die man selbst schreiben muss und die von einer gemeinsamen Oberklasse erben).

    Beispiel PositionMessage: PositionX, PositionY und Richtung sollen übertragen werden. Das wären 3*4 Byte (wenn die Werte vom Typ Single sind) = 12 Byte. Eine PositionMessage hätte also einen Daten-Byte-Array der immer 12 Byte lang ist.
    Bei Strings (Spielernamen) macht das Probleme wegen variabler länge der Daten... Am einfachsten wäre es zu sagen, dass ein Name nur maximal 30 Zeichen lang sein darf etc. Bei einem IngameChat hätte man dann aber wieder Probleme - da könnte man längere Strings zerstückeln, würde dann aber auch aus der Reihe tanzen...

    FreakJNS schrieb:

    ch wollte genau auf so eine Architektur wie du sie hast hinaus in "Informatik Facharbeit 2D Netzwerkspiel" gibts dazu auch kleine Code-Beispiele
    Wobei mir das Architektur-Diagramm noch am besten gefallen hat ;)

    FreakJNS schrieb:

    Spieleprogrammieren nach hinten verschieben, vorher was anderes machen.
    Würde ich abschwächen: nicht mit einem Realtime-Multiplayer Game anfangen.

    Warum zum Beispiel nicht mit einem verteilten Memory-Clone anfangen ? Das stellt im Wesentlichen die gleichen Probleme und kann auf einer ähnlichen Architektur aufgestellt werden. Man kann sogar mit Picureboxen anfangen um es dann später durch GDI zu erstezen.
    @Kangaroo
    Danke!

    Nagut, ein Memory ist wirklich okay^^ Wobei ich nie zu Pictureboxen raten würde: KlickiBunti kann jeder (siehe Youtube: LukaSoftware) und ein Memory, das man sich so zusammenklickt? Vor lauter Pictureboxen das Programm nichtmehr sehen xD
    Viel viel wichtiger ist es zu lernen wie man Datentypen und Klassen für sich nutzt: also Klassen für eine Karte erstellen und eine für das Spielfeld (stellt dann Methoden bereit um Karten umzudrehen, wer an der reihe ist, etc). Dann baut man sich ein Control, dessen Aufgabe es ist das Spielfeld darzustellen.