Der Umstieg auf andere Maker

[Zakkie]

Wenn du wüsstest in wievielen Makergames ich bisher dieses wunderschöne 1:1-kopierte Actionkampfsystem von Lachsen mit 1:1 demselben Eventcode und lediglich leicht bis gar nicht abgeänderter Grafik-HUD vorgefunden hab...^^ von 100%ig übernommenen Hinterherlaufskripten etc. pp mal ganz abgesehen. Ich finds ja rein grundsätzlich nicht mal falsch sich an Tutorials zu orientieren, andererseits macht dieses Zusammenkopieren null Sinn, wenn man die Technik dahinter nicht versteht und den ganzen Kram dann 1:1 übernehmen muss. Am Ende kommt n Spiel bei raus, welches auf vorgefertigten Funktionalitäten basiert und kein eigens erstelltes Gameplay enthält. Muss nix schlechtes sein, aber die Chance ist hoch.

...

Ich würde mal glatt behaupten, dass das nur TechDemo Leute sind, die keine Ahnung von makern haben. Kommt vom Niveau her einem Yanfly oder Tankentai-KS nahe: Lad's runter, wechsel die Figuren aus und das war's. Genau das Gleiche spielt sich hier ab. Würde das aber nicht Contentklau nennen, sondern RPG-Maker Neulinge. Überraschenderweise noch immer weltweit beliebt, sogar mit Tankentai Ace - wo viele Starscripter schon von Day 1 an sagen, dass sie das Teil niemals supporten werden, weil es Gift für die Community ist.

[Cornix]

Wer kopiert bitteschön Events?

...

Selbst wenn man nicht event-code kopiert nimmt doch jeder dritte einen Community-Patch oder eine der zahlreichen inoffiziellen Erweiterungen für den Maker.
Das ist nichts anderes als Ruby-Script zu kopieren.

Wenn du wüsstest in wievielen Makergames ich bisher dieses wunderschöne 1:1-kopierte Actionkampfsystem von Lachsen mit 1:1 demselben Eventcode und lediglich leicht bis gar nicht abgeänderter Grafik-HUD vorgefunden hab...^^ von 100%ig übernommenen Hinterherlaufskripten etc. pp mal ganz abgesehen. Ich finds ja rein grundsätzlich nicht mal falsch sich an Tutorials zu orientieren, andererseits macht dieses Zusammenkopieren null Sinn, wenn man die Technik dahinter nicht versteht und den ganzen Kram dann 1:1 übernehmen muss. Am Ende kommt n Spiel bei raus, welches auf vorgefertigten Funktionalitäten basiert und kein eigens erstelltes Gameplay enthält. Muss nix schlechtes sein, aber die Chance ist hoch.

...

Deshalb benutze ich auch kein Windows weil ich nicht weis wie ein Betriebssystem exakt funktioniert. Solange ich nicht in der Lage bin mein eigenes Betriebssystem zu programmieren macht es überhaupt keinen Sinn einen Computer überhaupt anzufassen.

Aber all diese nutzlosen Grundsatzdebatten außen vor gelassen denke ich kommen wir ein wenig vom Thema ab.

[TwoFace]

Deshalb benutze ich auch kein Windows weil ich nicht weis wie ein Betriebssystem exakt funktioniert. Solange ich nicht in der Lage bin mein eigenes Betriebssystem zu programmieren macht es überhaupt keinen Sinn einen Computer überhaupt anzufassen.

...

Seltsamer Vergleich. Ich rede davon, dass ein Spiele-Entwickler verstehen sollte, was er sich da zusammenbastelt und nicht nur stumpf kopieren sollte. Genauso sollte der Entwickler von Windows wohl verstehen wie man ein Betriebssystem programmiert. O.o

[Cornix]

Seltsamer Vergleich. Ich rede davon, dass ein Spiele-Entwickler verstehen sollte, was er sich da zusammenbastelt und nicht nur stumpf kopieren sollte. Genauso sollte der Entwickler von Windows wohl verstehen wie man ein Betriebssystem programmiert. O.o

...

Ich bezweifle stark dass jeder hier versteht wie der RPG-Maker funktioniert. Der Event-Code dahinter der irgendwie interpretiert werden muss um von dem Computer ausgeführt zu werden.
Man kann diese Kette ellenlang ziehen.
Ob man nun das eine Event-Script nicht versteht, oder ein Ruby-Script, oder wie Event-Code funktioniert, oder wie der Maker intern arbeitet, oder ein Computer intern arbeitet, und so weiter und so weiter.
Es gibt nur einen graduellen Unterschied dazwischen. Was wirklich zählt ist das Ergebnis. Der Entwickler will ein Ergebnis und verwendet dafür ein vorhandenes Werkzeug. Ob er komplett verstanden hat wie das Werkzeug seine Arbeit erledigt ist zweitrangig. Wichtig für seinen Erfolg ist lediglich ob er weis wie das Werkzeug zu bedienen ist.

Aber wie schon gesagt, das ist nicht Thema dieses Threads und sollte hier an dieser Stelle nicht weiter ausdiskutiert werden.

[Corti]

@Twoface und Cornix:
Programmieren besteht in erster Linie nur daraus APIs aufzurufen, die wenigsten sind heutzutage noch in der Lage jeden Schritt von ihrem API-Aufruf (zB eine Makereventzeile) bis zum Register auf dem Prozessor selbst komplett zu kennen und nachbauen zu können. Das ist auch nicht wichtig, es reicht oft die eigene Ebene zu beherrschen. Im Bezug auf den Maker wäre es, dass man nicht wissen muss was die Eventbefehle bitweise machen, es reicht zu wissen wie man sie anwendet.

Auf ein Kampfsystem im Maker bezogen muss man nicht wissen wie das Kampfsystem intern funktioniert. Ruby-Scripte für XP,VX,Ace ändern das halbe Kampfsystem und der Spielentwickler muss es nur als Script reinkopieren und sich in der Dokumentation/Hilfe durchlesen was z.B. für <Notes> etc. irgendwo reingeschrieben werden können um gewisse Funktionen zu nutzen. Das meiste bleibt gleich, Monstergruppen, Monster, Skills, Helden, etc. alles wie man es kennt.

Wenn man das Kampfsystem von Velsarbor kopiert sieht das sicherlich etwas anders aus. Ich bin mir fast sicher, das Ding ist nicht dafür designt als Komponente kopiert zu werden und es gibt sicherlich keine nutzerfreundlich dokumentierten und rausgeführten Einstellungen. Natürlich gibt es auch eine grafische Oberfläche in der man sich Inhalte zusammenklicken kann ohne verstehen zu müssen was in den Zwischenschritten passiert.
Wenn man mit so etwas arbeiten will kommt man schwer darum zu verstehen, wie das System funktioniert.

[Luthandorius2]

Wenn man mit so etwas arbeiten will kommt man schwer darum zu verstehen, wie das System funktioniert.

...

Ich denke der Satz ist eigentlich passend. Und ich halte einfaches Kopieren in den seltensten Fällen für brauchbar - ohne zumindest etwas anzupassen(und darunter verstehe ich dan schon "mit etwas arbeiten").. Es ist also schon hilfreich zu verstehen, was so passiert. Ich würde selber auch bei allem was ich mir von irgendwo her kopiere, möglichst versuchen zu verstehen, wie es funktioniert - um bei Bedarf Anpassungen vornehmen zu können oder vielleicht einfach nur undokumentierte Nebeneffekte besser nachvollziehen zu können und mich nicht zu wundern wieso plötzlich nach zig wild zusammenkopierten Skripts nix mehr läuft.

[Corti]

Nein, kopieren ist toll. Es gibt viele Sachen die dafür gemacht sind sie zu kopieren, da muss man nicht verstehen was "in der Box" passiert.

[AmigaMix]

Ich toleriere ja eigentlich das Kopieren von Scripts, da ich darin keinen Verlust für andere Sehe, doch was mir vor allem Kopfzerbrechen bereitet, ist die Tatsache, dass gerade Neulinge gerne blind Scripts kopieren um ihr Spiel "ganz toll" und "individuell" zu machen, dabei aber primäre Punkte außer Acht lassen.

[Corti]

Ist es nicht üblich sich erstmal auszutoben mit den Dingen die man so zu greifen kriegt? Es gibt viele Wege zu Erfahrung und Können.

[AmigaMix]

Ich sag mal: "learn by doing"
Wenn man dir alles vorkaut und so vor die Füße wirft... (ekelhafter Gedanke ) dann lernst du daraus leider nichts.

[Kelven]

Du kannst die Neulinge ja darauf hinweisen, dass sie etwas Wichtiges außer Acht gelassen haben. Vielleicht sehen sie das selbst ganz anders. Ich denke nicht, dass sie das Script einfach nur zum Protzen eingebaut haben, sondern weil es das Spiel bereichern soll. Wenn das manchmal etwas unbeholfen wirkt, dann liegt das an der fehlenden Erfahrung.

[AmigaMix]

Ich denke nicht, dass sie das Script einfach nur zum Protzen eingebaut haben, sondern weil es das Spiel bereichern soll.

...

Anders habe ich das auch nicht gemeint, falls du es so aufgefasst haben solltest. Aber ich denke, dass viele Scripts einfach verwendet werden, weil es sie gibt, nicht weil sie benötigt werden. Ich meine Spiele können auch ohne viel Schnick-Schnack funktionieren... Siehe UID, dieses Spiel wird zwar von einigen als veraltet bezeichnet, dem Stand dieses Spiels gleich zu kommen, schaffen jedoch nicht viele.