Zeitplan

Hallo! Wir haben die > Forumsoftware aktualisiert! <


    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.

    Hallo Galilei,


    niemand hat gesagt das
    - der Einkauf/Verkauf
    - das Steuern der Schiffe
    - die autom. Seeschlacht
    - die Verhalten von Angebot und Nachfrage


    trivial ist.
    Ich möchte jetzt aber auch nicht, daß wir uns auf nur ein Themengebiet "versteifen" ;)


    Was den Einkauf/Verkauf angeht würde ich dann einen extra Thread aufmachen (wenn es soweit ist) und die Frage an alle User richten wie wir das lösen wollen.
    Hier können nämlich auch User ihre Meinung einbringen die eigentlcih gar nicht programmieren können.


    Ach ja, was EK/VK bvetrifft könnte man das Beispielsweise wie bei einer "Kasse" machen.
    Es wird sequentiell gearbeitet. Also wie gesagt nur eine Idee. Ich habe mir darum nochh keine Gedanken gemacht, halte das aber auch ohne Client/Server für machbar.
    Die Client/Server Variante ist deshalb so toll, weil ich dann schon eine Abfragesprache (SQL) besitze.


    Übrigens ist ein gutes Datenbankdesign auch nicht trivial.


    Aber wir sollten wirklich die anderen User mit einbinden und erst mal die Randbedingungen klären :P


    Gruß
    Seebär

    Für mich ist client - server exclusiv für komunikation zwischen das client program und den server. Um ein schnelles spiel hin zu bekommen durfte es NIEMALS eine datenbank client-server system geben. Datenbank muss exclusiv am server sein. Ich bin da auch kein freund von SQL. SQL ist zwar viel leichter zu benützen aber dafür SEHR langsam. Aber da unser flaschenhals wohl das netzwerk sein wird finde ich das SQL hier kein problem sein dürfte.


    Das netzwerk muss in klasischem TCP-browser modus gemacht werden. Also anschluss herstellen, daten übertragen und dann wieder anschluss schliesen. So kann man mehrere hundert spieler gleichzeitig bedienen. Nur in bestimte zeiten (wie oben erwähnt - handel, gebäude plazieren, usw) bleibt ein anschluss bestehen.


    Galilei
    Konflickte mit leute die zur gleichen zeit das gleiche machen kann man immer lösen. Das muss zwar eingebaut sein, aber man findet immer eine elegante lösung.

    @ 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.

    Salve,


    einen MP sollte es schon geben, da müssen wir eine gute Lösung haben, nicht dass es uns dann wie MAXDesign & Anno geht...


    Vale RF

    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 ?

    Zitat

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


    Hallo Galilei,


    Du hast natürlich recht wenn du sagst, daß wir uns vorher Gedanken machen sollen ob wir ein MP-Spiel über TCP/IP bzw. Internet spielen wollen.
    Wenn das gewünscht wird, müßen wir dafür erstmal das Transaktionsmodul entwickeln.
    Das halt ich allerdings auch für schwierig.
    Diverse Zeitprobleme kann man schon im Forum beachten. Und da haben wir es wirklich "nur" mit der Aktualisierung von Beiträgen zu tun.


    Damit wir jedoch den Spaß an der Sache nicht verlieren wäre ich für ein SinglePlayer.


    Wir sollten wirklich unsere Ziele am Anfang nicht zu hoch setzen.

    Galilei


    Was du bescreibst ist ein tüpischer daten bank client server. Der client muss nicht wissen wo alle schiffe sind, was gehandelt wird usw. Es muss nur so viel wissen um den spieler dass zu zeigen wass er gerade wissen möchte. Meine arbeit besteht darin machinen zu steuern über sehr langsame serielle linien (9600 baud). Ich weis wie wichtig diese art von komunikation ist. Die einsige zeit die ein client voll mit dem server verbunden bleibt ist wenn es wirklich not ist echtzeit daten zu bekommen - und da wird auch nur dass notwentigste übertragen.


    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.

    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.


    Hallo Seebär,
    ja fände es schade, wenn das Projekt dann in der frühen Testphase in einer Sackgasse untergeht,
    weil vorher niemand auf die Realisierbarkeit geachtet hat.


    Vielleicht versuche ich noch mal es an einem Forum zu erklären,
    da ist es für den Server kein großes Problem, wenn mehrere fast gleichzeitig einen neuen Beitrag zu einem Thread schreiben, denn die werden einfach hintereinander gepackt, Reihenfolge unwichtig.


    Wenn der Server aber nur 50 Fass Bier zu verkaufen hat und nehmen wir mal lediglich 3 Interessenten an,
    A 30 Fass zu 90 GS, B 25 Fass zu 80 GS und KI 10 Fass zu 70 GS in Auftrag geben,
    ist sofort Chaos,
    die Preise stimmen höchstens noch für den, der als erstes drankommt, schlimmstenfalls wird gar nicht vorhandenes BIer verkauft.
    Und die Situation kommt in einer WiSim am Fließband vor,
    da die Spieler ja gerade um knappe Waren konkurrieren.

    Da hat Patroni schon recht mit dem Ansatz,
    dass ein Terminplan und ein Konzept nötig sind.


    Weitere unpopuläre Botschaft ;) :
    Beim Programmieren ist mit einem Aufwand von mind. 2 Jahren zu rechnen,
    selbst wenn 95% aller Featurewünsche dabei unter den Tisch fallen und sich genügend Programmierer finden.
    Einfach P2 (Handel), Anno Bauen & Warenketten + Stronghold Belagerungen + Gilde Rollenspiel
    = SuperGame ist leider nicht machbar.
    Das sind Politikerträume Marke "ich versprech mal allen was, habe zwar keine Ahnung davon und auch nicht die nötigen Ressourcen, aber beim obligatorischen Scheitern findet sich schon ein Sündenbock"



    Und da bei einem Fanprojekt keine 45h - Wochen zur Verfügung stehen,
    werden dabei noch reichlich Features aus P2 wegfallen müssen,
    um den Aufwand in Grenzen zu halten.


    Ferner hat nur modulares Vorgehen und die Nutzung von Programmiersprachen, Tools und Bibliotheken mit möglichst geringem Arbeitsaufwand und leichter Einarbeitung überhaupt Aussicht auf ein erfolgreiches Ende,
    da sicher zwischendurch eine Fluktuation bei den BEteiligten herrscht.

    Zitat

    Original von Galilei


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




    Moin Galilei,


    an dieser Stelle möchte ich den ehemaligen P2-Programmierern ganz gerne signalisieren, daß wir in der Vergangenheit mit mehreren Handel/Wandel/Aufbauspiel begeisterten Leuten in einem Raum zusammensitzend, via LAN P2-mäßig verknüpft, durchaus viel Spaß hatten!


    Der Ruf "PIRATEN VOR MALMÖ" hat schon mal einen ganz anderen Klang und wenn dann eine Fracht verloren geht oder sogar ein Schiff, entwickelt sich eine ganz andere Dynamik und Dramaturgie als im Save/Load-Einzelspiel. *g* Tja, und bei den gelegentlichen Seegefechten steht man halt auf, betrachtet sich den mit hochroten Ohren dasitzenden Schiffslenker und freut sich über die vielen Kommentare und gut gemeinten Tips, die in solchen Spielphasen halt abgegeben werden. Also wir fanden die ganze Szenerie immer sehr lustig!


    Obwohl ich mich seinerzeit sehr auf das Erscheinen von 1503 gefreut habe, wurde es von mir bis heute noch nicht angespielt - Hauptgründe sind die mittlerweile eigenen P2-Aktivitäten (allerdings im Einzelspiel) und der zumindest damals fehlende Multiplayer-Modus.


    Galilei, ich vergesse nichts. Du hast noch nicht kapiert das diies alles (kontoverwalter, autokonvoi, ect) nichts mit dem client zu tun hat. Es pasiert alles intern im server. Die resultate können zum client gehen wen der user gerade dies sehen möchte, sonst nicht.


    Der server macht ALLES was nicht DIRECT mit dem spieler zu tun hat. Kontor verwalter von alle spieler laufen gleichzeitig im server ab. Shiffe laufen im server herum. Wen der spieler ein schiff anshauen möchte, dann bekommt der client dies zu geschickt - wenn der server nicht schon zeit hatte vor zu beugen. Der client macht keine rechnungen, und muss sehr wenig wissen.

    Doch es geht um das,
    was der Client gerade sieht und ändert - klar passieren die Aktionen alle im Server.
    Und das sind in der Regel mehrere Konvois, eine komplette Stadtansicht oder ein Handelsbildschirm + einen Haufen Städte - und die kannst du bei einem Echtzeitspiel nicht einfach "elegant" für die Dauer der Aktion sperren,
    der Spieler am Client will halt immer im Gegensatz zu deinen Maschinen zu den Konditionen handeln / bauen ... die er angezeigt kriegt
    und nicht zu den völlig anderen, die der Server mittlerweile berechnet hat.

    Beim Bauen sehe ich ehrlich gesagt nicht das große Problem. Das ändert sich im allgemeinen nicht so furchtbar schnell. Dann sollte es durchaus ausreichend sein, wenn der Server bei Änderungen alle gerade mit dem Bauen in dieser Stadt beschäftigten Clients informiert.


    Beim "Autohandel" sehe ich auch eher kein Problem, denn der zeichnet sich ja dadurch aus, dass die aktuellsten Preise eigentlich uninteressant sind und die Handelsanfrage so oder so gestartet wird (z.B. "gib mir alles Bier bis zum Preis von 100")


    Das einzige Problem, was ich momentan auch erkennen kann, ist bei manuellem Handel. Hier muss der Spieler ständig über alle Preise informiert werden und es stellt sich die Frage, wie aktuell sind diese und wieviel hat sich inzwischen schon geändert. Wenn die Anzeige aber halbwegs aktuell gehalten werden kann...was spricht dann dagegen, nicht mehr durchführbare Handel abzulehnen? Diese Zahl sollte sich dann ja in Grenzen halten lassen .

    Wieso reden wir immer darüber was nicht machbar ist ?(


    Eigentlich wäre ich schon froh, wenn Patroni oder wer auch immer sagen würde er/sie möchte das mit dem Projektleiter machen :tong:


    Selbst wenn das alles in eine Sackgasse führt. Ich verstehe das alles nur als "just for fun" Projekt.
    Wenn mehr draus wird ist es auch OK ;)


    Also laßt uns doch ganz einfach locker anfangen. :eek2:

    Salve,


    das Problem dabei ist: wenn wir jetzt locker anfangen, machen wir Fehler, die das Projekt in 1-2 Jahren vielleicht scheitern lassen.


    Vale RF

    @ Seebär


    Just for fun ohne lästige Überlegungen, was überhaupt realisierbar ist,
    ein Projekt zu starten,
    empfiehlt sich nur für "nach mir die Sintflut" - Entscheidungsträger,
    die die Millionenabfindung schon im Vertrag stehen haben,
    oder die ihre Pensionen zahlenden Steuerzahler beglücken wollen,
    zwischendurch auf ständig neue andere "Schuldige" zeigend.


    Aber nicht um ein Softwareprojekt in akzeptabler Zeit erfolgreich zu beenden.
    Alles Nicht - Realisierbare dürfen hinterher die Programmierer mit unbefriedigenden Notlösungen ausbaden,
    du kannst dir sicher vorstellen, wie lange die das in ihrer Freizeit mitmachen.

    Moin,


    vielleicht darf man ja die Entwicklung eines Spiels mit einem Hausbau vergleichen. Bevor es zur Ausführung kommt, muß gründlichst geplant werden. Aber bevor die Planung einsetzt, muß doch klar sein, ob es ein umfangreicher Anbau oder ein freistehendes Ein-/ oder Zweifamilienhaus werden soll.


    Wäre es in unserem Zukunftsbereich daher nicht sinnvoll, bis Mitte Juni darüber abzustimmen, ob sozusagen eher ein verbessertes P2-AO ala Brasileiro und Roland oder doch ein "völlig Neues" (siehe Adalbertus und vielleicht auch Galilei ?( ) von der Allgemeinheit gewünscht wird.


    Viele Argumente wurden ja bereits niedergeschrieben und ein jeder wird sich hierzu seine eigenen Gedanken gemacht haben - mal unabhängig davon, ob man ein solches Projekt in diesem Rahmen für realisierbar hält oder nicht.


    Bestünde nach einer solchen Abstimmung nicht die Aussicht, auf eine effizientere Abarbeitung von Patronis Punkt 1 im Zeitplan?