@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 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.

Soviel von meiner Seite

C ya

Lachsen