Man kann im Maker schon effizient und ordentlich arbeiten.
Eine große Hilfe ist dabei sind die Kommentare vom 2k3.
Die erste Zeile ist grün. Das macht es erst richtig übersichtlich auf die Dauer.
Besonders das künstliche Vergrößerung der Kommentare brachte mir da viele Wege den Code anständig auszukommentieren.
Ich finde vorallem wenn das KS RICHTIG groß wird und man mit großen Zeitabständen daran arbeitet, ist es unheimlich praktisch wenn man ne anständige Doku im Projekt hat. Das hat recht häufig dazu geführt das ich Code schneller verstehe. Als ich noch ohne das gearbeitet habe, wurde es eher ekelig. Dann musste ich mich erstmal wieder in die Codestruktur eindenken.
Zusätzlich dazu kann es helfen sich nen System auszudenken mit dem man seine Methode auskommentiert. Ich habe mir für so ein System simpel ein Template erstellt. Das nehme ich nun für neue CEs und gut ist.
Was ich z.B. Teil von so einem System sein kann: Variablennamen sinnvoll gestalten.
Pointer werden z.B. mit einem führenden P geschrieben. Variablen die Werte von Derefenzierungen enthalten mit einem führenden V. Das macht es schonmal einfacher das auseinanderzuhalten.
Was ich dir wohl kaum sagen brauche, ist das Objektorentierung bis zu einem gewissen Maß selbst im Maker möglich ist. Klar sowas wie
geht dort natürlich nicht. Aber die Denkweise klappt ja klasse. Man kann immerhin jedes CE als Objekt einer Klasse sehen. Quasi als statisches. So hat man leider keine Variablität mehr, jedoch ist die Denkweise von "Jedes Objekt beeinhaltet seine Daten und erfüllt seine nur ihm möglichen Aufgaben" wunderbar ausbaubar. Interne Klassen die nur von der Hauptklasse angesprochen werden sind so auch möglich. Man braucht ja nicht zwingend ein System was OO unterstützt um es sinnvoll einzusetzen.
Und bei der Perfomance vom Maker ist das ja immer so ein Ding. Am simpelsten lässt sich das denke ich lösen, indem man erwägt wo die PPs gebraucht werden. Ich habe stellenweise 10 PPs gleichzeitig laufen. Kein Problem an sich. Sie müssen ja zum Glück nicht immer aktiv sein. Und in ihnen sind dann meist Schleifen, die effizient formulierte Codesegmente wiederholen. So passt es dann immerhin. Oftmal baut man denke ich auch Code ein der nur einmal durchgeführt werden müsste. Wenn man mal genauer darüber nachdenkt. Anderer müsste nicht als PP laufen, er kann auch gecallt werden.
Alles in allem ist Codearchitektur im Maker ne eigene kleine Wissenschaft. Wie bei den großen Programmiersprachen an sich. Assembler ahoi.
Zitat
Durch Cherry weiß ich ja nun, wie es zum laggen durch Bilder kommen kann und umgehe das einfach.
...
Hm? Berichte mal wie es zum Lag durch Bilder kommen soll. Wäre mal interessant zu wissen ob es was neues ist.
Nun, ich hab Cherry mal gefragt wie es dazu kommt, die Antwort war:
-Viele Bilder oft hinterainander anzeigen lassen
-Viele Bilder mit Ripple
Das gilt vorallem bei PP's. Dehalb mach ich ja auch ein globales Event^^
Achja, CE's haben aber nen ziemlichen Nachteil imho.
Als Calls sind sie Ok, aber als PP...
Dort eher selten, denn stellt man den Switch auf auf OFF und später auf ON so beginnt das PP da wo es aufgehört hat D:
Man kann natürlich das PP auch immer laufen lassen, aber das ist imho eher weniger gut^^°
@R.D.
Genau das was du beschreibst hab ich wie gesagt auch probiert und wenn man es damit übertreibt, hat es zumindest bei mir stark zu stocken angefangen. Damit meine ich halt diese Code Struktur, bei der man alles über ein Event laufen lässt und damit alles hintereinander. Je nachdem wie man das ganze aufbaut hat man schnell sehr langen Code, weil man für eine bestimmte Stelle z.B. potentiell alle Möglichen Posen anzeigen kann, aber pro Durchlauf immer nur eine Pose angezeigt wird. Alle andere Abfragen werden übersprüngen und genau das wäre Overhead.
Nach meiner Erfahrung sind viele Parallel Events an sich effizienter als ein Event das alles macht und dafür riesige Mengen an Code in kürzester Zeit durchläuft. Man muss halt nur darauf achten, dass keines der Parallelen Events unnötige Arbeit macht.
Und da muss man gerade bei Show Picture aufpassen. Show Picture sollte man nur verwenden, wenn man es auch wirklich braucht. Ein parallel Event ohne Wartezeit und einem Show Picture in der Schleife lässt bei meinem Rechner das Spiel aufhängen. Entsprechend stark wird der Rechner belastet wenn du in kürzester Zeit wirklich viele Pictures anzeigt. Aber das hat so wie ich das abschätze nichts mit Parallel Events zu tun. Wenn du den gleichen Rechenaufwand auch in einem Event hast, sollte es genauso stocken.
Naja, ansonsten...
Zitat
(Btw, das mit deinem Attribut-Einfluss und den Zahlen 777778 oder so musst du mir mal erklären, da steig ich noch nicht hinter, warum du das so gemacht hast ,_,)
...
Das ist in der Regel die Resistenz. Ich speichere die Resistenz von einem Kampfteilnehmer gegenüber allen Attributsveränderungen in einer Variable. Da es genau 6 Attribute gibt, passt das halt genau. Jedes Zeichen ist eine Resistenz. 0 bedeutet immun, 9 ist äußerst empfindlich. Die Werte kann man mit / und Mod rausfiltern bei der eigentlichen Abfrage. Das habe ich in erster Linie gemacht, um Variablen zu sparen. Genau das selbe findest du bei Element Resistenzen, Zustand Resistenzen, Zustand Zeitstatus (da gehen auch maximal 9 Runden), Verzauberungen Resistenzen/ Zeitstatus usw. Da man bis zu 7 Kampfteilnehmer hat hab ich dadurch schon nen ganzen Batzen an Variablen gespart (Für die hier genannten wären das bereits 7*5*5 = 175 Variablen).
Und ja, das was du da bei Common Events anspricht nervt mich auch persönlich. Die sollten genauso wie Map Events einfach wieder von vorne beginnen, wenn man sie abwürgt. >_<
Nur wegen dem Mist habe ich auf jeder Map ein paar Map Events die nichts weiter tun als ein Call Event aufzurufen und in einer Schleife zu laufen. Nur damit ich die abbrechen kann und der Code wieder von vorne beginnt.
@Makenshi
Was Kommentare angeht hast du Recht. An sich mache ich heutzutage auch viel mehr Kommentare als früher und der Code ist schon besser lesbar damit.
Aber ansonsten:
Es ist schwer mit dem RPG-Maker ordentlich zu arbeiten. Problem sind hauptsächlich die Common Events und die Variablen: Diese haben eine fest Ordnung. Selbst wenn du dir ein gutes Namen-Schema überlegst, du brauchst auch eine gute Anordnung der Variablen und Common Events, damit es wirklich übersichtlich ist. Und dafür musst du schon sehr gut vorplanen, um genug Platz zu lassen, damit alles bis zum Ende seine richtige Ordnung hat. Ich versage an dem Punkt immer, ganz einfach weil ich zu wenig vorplane. Ab einem gewissen Punkt geb ich es immer auf und meine Variablen und Common Events sind dann im Endeffekt immer ein Durcheinander.
Was Objektorientierung angeht:
Wenn du behauptest sowas geht auch nur ansatzweise im Maker, kannst du auch das selbe zu Sprachen wie C sagen. Objektorientierung ist denke ich etwas mehr als das Strukturieren von Code. Du kannst in fast jeder Programmiersprache heutzutage Funktionen schreiben. Nehmen wir dazu noch einen globalen Array auf den man zugreifen darf und du hast im wesentlichen das, was der Maker kann. Aber das ist keine Objektorientierung. Bei Objektorientierung geht es darum, dass du Klassen in Form von Objekten instanziieren kannst, das du über die Objekte auf Funktionalität UND Daten zugreifen kannst. Dazu kommen noch Sachen wie vererbung usw. Der RPG-Maker hat nicht einmal einen local scope, d.h. du hast nichtmal anständige Funktionen. Der RPG-Maker ist was das alles angeht wirklich nur mit Assembler zu vergleichen und von Objektorientierung weit entfernt.
Es gibt btw. auch Diskussion darüber, ob Objektorientierung nun wirklich der beste Ansatz fürs Programmieren ist, das nur so nebenbei... Und so manchmal denke ich auch, dass es seine Nachteile hat...
Und wieder was Performance angeht:
Ich hatte selber lange Zeit die Einstellung man müsste Parallel Events möglichst vermeiden, weil viele Parallel Events das ganze verlangsamen. Aber man dann aber soweit geht, dass man alles in einem Event macht, obwohl das auszuführende an sich etwas paralleles ist (z.B. die Kampfanimationen von allen Kampfteilnehmern), kann das nach hinten los gehen. Das ist nur ne Erfahrung die ich mehrmals gemacht habe.
Genau das was du beschreibst hab ich wie gesagt auch probiert und wenn man es damit übertreibt, hat es zumindest bei mir stark zu stocken angefangen.
...
Ok, also vllt funzt es bei mir, weil ich einfach alles mit calls noch ausbaue, das erhöht vlllt die Wartezeit und allgemein, vermeide ich Bilder ja soweit bis man Enter drückt oder ein Teilnehmer eine Aktion ausführt.
kA wieso es funzt XD
Zitat
Damit meine ich halt diese Code Struktur, bei der man alles über ein Event laufen lässt und damit alles hintereinander. Je nachdem wie man das ganze aufbaut hat man schnell sehr langen Code, weil man für eine bestimmte Stelle z.B. potentiell alle Möglichen Posen anzeigen kann, aber pro Durchlauf immer nur eine Pose angezeigt wird. Alle andere Abfragen werden übersprüngen und genau das wäre Overhead.
...
Gut, das habe ich nun nicht, wie gesagt im Grund besteht es aus warten (also das KS) bis zur Aktion und wenn man Enter drückt, das Enter drücken sieht dann in etwa so aus:
hier vergehen dann die 0,1 sec.
Zitat
Nach meiner Erfahrung sind viele Parallel Events an sich effizienter als ein Event das alles macht und dafür riesige Mengen an Code in kürzester Zeit durchläuft. Man muss halt nur darauf achten, dass keines der Parallelen Events unnötige Arbeit macht.
Und da muss man gerade bei Show Picture aufpassen. Show Picture sollte man nur verwenden, wenn man es auch wirklich braucht. Ein parallel Event ohne Wartezeit und einem Show Picture in der Schleife lässt bei meinem Rechner das Spiel aufhängen. Entsprechend stark wird der Rechner belastet wenn du in kürzester Zeit wirklich viele Pictures anzeigt. Aber das hat so wie ich das abschätze nichts mit Parallel Events zu tun. Wenn du den gleichen Rechenaufwand auch in einem Event hast, sollte es genauso stocken.
...
Mh... Ich bin ganz ehrlich, Ich halte PP-events bei mir zumindest für nicht gut. Allein das ATB artige, würde mir wahrscheinlich meine Kontrolle entreißen. Ich hatte das schon mal bei meinem ersten KS... es war schrecklich D:
Bisher läuft es bei mir ja auch ganz gut. Ich rechne ja auch nur und wenn es halt zu einer Aktion kommt, das wird ja alles angehalten^^
Ah, ich verstehe^^ Nicht schlecht, zum Glück gibs bei mir nur Halbiert/Null/Doppel.
Zitat
Und ja, das was du da bei Common Events anspricht nervt mich auch persönlich. Die sollten genauso wie Map Events einfach wieder von vorne beginnen, wenn man sie abwürgt. >_<
Nur wegen dem Mist habe ich auf jeder Map ein paar Map Events die nichts weiter tun als ein Call Event aufzurufen und in einer Schleife zu laufen. Nur damit ich die abbrechen kann und der Code wieder von vorne beginnt.
...
Ja, es ist grausam D: Aber lustigerweise habe ich in PMOS einen Grund ein CE-PP^^
Es gibt btw. auch Diskussion darüber, ob Objektorientierung nun wirklich der beste Ansatz fürs Programmieren ist, das nur so nebenbei... Und so manchmal denke ich auch, dass es seine Nachteile hat...
...
Es gibt keinen besten Ansatz für Programmierung, jede Programmiertechnik hat seine Vor- und Nachteile und man sollte immer die Technik anwenden, die zur Lösung des aktuellen Problems am besten geeignet ist.
Die Nachteile der objektorientierten Programmierung wären etwa die schlechtere Performance (selbst vollkommen korrekt angewandt, impliziert OOP Zugriffe über Umwege, die allgemein, aber besonders bemerkbar im zeitkritischen Code zu Performanceverlusten führen) oder die Einführung von nebensächlicher Komplexität, wie etwa die "ist eine/hat eine"-Beziehung, ein für die Lösung des Problems unnötiger Ballast.
Die Vorteile wären dann beispielsweise die Wiederverwertung von Code, Reduzierung von Wechselwirkungen und Verbesserung der Lesbarkeit und Verständlichkeit, aber auch nur solange korrekt angewandt.
------------------------------------------------
OOP im Maker, ohne eine Sprache zur Verfügung zu haben, die das unterstützt ist echt witzig. Kapselung ist nicht möglich, von Vererbung und Polymorphie wollen wir gar nicht reden. Was bleibt, hat kaum mehr etwas mit OOP zu tun.
Ich weiß nur eines, als ich letztens wieder mal versucht habe ein Menü mit dem 2K3 zu scripten, ist mir nach kurzer Zeit schon so übel geworden, dass ich zum XP wechseln musste.
Ja, im Prinzip besteht ein Menü nur aus Eingabe und Ausgabe, aber es ist die Menge der Daten, die auf den alten Makern so Probleme macht. Ein Menü mit Bereichen für Statuswerte, Ausrüstung (inkl. Interaktion), Gegenständen, Techniken usw. ist sehr aufwändig. Natürlich ist es trivial, aber der Makercode macht es einem nicht gerade einfach.
Aber ich muss sagen, ich fands ziemlich cool sowas zu machen
Bei PMOs habe ich das ja auch und muss sagen, das mich eingentlich nur der Item-Ordner angepisst hat.
Verdammt viel Fleißarbeit D:
OOP im Maker, ohne eine Sprache zur Verfügung zu haben, die das unterstützt ist echt witzig. Kapselung ist nicht möglich, von Vererbung und Polymorphie wollen wir gar nicht reden. Was bleibt, hat kaum mehr etwas mit OOP zu tun.
...
Ich sprach auch nicht die Blüten der OO an. Die sind selbstredend im Maker nicht vorhanden. Vererbung und Kapselung wären sehr praktisch.
Ich sprach allerdings afaik nirgens davon das du im Maker objektorientierung vollständig ausüben kannst. Ich sprach eher davon das die Konstruktionprinzipien der OO übernehmen zu können. Anstelle das du Systeme baust die sich kreuz- und quer durch die Variablenliste pointern, lässt man Daten exklusiv in ihren CEs. Man lässt alles nach Möglichkeit für sich selbst eine Teilaufgabe erfüllen. Abgekapselt von dem restlichen System. Sowas in der Art war eher gemeint. Halt das Urgestein dessen.
Und Kapselung kann man btw. auch selbst konsequent ausführen. Da man am Maker selten mit anderen Leuten an der Technik arbeitet, besteht auch nicht die Gefahr eines Stilbruchs. Auch wenn Kapselung natürlich mehr bedeutet als Variablen auf privat zu schalten. Aber gut. Das geht dann wieder weeeeiiittt über den Maker hinaus.
Ich denke es sollte rüberkommen was ich ausdrücken will. Ich treff wohl nur nicht richtig den Punkt. Wenn man "am Objekt" erklären könnte was ich meine, dann würde es recht schnell einleuchten.
@Lachsen
Mir ist schon klar das OO nicht nur aus den Grundzügen seiner Architektur besteht. Das ist sonnenklar. Aber wie man oben liest war das auch nicht das was ich ansprechen wollte.
[...] Anstelle das du Systeme baust die sich kreuz- und quer durch die Variablenliste pointern, lässt man Daten exklusiv in ihren CEs. [...]
...
Ich verstehe nicht ganz wie du das implementieren willst, mit einem globalen Daten-Array. Die einzige Möglichkeit, die mir im Moment einleuchtet ist den Array in Blöcke aufzuteilen und vorzugeben, dass sie nur lokal aus den jeweiligen Teilprogrammen zugreifbar wären, aber das klingt immernoch nicht mal ansatzweise nach Objektorientierung. Das was du beschreibst würde ich eher mit prozeduraler Programmierung gleichsetzen, bei der es darum geht, das Programm so in Teilprogramme (Prozeduren) zu zerlegen, dass jeder Teil für sich ein eigenes Problem löst, unabhängig von den übrigen.
Objekte sind wirklich per Definition Instanzen von Klassen mit lokalen Daten (Attributen) und Funktionen, die auf diesen Daten arbeiten (Methoden), aber das weißt du wahrscheinlich eh schon.
Man könnte zwar Common Events als sehr vereinfachte Singletons betrachten, aber dann gibt es immernoch das Problem, dass Daten getrennt existieren. Common Events als Prozeduren zu betrachten, ergibt da schon viel mehr Sinn, so wie ich das sehe, wurden sie sogar für diesen Zweck implementiert.
---------------------------------------------
Übrigens: Dass Parallele Common Events beliebig zwischen Anweisungen gestoppt werden können und später fortgeführt, sieht mir sehr nach Fibers (oder auch Coroutines genannt) aus. Weiß da einer mehr? Richtig parallel können solche Common Events natürlich nicht sein, denn dafür bräuchte man hardwareseitiges Multithreading und ich bezweifle stark, dass diese Technik zumindest in den älteren Makern umgesetzt wurde.
Zitat von makenshi
Und Kapselung kann man btw. auch selbst konsequent ausführen. Da man am Maker selten mit anderen Leuten an der Technik arbeitet, besteht auch nicht die Gefahr eines Stilbruchs. Auch wenn Kapselung natürlich mehr bedeutet als Variablen auf privat zu schalten. Aber gut. Das geht dann wieder weeeeiiittt über den Maker hinaus.
...
"Stilbruch"? Darum geht es nun wirklich nicht beim Verstecken von Implementierungsdetails.
Aber naja, wahrscheinlich hast du dich nur falsch ausgedrückt und so wichtig ist dieser Begriff auch nicht in dieser Diskussion, da sowieso nicht unterstützt.
So hat man leider keine Variablität mehr, jedoch ist die Denkweise von "Jedes Objekt beeinhaltet seine Daten und erfüllt seine nur ihm möglichen Aufgaben" wunderbar ausbaubar. Interne Klassen die nur von der Hauptklasse angesprochen werden sind so auch möglich. Man braucht ja nicht zwingend ein System was OO unterstützt um es sinnvoll einzusetzen.
Zitat
Zitieren
