Endyr Entwicklerblog

Liebe Endyr-Fans

Ursprünglich sollte Endyr am 21. Dezember zusammen mit dem Weltuntergang online gehen – dies war auch tatsächlich der Fall, allerdings aufgrund massiven Zeitmangels in stark gekürzter Form. Die Endyr Alpha hat gezeigt, dass das System grundsätzlich funktioniert, wo die Schwachstellen sind (insbesondere ist das "Rubberbanding" beim Laufen aufgefallen) und nicht zuletzt auch, wer überhaupt Interesse an dem Projekt hat.

Nun, gut 6 Monate später, sieht Endyr noch fast genauso aus wie damals – und das mit gutem Grund. Massive interne Umbauarbeiten, vor allem aber Updates an Yhoko.com (man denke nur an Yotto und Marktplatz) und im Sternchenspiel sowie private Gründe (WG-Auflösung mit Auszug) haben die Weiterentwicklung gebremst. All diese Faktoren liegen jetzt hinter mir und Endyr steht wieder ganz oben auf meiner imaginären Todo-Liste.

• Endyr Website

Nun zu diesem Forenthema:
Bislang gab es zu Endyr immer mal wieder Screenshots, doch die Grafik hat allmählich ihren endgültigen Stand erreicht. Das heisst, man kann jetzt bloss noch Spielszenen posten, was ich aber natürlich auch weiterhin tun werde. Die Entwicklung jedoch verlagert sich immer mehr unter die Haube; Skripte werden verfeinert, die KI verbessert, das Crafting ausgeweitet und Spielabläufe optimiert. Da sich diese Prozesse oft nur mit (mehr oder weniger viel) Text erklären lassen, habe ich beschlossen, diesen Blog hier zu pflegen. Nicht jedes Thema und nicht jede Neuerung an Endyr wird hier zur Sprache kommen (dafür gibt es das offizielle Changelog mit sämtlichen Updates und Neuerungen) sondern nur diejenigen, die mir angemessen scheinen.

• Endyr Changelog

Wer sich also für Endyr und die Technik dahinter interessiert, möge das Thema gleich abonnieren oder öfter mal reinschauen. Direkte Antworten sind gesperrt, verwendet also für Fragen oder Anmerkungen zu einem Beiträg den dazugehörigen "Diskutieren" Link.

Yhoko

Gegnerskripte

Eben sprach ich noch von Skriptverbesserungen und KI, da möchte ich den ersten Beitrag ansetzen. Wer schonmal ein Spiel programmiert hat, kennt die Komplexität dieses Themas – man beginnt mit herumstehenden NPCs (je nachdem kann man die sogar schon ansprechen), dann folgen solche, die bloss zufällig herumlaufen (z.B. Haustiere oder alte Leute, die dumme Sprüche von sich geben), zwischendurch vielleicht noch patroullierende NPCs (wie etwa Soldaten) und dann wirds komplizierter. Vielleicht will man Verfolger, die dem Spieler nachlaufen, oder Gegner, die bei Sichtkontakt aufmerksam werden, den Spieler verfolgen oder gar Deckung nehmen, wenn sie unter Beschuss geraten.

Soweit eigentlich kein Thema für Endyr, aber nun kommt der Haken: Selbst ein komplexer Gegner soll patroullieren oder zufällig herumlaufen, wenn keine Spieler in der Nähe sind. Bislang war es so, dass dazu das ganze Bewegungs-Skript der Dorfbewohner als Kopie nochmal im Gegner-Skript vorhanden war. Dasselbe gilt natürlich auch für alle anderen Funktionen, etwa Looting (erzeugt Items, nachdem ein Gegner besiegt wurde) oder Gespräche. Wollte man also eine neue Gegnerart erschaffen (z.B. einen Geist, der zwischen der normalen und Geisterebene wechseln kann) musste man dies entweder mit immer mehr Parametern regeln (bei jedem Gegner zusätzlich eintragen ob er ein Geist ist, wie oft er die Ebene wechseln kann, usw. – auf Dauer ziemlich lästig) oder das ganze Skript nochmal kopieren (auch lästig, denn sämtliche Änderungen und Bugfixes müssen dann an allen kopierten Skripte ebenfalls vorgenommen werden).

Um hier nun mehr Modularität zu schaffen habe ich das Skripting so erweitert, dass man weitere Skripte per Befehl einbinden und zuweisen kann. Das erleichtert nicht nur die Handhabung sondern führt zu einer sehr praktischen Aufgabentrennung. Konkret: Statt einem "Gegner"-Skript, welches den NPC bewegt, angreift und letztendlich Loot erzeugt, gibt es nun primär einen "Controller", also sozusagen das Drehbuch für den Gegner.
Ein Beispiel: Der Controller wird geladen und weist erstmal das "random" Skript zu, damit der NPC zufällig herumläuft. Weiterhin erzeugt er "senses", also Sinne, welche seine Umgebung abtasten. Sobald etwas gesichtet wird, melden die Sinne dies dem Controller und er entscheidet, was zu tun ist – handelt es sich um einen Spieler, klinkt er "random" aus und bindet stattdessen "chase", also Verfolgung, für die Fortbewegung ein. Weiterhin kann er "attack" hinzufügen oder sonstige Skripte einbinden. Melden die Sinne, dass der Spieler nicht mehr da ist (ausser Reichweite, Ebene gewechselt, Unsichtbarkeitstrank, etc.) wird der Controller das alles wieder entfernen und auf "random" zurückschalten.

Während nun die einfachen Gegner auch ziemlich einfache "Sinne" haben (vlt. einfach ein "visueller Annäherungssensor", also vereinfachte Augen) können komplexere Bossgegner natürlich auch andere Skripte verwenden. Denkbar sind z.B. Augen mit eingeschränktem Blickfeld, ein Geruchssensor (Nase) welcher richtungsunabhängig, dafür aber mit Verzögerung reagiert, Schallsensoren (Ohren) die auf Schritte und Kampfgeräusche reagieren, usw. – dem Spielprinzip sind hier lediglich Kapazitätsgrenzen gesetzt.

Damit beendet ich den heutigen Blogeintrag und setze mich wieder an die Umsetzung von eben dem ;-) Das Grundprinzip steht, aber die ganzen Gegner sollen nun entsprechend umgeschrieben werden.

Appendix zum Thema Sinne und der Frage "Wozu das Ganze?":

Stellen wir uns Gegner vor, die nur Ohren als Sinne haben. Spieler mit Lederrüstungen könnten diese unbemerkt passieren, während eine Metallrüstung sie aufweckt und anlockt – was entweder versehentlich oder natürlich auch absichtlich geschehen kann.
Nun denken wir an eine verwandte Spezies, die Ohren und Nasen hat. Auch hier könnte man gut vorbeischleichen, sofern man dabei nicht trödelt – wer zu lange in Gegnernähe verweilt, wird gerochen und damit entdeckt. Ähnliches gilt für eine andere Spezies, die Wärme oder Lebensenergie spürt.

Eine andere Variante wären Gegner nur mit Augen als Sinne. Solange man hinter ihnen vorbeigeht, kann man unbemerkt bleiben, doch wehe einer dreht sich um! Oder die Gegner sehen lediglich infrarot und mit einem speziellen Kühltrank kann man sich vor ihnen verbergen. Die Möglichkeiten sind ziemlich weitreichend und jeder Sinn ermöglicht andere Items, die das Spielprinzip erweitern. Nebst einem Parfüm, dass den eigenen Duft verschleiert, sind z.B. Köder denkbar, welche die Gegner in eine Falle locken – oder andere Gegner ihre Kollegen, die man zuvor mit einer Duftbombe eingenebelt hat, angreifen lassen.

Taktik lautet das Stichwort und die Tiefe der Möglichkeiten hängt momentan noch sehr stark davon ab, was die Spieler – also ihr – wünschen.

Refaktorisierung

Auch wenn heute nicht viel Zeit dafür blieb: Grosse Teile des Endyr-Servers konnte ich konsolidieren, so dass nun z.B. alle Skript-Funktionen an einem Ort sind. Bisher besass jede Klasse (Char, Actors, Objects, Items, etc.) dieselben Funktionen, um interne Skripte aufzurufen. Während das grundsätzlich in Ordnung war, gab es in letzter Zeit einige Anlässe, das Skriptsystem zu erweitern und der Code musste entsprechend in jeder Klasse separat nachgetragen werden. Dieser Aufwand entfällt nun durch die zentrale Organisation der Klassenfunktionen. Schön ist auch, dass der Code dadurch schlanker und übersichtlicher wurde – worum es im Wesentlichen bei der Refaktorisierung geht. Der nächste Schritt wird nun sein, die oben erwähnte Modularität umzusetzen, denn diese erfordert eine (nun zentrale) Erweiterung des Skriptsystems.

In einer echten Programmiersprache hätte ich vielleicht von Anfang an mit Klassenvererbung gearbeitet, doch ich hatte anfangs auch nicht damit gerechnet, allem und jedem noch Skripte anhängen zu wollen.

Neue Möglichkeiten

Gesagt, getan – das Klassensystem aus den vorhergehenden Einträgen ist nun implementiert, der Code ist um gefühlte 200 Zeilen leichter geworden und statt dabei Funktionen einzubüssen hat die Engine viele neue Möglichkeiten dazugewonnen. Die Aufteilung der Skripte in control/move/sense/etc. ist beispielsweise jetzt auch bei Gegenständen und Objekten möglich – was aber nicht heissen soll, dass es dafür schon eine sinnvolle Anwendung gibt ;-) Ausser bei den Levels, wo sich nun Abläufe besser organisieren lassen. Als unverbindliches Beispiel kommt mir da eine Mine in Sinn, die beim Abbau unterschiedliche Skripte aufruft, abhängig davon, wie der Zustand der Mine ist. Dinge, die man zwar auch bisher umsetzen konnte, aber eben mit viel mehr Redundanz.

Das Huhn

Just for fun: Mit folgendem Skript läuft ein NPC zufällig herum und gackert alle 1-20 Sekunden ins Debug-Log:



Anmerkung: Das Skript ist an sich vollständig, die ganze Arbeit des Herumlaufens wird aber natürlich von der Klasse "moveRandom" verrichtet. Das Huhn ist damit auch noch nicht fertig, z.B. muss man es noch angreifen und rupfen können - sobald die entsprechenden Module entwickelt sind, werden das hier aber auch nur zwei weitere setClass() Einträge werden.

Freude herrscht

Programmieren ist vergleichbau mit dem Bau einer Maschine. So richtig Spass machts, wenn alle Rädchen sich drehen und die Mechanik erwartungsgemäss arbeitet. Ein vergleichbares Gefühl erzeugen die neu gestalteteten Skriptklassen, die sich nun langsam wie kleine Zahnrädchen verhalten – so wird etwa beim Angriff mit dem Schwert ein Damage-Skript des Gegners aufgerufen, welches ein entsprechendes Event an die KI zurückmeldet, die auf den Angriff reagieren kann, indem sie z.B. ein Flucht-Skript einbindet. Sofern jedoch die Trefferpunkte dabei auf 0 sinken wird das Damage-Skript den "Death Handler" aufrufen, dieser eine Rauchwolke produzieren, Loot erzeugen und den Gegner von der Karte entfernen. Ein grosser Boss hingegen kriegt einen anderen Death-Handler, der ihn z.B. in neuer Gestalt wiedererweckt und wenn man auch noch den Loot-Handler ersetzt, könnte dieser nicht einfach "Drops" erzeugen sondern eine Leiche hinterlassen, die man entweder per Klick looten kann oder die einen Beutel öffnet, aus dem man die Gegenstände direkt ins Inventar ziehen kann.

Lange Rede, kurzer Sinn, es macht wirklich Freude, nach dem neuen System zu skripten :-) Bald sind die Gegner wieder einsatzbereit, dann wird auch der Server wieder geöffnet.

Feinheiten des Scriptings

Wie viele Details braucht ein Spiel? Wie viele Details verträgt ein Spiel? Irgendwo dazwischen liegt das Optimum und es ist nicht leicht zu finden. Mit "Details" meine ich freilich nicht die Grafik sondern die Spielmechanik, also auf der einen Seite wie abstrakt das Spiel funktioniert (muss man Fleisch nur anklicken um es zu essen oder es vorher noch kochen) und auf der anderen wie viele Faktoren es berücksichtigt (zieht man es einfach in den Herd und wartet oder muss man zunächst eine Pfanne benutzen, auf die Zeit achten, es gelegentlich wenden, auch noch Öl dazugeben, etc.?).

Ein aktuelles Beispiel: Von Hühnern kriegt man natürlich Federn, aber wie? Bei Dungeon Keeper gibt es keine Federn, weil die Küken nur als Nahrung dienen. Bei Minecraft greift man die Hühner an, woraufhin sie für kurze Zeit fliehen. Beim Tod hinterlassen sie Fleisch und die gesuchten Federn. Auf Elantharil muss man das Huhn zunächst töten, entweder wie gehabt im Kampf oder, wenn es gezähmt ist, durch Schlachtung mit einem Beil. Allerdings fliehen die Tiere hier nicht sondern greifen an, wenn man den ersten Treffer landet. Auf die Leiche wendet man schliesslich ein Messer an, um ans Fleisch und die gesuchten Federn zu kommen. Und bei Endyr?

Der Grundmechanismus ist klar: erst das Huhn töten, dann rupfen (lebenden Hühnern die Federn zu stehlen ist nicht nur unmoralisch sondern auch viel schwieriger). Interessanter ist daher die Frage, wie man ein Huhn denn eigentlich tötet. Dass Hühner lieber fliehen als sich dem Kampf zu stellen scheint mir intuitiv, dass sie sich einfach abschlachten lassen hingegen weniger. Daher habe ich folgende Mechanismen geskriptet, die bei einem Huhn-Angriff zur Geltung kommen:
1) Alle Hühner im näheren Umkreis fliehen vor dem Angreifer
2) Ist ein Hahn in der Nähe, stürzt er sich auf den Angreifer
Oh, ein Hahn, das gabs in den anderen Spielen ja gar nicht – ausser bei Elantharil, aber auch da verteidigt er seine Hühner nicht. Bei Endyr hingegen war er schon vorher da, nämlich um die Hühner zu befruchten, und wenn sie kreischen eilt er nun zur Stelle. Aber macht er das auch, wenn er selbst schon im Kampf ist? Was, wenn er dazu über ein Stück Lava laufen muss? Bei jeder dieser Fragen muss entschieden werden, ob die Mechanik überhaupt umgesetzt werden soll, und wenn ja, wie sie umgesetzt werden soll und dann noch welche konkreten Werte die Funktionen erhalten sollen. Der Hahn könnte beispielsweise über die Lava hinwegspringen – oh hoppla, Springen gibts ja noch gar nicht. Und wenn man das nun für den Hahn implementiert, muss man es auch für alle anderen Gegner und Tiere konfigurieren. Und natürlich stellt sich die Frage, ob ein Lavatropfen schon ausreicht, um den Hahn einzuschüchtern, oder erst ein faustgrosser Klumpen, ein einzelnes Feld, mehrere Felder, ein ganzer Lavasee..? Gut, ein Hahn ist vielleicht eher schüchtern gegenüber Feuer, aber dieselbe Situation ergibt sich beim Skripten eines Erdelementars.

Das einzige, was dem durch diese Details exponentiell wachsenden Haufen an Skripten entgegenwirkt, ist eine ausgeklügelte, modulare Organisation der Skriptfunktionen, damit alles aufeinander aufbauen kann, dabei aber flexibel austauschbar bleibt und am besten auch noch irgendwie übersichtlich zu entwickeln ist. Knifflig – und wir werden sehen, wie das bei Endyr herauskommt. Letztendlich darf man nämlich eines nie vergessen: Das Spiel soll Spass machen. Und ein einfaches Steak geniessbar zu braten sollte vielleicht nicht die grösste Herausforderung für den Spieler sein.

Onwaaaard!

Die letzten Tage hing eine düstere Wolke über dem Yhoko.com Hauptquartier – nein, leider keine echte sondern nur eine sprichwörtliche; eigentlich schien die Sonne und es war viel zu warm. Aber das Wetter nimmt auf keinen Rücksicht, denn ich behaupte vorsichtig, dass es am aktuellen Debakel schuld ist. Aber nicht nur.

Die Dunkelheit begann am Freitag, als meine Wii plötzlich den Geist aufgab. Um genau zu sein wollte sie keine CDs mehr lesen und auch nur sehr mühsam wieder aussprucken. Das Wochenende war aber ohnehin als Basteltage gekennzeichnet, mein Game-PC lief nicht mehr und auch ein alter Freund kam zu Besuch und brachte seinen Rechner für eine Neuinstallation mit. Also halb so wild. Gebastelt wurde dann auch – nach 4 Stunden Schräubchendrehen konnten wir zumindest Wii Sports einlegen; was anderes spiele ich ohnehin nicht (und hätten am liebsten einen von Nintendo erschossen – dämliche Dreiecksschrauben). Die restliche Nacht auf den Sonntag verbrachte ich also damit, meinen Game-PC wieder flott zu kriegen. Anfangs sah es bitter aus, doch offenbar war ich so schlau erst kürzlich ein Backup zu ziehen, welches dann freudigerweise auftauchte, und so war zumindest das bald wieder repariert. Endlich wieder Skyrim! Parallel dazu brachte ich Selays Rechner wieder in Ordnung, wobei Ubuntu sich nicht so recht mit Windows 7 vertragen wollte. Der Bootloader machte Probleme; also nichts tragisches. Am frühen Nachmittag gönnte ich mir eine kleine Mütze Schlaf, dann verschwand Selay wieder nach Hause.

Dann kam die Überraschung: Alles lief irgendwie ... lahm. Kurzer Blick auf den Server; das aktuelle Backup wurde gerade zu Jeromy übertragen. Aber wieso brauchte das 2'000% Prozessorleistung? Wie sich herausstellte war es eine Hardwarebremse; die Temp-Festplatte hatte ihren Geist aufgegeben. Das ist die mit den Minecraft-Welten, noch nicht sortierten Downloads und Daten von meinen früheren Rechnern. Die wichtigen Sachen daraus waren zwar längst woanders, aber nicht zu wissen, was alles verloren gegangen war (insbesondere die Downloads) war schon ärgerlich. Also versuchte ich, die Platte wieder zum Laufen zu kriegen, indem ich sie aus dem Server nahm und bei mir einbaute.

Symptome: Festplatte startet, beschleunigt, soweit okay, aber dann klackt der Lesekopf nur ein paar Mal, ehe er aufgibt und sich schlafen legt. Auch das BIOS wollte kein HDD erkennen. Mist. Und dann gings doch plötzlich mal, der PC startete fröhlich und dann – Fehlanzeige, keine Partitionen. Daten weg? Entrüstung. Dann ein Hoffnungsschimmer: die ursprüngliche Temp-Platte kam damals aus meinem Rechner und war mit NTFS formatiert, doch irgendwann wurde sie aus Platzgründen ausgetauscht – und dabei womöglich mit ext3 (Linux) formatiert. Womöglich war die Partition also... ja! Noch vorhanden.
Unter Linux zeigte sich dann dasselbe Bild - meist wurde die Platte bereits vom BIOS nicht erkannt, und wenn doch, nicht eingebunden, und wenn doch waren die Daten nicht lesbar. Meine Ansprüche beschränkten sich bereits darauf, eine Liste der Downloads aus dem Dateisystem zu ziehen, aber manchmal waren die Ordner da, manchmal nicht.

Diese Symptome deuteten auf einen festhängenden Lesekopf hin und hier kommen wir wieder zum Wetter zurück. Es war wirklich warm die letzten Tage und als ich die defekte Festplatte aus dem Gehäuse zog, hätte ich mir fast die Finger verbrannt. Übrigens trotz des Lüfters vor den Server-Festplatten. Womöglich, dachte ich mir, hatte sich einfach nur das Metall ob der mutmasslichen Überhitzung ein wenig verformt.

Mein Lösungsansatz bestand anschliessend daraus, die Festplatte auf -18° zu kühlen und es dann erneut zu versuchen. Diesen Tipp hatte ich im Internet gefunden und für plausibel befunden. Es hiess auch, dass dies eine einmalige, letzte Chance sei, weil die Platte danach zweifellos im Eimer wäre. Mehr als die Dateiliste wollte ich ja aber auch nicht haben. Gesagt, getan, wurde sie erstmal mit Kühlpacks versehen wieder in Betrieb genommen. Und siehe da: Sie startete! Leider meinte das BIOS aber, dass die neue IDE-Festplatte (alle anderen waren SATA) die Bootpartition sei und meldete einen Fehler. Kurzer Neustart um das im BIOS zu berichtigen, und dann wieder Entrüstung – sie wurde nicht mehr erkannt, das bekannte Klacken trat wieder auf. Also nichts mehr zu retten. Oder doch?

Mit etwas Hartnäckigkeit und Experimentierfreude versuchte ich nochmal, die Platte tiefgefroren zu betreiben, und nach ein paar Neustarts kam ich auch tatsächlich an die gewünschte Dateiliste heran – und sah dabei, dass auch einige Downloads dabei waren, die ich unmöglich wieder im Internet finden würde. Ein kleines Textfile mit YouTube-Links konnte ich immerhin kopieren - und damit stand der Beweis, dass die Daten noch vorhanden waren (denn jenes Textfile ergab oft einen I/O Fehler beim öffnen, und dann klappte es wieder einwandfrei). Schnell war klar, dass die Festplatte sich einfach zu schnell aufwärmte (von innen). Das Experiment gipfelte also darin, dass ich sie mit langen IDE- und Stromkabeln [Y.com] innerhalb des Tiefgefrierers bei -18°C betrieb. Mit Erfolg!

...oder zumindest teilweise. Ich konnte die Festplatte wesentlich länger betrachten und die meisten Verzeichnisse öffnen, aber um wirklich etwas zu kopieren war die Zeit zu knapp. Immerhin, aber dennoch – mit einem Teilerfolg wollte ich mich jetzt nicht mehr zufriedengeben. Mittlerweile war es Dienstag und die Festplatte hatte schon gefühlte 100 Neustarts mitgemacht. Mir war bewusst, dass sie jederzeit komplett den Geist aufgeben konnte, aber ich hatte auch nichts ausser Zeit zu verlieren. Also versuchte ich es mehrmals mit Einfrieren, drehte sie mal auf den Kopf oder auf die Seite (man weiss nie ob die Gravitation auch ein wenig hilft), verhinderte Vibrationen, drückte drauf... Es half alles nichts, obwohl sie manchmal tatsächlich wieder startete. Schliesslich kam mir die Idee, dass durch eine Erwärmung das Material erneut verformt würde... ausserdem würde die ständige Vibration womögliche Blockaden vielleicht überwinden. Also liess ich sie einige Stunden bei Zimmertemperatur in Betrieb und versuchte gelegentlich, etwas zu kopieren.

Es klappte! Ich konnte einzelne kleine Dateien kopieren, nur einige Verzeichnisse konnten gar nicht erst gelesen werden. Oft gab es auch beim Kopieren Lesefehler, aber nach mehrfacher Wiederholung klappte es und die Dateien waren tatsächlich korrekt mit Inhalt gefüllt. Irgendwann erreichte die Platte angenehme +40°C und etwa ab da passierte es: Es ging wieder! Alles! In grosser Euphorie kopierte ich die wichtigsten Dateien, ging dann weiter zu den seltenen Downloads und als auch da keine Probleme auftraten, kopierte ich kurzerhand die gesamte Festplatte auf eine andere. Ein unglaublicher Erfolg!

Ich weiss nicht, ob sie jetzt noch funktionieren würde, aber meine Bitte nach einem "letzten Mal" hat sie schonmal tadellos erfüllt. Brave Festplatte. Mittlerweile war es Mittwoch und der gestern bestellte Ersatz kam bereits per Post an, so dass ich die Daten bereits wieder auf den Server kopieren konnte. Ironie des Schicksals: Als die Vermutung nahe lag, nichts mehr retten zu können, startete ich einen Transfer der Minecraft-Welten von Jeromys Backup. Er war in derselben Minute abgeschlossen, in der ich die Welten von der defekten HD zurücktransferiert hatte. Aber ich will mich nicht beschweren; die Originaldaten sind wieder da und das Backup hätte allenfalls einwandfrei funktioniert. Und auch das Wetter meint es heute nochmal wolkig gut, bevor die Sonne in den nächsten Tagen laut Wetterbericht so richtig aufdreht.

Nach diesen zeitweise von knisternder Spannung erfüllten Tagen kehre ich nun also wieder zu Endyr zurück und setze die Entwicklung fort. Onwaaard!

Abwechslung

Die letzten Tage waren ziemlich abwechslungsreich, leider aber lassen sich die Früchte meiner Arbeit auch weiterhin kaum bildlich darstellen. Ich fasse sie daher kurz zusammen:

1) NPC-Animationen. Bisher waren alle Figuren auf eine einzige Animation beschränkt (z.B. "laufen" bei fast allen Figuren oder ein ständiges Flügelschwingen bei Flugwesen). Neu kann man für einen NPC beliebige Animationen festlegen. Mein Testobjekt, der Pogopuschel, beherrscht einige davon.

2) KI-Entscheidungen. Besagter Pogopuschel ist ein quirrliger Zeitgenosse. Meistens hüpft er fröhlich umher, wirbelt durch die Luft oder macht ein Nickerchen. Kommt ihm jedoch ein böser Spieler zu nahe, beisst er gerne zu und hüpft dann schnell weg. Wird er leicht angegriffen, bringt er sich in Sicherheit und schüttelt erstmal den Kopf, ehe er weiterspringt - oder komplett geduckt bleibt, falls er kaum mehr Energie hat. Das alles wird von oben genannten Animationen hübsch dargestellt.

3) Wie eben erwähnt können NPCs jetzt hüpfen statt nur gehen (und dabei auch noch animiert sein). Ist noch nicht perfekt, reicht aber für den Augenblick.

4) Patroullien. Durch Kombination der neuen KI-Möglichkeiten können NPCs in Kenntnis bringen, in welchem Raum oder Gebiet sie sich befinden. So konnte ich ein kleines Testlevel mit verschiedenen Räumen gestalten, in dem ein NPC von Raum zu Raum schlendert und entsprechende Kommentar abgibt.

5) Das Schadensmodell wurde erweitert, neu ist die Schadensart "Elektro" für Blitze und generell Stromschläge dazugekommen. Ausserdem haben jetzt auch NPCs eine Schadensart, so fällt z.B. der Biss eines Pogopuschel unter Stichschaden, ein Schwerthieb hingegen ist Hiebschaden. Es kann jetzt also auch Rüstungen geben, die z.B. gegen Elektroschocks oder Flammen helfen, sonst jedoch keinerlei Schaden abwehren.

So viel zu den Neuigkeiten. Ich lenke nun meine Kraft weiter in Richtung Gegner und Schadensmodell, weiterhin stehen auch Zeiteffekte (z.B. Alkohol, nachdem man ein Bier trinkt, oder der Heilprozess, nachdem man etwas gegessen hat) auf dem Plan. Es ist noch unklar, ob man diese Effekte ("Buffs") sehen wird, oder nur ihre Auswirkungen spürt. Ich tendiere zu Letzterem.