Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: Webgamers. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

61

Mittwoch, 17. Dezember 2014, 08:03

Nachdem wir endlich auch Unterstützung bei der Front-End Entwicklung haben nimmt das ganze Formen an.
Es gibt eine Datenbank für die Simulationsobjekte.
Es gibt das Front-End, aber ohne anständiges Design, zum Testen.
Wir haben das Anlegen neuer Spieler bereits implementiert und es ist angenehm flott.
Als nächstes kommen so essentielle Funktionen wie Anmeldung und Abmeldung an der Simulation, damit das auch im Front-End nutzbar ist.

62

Montag, 22. Dezember 2014, 17:33

Wir haben unseren Sternen jetzt Planeten zugeordnet.
Wir haben nur der der Hälfte der Sterne auch Planeten gegeben. Es sind neben den 300.000 Sternen nun auch 1.300.000 Planeten im System.

Das laden der Daten braucht halt seine Zeit, soll aber auch nicht so oft passieren.

Im Leerlauf braucht die Simulation jetzt ca. 80ms für einen Durchlauf und belegt aktuell 900MB RAM.

Als nächstes wird die zentrale Verwaltung hinzugefügt über die die Bauaufträge und noch viele Dinge mehr abgewickelt werden.

63

Dienstag, 23. Dezember 2014, 11:52

Ich habe mir hier mal den Thread angeschaut und festgestellt ... soweit war ich schonmal :D
So ist das eben wenn man versucht Dinge so gut wie nur eben Möglich zu realisieren. Aber dennoch haben Fosco und ich das Gefühl das es das erstemal seit langer Zeit wirklich vorangeht.

64

Mittwoch, 24. Dezember 2014, 11:28

Jetzt ist Weihnachten und ich mache mal 2-3 Tage Pause.

In der Simulation wird ein Cycle-Counter verwendet um einen Teil der Berechnungen nur bei Bedarf ausführen zu müssen. Dieser Cycle-Counter wird nun in der DB gespeichert und beim Start von dort wieder eingelesen.

Am ende der Initialisierungsphase, die immer mit einem Cycle-Counter Wert 0 startet, wird der Cycle-Counter auf den alten Wert aus der DB gesetzt. Damit sollte nun der Zustand der Objekte zum Cycle-Counter passen.
Dabei habe ich auch gleich das Speichern von Daten in der DB getestet. War eh schon lange mal fällig.

65

Freitag, 26. Dezember 2014, 14:08

Um schnell einen Planeten zu finden der für einen neu angemeldeten Spieler geeignet ist, gibt es eine spezielle Liste der nicht genutzten Sternensystem.
Da wir im Moment keine weiteren Kriterien für die Auswahl einbauen, reicht die Liste erstmal aus.

Es wird ein wenig mehr Speicher benötigt, wir sind nun bei 1GB für ein Spielfeld mit 1.7M Objekten.

Dann habe ich noch den Code an einer Stelle vereinfacht. Das wars dann aber für heute.

66

Mittwoch, 31. Dezember 2014, 14:02

So.
Das Jahr ist rum. Heute habe ich das Erzeugen eines neuen Spielers komplettiert.
Also fast.

Wenn ein Spieler sich nach der Registrierung das erstemal anmeldet kann er sich eines der Völker aussuchen. Dann wird ein Planet ausgesucht der zu dem Volk passt, auf dem Planeten eine Stadt erzeugt und in der Stadt eine Administration. Damit sind dann alle Objekte vorhanden die ein Spieler so braucht um starten zu können.

Aber noch ist nicht alles perfekt. Aber wir arbeiten dran, auch im nächsten Jahr.

67

Sonntag, 18. Januar 2015, 15:25

Habe gerade eine kleine Änderung eingebaut, bei der es vor allem um das Nutzen von Templates in der Simulation geht.
Wenn neue Objekte erzeugt werden, dann werden häufig bestimmte Werte als Defaults in die Objekte eingetragen und anstatt das direkt in den Programm-Code zu packen speichere ich die Informationen in der DB. Das war auch immer so, weil das einfach Sinn macht. Sonst müsste man bei der Anpassung von Werten immer die Simulation neu übersetzen. Wäre viel zu umständlich.

In einem ersten Ansatz habe ich aus dem Template auf der DB das neue Objekt erzeugt und dann die Daten in die Simulation geladen. Das mag beim anlegen eines neuen Spielers noch gehen, immerhin hat Ulle bei einem Test in 70 Sekunden 1000 Accounts erzeugt, von Remote durchs Internet.

Aber für Objekte die während des Spiels so entstehen ist das keine gute Lösung. Daher habe ich das jetzt umgedreht. Die Templates werden aus der DB gelesen und dort gespeichert und bei bedarf werden die neuen Objekte nun in der Simulation aus den Templates erzeugt. Die Daten werden dann im Hintergrund in die DB übertragen.

Das dürfte nochmal ein paar Schritte schneller gehen. Ist aber natürlich beim Erzeugen neuer Accounts nicht wirklich wichtig.

68

Dienstag, 20. Januar 2015, 13:16

Da ich ja mittlerweile auch Unterstützung durch meinen Bruder erfahre geht die Entwicklung auch noch in eine andere Richtung.
Mein Bruder ist aktuell dabei sich eine Art Programmiersprache einfallen zu lassen, nichts berauschendes und auf unsere einfachen Bedürfnisse abgestellt. Wir tragen aktuell ein paar Eckpunkte zusammen.

Damit wäre dann auch jemand in der Lage die Objekte in der Simulation zu spezifizieren und ihr Verhalten zu definieren der nicht C/C++ programmieren kann. So ist jedenfalls die Idee.
Ob uns das gelingt wird man sehen.

69

Samstag, 14. März 2015, 15:48

Also liebe Fangemeinde, oder die es noch werden wollen.
Ich musste mich ein wenig zurück nehmen und habe dann doch ein paar Arbeiten an dem System durchgeführt die einfach mal nötig waren.

Die Software ist jetzt in drei Bestandteile zerlegt, wobei aber noch nicht alles an seinem Platz ist.
Sie besteht nun aus

  • Einem Simulationskern
  • Einer Library die die Schnittstelle definiert.
  • Einer Library in der das Spiel untergebracht ist.

Durch diese Aufteilung kann man unterschiedliche Simulationen in Shared-Libraries unterbringen und verwendet immer den gleichen unveränderten Kern.
Gerade wenn man durch eine Sprache oder durch eine Modellierung in UML die Simulation beschreiben will, ist es wichtig keinen Bezug zum Simulationskern zu haben.
Sonst ändert der sich ständig mit und das führt dann zu Verwirrungen und vor allem Aufwand bei der Pflege.

Weil ich gerade dabei war habe ich auch den Ladevorgang ein wenig beschleunigt. Dazu muss man aber wissen das aktuell in der Test-Datenbank

  • 1.757.641 Objekte enthalten sind.
  • 4.157.489 Double Werte als Attribute der Objekte.
  • 778.341 Integer Werte als Attribute der Objekte.
  • 1.062.855 Texte als Attribute der Objekte.
  • 1.458.464 Referenzen zwischen Objekten.

Das ganze hat vorher irgendwas um die 15 Minuten benötigt. Jetzt sind es nur noch 10 Sekunden.

Da ich Statistiken so toll finde hier auch mal eine.

Aktuell umfasst die Simulation ca.:

  • 5440 Zeilen C/C++ Code.
  • 178 Zeilen awk Code
  • 54 Zeilen php Code
  • 3 Zeilen Shellscript


Alleine für das Speedup hat es sich gelohnt ein bisschen was zu ändern. Denn das Testen und Debugging macht keinen Spass wenn man immer eine viertel Stunde warten muss bis man an der richtigen Stelle im Programm ist.
Ich muss noch Überarbeitung des Codes machen, mal schauen vielleicht morgen, und dann macht es bestimmt auch wieder spass neue Dinge einzubauen.

70

Montag, 6. April 2015, 15:34

Ich bin zwar nicht schnell aber unnachgiebig.

Es gibt bei der Definition der Objekte und ihrer ganzen Interaktionen etc. ein Komplexitätsproblem.
Ohne die Unterstützung durch eine Sprache, wie ja eigentlich mal angedacht, oder einem anderen Tool, zum Beispiel UML, ist das nicht in den Griff zu bekommen.

Pierre Romain sollte immer ein Spiel sein, das sich durch seine vielfältigen Möglichkeiten vom Rest abhebt. Daher ist es essentiell die Komplexität in den Griff zu bekommen. Wenn es nur was simples wäre würde ich das wahrscheinlich einfach zusammen tippern und gut wäre.

Nun habe ich also mal geschaut wie man sowas in UML machen würde und muss sagen es nimmt mir auch dort allerlei Arbeit ab. Aber ich muss da noch ein wenig was hinzufügen.

Das soll hier nur mal ne Info sein, damit keiner denkt "da passiert nix." Neeeeee. Nicht aufgeben ist die Devise.

fredalex

Fortgeschrittener

Beiträge: 47

Danksagungen: 412

  • Nachricht senden

71

Montag, 6. April 2015, 22:35

Hallo, habe im Thread diesen Teil gelesen:
Es gibt ein Plugin-System, bei dem man C/C++ Plugins entwickeln kann, auf die dann die entsprechenden Requests umgeleitet werden. Der Hintergrund dazu wiederum ist, das wir mit solchen C/C++ Plugins dann im Binärformat mit der Simulation kommunizieren können.


finde das sehr interessant und wollte mal Fragen wie du das machst?
über Sockets? Wie ist die Performance der Kommunikation? Und wie siehts mit Multithreading, bzw mehreren parallelen anfragen aus?

Lg

72

Dienstag, 7. April 2015, 10:59

Öh.

Das ist ja ein Post von vor einem Jahr!
Aber dennoch. Das ging ja damals um den Web-Server den ich gebaut habe. Da ist es so das jedes Plugin ein eigener Thread ist und somit Anfragen an unterschiedliche Plugins parallel ausgeführt werden, wenn man denn wie heute üblich mehrere Cores zur Verfügung hat.

Die HTTP-Requests sind in einem Objekt soweit aufbereitet das ein Plugin alle relevanten Informationen zur Verfügung hat. Die Plugins haben eine Message-Queue in die die Requests hinein geschrieben werden. Die Messages werden als Pointer weitergegeben was die Sache recht performant macht.
Jedes Plugin hat seine eigene Verbindung zur Simulation. Die Verbindung ist eine TCP/IP Verbindung, die Kommunikation erfolgt also über Sockets. Die Kommunikation ist non-blocking. Dadurch können also fleissig neue Requests entgegen genommen werden während andere bereits in der Simulation abgearbeitet werden.

Die Simulation selbst ist grundsätzlich in der Lage mehrere Verbindungen von einem oder mehreren Web-Servern zu verwalten. Man kann also für einen höheren Durchsatz mehrere Computer mit Web-Servern ausstatten und diese Verbinden sich dann mit einer Simulation.

Durch die Verwendung von TCP/IP als Kommunikationspfad können Web-Server und Simulation auf unterschiedlichen Maschinen ausgeführt werden.

HTTP-Requests die nur ein paar statische Inhalte abrufen werden direkt in den Worker-Threads abgewickelt. Die Anzahl der Worker kann man konfigurieren. Darüber wird auch die Parallelität erreicht.

Auf dem Root-Server haben wir Round-Trip-Times von irgendwas zwischen 10ms und 30ms wenn denn die Simulation auch noch was zu erledigen hat.

Da das, wie schon Eingangs erwähnt, ein altes Post ist auf das du dich da beziehst, sind die Aussagen nicht mit dem aktuellen Stand zu vergleichen. Da haben wir ein paar Veränderungen gemacht. Aber das ist eine andere Story.
Grundsätzlich ist das ganze Sauschnell, wobei es aber noch nie einem wirklichen Lasttest ausgesetzt gewesen ist. Aber ich habe mal von zu Hause 200 Verbindungen offen gehabt, das ging recht flott. Ist also kein grundsätzliches Problem.

73

Sonntag, 3. Mai 2015, 17:12

Ich habe mal angefangen die Simulation in UML zu modellieren. Dabei mache ich aber erstmal nur die statische Abbildung.

Das ....

[img]http://devel.simulated-universe.de/StellarObjects.png[/img]

führt zu dem ....

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
//
//                   S t r u c t   d e c l a r a t i o n
typedef struct __tResourceOutput {
    uint64_t ProducerID;
    int64_t OutputPerCycle;
} tResourceOutput;
//
//                   S t r u c t   d e c l a r a t i o n
typedef struct __tResourceStorage {
    uint64_t ResourceID;
    uint64_t CalculationTime;
    int64_t AllOutputPerCycle;
    int64_t Content;
    std::vector< tResourceOutput > OutputPerSource;
} tResourceStorage;
//
//                   S i m o b j e c t    d e c l a r a t i o n
typedef struct __tPlanet {
    tSimObj    base;
    tSimObj* Viewport;
    char* Name;
    double Diameter;
    double VolumicMass;
    double Gravity;
    double Age;
    double DistanceToStar;
    double Temperature;
    double Water;
    double DayLength;
    double YearLength;
    double TaxesPerCycle;
    uint64_t Population;
    std::vector<tSimObjRef> Area;
    std::vector< tResourceStorage > Resources;
    tAtmosphere Atmosphere;
} tPlanet;

74

Sonntag, 31. Mai 2015, 15:53

Es ist mal wieder was passiert. :) Nur leider kann man das nicht sehen :(
Ich habe mein UML-Tool soweit angepasst das man nun keine Dinge mehr modellieren muss, die nicht direkt mit der Simulation zutun haben. Es sind einige Dinge als generischer Bestandteil in ausgelagert worden und werden nun nurnoch in einer Init-Funktion mit Werten befüllt.
Für die Kommunikation mit der Aussenwelt wird JSON verwendet, das ich in mein eigenes Format konvertiere. Alle Funktionen die dafür benötigt werden werden aus dem Modell erzeugt. Man kann sich also voll und ganz auf das modellieren der Simulation konzentrieren. Aus einzelnen Sequence-Diagrammen werden die Nachrichten-Dispatcher erzeugt, aus den Simulations-Objekten die Attribute-Ids und vieles mehr.

Es fehlt noch ein bisschen was, aber so wie es jetzt ist, finde ich es super.
Mal schauen was als nächstes fertig wird.

75

Samstag, 6. Juni 2015, 15:37

Das sind so die nächsten Stücke die ich fertig implementieren will.
Ist eigentlich ganz einfach, weil auch schonmal gemacht.



Ausserdem wollte ich mal schauen ob und wie man bilder hier rein kriegt.



Also. Das eine sind die UseCases. Das andere der Ablauf. Eigentlich recht einsichtig.

76

Sonntag, 7. Juni 2015, 16:51

Ich habe an diesem Wochenende die Generierung von Code weiter ausgebaut.
Unter anderem das Einrichten eines Template Mechanismus. Die Templates werden als Objekte in die DB der Simulation abgespeichert und beim Start geladen.
Anhand der Objekt-ID wird ein Template von einem "echten" Objekt unterschieden. Da ich der Meinung bin, das man erstmal nicht mehr als 1Mrd Objekte benötigt habe ich einfach die obersten beiden Bits als Identifikation eines Templates benutzt.
Zu jedem Objekt gibt es nun ein Template-Store in dem diese Templates abgelegt werden und eine Funktion mit der man neue Objekte von bestehende Templates erzeugen kann.
Das ganze ist leider noch nicht getestet, das werde ich wohl am nächsten Wochenende machen. Ohne diesen Template Mechanismus kann ich leider auch nicht das erzeugen neuer Spieler testen.
Baut also aufeinander auf.

77

Donnerstag, 11. Juni 2015, 15:28

Mal was neues.

Ich habe mir wordpress installiert und bin nun nicht mehr auf google und co angewiesen. In der Signatur ist der Link auf das BLOG auch aktualisiert.
Im folgenden werde ich versuchen die Hardcore technischen Dinge im BLOG abzulegen und hier nur noch über allgemeine Dinge berichten.
Zum Beispiel wenn es erfolge zu vermelden gibt.

Slayer

Fortgeschrittener

Beiträge: 472

Danksagungen: 139

  • Nachricht senden

78

Donnerstag, 11. Juni 2015, 16:01

Ich habe mir wordpress installiert

Finde ich super! Dann gibt es neben uns nun noch einen deutschsprachigen Blogger, der sich mit Spiele-Entwicklung beschäftigt.

Have fun
Slayer
eXperinox - Browserspiel Science Fiction / Weltraum - "noXen macht Spaß!"
---
Austria Insiderinfo - Wandern im Salzburger Land

79

Donnerstag, 11. Juni 2015, 16:18

Na ich hoffe das ich deine Euphorie nicht bremsen muss. Ich habe absolut keine Ahnung wie man sowas macht. Ich versuchs einfach mal wieder.
Aber es freut mich das es wenigstens schon einen Leser geben wird.

80

Mittwoch, 17. Juni 2015, 14:51

Habe tatsächlich was ins blog geschrieben.
Ist noch nicht so richtig hübsch, aber das kommt noch.

Social Bookmarks