Beiträge von Galilei

Hallo! Wir haben die > Forumsoftware aktualisiert! <

  • Zeitplan

    Zitat

    Original von Brasileiro
    Galilei


    Zum beispiel handel. Der spieler eröfnet ein handels fenster. Ein anschluss wird hergestellt und die menge und preise der waren werden alle 500 ms erneuert (WENN NÖTIG). Sagen wir das wir 40 waren haben - das sind 480 bytes zum übertragen pro sekunde. Das schaft jeder server und internet anschluss. Wen der spieler was kauft, und die preise haben sich geendert, wird der kauf NICHT durchzogen, und der käufer bekommt bescheit.


    Man muss die sachen nur alles gut überdenken und niemals die einfachste lösung benützen. Es muss alles bis ins kleinste überdacht werden.


    Du vergißt bei deiner Rechnung aber, dass jeder menschliche Spieler mindestens 20 Konvois und einen Haufen Kontorsverwalter haben wird, von den ganzen KIlern, Konsumenten etc. mal abgesehen. Und gleichzeitig noch > 100 Konvois über die Meere schippern, von neuen Wünschen wie Pferdefuhrwerke mal abgesehen.


    Wenn du die Aktion nicht durchziehst, falls sich die Preise geändert haben,
    musst du entweder die Ware vor jeder Aktion sperren, um das überhaupt rausfinden zu können -> jede Aktion braucht eine 1/2 Sekunde
    oder es herrscht das totale Chaos,
    weil die Aktionen nie durchgeführt werden können, da sich ständig was ändert, bzw. der Handel verkommt zum reinen Glücksspiel weil der Server das Problem einfach ignoriert.


    Das Problem ist einfach,
    dass beim P2 - Handelssystem eine riesige Menge Daten ständig von konkurrierenden Aktionen zeitgleich tangiert wird.
    Das ist keine Überweisung, wo man eben kurz das Konto - Objekt sperrt,
    und auch kein Buchungssystem, wo man halt auch nur das betroffene Obkjekt sperrt,
    oder vielmehr der Datenbank den Job überlässt,
    und keine Supermarktkasse wo sich die Kunden brav zum Festpreis in der Schlange einreihen,
    falls sie die gesuchte Ware gefunden haben.

  • Zeitplan

    Davor will ich Brasileiro ja warnen,
    dass eine Echtzeit - Lösung mit der Komplexität unseres Vorbilds und erst recht mit einer höheren genauso enden würde. Eine WiSim ist halt kein Simpel - Shooter mit 32 Teilnehmern * max. 2 aktiv nutzbaren Waffenmodi und ein paar Gegenstände.



    Wenn es ein MP (fähiges) - Spiel werden soll,
    wird man beim Konzept nicht drumherum kommen,
    statt einem P2 - Klon Richtung (größtenteils) rundenbasiert zu gehen,
    um die Datenmengen deutlich zu drücken und das Ganze sequentiell zu kriegen.


    Und ferner Handel und Schiffahrt völlig anders mit selteneren aber spannenderen Entscheidungen völlig neu zu konzipieren, um den Spieler nicht mit nicht zu bewältigendem Mikromanagement zu frusten.


    Hat hier jemand schon P2 im Multiplayer gespielt und dabei richtig Spaß gehabt ?

  • Zeitplan

    @ Seebär
    Das sind keineswegs Randbedingungen ( vor allem für den Multiplayer),
    sondern absolute Grundlagen.


    Brasileiros TCP - Modus würde bei einem Spiel a la P 2 schnell Schiffbruch erleiden:


    Schon beim Handel sind ständig 20 Waren * 20 Städte * 20 Preise * 2 ( EK oder VK) * geschätzt 50 Transaktionen durch Konvois oder VErwalter auf dem aktuellen Stand zu halten.
    Dazu kommen noch Nachfrage, Schiffsbewegungen, Produktionsfaktoren wie Arbeiterzahl in ähnlichen Größenordnungen + sonstiges ...


    Das packt keine DSL - Leitung in Echtzeit und auch der Server ist bei jeder Aktion erst mal mit sperren und hinterher entsperren der Daten beschäftigt.
    Erst recht nicht, wenn hier noch 5 Waren, dort noch 20 Städte dazukommen ...
    Mir ist jedenfalls kein Spiel dieses Komplexitätsgrades bekannt,
    wo der Multiplayer wirklich funktioniert und auch noch Spaß macht.


    Und Dinge wie manueller Handel, gemütliches Bauplatz suchen oder "ich erstell mir kurz meine Autoroute *Pause* "
    sind im Multiplayer zeitlich so nicht drin.
    Man kann ja nicht einfach den Server auf das Verbindungsende warten lassen,
    bis Spieler X endlich seine 6 Fass Bier verkauft hat,
    oder verkünden "sie können jetzt leider in Danzig nicht bauen, da Spieler X gerade das Baufenster offen hat.


    Das müsste aber vorher geklärt sein,
    bevor man sich entscheidet,
    ob es nun einen Multiplayer geben soll oder nicht.

  • Zeitplan


    Was anderes als Client und Server ist auch gar nicht möglich,
    nur wird das Problem weiter unterschätzt.
    Es geht nicht darum, als Client zu übermitteln, kaufe 50 Fass Bier, baue einen Getreidehof ( das ist nicht schwerer als einen Chat oder ein Forum zu proggen),
    sondern darum,
    dass der Server jedes Fass nur an einen verkaufen kann,
    der Spieler natürlich zum angezeigten Preis kaufen wollte oder dass auf jeden Bauplatz nur ein Gebäude passt.
    Im Singleplayer in einem Programm ist das für die KI kein Problem,
    das Programm arbeitet halt die Wünsche des Spielers und die KI - Aktionen nacheinander ab.


    Beim Server treffen die Anforderungen aber in keiner festen Reihenfolge ein,
    teilweise sogar parallel,
    er kann nicht KI - Händler X 50 Fass Bier verkaufen und gleichzeitig die Preisanzeigen von Spieler A und D aktuell halten, die eventuell gerade auch auf Bier kaufen geklickt haben.


    Es wird sich aber kein Spieler bieten lassen, die Anweisung verkaufe 50 Bier für 40 pro Stück zu erteilen
    und dann 11 Stück für 80 pro Stück zu bekommen ...


    Das Problem wirkt erstmal trivial, harmlos und besserwisserisch,
    macht einen aber spätestens bei der Frage,
    warum das Programm sich im Test so komisch verhält garantiert :crazy: ,
    dann ist das Kind schon im Brunnen ertrunken.

  • Zeitplan

    Hallo Seebär,


    ich habe das Beispiel auch nur angeführt,
    um klarzumachen,
    dass man entweder von Anfang an an einen Multiplayer denkt
    oder diesen komplett sein lässt (weil nachträglich nicht möglich).


    Ist halt eine der Weisheiten des Software Engineerings :-)

  • Zeitplan

    Das geht aber leider nicht,


    die Netzübertragung kann man als Modul locker und vor allem sinnvoll auslagern,
    die Synchronisierung der Daten läuft aber nicht bei der Übertragung sondern über den Zugriff auf die Daten.


    Im Klartext entweder jede kritische Objektmethode wie Ware.kaufen() ist von Anfang an sauber dafür vorgesehen,
    oder der Multiplayer ist tot, sobald er geboren wird.


    Alternativ überlässt man diese Arbeit einer guten Datenbank ( soll halt sehen, ob sie die SQL - Anweisung ausführen kann),
    nur dürfte die Systemanforderung Oracle oder MS SQL Server die Zielgruppe doch sehr einengen ;-)

  • Zeitplan

    Und genau die Schnittstelle ist das Problem beim Multiplayer.


    a) muss sie sämtliche Datenmanipulationen durch "Spieler" umfassen,
    ohne undisziplinierte Hintertüren


    b) müssen die alle synchronized sein,
    da das Fass Bier nur von einem gekauft werden kann,
    oder anderes Beispiel ein Schiff nur einmal versenkt


    Daten hin und her schicken ist simpel,
    aber sie synchron zu halten ist sauschwer

  • Zeitplan


    Hmm,
    ist halt schwierig.


    Erstmal programmiert man P2 nicht mal eben in ein paar Monaten nach (ganz abgesehen davon, dass dies wenig bringt),
    zweitens wird man wohl modulweise vorgehen müssen,
    um die Motivation der Beteiligten durch Vorzeigbares aufrecht zu erhalten.


    Und die Technik hängt davon ab,
    was inhaltlich gewünscht wird.


    Für Multiplayer kommen eigentlich nur Java oder Browserspiel mit PHP infrage,
    es sei denn es findet ein Spezialist für Netzwerkprogrammierung C++ mit enorm viel Zeit.


    Die Textvariante ist eigentlich kaum sinnvoll,
    da Echtzeit damit unmöglich ist und Eingabe/Ausgabe die reinste Folter ...


    Und Echtzeit ist ein weiteres Problem,
    wenn sich Preise im ms - Takt ändern und Schiffe über die Nordsee tickern,
    kann man keine umfangreichen Berechnungen (z.B. Untiefen, Abnutzung, logische Nachfrage) damit mehr anstellen.


    Fertige Engines dürften sich für eine WiSim kaum eignen,
    aber eine z.B. in 3D zu programmieren dürfte vom Aufwand nicht machbar sein.
    Bleibt eigentlich nur eine 2D - Oberfläche, zu Beginn mit Platzhaltergrafiken und ohne großartige Animationen.