Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 20 von 157

Thema: Power Patch v0.3/0.4x

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    wieso soll der Patch in der Praxis nicht benutzt werden? Mir ist schon klar, dass Anfänger damit nichts anfangen können (xD), aber es wendet sich auch eher an die Fortgeschrittenen bis Profis.

  2. #2
    Zitat Zitat von Cherry1 Beitrag anzeigen
    wieso soll der Patch in der Praxis nicht benutzt werden? Mir ist schon klar, dass Anfänger damit nichts anfangen können (xD), aber es wendet sich auch eher an die Fortgeschrittenen bis Profis.
    Najo, er hat schon Recht. Schau dir doch einmal an wie oft
    die bereits vorhandenen Patche genutzt werden?
    Der Tastenpatch von Ineluki z.B. ist eigentlich ein recht bekannter
    Patch. Wieviele Spiele genau nutzen diesen Patch? Die meisten kommen
    auch gut ohne aus. Die zwei Patche die am häufigsten genutzt werden
    sind wohl der reine MP3 Patch und Gnafs angeblicher Patch.
    Beide sind nämlich recht einfach in der Handhabung. Der Tastenpatch
    benötigt jedoch schon etwas Lernaufwand.

    Nun kommt dein Patch und hat die LUA im Schlepptau.
    Sicherlich eine lustige Idee. Nur wer wird das schon nutzen?
    Die Fortgeschrittenen oder Profis würden sich dann schon
    eher dem XP zuwenden. Dieser hat nämlich den Vorteil
    das er garantiert funktioniert. Dein Patch ist komplett
    unerprobt. Und wer geht schon gern solch ein Risiko ein?
    Wenn dein Patch Macken hat, dann wirkt sich das negativ
    auf die eigene Arbeit am Spiel aus. Vorallem aber dann beim
    Spieler selbst. Was ist wenn das eigene Savemenü das auf
    deinem Patch ruht aufeinmal die zu speicherten Daten nicht
    richtig ausliest und abspeichert? Schon haben wir ein
    enormes Problem.

    Dein Patch benötigt also schon recht ausgeweitete Kentnisse
    in Sachen Programmierung. Er ist ungetestet. Und er richtet
    sich an eine Zielgruppe die meist beim 2k/2k3 sitzt weil sie
    die Herausforderung suchen. Diejenigen die es nicht tun
    sitzen dann ohnehin beim XP oder bei anderen Dingen.

    Alles in allem wird das wohl das sein was Corti meinte.
    Und die Wahrscheinlichkeit für diese Entwicklung steht
    zu deinem Pech
    recht gut.

  3. #3
    @Makenshi: Also ich persönlich finde ja, dass *jedes* Tool einmal ungetestet gewesen ist. Ich arbeite schon sehr lange mit dem 2k3 und kenn mich auch gut aus, zähle mich jetzt also mal zu Cherrys Zielgruppe dazu - und ich sehe keinen Grund, aus dem man das Ding nicht mal probieren sollte. Vorher vielleicht eine Sicherungskopie vom Projekt auf einen externen Datenträger machen und die rpg2k3setup-Datei jederzeit griffbereit, falls alle Stricke reißen, aber einen Versuch sind DIESE Features doch allemal wert, finde ich zumindest. Und wenn Cherry immer für technische Fragen und/oder Probleme zur Verfügung steht, ist das auch vollkommen in Ordnung...

  4. #4
    Zitat Zitat von Alan Beitrag anzeigen
    @Makenshi: Also ich persönlich finde ja, dass *jedes* Tool einmal ungetestet gewesen ist. Ich arbeite schon sehr lange mit dem 2k3 und kenn mich auch gut aus, zähle mich jetzt also mal zu Cherrys Zielgruppe dazu - und ich sehe keinen Grund, aus dem man das Ding nicht mal probieren sollte. Vorher vielleicht eine Sicherungskopie vom Projekt auf einen externen Datenträger machen und die rpg2k3setup-Datei jederzeit griffbereit, falls alle Stricke reißen, aber einen Versuch sind DIESE Features doch allemal wert, finde ich zumindest. Und wenn Cherry immer für technische Fragen und/oder Probleme zur Verfügung steht, ist das auch vollkommen in Ordnung...
    @Alan

    Natürlich hast du Recht damit das jedes Tool einmal unerprobt war.
    Jedoch geht es mir (wie beschrieben) nicht darum das man es "mal eben"
    ausprobiert. Dagegen spricht nichts. Man macht sich schon eher Sorgen
    um unvorhersehbare Langzeitwirkungen in kritischen Bereichen des Projekts.
    Wie halt schon beschrieben meine ich die Spielstände des Spielers.

    Ich persönlich möchte genau wie mein Projektpartner ein solches Risiko
    gar nicht erst eingehen. Dafür steckt in unserem Projekt viel zuviel
    Herzblut drin. Wenn du dieses Risiko eingehen möchtest, dann tu das.

    @Cherry

    Gute Idee. Mit einem grafischen UI könntest du sicherlich die
    Benutzbarkeit erhöhen. Ob das jedoch das aufgezählte Problem
    beseitigt sei mal dahingestellt.

  5. #5
    Zitat Zitat
    Wenn du dieses Risiko eingehen möchtest, dann tu das.


    Hm, wenn man vorher eine Sicherungskopie vom Projekt macht und die 2k3.exe griffbereit hat, WAS soll dann noch schiefgehen? Ich meine, ja klar möcht ich nicht, dass mein Projekt wegen einer Patch-Fehlfunktion draufgeht, aber wenn man entsprechende Sicherheitsvorkehrungen trifft... und so extrem schiefgehen, dass sich Windows nicht mehr starten lässt, wird's wohl hoffentlich auch wieder nicht

  6. #6
    Zitat Zitat von Alan Beitrag anzeigen
    Hm, wenn man vorher eine Sicherungskopie vom Projekt macht und die 2k3.exe griffbereit hat, WAS soll dann noch schiefgehen? Ich meine, ja klar möcht ich nicht, dass mein Projekt wegen einer Patch-Fehlfunktion draufgeht, aber wenn man entsprechende Sicherheitsvorkehrungen trifft... und so extrem schiefgehen, dass sich Windows nicht mehr starten lässt, wird's wohl hoffentlich auch wieder nicht ;)
    Du musst schon lesen was ich schreibe. :)
    Ich bin nicht so der Fan von ständigen Wiederholungen.
    Ich habe bereits geschrieben das man Fehlereinwirkungen
    zu fürchten hat die sich NICHT testen lassen.
    Wie aufgeführt wäre es bei solch einem ungetesten Patch
    sehr gut im Bereich des möglichen das die Speicherroutine
    die auf diesem Patch thront, beim 34x abspeichern aufeinmal
    das Savegame falsch schreibt. Dies hätte zur Folge das der
    Spieler dieses in die Tonne hauen könnte. Das erzeugt Frust.
    Und verschafft dem Spiel einen Flug in den Papierkorb.

    Und nein, so etwas ist nicht wirklich testbar. Wenn du
    nämlich zum testen 20x abspeicherst, bemerkst du nichts.
    Und ja, das ist nur ein Beispiel. Nichts zum haarkleinen
    interpretieren.

    Solche Faktoren wie der Beispielfaktor sind mir mehr als
    Grund genug so etwas ungetestetes nicht zu benutzen.
    Und jetzt schreib bitte nicht WIEDER das du das durch
    entsprechende Vorkehrungen das verhindern kannst.
    Wenn das z.B. im Betatest passiert, dann wird es
    reichlich widerlich.

  7. #7
    @myriad: in der nächsten Version geht das.
    @Makenshi: mann, wie soll das gehen? Die Speicher/Ladesache ist sowas von primitiv, da wird eine Variable nach der anderen in ne Datei geschrieben...
    mfG Cherry

  8. #8
    Zitat Zitat von Cherry1 Beitrag anzeigen
    wieso soll der Patch in der Praxis nicht benutzt werden? Mir ist schon klar, dass Anfänger damit nichts anfangen können (xD), aber es wendet sich auch eher an die Fortgeschrittenen bis Profis.
    Was Corti andeutet stimmt leider in der Art schon.
    Viele Leute die den Maker benutzen nutzen ihn in dem Willen und dem Wissen das sie genau mit diesem Tool arbeiten wollen.
    Viele "freuen" sich das der Maker sowenige Funktionen hat weil sie einfach loslegen wollen um ein bisschen RPG zu bauen.

    Wem die Funktionen des Makers zu spärlich sind, der wendet sich meist anspruchsvolleren und echten Programmiersprachen zu.

    Dein Patch - so handwerklich genial wie er nun ist - ist wie ein Ferrari-Motor in einem Trabi: Egal wie gut er funktioniert - es werden ihn nur wenige fahren weil Leute die Geschwindigkeit wollen gleich zu einem Ferrari tendieren und Trabinostalgiker froh sind das ihr Auto fährt wie es fahren soll.

    Das ist zwar wirklich schade aber bevor du Jahre in die Entwicklung steckst solltest du wissen das es unter Umständen deinem Patch so ergehen könnte...

  9. #9
    also, Jahre ganz sicher nicht, ich werde es bis v1.0 machen und dann, von Bugfixes abgesehen, ruhen lassen. Außerdem macht mir die Sache ganz einfach Spaß.
    mfG Cherry

  10. #10
    @Daen vom Clan: Um bei deinem Vergleich zu bleiben (den ich übrigens ganz gut finde ^^): Was ist jetzt aber, wenn es sich im Trabi bequemer fährt als im Ferrari? Ich mein, klar gibt's was technisch höheres als den Maker, aber wer ist schon gewillt, sein Hauptprojekt in diesem vermeintlich besseren Programm komplett neu zu schreiben wenn er doch eine Extension am Maker haben kann, mit dem auch mehr Möglichkeiten offen stehen? Wer gewöhnt sich denn schon gerne an eine komplett neue Entwicklungs-Umgebung? Was glaubst du, warum der RMXP lang nicht so erfolgreich ist wie der 2k3? Denk mal drüber nach...

    @Cherry: Egal was die anderen sagen - keep going!

  11. #11
    Zitat Zitat von Alan Beitrag anzeigen
    @Daen vom Clan: Um bei deinem Vergleich zu bleiben (den ich übrigens ganz gut finde ^^): Was ist jetzt aber, wenn es sich im Trabi bequemer fährt als im Ferrari? Ich mein, klar gibt's was technisch höheres als den Maker, aber wer ist schon gewillt, sein Hauptprojekt in diesem vermeintlich besseren Programm komplett neu zu schreiben wenn er doch eine Extension am Maker haben kann, mit dem auch mehr Möglichkeiten offen stehen? Wer gewöhnt sich denn schon gerne an eine komplett neue Entwicklungs-Umgebung? Was glaubst du, warum der RMXP lang nicht so erfolgreich ist wie der 2k3? Denk mal drüber nach...
    Der XP ist deswegen nicht erfolgreich, weil viele Leute völlig falsche
    Informationen über ihn haben und sie auch noch brav weiter verbreiten.
    Der XP ist für von seiner Nutzerführung definitiv kaum anders als der 2k/2k3.
    Er macht einem das Leben eher um einiges einfacher. Selbst der 2k3 der wird kaum benutzt. Und dies obwohl er dem 2k nur in Sachen Perfomance unterlegen ist. Hier ist die Benutzeroberfläche nahezu identisch. Die Leute sind simpel zu faul auch nur die kleinste Änderung anzunehmen.

    Eben aus diesem Grund werden die meisten den Ferrarimotor nicht richtig nutzen. Sondern in ihrem Trabbi sitzen bleiben. Immerhin muss man lernen wie man den Ferrarimotor nicht abwürgt. Da wird ja aber faul sind, lassen wir das schön sein. Und ja, es sind natürlich nicht alle 2k/2k3 Nutzer damit gemeint. Ich bin selbst einer. Nur trifft dieses Bild leider auf eine gefühlt große Menge der "Anti XP" Front. Die Krönung dieser Lächerlichkeit sind die Leute die etwas von "Tradition" erzählen und damit nur verdecken das sie zu faul sind sich an ein paar neue Buttons zu gewöhnen.

    Wer also was neues will, der sollte durchaus den XP nehmen.
    Oder sich gleich an was professionellen bedienen. Da gibt es Möglichkeiten von denen man beim Maker nur träumen kann. Und da hilft dann auch der Ferrarimotor nichts. Und glaub mir eins. Wenn man schon einen Ferarrimotor hat, dann fährt man auch das dazugehörige Vehicle. Einfach weil einen in diesem Sinne die primitiven Überreste der "ex-Entwicklungsumgebung" nur behindern. Wer mehr will, muss auch dazu bereit sein mehr zutun.
    Diese Last fällt auch mit diesem Patch von niemanden.

  12. #12
    Das mit der Tradition ist für mich aber ein ziemlich stichhaltiges Argument, muss ich sagen - ich persönlich will nicht auf XP umsteigen weil ich die knuffigen 24x32-Pixel-Charas so toll find ^^ Die auf dem XP sind so irgendwie nicht Fisch, nicht Fleisch - nicht hochauflösend und auch nicht mehr Retro...

    @Topic: Ich versteh trotz allem für und wider immer noch nicht ganz, warum ihr Cherry's Arbeit so skeptisch gegenübersteht - ich mein, schließlich will er dafür sorgen, dass das Altbekannte in Zukunft mehr kann als jetzt, ein (wie ich finde) sehr löbliches Unterfangen, das wir eigentlich alle unterstützen sollten, anstatt es zu kritisieren...

    Nochmal wegen dem Auto-Vergleich. Ich hab mir vor einigen Wochen das "3D-Game-Studio 7", eine nicht ganz billige, professionelle Entwicklungsumgebung für dreidimensionale Spiele mit allem drum und dran gekauft - einen "Ferrari" sozusagen. Und trotzdem wär's mir lieber gewesen, wenn der gute alte RPG-Maker endlich mal in die dritte Dimension gewechselt wär (Gerüchte kursieren schon lang, aber ich hab noch nie was Konkretes gesehen). Ich sitz manchmal vor der mir bis dato unbekannten Programmiersprache und wünsch mir sehnlichst eine Command-List wie im Maker herbei... Jeder der schonmal eine Programmiersprache von Grund auf selber lernen musste, kennt das Problem garantiert. Ich hab jetzt also meinen Ferrari - und fahr nebenbei trotzdem weiter Trabi. Hätt absolut nix dagegen einzuwenden, wenn der gute alte Trabi ein paar neue Tricks spendiert bekäme...


    Greetings!


    Alan

  13. #13
    Die Arbeit von Cherry ist schon super. Dagegen sagt ja auch keiner was.

    Aber fakt ist das selbst EINFACHE Erweiterungen wie der KeyPatch kaum bis gar nicht genutzt werden. Du glaubst doch nicht allen ernstes das sich die Community dann an die LUA Scriptsprache ranwagt? Ruby war mitunter auch ein Grund warum viele den XP abgelehnt haben weil sie A) es als zu mächtiges Werkzeug empfunden haben oder B) glauben (weils teilweiße noch immer so ist) das man für den XP Ruby können muss. Das ist zwar nicht der Fall aber über kurz oder lang, je nachdem wie sich die Maker Generation weiter entwickelt werden 90% der Spiele, um qualitativ mithalten zu können, Ruby benötigen.

    Ich gehörte lange zur Fraktion A. Da ich davon ausgegangen bin wenn ich extra Ruby lernen soll kann ich auch meine vorhandenen Delphi-Kenntnissse nutzen, um etwas Spieleentwicklung erweitern, und von 0 anfangen ein Spiel zu kreieren.

    Letzteres trifft aber nicht zu. Denn die grobe Mechanik ist die selbe wie beim 2k/2k3. Selbst die alten Grafiken lassen sich problemlos verwenden. ChipSets, CharSets... einfach alles o_O

    Nun vergleichen wir mal:
    Cherrys sehr guter Patch hat die Lua im Schlepptau und ermöglicht Zugriff auf die Variablen des Makers von außen.

    Der XP hat Ruby im Schlepptau und ermöglicht darüber Zugriff AUF DIE GESAMTE SPIELMECHANIK.

    Wenn ich als 2k/2k3 Nutzer nun da stehe und mich entscheiden müsste, komme ich nicht drum rum eine neue Sprache zu lernen. Lua oder Ruby. Und in dem vergleichsfall gewinnt klar Ruby da es in Verbindung mit dem XP mehr zu bieten hat.

    Die Eigenarbeit die ich investieren muss ist die gleiche, die Sprache lernen. Bloß habe ich beim XP wesentlich mehr davon und kann zugleich den alten 2k/2k3 Look noch weiter verwenden. Und falls sich mal ne Hürde aufbaut (wie z.B. das es keine FaceSets mehr gibt) bau ich mir das via Ruby ein.

    Der XP steht dem 2k/2k3 in nichts nach. Ausgenommen die Performance. Aber neue Technik braucht mehr Leistung. Niemand würde sagen: Unreal Tournament 2007 ist schlechter als Unreal 1 weil es mehr Leistung braucht! <_<

    In einem bestehendem Projekt nützt Cherrys Patch auch recht wenig. Denn ein Save/Load Menü nur auf Basis der Variablen auzfzubauen benötigt eine gewisse Vorbereitung welche sich im Falle von meinem Projekt nicht mehr nachträglich integrieren ließe.

    Geändert von Caine Luveno (22.10.2007 um 18:41 Uhr)

  14. #14
    Zitat Zitat
    Das mit der Tradition ist für mich aber ein ziemlich stichhaltiges Argument, muss ich sagen - ich persönlich will nicht auf XP umsteigen weil ich die knuffigen 24x32-Pixel-Charas so toll find ^^ Die auf dem XP sind so irgendwie nicht Fisch, nicht Fleisch - nicht hochauflösend und auch nicht mehr Retro...
    Halte ich für völligen Blödsinn. Retro kommt doch nicht davon das man eine 320x240 Auflösung hat. Das doppelt davon radiert noch kein Retro aus.
    Zudem die Pixelchars auch nicht knuffig aussehen müssen. Das ist eine Sache des Designs. Nicht des XPs. Wiederum hat es nichts mit "Tradition" zutun, das man Retro an ein paar grafischen Eigenschaften festmacht.

    Zitat Zitat
    @Topic: Ich versteh trotz allem für und wider immer noch nicht ganz, warum ihr Cherry's Arbeit so skeptisch gegenübersteht - ich mein, schließlich will er dafür sorgen, dass das Altbekannte in Zukunft mehr kann als jetzt, ein (wie ich finde) sehr löbliches Unterfangen, das wir eigentlich alle unterstützen sollten, anstatt es zu kritisieren...
    Da ich wie schon erwähnt nicht auf Wiederholungen stehe, verweise ich für diese Frage mal auf die Posts im Topic. Die beantworten diesen Punkt ausreichend, denke ich.

    Zitat Zitat
    Nochmal wegen dem Auto-Vergleich. Ich hab mir vor einigen Wochen das "3D-Game-Studio 7", eine nicht ganz billige, professionelle Entwicklungsumgebung für dreidimensionale Spiele mit allem drum und dran gekauft - einen "Ferrari" sozusagen. Und trotzdem wär's mir lieber gewesen, wenn der gute alte RPG-Maker endlich mal in die dritte Dimension gewechselt wär (Gerüchte kursieren schon lang, aber ich hab noch nie was Konkretes gesehen). Ich sitz manchmal vor der mir bis dato unbekannten Programmiersprache und wünsch mir sehnlichst eine Command-List wie im Maker herbei... Jeder der schonmal eine Programmiersprache von Grund auf selber lernen musste, kennt das Problem garantiert. Ich hab jetzt also meinen Ferrari - und fahr nebenbei trotzdem weiter Trabi. Hätt absolut nix dagegen einzuwenden, wenn der gute alte Trabi ein paar neue Tricks spendiert bekäme...
    Hast du denn wirklich erwartet das der Einstieg mit einem Tool wie dem 3D-Gamestudio einfach wird? Es ist schon klar das bei einer Programmiersprache ganz andere Dimensionen auf einen zukommen. Und ich muss dir sagen, ich habe eine Programmiersprache mit Freuden gelernt. Einfach weil es mein Interessengebiet ist. Ein Hobby. Wenn du dieses Hobby nicht hast, dann schaff dir keine Tools an die genau das benötigen würden.
    In dem Fall ist der Trabbi ideal für dich. Und zwar mit seinen gegebenen Funktionen. Und wie man wunderbar rauslesen kann, wirst du dann auch mit LUA nicht viel anfangen können. Auch wenn es eine Skriptsprache ist, heisst es noch lange nicht das dabei keinerlei Arbeit auf dich zukommt um es zu lernen.

    Wo genau liegt also nun der Unterschied WO du die neuen Sachen lernen musst? Ruby ist übrigens auch eine Skriptsprache. Und hat keinen enormen Lernaufwand, wie ich finde. Es ist und bleibt wie es ist. Und leider muss ich mich nun doch wiederholen. Wer mehr haben will, der muss auch bereit sein ein wenig Mühe zu investieren. Und davor wird dich auch Cherrys Patch nicht bewahren. Wenn du ihn nutzen willst, dann musst du die LUA beherrschen lernen. Und damit stehst du dann vor genau demselben Problem wie beim Gamestudio. Kein Rumgeklicke - nicht das was dir gefällt.

    Zu deinem Glück scheint er ja ein Klickinterface für ein paar Features einzubauen. Das wird dir die teilweise Nutzung des Patches ermöglichen. Jedoch sind wir auch hier wieder an dem Punkt das die Leute das ganze wohl wenig nutzen werden. Gründe hierfür wurden auch schon genug genannt.

    Im Allgemeinen ist die Diskussion ab einer gewissen Stelle überflüssig. Diese Aussagen hier sind Prognosen. Mehr nicht. Wer den Patch nutzen will, der wird es tun. Jedoch wirst du damit leben müssen das einige objektiv den Nutzen dieser Erweiterung ermitteln wollen. Und dann halt zu diesem Ergebnis kommen.

  15. #15
    Zitat Zitat von makenshi Beitrag anzeigen
    Hast du denn wirklich erwartet das der Einstieg mit einem Tool wie dem 3D-Gamestudio einfach wird? Es ist schon klar das bei einer Programmiersprache ganz andere Dimensionen auf einen zukommen. Und ich muss dir sagen, ich habe eine Programmiersprache mit Freuden gelernt. Einfach weil es mein Interessengebiet ist. Ein Hobby. Wenn du dieses Hobby nicht hast, dann schaff dir keine Tools an die genau das benötigen würden.
    In dem Fall ist der Trabbi ideal für dich. Und zwar mit seinen gegebenen Funktionen. Und wie man wunderbar rauslesen kann, wirst du dann auch mit LUA nicht viel anfangen können. Auch wenn es eine Skriptsprache ist, heisst es noch lange nicht das dabei keinerlei Arbeit auf dich zukommt um es zu lernen.

    Wo genau liegt also nun der Unterschied WO du die neuen Sachen lernen musst? Ruby ist übrigens auch eine Skriptsprache. Und hat keinen enormen Lernaufwand, wie ich finde. Es ist und bleibt wie es ist. Und leider muss ich mich nun doch wiederholen. Wer mehr haben will, der muss auch bereit sein ein wenig Mühe zu investieren. Und davor wird dich auch Cherrys Patch nicht bewahren. Wenn du ihn nutzen willst, dann musst du die LUA beherrschen lernen. Und damit stehst du dann vor genau demselben Problem wie beim Gamestudio. Kein Rumgeklicke - nicht das was dir gefällt.
    Also damit haste mich als leidenschaftlichen Programmierer echt tief getroffen, das muss man dir lassen. Ich kann einiges in Delphi, HTML und auch Ruby, C-Skript (die Sprache vom GameStudio) hab ich soweit auch schon ganz gut drauf. Was mich an Ruby so stört sind die ständigen Kürzel, die den Code unlesbar machen. Warum braucht man 30 Varianten um zu schreiben "Zähle a und b zusammen". Außerdem gibt's in Ruby unheimlich viel vordefiniertes Zeug, da will der erste Durchblick erstmal gefunden werden. Außerdem steht man (wenn man sich nicht anderweitig zu helfen weiß) im RMXP bei Ruby ohne jegliche Unterstützung da, von den paar Kommentaren mal abgesehen. WENN Enterbrain schon eine in Europa kaum gebräuchliche Sprache einführt, sollten sie eigentlich auch ein paar Tutorials dazulegen... Na, lassen wir das...

    By the way... wer sagt denn eigentlich, dass ich auf LUA so scharf bin? Ist ein netter Zusatz, mehr nicht. ABER: Bei den 200 Pic-IDs ist das schon gaaaaanz was anderes, findet ihr nicht? Vor allem für die Erstellung von Kampfsystem-HUDs äußerst hilfreich. Was der Patch sonst noch kann schau ich mir an wenn's soweit ist...



    Greetings!


    Alan

  16. #16
    ...wobei gesagt werden muss, dass die 200 Pics auch nur was für Faule sind. Man kann nämlich per Skript Bilder bearbeiten, vereinen, ausschnieden, Filter anwenden, etc. Somit sind ganz tolle Kampfübergänge und ähnliches möglich. Weiters wird ein komplettes Textsystem enthalten sein, was quasi die Standard-Messagebox ersetzt und eine Reihe weitere Features enthält (so ungefähr wie das AMS beim XP). Die 200 Pics sind natürlich auch gewissermaßen ein "Anreiz", den Patch zu verwenden. Da dafür eigentlich keine Skriptarbeit von Nöten ist - einen Helden "ShowPic(0, "mypic.png", 160, 120, 100)" nennen kann doch nicht so schwer sein (man muss halt vorher den Maker auf längere Heldennamen patchen, aber das wird alles erklärt).

    Btw - das Speicher-/Lademenü war eigentlich gar nicht als Hauptfeature gedacht. Es wurde nur irgendwie zu einem Schlagwort, da sowas vollkommen neu ist (afaik). Eigentlich war das Speichern/Laden von Variablen eher dafür gedacht, freispielbare Sachen einzubauen, die dann bei "New Game" auch verfügbar sind. Oder die Variablen dann mit einem anderen Programm zu verarbeiten, falls nötig.

    mfG Cherry

  17. #17
    Zitat Zitat
    Also damit haste mich als leidenschaftlichen Programmierer echt tief getroffen, das muss man dir lassen. Ich kann einiges in Delphi, HTML und auch Ruby, C-Skript (die Sprache vom GameStudio) hab ich soweit auch schon ganz gut drauf. Was mich an Ruby so stört sind die ständigen Kürzel, die den Code unlesbar machen. Warum braucht man 30 Varianten um zu schreiben "Zähle a und b zusammen". Außerdem gibt's in Ruby unheimlich viel vordefiniertes Zeug, da will der erste Durchblick erstmal gefunden werden. Außerdem steht man (wenn man sich nicht anderweitig zu helfen weiß) im RMXP bei Ruby ohne jegliche Unterstützung da, von den paar Kommentaren mal abgesehen. WENN Enterbrain schon eine in Europa kaum gebräuchliche Sprache einführt, sollten sie eigentlich auch ein paar Tutorials dazulegen... Na, lassen wir das...
    Kürzel sind eine große Erleichterung. Sie mach das Listing simpel kürzer.
    A = A + 1; ist viel länger als A++; (wäre Java Syntax). Genau wie
    A = A + 20; viel länger ist als A+=20;

    Wie du so etwas als angeblicher leidenschaftlicher Programmierer nicht mögen kannst, wundert mich doch sehr. Magst du lange unübersichtliche Listings?

    Das "vordefinierte Zeug" soll dann wohl die Methoden und Klassen sein die per RGSS mitliegen. Diese nehmen übrigens Komplexität heraus und erlauben eine wunderbare Kommunikation mit dem XP per Ruby. In der englischen Hilfe steht das ganze auch passabel beschrieben bei. Ansonsten -> Kai oder Magor haben mir persönlich noch nie eine Hilfestellung versagt. Und das sind ja nicht die einzigen zwei.

    Zu dem Thema Unterstützung: Es gibt ja wohl mehr als genug Rubytutorials im Internet. Zudem hat die Community schon stellenweise recht hochwertige Tutorials dafür produziert. Beim 2k/2k3 lagen immerhin auch keine Tutorials dabei. Da beschwert sich lustigerweise niemand. Übrigens das ironisch ist, je mehr Leute sich mit Ruby + XP beschäftigen würden, desto mehr Tutorials würde es geben. Es würde zumindestens die Wahrscheinlichkeit dazu anheben.
    Das Gesabbel das man Ruby eigentlich auch ohne Kentnisse über dieses im XP nutzen kann, schenke ich mir mal. Wird ohnehin ignoriert.

    Zitat Zitat
    By the way... wer sagt denn eigentlich, dass ich auf LUA so scharf bin? Ist ein netter Zusatz, mehr nicht. ABER: Bei den 200 Pic-IDs ist das schon gaaaaanz was anderes, findet ihr nicht? Vor allem für die Erstellung von Kampfsystem-HUDs äußerst hilfreich. Was der Patch sonst noch kann schau ich mir an wenn's soweit ist...
    Du weisst aber schon wie er die 200 BildIDs realisieren will? Anscheinend wird dieser "Trick" dazu führen das sich mehrere Bilder die Farbtiefe teilen müssen.
    Wie das mit der Zeit aussieht, kannst du dir ausmalen. Wobei er das sicher noch anders regeln wird. Wäre ansonsten eventuell recht kritisch anzusehen.

    Aber mal nebenbei: Wer zum Henker braucht mehr als 50 Bilder? Ich arbeite momentan mit 40 an einem recht umfangreichen KS. Und ja, Corti ist recht anspruchsvoll was das ganze angeht. Mit einer entsprechenden Liste über die Verwaltung der eigenen BildIDs kann man damit wunderbar haushalten. Man muss sich nur einmal sinnvoll überlegen wann diese zu belegen sind. Und wann dies eben vermeidbar ist. Solche Aspekte machen übrigens ganz nebenbei einen Reiz vom makern aus. Zumindestens für mich. Alles in allem kann man schon fast behaupten das es eher schlecht ist wenn man so dermaßen viele Bilder braucht. Immerhin bremsen diese schon ganz gut aus. Ist also an sich nicht so sinnig wie es auf den ersten Gedanken klingt.

  18. #18
    Zitat Zitat von makenshi Beitrag anzeigen
    Alles in allem kann man schon fast behaupten das es eher schlecht ist wenn man so dermaßen viele Bilder braucht. Immerhin bremsen diese schon ganz gut aus. Ist also an sich nicht so sinnig wie es auf den ersten Gedanken klingt.
    ... sagst du, wo du doch selbst ein Verfechter von Ruby bist ^^ Und genau das ist für mich einer der Hauptgründe, warum ich den XP nicht mag - Ruby nimmt die ganzen Tüftlereien mit den Standard-Skript-Befehlen vollkommen raus. Wer was komplexeres als ein eigenes Menü will (naja, manchmal wird sogar DAS nicht mehr per Skriptbefehlen gemacht) greift sofort zu Ruby... Dabei mochte ich doch die Knobeleien so gerne, das Umdenken, wenn man plötzlich keine Arrays mehr und Pointer nur eingeschränkt zur Verfügung hat.

    Wieso ich mehr als 50 Pic-IDs brauche? Ich könnt's dir vorrechnen, aber ich sag als Schlagwort nur "Zahlenanzeige"...

    Nochmal wegen den Kürzeln. Nein, natürlich gefällt's mir nicht, wenn die Listings unübersichtlich werden, aber wer seinen Code ordentlich mit Einrücken und Zeilenumbrüchen formatiert, wird auch mit den ausführlicheren Varianten keine Probleme haben. Und der Ober-Wahnsinnn ist sowieso die Kurzform für das "if" in Ruby, einen kompletten Bedingungsblock in eine Zeile zu quetschen, also sowas... Da stehen dem Delphi-Programmierer doch die Haare zu Berge, der weiterhin schreibt:

    if (x = 1) //naja, irgend sowas eben, nur als Beispiel ^^
    --then
    --{mach irgendwas}
    --else
    --{mach irgendwas}

    Außerdem erscheinen mir die Vergleichs-Operatoren in Ruby ein wenig seltsam. Für "nicht gleich" verwendet man "!=". Warum nicht "<>" wie in so vielen anderen Sprachen auch? Und warum in aller Welt musste man als Zuweisungsoperator (!) das "=" verwenden... zugegben, ist in manchen anderen Sprachen auch so, aber wer Delphi gewohnt ist, schreibt trotzdem brav ":=" als Zuweisungsoperator und wundert sich dann, warum es nicht funktioniert XD



    Also irgendwie... bin ich jetzt voll im Off-Topic gelandet... sorry, soll nicht wieder vorkommen...


    Greetings!



    Alan

  19. #19
    Zitat Zitat
    ... sagst du, wo du doch selbst ein Verfechter von Ruby bist ^^ Und genau das ist für mich einer der Hauptgründe, warum ich den XP nicht mag - Ruby nimmt die ganzen Tüftlereien mit den Standard-Skript-Befehlen vollkommen raus. Wer was komplexeres als ein eigenes Menü will (naja, manchmal wird sogar DAS nicht mehr per Skriptbefehlen gemacht) greift sofort zu Ruby... Dabei mochte ich doch die Knobeleien so gerne, das Umdenken, wenn man plötzlich keine Arrays mehr und Pointer nur eingeschränkt zur Verfügung hat.
    Du, ich bin ein "Javamensch". :) Mit Ruby hab ich sonst nicht viel am Hut. Das einzige was ich hier Verfechte sind Tatsachen. Und wie schon geschrieben, ist das von dir geschriebene eigentlich der einzige Grund warum ich mit dem Maker "arbeite". Ich mag es mit diesen primitiven Mitteln komplexe Dinge aufzulegen. Für ein komplettes Spiel jedoch bedeutet das sehr viel Aufwand. Deswegen ist es in meinen Augen falsch zu sagen: "Ah, die Rubyleute kämen ohne ihr Ruby nicht klar." Immerhin ist Ruby im XP eine Errungenschaft. Jedoch nichts was man nutzen muss. Auf Sicht eines langen Projektes ist Ruby sehr vorteilhaft. Wer es jedoch unbedingt mit Eventbefehlen probieren möchte, was genau hindert diesen Menschen daran? Es gibt für mich da kein echtes Argument was irgendwelche "Qualitäten" offenlegt.

    PS: Arrays kann man sich selbst im Maker bauen. :)

    Zitat Zitat
    Wieso ich mehr als 50 Pic-IDs brauche? Ich könnt's dir vorrechnen, aber ich sag als Schlagwort nur "Zahlenanzeige"...
    Jetzt sprichst du grad gegen deine eigene Überzeugung.
    Du sagst in deinem vorherigen Abschnitt das du die Beschränkungen
    des Makers magst. Nun willst du eine umgehen weil du anscheinend so
    geplant hast, das der Maker damit nicht fertig wird?
    Und wo genau liegt nun der Unterschied ob du deine Möglichkeiten mit
    Ruby oder mit dem Patch erweiterst? Als "leidenschaftlicher Programmierer"
    müsstest du doch eher durch Programmierung zu gewinnen sein?
    Denn Programmierung betreibt man im Maker keineswegs.

    Es gibt übrigens auch noch Events. Nicht jede Anzeige muss vom User jederzeit einsehbar sein. Durch Kombibilder kann man Bilder sparen. Es ist in meinen Augen simpel eine Verschwendung noch mehr Bilder zu verwenden.
    Davon abgesehen, will ich mal sehen will was passiert wenn sich deine Anzeigen 8 Bit an Farbauswahl teilen müssen.

    Zitat Zitat
    Nochmal wegen den Kürzeln. Nein, natürlich gefällt's mir nicht, wenn die Listings unübersichtlich werden, aber wer seinen Code ordentlich mit Einrücken und Zeilenumbrüchen formatiert, wird auch mit den ausführlicheren Varianten keine Probleme haben. Und der Ober-Wahnsinnn ist sowieso die Kurzform für das "if" in Ruby, einen kompletten Bedingungsblock in eine Zeile zu quetschen, also sowas... Da stehen dem Delphi-Programmierer doch die Haare zu Berge, der weiterhin schreibt:

    if (x = 1) //naja, irgend sowas eben, nur als Beispiel ^^
    --then
    --{mach irgendwas}
    --else
    --{mach irgendwas}

    Außerdem erscheinen mir die Vergleichs-Operatoren in Ruby ein wenig seltsam. Für "nicht gleich" verwendet man "!=". Warum nicht "<>" wie in so vielen anderen Sprachen auch? Und warum in aller Welt musste man als Zuweisungsoperator (!) das "=" verwenden... zugegben, ist in manchen anderen Sprachen auch so, aber wer Delphi gewohnt ist, schreibt trotzdem brav ":=" als Zuweisungsoperator und wundert sich dann, warum es nicht funktioniert XD
    Ganz ehrlich? Das sind doch wirklich Lapalien.
    Man kann sich doch als logisch denkender Mensch merken
    das != ein Ungleichoperator ist? So abwegig ist der Gedanke
    kein Stück. Die Zeichenkombination offenbart dies schon.
    Im Allgemeinen ist das was du da aufzählst nichts weltbewegendes.
    Wer sich ein wenig mit Ruby beschäftigt, wird diese Syntax verinnerlichen.
    Und diese paar Änderungen wird man ebenfalls mit der Zeit intus haben.

    Da ich das ganze beruflich machen möchte, werde ich mich wohl auch
    häufiger an neue Sprachen gewöhnen müssen. Auch wenn du es nicht
    beruflich machen willst, sehe ich keinen Grund warum du dir diese paar
    Syntaxschreibweisen nicht aneignen könntest. Zumindestens gibt es
    dafür keinen rationalen Grund.



    Zitat Zitat
    Es gibt noch mehr Fälle,bei denen mehr als 50 Pics vonnöten sind.Ich habe nämlich für ein RPG ein Menü in Planung,das nur auf Pics basiert.Und da komme ich wegen den Heldenwerten einfach nicht unter 50 Pics.
    Ein komplettes Menü auf Bildern aufzubauen ist -tschuldige- Blödsinn.
    Du ignorierst damit völlig das du als Anzeigemittel auch Panoramen,Events und das Chipset selbst hast. In diesem Zusammenhang kannst du nicht behaupten das du mehr Bilder bräuchtest. Du brauchst eher mal eine sorgfältige Planung die sich mit dem Thema anständig auseinandersetzt.

    Geändert von makenshi (23.10.2007 um 09:27 Uhr)

  20. #20
    Boa, das ist ein Grund um mein laufendes Projekt kurz anzuhalten...

    @ Cherry edit:

    Absolut geil, ich hab mit diesem Patch schon ein bischen rumm hantiert und frage dich nun, ob ich deine Einwilligung habe ein Spiel zu machen. Wenn alles glatt läuft wird ein DOMP ONLINE erscheinen. Ich werkle grad mit einem Kumpel daran eine spielbare Netzwerk / Internet - verbindung her zu stellen. Ich würde mich wirklich für eine Einwilligung freuen und ein spezieller Credit Eintrag wäre sicher...

    Geändert von ThePico!!! (25.10.2007 um 23:28 Uhr)

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •