ZFX + Developia

<von der letzten seite>
@tiles : danke! schön zu wissen dass es weitere lurker gibt :D

die entwicklungsschritte: oben links erster test, die geschütze feuern dauernd und richten sich nach links aus... im zweiten bild stimmt die ausrchtung auf einen gegner. danach zwei tests mit unterschiedlichen basiselementen.


leider ist es ein schlag ins wasser. ich habs hinbekommen, dass die geschütze schön um den bot aufgereiht sind. sie suchen sich ein ziel aus und ballern drauf. der ausrichtungswinkel ist jeweils eingeschränkt so dass sie sich nicht gegenseitig beschiessen.
das problem: wenn ich die geschütze fix am bot habe gibts bei den kollisionen probleme. wenn sie nicht ganz fix sind, hecheln sie dem bot immer hinterher was schlecht ausschaut und die kollisionen sind weiterhin müll. was ich mit müll meine: sie können durch andere objekte hindurchfahren.
</ich bin ein doppelposter>


hab mal ne erste version von multi-schuss eingebaut zum testen. sieht eigentlich ganz witzig aus, aber ich seh heute nur probleme :roll:
multischuss -> vervielfachung der angriffskraft durch normales schiessen -> geschütztürme/assistenten/power-schuss/schwert werden alle verhältnismässig schwächer -> der original-schuss müsste stark abgeschwächt werden -> ohne upgrades ist man ziemlich verloren. das war in den alten arcade ballerspielen doch auch so? wenn man einmal drauf ging mit den ultra-geilen upgrades musste man von vorne mit dem aufsammeln beginnen, es wurde also verdammt viel schwieriger wieder ins spiel zu kommen. wenn die upgrades nicht verloren gehen, sind sie vor allem für eines da: zum geil ausschauen, da das balancing vom ganzen spiel auf einen hohen upgrade stand ausgelegt ist.

eine variante wäre beim multischuss, dass man die stärke eines einzelnen schusses durch die anzahl schüsse dividiert. hätte zur folge, dass man weniger schaden anrichtet, dafür mehr gegner treffen kann. das könnte strategisch noch ganz interessant sein. setzt aber voraus, dass der spieler die waffenart auswählen kann.

trippleposter...


irgendwas läuft einfach schief. der spielspass sinkt gegen ende des spiels immer mehr. irgendwann hat man den dreh raus, bzw. kann so viel einstecken, dass man sich nicht mega sorgen ums überleben macht.
ich muss mich darum kümmern, dass die späteren spinnen von der KI her interessanter werden. denke das könnte verhindern, dass es zu repetitiv wird.

habe bis zum endboss durchgehalten, die schwarzen spinnen sind aber kaum tot zu kriegen. zu viel hp. ein anderes problem ist, dass die geschütze irgenwann zu schwach werden (ich hab voll auf waffen und schilder gesetzt, von daher machts eigentlich sinn)
die assistenten waren auch mehr ein tropfen auf dem heisssen stein, als das sie wirklich nützlich/sinnvoll gewesen wären. eine möglichkeit wäre die waffenupgrades noch einmal abzuschwächen, aber auch die gegner schwächer zu machen (weniger hp).

Die neuste Version erlaubt mit einem Score-Malus unbeschränkt weiterzumachen. Irgendwann werde ich dann einen Minimalscore festlegen (vermutlich 100'000) der benötigt wird um weiterzumachen. Für jetzt ist es ganz praktisch, da man das ganze Spiel bis zum Ende spielen kann.


Ich habe die KI für die ersten 6 Spinnen verändert. Eigentlich ist es immer noch fast gleich, der Hauptunterschied ist, dass es jetzt nicht mehr über meine KI-Schnittstelle läuft. Das Problem mit der Schnittstelle: Ich habe sie für die damaligen PvP KI-Schlachten gebaut. Ich musste also auch verhindern, dass die KI auf Daten zugreift, die sie nicht haben darf. Ebenso musste ich absichern, dass nichts verändert wurde, das nicht verändert werden darf. Dies verlangt einige Wrapper-Klassen, die natürlich auch wieder Performance fressen. Im Bild sieht man die Spinnen unterschiedlich eingefärbt, das war für mich eine Hilfe zum debuggen. Die blauen haben Hexas im Visier, die grünen wollen den Spieler vernichten und die schwarzen irren umher.

marcgfx hat geschrieben:Performance fressen.

Wolltest du nicht Performance sparen? Du arbeitest doch allein an dem Projekt. Weißt du wie ich es bei mir mache? Ich scheiße einfach auf alles... ich habe mehr globale als lokale Variablen... ich habe soweit ich weiß, keine getter und setter und nicht wirklich viele Klassen, nur da wo es nötig ist. Man muss sich zwar nicht überall das Leben schwer machen, aber wenn du den Code selbst schreibst und der für dich ist, dann lerne auch, damit umzugehen und den zu beherrschen, auch wenn es nicht überall Netz und doppelten Boden gibt! :D
Naja, nur meine Meinung bzw. mein Tipp. Darum, mach es so, wie es dir Spass macht! :)

Jap, genau deswegen werde ich ja die Performancefresser los :). Die Umstellung in der KI erlaubt mir jetzt direkt auf die Daten zuzugreifen, anstatt die Wrapper zu vewenden. Habs auch schon mit 800 Spinnen getestet und es lief passabel. Bei der grossen Anzahl spielt aber der Kollisionscode wieder eine grosse Rolle.

Globale Variablen gibts schon einige, aber grad bei der KI brauche ich da eigentlich nichts.

Oh sorry, dann hab ich das nicht richtig mitbekommen :D

Wenn ich mir dein Krabbenbild da anschaue, erinnert mich das übrigens an...
[youtube]QKg7MI_iJN8[/youtube]

noch was bezüglich globale variablen. die sind in javascript für die performance schlecht!
mit dem lied kann ich so gar nix anfangen, aber schön dass du dabei an meine spinnen denkst :lol:

Naja, die sind auch in C++ für die Performance schlecht :D

(Adressierung durch eine globale Adresse ist drei Bytes länger als Adressierung relativ zu einem Register; man kann sich dann Ärger mit dem Decoder-Durchsatz oder der L1-Instruction-Bandbreite einfangen.)

Aber in JavaScript ist das wahrscheinlich dein geringstes Problem ;)

marcgfx hat geschrieben:mit dem lied kann ich so gar nix anfangen, aber schön dass du dabei an meine spinnen denkst :lol:

Ich finde, zumindest die "Spinnen" da im Bild sehen eher wie Krabben aus.

Krishty hat geschrieben:(Adressierung durch eine globale Adresse ist drei Bytes länger als Adressierung relativ zu einem Register; man kann sich dann Ärger mit dem Decoder-Durchsatz oder der L1-Instruction-Bandbreite einfangen.)

DANKE für den Tipp! :D
Wie ist das mit Globalen Arrays? Und meinst du Lokal, also in einer Klasseninstanz?

Lokal ist alles, was relativ zu einem Register ist. Ich habe keine Ahnung, was für Code dein Delphi da erzeugt, darum kann ich die Frage nicht beantworten. Ich weiß nur, dass mov rax, [0x12345678] quasi doppelt so groß ist wie mov rax, [ebp+123]. Guck halt ins Disassembly, vergleich, und benchmarke.

Heute früh habe ich nochmal am Schwert gearbeitet. Als erstes habe ich mich darum gekümmert, dass es nicht einfach durch alles hindurchlappt. Stösst es auf ein Hindernis, wird das Schwer entsprechend gekürzt. Es kann jetzt ausserdem Schüsse zerstören und je schneller man Fuchtelt, desto mehr Schaden macht man...


Auf Spieleprogrammierer kam der Wunsch nach Minimap, habe sie promp wieder eingebaut. Ein paar Sachen mussten noch angepasst werden und mir scheint es ist noch etwas buggy. Im Bild kann man gut erkennen, wie das Tentakelmonster angezeigt wird. Man kann ausserdem erkennen, dass vom Tentakelmonster schwarze Energie auf die Schüsse geht. Ist auch ein kleiner Bug :) Ich habe für das Schwert eine Funktion umgestellt, welche in einem Radius alle Elmente zurückgibt. Zuvor wurden die Schüsse nicht gefunden, jetzt eben schon.

Multi-Shot ist als Power-Up jetzt drin. Meine Überlegungen wieso ich es nicht integrieren wollte waren zwar alle richtig, aber es gibt eine super einfache Lösung dazu: Das Power-Up ist zeitlich begrenzt. Somit hat man den Spass mit dem Multi-Shot und es kann das Balancing nicht zur Sau machen. Es ist jetzt das erste Power-Up das man aufsammeln kann, es macht auch ziemlich Laune :)

Ich habe jetzt die anderen zwei Schuss-Powerups implementiert: Zielsuchende Schüsse und ein Stärke-Upgrade. Sie sind allerdings bei weitem nicht so befriedigend wie der Multi-Shot. Das schöne an meiner Implementierung: Die Powerups können kumuliert werden. Sammelt man zwei mal den Multi-Shot ein, schiesst man 5 Schüsse pro Waffe. Mit dem Zielsuch und Stärke Upgrade zusammen, wird die Waffe dann immer brutaler. Im Screenshot sieht man das Resultat.

Anhängsel sind jetzt tatsächlich drin, mit anständigem physikalischem Verhalten. Ich hab mich vor ein paar Posts noch aufgeregt, dass ichs nicht lösen kann. Hat mich nicht in Ruhe gelassen. Jetzt ist es drin, ob sinnvoll oder sinnfrei ist nicht die Frage.
Mehr als 10 Stück gehen wirklich nicht, ich denke im Spiel wird das Limit eher 6 sein.

Vermutlich nicht die beste Idee die ich jemals hatte: Dieser Spinnentyp vervielfältigt sich selbstständigig. Je länger man wartet, desto mehr werden es... Unbeschränkt geht die Performance verdammt schnell in die Knie. Ich wollte einfach noch einen Spinnentyp haben, bei dem man seine Zerstörungswut richtig ausleben kann :D

Das Wochenend hat sich noch einiges getan bei der Spinnen-KI. Die Verhaltensmuster sind jetzt nicht mehr überall identisch, teilweise sind sie jetzt vielleicht schon zu intelligent.

Ich glaube ich muss die Bossmonster noch interessanter gestalten... irgendwie sind sie etwas öde. Vielleicht macht es nur auf mich den Eindruck, weil ich sie schon 100 mal gesehen habe??

Ich denke ich muss die Bossmonster mit verschiedenen Aktionen ausstatten. Aktuell haben sie genau ein einziges Muster, dass sie von Anfang bis Ende verfolgen. Cool wäre es schon, wenn man etwas zerstört, dass sich der Boss verändert.

Was ebenfalls noch cool wäre: Wenn jeder Boss durch die neue Mechanik, die im Level zur Verfügung gestellt wird, einfacher zu besiegen wäre.
1. Nuke (gut getimte nuke beim Tentakelmonster)
2. Geschützturm (platzieren und wieder wegnehmen, Orbiter-boss)
3. Power-Schuss (gut gezielter Schuss, evtl. den Boss betäuben und ein Treffer ist dann frei, der Wirkung macht??? )
4. Assistenten (schon schwer genug sie am Leben zu halten, evtl. können für den Bosskampf weitere abgeworfen werden???)
5. Energie-Ball (Hauptproblem ist wenn man den Ball in eine Ecke bugsiert hat und nicht sinnvoll wieder kontrollieren kann...)
6. Schwert (klappt ganz gut mit dem letzten Boss)

Die Spinnen halten jetzt von einander etwas Abstand. die zwei Spinnen die am nächsten sind werden jeweils verbunden. Das Netz wird Schaden machen.

So sieht es inzwischen aus, jetzt muss es nur noch Schaden machen... ob es ein guter Gegner ist, wird sich noch zeigen.

Vor 4h wollte ich noch kurz was einbauen. Aber... man kennt das ja. Ich wollte unbedingt noch Trommelfells Musik besser einbinden. Der erste Track startet jetzt bereits im Menü und zieht sich durch das Einführungslevel. Wenn man alle Viecher vernichtet hat wird die Musik langsam leiser und das Upgrade-Menü wird angezeigt. Wenn man seine Upgrades ausgewählt hat geht es mit dem nächsten Track los.

Die neue Version ist online und hat neben Musik, endlos Continues, viel zu viele Extras und leicht überarbeitete Bosse (da muss noch viel gemacht werden). Die neuen Spinnen sind natürlich auch dabei.
Ach ja, Bugs gibts garantiert. Bis zum Ende habe ichs eben nicht fertig gespielt... zu müde :P

http://data.cyberlympics.com/html/game. ... ntiMiner_1

edit: jap hat sofort gebuggt... musste noch was fixen. Wieso verhält sich bloss ein Release immer etwas anders :P

Ich mag meine Screenshots überhaupt nicht, in Bewegung siehts immer viel besser aus. Leider sind die gifs immer sofort riesig :( und die gif Programme die ich benutze sind sowas von mühsam.
Das hier habe ich mit ScreenToGif aufgenommen. Da waren es 6mb, wieso weiss keiner. Ich habs dann mit GIMP geöffnet und nochmal gespeichert, jetzt sind es ~600kb



Ich hatte plötztlich wieder einen NaN fehler (die ich so liebe). Trat irgendwo bei diesem Elektro-Ball auf und führte zu einer Endlos-Schleife. Um es möglichst einfach wiederholen zu können habe ich also verdammt viele von diesen Bällen erzeugt und ein paar Überprüfungen eingebaut. Stellt sich heraus das meine qsin (quick sinus über tabelle) einen Fehler hat... ich verwende die Funktion überall. Ich glaube ich hatte verdammtes Glück, dass der Bug so einfach aufzufinden war :D

Habe heute viel zu lange gebraucht um die Tausendfüssler zu verbessern. Es ist immer wieder vorgekommen, dass Glieder in die falsche Richtung gelaufen sind und eine kleine Schleife machten. Dies ist immer dann passiert, wenn das hintere Glied das vordere überholt hat. Alle kleinen Fixes haben zu nichts geführt, machten es schlimmer oder erzeugten neue Probleme.

Also musste der Tausendfüssler komplett überarbeitet werden. Bislang war es so, dass die Glieder unter einander Kollidieren konnten. Dies hat zu dem guten Effekt des Tausendfüsslers geführt. Die neue Version erlaubt keine Selbstkollisionen mehr und ist damit viel weniger Fehleranfällig. Bis ich das Zusammenspiel zufriedenstellen hinbekommen habe, sind sicher 6h vergangen. Naja... ich hoffe ich kann es jetzt so belassen.


Gab auch noch ein paar andere Anpassungen, u.a. beim GUI für die Gamepad Steuerung. Ist aber immer noch nicht Fehlerfrei. Immerhin hab ich es auch mit dem Gamepad bis zum Endboss geschafft :)

Ich bin dabei den Ladevorgang zu verbessern. Kein besonders witziger Job, aber ich denke es ist wichtig.

Bislang wurde für jede Bildergruppe ein Farbkanal ein Alphakanal und eine Informationsdatei (Position der Einzelbilder im Bild) geladen. Die zwei Bilder werden zu einem RGBA Bild kombiniert. Nachdem alle Bilder geladen und kombiniert sind, wird der Textur-Atlas erstellt. Dafür werden viele Bilddaten rumkopieren und die möglichst optimale Platzierung berechnet.

Das fällt jetzt hoffentlich alles weg. In AntiMiner weiss ich genau welche Bilder gebraucht werden und es gibt kein späteres nachladen von anderen Bildern. Ich lade jetzt den Atlas direkt mit den dazugehörigen Informationen. Noch bin ich nicht fertig, aber ich hab mich so darüber gefreut, dass überhaupt was zu sehen ist, dass ich einen Screenshot machen musste :D

Die Ladezeiten sind plötzlich erschreckend schnell, vor allem wenn das 3.6mb Bild mal im Cache ist. Wenn man die Seite öffnet und ins Menü kommt wird das Spiel im Hintergrund sowieso bereits geladen, wenn ich jetzt auf Start drücke gehts gefühlte 0.2 sekunden. Den Ladeschirm bekomme ich gar nicht mehr zu sehen :D
Ich hätte das schon sooo viel früher machen müssen, was ich da an Wartezeit gespart hätte :roll:

Die neue Chrome Version hat mir nicht so viel Freude bereitet. Zumindest glaube ich dass einige Probleme deswegen auftauchen...
Es gibt in Javascript ein "debugger"-statement, dass wie ein break-point funktioniert. Wenn man es einsetzt, dann verhindert es ausserdem die Optimierungen für diese Funktion. Nun ist mir bei einem meiner Scripte ein Problem aufgefallen und ich wollte mit Hilfe des "debugger"-statements dem Problem auf die Spur kommen. Das Problem trat aber nicht mehr auf. Also debugger-statement wieder rausgenommen, da war das Problem wieder da... Meine Vermutung ist nun, dass irgend eine Optimierung zum Problem führt. Wie sich das Problem zeigt: Ich bekomme komische float-Werte, so was wie "-2.6380304608078758e+131". Ich bin nicht mal sicher was das für ein Wert sein soll.

Ausserdem habe ich das Gefühl, dass das Spiel neu immer wieder stockt... :(

Ich werde optional noch eine kleine Anzeige einbauen, die das Zielen mit Gamepad erleichtern soll. Manchmal kann es sein, dass das Zielkreuz ausserhalb des sichtbaren Bereichs ist. Ich muss daran auf alle Fälle noch arbeiten.

Seit der neuesten Chrome Version hab ich ziemliche Performance Probleme. Bis zu 15% der CPU Leistung geht für Garbage Collection drauf. Ich habe den Verdacht, dass es mit meiner Objekt-Struktur zusammenhängt, weiss es aber nicht wirklich. Auf die Struktur bin ich überhaupt nicht stolz, aber ich habe mich bisher nicht mehr getraut an dem Ding was zu ändern. Es hängt alles irgendwie dran... Jetzt habe ich den Schritt gewagt und es wird wohl in nächster Zeit überhaupt nichts laufen. JavaScript ist wohl auch die besch**** Sprache für so ein komplettes Refactoring. Bis ich das Ding starte habe ich keinen Schimmer ob es irgendwo knallen wird. Wenn ich in ein paar Tagen eine Glatze habe, weiss ich genau weswegen. Worst case wäre wenn die Umstellung gar nix bringt...

Nicht beneidenswert ;)
Auf was baust du um? Aus meiner bescheidenen Erfahrung heraus haben Pools das GC-Problem ganz gut im Griff.

Auf Pools habe ich schon lange umgestellt, das Problem ist vermutlich was anderes. Ich habe nicht mit prototype gearbeitet, sondern mit closures. Als ich vor 5 Jahren angefangen habe, waren die Ansprüche anders. Es hat bislang auch ganz gut funktioniert...

Meine Klassen sahen so aus:
jetzt stelle ich auf sowas um:
Wie gesagt, ich bin nicht stolz darauf :P. Es kann aber durchaus sein, dass es nicht der Grund für mein neues Performance-Problem ist.
Es gibt inheritance Möglichkeiten in JavaScript, scheinbar sind diese lahm. Darum das neue Krüppelkonstrukt.

Ja, das JS-Klassensystem mit den Prototypes... alles irgendwie sperrig. Schade auch, dass die Sprache nicht typisiert ist.
Ich drück jedenfalls die Daumen, dass du das ohne allzuviel Frust und Rückschläge in den Griff bekommst.

Schon mal daran gedacht auf TypeScript oder so umzusteigen?

Langsam komme ich wieder auf den alten Stand... stürzt dauernd ab, aber man sieht zumindest wieder was :)

@joeydee: Danke! Javascript ist manchmal schon ziemlich hässlich. Ich finde es aber schön dass man nicht kompilieren muss :D
@Chromanoid: Nein, bis jetzt habe ich mir das nie überlegt. Könnte schon sinn machen, evtl. hätte es gar auf die Performance noch positiven Einfluss, da weniger Wildwuchs möglich ist. Ich weiss nur nicht ob ich dass jetzt auch noch angehen möchte :)

Also wenn Dein Codebase jetzt schon so groß ist, dass Dir Refactoring wirklich in die Quere kommt, könnte das schon Sinn machen. Das hier sieht ganz spannend aus: http://news.turbulenz.com/post/47457658 ... -engine-to (Achtung: das ist 3 Jahre alt, aber trotzdem stößt man in Grenzfällen sicher heute auch noch auf ähnliche Probleme wie die).