wie FF 12? Hääääää? Kleiner Hinweiß, die Autofunktion ist eine Zusatzfunktion, die man zum Grinden nutzen kann, sollte man aber in richtigen Bossbattles lieber lassen.
wie FF 12? Hääääää? Kleiner Hinweiß, die Autofunktion ist eine Zusatzfunktion, die man zum Grinden nutzen kann, sollte man aber in richtigen Bossbattles lieber lassen.
--
Ich sagte doch das ich das nur aus dem Hörensagen weiß.^^ Ich hab gehört das das da funktioniert, mehr nicht. Ich hab das betreffend nur Halbwissen, das hab ich aber auch gesagt.Zitat
Geändert von Mivey (18.04.2009 um 13:27 Uhr)
In der Demo von Dragonblade4 wird ein Aks mit mehreren Charaktern benutzt Das nehmen wo Angol steht
Igit,
FranzösichUngarisch
Edit: Egal ob ungarisch oder französisch oder taiwanesich, ich sprechs nicht also ist die bezeichnung "igit" korrekt
Geändert von Mivey (19.04.2009 um 13:57 Uhr)
Nein ungarisch xD muss ja niemand verstehen, wollte nur zeigen das es sowas gibt. Zudem ist die Demo auf englisch
Hui, hier wird viel über mich gelabert.
Also muss ich mal was dazu schreiben xD
(Im Moment verbringe ich irgendwie zuviel Zeit im Forum...)
Zu meinem "uralten" Aktion-KS:
Zunächst einmal: Das KS erfüllt nicht einmal die hier angesprochenen Anforderungen. Es gibt nur einen spielbaren Charakter. Das System lässt sich auch nicht ohne weiteres mit mehreren Charakteren umsetzen. Genauer gesagt wäre das äußerst kompliziert.
Dann: Das KS ist uralt und entsprechend schwach ist der Code. Ich kannte den Maker seit ca. 2 Jahren, als ich mit den Kram gemacht habe und hatte keine Erfahrung vom Programmieren. Also was raus kam: schrecklich redundanter und chaotischer Code. Ich hab nur meine Art trotz all dem Chaos immer etwas zustande zu bekommen, was funktioniert. So hat das auch bei TA geklappt (und an GSandSDS meinen Respekt, dass er damit klar kommt und mein Beileid, dass er damit arbeiten muss..). Aber genau wegen diesem Ansatz würde ich das Skript zum direkten Umsetzen wirklich niemanden empfehlen. Das Skript ist nur für folgende Sachen gut: Es zeigt was mit dem RPG-Maker 2000 möglich war (bzw. ist), ist für technisch bewandte Leute etwas zum reinschauen und abgucken für verschiedene Techniken (Abstand zum Gegner messen, Kollision mit Pixel Coordinaten etc.) und schließlich das wichtigste: ich kann damit angeben. :P
Das Skript ist wirklich nicht als Tutorial für Anfänger gedacht und hat genau deshalb auch wenig/keine Kommentare.
Damals kam ich sowieso nie auf die Idee mal Kommentare zu schreiben, aber zu Kommentaren komme ich jetzt als nächstes.
Zu Kommentaren im Code:
Also ja. Kommentare sind im allgemeinen sehr wichtig. Da ist kein Unterschied zwischen richtigen Programmiersprachen und RPG-Maker Skript Code. Das Problem ist, dass man sie meistens aus bequemlichkeit weg lässt (selbst erfahrene Programmierer, je nachdem, wie sie eingestellt sind - ich denke da nur an eine Masterarbeit von einer gewissen Person, bei der ich mitwirkte. Da wurden allerhöchstens Codezeilen auskommentiert und das war es auch schon.)
Kommentare sind vorallem dann wichtig, wenn mehrere Leute den Code verstehen sollen. Wenn man wiederum alleine daran arbeitet... Ich persönliche hatte nie groß Probleme damit meinen Code zu verstehen, selbst wenn er wenig Kommentare hat. Natürlich dauert es etwas länger, wenn man lange nicht mehr damit gearbeitet hat, aber finde mich dennoch recht schnell damit zurecht. Das ist bei einigen Leuten vielleicht anders. Das gilt übrigens nur wenn es MEIN Code ist. Der Code anderer Leute ist für mich ohne Kommentare auch sehr schwer zu verstehen. Und damit meine ich nicht, dass mein Code besser ist, oder sonst etwas. Er ist einfach nur von mir gekommen und damit leichter wieder in meinen Kopf zurück zu kriegen.
Kommentare sind in der Hinsicht eigentlich genauso wie ein gutes Code Design: Sie machen die Sache übersichtlich und sind absolut notwendig für große Projekte.
... Dann wiederum schluckt beides viel Zeit. Und das Velsarbor KS ist nicht klein und dennoch ein reines Chaos und ich kam recht weit damit. Zwischendurch habe ich wegen der Uni wirklich ordentlich Programmieren müssen (bei Sprachen wie Java wird deine Denkweise praktisch mit aller Gewalt in diese Richtung gedrängt, mit 5.000 Klassen, Unterkassen, Interfaces, für maximalen Code Reuse und 20 Codezeilen für simpelste Operationen)... und es dauert einfach LÄNGER. Ich habe mehrmals damit angefangen ordentlich mit Sprachen wie C++ und Javascript Spiele zu programmieren. Ich sitze Wochen dran, grübel über ein gutes Design und krieg die paar ersten Grundfunktionen der Engine hin.
Auf dem RPG-Maker 2000 krieg ich mit der ekligen gehackten Variante in 3 Wochen ein Duell Kampfsystem mit 3 Partymigliedern + simples Jump'n Run Skript + recht aufwändiges Interface hin. Komplett Funktionstüchtig und fast fehlerfrei.
Aus diesem Grund muss ich an diese ordentliche Programmierrangehensweise stellenweise doch etwas zweifeln.
Und ja, beim RPG-Maker hacke ich noch heute. Meiner Ansicht nach ist wirklich schöner Code beim RPG-Maker fast nicht möglich und ironischerweise äußerst ineffizient was Performance angeht, wenn man nicht aufpasst. Ich hab nämlich schon ein paar Mal versucht ordentlich mit dem RPG-Maker zu skripten. Und bisher waren das immer meine misslungenen Projekte (weil es zu langsam lief).
Wie auch immer. Ich denke spätestens wenn man bei der Technik im Team arbeitet hat man kaum eine andere Wahl, als es schön und ordentlich zu machen.
Und noch so als Schlussstrich zu Kommentaren:
Streng genommen hat der RPG-Maker mehr Kommentare nötig als Programmiersprachen. Bei Programmiersprachen hast du bereits Funktionen und eventuell Klassen, die dein Programm bei anständiger Benennung bereits mit einer guten Struktur versehen. Beim RPG-Maker hast du das nicht (ja gut, Common Events, aber du bist wegen der fixen Anzahl dazu gedrängt die sparsamer zu verwenden. Viele Common Events sind ironischerweise auch ineffizient. Ja, kein Scherz.). Darüber hinaus sind viele Sachen bei Programmiersprachen viel kompakter zu schreiben. Solche arithmetischen Rechnungen sind beim RPG-Maker praktisch wie in Assembler, wenn nicht noch schlimmer.
So und dann geh ich noch auf verschiedenes ein:
@Mivey:
Sorry, dass ich nicht der soziale Community-Diener bin, für den du mich hälst :P
Es macht keinen Sinn sich durch Sachen zu quälen ohne Erfolge zu haben. So verliert man nur die Motivation.Quatsch, an solchen Dingen wächst man. Es gebe heute keine guten Techniker wenn jeder gleich vor jeder noch so kleinen Herausforderung wegrennt.
Ansonsten: Wenn du das Skript mit Kommentaren versehen willst: nur zu. Ich will nur nochmal daran erinnern, dass die allgemeine Struktur von dem Skript wirklich keine gute Vorlage ist...
@Mirkwood:
Ich verwende nicht Variablen anstatt Switches um Leute aktiv zu verwirren. Ich verwende Variablen, weil sie einfach besser unterstützt werden im RPG-Maker. Mein liebstes Beispiel ist das gleichsetzen zweier Switches/Variablen.
Switch:
if(b1)
b2 = true;
else
b2 = false;
Variable:
v2 = v1;
Es geht meines Wissens wirklich nicht einfacher. Darüber hinaus kann man in Variablen mehr Werte abspeichern und eine Variable ist weitaus praktischer als mehrere Switches, wenn beides den Zweck erfüllt.
Aber ganz ehrlich: Ich code nicht absichtlich kompliziert um Leute zu verwirren. Ich Code nur so, wie es für mich am praktischsten erscheint. (natürlich liege ich nicht immer richtig). Und ich erkläre den Code auch nicht deshalb, weil ich nicht will, das Leute meine Technik verstehen. Ich tu es nur deshalb nicht, weil es so sehr, sehr viel Zeit in Anspruch nimmt.
Zum Schluss nochmal etwas zum eigentlichen Thema:
Früher war ich immer der Meinung, dass ein AKS mit mehreren Party Mitgliedern vergleichbar mit SoM sehr schwer bis unmöglich ist.
Streng genommen ist es möglich, aber es ist nach wie vor sehr kompliziert.
Bei Kampfsystemen mit einem Charakter kann man sich Sachen sehr stark vereinfachen, indem man Move Event Befehle wie "Normal Face Hero" und "Move Toward Hero" verwendet. All das kann man nicht mehr gebrauchen, wenn man mehrere Helden aufeinmal hat. Jetzt müssen sich Gegner für ein Ziel entscheiden und das anvisieren und zulaufen zum Charakter muss manuell berechnet werden, mit Coordinaten vergleich und If-Abfragen. Das verlängert den Code allgemein und macht die Sache sehr kompliziert, wenn man es nicht klever strukturiert. Ich persönlich habe schon eine Art KS versucht, bei der man nur zwei Charaktere hat. Das war praktisch mein erstes KS, wo ich eine wirklich ordentliche Code Struktur versucht habe, mit der man so komplexe Berechnungen sogar handhaben konnte. Das Resultat: Es war zu langsam.
Man löst beim richtigen Programmieren solche Algorithmen meistens so, dass man einen Zyklus hat, über den alles läuft. Man erstellt einen Algorithmus, der für alle Kampfteilnehmer verwendet wird (sowohl Gegner als auch Helden). Man kopiert Variablen Werte oder verwendet Variable-Indices um den Code flexibel zu halten. Das wesentliche Problem ist aber: Dieser Grundliegende Algorithmus MUSS für jeden Kampfteilnehmer hintereinander durchlaufen werden und das ziemlich schnell hintereinander. Und hier kommt der Knackpunkt: Das durchwandern von langem Code ist OVERHEAD beim RPG-Maker 2000. Nicht zu vernachlässigender Overhead. D.h. wenn man es damit übertreibt, wird das Spiel stocken.
Wenn man dann wiederum nicht mit so einer Struktur arbeitet, ist man dazu gezwungen viel Code zu duplizieren, den man dafür Parallel ausführen kann, was das Projekt schwer zu verwalten macht (genau das, was ich bei meinem alten AKS habe...).
Was ich damit sagen will: Wahrscheinlich ist ein Party Aktion-Kampfsystem wie in Secret of Mana möglich (vorallem wenn die KI entsprechend simple gehalten ist), aber es ist technisch sehr aufwändig und ich würde es wirklich niemanden empfehlen, der dazu eine Frage in einem Forum stellt.
Ansonsten schließ ich mich mal Mivey an: Ein Aktion Kampfsystem bei dem man die Charaktere auswechseln kann, halte ich am ehesten für Umsetzbar.
Soviel von meiner Seite.
C ya
Lachsen
PS: Alle Aussagen zum RPG-Maker beziehen sich nur auf dem RPG-Maker 2000. Bei dem XP / VX sieht das ganze wahrscheinlich nochmal anders aus. (hier hat man immerhin eine anständige Skriptsprache)
Ist hier eigentlich schonmal jemanden aufgefallen, das der Threadersteller gar kein kompliziertes Skript mit Pathfinding und co. braucht?Er will doch einfach nur das ein Zauberer hinter dem Helden herläuft und den Gegner mit Magie angreift.Und das ist imo sehr leicht umzusetzen.
--Mein Projekt:
Pokemon World:?%
,,Niemand ist perfekt.Ich bin Niemand!"
Nein, das war nur eine seiner Fragen, aber er bat auch um allgemeine Hilfe für ein AKS mit mehreren Teilnehmern.
Und dafür braucht man wenn es so funktionieren soll wie zb. in SoM doch ein kompliziertes Script, Lachsen hat das ja genauer erklärt.
Hierzu möchte ich mal etwas loswerden. im Moment arbeite ich ja an einem neuen KS in Phönix Memories of Shadow. Dieses ist ein Aktives KS, was eigentlich mindestens 6 PP-events allein für die Teilnehmer haben müsste.
Lustigerweise funzt aber alles und ruckeln mit 80-90 Bildern gleichzeitg und einem einzigen Wait von 0,1 sec. Ich denke mal, dass das mein Schutz vor dem Lagg ist XD
Der Trick ist einfach alle wichtigen Berechnungen hintereinander ablaufen zu lassen, ja sogar die Menüabfrage (Push Enter to open the Menu) ist in dieser einen Eventseite drin. Durch Cherry weiß ich ja nun, wie es zum laggen durch Bilder kommen kann und umgehe das einfach. So brauch ich mir auch keine Sorgen darüber zu machen, das ein PP-Overhead auftreten könnte.
HAst du das nicht auch in Felslabor so gemacht o-o° Ich kenne ja deine Speedrechnung aber du verwendest da irgendwo auch sowas. Und ich betone nochmal, ich finde deinen Code gar nicht so schlimm, ich muss nur oft nachsehen aus welche Vari nun der Pointer zeigt D:
(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 ,_,)
@Noch ein Niemand
Ja, ist aber ein wenig.... meeeeeh~ Mich würde es etwas verwirren wenn auf einmal ein Zauber abgepfeffert wird. Ich nehme nämlich nicht an, das der Ersteller schon daran gedacht hat, dass er auc hdieses Figur irgendwie in Aktion bringen muss, auch die muss entscheiden über Angriff usw.
Miveys Idee ist schon ganz gut, Hatte das nicht Itaju genau so gemacht?
--
@Lachsen
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.
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...
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
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
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.
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.
Ja, es ist grausam D: Aber lustigerweise habe ich in PMOS einen Grund ein CE-PP^^
--
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.
@Kelven
Entschuldige meine Verwunderung, aber WHAAAAT?
Ein Menü besteht doch im Maker nur aus:
-Enter password
-If/Then-Abfrage
Zumindest wenn man andere Schnickschnack wie Statusanzeige oder so mal vergisst^^
--
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.
aso, ich wollt schon meinen XD
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:
--
Ich sprach auch nicht die Blüten der OO an.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 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.
--
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.
"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.
Berechtigungen
Zitieren
