Eigenes Kampfsystem: Unterschied zwischen den Versionen
| Zeile 1: | Zeile 1: | ||
'''Eigene Kampfsysteme''' in [[RPG Maker|RPG-Maker]]-[[Spieledatenbank von A bis Z|Spielen]] sind schon etwa genau so lang ein Thema für [[:Kategorie:Entwickler/-in|Entwickler]] wie der [[RPG Maker 2000]] existiert. In selbigem sowie dessen [[RPG Maker 2003|Nachfolger]] werden sie häufig in Form einer oder mehrerer [[Mapping|Maps]] gefertigt und sind bei dieser Umsetzung von ähnlich kritischen Problemen und Umständlichkeiten wie [[Eigenes Menü|eigene Menüs]] geplagt. Nur selten sind eigene Kampfsysteme in der [[RPG_RT.exe|RPG_RT-Engine]] so aufgebaut, dass ihre Kämpfe dynamisch auf jeder Map stattfinden können. Seit dem [[RPG Maker XP]] besteht in der Reihe eine weitaus elegantere Möglichkeit der Umsetzung, die durch Änderungen am [[Ruby]]-, oder seit [[RPG Maker MV|RPGMV]] [[JavaScript]]-Code vorgenommen wird und nicht mehr auf [[Event]]s angewiesen ist. | '''Eigene Kampfsysteme''' in [[RPG Maker|RPG-Maker]]-[[Spieledatenbank von A bis Z|Spielen]] sind schon etwa genau so lang ein Thema für [[:Kategorie:Entwickler/-in|Entwickler]] wie der [[RPG Maker 2000]] existiert. In selbigem sowie dessen [[RPG Maker 2003|Nachfolger]] werden sie häufig in Form einer oder mehrerer [[Mapping|Maps]] gefertigt und sind bei dieser Umsetzung von ähnlich kritischen Problemen und Umständlichkeiten wie [[Eigenes Menü|eigene Menüs]] geplagt. Nur selten sind eigene Kampfsysteme in der [[RPG_RT.exe|RPG_RT-Engine]] so aufgebaut, dass ihre Kämpfe dynamisch auf jeder Map stattfinden können. Seit dem [[RPG Maker XP]] besteht in der Reihe eine weitaus elegantere Möglichkeit der Umsetzung, die durch Änderungen am [[Ruby]]-, oder seit [[RPG Maker MV|RPGMV]] [[JavaScript]]-Code vorgenommen wird und nicht mehr auf [[Event]]s angewiesen ist. | ||
| − | Ein Ansporn, selbst ein Kampfsystem zu erstellen, ist häufig, dass eine ''andere Kameraperspektive'' gewünscht wird, als sie vom Standard vorgegeben wird, seltener auch, dass bestimmte Features sonst kaum oder gar nicht umzusetzen | + | Ein Ansporn, selbst ein Kampfsystem zu erstellen, ist häufig, dass eine ''andere Kameraperspektive'' gewünscht wird, als sie vom Standard vorgegeben wird, seltener auch, dass bestimmte Features sonst kaum oder gar nicht umzusetzen sind. |
| + | |||
| + | Für einige Jahre waren eigene Kampfsysteme primär ein Selbstzweck - ein Spiel enthielt ein eigenes Kampfsystem hauptsächlich damit es ein eigenes Kampfsystem hatte. Viele dieser Kreationen waren dem [[Standard-Kampfsystem (2000)|Standard]] in jedem Punkt unterlegen und waren in vielen Fällen so rudimentär umgesetzt, dass eigentlich kein objektiver Grund für deren Einsatz sprach. Für längere Zeit herrschte in weiten Teilen der Maker-Szene jedoch der Aberglaube, jedes Projekt in dieser Engine müsse ohne Wenn und Aber ein ''eigenes KS'' aufweisen, um interessant genug für Spieler zu sein. | ||
''Unterlegene Kampfsysteme'' zeichnen sich meist durch sperrige Bedienung, sehr langsame oder gar nicht animierte Optik, unbequeme Funktionseinschränkungen, wie etwa nur sehr wenige, bzw ''einen'' Gegner oder unübersichtliche Menüs, oder eine Dichte an Bugs aus, die dem [[Standard-Kampfsystem (2003)|RPG2003-Standard-KS]] Konkurrenz macht. | ''Unterlegene Kampfsysteme'' zeichnen sich meist durch sperrige Bedienung, sehr langsame oder gar nicht animierte Optik, unbequeme Funktionseinschränkungen, wie etwa nur sehr wenige, bzw ''einen'' Gegner oder unübersichtliche Menüs, oder eine Dichte an Bugs aus, die dem [[Standard-Kampfsystem (2003)|RPG2003-Standard-KS]] Konkurrenz macht. | ||
Version vom 30. Januar 2021, 01:45 Uhr
Eigene Kampfsysteme in RPG-Maker-Spielen sind schon etwa genau so lang ein Thema für Entwickler wie der RPG Maker 2000 existiert. In selbigem sowie dessen Nachfolger werden sie häufig in Form einer oder mehrerer Maps gefertigt und sind bei dieser Umsetzung von ähnlich kritischen Problemen und Umständlichkeiten wie eigene Menüs geplagt. Nur selten sind eigene Kampfsysteme in der RPG_RT-Engine so aufgebaut, dass ihre Kämpfe dynamisch auf jeder Map stattfinden können. Seit dem RPG Maker XP besteht in der Reihe eine weitaus elegantere Möglichkeit der Umsetzung, die durch Änderungen am Ruby-, oder seit RPGMV JavaScript-Code vorgenommen wird und nicht mehr auf Events angewiesen ist.
Ein Ansporn, selbst ein Kampfsystem zu erstellen, ist häufig, dass eine andere Kameraperspektive gewünscht wird, als sie vom Standard vorgegeben wird, seltener auch, dass bestimmte Features sonst kaum oder gar nicht umzusetzen sind.
Für einige Jahre waren eigene Kampfsysteme primär ein Selbstzweck - ein Spiel enthielt ein eigenes Kampfsystem hauptsächlich damit es ein eigenes Kampfsystem hatte. Viele dieser Kreationen waren dem Standard in jedem Punkt unterlegen und waren in vielen Fällen so rudimentär umgesetzt, dass eigentlich kein objektiver Grund für deren Einsatz sprach. Für längere Zeit herrschte in weiten Teilen der Maker-Szene jedoch der Aberglaube, jedes Projekt in dieser Engine müsse ohne Wenn und Aber ein eigenes KS aufweisen, um interessant genug für Spieler zu sein.
Unterlegene Kampfsysteme zeichnen sich meist durch sperrige Bedienung, sehr langsame oder gar nicht animierte Optik, unbequeme Funktionseinschränkungen, wie etwa nur sehr wenige, bzw einen Gegner oder unübersichtliche Menüs, oder eine Dichte an Bugs aus, die dem RPG2003-Standard-KS Konkurrenz macht.
Auch häufig als "Kampfsystem" bezeichnet, jedoch keinen systematischen Aufbau ihr Eigen nennend, sind die meisten sogenannten "Action-Kampfsysteme" (direkteres, aktives Bekämpfen von Gegnern in Echtzeit) in vielen RPG2000-/-2003-Spielen (theoretisch auch auf neueren Versionen, je nach Arbeitsweise), da sie einen besonders großen Anteil an Hardcoding aufweisen und z.B. jedem Exemplar gleicher Gegner auf's Neue zuweisen, wie sie sich verhalten und wie sie bekämpft werden können.
