ZFX + Developia

Mir ist aufgefallen, dass sich die Gegner aufreihen um besser abgeschossen zu werden. Fände es viel beklemmender wenn die wie eine Wolke auf einen zukommen.

Stimmt, gut bemerkt. Das Problem ist auch bereits Gegenstand interner Diskussionen. Die Viecher reihen sich ja nicht absichtlich auf, sondern nähern einander nur immer mehr an, weil sie das selbe Ziel verfolgen und immer den kürzesten Weg nehmen. Ich habe mir überlegt, ihre Wege in Abhängigkeit von anderen Monstern etwas auseinander driften zu lassen, so dass sie einander etwas Platz lassen. Leider wird das bei potentiell einigen Hundert Feinden eine rechenzeit-intensive Beschäftigung, die noch schlimmer dadurch wird, dass ich aktuell *keine* Beschleunigungsstruktur zum schnellen Auffinden von nahen Objekten drin habe. Bei jeder Umgebungsabfrage werden alle Objekte im Level durchgegangen... das muss ich vor Release unbedingt noch ändern.

Das Gleiche gilt übrigens aktuell auch für den Boden-Schmodder. 5000 Sprites, die bei einer Explosion durchgegangen werden, um ihnen einen Schubs zu geben... dafür ist das alles noch erstaunlich fix :-) Erstaunlich, was heutige Hardware alles leisten kann. Das alles ist aber eh lächerlich im Vergleich zur Rechenzeit, die dafür draufgeht, in jedem Frame etwa 10k Sprites zu cullen und durch 10+ Renderpasses zu jagen. Und das wäre dann auch der erste Punkt, an dem ich bei der Optimierung ansetzen werde: Multicore-Rendering.

Kannst du beim Wegberechnen nicht die "Monster" im Umkreis von x oder im Quadrant y als Gegenstände im Wegfindungsalgo unterbringen?

Nein, die Wegesuche ist nur auf ein halbes Tile genau. Viertel-Tiles hab ich auch mal probiert, aber die Zeiten für die Berechnung des Wegenetzes vervierfachen sich dann konsequenterweise. Und man will ja nicht, dass ein Zombie stehen bleibt, nur weil bereits zwei Zombies vor ihm stehen und den Weg zum Spieler blockieren. Wir reden hier ja von Splatter - da wird knietief durch Monster gewatet :-)

Vielleicht kannst Du um den Spieler herum einfach so eine Art Einflugschneisen definieren. Jedes Monster schreibt sich da selbst ab einer bestimmten Entfernung rein und wenn zu viele in einer Schneise sind, dann wechselt er die Spur. Ggf. kann man die Spuren dann noch "beliebig" unterteilen und anhand einer ID pseudozufällig die Zombies einer "Bahn" zuordnen.

Vielleicht bin ich zu blöd, aber mir erschließt sich das nicht ganz. Wenn auf dem Weg zwischen Zombie und Spieler ein anderer Zombie steht, dann ist der kürzeste Weg doch um diesen Zombie drumrum. Der direkte Weg ist ja offensichtlich blockiert.

Abgesehen davon hätte ich ohnehin für Zombies keine richtige Wegfindung implementiert, sondern nur ein lokales Attraktor/Repellor System. Ich würde dir das jetzt skizzieren aber erstens müste ich dazu Vorlesungsunterlagen von Anno Dunnemals raussuchen und zweitens wird es zu spät im Prozess sein, als das du das noch ändern wollen würdest. Ich Hypothetisiere aber mal, dass so ein System erstens weniger Recheneit bräuchte, zweitens "Schwarmiges" Verhalten erzeugen würde und drittens einem Zombie eher gerecht würde. Zombies gelten ja eher als mittelmäßig intelligent. Dass sie GPS an Bord haben halte ich für unglaubwürdig.

Wie dem auch sei. Releasen ist wichtiger :)

Für echte Wegfindung von Zombie-Horden würde sich vielleicht sowas anbieten: http://gamedev.stackexchange.com/questi ... nding-work

Aber wie Alexander schon sagte, da sie ohnehin immer nur vom spieler angezogen werden…

Ich hab vor Ewigkeiten mal Boids umgesetzt. Geht ziemlich easy, auch auf der GPU, schaut sehr hübsch und interessant aus und ist irre schnell. Zombie-Schwärme sollten sich damit ziemlich gut realisieren lassen.

Eine gute Idee! Sowas in der Richtung hatte ich in der Tat vor. Aber wie gesagt: das eigentliche Teure daran sind die Umgebungsqueries nach anderen Zombies. Und die muss ich erstmal optimieren, bevor ich was am Gruppenverhalten versuche.

Der Diskussion um den ZFX-Pagerank und die Projektvorstellungen folgend poste ich mal etwas kleinteiliger, wenn es für euch evtl. interessant sein könnte, da ihr ja auch Entwickler seid.

Meine aktuelle Deploy-Strategie: nicht ganz aus dem Mittelalter, aber noch weit entfernt von der vollautomatischen Moderne. Und zwar Total Commander mit der Verzeichnisse-Synchronisieren-Funktion: Meine Arbeitsweise hier ist zugegebenermaßen streitbar, aber das Tool ist uneingeschränkt zu empfehlen. Ich will nicht mehr ohne leben.

Splatter_TGGC... die Gerüchte verdichten sich ;)
Deployment ist bei mir auch sowas gruseliges. Die Dateien werden halb automatisch, halb durch Batch-Scripte zusammengesammelt oder aufbereitet.

Ja, aber Christian weiß noch nichts davon, dass er das Spiel bekommt. Und ich entdecke permanent neue Details beim Erproben, die ich unbedingt noch in der Version drinhaben will.

Du weißt ja: man hat nur eine Chance auf einen ersten Eindruck.

Oh damn. Dann habe ich meine ja schon lange verspielt ;) Trotzdem, ich hoffe du schaffst es bis morgen selbst mit der Lieferung zufrieden zu sein.

Rein aus Interesse: Benutzt du Qt, oder ist die Namensgebung nur Zufall? Ich habe Qt mit Qml schön öfter auf mobilen Geräten benutzt. Habe Qt jetzt hier im Forum schon mehrfach gelesen und bin deshalb etwas neugierig.

Übrigens fehlt da D:\backup\Splatter_Niki ;)

Wir benutzen Qt nur für den Editor. Im Spiel selbst könnte das Qt-Framework wahrscheinlich auch nützlich sein - es bietet ja immerhin eine Menge ausgereifter plattformübergreifender Helfer. Ich mag allerdings nicht, dass Qt mir die Message Loop wegnimmt - die brauche ich für einige Spezialfälle. Und ohne die Qt-Message-Loop ist ein Großteil der Qt-eigenen Features unbrauchbar.

Eine simple Strategie fuer die Umgebungsabfragen ist folgendes:
Du machst ein grobes Raster um den Spieler, z.b. mit 128x128 Pixel. Jetzt gehst du alle deine Zombies durch und schaust in welchem Raster die stehen. Nun erzeugst du fuer jedes Rasterfeld das naeher als x zum Spieler ist zwei Listen: einmal alle Zombies in dem Feld, einmal alle Zombies die in den neun Kacheln (3x3) rumstehen evtl. auch nochmal gefiltert durch Abstand zur mittleren Kachel. Fuer deinen Boid-Algo oder sowas, gehst du nun immer die erste Liste durch und nimmst die Einheiten aus Liste 2 als potenzielle Kollsionsgegner. Da sich deinen Gegner ja alle recht gleichfoermig bewegen, musst du die Liste auch nicht staendig updaten, sondern kannst das auch auf ein paar Frames verteilen.

Sehe gerade den Stream auf TGGCs Stream :) beim Sehen hätte ich Lust auf ein "Treten" Feature um ohne Waffe zu Wechseln nicht explosive Sachen kaputt zu machen.

@TGGC: spät, aber Danke für den Tipp. So eine Art Cache für umstehende Monster ist ne gute Idee. Muss aber leider erstmal warten, bis die Kampagne fertig ist.

@Chromanoid: Nahkampf :-) Hatten wir mal erwogen, aber wir haben uns dagegen entschieden. Aus dem gleichen Grund, warum es auch keine "Interaktion/Benutzen"-Taste gibt - die aktuelle Steuerung ist bewusst minimal gehalten und jede zusätzliche Taste sollte vermieden werden.

Ich baue aktuell am Endgegner, aber zwischendurch wollte ich nochmal kurz eines der neuen Nebenfeatures zeigen: Sichtblocker. Damit sind bestimmte Bereiche wie z.B. das Innere eines Hauses erstmal ausgeschwärzt und werden erst per Trigger oder beim Betreten freigelegt. Ich habe mal (mit einigen Mühen und LICEcap)ein GIF davon in Aktion produziert.



Und immer, wenn ich sowas sehe, habe ich den Eindruck, das Spiel sei viel zu dunkel. Im Spiel fällt mir das gar nicht so auf, aber vielleicht habe ich mich auch nur schon zu sehr dran gewöhnt. Wer weiß... es ist bei solchen Sachen echt schwer, aussagekräftiges Feedback zu bekommen.

Sieht sehr gut aus. Allerdings finde ich die Straßen/Steinplatten Bodentiles überarbeitungswürdig, die sehen mir einfach zu sehr nach "BumpMAAAP!" aus... Und die Wände (von oben) gefallen mir leider auch immer noch nicht. Wird es Modsupport geben? :D Bzgl. der Helligkeit: wäre es schwierig die Lichtquellen in Häusern etwas heller zu machen, viellleicht auch etwas gleißender.

Ja, die Steinplatten-Tiles sehen immernoch zu heftig aus. Ich habe aber auch bezüglich der sonstigen Untergründe Zweifel. Ich meine.... ich zweifel ja eh immer und an allem, aber diese konkreten Zweifel sind neu. Die klassische Grafik-Lehre besagt ja, dass man die Hintergründe entsättigen und kontrastärmer machen solle, damit sich die wichtigen Dinge im Vordergrund abheben. Es ist nur evtl. etwas zu spät für solche Überlegungen.

Kleiner Gag am Rande: der epische mehrstufige Kampf mit dem finalen Gegner nimmt langsam Gestalt an. Nur leider wirkt selbst der finsterste Evil Overlord lächerlich, wenn er mit Platzhalter-Grafiken in den Kampf ziehen muss :)

Schrompf hat geschrieben: Und immer, wenn ich sowas sehe, habe ich den Eindruck, das Spiel sei viel zu dunkel. Im Spiel fällt mir das gar nicht so auf, aber vielleicht habe ich mich auch nur schon zu sehr dran gewöhnt. Wer weiß... es ist bei solchen Sachen echt schwer, aussagekräftiges Feedback zu bekommen.

Ich habe mich bei TGGCs Test zwei Dinge gefragt:

1) Ist es gewollt dass man Gegner die sich von hinten nähern nicht sehen kann? Würde mir die Tension vermutlich zu sehr erhöhen. Ich bin da aber auch Mimi. Alan Wake kann ich quasi nicht spielen vor Grusel.
2) Warum laufen die Gegner vor dem Lichtkegel der Taschenlampe nicht weg. Muss es eine bestimmte Helligkeit sein? Also dieses Magnesium-hell? Und ist das im Spiel konsistent (Angst der Gegner immer dieselbe Funktion der Lichtintensität.

Letztlich scheint es ein bisschen darauf hinauszulaufen, dass am Gamma drehen den Schwierigkeitsgrad verändert. Oder dass Menschen mit schlecht kalibriertem Monitor Probleme bekommen, wenn man nicht am Gamma drehen kann. Obwohl ich da relativ fein raus bin weil das default Gamma bei den meisten aktuellen Spielen für mich passt.

Gute Fragen, daher die vorhin schonmal getippte Antwort nochmal in Kurzform:

1) Eigentlich ist die Dunkelheit Absicht. Die Wurffackeln sind ja auch zur Beleuchtung da und dunkle Ecken sollen den Spieler dazu bringen, die Gegend vor ihm zu beleuchten, bevor er weiter läuft. Allerdings hat man die Fackeln ja nicht ab Start... ich habe da ein paar Szenen sorgfältig konstruiert, um die Wirkung vorzuführen und dann den Spieler die Nützlichkeit selbst erleben zu lassen. Sonst hätte man die wohl noch eher bringen müssen. Gegner von hinten sieht man aber genauso wie von vorn: man erkennt Bewegungen und Geräusche, aber die Beleuchtungssituation ist bisweilen auch noch nicht so recht durchdacht oder eher von optischen als von spielerischen Gesichtspunkten geleitet. Hm. Verbesserungspotenzial.

2) Welche Lichtquellen Angst verbreiten und welche nicht, soll durch das dicke Lensflare unterschieden werden. Der Spielcharakter spekuliert darüber auch im vierten Level ein bisschen, aber so richtig erklärt wird es nie.

Und ja, Gamma-Einstellung muss noch rein.

Witzigerweise wurde am Ende des Streams auch schon zu den Fackeln gefragt:
[youtube]9dA4GcUkub0[/youtube]

Schrompf, hast du eigentlich schon einen konkret angepeilten Release-Termin?

Noch nichts Konkretes. Aktuall baue ich wie ein Wahnsinniger am finalen Bosskampf, zwei von drei Stufen sind schon gut spielbar und glaube auch spaßig. Wenn der Bosskampf vollständig spielbar ist, baue ich dann noch einen Platzhalter-Abspann und dann geht erstmal die Anschauversion an GoodOldGames raus.

Hoffentlich nehmen die mein Spiel. Falls ja, hat der Release bei GOG etwa 6 Wochen Vorlaufzeit. Aber auch sonst werde ich dann intensiv an allem weiterschrauben - einige grundsätzliche Features, eine Menge Cutscenes und vor allem viiiieeel Polishing fehlen noch. Ich peile aktuell Ende Mai als Releasezeitpunkt an.

Ich fände es interessant, wenn du anschließend einen Erfahrungsbericht schreiben würdest, egal ob gog das Spiel annimmt, oder nicht.Und viele andere fänden das gewiss auch spannend.

Achja, werden noch Tester gesucht? Ich mag es, über Gamedesign zu reden und würde daher vermutlich auch relativ ausführlich Feedback geben, andererseits weiß ich noch gar nicht, ob ich überhaupt eine nicht finale Version spielen möchte, oder die finale Version als ganzes und ohne 'Spoiler' genießen möchte. Andererseits reizt es mich schon, noch Einfluss auf gewisse Fehlerkorrekturen nehmen zu können und nicht später sagen zu müssen "tolles Spiel, aber mit diesen 2-3 Details hätte ich es noch viel besser gefunden".

Erfahrungsbericht... zu GOG oder allgemein zur Entwicklung? Nur zu GOG gibt es ehrlich gesagt nicht so viel zu erzählen... ich kann ja schlecht den EMail-Verkehr offenlegen. Das wird sich aber zeigen, wenn es soweit ist. Und zur allgemeinen Entwicklung - kann ich machen, wenn ich mich noch an was Relevantes erinnere :-)

Danke für das Testangebot! Ich melde mich, sobald die Story inhaltsvollständig ist. Das wird hoffentlich heute noch, aber wie ich meine Zeitschätzungen kenne, eher morgen.

Hm, bin eben gerade in Steam Greenlight auf das Spiel Darkwood gestoßen. Sieht vom Stil her schon ein bisschen nach Splatter aus und hat eine nette Atmosphäre. :D Schrompf, wie sieht es bei dir mit Greenlight aus? Schonmal in Erwägung gezogen?

[youtube]uQOPb9p3HTQ[/youtube]

Warum poste ich hier so selten? Ich hab gefühlt irgendwie nix zu erzählen, aber wenn dann jemand ne Frage hat, verpasse ich die auch noch. Sorry, mnemonix.

@Darkwood: Danke für den Hinweis. Das Spiel habe ich auch von anderen schon gezeigt bekommen, aber es hat mit meinem Splatter glaube ich nicht viel zu tun. Es ist mehr Survival-Atmosphäre und vor allem in einem viel früheren Entwicklungsstadium.

Und weil ich gestern zum Ressourcenverbrauch gejammert habe: ich habe mich ein bisschen zu Non-Power-Of-Two-Texturen und MipMaps belesen und die Textur-Atlanten kurzerhand in der Höhe auf den tatsächlich genutzten Bereich eingeschränkt. Die Textur-Atlanten werden automatisch zusammengestellt, falls sich an der XML-Datei mit allen Defs und Werten was geändert hat. Das braucht einige Sekunden, aber wird dann im Ganzen auf Platte geschrieben, so dass ich es beim nächsten Start schnell laden kann. Und nun, nach der Zusammenstutzung, ist der Tiles-Texturatlas noch 1640 Pixel hoch und der für Sprites 2400 Pixel. Der VideoRAM-Verbrauch hat sich fast halbiert.

Konsole hat geschrieben:>videoram
Insgesamt 121 Resourcen mit einer Gesamtgröße von schätzungsweise 345840 kb.
6 Vertex-Eingabedeklarationen
18 VertexShader
18 PixelShader

32 VertexBuffer (4463 kb)
davon 32 im VideoRAM (4463 kb)
davon 29 dynamisch (4463 kb)
davon 0 offline (0 kb)

4 IndexBuffer (5 kb)
davon 4 im VideoRAM (5 kb)
davon 0 dynamisch (0 kb)
davon 0 offline (0 kb)

43 Texturen (341371 kb)
davon 43 im VideoRAM (341371 kb)
davon 0 dynamisch (0 kb)
davon 15 Renderziele (70465 kb)
davon 0 offline (0 kb)

Jawolljaja!

Sollte nicht Ende Mai Release sein?