Archiv verlassen und diese Seite im Standarddesign anzeigen : Script für ein AKS mit mehreren Partymitgliedern
Mr.Funkymaus
04.04.2009, 20:41
'N Abend Community =)
Ich wollte mal fragen, ob einer ein Script für ein AKS hat mit mehreren Partymitgliedern. und wenn nicht... kann mir einer dies erklären, wie ich so etwas einbauen könnte? Ich würd emich echt mega freuen.
Vll etwas genauer... ein Partymitglied soll ein Magier werden, der einen Zauber startet, wenn der Gegner nurnoch 2 Felder von ihm entfernt ist. Wie würde denn so etwas klappen?
Ich würde mich mega auf eine antwort freuen =)
Nochn schönen Abend
Kyle~
noch ein niemand
05.04.2009, 11:33
Sry, dasss das keine Mega Antwort ist, aber Fakt ist:
-Ein solches Skript gibt es nicht, ich weiß nicht einmal ob es das in einem Spiel gibt
-Niemand(nicht ich) wird sagen:,,Ich verschwende jetzt mal meine Zeit mit einem Giga Script, dass ich nicht brauche"
-Die Lösung ist also selber machen
Aber da ich heute so nett bin und nicht weiß wie es um deine Fähigkeiten steht:
Du musst die X und Y Koordinaten des Gegners und des Magiers festlegen.Die Variable Operation
machst du dabei auf This-Event und ganz wichtig nicht in ein Common Event sondern in das Gegner bzw. das Magier Event.Dann kommt die Überprüfung in einem Common Event.Dabei musst du einfach nur abfragen ob der Magier 2x,-2x, 2y oder -2y entfernt ist dann Startest du die Attacke.Erstelle jetzt ein Picture (Magisch halt) das du auf den x/y Koordinaten (Wichtig Screen-Relative) machst und dann mit Move Picture auf den Gegner fliegen lässt.
Jetzt machst du einen Switch für getroffen im Monster der dem Monster ein Leben abzieht denn machst du wieder weg, das Common Event würde ich nach einer kurzen Pause wieder starten lassen.
Ich hoffe du bist damit zufrieden.Hast du noch fragen, dann stell sie in diesem Thread.
mfg, der perfekte
Supermike
05.04.2009, 13:46
Hat da jemand nicht überall gesucht?
-Ein solches Skript gibt es nicht, ich weiß nicht einmal ob es das in einem Spiel gibt
Da ganz unten, unter SOM, es ist von Lachsen (http://rpg2000.4players.de/index.php?inhalt=Scripts2&limit1=150&seite=11&order=name&direction=ASC)
-Niemand(nicht ich) wird sagen:,,Ich verschwende jetzt mal meine Zeit mit einem Giga Script, dass ich nicht brauche"
Ich würde eher sagen, SEHR SEHR VIELE würden sagen das sie das nicht können! Oder zumindest dann an der umsetzung scheitern.
Also werden dir hier SEHR SEHR VIELE nicht sagen können wie es geht.
Und die die's können sagens trotzdem nicht weil es halt zu kompliziert ist.
Da es von Lachsen ist sagt es schon alles...
Es ist extremst kompliziert. Und wenn du schon fragst wie man eine simple KI scriptet in der ein Event auf eine Distanz reagiert, dann kann ich nur sagen: Finger weg! Ernsthaft! Das KS ist toll, ja! Aber deine Partymitglieder brauchen alle eine eingermassen intelligente KI, die nebenbei noch viel mehr kann und viel kompliziertere Dinge tun sollen, als auf eine Distanz zu reagieren. Wenn die KI monoton (oder verständlich gesagt: zu einfach bzw simpel) ist sind sie entweder dumm, weil sie ständig weglaufen oder dumm weil sie sofort tot sind wenn der Gegner zu nahe kommt.
Glaub mir, ich hab mal einen ganzen Tag an einem AKS-Script von Lachsen gesessen nur um es zu verstehn... und ich hatte danach trotzdem keine ahnung wie es funktioniert.
Vll etwas genauer... ein Partymitglied soll ein Magier werden, der einen Zauber startet, wenn der Gegner nurnoch 2 Felder von ihm entfernt ist. Wie würde denn so etwas klappen?
Wenn du das selber hinkriegst kannst du ja versuchen, ein event in die richtung deines bewegenden helden zu steuern. Durch eine KI und nicht mit "step toward hero"!
Und dann versuch das mal mit einem partymitglied und dann kannst du dir mal das skript ansehen...
Ansonsten rate ich dir nach einer alternative zu suchen die deinem Können entspricht.
Da es von Lachsen ist sagt es schon alles...
Es ist extremst kompliziertDas ist nich das Problem. Ich hab schon einige Scripte von Lachsen anaysieren müssen. Das dämliche ist das er nicht kommentiert was er da macht. Das muss man sich alles selber ansehen jede einzelne Zeile, jeden Befehl, das ist nunmal sehr zeitaufwändig. Wieso zeigt jemand ein Script vor wenn er es nicht gescheit kommentiert? Das ist bescheuert hoch zehn. Gut gemacht Lachsen :A
Kapieren ist da eigentlich sehr leicht. Ich baue auf dieses KS auf und erweitere es auch um ein paar ecken aber es wäre definitiv schneller gegangen wenn da Comments gewesen wären. Ich bin dankbar für das KS aber da hat er echt nur halbe Arbeit gemacht.
Vll etwas genauer... ein Partymitglied soll ein Magier werden, der einen Zauber startet, wenn der Gegner nurnoch 2 Felder von ihm entfernt ist. Wie würde denn so etwas klappen?Der Gegner kann sehr wohl durch simples "step toward hero" kontrolliert werden, solange die map leer ist denn durch hindernisse geht das nicht. Ich glaub Lachsen hat das duch auch duch Face anpassung und vorwärts gehen geregelt und noch ein paar zufällige Bewegungen eingebaut ein wirkliches path finding fehlt ist aber nicht dringend notwendig, wenn du ein AKS macht musst die maps auch weitläufiger machen. DIe Abfrage ob der Gegner 2 Felder entfernt ist ist einfach. XY Koordinaten des Heros weniger die XY Koordinaten des Gegners. Dann musst du sie beide positiv ( mal -1) falls eines der beiden negativ ist. Wenn nun beide Variablen kleiner/gleich 2 sind, beide das ist wichtig, ist der Gegner näher als 2 Felder.
Setzt das im Maker Code um.
Ansonsten rate ich dir nach einer alternative zu suchen die deinem Können entspricht. Quatsch, an solchen Dingen wächst man. Es gebe heute keine guten Techniker wenn jeder gleich vor jeder noch so kleinen Herausforderung wegrennt.
Supermike
10.04.2009, 11:57
Das ist nich das Problem. Ich hab schon einige Scripte von Lachsen anaysieren müssen. Das dämliche ist das er nicht kommentiert was er da macht.
Erwartest du wirklich das jeder alles komentiert wofür er welchen Befehl benutzt? Was das Skript tut bzw was miteinberechnet wird steht in den Codezeilen. Und Lachsen war eh nie der Typ der allen und jedem erklärt wie ein hochkompliziertes Skript funktioniert, dass sowohl Distanzen als auch ladezeiten, angriffe, pathfindig etc rechnet.
Vielleicht hat er die Skripte auch nur gemacht weil andere es wollten und er wirklich nie vorhatte jedem das zu erklären?
Das muss man sich alles selber ansehen jede einzelne Zeile, jeden Befehl, das ist nunmal sehr zeitaufwändig.
Wenn du gut sein willst, ist das erste was du brauchst geduld.
Wieso zeigt jemand ein Script vor wenn er es nicht gescheit kommentiert? Das ist bescheuert hoch zehn. Gut gemacht Lachsen :A
Vielleicht hat er die Skripte auch nur gemacht weil andere es wollten und er wirklich nie vorhatte jedem das zu erklären?
Kapieren ist da eigentlich sehr leicht.
und über was hast du dich davor beschwert wenn es dann doch leicht zu kapieren sei?
Ich baue auf dieses KS auf und erweitere es auch um ein paar ecken[...]
Wie? Heisst das du nimmst dann doch das Skript und baust dann dein Spiel darin auf? Also... willst du es nur verstehen um es erweitern zu können?
[...] Setzt das im Maker Code um.
Stop! Erklär mir nochmal was ich umsetzen soll. ICh komm beim oberen Absatz grad nicht mit...
Quatsch, an solchen Dingen wächst man. Es gebe heute keine guten Techniker wenn jeder gleich vor jeder noch so kleinen Herausforderung wegrennt.
Klar wächst man ran. Aber nicht indem man als noob der grad den RM gekriegt hat nen Pathfinding skripten will ohne zu wissen wie und was man benötigt. Bevor du also DARAN wächst musst du erst ans wie und was herankommen. Step by step you know?
Das hat zwar mit dem Problem von Kyle nichtsz utun aber ich denke ich antworte einfach mal^^
(kein bock auf zitate lest einfach supermikes post)
Also ich benutze das script weil es einfacher ist auf was vorhandenes aufzubauen als was komplett neu zu machen, ich erweitere es weil es im Spiel an dem ich grad arbeite um einiges mehr können muss als das was es bereits kann.
Ich beschwere mich nur das wenn man ein script anbietet es zum guten Ton gehört Comments zu machen, das bedeutet nicht das er jeden befehl kommentieren muss sondern erklären was gerade geschieht sondern WAS geschieht die semantik des codes, denn Sinn. Comments in Scripts sind gebräuchlich und normal.
Also zum meinem Vorschlag wie er nachprüfen kann ob ein Gegner zwei Felder entfernt ist: Die Distanz Hero-Gegner in Variablen speichern, sie miteinnader subtrahieren, und nachprüfen ob beide variablen kleiner als 2 sind. Ganz einfach. Hoffe das löst dein Problem klye^^
Und ich sag immer "lieber überschätzen als unterschätzen" das ist mein Motto, klar Grenzen kennen ist wichtig aber trotzdem soll man niemals Angst haben sich an was großes ranzuwagen.
Supermike
10.04.2009, 12:29
Ich beschwere mich nur das wenn man ein script anbietet es zum guten Ton gehört Comments zu machen, das bedeutet nicht das er jeden befehl kommentieren muss sondern erklären was gerade geschieht sondern WAS geschieht die semantik des codes, denn Sinn. Comments in Scripts sind gebräuchlich und normal.
hm.. ja schon... :/
Aber bei lachsen wundert mich das weniger, da er auf der Homepage von Velsarbor (glaube ich zumindest) gerschrieben hat, dass man ihn bezüglich Technik nicht fragen soll ob er alles erklärt. Irgendwo ist seine Denkweise schon kompliziert :O
Ich habs mir auch schon angesehn und wenig kapiert. gerade mal so viel, dass ich zumindest einen Teil neu skripten konnte, welches man auch schon im Spiel betrachten kann.
Neu Skripten hatte, bei mir, lediglich den Zweck das ich noch weiss was ich geskriptet hab xD
Und ich sag immer "lieber überschätzen als unterschätzen" das ist mein Motto, klar Grenzen kennen ist wichtig aber trotzdem soll man niemals Angst haben sich an was großes ranzuwagen.
olol!
Dann hab ich dich diesbezüglich falsch verstanden xD
Erwartest du wirklich das jeder alles komentiert wofür er welchen Befehl benutzt?
In der echten Informatik ist die Dokumentation zeitaufwendiger als das eigentliche Programmieren, von daher...
Sobald es etwas komplizierter wird, braucht man ganz einfach Kommentare.
@Mivey: WIe wärs, wenn du Lachsen fragst, ob du das Ding mit Kommentaren versehen darfst und das dann in der Script-Section mit einer von dir kommentierten Version aktualisierst?
(für so ein Script wäre es schon fast sinnvoll, das Ding nicht als Makerspiel hochzuladen sondern als ein Diagram anhand dessen der Downloader das Ding selbst bastelt - was man eh muss wenn man jede Zeile Code verstehen will)
@Mivey: WIe wärs, wenn du Lachsen fragst, ob du das Ding mit Kommentaren versehen darfst und das dann in der Script-Section mit einer von dir kommentierten Version aktualisierst?
Klar kann ich machen, allerdings sind die meisten Kommentare momentan in einer ... sagen wir sprachlich unterentwickelten Form. Ich hab nur soviel geschrieben wie ich brauch das ich zu einem späteren Zeitpunkt wieder gleich weiter arbeiten kann.
Müsst also fast alle überarbeiten.
Ich schau mal ob das Lachsen passt und ich in nächster Zeit nichts zu tun hab.
(für so ein Script wäre es schon fast sinnvoll, das Ding nicht als Makerspiel hochzuladen sondern als ein Diagram anhand dessen der Downloader das Ding selbst bastelt - was man eh muss wenn man jede Zeile Code verstehen will)Dann würde aber Copy & Paste nicht mehr funktionieren, wär das wirklich schlau?
Ich erinner mich, das Lachsen mal gesagt hat: "Ihr könnt euch nehmen was ihr wollt, aber erklären tu ich es euch nicht"
der Maker Code ist auch nciht verdammt komplieziert,aber bei richtigen Programmiersprachen, ist -wie Dhan sagte- die Kommentierung echt wichtig. Ich hab selsbt ein Projekt herstellen müssen, mit kommentierung, Schaltplan der Methoden und Datendeklaration.
Ich erinner mich, das Lachsen mal gesagt hat: "Ihr könnt euch nehmen was ihr wollt, aber erklären tu ich es euch nicht"Das steht irgendwo in Vsb drin, aber für ein explizites Script macht der Part "keine Erklärung" absolut keinen Sinn. Das ganze ist schließlich nur dafür da das man es anderen erklärt.
Es ist nich der Code der kompliziert ist aber es ist schon sehr aufwändig das ohne Kommentare zu analysieren, würd schon Sinn machen.
makenshi
10.04.2009, 18:49
[...]der Maker Code ist auch nciht verdammt komplieziert,aber bei richtigen Programmiersprachen, ist -wie Dhan sagte- die Kommentierung echt wichtig.
"Echter Programmiersprachencode" ist auch nicht wirklich kompliziert. Sofern du die Sprache beherrschst. Doch genau so wie da sollte man auch im Maker entsprechende Codesegmente auskommentieren.
Wenn man an entsprechenden großem System wie einem KS arbeitet hilft das enorm. Einfach weil es eben dadurch sehr viel einfacher wird sich in der Code reinzudenken, wenn es wieder nötig wird.
Unkommentierter Code macht anständiges Arbeiten mit diesem auf die Dauer unmöglich.
Whitewolf
13.04.2009, 13:57
Als ich mir Lachsens Technik in VSb angeschaut habe, ist mir aufgefallen, dass er selbst für viele einfache Sachen,
die man eigentlich mit normalen Switches hätte regeln können, komplizierte Codes für skriptet hat, was das ganze
noch verwirrender macht -.-
Von daher sollte man sich das wirklich nicht zu gemühte führen,
die Codes zu verstehen ohne eine passende Erklärung, die wir laut
seiner Aussage ja nicht erhalten werden ...
Bist du dir sicher, dass der zusätzliche Code keinen Sinn hatte, beispielsweise indem er die Sache dynamischer macht und dafür sorgt, dass Lachsen Events nur kopieren muss wenn er eine Sache doppelt haben will oder nur an einer Stelle etwas ändern muss wenn er das gesamte System ändern will?
Zeig mal ein Beispiel, wo unnötiger Code ist (das soll kein "Lachsen ist Uber-Scripter"-Statement sein, mich interessiert tatsächlich, wie effizient Lachsens Code ist ^^)
(das soll kein "Lachsen ist Uber-Scripter"-Statement sein, mich interessiert tatsächlich, wie effizient Lachsens Code ist ^^)
Frag ihn doch^^
Also aus meinen Erfahrungen wo ich mir ein paar mal die Codes aus Vsb ansah um zu schauen wie er dieses oder jenes gemacht hat muss ich sagen das er einige Sachen verdammt genial regelt. Leider ein wenig kompliziert an einigen Ecken. Uneffizienz konnte ich nirgendwo entdecken habe aber auch nicht gezielt nach alternativen lösungen gesucht.
"Echter Programmiersprachencode" ist auch nicht wirklich kompliziert. Sofern du die Sprache beherrschst. Doch genau so wie da sollte man auch im Maker entsprechende Codesegmente auskommentieren.
Wenn man an entsprechenden großem System wie einem KS arbeitet hilft das enorm. Einfach weil es eben dadurch sehr viel einfacher wird sich in der Code reinzudenken, wenn es wieder nötig wird.
Unkommentierter Code macht anständiges Arbeiten mit diesem auf die Dauer unmöglich.
Ich weiß ich weiß^^ Ich sagte, OHne Kommentare wäre mein Englischhilfe-Programm für die Schule ziemlich undurchsichtig gworden (Ich musste mit dem Turbo Pascal 7.0 Compiler arbeiten, sprich DOS).
Als ich mir Lachsens Technik in VSb angeschaut habe, ist mir aufgefallen, dass er selbst für viele einfache Sachen,
die man eigentlich mit normalen Switches hätte regeln können, komplizierte Codes für skriptet hat, was das ganze
noch verwirrender macht -.-
Von daher sollte man sich das wirklich nicht zu gemühte führen,
die Codes zu verstehen ohne eine passende Erklärung, die wir laut
seiner Aussage ja nicht erhalten werden ...
Das beweise mir mal. Vllt bist du auch einfach noch nicht soweit um zu verstehen das man vllt Switches benutzen kann, aber du machst dafür einen langen Code, Lachsen (nicht nur er, viele andere auch ich machen das so) nutzt eben das von Dhan erwähnte dynamsiche programmieren. das hilft etwa wenn man sagt das jeder Held auf jeder Position stehen könnte und nicht nur, wie es bei viele Maker-RPG's standert ist, nach dem Muster:
Held 1=Hauptheld
Held 2=2.Figur dieim Spiel dazu kommt
Lachsen Programmierarbeit hat schon Sinn und Zweck und ich finde es gar nicht so kompliziert. Ich hab mich schon ausgiebig damit beschäftigt, weil ich wissen wollte warum er seinen Gegner etwa einen Attributwert von 777777 gibt usw. Lustigerweise war das kommentiert :D
Jab, ich glaube du bist einfach noch nicht wirklich dahinter gestiegen^^ Sry klingt für mich so.
Back to Topic:
Es geht hier im Thread ja um ein AKS mit mehreren Teilnehmern.
Das ist in Lachsens AKS nicht drin, muss du also hinzufügen.
Du hättest hier 3 Optionen, Kyle.
---------------------------------------------------------------------------------------
a ) Held Steuert einen Helden und die restlichen sind in Reserve ( wechsel möglich)
---------------------------------------------------------------------------------------
b) Held Steuert einen Helden und die anderen sind auch auf dem Feld werden aber durch eine KI gesteuert. Dies erfordert zusätzlich eine Menge Platz auf der Map da das, selbst wenn der Code funktioniert, sehr eng mit 4 sich auf ein Ziel zu bewegenden NPCs werden kann.
---------------------------------------------------------------------------------------
c) Der Held steuert keinen der NPC, sie agieren alle auf KI man kann aber diese KI einstellen und dadurch gewisse Strategien entwickeln. Ist halt weniger aufregend für den Spieler.
---------------------------------------------------------------------------------------
Am leichtesten ist natürlich a und daher empfehle ich es dir auch. Du müsstest bloß einstellen das einer der Helden immer gewählt ist (durch Variablen ganz einfach^^) und der kämpft dann.
nutzt eben das von Dhan erwähnte dynamsiche programmieren.
Uh Vorsicht mit Begriffschöpfung. An sich könnte man hier leicht sagen: Ist dynamisch und ist proggen, nennen wirs doch dynamisches Programmieren, aber ich will hier mal verhindern, dass sich das irgendwie einbürgert. Der Begriff "dynamisches Programmieren" hat in der Informatik nochmal eine andere Bedeutung, ist so gesehen reserviert.
Ist jetzt ein wenig klugscheißerisch, aber Metier ist Metier ^^
@Mivey: Versteh ich c) so richtig das nichtmal eine einzige Figur direkt vom Spieler gesteuert wird? Nee, das klingt nach doofem Gameplay.
@Kyle
Für ein AKS dürfte KI an sich garnicht so schwer sein, jedenfalls für jemanden, der generell ein AKS hinbekommt. Die SoM-KI ist jedenfalls recht simpel gehalten. Im Wesentlichen lässt sich sowas entwickeln, indem man als Entwickler selbst ein wenig im KS kämpft und dabei beobachtet, was man warum macht, wie man verhindert, getroffen zu werden und wie man möglichst geschickt trifft. Das sind meist nur einige wenige Tricks die sich eigentlich recht einfach übertragen lassen müssten. Einziges Problem ist hier die Unübersichtlichkeit des Variablenmanagements vom Maker (oh und natürlich, dass ein Raster-AKS nicht viel Möglichkeiten für Taktiken bietet)
An Verhalten wäre nicht verkehrt, die NPCs entweder das zu ihnen nächste Monster anzugreifen, das zur Spielerfigur nächste oder das Gefährlichste (machbar, wenn man die "Gefährlichkeit" einfach als Eigenschaftsvariable der Monster festsetzt, aber nur sinnvoll, wenn es Monster gibt, die aus der Ferne heftig attackieren, Bogenschützen oder Magier oder sowas die man mit einem Schlag unterbrechen kann
Sinnvoll zu wissen wäre dein technisches Können. Generell gilt halt, ein AKS muss man vollkommen verstehen und dementsprechend ist es sinnvoll, jeden Befehl selbst eingegeben zu haben wobei man sich bei einem fremden AKS Tricks abschauen kann, Code kopieren ist jedoch schlecht, wie gesagt, weiß man am Ende nicht, wozu was gut ist.
Und ich sag mal, wenn du erstmal ein AKS ohne Helfernpcs aufgestellt hast, sind die dann relativ leicht zu integrieren. Halt dir in der Monster-KI aber noch die Stelle offen, in der die Monster entscheiden, ob sie den Spielercharakter oder einen Helfer angreifen.
Uh Vorsicht mit Begriffschöpfung. An sich könnte man hier leicht sagen: Ist dynamisch und ist proggen, nennen wirs doch dynamisches Programmieren, aber ich will hier mal verhindern, dass sich das irgendwie einbürgert. Der Begriff "dynamisches Programmieren" hat in der Informatik nochmal eine andere Bedeutung, ist so gesehen reserviert.
Ist jetzt ein wenig klugscheißerisch, aber Metier ist Metier ^^
Stimmt du hast Recht, aber ich denke, du weißt was ich meinte, ich fnd auch jetzt keinen andere passenden Begriff, vllt wenn ich mein Studium anfang und endlich nur das mache, was ich kann.
Mathe-Info :>
@Mivey: Versteh ich c) so richtig das nichtmal eine einzige Figur direkt vom Spieler gesteuert wird? Nee, das klingt nach doofem Gameplay.Es ist dann kein Action KS mehr. Eher sowie das KS in FF12 oder das in DSA-Drakensang, kann sein das das doch anders in DSA war, weiß das nur aus dem Hören-sagen^^.
Der Faktor Aufregung und Spannung, den ein AKS ausmacht geht flöten ja das wär wohl nicht erwünscht, zumindest nicht wenn man ein AKS will. War nur so ein Vorschlag und eine aus meiner Sicht logische Erweiterung der Aufzählung. (Keine KI bei Helden nur Monstern danach alle außer "Hauptheld" mit KI und zuletzt alle mit KI, Monster und Helden)
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.
In der Demo von Dragonblade4 wird ein Aks mit mehreren Charaktern benutzt Das nehmen wo Angol steht (http://rubydragon.extra.hu/dragonblade/index.php?act=letoltes)
In der Demo von Dragonblade4 wird ein Aks mit mehreren Charaktern benutzt Das nehmen wo Angol steht (http://rubydragon.extra.hu/dragonblade/index.php?act=letoltes)
Igit, Französich Ungarisch
Edit: Egal ob ungarisch oder französisch oder taiwanesich, ich sprechs nicht also ist die bezeichnung "igit" korrekt
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:
Wieso zeigt jemand ein Script vor wenn er es nicht gescheit kommentiert? Das ist bescheuert hoch zehn. Gut gemacht Lachsen.
Sorry, dass ich nicht der soziale Community-Diener bin, für den du mich hälst :P
Ansonsten rate ich dir nach einer alternative zu suchen die deinem Können entspricht.
Quatsch, an solchen Dingen wächst man. Es gebe heute keine guten Techniker wenn jeder gleich vor jeder noch so kleinen Herausforderung wegrennt.
Es macht keinen Sinn sich durch Sachen zu quälen ohne Erfolge zu haben. So verliert man nur die Motivation.
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:
Als ich mir Lachsens Technik in VSb angeschaut habe, ist mir aufgefallen, dass er selbst für viele einfache Sachen,
die man eigentlich mit normalen Switches hätte regeln können, komplizierte Codes für skriptet hat, was das ganze
noch verwirrender macht -.-
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)
noch ein niemand
25.04.2009, 09:45
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.
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.
Nein, das war nur eine seiner Fragen, aber er bat auch um allgemeine Hilfe für ein AKS mit mehreren Teilnehmern.
Ich wollte mal fragen, ob einer ein Script für ein AKS hat mit mehreren Partymitgliedern. und wenn nicht... kann mir einer dies erklären, wie ich so etwas einbauen könnte?
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.
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...).
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?
makenshi
25.04.2009, 17:33
@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
Battlesystem bsys = new Battlesystem();
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. :)
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...
(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
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
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:
- SCRIPT -
<> Label: 7
<> Key Input Processing: Var. [1026], Keys: Decision
<> Fork Condition: If Variable [1026] >= 5 then ...
<> Comment: ==> CALL MENÜ
<> Call Event: Map Event #10005, Page #15
<>
: End of fork
<> Wait: 0,0 sec.
<> Change Variable: [991] += 1
<> Fork Condition: If Variable [991] >= 6 then ...
<>
: Else ...
<> Jump To Label: 7
<>
: End of fork
hier vergehen dann die 0,1 sec.
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^^
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).
Ah, ich verstehe^^ Nicht schlecht, zum Glück gibs bei mir nur Halbiert/Null/Doppel.
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. :D
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. ;) 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.
aso, ich wollt schon meinen XD
Aber ich muss sagen, ich fands ziemlich cool sowas zu machen :A
Bei PMOs habe ich das ja auch und muss sagen, das mich eingentlich nur der Item-Ordner angepisst hat.
Verdammt viel Fleißarbeit D:
makenshi
26.04.2009, 23:48
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. :D
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.
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.
Naja ganz unmöglich isses ja nicht...
Die Party läuft hinten ran und der näheste gegner wir anvisiert.
darauf hin teilt sich die party auf und jeder haut was rein. Spielen kann man da natürlich nur 1 Charakter aber gut aussehen tuts alle mal ^^
noch ein niemand
30.04.2009, 13:53
Kann sein das ich deinen Post falsch verstehe, aber das hört sich mehr so an, als würdest du Denken, das das umsetzen nicht der Knackpunkt ist.Das ist die Umsetzung ja eben.Dabei reihe ich mich ja auch eher in die Reihe der Leute ein, die Denken, dass es für Erfahrene nicht unmöglich ist
Ich weiß, was ich heute tun werde XDD
Ich guck mal, ob ich solch ein skript hinkriege, ist zwar sehr, sehr aufwendig (ich mach das am besten in einer spezifischen map), aber die herausforderung nehm ich an.
Solch ein Spiel wie Secret of Mana kann man mit dem RPG Maker vergessen. Aber ein AKS mit mehreren Partymitgliedern
ist möglich, man muss aber am besten ne map machen, wo nur maximal 4-5 gegner drin stehen. Beispiel:
Man ist in nem Dungeon, berührt nen Gegner und dann kommt man in einen Kampf, extra map.
Ich weiß, was ich heute tun werde XDD
Ich guck mal, ob ich solch ein skript hinkriege, ist zwar sehr, sehr aufwendig (ich mach das am besten in einer spezifischen map), aber die herausforderung nehm ich an.
Solch ein Spiel wie Secret of Mana kann man mit dem RPG Maker vergessen. Aber ein AKS mit mehreren Partymitgliedern
ist möglich, man muss aber am besten ne map machen, wo nur maximal 4-5 gegner drin stehen. Beispiel:
Man ist in nem Dungeon, berührt nen Gegner und dann kommt man in einen Kampf, extra map.
Dafür bräuchte man Pixelmovement aber das Script von lachsen zeigt sehr wohl das man auch so sehr nah ran kommen kann. Und der Script von Lachsen wäre (konjunktiv weil du ja noch keinen hast) deinem überlegen weil es nicht erfordert das man in eine extra map gehen muss leider muss man dafür selber einige Mapevents in CE umwandeln aber da alle von denen außer denen die Zahlenwerte anzeigen nicht unbedingt ME sein müssen geht das sehr wohl. Und abwechselnde Helden ist nicht sooo schwer solange immer nur einer kämpft.
Dafür bräuchte man Pixelmovement aber das Script von lachsen zeigt sehr wohl das man auch so sehr nah ran kommen kann. Und der Script von Lachsen wäre (konjunktiv weil du ja noch keinen hast) deinem überlegen weil es nicht erfordert das man in eine extra map gehen muss leider muss man dafür selber einige Mapevents in CE umwandeln aber da alle von denen außer denen die Zahlenwerte anzeigen nicht unbedingt ME sein müssen geht das sehr wohl. Und abwechselnde Helden ist nicht sooo schwer solange immer nur einer kämpft.
Warum bräuchte man denn bitte Pixelmovement? Pixelmovement mag etwas reißen, wenn du wirklich detaillierte Abfragen machen willst (trifft der Schlag den Gegner am Bein oder am Kopf?), aber so wäre es allenfalls ein nettes Feature - falsch umgesetzt allerdings eher ein riesiges Manko.
Warum bräuchte man denn bitte Pixelmovement? Pixelmovement mag etwas reißen, wenn du wirklich detaillierte Abfragen machen willst (trifft der Schlag den Gegner am Bein oder am Kopf?), aber so wäre es allenfalls ein nettes Feature - falsch umgesetzt allerdings eher ein riesiges Manko.
Die Frage war ja ob das KS auf SoM Niveau sein soll. Beim Maker (2k(3)) kann man nur die 16x16 Felder abfragen. Das reicht nicht aus.
EDIT:
Und durch komplexe Abfragen kann man es taktisch stark verbessern bzw. eine bessere Schadensberechnung mit Schadensbezogenen Effekten (schlag auf kopf ist stärker und senkt trefferquote des gegners (augen)) hinzufügen
Ich geb Mivey teilweise Recht, eine Pixelabfrage wäre 100% besser.
Ich hasse dieses "Vor dem Held"-Feld. Wenn sich ein Gegner genau im Moment des Schlages bewegt, wird er schon gar nicht mehr erfasst, das finde ich bei vielen Spielen schlecht :V
Ein Pixelabfrage ist viel genauer, auch wenn ich nicht unbedingt sagen würde, das man ein Pixelmovment bräuchte.
Das Problem ist:
Macht man eine Map voller Gegner, dann hätte man viel zu viel an KIs zu Skripten
Gegner1 X
Gegner1 Y
Gegner1 HP
......
Gegner20 BlahBlah
Das ist sehr schwierig, vor allem dann noch ne Pixelabfrage.
Ja, der Aufwand ist schon ziemlich groß.
Aber naja, man kann doch locker 500.000 Variable speichern. Sollte kein Problem sein, mit einem Pointersystem das über ein Map-Event gesteuert wird. So macht man eine Template-Map auf der die Maximale Anzahl an Gegner drauf ist oder sowas und kopiert/löscht das was man braucht/nicht braucht.
Warum bräuchte man denn bitte Pixelmovement? Pixelmovement mag etwas reißen, wenn du wirklich detaillierte Abfragen machen willst (trifft der Schlag den Gegner am Bein oder am Kopf?), aber so wäre es allenfalls ein nettes Feature - falsch umgesetzt allerdings eher ein riesiges Manko.
Fällt dir ein erfolgreiches Action-RPG auf dem Markt ein mit Rastermovement?
Ohne Pixelmovement macht das keinen Spass, die Möglichkeiten sind einfach zu stark eingeschränkt. Du kannst dich dem Gegner 16 Pixel nähern oder garnicht.
@Drakee: Dann machs wie in SoM und limitier die maximale Anzahl gleichzeitig anwesender Gegner auf 3. (prüfs nach, ist echt so, du wirst in SoM niemals mehr als 3 Gegner sehen)
Hybris 2nd Awakening hat afaik kein Pixelmovement und spielt sich trotzdem recht gut. Außerdem gibt es auf dem Maker ja auch kein erfolgreiches Action-RPG mit Pixelmovement.
Hybris 2nd Awakening hat afaik kein Pixelmovement und spielt sich trotzdem recht gut. Außerdem gibt es auf dem Maker ja auch kein erfolgreiches Action-RPG mit Pixelmovement. .
Ich denke das sich das auf dem alten Makern (2k(3)) auch nicht ändern wird.
Was nicht geht geht einfach nicht. Aber der XP gibt einem da sehr wohl die möglichkeit Pixelmovement und Abfrage einzubauen.
Und wenn sich jemand die Mühe gebe sowas einzubauen so würde vermutlich auch der Rest des Spieles zumindest aktzeptabel werden, einfach weil niemand sich in einem Bereich Mühe gibt aber auf den Rest scheißt. Das macht keinen Sinn. Sehr gut möglich also das in nächster Zeit ein "erfolgreiches Action-RPG mit Pixelmovement" erscheint.
tsstsstss
es geht sehrwohl pixelmovement mit dem 2k/2k3
nur, das ist aufwendig, wenn sogar noch aufwendiger als das mit dem aks mit mehreren partymembers.
es gibt doh auch schließlich jump'n runs für den rpg maker MIT Pixelmovement, wie z.B. Bones oder so.
makenshi
16.05.2009, 16:11
tsstsstss
es geht sehrwohl pixelmovement mit dem 2k/2k3
nur, das ist aufwendig, wenn sogar noch aufwendiger als das mit dem aks mit mehreren partymembers.
es gibt doh auch schließlich jump'n runs für den rpg maker MIT Pixelmovement, wie z.B. Bones oder so.
Wo wurden denn widersprochen das ein Pixelmovement umsetzbar ist?
Es ist simpel ineffizient.
tsstsstss
es geht sehrwohl pixelmovement mit dem 2k/2k3
nur, das ist aufwendig, wenn sogar noch aufwendiger als das mit dem aks mit mehreren partymembers.
es gibt doh auch schließlich jump'n runs für den rpg maker MIT Pixelmovement, wie z.B. Bones oder so.
Was soll ich sagen, der Maker wäre ohne Variablenbeschränkung turing-vollständig ^^
@Kelven: Humm ich werd mal bei Gelegenheit Hybris testen.
Was nicht geht geht einfach nicht.
da zum Beispiel wird widersprochen, dass Pixelmovement möglich ist... wenn auch VIELLEICHT indirekt
makenshi
17.05.2009, 12:50
da zum Beispiel wird widersprochen, dass Pixelmovement möglich ist... wenn auch VIELLEICHT indirekt
Was sich wohl eher auf die Sinnigkeit eines Pixelmovements für den 2k/2k3 bezogen als auf die Machbarkeit.
da zum Beispiel wird widersprochen, dass Pixelmovement möglich ist... wenn auch VIELLEICHT indirekt
Also ich hab mir Bones angeschaut und ich muss sagen beeindruckend aber wenn der XP benutzt hätte wäre der Arbeitsaufwand nur ein Bruchteil gewesen, davon bin ich überzeugt.
Vor allem hat Bones eine primitive KI und Schadensberechnung ein "echtes" Aks im Stile von SoM 2 zb braucht da um einiges mehr.
Aber Hut ab das sich Shadowsoul die Arbeit gemacht hat sowas mit dem Maker umzusetzen.
Powered by vBulletin® Version 4.2.3 Copyright ©2025 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.