Tehadon
nochmal HDSS
Sonntag, 24. August 2008 von peacemaker
So, ein weiterer kleiner Eintrag.
Ich erzähle wieder primär von HDSS. Ich habe eine kleine interne Demo released, dabei sind mir einige Bugs aufgefallen. Die sind teilweise sogar schon gefixt.
Ansonsten wollte ich mal endlich ein bisschen interaktion in HDSS einbringen, und hab so ein paar Input-Befehle zum Abfragen von Tasten und Maus eingebaut. Ist ja nichts besonderes und war eine Arbeit von 5 Minuten. Was ich damit angestellt habe war hingegen schon von anderem Kaliber.
Zuerst jedoch: Ich habe nun eine provisorische Do-Schleife reingebaut. Leider scheiterte ich bisher immer an einer While-Schleife, zwar habe ich eine Idee, aber das ginge nur mit einer Typeliste, was ich irgendwie vermeiden will.
Die Do-Schleife führt sich einfach unendlich oft aus. Dabei kann man auch verschachteln.
Code: [AUSKLAPPEN]
do ()
{
do ()
{
do ()
{
}
}
}
Da fällt mir übrigens auch ein, das verschachtelte If-Abfragen funktionieren. Man kann beliebig viele machen, sie funktionieren trotzdem, und das angenehm schnell.
So, wieder zurück. Ich habe mir gedacht, ein kleines Bild in einer Schleife anzuzeigen und es dabei bewegbar zu machen, also die Position mithilfe von Tastatur und Maus zu verändern.
Das Skript schaut so aus:
Code: [AUSKLAPPEN]
void main ()
{
Cls ();
var $alien;
$alien = New (Image);
$alien->create ("player.BMP");
var $x;
var $y;
var $kh_left;
var $kh_right;
var $kh_up;
var $kh_down;
var $md;
var $bQuit;
$x = 15;
$y = 16;
do ()
{
Cls ();
$kh_left =Keydown (205);
$kh_right=Keydown (203);
$kh_up =Keydown (200);
$kh_down =Keydown (208);
$md = Mousedown (1);
$bQuit=KeyHit (1);
if ($md==1)
{
$x=mouseX ();
$y=mouseY ();
};
if ($kh_left==1)
{
$x=$x+1;
};
if ($kh_right==1)
{
$x=$x-1;
};
if ($kh_up==1)
{
$y=$y-1;
};
if ($kh_down==1)
{
$y=$y+1;
};
Text (20,20, GetFPS ());
//delay (20);
$alien->x = $x;
$alien->y = $y;
$alien->draw ();
Flip ();
};
print (1==1);
}
Nun, was mich besonders erstaunte waren die FPS-Zahlen, die da ja ausgegeben werden. Ich hatte teilweise bis zu 500, was eigentlich schon ziemlich viel für ein Skript ist.
HDSS ist echt ziemlich schnell, wenn man das so sagen kann.
Ausserdem scheints so, als wäre ziemlich bald mit einer dicken Alpha zu rechnen. Mal schauen.
Ich habe begonnen nun auch noch die Schnittstelle zwischen HDSS-Skripten und BB-Code zu basteln.
Dazu habe ich mir eine kleine Mindmap gezeichnet, und möchte euch diese nicht vorenthalten. Ist aber nicht für jeden interessant.
Noch etwas kleines nebenbei: Ich habe mal zählen lassen, wieviele Zeilen Tehadon jetzt hat. Es sind insgesamt 41'789 Zeilen. Sind ja schon einige.
mfG
Ich erzähle wieder primär von HDSS. Ich habe eine kleine interne Demo released, dabei sind mir einige Bugs aufgefallen. Die sind teilweise sogar schon gefixt.
Ansonsten wollte ich mal endlich ein bisschen interaktion in HDSS einbringen, und hab so ein paar Input-Befehle zum Abfragen von Tasten und Maus eingebaut. Ist ja nichts besonderes und war eine Arbeit von 5 Minuten. Was ich damit angestellt habe war hingegen schon von anderem Kaliber.
Zuerst jedoch: Ich habe nun eine provisorische Do-Schleife reingebaut. Leider scheiterte ich bisher immer an einer While-Schleife, zwar habe ich eine Idee, aber das ginge nur mit einer Typeliste, was ich irgendwie vermeiden will.
Die Do-Schleife führt sich einfach unendlich oft aus. Dabei kann man auch verschachteln.
Code: [AUSKLAPPEN]
do ()
{
do ()
{
do ()
{
}
}
}
Da fällt mir übrigens auch ein, das verschachtelte If-Abfragen funktionieren. Man kann beliebig viele machen, sie funktionieren trotzdem, und das angenehm schnell.
So, wieder zurück. Ich habe mir gedacht, ein kleines Bild in einer Schleife anzuzeigen und es dabei bewegbar zu machen, also die Position mithilfe von Tastatur und Maus zu verändern.
Das Skript schaut so aus:
Code: [AUSKLAPPEN]
void main ()
{
Cls ();
var $alien;
$alien = New (Image);
$alien->create ("player.BMP");
var $x;
var $y;
var $kh_left;
var $kh_right;
var $kh_up;
var $kh_down;
var $md;
var $bQuit;
$x = 15;
$y = 16;
do ()
{
Cls ();
$kh_left =Keydown (205);
$kh_right=Keydown (203);
$kh_up =Keydown (200);
$kh_down =Keydown (208);
$md = Mousedown (1);
$bQuit=KeyHit (1);
if ($md==1)
{
$x=mouseX ();
$y=mouseY ();
};
if ($kh_left==1)
{
$x=$x+1;
};
if ($kh_right==1)
{
$x=$x-1;
};
if ($kh_up==1)
{
$y=$y-1;
};
if ($kh_down==1)
{
$y=$y+1;
};
Text (20,20, GetFPS ());
//delay (20);
$alien->x = $x;
$alien->y = $y;
$alien->draw ();
Flip ();
};
print (1==1);
}
Nun, was mich besonders erstaunte waren die FPS-Zahlen, die da ja ausgegeben werden. Ich hatte teilweise bis zu 500, was eigentlich schon ziemlich viel für ein Skript ist.
HDSS ist echt ziemlich schnell, wenn man das so sagen kann.
Ausserdem scheints so, als wäre ziemlich bald mit einer dicken Alpha zu rechnen. Mal schauen.
Ich habe begonnen nun auch noch die Schnittstelle zwischen HDSS-Skripten und BB-Code zu basteln.
Dazu habe ich mir eine kleine Mindmap gezeichnet, und möchte euch diese nicht vorenthalten. Ist aber nicht für jeden interessant.
Noch etwas kleines nebenbei: Ich habe mal zählen lassen, wieviele Zeilen Tehadon jetzt hat. Es sind insgesamt 41'789 Zeilen. Sind ja schon einige.
mfG
Brücke und HDSS
Sonntag, 17. August 2008 von peacemaker
Ich habe mal die Brücke von Grosserboss ingame ausprobiert.
Anstatt lange herumzulabern lieber hier die Bilder.
Die andern Bilder findet ihr hier .
Ausserdem habe ich die Seite um einen kleinen Newseintrag erweitert. Zur Seite. Diese drei Bilder sind übrigens von mir, desshalb
nicht allzu sehr wundern. Ich finde sie ganz gut für meine Verhältnisse, wesshalb ich sie veröffentlicht habe.
Was ich auch noch gemacht habe, ist das Eventsystem von HDSS komplettiert. Es funktioniert jetzt ohne Probleme.
Man kann jetzt mit dem Befehl HDSS_VoidExecute eine HDSS-Prozedur ausführen. Jetzt hat HDSS eigtl. alles was es braucht, um es einzubauen, aber das werd ich erst machen, wenns mehr oder weniger Bugfrei ist.
mfG
Anstatt lange herumzulabern lieber hier die Bilder.
Die andern Bilder findet ihr hier .
Ausserdem habe ich die Seite um einen kleinen Newseintrag erweitert. Zur Seite. Diese drei Bilder sind übrigens von mir, desshalb
nicht allzu sehr wundern. Ich finde sie ganz gut für meine Verhältnisse, wesshalb ich sie veröffentlicht habe.
Was ich auch noch gemacht habe, ist das Eventsystem von HDSS komplettiert. Es funktioniert jetzt ohne Probleme.
Man kann jetzt mit dem Befehl HDSS_VoidExecute eine HDSS-Prozedur ausführen. Jetzt hat HDSS eigtl. alles was es braucht, um es einzubauen, aber das werd ich erst machen, wenns mehr oder weniger Bugfrei ist.
mfG
diverses zu HDSS
Samstag, 16. August 2008 von peacemaker
So, auch hier mal wieder was.
Ich bin heute nach Hause gekommen, und habe sogleich angefangen den Source an die hiesigen Verhältnisse anzupassen. Hier habe ich nämlich wieder IDEal zur Verfügung, dort musste ich mich mit der Standart-IDE zufriedengeben.
Und musste gleich staunen, wie schnell hier HDSS läuft.
Fast 4 mal so schnell wie auf dem schlechten Notebook, nämlich.
Was jetzt auch geht, ist die Vorberechnung bei konstanten numerischen Werten.
Zitat:
Also:
Zitat:
Zum Schluss noch einige Pläne für die Zukunft. Ihr könnt schon ziemlich bald mit einer HDSS-Alpha rechnen. Das ganze wird einige Hilfsklassen für 2D- und 3D-Grafik enthalten. Es ist etwas Geduld angesagt, aber es ist ziemlich bald damit zu rechnen.
mfG
Ich bin heute nach Hause gekommen, und habe sogleich angefangen den Source an die hiesigen Verhältnisse anzupassen. Hier habe ich nämlich wieder IDEal zur Verfügung, dort musste ich mich mit der Standart-IDE zufriedengeben.
Und musste gleich staunen, wie schnell hier HDSS läuft.
Fast 4 mal so schnell wie auf dem schlechten Notebook, nämlich.
Was jetzt auch geht, ist die Vorberechnung bei konstanten numerischen Werten.
Zitat:
print (120+40);
wird in Zwischencode schon vorberechnet, weil die Werte konstant sind.
Also:
Zitat:
PRINT
160
Das funktioniert auch schon mit der Subtraktion.
160
Zum Schluss noch einige Pläne für die Zukunft. Ihr könnt schon ziemlich bald mit einer HDSS-Alpha rechnen. Das ganze wird einige Hilfsklassen für 2D- und 3D-Grafik enthalten. Es ist etwas Geduld angesagt, aber es ist ziemlich bald damit zu rechnen.
mfG
Es ist Zeit ...
Montag, 11. August 2008 von peacemaker
... mal wieder hier was zu schreiben.
Ja, ich weiss, die Worklog-Aktivitaet laesst echt zu wuenschen uebrig, aber ich bin leider nicht zuhause und habe hier nur Zugriff auf schlechte PCs und I-net.
Von der Entwicklung kann ich leider eher wenig neues erzaehlen. Dafuer dachte ich mir, das ein neues Making-Of faellig waere. Also, gesagt getan, ihr koennt es hier finden. Es handelt um das Kampfsystem.
Ich hab mir Muehe gegeben und wuerde mich sehr ueber Feedback freuen.
Ausserdem hat Grosserboss unser 3D-Mann seine Bruecke vollendet.
Das Modell hat 2235 Faces-> also recht viel aber für diese Groesse sollte das kein Problem sein.
mfG pm
Ja, ich weiss, die Worklog-Aktivitaet laesst echt zu wuenschen uebrig, aber ich bin leider nicht zuhause und habe hier nur Zugriff auf schlechte PCs und I-net.
Von der Entwicklung kann ich leider eher wenig neues erzaehlen. Dafuer dachte ich mir, das ein neues Making-Of faellig waere. Also, gesagt getan, ihr koennt es hier finden. Es handelt um das Kampfsystem.
Ich hab mir Muehe gegeben und wuerde mich sehr ueber Feedback freuen.
Ausserdem hat Grosserboss unser 3D-Mann seine Bruecke vollendet.
Das Modell hat 2235 Faces-> also recht viel aber für diese Groesse sollte das kein Problem sein.
mfG pm
Bruecke
Sonntag, 27. Juli 2008 von peacemaker
Kleiner Nachtrag: Grosserboss, einer unserer 3D-Leuten, hat angefangen eine Bruecke zu modellieren.
Natuerlich ist sie noch nicht fertig was Texturierung betrifft, es wird spaeter auch Abwechslung usw. geben.
Nach meinen Informationen hat die ganze Bruecke ca 2 k Polys, sie ist aber auch ziemlich gross.
Schreibt eure Kommentare dazu bitte hier hin.
mfG
Natuerlich ist sie noch nicht fertig was Texturierung betrifft, es wird spaeter auch Abwechslung usw. geben.
Nach meinen Informationen hat die ganze Bruecke ca 2 k Polys, sie ist aber auch ziemlich gross.
Schreibt eure Kommentare dazu bitte hier hin.
mfG
Forum offline und einige Infos
Sonntag, 27. Juli 2008 von peacemaker
Ave,
Es ist schon ziemlich sehr lange her, das dieser Worklog einen neuen Eintrag gesehn hat. Also verfasse ich flugs mal wieder einen.
Tehadon wird natuerlich weiterentwickelt, nur kommt Tehadon durch diverse RL-Dinge etwas kurz. Aber auch das wird bald schon weg sein.
Das Forum ist ausserdem offline, da der gesamte Forenberg auf einen neuen Server umzieht. Das bedeutet z.B. mehr Speed, mehr Space, und noch einige Dinge mehr.
Kommen wir wieder zurueck zur Entwicklung. Ich habe mir in den letzten paar Tagen vor allem ueber die Doerfer und Staedte Gedanken gemacht.
Ich habe diverse Konzeptskizzen erstellt und mir auch einiges von den Doerfern hier abgeschaut.
Desweiteren habe ich vor allem im Bereich Story weitergewerkelt und mir ein paar kleine Locations ausgedacht.
Sobald ich wieder zuhause bin (was in einer Woche ist), sollte HDSS fertig entwickelt werden. Zuvor wird jedoch eine Alpha rausgegeben. Diese soll diverse Module beinhalten. So z.B. Teile der B3D-Engine, mit dem OOP-System gewrappt, oder auch die 2D-Befehle. Natuerlich nicht alles, aber doch genug um evtl. kleinere Spielchen zu machen.
Wozu das ganze? HDSS ist ein System, das fast zuunterst steht. Fast alles basiert spaeter darauf, NPCs, IAOs, Dialoge, Events, usw. Wenn das nicht vernuenftig laeuft, dann kann man das andere auch vergessen. Desshalb habe ich mir gedacht, HDSS erst einzubauen, wenn es final ist, also praktisch buglos und genug schnell ist. Zweiteres ist es schon, ersteres jedoch nicht.
Und dann werden alle Systeme auf neue HDSS-Version angepasst, dann kommen die IAOs (Interactive Objects) rein, und werden mit dem Item-System verknuepft. Danach werde ich weiter an der DGF-AI arbeiten, die ist in letzter Zeit arg kurz gekommen.
Willi die Ruebe, wollte noch die Kamerasteuerung samt Physik uebernehmen, sodass auch in diesem Bereich vorgesorgt ist. Ausserdem hat er inzwischen das GUI-System so weit fertig, das der komplette Einbau des Interfaces moeglich waere. Was aber noch fehlt waeren, neben den Grafiken, auch ein Tab-System, wobei sowas schnell gemacht ist.
mfG
Es ist schon ziemlich sehr lange her, das dieser Worklog einen neuen Eintrag gesehn hat. Also verfasse ich flugs mal wieder einen.
Tehadon wird natuerlich weiterentwickelt, nur kommt Tehadon durch diverse RL-Dinge etwas kurz. Aber auch das wird bald schon weg sein.
Das Forum ist ausserdem offline, da der gesamte Forenberg auf einen neuen Server umzieht. Das bedeutet z.B. mehr Speed, mehr Space, und noch einige Dinge mehr.
Kommen wir wieder zurueck zur Entwicklung. Ich habe mir in den letzten paar Tagen vor allem ueber die Doerfer und Staedte Gedanken gemacht.
Ich habe diverse Konzeptskizzen erstellt und mir auch einiges von den Doerfern hier abgeschaut.
Desweiteren habe ich vor allem im Bereich Story weitergewerkelt und mir ein paar kleine Locations ausgedacht.
Sobald ich wieder zuhause bin (was in einer Woche ist), sollte HDSS fertig entwickelt werden. Zuvor wird jedoch eine Alpha rausgegeben. Diese soll diverse Module beinhalten. So z.B. Teile der B3D-Engine, mit dem OOP-System gewrappt, oder auch die 2D-Befehle. Natuerlich nicht alles, aber doch genug um evtl. kleinere Spielchen zu machen.
Wozu das ganze? HDSS ist ein System, das fast zuunterst steht. Fast alles basiert spaeter darauf, NPCs, IAOs, Dialoge, Events, usw. Wenn das nicht vernuenftig laeuft, dann kann man das andere auch vergessen. Desshalb habe ich mir gedacht, HDSS erst einzubauen, wenn es final ist, also praktisch buglos und genug schnell ist. Zweiteres ist es schon, ersteres jedoch nicht.
Und dann werden alle Systeme auf neue HDSS-Version angepasst, dann kommen die IAOs (Interactive Objects) rein, und werden mit dem Item-System verknuepft. Danach werde ich weiter an der DGF-AI arbeiten, die ist in letzter Zeit arg kurz gekommen.
Willi die Ruebe, wollte noch die Kamerasteuerung samt Physik uebernehmen, sodass auch in diesem Bereich vorgesorgt ist. Ausserdem hat er inzwischen das GUI-System so weit fertig, das der komplette Einbau des Interfaces moeglich waere. Was aber noch fehlt waeren, neben den Grafiken, auch ein Tab-System, wobei sowas schnell gemacht ist.
mfG
HDSS gedeiht ...
Dienstag, 15. Juli 2008 von peacemaker
So, weiter gehts hier.
Da ich momentan in den Ferien bin, und nur einen Laptop mit 900 MHz und 64 MB Ram zur Verfuegung habe, kann ich nicht am eigentlichen Spiel oder aehnlichem werkeln. Desshalb habe ich mich auf HDSS konzentriert, und es traegt schon die ersten Fruechte.
Methoden sind nun schonmal drin. Methoden sind eigentlich nichts anderes als Prozeduren, nur das sie immer noch die Instanz, des verknupeften Ojektes als Parameter mitkriegt. Fuer die die sich auskennen, das ist diese $this-Instanz. Nun, das funktioniert jetzt. HDSS ist jetzt eigentlich sogar Betriebsbereit, da fast alle Elemente drin sind. Was noch fehlt sind Schleifen und Funktionen. Prozeduren gibt es ja schon, jetzt muessen sie noch etwas zurueckliefern, was ja kaum ein Problem ist. Um HDSS ein bisschen besser zu testen habe ich diverse Hilfsklasse integriert. Z.B. eine Namens File. In der Anwendung schaut das so aus:
Code: [AUSKLAPPEN]
Oder eine namens Image. Die ist fuer, welch wunder, Bilder gemacht.
Code: [AUSKLAPPEN]
Nun, man kann sagen das HDSS jetzt ein bisschen OOP ist. Sachen wie Vererbung Polymorphie und co. gibts aber noch nicht. Bzw. wirds wohl auch nicht geben, denn fuer Tehadon wird das nicht gebraucht. Das ganze OOP-Zeug ist sehr sehr schnell. Egal wieviele Klassen, egal wieviele Members oder Methoden, das ganze bleibt konstant gleich schnell, da fuer alles nur ein einziges Array-Feld genutzt wird.
Kommen wir zum Speed. Ich habe die Ausfuehr-Funktion jetzt optimiert. Das ganze ist jetyt ca. 30% schneller. Fuer ein natives Skript in normaler Skriptlaenge (d.H. die Durchschnittslaenge pro Event, spaeter im Spiel), wie z.B. das folgende, braucht 0 ms zum ausfuehren. Also es sind knapp 1, 0.6 ms.
Code: [AUSKLAPPEN]
void main ()
{
var $test1;
var $container;
var $test2;
$test1 = $test1+15;
$test2 = $test2+$test1;
$container = new (Mensch):
$container->name = "Mensch";
$container->setSize (180);
$container = len ($container->name) + abs (-17);
$container = $test1 * 15:
}
Ich denke nicht, das die Skripte viel laenger werden, da ja alles Event-Basiert ist.
Das ganze OOP-Zeugs ermoegtlicht jetzt echt coole Sachen.
Um mal das mit den Events zu zeigen: das hier wird am Anfang der momentan gespielten Mod (dazu zaehlt auch Tehadon) ausgefuehrt.
Dabei werden einige NPCs erstellt und greifen den Spieler an.
Code: [AUSKLAPPEN]
Mir faellt gerade noch ein, das jetzt auch mehrfach-Deklarationen von Variabeln moeglich sind:
Code: [AUSKLAPPEN]
mfG
Da ich momentan in den Ferien bin, und nur einen Laptop mit 900 MHz und 64 MB Ram zur Verfuegung habe, kann ich nicht am eigentlichen Spiel oder aehnlichem werkeln. Desshalb habe ich mich auf HDSS konzentriert, und es traegt schon die ersten Fruechte.
Methoden sind nun schonmal drin. Methoden sind eigentlich nichts anderes als Prozeduren, nur das sie immer noch die Instanz, des verknupeften Ojektes als Parameter mitkriegt. Fuer die die sich auskennen, das ist diese $this-Instanz. Nun, das funktioniert jetzt. HDSS ist jetzt eigentlich sogar Betriebsbereit, da fast alle Elemente drin sind. Was noch fehlt sind Schleifen und Funktionen. Prozeduren gibt es ja schon, jetzt muessen sie noch etwas zurueckliefern, was ja kaum ein Problem ist. Um HDSS ein bisschen besser zu testen habe ich diverse Hilfsklasse integriert. Z.B. eine Namens File. In der Anwendung schaut das so aus:
Code: [AUSKLAPPEN]
//Files
var $file:
$file = new (File):
$file->load ("test.txt"):
print ($file->getLine ()): // Zeile auslesen und anzeigen
var $file:
$file = new (File):
$file->load ("test.txt"):
print ($file->getLine ()): // Zeile auslesen und anzeigen
Oder eine namens Image. Die ist fuer, welch wunder, Bilder gemacht.
Code: [AUSKLAPPEN]
var $image;
$image->load ("player.BMP");
$image->setPosition (120, 150);
$image->draw ():
$image->load ("player.BMP");
$image->setPosition (120, 150);
$image->draw ():
Nun, man kann sagen das HDSS jetzt ein bisschen OOP ist. Sachen wie Vererbung Polymorphie und co. gibts aber noch nicht. Bzw. wirds wohl auch nicht geben, denn fuer Tehadon wird das nicht gebraucht. Das ganze OOP-Zeug ist sehr sehr schnell. Egal wieviele Klassen, egal wieviele Members oder Methoden, das ganze bleibt konstant gleich schnell, da fuer alles nur ein einziges Array-Feld genutzt wird.
Kommen wir zum Speed. Ich habe die Ausfuehr-Funktion jetzt optimiert. Das ganze ist jetyt ca. 30% schneller. Fuer ein natives Skript in normaler Skriptlaenge (d.H. die Durchschnittslaenge pro Event, spaeter im Spiel), wie z.B. das folgende, braucht 0 ms zum ausfuehren. Also es sind knapp 1, 0.6 ms.
Code: [AUSKLAPPEN]
void main ()
{
var $test1;
var $container;
var $test2;
$test1 = $test1+15;
$test2 = $test2+$test1;
$container = new (Mensch):
$container->name = "Mensch";
$container->setSize (180);
$container = len ($container->name) + abs (-17);
$container = $test1 * 15:
}
Ich denke nicht, das die Skripte viel laenger werden, da ja alles Event-Basiert ist.
Das ganze OOP-Zeugs ermoegtlicht jetzt echt coole Sachen.
Um mal das mit den Events zu zeigen: das hier wird am Anfang der momentan gespielten Mod (dazu zaehlt auch Tehadon) ausgefuehrt.
Dabei werden einige NPCs erstellt und greifen den Spieler an.
Code: [AUSKLAPPEN]
void Tehadon::onStart 90
{
var $npc1;
$npc1->name = "Boeser Junge';
$npc1->mesh = loadMesh ("testnpc.B3D");
// hier noch andere Eigenschaften setzen...
$Tehadon->message ("Du wirst gleich in 10 Sekunden angegriffen"):
// Timer erstellen:
var $timer = new (Timer);
$timer->value = 10000; // 10000 ms
}
void $timer :: onActive ()
{
// spieler angreifen wenn Zeit vorbei ist
$npc1->attack ($player):
}
{
var $npc1;
$npc1->name = "Boeser Junge';
$npc1->mesh = loadMesh ("testnpc.B3D");
// hier noch andere Eigenschaften setzen...
$Tehadon->message ("Du wirst gleich in 10 Sekunden angegriffen"):
// Timer erstellen:
var $timer = new (Timer);
$timer->value = 10000; // 10000 ms
}
void $timer :: onActive ()
{
// spieler angreifen wenn Zeit vorbei ist
$npc1->attack ($player):
}
Mir faellt gerade noch ein, das jetzt auch mehrfach-Deklarationen von Variabeln moeglich sind:
Code: [AUSKLAPPEN]
var $test1, $test2, $test4, // .... usw.
mfG
Marhem
Sonntag, 29. Juni 2008 von peacemaker
Heute gibt es wieder mehr eine kleine Erklärung. Das ganze habe ich direkt aus unserem internen Storyboard kopiert, wenn Fragen offen sind => wie immer hier stellen.
Ich erzähl hier mal über eine Stadt, die zwar nicht allzu wichtig für Hauptstory ist, aber trotzdem ganz interessant ist.
Marhem liegt im Südosten Issanûrs. Hierhin kommen nur die, die vom König flüchten, oder das Gesindel eben. Kein Wunder, Marhem ist eine Stadt, die praktisch nur von Piraterie lebt. Um nach Marhem zu gelangen, müsste man zu Lande das undurchdringliche Asodan-Gebirge kommen. Schon desshalb kommen nur die härtesten bis nach Marhem.
Den Meerweg kann man vergessen, da dort die Piraten von Marhem hausen. Diese besitzen einige Schiffe, die sie der königlichen Flotte abgenommen haben, so z.B. einige Schiffe vom Typen "schwarze Irothen" , welches eines der stärksten Schiffe des Landes darstellt.
Marhem lebt, wie schon gesagt von der Piraterie. Die Handelsstadt "Mercathem", eine der einzigen Städte die Meerhandel im grossen macht, liegt in der Nähe von Marhem, was den Marhem-Bewohnern sehr günstig kommt. Mercathem versorgt auch viele Städte auf Issanûr, so z.B. auch Palan, und diverse mehr. So streifen die Schiffe von Marhem in dieser Meerenge herum und passen viele Schiffe ab. Dabei hat die Regierung schon öfters versucht, etwas dagegen zu unternehmen, meist jedoch ohne Erfolg. Vor allem Palan litt eine Zeit lang unter der Piraterie, mittlerweile hat sich Palan aber unabhängig von Mercathem neue Handelspartner gesucht, nicht destotrotz wird immer noch Handel mit Mercathem betrieben. Bevor die Intenare kamen, versuchte der König sehr oft, Marhem unter seine Kontrolle zu bringen oder gar auszuschalten, dies gelang jedoch nie. Der Landweg war schwierig zu durchqueren, ausserdem sehr ungünstig um viele Leute dort durchzubringen. Über den Meerweg war Marhem durch seine vielen geklauten Schiffe auch sehr schwierig zu erreichen.
Einmal gelang es der königlichen Flotte jedoch, Marhem fast einzunehmen. Dies war ein harter Schlag für Marhem. Die Schiffe siegten bei der Seeschlacht an der Küste von Marhem und am Schluss segelten 4 Schiffe der königlichen Flotte auf Marhem zu. An Land wurden sie jedoch wieder zurückgeschlagen.
Seit der Intenar-Feldzug begonnen hat, hat der König jedoch aufgehört, Marhem anzugreifen.
Bisher bekundeten die Intenare kein Interesse an Marhem, man vermutet aber, das auch Marhem bald von Intenaren erobert wird.
Die Gegend bei Marhem, sowie die Seewege in der Meerenge:
(In Paint gemacht, nicht auslachen
)
Ansonsten habe ich wieder weiter an HDSS gewerkelt.
Jetzt kann man immerhin schon Klassen erstellen und Eigenschaften zuweisen. Beispiel: ich will hier mal eine Klasse namens 'Mensch' erstellen.
Also im HDSS-Sourcecode das schreiben:
Code: [AUSKLAPPEN]
HDSS_CreateClass ("mensch",3); Das ganze hat 3 members
HDSS_AddMember ("name");
HDSS_AddMember ("groesse");
HDSS_AddMember ("alter");
Dann in HDSS-Code:
Code: [AUSKLAPPEN]
void main ()
{
var $peacemaker;
var $hans;
$peacemaker = new (Mensch);
$hans = new (Mensch);
$peacemaker->name = "der friedensstifter+
$hans->name = "Der grosse hans"
$peacemaker->groesse = 180;
$hans->groesse = 240;
$peacemaker->alter = 15;
$hans->alter = 120;
// Member ausgeben:
print ($peacemaker->alter);
};
Das ganze funktioniert sogar einigermassen fehlerfrei.
mfG
Ich erzähl hier mal über eine Stadt, die zwar nicht allzu wichtig für Hauptstory ist, aber trotzdem ganz interessant ist.
Marhem liegt im Südosten Issanûrs. Hierhin kommen nur die, die vom König flüchten, oder das Gesindel eben. Kein Wunder, Marhem ist eine Stadt, die praktisch nur von Piraterie lebt. Um nach Marhem zu gelangen, müsste man zu Lande das undurchdringliche Asodan-Gebirge kommen. Schon desshalb kommen nur die härtesten bis nach Marhem.
Den Meerweg kann man vergessen, da dort die Piraten von Marhem hausen. Diese besitzen einige Schiffe, die sie der königlichen Flotte abgenommen haben, so z.B. einige Schiffe vom Typen "schwarze Irothen" , welches eines der stärksten Schiffe des Landes darstellt.
Marhem lebt, wie schon gesagt von der Piraterie. Die Handelsstadt "Mercathem", eine der einzigen Städte die Meerhandel im grossen macht, liegt in der Nähe von Marhem, was den Marhem-Bewohnern sehr günstig kommt. Mercathem versorgt auch viele Städte auf Issanûr, so z.B. auch Palan, und diverse mehr. So streifen die Schiffe von Marhem in dieser Meerenge herum und passen viele Schiffe ab. Dabei hat die Regierung schon öfters versucht, etwas dagegen zu unternehmen, meist jedoch ohne Erfolg. Vor allem Palan litt eine Zeit lang unter der Piraterie, mittlerweile hat sich Palan aber unabhängig von Mercathem neue Handelspartner gesucht, nicht destotrotz wird immer noch Handel mit Mercathem betrieben. Bevor die Intenare kamen, versuchte der König sehr oft, Marhem unter seine Kontrolle zu bringen oder gar auszuschalten, dies gelang jedoch nie. Der Landweg war schwierig zu durchqueren, ausserdem sehr ungünstig um viele Leute dort durchzubringen. Über den Meerweg war Marhem durch seine vielen geklauten Schiffe auch sehr schwierig zu erreichen.
Einmal gelang es der königlichen Flotte jedoch, Marhem fast einzunehmen. Dies war ein harter Schlag für Marhem. Die Schiffe siegten bei der Seeschlacht an der Küste von Marhem und am Schluss segelten 4 Schiffe der königlichen Flotte auf Marhem zu. An Land wurden sie jedoch wieder zurückgeschlagen.
Seit der Intenar-Feldzug begonnen hat, hat der König jedoch aufgehört, Marhem anzugreifen.
Bisher bekundeten die Intenare kein Interesse an Marhem, man vermutet aber, das auch Marhem bald von Intenaren erobert wird.
Die Gegend bei Marhem, sowie die Seewege in der Meerenge:
(In Paint gemacht, nicht auslachen
)
Ansonsten habe ich wieder weiter an HDSS gewerkelt.
Jetzt kann man immerhin schon Klassen erstellen und Eigenschaften zuweisen. Beispiel: ich will hier mal eine Klasse namens 'Mensch' erstellen.
Also im HDSS-Sourcecode das schreiben:
Code: [AUSKLAPPEN]
HDSS_CreateClass ("mensch",3); Das ganze hat 3 members
HDSS_AddMember ("name");
HDSS_AddMember ("groesse");
HDSS_AddMember ("alter");
Dann in HDSS-Code:
Code: [AUSKLAPPEN]
void main ()
{
var $peacemaker;
var $hans;
$peacemaker = new (Mensch);
$hans = new (Mensch);
$peacemaker->name = "der friedensstifter+
$hans->name = "Der grosse hans"
$peacemaker->groesse = 180;
$hans->groesse = 240;
$peacemaker->alter = 15;
$hans->alter = 120;
// Member ausgeben:
print ($peacemaker->alter);
};
Das ganze funktioniert sogar einigermassen fehlerfrei.
mfG
RPG-Systeme
Mittwoch, 25. Juni 2008 von peacemaker
Heute erzähle ich mal etwas über die RPG-Systeme im Spiel. Dazu gehört z.B. Charakterentwicklung, Kampfsystem, Items, usw. Nun, ich hab mich vor längerer Zeit mit einem wahren Pen'n'Paper-Experten zusammengesetzt und mir ein kleines Konzept diesbezüglich erarbeitet. Das alte Konzept war halt sehr üblich, nicht ganz den D&D-Regeln unähnlich. Nun haben wir ein neues Konzept aufgestellt.
Zuerst: wenn man das ganze aus meiner Sicht betrachtet, so sieht man, das das ganze nur aus Formeln bestehen, es läuft alles regulär ab.
Beispiel: Der Spieler hat ein Item. Dieses hat ja einen Schaden, das bezeichnen wir hier als Item-Attribut.
Wenn der Spieler jetzt mit dem Item (nehmen wir an es ist ein Schwert) schlägt, so zieht es ja dem Gegner Leben ab.
Das ist der effektive Schaden. Der wird auch als mehreren Faktoren berechnet, so z.B.: Stärke des Spielers, Rüstwert des Gegenübers, Item-Schaden, Beweglichkeit, usw.
Nun, kommen wir zum Item-Schaden:
Ein Item hat ja ein Attribut, bei nem Schwert wäre das einfach der Schaden, den das Schwert im Normalfall verursacht.
Jetzt gibts eine Besonderheit in Tehadon: ist der Spieler zu schwach um das Schwert zu benützen (jedes Item braucht einen gewissen Wert um es zu benutzen hier nenn wir es benötigtes Attribut) dann macht das Schwert eben entsprechend wenig Item-Schaden. Dies wird so berechnet:
Item-Schaden = Item Attribut * (Spielerattribut / benötigtes Attribut)
Beispiel:
Der Spieler will ein Schwert benutzen, welches den Item-Attribut (Schaden) 40 hat. Um das Schwert zu benutzen, braucht man eine Stärke von 50. Der spieler hat aber nur 30.
Also:
Item-Schaden = 40 * (30/50)= 24
Von den 40 ursprünglichen Schadenspunkten, sinds jetzt nur noch 24. Da muss man sich doch genauer üblerlegen, ob mein ein Schwert benutzt.
Es ist noch zu sagen, das so etwas wirklich sehr empfindlich ist. Macht man bei solchen Dingen einen Fehler, wird der Spieler später eine Schwachstelle finden, zum Beispiel: aha, wenn ich ein Schwert benutze, bei welche die benötigten Attribute tiefer sind als das Spielerattribut, so mache ich mehr Punkte. Also, findet die obere Formel nur dann statt, wenn Spielerattribut < benötigtes Attribut ist.
Nun, das ist natürlich nicht die Finale Schadensberechnung. Die Genauer Formel erklär ich hier nicht, da sie a) sehr komplex ist, weil da noch viele andere Dinge mitspielen b) sie noch nicht so weit konzipiert ist.
Grundsätzlich funktioniert sie so:
effektiver Schaden = Schlagwert - Rüstungswert des Gegners
Der Schlagwert berechnet sich aus der Stärke des Spielersund aus dem Item-Schaden. Zu dieser Formel kommen noch Dinge hinzu, wie z.B. Trefferzonen.
Der Rüstungswert berechnet sich aus der Stärke der Rüstung, sowie noch anderen Faktoren.
Jede Trefferzonen multipliziert das ganze um einen bestimmten Faktor. Beispiel: Kopf gibt 0.3, Körper gibt 0.3, Beine geben 0.15, Armegeben 0.2.Beispiel: Schlagwert = 50, Rüstungswert = 45, der Körper wird getroffen.
Effektiver Schaden = (50-45)*0.3 = 1.5
Jetzt wird einfach 1.5 vom Gegnerleben abgezogen. Dies ist auch bei jedem Gegner variabel.
Noch etwas zu den Items: Items lassen sich erweitern, jedoch nur z.B. einmal, wenn man sie schleift oä.
Gewisse Items existieren z.B. gar nicht, sondern müssen erst gebaut werden. Dazu muss man mit dem Rezept zu nem Schmied gehen. Wenn dieser genug gut schmieden kann, wird er einem dieses Schwert gegen einen Entgelt (Geld oder einen Gefallen) herstellen.
Dabei wird das ganze wohl visuell ablaufen, d.H. man kann dem Schmied wirklich dabei zusehen. Das ganze wird durch externe AI-States verwirklicht, die sind für solche Dinge ideal.
Dabei wirds auch durchaus seltene Waffen geben, die z.B. nur ein Schmied der irgendwo in den Bergen haust bauen kann. So lassen sich einige interessante Dinge machen.
Nun, wenn Fragen da sind, könnt ihr sie gerne hier stellen.
Zuerst: wenn man das ganze aus meiner Sicht betrachtet, so sieht man, das das ganze nur aus Formeln bestehen, es läuft alles regulär ab.
Beispiel: Der Spieler hat ein Item. Dieses hat ja einen Schaden, das bezeichnen wir hier als Item-Attribut.
Wenn der Spieler jetzt mit dem Item (nehmen wir an es ist ein Schwert) schlägt, so zieht es ja dem Gegner Leben ab.
Das ist der effektive Schaden. Der wird auch als mehreren Faktoren berechnet, so z.B.: Stärke des Spielers, Rüstwert des Gegenübers, Item-Schaden, Beweglichkeit, usw.
Nun, kommen wir zum Item-Schaden:
Ein Item hat ja ein Attribut, bei nem Schwert wäre das einfach der Schaden, den das Schwert im Normalfall verursacht.
Jetzt gibts eine Besonderheit in Tehadon: ist der Spieler zu schwach um das Schwert zu benützen (jedes Item braucht einen gewissen Wert um es zu benutzen hier nenn wir es benötigtes Attribut) dann macht das Schwert eben entsprechend wenig Item-Schaden. Dies wird so berechnet:
Item-Schaden = Item Attribut * (Spielerattribut / benötigtes Attribut)
Beispiel:
Der Spieler will ein Schwert benutzen, welches den Item-Attribut (Schaden) 40 hat. Um das Schwert zu benutzen, braucht man eine Stärke von 50. Der spieler hat aber nur 30.
Also:
Item-Schaden = 40 * (30/50)= 24
Von den 40 ursprünglichen Schadenspunkten, sinds jetzt nur noch 24. Da muss man sich doch genauer üblerlegen, ob mein ein Schwert benutzt.
Es ist noch zu sagen, das so etwas wirklich sehr empfindlich ist. Macht man bei solchen Dingen einen Fehler, wird der Spieler später eine Schwachstelle finden, zum Beispiel: aha, wenn ich ein Schwert benutze, bei welche die benötigten Attribute tiefer sind als das Spielerattribut, so mache ich mehr Punkte. Also, findet die obere Formel nur dann statt, wenn Spielerattribut < benötigtes Attribut ist.
Nun, das ist natürlich nicht die Finale Schadensberechnung. Die Genauer Formel erklär ich hier nicht, da sie a) sehr komplex ist, weil da noch viele andere Dinge mitspielen b) sie noch nicht so weit konzipiert ist.
Grundsätzlich funktioniert sie so:
effektiver Schaden = Schlagwert - Rüstungswert des Gegners
Der Schlagwert berechnet sich aus der Stärke des Spielersund aus dem Item-Schaden. Zu dieser Formel kommen noch Dinge hinzu, wie z.B. Trefferzonen.
Der Rüstungswert berechnet sich aus der Stärke der Rüstung, sowie noch anderen Faktoren.
Jede Trefferzonen multipliziert das ganze um einen bestimmten Faktor. Beispiel: Kopf gibt 0.3, Körper gibt 0.3, Beine geben 0.15, Armegeben 0.2.Beispiel: Schlagwert = 50, Rüstungswert = 45, der Körper wird getroffen.
Effektiver Schaden = (50-45)*0.3 = 1.5
Jetzt wird einfach 1.5 vom Gegnerleben abgezogen. Dies ist auch bei jedem Gegner variabel.
Noch etwas zu den Items: Items lassen sich erweitern, jedoch nur z.B. einmal, wenn man sie schleift oä.
Gewisse Items existieren z.B. gar nicht, sondern müssen erst gebaut werden. Dazu muss man mit dem Rezept zu nem Schmied gehen. Wenn dieser genug gut schmieden kann, wird er einem dieses Schwert gegen einen Entgelt (Geld oder einen Gefallen) herstellen.
Dabei wird das ganze wohl visuell ablaufen, d.H. man kann dem Schmied wirklich dabei zusehen. Das ganze wird durch externe AI-States verwirklicht, die sind für solche Dinge ideal.
Dabei wirds auch durchaus seltene Waffen geben, die z.B. nur ein Schmied der irgendwo in den Bergen haust bauen kann. So lassen sich einige interessante Dinge machen.
Nun, wenn Fragen da sind, könnt ihr sie gerne hier stellen.
HDSS
Freitag, 20. Juni 2008 von peacemaker
Guten Tag allerseits,
Ich muss gestehen, ich war erschrocken, als ich das Datum des letzten Worklogeintrags sah. Nun, natürlich geht die Entwicklung wie gehabt weiter, nur halt immernoch tief im System, sprich: HDSS. Ihr fragt euch warum ich all diese vlt in euren Augen idiotischen Bemühungen anstelle, aber das hat doch seine Gründe. Z.B. würde ein bequemes Skriptsystem in der Editing-Phase vieles erleichtern. Zum anderen funktionieren fast alle Systeme mit dem Skriptsystem, soll heissen: es wird sehr oft gebraucht. Und wenn ein System nicht allzu gut geeignet dafür ist, bzw. der Speed nicht entsprechend ist, geht das nicht.
Klar, HDSS version 4 war echt schnell, muss ich sagen, aber komplexe Terme konnte man da vergessen. Da habe ich mir selber ne Falle gestellt.
Nun, das neue HDSS wird ja, wie schon öfters gesagt, kompiliert. Dabei funktioniert das ganze wie ein gewöhner Compiler, nur das hier der Zielcode kein Maschinencode (bzw. .exe-Datei ist) sondern HDSS-Zwischencode, welcher doch nicht ganz so low-Level ist, wie Maschinencode oder Assembler.
Also habe ich mich wieder mit Compilerbau beschäftigt. Also, das liegt jetzt ja ein paar Wochen zurück, HDSS lässt sich bereits zu grossen Teilen kompilieren, einige spätere Elemten sind schon drin.
Mein nächstes Ziel ist eine Stand-Alone-Demo von HDSS rauszubringen. Dabei wird das ganze den HDSS-Compiler sowie eine VM (Programm welches den HDSS-Zwischencode ausführt. (=> wie in java z.B. )) beinhalten. Folgende Systeme werden dann verfügbar sein:
Ich zeig euch hier mal ein Beispiel, Wir fügen einen Befehl namens "write" hinzu. In BB würde das (hier nur als Beispiel!) dem Befehl "print" entsprechen.
So, zuerst muss man den Befehl zu dem Compiler hinzufügen. Der managt das mit einigen hinv-Files. Diese Befehle nennt man "Invokes". Also, dafür einfach eine neue Datei namens "console.hinv" und in den Unterordner des Compilers "modules\" reinspeichern.
Dort schreiben wir einfach folgendes rein:
Code: [AUSKLAPPEN]
cmd=write;
ID=15; // konstante ID
param=1; // Anzahl Parameter (ist natürlich Optional. Wenn man das nicht angibt, ist es Flexibel)
Wenn man bei Param einen Wert eingibt, und der Befehl Print später mehr als 1 Parameter angegeben bekommt, motzt der Compiler. Das kann man auch ausschalten, aber es ist eher eine Sicherheitsmassnahme.
Nun, jetzt in der Datei "HDSS_CommandID.BB" einfach eine Konstante einfügen:
Code: [AUSKLAPPEN]
const HDSS_COMMAND_PRINT_ID = 15;
Es gibt auch einen Befehl namens "HDSS_GetCommandID". Dort gibt man den Befehlsnamen an, und kriegt die in der hinv-Datei angegebene ID zurück.
So, jetzt gehts an die VM.
Dort gibt es eine Funktion namens "execToken". Die führt immer den nächsten Term im HDSS-Zwischencode aus.
Dort einfach folgendes hinzufügen:
Code: [AUSKLAPPEN]
function execToken$ ();
local sHDSSLine$ = HDSS_GetNextBCLine$ ();
; ...
select sHDSSLine$
; ...
case ...
case ....
; SO JETZT:
case HDSS_COMMAND_PRINT_ID
print execToken$ ();
return 0;
case ...
End Select
; ...
End Function
So einfach ist das. bei print gibt man ja als Parameter "execToken" an. Das liefert hier einfach den nächstem Term zurück. Dabei ist ja nicht bekannt, wieviele Schritte nötig sind, da das ganze ja nicht nur eine Zahl oder eine Variable sein kann, sondern auch Dinge wie: "absolute (-17)+$var" usw.
Nun, schon ist ein neuer Befehl verfügbar. Ich habe noch vergessen zu sagen, das HDSS nicht case-sensitive ist. Man kann sowohl "wRiTe" als auch "WRITE" schreiben, das ist egal.
So, was HDSS jetzt erstmal kann, ist so etwas:
Code: [AUSKLAPPEN]
void main ()
{
var $file;
var $line;
$file = openFile ("file.txt");
$line = getFileLine ($file);
print ($line);
if ($line=="line")
{
print ("in dieser Zeile steht: 'line');
};
};
Wenn bei "openFile" keine Datei gefunden werden kann, kriegt man folgende Fehlermeldung:
Klar, nicht schön, aber aussagekräftiger, als wenn man später plötzlich ein "Memory Acces Vialotion" kriegt.
So, was kommt als nächstes? Ich mache mir gerade ein OOP-Konzept, bisher wird das wohl etwa so funktionieren:
Code: [AUSKLAPPEN]
$testButton01 = new Button ();
$testButton01->Caption = "drück mich!";
$testButton01->x ; // ... hier noch Grösse / Breite / Position definieren. Lassen wir mal weg.
// hier ginge auch:
// INSTANCE $testButton01 (Button)
// {
// Caption = "drück mich";
// x = ... etc
// };
// Dann: definieren was passiert, wenn man den Button drückt:
void testButton01::onClick ()
{
$testButton01->Caption = "du hast mich gedrückt!";
};
Das ist eigtl. sehr einfach. Wie das umzusetzen ist? Ich hatte bereits eine gute Idee. Man reserviert einfach eine ganze Reihen von Variabeln hintereinander (also das ist jetzt intern). Eine klasse hat z.B. 3 Eigenschaften. Also werden 3 Variabeln dafür reserviert. Die Instanz-ID, in diesem Fall $testButton01, beinhaltet einfach die Position der ersten Variable. Die Variabeln werden nämlich in einer langen Liste gemanagt.
Und nun noch ein kleines Skript, welches ich aus dem Kopf erstellt habe. Hat sicher noch Fehler, aber es war mehr ein Konzept. Was es tut: es erstellt ein Schiff, welches als Child-Objekt eines Ruderrades fundiert. Das ganze ist etwas High-Level, d.H. extern gemacht. Durch den enormen Speed von HDSS ist das jetzt auch ganz gut möglich.
Nun, hier das Skript:
Code: [AUSKLAPPEN]
Es ist ja eigtl. sehr simpel.
Nun denn, auf das HDSS mal bald fertig wird!
mfG pm
Ich muss gestehen, ich war erschrocken, als ich das Datum des letzten Worklogeintrags sah. Nun, natürlich geht die Entwicklung wie gehabt weiter, nur halt immernoch tief im System, sprich: HDSS. Ihr fragt euch warum ich all diese vlt in euren Augen idiotischen Bemühungen anstelle, aber das hat doch seine Gründe. Z.B. würde ein bequemes Skriptsystem in der Editing-Phase vieles erleichtern. Zum anderen funktionieren fast alle Systeme mit dem Skriptsystem, soll heissen: es wird sehr oft gebraucht. Und wenn ein System nicht allzu gut geeignet dafür ist, bzw. der Speed nicht entsprechend ist, geht das nicht.
Klar, HDSS version 4 war echt schnell, muss ich sagen, aber komplexe Terme konnte man da vergessen. Da habe ich mir selber ne Falle gestellt.
Nun, das neue HDSS wird ja, wie schon öfters gesagt, kompiliert. Dabei funktioniert das ganze wie ein gewöhner Compiler, nur das hier der Zielcode kein Maschinencode (bzw. .exe-Datei ist) sondern HDSS-Zwischencode, welcher doch nicht ganz so low-Level ist, wie Maschinencode oder Assembler.
Also habe ich mich wieder mit Compilerbau beschäftigt. Also, das liegt jetzt ja ein paar Wochen zurück, HDSS lässt sich bereits zu grossen Teilen kompilieren, einige spätere Elemten sind schon drin.
Mein nächstes Ziel ist eine Stand-Alone-Demo von HDSS rauszubringen. Dabei wird das ganze den HDSS-Compiler sowie eine VM (Programm welches den HDSS-Zwischencode ausführt. (=> wie in java z.B. )) beinhalten. Folgende Systeme werden dann verfügbar sein:
- B3D-Engine
- Devil-Particelengine
- Devil-Shadowengine
- ODE
- Datei/String-System (mit vielen Funktionen für z.B. parsern etc)
- Mathe-Funktionen
Ich zeig euch hier mal ein Beispiel, Wir fügen einen Befehl namens "write" hinzu. In BB würde das (hier nur als Beispiel!) dem Befehl "print" entsprechen.
So, zuerst muss man den Befehl zu dem Compiler hinzufügen. Der managt das mit einigen hinv-Files. Diese Befehle nennt man "Invokes". Also, dafür einfach eine neue Datei namens "console.hinv" und in den Unterordner des Compilers "modules\" reinspeichern.
Dort schreiben wir einfach folgendes rein:
Code: [AUSKLAPPEN]
cmd=write;
ID=15; // konstante ID
param=1; // Anzahl Parameter (ist natürlich Optional. Wenn man das nicht angibt, ist es Flexibel)
Wenn man bei Param einen Wert eingibt, und der Befehl Print später mehr als 1 Parameter angegeben bekommt, motzt der Compiler. Das kann man auch ausschalten, aber es ist eher eine Sicherheitsmassnahme.
Nun, jetzt in der Datei "HDSS_CommandID.BB" einfach eine Konstante einfügen:
Code: [AUSKLAPPEN]
const HDSS_COMMAND_PRINT_ID = 15;
Es gibt auch einen Befehl namens "HDSS_GetCommandID". Dort gibt man den Befehlsnamen an, und kriegt die in der hinv-Datei angegebene ID zurück.
So, jetzt gehts an die VM.
Dort gibt es eine Funktion namens "execToken". Die führt immer den nächsten Term im HDSS-Zwischencode aus.
Dort einfach folgendes hinzufügen:
Code: [AUSKLAPPEN]
function execToken$ ();
local sHDSSLine$ = HDSS_GetNextBCLine$ ();
; ...
select sHDSSLine$
; ...
case ...
case ....
; SO JETZT:
case HDSS_COMMAND_PRINT_ID
print execToken$ ();
return 0;
case ...
End Select
; ...
End Function
So einfach ist das. bei print gibt man ja als Parameter "execToken" an. Das liefert hier einfach den nächstem Term zurück. Dabei ist ja nicht bekannt, wieviele Schritte nötig sind, da das ganze ja nicht nur eine Zahl oder eine Variable sein kann, sondern auch Dinge wie: "absolute (-17)+$var" usw.
Nun, schon ist ein neuer Befehl verfügbar. Ich habe noch vergessen zu sagen, das HDSS nicht case-sensitive ist. Man kann sowohl "wRiTe" als auch "WRITE" schreiben, das ist egal.
So, was HDSS jetzt erstmal kann, ist so etwas:
Code: [AUSKLAPPEN]
void main ()
{
var $file;
var $line;
$file = openFile ("file.txt");
$line = getFileLine ($file);
print ($line);
if ($line=="line")
{
print ("in dieser Zeile steht: 'line');
};
};
Wenn bei "openFile" keine Datei gefunden werden kann, kriegt man folgende Fehlermeldung:
Klar, nicht schön, aber aussagekräftiger, als wenn man später plötzlich ein "Memory Acces Vialotion" kriegt.
So, was kommt als nächstes? Ich mache mir gerade ein OOP-Konzept, bisher wird das wohl etwa so funktionieren:
Code: [AUSKLAPPEN]
$testButton01 = new Button ();
$testButton01->Caption = "drück mich!";
$testButton01->x ; // ... hier noch Grösse / Breite / Position definieren. Lassen wir mal weg.
// hier ginge auch:
// INSTANCE $testButton01 (Button)
// {
// Caption = "drück mich";
// x = ... etc
// };
// Dann: definieren was passiert, wenn man den Button drückt:
void testButton01::onClick ()
{
$testButton01->Caption = "du hast mich gedrückt!";
};
Das ist eigtl. sehr einfach. Wie das umzusetzen ist? Ich hatte bereits eine gute Idee. Man reserviert einfach eine ganze Reihen von Variabeln hintereinander (also das ist jetzt intern). Eine klasse hat z.B. 3 Eigenschaften. Also werden 3 Variabeln dafür reserviert. Die Instanz-ID, in diesem Fall $testButton01, beinhaltet einfach die Position der ersten Variable. Die Variabeln werden nämlich in einer langen Liste gemanagt.
Und nun noch ein kleines Skript, welches ich aus dem Kopf erstellt habe. Hat sicher noch Fehler, aber es war mehr ein Konzept. Was es tut: es erstellt ein Schiff, welches als Child-Objekt eines Ruderrades fundiert. Das ganze ist etwas High-Level, d.H. extern gemacht. Durch den enormen Speed von HDSS ist das jetzt auch ganz gut möglich.
Nun, hier das Skript:
Code: [AUSKLAPPEN]
const SHIP_STATE_ON_DRIVE = 1;
const SHIP_VAR_SPEED = 2;
INSTANCE Ship01 (C_IAO)
{
name = "Grosses Schiff";
var[SHIP_VAR_SPEED] = 120.0;
};
INSTANCE Ship01_RuderRad (C_IAO)
{
parent = Ship01;
};
void Ship01::onUse ()
{
var $RuderRad;
$RuderRad = Entity->GetChild ("SLOT_ruderRad");
if (NPC->DistaneToEntity ($user->ID,$Ruderrad) < $user->RangeDistance
{
if (Input->MouseHit(MOUSE_LEFT))
{
Ship01_Ruderad->State = IAO_ON_USE;
};
};
};
void Ship01_RuderRad::onUse ()
{
if (Input->KeyDown (KEY_UP))
{
$this->parent->ODE_AddImpulse (0,0,$this->parent->var[SHIP_VAR_SPEED]);
};
};
const SHIP_VAR_SPEED = 2;
INSTANCE Ship01 (C_IAO)
{
name = "Grosses Schiff";
var[SHIP_VAR_SPEED] = 120.0;
};
INSTANCE Ship01_RuderRad (C_IAO)
{
parent = Ship01;
};
void Ship01::onUse ()
{
var $RuderRad;
$RuderRad = Entity->GetChild ("SLOT_ruderRad");
if (NPC->DistaneToEntity ($user->ID,$Ruderrad) < $user->RangeDistance
{
if (Input->MouseHit(MOUSE_LEFT))
{
Ship01_Ruderad->State = IAO_ON_USE;
};
};
};
void Ship01_RuderRad::onUse ()
{
if (Input->KeyDown (KEY_UP))
{
$this->parent->ODE_AddImpulse (0,0,$this->parent->var[SHIP_VAR_SPEED]);
};
};
Es ist ja eigtl. sehr simpel.
Nun denn, auf das HDSS mal bald fertig wird!
mfG pm
Gehe zu Seite Zurück 1, 2, 3 ... 6, 7, 8 ... 10, 11, 12 Weiter