Iliran

Kommentare anzeigen Worklog abonnieren
Gehe zu Seite Zurück  1, 2

Worklogs Iliran

Neuer Mapdesigner, NPC-Editor und flexiblere Listensteuerung

Freitag, 30. Oktober 2009 von Lador
Nachdem ich hier schon länger nichts mehr geschrieben habe, ist es diesmal (etwas) mehr. ^^

Zuerst einmal wollte ich vor ca. 2 Wochen mal wieder meinen Quest-Editor anschauen, weil ich ein paar Werte einer Quest ändern musste, damit diese aktuell auf meiner TestMap funktioniert. Dann bemerkte ich nur leider, dass kein Ordner "Quest-Editor" mehr auf meiner Festplatte existiert. Dachte mir dann "na toll, darfste des Ganze nochmal machen, dauert locker 1-2 Wochen". Allerdings ist mir nach ungefähr 15 Minuten eingefallen, dass ich meine ganzen Programmierdaten (alle paar Monate mal ^^) auf meinen USB-Stick speichere. Und dann hatte ich auch meinen Quest-Editor wieder. ^^ So viel dazu.

Ich habe schon vor einigen Wochen damit angefangen, die Fertigkeiten flexibler zu machen. Bis jetzt hatte ich alles manuell gespeichert. Der Spieler-Type hatte für jede Fertigkeit einen extra Field-Eintrag. Jetzt habe ich aber ein Array Fertigkeiten:TFertigkeiten[16] als eigenen Field-Eintrag. Der Type dazu sieht folgendermaßen aus:

Code: [AUSKLAPPEN]

Type TFertigkeit
   Field Name:String
   Field Level:Byte
   Field ActExp:Float
   Field NextExp:Short
End Type


Name ist die Bezeichnung der Fertigkeit, also zum Beispiel "Lange Klingen". Level ist die derzeitige Stufe der Fertigkeit (es geht von 5-100), je höher die Stufe, desto besser ist man im Umgang mit dieser Fertigkeit. ActExp (=aktuelle Experience) gibt an, wie viel Erfahrung man auf der derzeitigen Stufe des Fertigkeitslevels schon gesammelt hat. NextExp ist die Erfahrung, die man braucht, um ein Fertigkeitslevel aufzusteigen (ActExp = NextExp -> ActExp = 0; NextExp wird neu berechnet). Namen und Level schreibe ich manuell im Hauptprogrammcode, das sieht ca. so aus:

Code: [AUSKLAPPEN]

p.Fertigkeiten[1].Name  = "Lange Klinge"
p.Fertigkeiten[1].Level = 20
p.Fertigkeiten[2].Name  = "Axtkampf"
p.Fertigkeiten[2].Level = 25
[...]


Level bekommt dann später je nach Klasse einen individuellen Startwert.
Dann habe ich zwei weitere Arrays (außerhalb des Spieler-Types) gemacht, nämlich Hauptfertigkeiten:Byte[5] und Nebenfertigkeiten:Byte[10]. In beiden werden die Index-Nummern des Fertigkeits-Arrays gespeichert.

In den letzten 2-3 Wochen habe ich dann die Umstellung von Arrays zu Listen bei den NPCs und den Gegnern vollzogen. Außerdem werden jetzt beide aus Dateien gelesen. Dazu habe ich dann noch die Gegner-Typen "erfunden". Das ist sozusagen eine Schablone für eine gewisse Art von Gegnern. Das spart vor allem Speicher der Dateien, aus denen die Gegner gelesen werden. So ein Gegner-Typ speichert grundlegende Dinge wie zum Beispiel den Namen, die maximale Lebensenergie, den Rüstungsschutz etc. Die Dinge, die von Gegner zu Gegner (meistens) unterschiedlich sind, wie zum Beispiel die Position x/y, die Map, auf der der Gegner anzutreffen ist etc. Dazu hat der Gegner-Type einen extra Field-Eintrag "Typ:Byte". In der Funktion LoadGegner() wird dann nachdem die gegnerspezifischen Daten aus "Gegner.ild" geladen werden, noch die Datei "GegnerTyp.ild" geöffnet und nach der Schablone gesucht, der die Nummer "Gegner.Typ" hat.

Passend dazu habe ich in den letzten Tagen den "NPC- und Gegner-Editor" programmiert. Mit diesem kann man NPCs, Gegner und Gegner-Typen erstellen und bearbeiten:

user posted image

Auf der rechten Leiste kann man die Attribute auswählen und bearbeiten. Wenn das Side-Menü gerade geschlossen ist, kann man einen bereits erstellten NPC oder Gegner auf der Karte auswählen und bearbeiten oder löschen. Bei einem vorhandenen Gegner-Typ muss man dessen ID kennen.


Ich hoffe, ich habe es nicht zu kompliziert ausgedrückt und ihr konntet es gut verstehen und fandet es interessant. ^^


So, zum Schluss möchte ich jetzt noch den neuen Mapdesigner von Iliran vorstellen: Cireva. Da mein alter Mapdesigner Terabite wegen mangelden Zeitgründen leider abspringen musste, übernimmt Cireva jetzt seinen Job. Auf gute Zusammenarbeit!

Codeoptimierungen und Interface-Erweiterungen

Dienstag, 28. Juli 2009 von Lador
Da ich nun 3 Wochen kein Internet hatte, habe ich mich in dieser Zeit um das Aussehen meines Codes gekümmert. Ich habe zum Beispiel Tabs statt Leerzeichen benutzt und die Variablennamen teils sinnvoller benannt und vor allem groß geschrieben. Also zum Beispiel "HPMax" statt "hpmax", weil das alles einfach viel übersichtlicher macht.

Als das dann geschafft war, habe ich mich noch überwiegend um das Interface gekümmert. Vor allem waren das kleinere Verbesserungen bzw. Beseitigen von Bugs im Inventar, das Hinzufügen des Zaubermenüs (also das Zauber-Inventar) und die Hotkey-Leiste. In der Hotkeyleiste kann man Waffen und Zauber ablegen, um dann später schneller mittels Tastendruck darauf zugreifen zu können. An sich ist diese sehr simpel aufgebaut:

Code: [AUSKLAPPEN]
Type THotkey
   Field Image:TImage
   Field Typ:Byte
   Field ID:Short
End Type


Image speichert den Icon der Waffe/des Zaubers. Typ kann entweder 1 (=Waffe) oder 2 (=Zauber) sein, damit das Programm später weiß, ob die Waffe aus der WaffenList oder der Zauber aus der ZauberList gesucht werden soll. ID speichert die Nummer der Waffe/des Zaubers.


Demnächst werde ich dann noch die Zauberart einbauen, dass man Monster beschwören kann und diese dann von alleine einen Gegner angreifen. Danach muss ich noch eine flexible Verwaltung der Fertigkeiten (da ja jede Klasse andere Hauptfertigkeiten hat) und Fertigkeitenaufstiege machen.

Einige Verbesserungen und Ingame-Video

Freitag, 26. Juni 2009 von Lador
Lange hats gedauert, aber jetzt ist mein Video doch fertig geworden! Vorher habe ich noch einige Verbesserungen für das Video vollzogen. Zum Beispiel habe ich ein paar grafische Effekte eingebaut, das heißt, wenn man getroffen wird, blinkt der Spieler rot; wenn man sich heilt, blinkt er gelb. Ebenfalls im Video sehr gut zu sehen, ist, dass Spieler und Gegner beim Angriff nun eine Schrittanimation machen. Zudem haben Spieler, NPC und Gegner nun Schichten, dadurch wird der Spieler nicht mehr immer nur über den NPCs und den Gegnern gezeichnet, sondern er passt sich seiner Lage an. Außerdem habe ich noch die Pixel-by-Pixel-Engine eingebaut. Allerdings werde ich gegen Ende der Entwicklung noch einmal Verbesserungen an den genannten Punkten vornehmen.

Das Video selbst hat keinen Ton. Ihr könnt euch entweder die Youtube- oder die MyVideo-Fassungen ansehen, oder das unkonvertierte 60FPS-Original (40 MB) herunterladen. Im Übrigen sind die Quest, die NPCs, die Items und die Welt nur Testobjekte. Vielleicht kommen sie im späteren Spiel auch vor, gewiss ist es aber nicht.

http://www.youtube.com/watch?v=7gAJsyzlsUI
http://www.myvideo.de/watch/6616714/Iliran_Ingame
http://www.fileuploadx.de/910981

Einige Dinge, die man im Video noch nicht sehen kann, werde ich noch einbauen. Zum Beispiel:
-animiertes Wasser
-verschiedene Blutflecken
-evtl. Blutspritzer
-die Leichen der Gegner in ihrem Blut
-Interface
-evtl. die Schriftgröße beim Sprechen mit den NPCs und auf jeden Fall, wie viel in einer Zeile steht
[Edit:]-animierter Zauberschuss (im Video der kleine Feuerball, der auf den Gegner geschossen wird und in einem Turm aufgeht)


Anregungen, Verbesserungsvorschläge, konstruktive Kritik und natürlich Lob sind erwünscht! Ich hoffe, das Video gefällt euch und gewährt euch einen guten Einblick in Iliran.

MFG Lador

Das Quest-System, Teil 3

Montag, 25. Mai 2009 von Lador
Wie gesagt, habe ich mich in den letzten Tagen mit dem Einbinden der Quest-Engine in mein Hauptprogramm beschäftigt. Es lief eigentlich kaum ohne große Schwierigkeiten ab, jedoch musste ich zu meinen bisherigen Types aus dem Quest-Editor einige hinzufügen. Im Hauptprogramm sehen diese nun wie folgt aus:

Code: [AUSKLAPPEN]
Type TQuest
   Field ID:Short
   Field Name:String
   Field StartBedingung:String
   Field StartBedingungParam:String
   Field StartList:TList = New TList
   Field QuestList:TList = New TList
   Field GeschafftVar:Byte
End Type

Type TAufgabe
   Field Typ:Byte
   Field Art:String
   Field ParamX:Short
   Field ParamY:Short
   Field GeschafftVar:Byte
End Type


Wie ihr sehen könnt, haben sich lediglich die Field-Einträge "GeschafftVar:Byte" in beiden Types geändert. Diese speichern eine Zahl, die benötigt wird, um zu überprüfen, wie weit der Spieler schon mit der Quest gekommen ist und welche Effekte dann abgespielt werden. Diese Werte werden nach dem Einlesen und Speichern der Quests aus den Dateien ermittelt. Dabei lasse ich einfach einen Wert (von mir genannt "QuestGeschafft") zählen, wie viele "Aufgaben" bis jetzt erfüllt wurden. Standardwert ist natürlich 1. Den "Effekten" wird der Wert "QuestGeschafft" unter "GeschafftVar" zugeordnet. Bei den "Aufgaben" auch, nur wird zusätzlich der Wert um 1 erhöht, damit das Programm weiß, dass die folgenden Effekte erst abgespielt werden, wenn die Aufgabe erfüllt ist.
Der Field-Eintrag bei TQuest speichert, wie weit die Quest schon fortgeschritten ist. Wenn Quest.GeschafftVar = Effekt.GeschafftVar, wird der Effekt abgespielt. Wird eine Aufgabe erfüllt, wird Quest.GeschafftVar = Aufgabe.GeschafftVar. (Tut mir leid, wenn es etwas verwirrend klingt. Ich hoffe, ich habe hierbei nichts vergessen.)

Im Hauptprogramm sind schon die wesentlichsten Aufgaben und Effekte vorhanden. Die anderen werde ich in einigen Wochen (wenn das Programm etwas vollständiger ist, zum Beispiel gibt es noch kein Tagebuch, weshalb der Effekt "Tagebucheintrag" bis jetzt nutzlos ist) noch einbauen. In den nächsten Tagen/Wochen werde ich trotzdem noch etwas daran feilen.


Das war jetzt ein (im Vergleich zu den vorherigen) relativ kurzer Eintrag und wahrscheinlich auch der letzte zum Quest-System. Sollte ich noch etwas diesbezüglich einbauen, werde ich es in einem späteren Worklog schreiben. Bevor ich jedoch bald das Ingame-Video machen werde, muss ich noch ein bisschen an den wesentlichen Sachen werkeln, zum Beispiel wollte ich noch das Kampfsystem etwas verbessern, damit es für das Video auch gut rüberkommt. ^^

Das Quest-System, Teil 2

Dienstag, 19. Mai 2009 von Lador
Nachdem ich nun schon länger keinen Eintrag mehr geschrieben habe, weil ich viel in der Schule viel zu tun hatte, werde ich das jetzt nachholen.

In den letzten zwei Wochen habe ich mich immer noch mit dem Quest-Editor beschäftigt. Hauptsächlich eigentlich nur noch die Bedienung, ein bisschen musste ich auch noch am Quest-System feilen. An den Types hat sich eigentlich nur noch das Field "ID:Short" bei TQuest geändert, damit die Quest genau indentifizierbar ist.

Ich hatte in den letzten Tagen auch ein paar Probleme mit dem Speichern und Laden der Datei, in der die Quests gespeichert werden. Da man ja nicht genau weiß, wie viele Aufgaben bzw. Effekte in der QuestList vorhanden sind, war das etwas schwierig und mein Programm wollte nicht so, wie ich wollte. Habe das jetzt aber so gelöst, dass jede Quest in eine eigene Datei kommt. Somit können die Anzahl der Aufgaben/Effekte genau ausgelesen werden.


Auf Wunsch von Dottakopf und auch, weil ich es versprochen hatte, erkläre ich nun noch einmal, wie das Quest-System funktioniert (bzw. funktionieren soll, immerhin ist es noch nicht im Hauptprogramm eingebaut):

Es gibt zwei Types, TQuest (allgemein für die Quests) und TAufgabe (für Aufgaben und Effekte). Diese sind wie folgt aufgebaut:
Code: [AUSKLAPPEN]
Type TQuest
   Field ID:Short
   Field Name:String
   Field StartBedingung:String
   Field StartBedingungParam:String
   Field StartList:TList = New TList
   Field QuestList:TList = New TList
End Type

Type TAufgabe
   Field Typ:Byte
   Field Art:String
   Field ParamX:Short
   Field ParamY:Short
End Type

Im TQuest-Type werden neben der ID und dem Namen der Quest auch noch die Startbedingung sowie deren Parameter, außerdem noch die Start- und Questliste. Die Startbedingung ist die Bedingung, die erfüllt sein muss, damit man die Quest überhaupt annehmen kann. Ich habe bis jetzt "keine" (wenn man die Quest immer annehmen kann) und "abgeschlossene Quest x" (wenn man bereits vorher eine Quest absolviert haben muss), aber wahrscheinlich fallen mir im Laufe der Entwicklung noch einige Bedingungen ein.
StartBedingungParam ist der Parameter für die Startbedingung. Bei den oberen beiden Beispielen von Bedingungen gibt es nur bei "abgeschlossene Quest" einen Parameter, nämlich "x" bzw. der Name der Quest, die man bereits erfüllt haben muss.
Der Field-Eintrag "Typ" im Type TAufgabe speichert lediglich, ob es sich bei dieser Type-Instanz um eine Aufgabe oder einen Effekt handelt (mehr dazu weiter unten).
"Art" bezeichnet die Sorte von Aufgabe bzw. Effekt, um die es sich in der jeweiligen Instanz handelt. Ich habe zum Beispiel bei Aufgabe unter anderem "rede mit NPC x Ereignis y" und bei Effekt "Tagebucheintrag x".
"ParamX" und "ParamY" sind die Parameter zur Art der Aufgabe bzw. des Effekts. Beispielsweise speichert ParamX im obigen Beispiel "rede mit NPC x Ereignis y" die ID des NPCs, ParamY speichert sich das Ereignis (ich nenne in Iliran die Situationen "Ereignisse", also zum Beispiel sagt ein NPC bei Ereignis 1 "Ich habe einen Auftrag für Euch. Es ist ...", wenn man das gelesen hat, wird das Ereignis 2 und er sagt so etwas wie "Habt Ihr den Auftrag schon erledigt? Nein? Dann solltet Ihr Euch mal beeilen!", hoffe das war verständlich erklärt...).

Bleibt noch die Frage offen, was Aufgaben sind und was Effekte. Eine Aufgabe ist eigentlich auch fast wieder so etwas wie eine Bedingung. Alles was man in der Quest machen muss, sind Aufgaben, sie sind sozusagen aktiv.
Ein Effekt geschieht passiv, nämlich wenn man eine Aufgabe erfüllt hat. Er verändert etwas am Geschehen. Zum Beispiel: Ein NPC trägt dir auf, einem Freund von ihm einen Brief zu überbringen. Nachdem du mit seinem Freund geredet hast, ist die Aufgabe (die Quest aber noch nicht) erfüllt, und einige Effekte treten ein, beispielsweise bekommst du einen Tagebucheintrag und das Ereignis des Auftraggebers (und des Briefempfängers) springt um, sonst würden sie ja wieder dasselbe sagen wie vorher.
Hierfür habe ich zwei Screenshots vom Editor gemacht, jedoch habe ich die Map weggeschnitten, da sie sowieso auf beiden Bildern gleich ist:

user posted image
Hier sieht man die bisherigen Effekte des Editors.

user posted image
Hier habe ich eine fertige Quest (vielleicht behalte ich sie auch in baue sie in die Version ein, mit der ich das Video machen werde ^^), damit ihr sehen könnt, wie diese in etwa im fertigen Spiel aufgebaut sein werden.


Ich hoffe, ihr habt das so in etwa verstanden, und ich hoffe, dass ich nichts vergessen habe. ^^ In den nächsten Tagen werde ich versuchen, dass Quest-System in mein Hauptprogramm einzubinden. Deswegen folgt dann demnächst der Eintrag "Das Quest-System, Teil 3" in dem ich (notfalls) noch einmal etwas erläutern könnte, sofern ich in diesem eintrag etwas vergaß.

MFG Lador

Das Quest-System, Teil 1

Sonntag, 29. März 2009 von Lador
Heute habe ich mich mal an (meiner Meinung nach) eine der schwierigsten Engines in einem Rollenspiel gemacht: Das Quest-System.

Ich finde es sehr schwierig, da es so variabel sein muss. Immerhin will ich ja keine simplen und auf Dauer gleichen "Töte 20 hiervon, und am besten nochmal 30 davon" oder "Sammle 5 hiervon, 3 davon und 17 davon" machen, sondern innovative, motivierende und abwechslungsreiche Quests. Und dafür muss meine Engine eben sehr flexibel sein.

Auch wenn man das alles gar nicht extern, sondern auch intern lösen könnte (Hardcoding), finde ich diesen Weg sehr viel besser, wenn es auch mehr Überlegungszeit benötigt. Aber ich bin mir sicher, dass es mir im Nachhinein viel, viel Zeit gespart hat, dass ich kein Hardcoding gemacht habe.

Jedenfalls, ich hab mir schon länger mal Gedanken zum Quest-System gemacht. Damals dachte ich mir das so:

Code: [AUSKLAPPEN]

Start
Bedingung: keine; abgeschlossene Quest x
Aufgabe: rede mit NPC x

Quest (1-10)
Aufgabe: töte Gegner/Gruppe x; rede mit NPC x; benötigtes Item x Anzahl y besitzen


Naja, ist eigentlich auch fast so geblieben. Das sollte so funktionieren:
Um eine Quest annehmen zu können, gibt es entweder keine Bedingung, oder man muss schon eine andere Quest beendet haben (z.B. in einer Fraktion). Dann muss man eben mit einem NPC reden, um sie zu bekommen.
Da die Quest ja nicht immer strikt gehalten ist (also man redet mit NPC, dann macht man die Aufgabe und geht wieder zurück), dachte ich mir, man kann maximal 10 Aufgaben pro Quest machen. Also z.B. man geht erst zum NPC, der sagt, man soll die Monster aus einer Höhle vertreiben, dort findet man aber ein Amulett von jemand anderem, dann bringt man es demjenigen zurück und dann soll man wieder zum Auftraggeber.

Als ich dann aber anfing, den Quest-Editor (mitsamt System) zu coden, fiel mir auf, dass es so nicht ganz funktionieren kann. Zum einen wusste ich nicht, wie viele Aufgaben dem Spieler "dazwischen kommen" (Quest 1-10). Das hab ich jetzt halt statt mit einem Array mit einer List gelöst.
Zum anderen aber muss ja immer etwas dazwischen passieren, z.B. dass der NPC etwas anderes sagt. Deshalb dachte ich mir, dass ich "Effekte" einbaue (dabei kam mir wieder der Szenarien-Editor von Empire Earth in Erinnerung), die sowas übernehmen. Dann war das Problem nur, wie ich die variable Reihenfolge von Aufgaben und Effekten unterbringe. Dafür habe ich mich dann wieder für das Verwenden von Listen entschieden.

Ich hatte also bisher drei Types, von denen zwei dieselben Felder hatten und deshalb zu einem zusammengefasst wurden. Man kann sie durch ein extra Feld "Typ" unterscheiden.

Code: [AUSKLAPPEN]

Type TQuest
   Field Name:String
   Field StartBedingung:String
   Field StartBedingungParam:String
   Field StartList:TList = New TList
   Field QuestList:TList = New TList
End Type

Type TAufgabe
   Field Typ:Byte
   Field Art:String
   Field ParamX:Short
   Field ParamY:Short
End Type


ParamX und ParamY sind die Parameter für die jeweilige Art der Aufgabe bzw. des Effekts, also z.B. die ID des NPC.
StartList speichert die Aufgaben und Effekte, die vor der eigentlichen Quest kommen. QuestList speichert dann logischerweise die Aufgaben und Effekte, die während der eigentlichen Quest auftreten. Ein Beispiel, das das erläutern wird, werde ich demnächst einmal posten.
Das Gute an diesem System ist, dass sich ohne Probleme die "Arten" der Aufgaben und Effekte erweitern lässt. Deshalb sollte es möglich sein, dass alle Quest-Ideen umgesetzt werden können.


Bis jetzt habe ich lediglich das System, zurzeit bin ich über dem Quest-Editor. Ob es gut in das Hauptprogramm eingebaut werden kann, wird sich erst später herausstellen. Ich habe aber ein gutes Gefühl. ^^

Der Häuser-Editor

Montag, 23. März 2009 von Lador
Hallo Community.

Beim letzten Eintrag habe ich nur allgemein etwas über Iliran erzählt, aber jetzt werde ich auch mal etwas genauer auf die Programmierung eingehen.


In der letzten Woche habe ich mich hauptsächlich um einen Part des Spiels gekümmert, der eigentlich sogar ziemlich wichtig ist: das Wechseln von Innen- zu Außenwelt, also das Betreten von Häusern (und Dungeons). Immerhin ist es ziemlich langweilig, die ganze Zeit in der Landschaft rumzulaufen, ohne auch mal ein die Inneneinrichtung der Bewohner Ilirans zu sehen.

Die meiste Zeit der letzten Tage hat mein "Häuser-Editor" in Anspruch genommen. Eigentlich hätte ich die Angaben für den Map-Wechsel auch einfach manuell in eine Datei schreiben können, aber ich finde den Editor trotzdem ziemlich nützlich, vor allem was die Arbeit an einem Add-On angeht, oder aber, (wenn ich die Editoren veröffentliche) das Modden. Ich wollte für alles extra Editoren machen, also auch für NPCs, Gegner etc., nicht nur aus dem Grund, dass es viel bequemer ist, sondern auch wegen der Erfahrung.

Hier erstmal ein Screenshot von meinem Häuser-Editor (da er zur Entwicklung gehört, und nicht direkt zum Spiel, wird er nicht auf der Website veröffentlicht):
user posted image
(die Maus wurde von Windows entfernt ^^)

Man erkennt hierauf eigentlich sehr schön das Prinzip. Es gibt einen Type TVerbindung. Dieser sieht wie folgt aus:

Code: [AUSKLAPPEN]
Type TVerbindung
   Field Nr:Short
   Field StartMap:String
   Field X:Short
   Field Y:Short
   Field ZielMap:String
   Field ZielX:Short
   Field ZielY:Short
End Type


Jeder Verbindung (zwischen der Außenwelt und einem Haus/Dungeon) wird eine individuelle Nummer zugewiesen. Damit wird sie später ansprechbar sein.
StartMap ist der Name der .map-Datei, auf der sich der Spieler befinden muss, um die Verbindung benutzen zu können.
X/Y bzw. StartX/Y speichert die Position (in Tiles), die der Spieler haben muss, damit er die Verbindung benutzen kann.
ZielMap ist der Name der .map-Datei, die geladen wird, wenn der Spieler die Verbindung aktiviert. Und er befindet sich dann auf der Position ZielX, ZielY der ZielMap.

Das Prinzip ist erkennbar einfach. Mit dem Häuser-Editor kann man eine neue Verbindung erstellen, eine vorhandene ansehen, löschen oder editieren. Das System ist auch schon ins Hauptprogramm eingebaut, aber ich werde des demnächst noch etwas verbessern/erweitern.

Im Hauptprogramm musste ich aber für die Map-individuellen Types, also die Types, bei denen es Objekte in der einen, aber auch in der anderen Map gibt (das betrifft fast alle ^^), noch ein eigenes Feld eintragen. Das heißt "MapName" und speichert den Namen der .map-Datei (wie StartMap und ZielMap im Verbindung-Type), und muss mit der Variable "MapName" aus dem Hauptprogramm übereinstimmen, damit sich für diese Instanz überhaupt etwas tut.


Das wars soweit von mir.

Was demnächst noch ansteht:
-den Code etwas übersichtlicher machen
-Quest-Editor (ich mache den jetzt vor dem Beschwören von Gegnern, damit ich endlich mal ein Video hochladen kann ^^)

MFG Lador

Allgemein: Was ist Iliran?

Sonntag, 15. März 2009 von Lador
Hallo Community.

Da ich schon seit fast 3 Jahren an meinem 2D-Rollenspiel Iliran arbeite, und weil in letzter Zeit immer mehr Worklogs über Rollenspiele geschrieben werden hab ich mich jetzt dazu entschlossen, auch endlich einmal einen Worklog zu schreiben und mich den anderen "anzuschließen"... ^^

Iliran ist ein 2D-Fantasy-Rollenspiel. Mein Ziel war (und ist) es, ein Spiel mit motivierenden Quests, einem einfach zu verstehenden aber doch fähigem Charaktersystem, einer abwechslungsreichen Landschaft und einfach größerer Freiheit zu erschaffen. Ich muss dabei aber zugeben, ich habe mich sehr an der ElderScrolls-Reihe orientiert (was der ein oder andere sicherlich auch noch bemerken wird) ... ^^

Auch wenn ich schon seit fast 3 Jahren an Iliran arbeite (anfangs aber nur theoretisch, da habe ich nur Sachen aufgeschrieben und überlegt), bin ich immer nur schrittweise vorangekommen. Eigentlich war ich gerade dabei, ein anderes Rollenspiel zu machen, und die Ideen für Iliran sollten für ein späteres Spiel gebraucht werden. Doch das damalige Projekt scheiterte durch mangelnde Motivation meinerseits (was meiner Meinung an der miserabel gestalteten Map und der schlechten Technik lag).
Danach verlor ich für einige Monate die Lust am Programmieren und wollte ein kleines Test-MMORPG schreiben. Ich hatte die Grundengines (Laufen, Kämpfen, mit NPCs reden, naja mehr eigentlich auch nicht) ziemlich fertig. Dann aber kam es nie zu dem besagten MMORPG, aber ich wollte die Engines für Iliran benutzen. Deshalb arbeite ich eigentlich erst seit Sommer 2007 richtig an Iliran.
Nach und nach verbesserte ich die Engines immer mehr und kann jetzt eigentlich sagen, dass ich sehr zufrieden bin. ^^ (Mehr zu der Entstehungsgeschichte werde ich wahrscheinlich irgendwann einmal auf der offiziellen Website veröffentlichen - Extra Large ^^, link unten)

Vor ziemlich genau einem Jahr fragte ich dann Terabite (der in diesem Forum als PlanetLone eher bekannt sein dürfte), ob er für mich die Mapgestaltung übernehmen wolle (weil er mir das lange Zeit vorher einmal angeboten hatte), und nur wegen ihm konnte ich den Zielpunkt "abwechslungsreiche Landschaft" abhaken. ^^

Jetzt noch einen Screenshot (vielleicht kennt ihn jemand aus der Galerie), der ist zwar schon über neun Monate alt, aber grafisch hat sich bis jetzt kaum etwas getan (außer das nun auch NPCs in der Landschaft rumlaufen, mit denen man reden kann ^^):

(https://www.blitzforum.de/gallery/1080/)
user posted image
(Ich frage evtl. noch einmal Terabite, ob er nicht die Figuren entpixeln könnte.)

Ich hoffe, ich werde demnächst noch ein paar Sachen fertigstellen können (Häuser betreten, Quest-Editor + -System, Bugs ausmerzen), damit ich auch einmal ein Video hochladen kann.

Zudem hoffe ich, dass euch mein erster Worklog-Eintrag gefallen hat, und dass ich euer Interesse etwas wecken konnte.

Siehe auch:
www.iliran.de.vu <- offizielle Website
www.iliran-forum.de.vu <- Forum, bei Fragen oder Anregungen

MFG Lador

Gehe zu Seite Zurück  1, 2