Endyr Entwicklerblog

Eigene Grafiken

Auch wenn es meine Zeit eigentlich nicht zulässt, stelle ich neuerdings fast täglich Pixelgrafiken für Endyr her. Die Gründe dafür liegen auf der Hand; selbstgemachte Grafiken haben alle denselben Stil, passen entsprechend gut zueinander, vermitteln die Seele des Spiels und oft sind sie auch schlichtweg aus technischen Gründen unumgänglich. Einen Vorgeschmack dazu gibt es bereits in der Galerie unter "Endyr", für eine spätere Dokumentation habe ich die Grafiken aber auch in der Library untergebracht:

• lib.yhoko.com/de/Endyr/Mobiliar/

Von diesem Bremsklotz abgesehen geht die Entwicklung gut voran; Gebäude können mittlerweile von Spielern errichtet werden und die Innenräume (Böden und Wände) lassen sich ebenfalls gestalten, vom Platzieren des oben gezeigten Mobiliars mal ganz zu schweigen. Das alles stand zwar nicht wirklich auf dem Plan, tut dem Spiel aber letztendlich sehr gut. Für mich entfällt damit auch die Pflicht, den Spielern eine Basis herzurichten – sollen sie ruhig selbst eine aufbauen, wo auch immer sie möchten. Noch unklar ist dabei nur, wo man überall bauen kann. Rein schon aus technischen Gründen muss es Einschränkungen geben, aber voraussichtlich werden alle grösseren Wiesenflecke in Bauland umgewandelt.

Aktionspunkte

Es hilft eben nichts; was man immer wieder vor sich herschiebt, wird einen irgendwann einholen. Ich rede diesmal von den Objekten wie Amboss, Schrank, Herd und Bett. Diese Dinge haben eines gemeinsam; man kann sie benutzen bzw. bedienen und zwar solange sie in Reichweite sind. Anfangs war das nur eine Distanz-Prüfung; ein simpler Pythagoras. Aber was, wenn das Objekt ausser Reichweite war? Um die Sache einfach zu halten versuchte das Skript, die Spielfigur möglichst nahe zum Objekt zu bewegen und es dann erneut zu bedienen. Das klappt auch - meistens. Nicht so bei der Statue, denn die war ziemlich gross und belegte mehrere Felder in der Kollision-Map. Kam der Spieler also von der Seite oder von hinten heran, lag der Mittelpunkt immer noch ausser Reichweite. Da der Mittelpunkt glücklicherweise meist unten in der Mitte der Grafik liegt, war es dann naheliegend, das als Zielpunkt der Bewegung festzulegen. Und falls die Figur am Ende doch von der Seite her kam, etwa weil der Weg zur Mitte blockiert war, liess ich weiterhin die Abstandsberechnung nicht mehr nur zum Mittelpunkt sondern auch zu jedem Kollisionsfeld hin gelten. Und siehe da, auch Statuen waren nun nutzbar.

Gestern jedoch wollte ich einen Schrank öffnen, und dieser Schrank stand seitlich, man sah also nur die Seitenwand und der Mittelpunkt lag bei dieser unten zentriert. Klickte man den Schrank an, wanderte die Figur dorthin und öffnete von da den Schrank. Sah komisch aus. Schlimmer noch; stand die Figur schön korrekt vor dem Schrank, war der Mittelpunkt ausser Reichweite und sie marschierte wieder erst neben den Schrank. Gut, damit könnte man leben, aber was passiert wohl, wenn neben dem Schrank ein Tisch steht? Richtig, dann wäre der Mittelpunkt des Schranks quasi im Tisch und damit unerreichbar. Gut, der Server hätte das akzeptiert, denn er berechnete die Distanz nun ja auch zu jedem Kollisionsfeld, aber der Client wusste ja nicht, welche Felder zum Schrank gehören. Konnte er nicht, und wird er auch nie. Das war also eine Sackgasse.

Lösung? Schweren Herzens musste ich das Umsetzen, was von Anfang an hätte sein sollen: Aktionspunkte. Bei jedem Objekt ist nun festgelegt, von wo aus man es bedienen kann. Der Schrank hat z.B. je einen Aktionspunkt links und rechts, der Amboss davor und dahinter, das Zeichenbrett nur einen davor. Es kostete mich deutlich mehr Arbeit (und die CPU jeweils deutlich mehr Rechenzyklen), aber wenn man jetzt ein Objekt anklickt, sucht die Engine den Pfad zum nächsten Aktionspunkt, bewegt die Figur dorthin, dreht sie passend zum Objekt und führt dann die Tätigkeit aus.

Als kleiner Bonus hat sich nun noch etwas ergeben: War ein Objekt bisher von mehreren Spielern gleichzeitig bedienbar (sagen wir mal ein Tisch für 4 Personen), so konnten diese bei der Benutzung irgendwo in Reichweite stehen - selbst übereinander, bzw. sogar sehrwahrscheinlich übereinander, da sich aufgrund des Clients alle in der Nähe des Mittelpunkte befanden. Nun aber besetzt jeder einen eigenen Aktionspunkt und es ist vorgegeben, wo sich diese befinden (mit einem kleinen Spielraum, falls man bereits in der Nähe steht). Zudem weiss der Client nun bereits im Vorfeld, ob überhaupt noch ein Platz am Objekt frei ist.

Manchmal macht man die Arbeit eben doppelt, wenn man sie sich spart.

Monatliche Beiträge sind nicht jedermanns Sache.

• Keine Lust auf ein Abo?
• Lieber einmalig kaufen statt monatlich zahlen?
• Dabei am besten auch noch die Entwicklung unterstützen?

Um diesem Wunsch entgegenzukommen habe ich mir ein Sonderangebot überlegt: Für nur EUR 29.90 könnt ihr bereits jetzt einen zeitlich unlimitierten Endyr-Account vorbestellen! Ganz ohne Registrierung, ihr erhaltet einfach per E-Mail einen Freischalt-Code – oder mehrere, um sie als Geschenk weiterzugeben. ;-)

• Hier gehts zur Vorbestellung

Wer Endyr wirklich unterstützen möchte hat ausserdem die Möglichkeit, einen höheren Betrag zu wählen, um zusätzlich etwas zu spenden.

Ich danke im Voraus für eure Unterstützung!

Yhoko

Endyr goes Greenlight

1) Nach einem Hinweis aus der Community habe ich Endyr bei Steam Greenlight angemeldet. Wenn ihr einen Steam-Account habt, votet, favorisiert, folgt, teilt und kommentiert den Beitrag, um Endyr zu unterstützen. Wenn nicht, registriert einen und fangt nochmal bei 1) an! ;-)

• [http] Endyr on Greenlight

Endyr goes YouTube

Videos sind modern und werden heutzutage als selbstverständlich erachtet, doch selbst kurze Aufnahmen sind eine Heidenarbeit. Dennoch habe ich damit angefangen, Endyr zu verfilmen, um euch einen Einblick in das Spiel zu verschaffen:

• [http] Yhoko's YouTube channel

Feinschliff

In den letzten 2 Wochen gabs leider keine Updates zu Endyr, denn ich musste mich um andere Dinge kümmern. Die kleine Pause hat dazu geführt, dass ich wieder mit neuen Augen an das Projekt herangehen konnte und dabei fiel mir auf, dass die technische Seite so gut wie fertig ist. Ich kann mit Stolz behaupten, dass die Endyr-Engine ziemlich mächtig (d.h. umfangreich und flexibel) ist – nun müssen diese Möglichkeiten "nur" noch zielgerichtet eingesetzt werden.

In einem ersten Schritt habe ich die Char-Erschaffung um die Klassenangabe (Krieger, Handwerker oder Alchemist) erweitert. Dadurch wird nun auch die Startkleidung festgelegt, so dass man nicht im Nachthemd loslegen muss.
Während ich diesen Beitrag schreibe, arbeite ich am Taming (Tiere zähmen), welches voraussichtlich ohne Skills ablaufen wird. Eventuell muss man ein Talent freischalten, um bestimmte Tiere überhaupt zähmen zu können, grundsätzlich gewinnt man aber ihr Vertrauen, indem man sie einfach füttert, also ihnen Essen vor die Pfoten wirft. Dass Tiere nun auf dahergeworfene Gegenstände reagieren können ist ein schöner Beweis für die Flexibilität der Engine, denn bis vor 10 Minuten war das noch nicht der Fall – selbst ein Neustart des Endyr-Servers war nicht erforderlich.
Und schliesslich, als kleiner Ausblick in die Zukunft, werde ich mich noch um die eben erwähnten Talente kümmern, denn bisher gibt es weder einen Weg, diese freizuschalten, noch die Möglichkeit, überhaupt an EP zu kommen. Wie genau diese verteilt werden kann ich leider erst erklären, wenn das alles umgesetzt wurde.

Dass noch viel Feinschliff vonnötigen ist – und daher der Titel dieses Beitrags – sehe ich immer wieder. Zwar sind mittlerweile alle möglichen Funktionen implementiert, aber die Werte sind noch völlig "krumm". So dauert es z.B. nur 30 Sekunden, einen Blumenkohl zu züchten, was zwar zum Testen ungemein praktisch ist, doch für Spieler viel zu kurz (so viel könnt ihr in der Zeit gar nicht giessen, wie das Ding verschluckt ;-). Derartige Situationen klaffen momentan noch an jeder Ecke von Endyr und ehe ich die erste Beta ausrufen kann, müssen all diese Werte vernünftig festgelegt sein. Womöglich wird auch erst noch eine dritte Alpha folgen, um genau das auszutesten.

Nach diesem Update verweise ich nochmal auf den [http] YouTube Channel, den ihr bitte abonniert und fleissig +1 (bzw. Daumen-hoch oder was auch immer) anklickt. Weiterleiten an Freunde und Interessierte ist ebenfalls erwünscht! Und bitte nutzt die Gelegenheit zur [Y.de] Vorbestellung, um euer Interesse an Endyr zu zeigen und mich zusätzlich zu motivieren! :-)

Yhoko

Yaecron

Durch die Weiterentwicklung der Engine für Yaecron hat auch Endyr neue Fähigkeiten dazugewonnen. Wie der aktuelle Screenshot zeigt, sind Gegenstände in Objekten nun auch tatsächlich in der Welt sichtbar – ein Problem, dass ich lange für zu aufwändig hielt. Gerade für flache Objekte wie Tische, Kommoden oder eben Regale wird das in dreifacher Hinsicht praktisch: erstens muss ich jetzt keine Deko mehr pixeln (der Tisch ist eben leer, bis der Spieler ihn selbst mit Tellern und Besteck gestaltet), zweitens werden "offene" Behälter nun wertvoller als z.B. geschlossene Kisten, was dem Balancing gut tut und drittens sind damit neue Gegenstände wie z.B. eine Blumenvase oder Trophäen sehr einfach umzusetzen – und das wiederum gefällt den Spielern (hoffe ich ;-)

Fazit: An zwei Projekten mit derselben Engine zu arbeiten ist nur leicht anstrengender, macht dafür aber viel mehr Spass und ist spürbar effizienter. Ich bin froh, dass mich der Geistesblitz zu [http] Yaecron erwischt hat.

Yhoko

Zurück auf Los

Dass sich an Endyr schon lange nichts mehr getan hat, liegt vor allem daran, dass mein Kopf mit Auftragsarbeiten gefüllt ist. In diesem Zustand reicht die Denkkapazität nur noch für simple Aufgaben wie etwa das Blog-System oder Spielereien wie die persönlichen Zahlen und Fakten aus. Was nun Endyr betrifft stehen aber sehr knifflige Aufgaben an, wie etwa die Umsetzung der künstlichen Intelligenz für allerlei Gegner und die Tierwelt. Dennoch zieht es meine Gedanken immer wieder zu Endyr zurück und manchmal kann ich einfach nicht anders, als weiterzumachen – und da stehen wir nun.

Die grössere Denkpause hat auch einen kleinen Vorteil, und zwar den Perspektivenwechsel. Ich konnte das Projekt wieder aus der Distanz und als Ganzes betrachten und dabei Probleme angehen, die mir aus der Nähe nie aufgefallen werden. Aus diesem Grund habe ich die Gesundheitsanzeige vereinfacht, so dass man statt einzelner Körperteile nur noch einen einzigen Balken hat. Ausserdem ist nun der Sichtradius an die Gesundheit gekoppelt, d.h. je mehr Lebensenergie man hat, desto weiter sieht man im Dunkeln. Für Abenteurer ist das eine nette Zugabe, aber da sie im Kampf mit Monstern häufig Energie verlieren, können sie auf herkömmliche Lichtquellen nicht verzichten. Arbeiter hingegen, die in sicherer Umgebung z.B. Eisenerz abbauen, können sich dadurch aber das Hantieren mit Fackeln sparen. Weiterhin ist nun geplant, Rennen und Kämpfen an diese Lebensenergie zu koppeln, denn der Spieler soll sich jeweils gut überlegen, wann und ob er kämpft und rennt. Auch dabei kommen die Arbeiter in sicheren (also gut ausgeleuchteten) Gefielden wieder gut weg, denn dort lädt sich die Lebensenergie kontinuierlich auf.

Schliesslich habe ich einen kleinen, aber wichtigen Trennstrich zwischen Tieren (passive, meist ungefährliche Ressourcen) und Monstern (aktive, meist gefährliche Ressourcen oder einfach nur Hindernisse) gezogen. Die Monster sind nämlich hinter den Spielern her und wollen ihre Lebensenergie stehlen, Tiere hingegen nicht. Das heisst aber auch, dass Monster eben jene Energie freigeben, wenn man sie besiegt – sie hinterlassen also Lux zum Aufsammeln. Lux wiederum lassen sich in Lebensenergie umwandeln, oder ums auf den Punkt zu bringen: Wer reich ist lebt länger. Vor allem aber können sich Abenteurer so auch tief im Dungeon noch über Wasser halten, wenn ihre Nahrungsvorräte und Heiltränke längst aufgebraucht sind. Zumindest bis ihre Waffen und Rüstungen auseinanderfallen und sie endgültig verloren sind.

Zum Schluss kann ich also ein besseres Gameplay in Aussicht stellen und dass sich Endyr nun stärker auf seine Kernkompetenz konzentrieren wird – das Spiel um Licht und Schatten.

Yhoko

Wichtige Details

Im letzten Beitrag habe ich von einem neuen Ansatz berichtet, das ist nun auch schon wieder ein halbes Jahr her. In der Zwischenzeit hat sich das Projekt nur tröpfchenweise entwickelt, was wie üblich daran liegt, dass ich zahlende Kunden bedienen muss und auch möchte. Seit einigen Tagen kann ich aber wieder etwas Kapazität für Endyr erübrigen, wie ihr sicher auch anhand der neuen Screenshots schon bemerkt habt. Im Wesentlichen wurde das mit dem Rennen umgesetzt, wenngleich die Kopplung an die Lebensenergie zum Schluss doch wieder wegfiel – stattdessen gibt es nun den zusätzlichen Wert "Ausdauer", der sich über Zeit wieder auflädt und lediglich durch die Lebensenergie begrenzt wird, sie aber nicht beeinflusst. Insbesondere gab es aber auch Änderungen am Interface; so erscheint jetzt kurz ein rotes "X", wenn ein Klick zu nichts führt, und die Aufladezeit vor dem Rennen wird visuell dargestellt. Beides zusammen fühlt sich viel flüssiger und verständlicher an (speziell für Neueinsteiger, denn bisher wusste man nie genau, ob der Klick nun falsch war, der Befehl nicht ankam oder der Server gerade laggt).

Nun der Ausblick in die Zukunft. Man kann mittlerweile sagen, dass die Technik in den Hintergrund rückt und Fragen zum Spielprinzip immer wichtiger werden. Insbesondere folgende Punkte haben sich dabei als Stolpersteine erwiesen:

• Wo kommen neue Spieler her?
• Wie können sie sich in der Welt etablieren?
• Welche Ziele sollen sie anstreben und warum?
• Funktioniert das Spiel bei (zu) wenig aktiven Spielern?
• ...und bei immer weiter wachsender Spielerzahl? (Stichwort Bauplatz)
• Wie werden neue Siedlungen gegründet und gehandhabt?

Dazu kommen komplexere Fragestellungen, wie etwa der Nahrungskreislauf, Fortschritte innerhalb des Spiels und das übergeordnete Spielziel – nach wie vor steht das Überleben an erster Stelle, aber so wie Endyr sich bisher anfühlt, gibt es überhaupt keine Bedrohungen und viele Zufallsgegner wären eher lästig als spieltechnisch hilfreich.

Für all dieses Probleme gab es bisher keine Lösung und sicher ist das auch ein Mitgrund für die zögerliche Entwicklung des Projekts. In einem früheren Anlauf und wegen ähnlicher Fragen habe ich die Währung Lux und die Bastion eingeführt, um z.B. die Situation bei zu geringen Spielerzahlen zu entschärfen. Sie verhindert etwa, dass neue Spieler gleich wieder wegsterben, weil es noch keine etablierten Bauern (Nahrung und Rohstoffe), und keine Schmiede (Waffen und Rüstungen) gibt. Anfangs war das alles anders geplant, aber mit der Zeit hat sich einfach unmissverständlich gezeigt, dass das Spiel ohne derartige Elemente nicht funktioniert.

Nun stand ich also vor einer ähnlichen Situation und sah keinen anderen Weg, als das Spielkonzept erneut anzupassen, mit anderen Worten: Zurück ans Reissbrett. Die gute Nachricht ist, dass ich bereits einen Geistesblitz hatte, mit dem sich tatsächlich alle offenen Probleme auf einen Schlag lösen lassen: Die Umsiedlung auf den Mars. Welche Änderungen das mit sich bringt, möchte ich hier kurz beleuchten:

Die Marskolonie

Neuer Ausgangspunkt des Spiels ist eine Marsbasis, um die herum eine Kolonie aufgebaut wird. Neue Spieler kommen also von der Erde und werden ganz einfach mit Shuttles hergebracht. Ob freiwillig oder nicht, das liegt bei euch, aber man kann davon ausgehen, dass sie entweder alles zurücklassen wollen (oder müssen), denn der Mars ist gefährlich und die Arbeit dort knüppelhart, oder dass sie ohnehin nichts zu verlieren haben und die Chance auf ein neues Leben nutzen.

Der Spielverlauf ist damit ebenfalls grob vorgegeben; man fängt mit nichts (genauer: mit einem Schuldenberg) an und soll sich etwas aufbauen. Das fängt mit kleinen Jobs an, man verdient die ersten Credits, arbeitet in der Mine oder in einem Gewächshaus, verteidigt Funkanlagen, leistet sich bald einen eigenen Rover, eigene Waffen, zahlt die Schulden ab, stellt irgendwann ein eigenes Haus (sprich: Siedlungsmodul) auf, investiert in technische Geräte wie Solarzellen und 3D-Drucker, schützt das eigene Heim mit Kampfdrohnen und Geschütztürmen, fertigt bald eigene Werkzeuge an und leistet damit insgesamt seinen Beitrag zur Kolonie. Wie bisher schon hat man die freie Wahl, auf welche Art man sich nützlich macht; sei es durch Ackerbau, Minenarbeit oder Ressourcenbeschaffung durch Gegnerjagd. Apropos Gegner, dabei dachte ich an Roboterwesen, intelligente Luftwirbel, vielleicht auch Aliens oder lebende Pflanzen (in den Marsöhlen), der Mars wird also nicht so "leer" wie in der Realität.

Damit sind die wesentlichen Probleme des Spielkonzepts bereits aus der Welt geschafft, aber es geht noch weiter: Durch den modularen Aufbau kann man seine Wohneinheit ziemlich frei gestalten, durch den schnellen Ortswechsel (via Transportshuttle) gibt es unendlich Bauplatz für jeden. Für den kleinen Nebenverdienst kann man Sonden und Bohranlagen aufstellen, muss sie aber regelmässig reinigen. Wer mehr auf Action steht, findet in den zufällig erzeugten Höhlensystemen immer neue Herausforderungen und der Mars bietet mit seiner extrem kalten Atmosphäre ohne Sauerstoff, übertriebenen Sandstürmen, Meteoriteneinschlägen, Strahlengewittern und Erdbeben schon für sich grosse Schwierigkeiten, die es zu meistern gilt. Ausseneinsätze sind durch die Strom- und Sauerstoffreserven begrenzt, die sich mit der Zeit aber immer weiter aufstocken lassen.

Womöglich wäre es sinnvoll, dem Projekt einen neuen Namen zu geben, da es sich zumindest optisch doch recht stark vom ursprünglichen Endyr abhebt. Andererseits hat das ja auch als Zombiespiel angefangen und ist dann ziemlich ins Mittelalter abgedriftet. Auf jeden Fall aber bin ich überzeugt, dass das Spiel mit dem neuen Setting auch wirklich als solches funktionieren wird – und das ist letztendlich die Hauptsache.

Yhoko

Ein Update in eigener Sache: Das Entwickler-Tagebuch wird künftig in folgendem Blog-Format fortgesetzt:

• blog.yhoko.com/dev/

Als Yuser könnt ihr den Blog "Beobachten" oder unter "Newsletter" eure E-Mail Adresse eintragen.

Yhoko