Klingt echt gut, ich bin mal wirklich gespannt. Vor allem als Mac-User ist es doof, immer auf Windows switchen zu müssen, wenn man ein wenig Makern will und euer neuer Map-Editor sieht sehr funktional aus.
Klingt echt gut, ich bin mal wirklich gespannt. Vor allem als Mac-User ist es doof, immer auf Windows switchen zu müssen, wenn man ein wenig Makern will und euer neuer Map-Editor sieht sehr funktional aus.
Heute gibt es die versprochenen Neuigkeiten + Screenshots + Demo.
Fangen wir mit den Screenhots an:
Scripting
Nunja, Ruby im KorteX RPG Studio.
Mapping
Die Map aus der Demo mit aktiviertem Raster. Bei dieser Map werden 32x32 Tiles verwendet.
Mapping
Die Map aus der Demo. Diesesmal mit aktivierten Highlighting.
Events
Das Player-Event aus der Demo. Die Farben der einzelnen Befehle werden später noch angepasst. Zudem wird es die Möglichkeit geben, das der Benutzer die Farben selber festlegt.
Wie auch schon in der alten GUI ist auch hier wieder Möglich, Bedingungen, Schleifen, etc. ein- und auszuklappen.
Variablen
Variablen im KorteX RPG Studio. Das speichern von IDs in Variablen und wählen von Variablen aus gespeicherten IDs wird später noch hinzugefügt. Bei allen anderen Befehlen wie Warten, Tastaturabfrage, etc. ist es bereits möglich,
auch variable Werte zu verwenden. (Die Zeit die gewartet werden soll lässt sich also auch von einer Variable einsetzen).
Es gibt 4 verschiedene Typen von Variablen. Ganzzahlen(Integer), Kommazahlen(Float), Wahrheitswerte/Switches(Boolean) und Zeichenketten(String).
Es wird dabei unterschieden zwischen lokalen und globalen Variablen.
Jedes Event besitzt einen geringen Satz(Derzeit 20 pro Typ) lokaler Variablen.
Diese Variablen sind nur innerhalb des Events gültig. Ein Zugriff von außen ist nicht möglich.
Globale Variablen sind von überall aus zugänglich. Die Anzahl liegt derzeit bei 5000 pro Typ.
Variablen
Der Dialog zum wählen einer lokalen Variable.
Fonts
Im KorteX RPG Studio ist die Font-Verwaltung einfach. Ihr könnt einfach euren
Font auswählen, benötigte Attribute einstellen und konvertieren.
Dabei wird eine KSF-Datei(KorteX Studio Font) erzeugt. Diese enthält die
Font-Daten sowie PNG-Daten.(Es gibt diesesmal keine 2 Dateien mehr pro Font, wir haben diesesmal alles in einer datei vereint).
Warum nicht mehr Screenhots? Sicher könnte man noch von allen anderen
Befehlen Screenshots machen und Erklärungen schreiben. Das Problem ist nur, das mir die Zeit absolut fehlt da ich ja heute, in wenigen Stunden, verreise. Weitere Screenshots und Demos gibt es nach meinem Urlaub. (Ich bin nunmal der Programmierer im Team, wenn ich nicht da bin läuft leider nur wenig).
Bevor es nun die Demo gibt, ein paar Worte zu XRGSS(KorteX Ruby Game Scripting System).
In der Demo wird euch auffallen, das im Vergleich zu den bisherigen alten Demos ein paar Sachen fehlen. Dazu zählen Bildschirmübergänge(Transitions)
sowie die komplette Audioausgabe. Bei den damaligen Demos spielte immer ein schwaches Liedchen im Hintergrund. Bei dieser Demo gibt es keinen Sound.
Wer also ein Audio-Modul im XRGSS sucht wird nicht finden.
Der Grund dafür ist, das diese Systeme derzeit überarbeitet werden.
Allgemein sind die Skripte der Demo nicht zum abändern gedacht, außer man möchte lieber im Fenstermodus testen. (Dazu im Ruby-Ordner RUBY_5.rb öffnen und bei XGraphics.init das "true" zu einem "false" machen).
Es wird sicher noch Demos geben, die extra zum Skripten gedacht sind, entsprechend wird dann auch eine Dokumentation beigefügt. Bei dieser Demo ist das aber nicht der Fall. Bugs sollte es keine geben, falls doch so sollte man das bitte verzeihen. Ich hab das ganze in nur wenigen Stunden erstellt und gestestet, mir blieb nicht soviel Zeit.
Download: KorteX Demo
An dieser Stelle auch nochmal ein großes Danke an RPGA.info(www.rpga.info) für den zur Verfügung gestellten Space.
Als Mac User wirst du mit KorteX RPG Studio keine Probleme haben. Auf Mac OS X läuft das ganze einwandfrei. Es muss auch nicht zwingend Mac OS XZitat
10.5 Leopard mit extra Update und Java 6 Unterstützung sein. Java 5 ist bereits ausreichend. Und für die Spiele wird überhaupt kein Java benötigt.
Fragen, etc. können gerne gestellt werden. Ich werde diese nach meinem Urlaub beantworten.
Mit freundlichen Grüßen
Kasenoru
Geändert von Kasenoru (25.07.2008 um 19:10 Uhr)
Ach ja das gefällt mir ganz gut,
ich bin schon richtig gespannt wann das Programm uns zur verfügung stehen darf
Mach weiter so.
Bin ich der einzige, bei dem die Engine extrem langsam läuft?
Außerdem funktioniert "0" nicht, so dass ich das Intro nicht abspielen kann.
Naja es ist ok die geschwindigkeit bei mir, null funktioniert erst wenn du 1 gedrückt hast, das intro ist das titel bild^^
Was heißt "ok"? Bei mir dauert ein Schritt etwa 3 Sekunden.
Meine Hardware:
- Pentium D mit zwei Kernen, jeweils 2.8 Ghz (wobei XGame.exe nur ein Kern beansprucht)
- 2 GB RAM
- ATI Radeon X1950 Pro Grafikkarte mit 256 MB RAM
Lol, ok.
Nächstes Problem:
Versuch mal zwischen Intro und Map Engine umherzuschalten. Bei mir gibt es nach der Folge "10101" einen Crash und die Fehlermeldung: "XGame.exe hat ein Problem festgestellt und muss beendet werden."
Hmm... ich hab deine Probleme nicht. Ein Schritt dauert etwa so lange wie beim RM, ich bekomme keine Fehlermeldung, wenn ich hin und her schalte zwischen Intro und Map.
Zum Vergleich:
1 Ghz Prozessor
256 MB Ram
GraKa onboard aufm Lappie
Windows 2000 SP4
Was fürn OS nutzt du denn? Man (oder zumindest ich) hört ja nur schlechtes von Vista, vielleicht liegts dadran, falls du's benutzt?
@ Kasenoru:
Bei mir läuft die Demo auch enorm langsam und die Taste "0" funktioniert nicht.
Mein PC ist etwa vergleichbar mit dem von Kyuu.
Ich hab lediglich etwas mehr Ghz, dafür weniger RAM.
Hoffe das ihr das ausbessern könnt, bzw. dass es nur ein einmaliges Demo-Problem ist.
Kaltblut
Das hat sich erledigt, da das Intro nur das Titelbild ist. Von daher hat es keinen Effekt "0" im Titelbild zu drücken. ;)
Egal wie oft und wie schnell? Schon versucht schnell hintereinander "1" und "0" zu drücken und das längere Zeit?
Eventuell hängt es aber mit dem Betriebssystem zusammen, da du Windows 2000 hast und ich Windows XP (SP2).
@Sky-arts:
Welches Betriebssystem und welche Hardware hast du?
Mit etwas mehr Testern ließe sich das Problem eventuell eingrenzen.
Wenn nicht, hat das KorteX Studio ein großes Problem (außer, es ist nur ein Problem mit dieser Demo).
Geändert von Kyuu (26.07.2008 um 14:05 Uhr)
Bei mir selbst laeuft alles ganz gut und schnell (umschalten von 0-1 ist kein Problem egal wie schnell). Ich verwende zurzeit WinXP SP2 und einen Rechner mit 3,2 GHz und 1GB Ram.
Ach ja repariert mal den Move_speed alles ueber zwei macht die Kollisionserkennung und Bildschirmbewegung unmoeglich(Da will man bisschen mehr speed und dann sowas^^).
PS: Weiter so!!! Bisher einfach nur Geil.
Bei mir läuft alles flüssig und ohne Probleme.
Wenn ich allerdings gleich nachdem ich im "0" gedrückt hab "1" drücke und umgekehrt stürzt das Programm ab. Aber echt mal wer kommt darauf das schnell hintereinander zu drücken lol
eckdaten:
1x1,7GHz
1,5GB RAM
ATI x1600 mit 256MB
ich denke die paar fehler werden noch ausgemerzt werden ^^
für ne demo schauts auf alle fälle schon super aus, schließlich läuft ja das ganze
--
Bis auf die träge Reaktion des Chars beim Bewegen läuft auch bei mir alles flüssig. Sowohl im Vollbild- als auch im Fenstermodus.
Mein System:
Intel Core 2 Duo E6600, 2x2,4 GHz
3,0 GB RAM
Geforce 9600 GT 512 MB
Nachtrag: Oh achja: Hab Windows XP SP2 hier drauf. ^^
Geändert von The Best Isaac (26.07.2008 um 21:48 Uhr)
Also ich hab WinXP mit SP3 also bin auf den neusten stand von microsoft ^^
ansonsten hab ich eigentlich ein recht altes system 2.4+GHz 768MB ram 256mb graka das war's au scho...
Hoffe ich konnt helfen
Läuft die Demo eigentlich auch unter Linux? Also, generell sollte sie das ja tun. Die Stärke vom KorteX-Studio ist ja die Plattformunabhängigkeit. Aber, irgendwie bekomm ich beim Ausführen der "XGame.exe" jede Menge (Ruby-) Skriptfehler. Muss aber auch dazu sagen, dass ich noch absoluter Linux-Noob bin. ^^
Wollte es aber mal generell testen. Vielleicht weiß ja jemand Rat.
Programmabstürze sollten niemals passieren. Es ist das A und O jedes Programmierers sein Programm gegen Abstürze abzusichern.Aber echt mal wer kommt darauf das schnell hintereinander zu drücken lol
Hier scheint es aber, dass irgendeine Dependency für die Probleme verantwortlich ist, da kein Muster erkennbar ist. Ohne den Sourcecode zu kennen, könnte man den Übeltäter eventuell mit einem Programm wie Process Explorer finden.
Die Plattformunabhängigkeit liegt im Sourcecode, das heißt du kannst den Sourcecode auf jeder Plattform, die das Studio unterstützt, kompilieren.
Du kannst aber nicht einfach ein unter Windows kompiliertes Programm auf einer anderen Plattform starten und umgekehrt. (Weil das Programm in diesem Fall im plattformabhängigem Maschinencode vorliegt, der auf eine bestimmte Struktur abgestimmt ist.)
Zumindest nicht, wenn das Programm nicht in Java (so wie der Editor), oder einer anderen Sprache, die auf Virtual Machines basiert (wie z.B. Microsoft's .NET), geschrieben wurde. In dem Fall müsste der Entwickler aber immer darauf hoffen, dass die zugehörige VM auf dem Rechner des Endnutzers installiert ist, und/oder diesen explizit auffordern es nachzuholen. Das wäre aber in meinen Augen für Endnutzer nicht zumutbar und praktisch würde nur der Entwickler wirklich davon profitieren.
Btw:
Am 25. fahre ich erstmal bis zum 9. August in einen erholsamen Urlaub. Kurz davor wird es hier nochmal ein ganz ganz großen News-Flash geben und ne Demo für Windows auch
Geändert von Kyuu (27.07.2008 um 13:07 Uhr)
Okay, danke für die ausführliche Erklärung. Hätte ich eigentlich selbst drauf kommen müssen. xD
Berechtigungen
Zitieren