[Projekt] Universe (Spiel)
- Ersteller KingofKingzZ
- Erstellt am
TE
TE
KingofKingzZ
Software-Overclocker(in)
Danke, das hör ich gerne 
Hab hier noch nen Screen des Multithreadings an dem ich momentan arbeite. Hab es schnell mit Paint gemacht, deswegen siehts nicht so toll aus. Außerdem fehlen noch Threads für Audio, KI sowie ggf. später mal Netzwerk, aber da ich die Dinge noch nicht angefangen habe sind sie da nicht drauf.
Sobald es fertig ist erzähl ich noch bisschen mehr darüber wie ich es umgesetzt habe.
Lg
Hab hier noch nen Screen des Multithreadings an dem ich momentan arbeite. Hab es schnell mit Paint gemacht, deswegen siehts nicht so toll aus. Außerdem fehlen noch Threads für Audio, KI sowie ggf. später mal Netzwerk, aber da ich die Dinge noch nicht angefangen habe sind sie da nicht drauf.
Sobald es fertig ist erzähl ich noch bisschen mehr darüber wie ich es umgesetzt habe.
Lg
fadade
BIOS-Overclocker(in)
N1CE! Gerne mehr infos, DENN:
ich muss jetzt in der Firma, wo ich Praktikum mache auch Dutzende Threads mit "C" erstellen die dann alle was für die Kommunikation per RC232 machen ....
und ich hab noch keinen Plan, wie man so 10-20 Threads synchronisieren soll
Einen kontroller-thread, der bei bestimmten bedingungen die Berechnungen/Aktionen/EIn-Ausgabefunktionen der anderen Threads freigibt. diese stellen sich dann nach erledigter Arbeit in einen "Pausemodus" und warten dann wieder auf das Signal des kontroller-Threads ?!?!?
Bei dir schaut das so aus:
Main Thread: renderd map gui und particles und kümmert sich um post processing, sowie die Inputs (warum sind die am ende und nicht am Anfang?), während die anderen Physik bzw. partikel berechnen. Wenn die fertig sind, "geben sie iwwi das Rendering der Partikel etc. frei" (ist ja auch klar, da die erst gerendert werden sollen, wenn sie fertig berechnet sind), aber was machen denn die pfeile, die rückwärts auf die anderen Threads zeigen?^^
PS: Mir wurde gesagt, dass man bei mehreren Threads nicht gleich eine Multicore-Anwendung erstellt hat. Kennst du dich auch damit aus, wie du den Threads bestimmte Kerne zuweist?
Edit: achso ... die Eingaben sind am ende, womit sie eigentlich auch gleich wieder am anfang, also vor den berechnungen der Physik etc. sind
mann mann ... fadade + Nachmittag_vor_der_Führerscheinprüfung + Multithreads + Katze_fast_auf_der_Tastatur =
ich muss jetzt in der Firma, wo ich Praktikum mache auch Dutzende Threads mit "C" erstellen die dann alle was für die Kommunikation per RC232 machen ....
und ich hab noch keinen Plan, wie man so 10-20 Threads synchronisieren soll
Einen kontroller-thread, der bei bestimmten bedingungen die Berechnungen/Aktionen/EIn-Ausgabefunktionen der anderen Threads freigibt. diese stellen sich dann nach erledigter Arbeit in einen "Pausemodus" und warten dann wieder auf das Signal des kontroller-Threads ?!?!?
Bei dir schaut das so aus:
Main Thread: renderd map gui und particles und kümmert sich um post processing, sowie die Inputs (warum sind die am ende und nicht am Anfang?), während die anderen Physik bzw. partikel berechnen. Wenn die fertig sind, "geben sie iwwi das Rendering der Partikel etc. frei" (ist ja auch klar, da die erst gerendert werden sollen, wenn sie fertig berechnet sind), aber was machen denn die pfeile, die rückwärts auf die anderen Threads zeigen?^^
PS: Mir wurde gesagt, dass man bei mehreren Threads nicht gleich eine Multicore-Anwendung erstellt hat. Kennst du dich auch damit aus, wie du den Threads bestimmte Kerne zuweist?
Edit: achso ... die Eingaben sind am ende, womit sie eigentlich auch gleich wieder am anfang, also vor den berechnungen der Physik etc. sind
mann mann ... fadade + Nachmittag_vor_der_Führerscheinprüfung + Multithreads + Katze_fast_auf_der_Tastatur =
TE
TE
KingofKingzZ
Software-Overclocker(in)
Also bei mir läuft das im Moment so ab: Ich habe für jeden Thread ein Start und ein End Event erstellt (siehe MSDN Events).
Der Thread bekommt die beide als Parameter mit. Die Threadfunktion läuft dann in einer Endlosschleife (while(true)) und ganz am Anfang der Schleife wird dann "WaitForSingleObject(StartEvent)" aufgerufen, während der Main Thread am Anfang der Game Loop die Funktion "SetEvent(StartEvent)" aufruft. Somit läuft jetzt erst mal das Thread Programm und berechnet die eben z.B. die Physik o.ä.. Währenddessen rendert der MainThread z.B. die Map. Du musst dabei aber aufpassen, dass du nicht auf die selben Objekte zugreifst wie der Thread, denn sonst passieren unvorhersehbare Dinge. Also, nachdem der MainThread dann seine ganze (Render)arbeit erledigt hat wartet er auf das "EndEvent", das am Ende der Endlosschleife im Thread gesetzt wird, also nachdem alle Berechnungen fertig sind. Da das Thread Programm jetzt wieder auf das "StartEvent" wartet kann man sicher sein, dass er auf keine Objekte zugreift und so kann ich dann z.B. die eben Berechneten Partikel rendern.
Auf dem Bild sind die Pfeile nach rechts die "WaitForSingleObject(EndEvent)" Stellen. Ich wusste nicht wie ich das anders darstellen soll. Es bedeutet jedenfalls einfach dass der MainThread eben auf den anderen wartet, das sind also sozusagen Synchronisationspunkte.
Den Input hab ich ans Ende gemacht, weil:
1. Input häufig mit der Veränderung von Objekten zu tun hat und diese evtl. gerade von einem der anderen Threads bearbeitet werden.
2. Wenn die ganzen Renderinganweisungen erst mal raus sind und die Graka rendert, dann macht meine CPU nichts. Deswegen verarbeite ich nach dem Rendering die Eingaben, da ich sowieso auf die Graka warten muss (bis ich z.B. bei D3D Present() aufrufen könnte). Heutzutage fällt meinen Erfahrungen nach kaum-gar nicht auf, aber ich habe irgendwo mal gelesen, dass das durchaus vorkommen kann. Und da ich nicht gezwungen bin den Input am Anfang zu machen, mach ich ihn eben am Ende
Theoretisch hast du eigentlich schon eine Multicore Anwendung, wenn du mehrere Threads verwendest, denn als Programmierer hast du 0 Einfluss darauf, welcher Thread auf welchem Kern läuft. Das wird dynamisch vom OS verwaltet. Das Multithreading lohnt sich auch nur, wenn du wirklich etwas gut parallelisieren kannst. Also es sollten möglichst beide Threads was zu tun haben. Es bringt nichts, wenn der eine nach ner halben ms schon fertig ist und dann ewig wartet bis die Physik berechnet wurde.
Was die Synchronisation deiner Threads 10-20 angeht: Verwende so wenige CriticalSections etc. wie möglich (ich benutze im Moment gar keine, nur die Events), denn das kann schon einiges an Performance fressen, wenn du ständig CSs betrittst und verlässt. Events sind da schon leistungsschonender, aber erfordern von dir etwas mehr Verwaltungsaufwand (den Überblick bei 10-20 Threads zu behalten ist sicher hart).
Lg
Der Thread bekommt die beide als Parameter mit. Die Threadfunktion läuft dann in einer Endlosschleife (while(true)) und ganz am Anfang der Schleife wird dann "WaitForSingleObject(StartEvent)" aufgerufen, während der Main Thread am Anfang der Game Loop die Funktion "SetEvent(StartEvent)" aufruft. Somit läuft jetzt erst mal das Thread Programm und berechnet die eben z.B. die Physik o.ä.. Währenddessen rendert der MainThread z.B. die Map. Du musst dabei aber aufpassen, dass du nicht auf die selben Objekte zugreifst wie der Thread, denn sonst passieren unvorhersehbare Dinge. Also, nachdem der MainThread dann seine ganze (Render)arbeit erledigt hat wartet er auf das "EndEvent", das am Ende der Endlosschleife im Thread gesetzt wird, also nachdem alle Berechnungen fertig sind. Da das Thread Programm jetzt wieder auf das "StartEvent" wartet kann man sicher sein, dass er auf keine Objekte zugreift und so kann ich dann z.B. die eben Berechneten Partikel rendern.
Auf dem Bild sind die Pfeile nach rechts die "WaitForSingleObject(EndEvent)" Stellen. Ich wusste nicht wie ich das anders darstellen soll. Es bedeutet jedenfalls einfach dass der MainThread eben auf den anderen wartet, das sind also sozusagen Synchronisationspunkte.
Den Input hab ich ans Ende gemacht, weil:
1. Input häufig mit der Veränderung von Objekten zu tun hat und diese evtl. gerade von einem der anderen Threads bearbeitet werden.
2. Wenn die ganzen Renderinganweisungen erst mal raus sind und die Graka rendert, dann macht meine CPU nichts. Deswegen verarbeite ich nach dem Rendering die Eingaben, da ich sowieso auf die Graka warten muss (bis ich z.B. bei D3D Present() aufrufen könnte). Heutzutage fällt meinen Erfahrungen nach kaum-gar nicht auf, aber ich habe irgendwo mal gelesen, dass das durchaus vorkommen kann. Und da ich nicht gezwungen bin den Input am Anfang zu machen, mach ich ihn eben am Ende
Theoretisch hast du eigentlich schon eine Multicore Anwendung, wenn du mehrere Threads verwendest, denn als Programmierer hast du 0 Einfluss darauf, welcher Thread auf welchem Kern läuft. Das wird dynamisch vom OS verwaltet. Das Multithreading lohnt sich auch nur, wenn du wirklich etwas gut parallelisieren kannst. Also es sollten möglichst beide Threads was zu tun haben. Es bringt nichts, wenn der eine nach ner halben ms schon fertig ist und dann ewig wartet bis die Physik berechnet wurde.
Was die Synchronisation deiner Threads 10-20 angeht: Verwende so wenige CriticalSections etc. wie möglich (ich benutze im Moment gar keine, nur die Events), denn das kann schon einiges an Performance fressen, wenn du ständig CSs betrittst und verlässt. Events sind da schon leistungsschonender, aber erfordern von dir etwas mehr Verwaltungsaufwand (den Überblick bei 10-20 Threads zu behalten ist sicher hart
). Lg
TE
TE
KingofKingzZ
Software-Overclocker(in)
Soo, hier mal wieder ein kleines Update zum Game
Ich habe jetzt den Mapgenerator grundlegend fertiggestellt.
Im Moment erstellt er ein 80.000x80.000 Pixel großes Universum mit (jeweils Durchschnittswerte, da zufällig) ~250 Sternen, ~450 Planeten, ~200 Monden sowie einer "unbegrenzten" Anzahl an Asteroiden. Bei den Asteroiden gibt es aber eine kleine Ausnahme. Sie sind nicht von Anfang an da, sondern werden on-the-fly rund um das Sichtfeld gespawnt und wieder gelöscht, wenn sie weiter weg sind. Falls ein Asteroid aber später mal in die Nähe einer Kolonie kommen sollte bekommt er ein Flag, dass er nicht automatisch zerstört werden darf, da es ja etwas langweilig wäre, wenn man bei Asteroidengefahr einfach mit der Kamera kurz weg geht und alles ist wieder heil
Das ganze habe ich gemacht, weil die Anzahl an Asteroiden, die ich zu Beginn hätte generieren müssen viel zu groß gewesen wäre (~16.000), um das ganze anständig in Echtzeit mit Gravitation zu berechnen. So habe ich jetzt kaum Performance Verlust durch die Gravitations Physik (momentan ~300-500 FPS), es sieht gleich aus und spielerisch dürfte es später auch kaum Unterschiede geben.
Zur Zeit ist das Universum noch auf diese Größe beschränkt, doch die nächsten Tage werd ich das mal ausbauen, sodass weitere Teile im Hintergrund generiert werden, sobald man mit der Kamera nahe an den Rand des Universums kommt. Außerdem mache ich mich jetzt erst mal daran den ganzen Code aufzuräumen und widme mich dann der Kollisionserkennung (die übrigens im Physik Thread läuft).
Lg
Ich habe jetzt den Mapgenerator grundlegend fertiggestellt.
Im Moment erstellt er ein 80.000x80.000 Pixel großes Universum mit (jeweils Durchschnittswerte, da zufällig) ~250 Sternen, ~450 Planeten, ~200 Monden sowie einer "unbegrenzten" Anzahl an Asteroiden. Bei den Asteroiden gibt es aber eine kleine Ausnahme. Sie sind nicht von Anfang an da, sondern werden on-the-fly rund um das Sichtfeld gespawnt und wieder gelöscht, wenn sie weiter weg sind. Falls ein Asteroid aber später mal in die Nähe einer Kolonie kommen sollte bekommt er ein Flag, dass er nicht automatisch zerstört werden darf, da es ja etwas langweilig wäre, wenn man bei Asteroidengefahr einfach mit der Kamera kurz weg geht und alles ist wieder heil
Das ganze habe ich gemacht, weil die Anzahl an Asteroiden, die ich zu Beginn hätte generieren müssen viel zu groß gewesen wäre (~16.000), um das ganze anständig in Echtzeit mit Gravitation zu berechnen. So habe ich jetzt kaum Performance Verlust durch die Gravitations Physik (momentan ~300-500 FPS), es sieht gleich aus und spielerisch dürfte es später auch kaum Unterschiede geben.
Zur Zeit ist das Universum noch auf diese Größe beschränkt, doch die nächsten Tage werd ich das mal ausbauen, sodass weitere Teile im Hintergrund generiert werden, sobald man mit der Kamera nahe an den Rand des Universums kommt. Außerdem mache ich mich jetzt erst mal daran den ganzen Code aufzuräumen und widme mich dann der Kollisionserkennung (die übrigens im Physik Thread läuft).
Lg
fadade
BIOS-Overclocker(in)
Das war auch mein erster gedankeFalls ein Asteroid aber später mal in die Nähe einer Kolonie kommen sollte bekommt er ein Flag, dass er nicht automatisch zerstört werden darf, da es ja etwas langweilig wäre, wenn man bei Asteroidengefahr einfach mit der Kamera kurz weg geht und alles ist wieder heil
... ich cheater Allerdings wenn jetz so ein Asteroid (oder sinds vllt Kometen? Oder doch Meteoriten? xDD ) eine Bahn einschlägt, die später iwwo weiter woanders einen Planeten *hust* kreuzen würde und der Asteroid (bzw. Himmelskörper
) wird gelöscht, dann ist der entferntere Planet ja auch "gerettet".Daraus könnte ja der Vorschlag entstehen, dass du verschiedene Modi/Schwierigkeitsgrade machst und auf "Schwer" oder "SImulation" werden halt weniger Asteroiden berechnet, aber dafür bleiben die dann auch die gesate Zeit bestehen (bis außerhalb des Universums). dürfte ja ähnlich rechenaufwendig sein, wenn man für die Gravi etc. nur etwas nähere andere Objekte einbezieht
Waaaas? 16k Objekte und deren Berechnungen gehen ned? Hast du etwa kein Quad-Xeon-System als Mindestanforderung?
PS: Ich hab heute inner Firma nun auch diese Massive-Multithreaded-Communication-Pipeline angefangen und das erste ergebnis war ... schon komisch.
Alle Threads haben trotz eigentlich vorhandenen Wartezyklen (gesteuert vom Controllerthread) an die ausgangsgeräte wirres zeug geschickt und falsche Werte der Berechnungen benutzt. Ergebnis: 3 Geräte im Dutten und ein Besuch beim Chef à la "duuu.. mein praktikant hat da was gemacht ... "
Naja, aber wenn du EINFACHEN und möglichst CHRONOLOGISCHEN, also NICHT-PARALLELEN sachen hilfe brauchst, ikke bin gerne da
und damit gehts erstmal ab abendessen
TE
TE
KingofKingzZ
Software-Overclocker(in)
Das war auch mein erster gedanke
Allerdings wenn jetz so ein Asteroid (oder sinds vllt Kometen? Oder doch Meteoriten? xDD ) eine Bahn einschlägt, die später iwwo weiter woanders einen Planeten *hust* kreuzen würde und der Asteroid (bzw. Himmelskörper
Daraus könnte ja der Vorschlag entstehen, dass du verschiedene Modi/Schwierigkeitsgrade machst und auf "Schwer" oder "SImulation" werden halt weniger Asteroiden berechnet, aber dafür bleiben die dann auch die gesate Zeit bestehen (bis außerhalb des Universums). dürfte ja ähnlich rechenaufwendig sein, wenn man für die Gravi etc. nur etwas nähere andere Objekte einbezieht
Kann auch sein dass es Meteoriten oder Kometen sind, ich nenn sie jetzt einfach mal Objekte^^.
Da hast du Recht, das könnte natürlich sein. Allerdings ist es für den Spieler relativ egal, ob dieses "Objekt" jetzt vor 5 Minuten gespawnt wurde und seitdem die Performance runterzieht, oder ob ich von Zeit zu Zeit einfach zufällig in der Nähe eines (bewohnten)Planeten ein paar Objekte spawne und diese dann mit ner LifeTime sowie dem "nicht zerstören" Flag versehe.
Eine weitere Möglichkeit wäre dass etwa 1/5 der Objekte das Flag erhält und der Rest nicht.. Naja, ich denke ich lass es jetzt erst mal so und schau wie es sich dann später spielerisch verhält.
Lässt sich ja schnell ändern.
Waaaas? 16k Objekte und deren Berechnungen gehen ned? Hast du etwa kein Quad-Xeon-System als Mindestanforderung?
Von mir aus können da 100 Xeons drin Stecken, das lässt sich relativ schlecht parallelisieren. Das Problem ist, dass ich mit jedem Objekt durch alle Sterne, Monde + Planeten iterieren muss, schaun muss ob sie in Reichweite sind (so ne Art Culling) und dann letztlich noch die Gravitation berechnen muss. Das wären dann bei der Map 14,4 Millionen Berechnungen, die ich mindestens alle 25 Frames ausführen muss, was sich in hässlichen 100ms Lags zeigt. Das ganze lässt sich wie gesagt auch nicht so einfach auf weitere Kerne verteilen, weil z.B. die Sterne von beiden Threads gleichzeitig benötigt werden würden. Da ist meine jetzige Lösung schon deutlich schöner, auch vom "Spielgefühl" her. Aussehen tuts fast gleich und spielerisch wird sich wie gesagt dann zeigen.
ein Besuch beim Chef à la "duuu.. mein praktikant hat da was gemacht ... "
MfG King
fadade
BIOS-Overclocker(in)
hmmm... kommt wohl auf die Art der Rechnungen an, denn bei CUDA und Co. scheinen viele parallele Recheneinheiten ja auch viel Performance zu bieten, aber kp, was denn da genau gerechnet wird^^
Bzw. ..... .. kannst du nicht deine Berechnungen auch noch etwas aufteilen? ich nehme mal an, dass jedes Objekt ja ne instanz einer klasse ist halt (oder so ähnlich ausgedrückt
) und die dann so Variablen, wie Masse, Geschw., HP, und was auch immer haben. Und dann auch sowas wie 2D-Richtungsvektoren und Impuls und so?Dann könnte man da ja noch ausschau halten nach werten, die unabhängig voneinander sind. also wat weiß ich ... Position ist ja mitm richtungsvektor verbunden, der mit Geschw .... das lässt sich nicht trennen, aber was anderes vllt
z.B. die Physik rechts im Bild wird von dem Thread übernommen, währen links ein anderer macht
aber da kannste dann ja noch schauen.
Btw .... ich will auchmal spielen
Jajaaa.. Berechnungen sparen wo es nur geht
Kommt denn der ganze Rechenaufwand für spieleraktionen auch noch in nen Thread? also so betreffend Wirtschaft und so nem Kram?
tz tz tz .. also das hab ja selbst ICH schon in der 5. oder 6. Klasse geschafft!
Jaja ..erste Gehversuche mit Multithreading sind gar nicht mal so leicht finde ich (und dann gleich 18 Stück davon -.-)
TE
TE
KingofKingzZ
Software-Overclocker(in)
Das Problem sind ja nicht die Berechnungen/Simulation der Objekte selbst, sondern einfach die Schiere Masse davon.
Wie gesagt, bei einer Aufteilung müssten beide Threads ja z.B. die "Liste" der Sterne besitzen um die Gravitation zu berechnen.
Um gleichzeitiges Zugreifen zu verhindern müsste ich entweder direkt vor dem Eintritt in die "Sternen-Schleife" eine Critical Section betreten oder bei jeder einzelnen Iteration.
Im ersten Fall müsste der 2. Thread ewig warten -> Parallelisierung dahin
Im zweiten Fall wäre es zwar noch einigermaßen Parallel, aber ich würde ~80% der Zeit damit verbringen die Sections zu betreten und zu verlassen.
Damit wäre es in beiden Fällen wahrscheinlich noch langsamer als davor, da mit den Threads natürlich auch noch ein gewisser Overhead mitkommt.
Generell ist es eigentlich eine schlechte Idee zu versuchen sogar einzelne Objekte in verschiedene Threads zu "reißen". Man sollte lieber Dinge suchen, die sich gut vertragen, wie z.B. Rendering, größere Berechnungen oder Audio.
Mit CUDA oder OpenCL könnte man jetzt z.B. Blitzschnell die Umlaufbahnen von 20 Mio Objekten um 1 Stern berechnen. Wenn das mehr werden, muss aber auch die Graka auch erst mal die Daten für den 2. Stern in den Cache bekommen etc. Aber mit GPGPU kenn ich mich eher weniger aus.
Die gesamte Spiellogik (abgesehen von KI) wird noch in den MainThread (der mit dem Rendering) kommen. Die Kollisionsberechnung kommt in den PhysikThread, das wird so ablaufen:
Der PhysikThread hat einen Pointer auf ne std::map (Object,Object) und wenn eine Kollision festgestellt wurde, wird dort ein Eintrag erstellt. Anschließend wertet der MainThread diese Map aus und reagiert mit der entsprechenden Spiellogik.
Im 3. Thread werden dann noch die Partikel simuliert, soweit der Plan. Audio läuft bei mir von allein in nem eigenen Thread, da muss ich mich um nichts kümmern. Und später dann evtl. noch KI und/oder Netzwerk, aber soweit hab ich noch nicht geplant.
Es wird auch wie gesagt bald so ne Art Universumsdemo geben (noch ohne richtige Spielelemente). Mein Plan für die nächsten Tage sieht so aus:
heute noch: Code fertig aufräumen
morgen: Kollisionen
2.9.: Partikelsystem verbessern
3.9.: Partikelsystem integrieren
4.9.: Interaktion für die Demo integrieren
Wird also noch ein paar Tage dauern, bis ihr den Fortschritt in Bewegung sehen könnt.
Lg King
Wie gesagt, bei einer Aufteilung müssten beide Threads ja z.B. die "Liste" der Sterne besitzen um die Gravitation zu berechnen.
Um gleichzeitiges Zugreifen zu verhindern müsste ich entweder direkt vor dem Eintritt in die "Sternen-Schleife" eine Critical Section betreten oder bei jeder einzelnen Iteration.
Im ersten Fall müsste der 2. Thread ewig warten -> Parallelisierung dahin
Im zweiten Fall wäre es zwar noch einigermaßen Parallel, aber ich würde ~80% der Zeit damit verbringen die Sections zu betreten und zu verlassen.
Damit wäre es in beiden Fällen wahrscheinlich noch langsamer als davor, da mit den Threads natürlich auch noch ein gewisser Overhead mitkommt.
Generell ist es eigentlich eine schlechte Idee zu versuchen sogar einzelne Objekte in verschiedene Threads zu "reißen". Man sollte lieber Dinge suchen, die sich gut vertragen, wie z.B. Rendering, größere Berechnungen oder Audio.
Mit CUDA oder OpenCL könnte man jetzt z.B. Blitzschnell die Umlaufbahnen von 20 Mio Objekten um 1 Stern berechnen. Wenn das mehr werden, muss aber auch die Graka auch erst mal die Daten für den 2. Stern in den Cache bekommen etc. Aber mit GPGPU kenn ich mich eher weniger aus.
Die gesamte Spiellogik (abgesehen von KI) wird noch in den MainThread (der mit dem Rendering) kommen. Die Kollisionsberechnung kommt in den PhysikThread, das wird so ablaufen:
Der PhysikThread hat einen Pointer auf ne std::map (Object,Object) und wenn eine Kollision festgestellt wurde, wird dort ein Eintrag erstellt. Anschließend wertet der MainThread diese Map aus und reagiert mit der entsprechenden Spiellogik.
Im 3. Thread werden dann noch die Partikel simuliert, soweit der Plan. Audio läuft bei mir von allein in nem eigenen Thread, da muss ich mich um nichts kümmern. Und später dann evtl. noch KI und/oder Netzwerk, aber soweit hab ich noch nicht geplant.
Es wird auch wie gesagt bald so ne Art Universumsdemo geben (noch ohne richtige Spielelemente). Mein Plan für die nächsten Tage sieht so aus:
heute noch: Code fertig aufräumen
morgen: Kollisionen
2.9.: Partikelsystem verbessern
3.9.: Partikelsystem integrieren
4.9.: Interaktion für die Demo integrieren
Wird also noch ein paar Tage dauern, bis ihr den Fortschritt in Bewegung sehen könnt.
Lg King
J
joffal
Guest
..... ziemlick kompliziert so ein Spiel (sogar auch "nur" in 2D) zu programmieren 
Wie schauts eigentlich aus, wenn die Grakazwar jedes Frame rendert, die CPU einige Dinge aber nur alle 2 Frames berechnet, bzw. einer großen Objektmenge 2 Frames Zeit gibt da iwwas zu berechnen. Muss man halt nur schauen, dass da wieder nichts durcheinanderkommt ...
Weil ICH könnte damit leben, wenn irgendeine Geschwindigkeit oder Position von asteroiden nur alle 2 Frames geändert wird (also ja alle xyz Millisekunden )
Wie schauts eigentlich aus, wenn die Grakazwar jedes Frame rendert, die CPU einige Dinge aber nur alle 2 Frames berechnet, bzw. einer großen Objektmenge 2 Frames Zeit gibt da iwwas zu berechnen. Muss man halt nur schauen, dass da wieder nichts durcheinanderkommt ...
Weil ICH könnte damit leben, wenn irgendeine Geschwindigkeit oder Position von asteroiden nur alle 2 Frames geändert wird (also ja alle xyz Millisekunden
)
TE
TE
KingofKingzZ
Software-Overclocker(in)
Das mache ich ja auch so, aber das Problem bei den Asteroiden oben war einfach, dass es zu viele auf einmal waren. Wenn dann alle 30 FPS plötzlich ein 100ms Lag drin ist, wobei alle anderen Frames nur 2,5ms brauchen, fühlt sich das schon ziemlich hässlich an
Und 2 Frames Zeit nehmen geht nicht immer, weil ich spätestens vor dem Input warten müsste, da ich dort wieder teilweise auf Objekte zugreifen müsste.
Theoretisch wäre es eigentlich noch relativ einfach das ganze zu programmieren, was ich bis jetzt habe, aber die Optimierungen sind halt teilweise etwas komplizierter, aber da gewöhnt man sich dran
Und 2 Frames Zeit nehmen geht nicht immer, weil ich spätestens vor dem Input warten müsste, da ich dort wieder teilweise auf Objekte zugreifen müsste.
Theoretisch wäre es eigentlich noch relativ einfach das ganze zu programmieren, was ich bis jetzt habe, aber die Optimierungen sind halt teilweise etwas komplizierter, aber da gewöhnt man sich dran
TE
TE
KingofKingzZ
Software-Overclocker(in)
Wenn ihr Ideen habt, immer her damit, das Spiel kann dadurch ja nur besser werden
Ich habe noch keine inhaltlichen Dinge festgelegt, die unbedingt rein müssen, im Moment konzentriere ich mich auf die Technik und mach diese fertig, damit ich mich danach voll und ganz dem Inhalt widmen kann. Ihr habt bei Ideen also völlige Freiheit
Lg King
Ich habe noch keine inhaltlichen Dinge festgelegt, die unbedingt rein müssen, im Moment konzentriere ich mich auf die Technik und mach diese fertig, damit ich mich danach voll und ganz dem Inhalt widmen kann. Ihr habt bei Ideen also völlige Freiheit
Lg King
TE
TE
KingofKingzZ
Software-Overclocker(in)
Seit meinem letzten "Update" hat sich einiges getan:
- Kollisionserkennung nun fertig
- Unschärfe Shader hinzugefügt, seine Stärke ändert sich je nach Zoom (für die die es hassen: Er ist abschaltbar zu jeder Zeit)
- Singlethreading hinzugefügt (für ältere PCs, Laptops etc.)
- Im Menü die Optionen "Unschärfe" und "Multithreading" hinzugefügt
- Performance ein kleines Stück verbessert (aber nichts großartiges)
Als nächstes gehe ich jetzt die Partikel an. Außerdem bastel ich grad an ner Art "Light-Shader" (keine Ahnung wie ich es beschreiben soll), für Sterne etc.
Hier ist noch ein Screen der Unschärfe, leider erkennt man sie auf dem Bild nicht soo gut, in Echtzeit siehts etwas besser aus wie ich finde.
Ah ja: Hintergründe gibts auch mal bald neue, die gefallen mir eigentlich überhaupt nicht.^^ Zu unscharf und zu große Sterne oder was auch immer..
Lg King
Edit: Das Projekt besteht jetzt übrigens aus 2207 Zeilen (+ Engine (~3-4k)), wovon 1002 auf Kosten der Map gehen.
- Kollisionserkennung nun fertig
- Unschärfe Shader hinzugefügt, seine Stärke ändert sich je nach Zoom (für die die es hassen: Er ist abschaltbar zu jeder Zeit
)- Singlethreading hinzugefügt (für ältere PCs, Laptops etc.)
- Im Menü die Optionen "Unschärfe" und "Multithreading" hinzugefügt
- Performance ein kleines Stück verbessert (aber nichts großartiges)
Als nächstes gehe ich jetzt die Partikel an. Außerdem bastel ich grad an ner Art "Light-Shader" (keine Ahnung wie ich es beschreiben soll), für Sterne etc.
Hier ist noch ein Screen der Unschärfe, leider erkennt man sie auf dem Bild nicht soo gut, in Echtzeit siehts etwas besser aus wie ich finde.
Ah ja: Hintergründe gibts auch mal bald neue, die gefallen mir eigentlich überhaupt nicht.^^ Zu unscharf und zu große Sterne oder was auch immer..
Lg King
Edit: Das Projekt besteht jetzt übrigens aus 2207 Zeilen (+ Engine (~3-4k)), wovon 1002 auf Kosten der Map gehen.
Zuletzt bearbeitet:
Dann mal mein kleiner Inhaltsbeitrag ^^
Ich würde 3-4 verschiedene Rohstoffe machen.
Titan, Silizium und Iridium (oder sowas) als Rohstoffe die zum Bauen benötigt werden.
Wasserstoff ist so ne sache. Als Treibstoff würde ich ihn nicht wählen evtl als Zusatz Rohstoff für den Raumschiffbau.
Einen eigenen Raumschifftreibstoff zum herstellen würde ich für ein RTG eher ablehnen weil du musst bedenken die Handelsschiffe die automatisch herumfliegen brauchen ihn und deine Flotte braucht ihn. Wird logistisch denke ich eine zugroße Herausforderung mit wachsendem Reich.
Was sich aber in dem ein oder anderem RTG durchgesetzt hat das jedes Raumschiff einen vordefinierten "Tank" hat und es aber noch spezielle Tankerschiffe gibt zb bei offensiven oder größeren Handelsflotten die weite Strecken zurücklegen müssen mitgeschickt werden können und die anderen Schiffe dann mit Treibstoff versorgen.
Da fällt mir nochwas ein ^^
Da du es ja so mit deinen Asteroiden hast ^^
Asteroiden sind ja meist Reich an Metallen. Da wäre noch so die idee das man Bewusst die Laufbahn von Asteroiden verändern kann das diese Als Rohstofflieferanten dienen können. Aber weiß ich nicht inwieweit das machbar sein sollte.
Entweder durch gezielten einschlag auf dem Heimaplaneten durch gezielte Gravitationsänderung (in einem Speziell dafür vorgesehenem Bereich/Gebäude) oder im Späteren Spiel verlauf direkt durch Abbauschiffe.
So das wars jetzt aber erstmal ^^
Falls irgendwelche Fragen sind frag xD
Ich würde 3-4 verschiedene Rohstoffe machen.
Titan, Silizium und Iridium (oder sowas) als Rohstoffe die zum Bauen benötigt werden.
Wasserstoff ist so ne sache. Als Treibstoff würde ich ihn nicht wählen evtl als Zusatz Rohstoff für den Raumschiffbau.
Einen eigenen Raumschifftreibstoff zum herstellen würde ich für ein RTG eher ablehnen weil du musst bedenken die Handelsschiffe die automatisch herumfliegen brauchen ihn und deine Flotte braucht ihn. Wird logistisch denke ich eine zugroße Herausforderung mit wachsendem Reich.
Was sich aber in dem ein oder anderem RTG durchgesetzt hat das jedes Raumschiff einen vordefinierten "Tank" hat und es aber noch spezielle Tankerschiffe gibt zb bei offensiven oder größeren Handelsflotten die weite Strecken zurücklegen müssen mitgeschickt werden können und die anderen Schiffe dann mit Treibstoff versorgen.
Da fällt mir nochwas ein ^^
Da du es ja so mit deinen Asteroiden hast ^^
Asteroiden sind ja meist Reich an Metallen. Da wäre noch so die idee das man Bewusst die Laufbahn von Asteroiden verändern kann das diese Als Rohstofflieferanten dienen können. Aber weiß ich nicht inwieweit das machbar sein sollte.
Entweder durch gezielten einschlag auf dem Heimaplaneten durch gezielte Gravitationsänderung (in einem Speziell dafür vorgesehenem Bereich/Gebäude) oder im Späteren Spiel verlauf direkt durch Abbauschiffe.
So das wars jetzt aber erstmal ^^
Falls irgendwelche Fragen sind frag xD
TE
TE
KingofKingzZ
Software-Overclocker(in)
Danke, nicht schlecht
Bei den Rohstoffen hatte ich auch an 3-4 verschiedene gedacht, die zum Bau von Gebäuden und Raumschiffen notwendig sind.
Das mit den Wasserstoff ist mir auch schon durch den Kopf gegangen, dass das wohl doch keine soo gute Idee ist. Wäre ja auch ziemlich ärgerlich wenn mitten im Gefecht der Treibstoff aus geht xD. Was aber möglich wäre, dass man sich für seine Schiffe Upgrades kaufen kann und eins davon wäre eben ein Boost-Geschwindigkeits Upgrade, welches allerdings Wasserstoff benötigt (während dem Flug, nicht die Erforschung). Wenn der Wasserstoff leer ist, würde das Schiff eben nur mit normaler Geschwindigkeit fliegen. Für Handelsschiffe oder auch allgemein für Raumschiffe könnte man ja festlegen, dass die Schiffe, sofern das Upgrade vorhanden ist, sich selbst auftanken, sobald sie irgendwo landen und in der Station genug vorrätiger Wasserstoff ist. Tankerschiffe sowie Tank-Upgrades für einen größeren Tank wären ja dann auch möglich. Die Tankschiffe würden bei Beschuss sicher ne nette Explosion verursachen
Das mit den Asteroiden ist auch ne gute Idee. Man könnte eine Art Raumstation errichten, von welcher dann automatisch kleine Mini-Schiffchen zu den Asteroiden in der Umgebung fliegen und diese "aufsammeln". Außerdem könnte man ja als Upgrade oder auch als eigenständiges Gebäude ein Gravitationsfeld im All platzieren, das dann die Asteroiden anzieht und sobald sie in dem Feld sind, gefangen hält. Da können sie dann abgeholt werden.
Dann hab ich noch über "Luxusgüter" oder sowas nachgedacht, eben Stoffe, die aus anderen Hergestellt werden, aber nicht zwingend notwendig sind, sondern, wie im Beispiel oben der Wasserstoff, zusätzlich etwas bringen oder für spezielle Forschung/Upgrades o.ä. notwendig sind. Was hältst du davon?
Lg King
Bei den Rohstoffen hatte ich auch an 3-4 verschiedene gedacht, die zum Bau von Gebäuden und Raumschiffen notwendig sind.
Das mit den Wasserstoff ist mir auch schon durch den Kopf gegangen, dass das wohl doch keine soo gute Idee ist. Wäre ja auch ziemlich ärgerlich wenn mitten im Gefecht der Treibstoff aus geht xD. Was aber möglich wäre, dass man sich für seine Schiffe Upgrades kaufen kann und eins davon wäre eben ein Boost-Geschwindigkeits Upgrade, welches allerdings Wasserstoff benötigt (während dem Flug, nicht die Erforschung). Wenn der Wasserstoff leer ist, würde das Schiff eben nur mit normaler Geschwindigkeit fliegen. Für Handelsschiffe oder auch allgemein für Raumschiffe könnte man ja festlegen, dass die Schiffe, sofern das Upgrade vorhanden ist, sich selbst auftanken, sobald sie irgendwo landen und in der Station genug vorrätiger Wasserstoff ist. Tankerschiffe sowie Tank-Upgrades für einen größeren Tank wären ja dann auch möglich. Die Tankschiffe würden bei Beschuss sicher ne nette Explosion verursachen
Das mit den Asteroiden ist auch ne gute Idee. Man könnte eine Art Raumstation errichten, von welcher dann automatisch kleine Mini-Schiffchen zu den Asteroiden in der Umgebung fliegen und diese "aufsammeln". Außerdem könnte man ja als Upgrade oder auch als eigenständiges Gebäude ein Gravitationsfeld im All platzieren, das dann die Asteroiden anzieht und sobald sie in dem Feld sind, gefangen hält. Da können sie dann abgeholt werden.
Dann hab ich noch über "Luxusgüter" oder sowas nachgedacht, eben Stoffe, die aus anderen Hergestellt werden, aber nicht zwingend notwendig sind, sondern, wie im Beispiel oben der Wasserstoff, zusätzlich etwas bringen oder für spezielle Forschung/Upgrades o.ä. notwendig sind. Was hältst du davon?
Lg King
Nichts zu danken ^^ man versucht zu helfen wo man(n) kann ^^Danke, nicht schlecht
Wäre eine Option und sicher Strategisch interresant wie man sie zb auch einstellen kann.
zb das für HS das automatisch bei erkennen von Feindflotten angeht zb um zu flüchten oder nach dem start vom anfangspunkt. vllt auch das man es sich aussuchen kann.
Wäre sicher interresant und vorallem eine Lösung das "Problem" in den griff zu bekommen.
Vorallem kannst du da auch wieder ein wenig mit der Gravitation spielen ^^Tankerschiffe sowie Tank-Upgrades für einen größeren Tank wären ja dann auch möglich. Die Tankschiffe würden bei Beschuss sicher ne nette Explosion verursachen
Ich würde evtl sogar sagen das die Tankschiffe nur für den Boost zuständig sind. Weil es dann auch realistischer ist. und zum betanken muss die Flotte anhalten (auch aus realismusgründen)
Ich würde sagen als "Grundform" nur eine Raumstation die die kleinen abbauschiffe rum schickt um die asteroiden in der nähe abzugrasen und dann als eigenständiges gebäude einen Gravitationsgenerator denn man vllt sogar als art waffe einsetzten kann um zb teile feindlicher Flotten zu behindern bzw aufzuhalten (ala Tranktorstrahl)
Wasserstoff wäre ja im grunde eine Art Luxusgut. was ich ansich nicht schlecht finde.
Ich würde aber dann nur 2 reine Rohstoffe die du zm bauen brauchst (also Titan und Silicium) und dann vllt noch 2 "Edel/Luxusgüter" die man u.a. für Forschungen braucht.
Wasserstoff halt zum Forschen und für den Boost und zb Platinum als "Statussymbol" oder ein anderer Stoff für spezielle Forschungen.
Genauso würde ich dann aber die Produktion dieser beider Edelgüter etwas teurer gestalten bzw deutlich langsamer machen als die von Tit und Sili.
Dann wärst du wieder bei 4 Rohstoffen
Titan+Silicium als Grundgerüst um den Aufbau deines Heimatplaneten zu gestallten und der Kolonien sowie der Flotte.
Wasserstoff (denn ich erst nach einigem Wachstum erreichbar machen würde) als Edelgut um auch bessere Taktischevorteile und noch stärkere Forschungen zu erlangen.
Umd zum Schluss ein Reines Luxusgut was zb für Forschung oder als Siegziel benutzt werden kann.
Dann auch die Siegziele würde ich entsprechend variabell machen.
Einzigerüberlebender (Galaxy Domination Tour)
-> erklärt sich glaub ich von alleine ^^
Völkerbund (fällt mir kein toller name ein xD)
-> Bündniss mit allen (überlebenden) Völkern
Handelspartner
-> Mit allen (überlebenden) Völkern ein Handelsabkommen wobei man das noch irgendwie verfeinern müsste
Und zu gut erletzt noch ein Freies Spielen mit evtl vereinzelnt mal auftauchenden Priaten oder so ^^
Ich hoffe mein Roman ist nicht zulange *hust*
Greez D
TE
TE
KingofKingzZ
Software-Overclocker(in)
Okay, ihr habt mich überzeugt, 2 Rohstoffe für den Bau sind genug. Titan und Silicium hören sich da schon mal nicht schlecht an. Und für die oben beschriebenen Dinge Wasserstoff und vllt. Uran o.ä.? Dann wären Atomtechnologien möglich, die aber natürlich nicht zwingend sein müssen. Letztendlich werden wir wohl testen müssen, wie viele Rohstoffe am besten sind, ich denke das Balancing (und die KI, weil ich da eher weniger Erfahrung habe ) wird sowieso das Schwierigste am ganzen Spiel.
Was haltet ihr von Energie (wie z.B. in C&C)? Sodass z.B. die Gebäude eines Planeten nicht funktionieren, wenn zu wenig Energie da ist. Da könnte man dann später auch mit dem Uran größere Kraftwerke bauen, die eben mehr Energie liefern, als die normalen, aber zum Bau etwas Uran brauchen.
Was mir auch noch eingefallen ist, damit etwas Abwechslung da ist, wären z.B. 3 verschiedene Völker, einmal die Menschen und dann müsste man sich halt noch 2 ausdenken. Die Völker hätten dann alle verschiedene Stärken was Einheiten betrifft etc. Es wäre auch möglich, dass die 3 Völker andere (Luxus?)Rohstoffe haben, die auf andere Art beschafft werden müssen, wie die der anderen Völker, wobei mir da die Ideen für verschiedene Quellen ausgehen
Außerdem könnten wir doch "Spezielfähigkeiten" wie die aus C&C oder Schlacht und Mittelerde (die links an der Seite) machen, oder ist das schon zu viel des Guten?
PS: Das Partikelsystem ist fertig, jetzt wird es noch integriert
Lg
) wird sowieso das Schwierigste am ganzen Spiel. Was haltet ihr von Energie (wie z.B. in C&C)? Sodass z.B. die Gebäude eines Planeten nicht funktionieren, wenn zu wenig Energie da ist. Da könnte man dann später auch mit dem Uran größere Kraftwerke bauen, die eben mehr Energie liefern, als die normalen, aber zum Bau etwas Uran brauchen.
Was mir auch noch eingefallen ist, damit etwas Abwechslung da ist, wären z.B. 3 verschiedene Völker, einmal die Menschen und dann müsste man sich halt noch 2 ausdenken. Die Völker hätten dann alle verschiedene Stärken was Einheiten betrifft etc. Es wäre auch möglich, dass die 3 Völker andere (Luxus?)Rohstoffe haben, die auf andere Art beschafft werden müssen, wie die der anderen Völker, wobei mir da die Ideen für verschiedene Quellen ausgehen
Außerdem könnten wir doch "Spezielfähigkeiten" wie die aus C&C oder Schlacht und Mittelerde (die links an der Seite) machen, oder ist das schon zu viel des Guten?
PS: Das Partikelsystem ist fertig, jetzt wird es noch integriert
Lg
Lemiewings
Komplett-PC-Aufrüster(in)
Klingt alles schon mal gut. Und ja, bitte mehr wie eine Rasse! Es gibt nix was ich in einem Strategiespiel mehr hasse als gegen mein Spiegelbild zu kämpfen, da vergeht mir sofort die lust... Aber bitte kein Viecher alla Zerg oder Tyraniden. Mochte diese rein Biologischen Viecher/Lebende Raumschiffe noch nie
Um beim Thema zu bleiben, würde ich sagen das es auf jeden Fall Menschen geben sollte. Da würden dann auch Wasserstoff und Uran als Sekundäre Ressourcen gut passen.
Ansonsten kann man sich hier denke ich vlt. ein wenig was abgucken
Master of Orion
Finde da sind einige verwertbare Sachen bei
Die Idee mit dem Stromverbrauch finde ich auch gut. Muss da grad an Ogame denken wo es Solarkraftwerke und Satelliten gab die je näher der Planet an der Sonne war, mehr Strom lieferten. Da würde dann auch wieder die Gravitation ins Spiel kommen, wenn die um den Planeten herumkreisen.
Ansonsten fällt mir grad auch nicht mehr viel ein.
Um beim Thema zu bleiben, würde ich sagen das es auf jeden Fall Menschen geben sollte. Da würden dann auch Wasserstoff und Uran als Sekundäre Ressourcen gut passen.
Ansonsten kann man sich hier denke ich vlt. ein wenig was abgucken
Master of Orion
Finde da sind einige verwertbare Sachen bei
Die Idee mit dem Stromverbrauch finde ich auch gut. Muss da grad an Ogame denken wo es Solarkraftwerke und Satelliten gab die je näher der Planet an der Sonne war, mehr Strom lieferten. Da würde dann auch wieder die Gravitation ins Spiel kommen, wenn die um den Planeten herumkreisen
.Ansonsten fällt mir grad auch nicht mehr viel ein.
Ähnliche Themen
