Könnte man es nicht eine "Create Game Disk" Funktion geben, diedas RE direkt mit installiert?
So müsste man nicht den Spieler darum bitten.
Wenn er das RE bereits hat, kann er die Installation des RE mit einem entfernen des Haken unterbinden.
Könnte man es nicht eine "Create Game Disk" Funktion geben, diedas RE direkt mit installiert?
So müsste man nicht den Spieler darum bitten.
Wenn er das RE bereits hat, kann er die Installation des RE mit einem entfernen des Haken unterbinden.
--
Also, grundsätzlich sage ich:
Wenn es ähnlich leicht zu bedienen ist und über genauso viele oder mehr Möglichkeiten als die aktuellen Maker (Scripts ausgenommen) verfügt, hätte ich definitiv Interesse.
Geld würde ich auch ausgeben, wie viel hinge aber natürlich vom Preisleistungsverhältnis ab.
Dann müsste man wieder für jedes Betriebssystem eine eigene Version erstellen, oder aber einen signifikant höheren Speicherplatzbedarf in Kauf nehmen, wenn man alle Betriebssysteme in einer Version unterbringen will.Zitat von MajinSonic
Außerdem wird es dann schwieriger in Bezug auf Patches und Updates des RE. Das Spiel könnte dann nur mit der Version veröffentlicht werden, welche auf dem Computer des Entwicklers vorhanden ist, auch wenn diese veraltet ist.
Zudem könnte ich dann keine Garantien mehr im Bezug auf Virenfreiheit der Spiele machen. Wenn man das Spiel mitsamt dem RE veröffentlicht kann man nicht davon abgehalten werden das RE so zu modifizieren, dass es schädliche Operationen auf dem Computer des Benutzers ausführt.
Updates sind sowieso schwierig, da man nicht davon ausgehen kann, dass ein Spiel, welches mit einer älteren RTE-Version entwickelt wurde noch mit einer aktuelleren läuft.
Es sei denn, du willst dir so einen Rattenschwanz einfangen, wie bei Java. Der Grund warum Java sich so schleppend entwickelt, liegt an der Abwärtskompatibilität. Jeder Mist muss mitgezogen werden. Selbst veraltete Klassen müssen immer wieder getestet werden. Schaut man sich hingegen mal das .Net Framework an, da wird man schnell feststellen, dass Microsoft für keine Abwärtskompatibilität garantiert. Anwendungen, die z.B. mit .Net 2.0 entwickelt worden sind, laufen nicht mit .Net 4.0. Man kann also nicht das aktuellste .Net Framework installieren und gut ist. Man muss schon schauen, welches benötigt wird, und dies wäre für Spiele ein No-Go, da man dann zig unterschiedliche RTEs installieren muss. Ich kenne auch keine ernstgemeinte Engine, die die RTE nicht mitausliefert.
Das was möglich wäre, wäre ein Installer, der während der Installation die benötigte RTE-Version runterlädt und mitinstalliert.
Eine RTE, die alleine installiert wird, ist absoluter Nonsense, und in der Spielebranche auch nicht tragbar, da man es hier nicht mit IT-Spezialisten zu tun hat, sondern in der Regel mit einem Otto-Normalverbraucher, der schon mit einer einfachen Installation Probleme hat.
Nein.
Geändert von Whiz-zarD (28.01.2014 um 18:38 Uhr)
Das mag für Java vielleicht stimmen; aber es wird doch wohl kaum große Änderungen bei Patches des RE geben. Lediglich Bugfixes und Performance-Verbesserungen. Diese würden dann die einzelnen Projektdaten nicht beeinflussen, welche weiterhin auf allen Versionen funktionieren würden.
Aber es ist sowieso noch zu früh um genaues darüber zu sagen. Es steht ja noch nichts in Stein geschrieben. Man kann auch immernoch die Möglichkeit mit einbauen ein Spiel direkt für eine bestimmte Plattform mit eingebautem RE zu erzeugen.
Ich spreche da aus Erfahrung, und nein es wird nicht funktionieren.
Bugfixes verändern das Verhalten einer Anwendung. Zwar korrigieren sie Fehler, aber man weiß nie, ob dadurch andere Probleme auftauchen. Mir ist das schon oft passiert, dass ich irgendwo ein Bug fixe und dann die Anwendung in einer völlig anderen Stelle knallt. Auch Performance-Verbesserungen ziehen oft eine Änderung des Unterbaus mit sich, der nicht vernachlässigbar ist. Daher: Sage niemals nie! Wenn ich sowas entwickeln würde, würde ich meine Hand nicht ins Feuer legen, dass die Spiele noch lauffähig sind. Um das überhaupt zu garantieren muss die Engine etliche Tests unterzogen werden. Jedes noch so kleines Feature muss auf Herz und Nieren getestet werden. Die Schnittstellen müssen klar definiert sein, und dürften sich auch nicht mehr erweitern oder verändern, was ein Stillstand der Software bedeutet, da jede Weiterentwicklung nicht erlaubt wäre. Wie gesagt, schau dir Java an, wie zäh es sich entwickelt. Okay, Oracle lässt Java ziemlich schleifen, und man hätte es besser machen können, aber selbst in der damaligen Obhut von Sun lief die Entwicklung schon recht zäh, da sie einen riesigen Rattenschwanz zu testen hatten.
Okay, an der Software ist zwar ein anderes Kaliber, aber selbst bei dieser Software findet vor jeder Auslieferung ein Regressionstest statt. Sei es auch nur ein Hotfix, der einen kleinen Bug behebt.
Neulich gabs bei uns den Fall, dass ein kleiner Hotfix bewirkte, dass an zig unterschiedlichen Stellen die Anwendung etwas anders tickte. Aus einem kleinen Hotfix wurden etliche neue Probleme, die erst mal analysiert werden mussten.
Ist das Spiel dann immer noch 11 MB groß, wenn ich stattdessen die Unreal- oder Source-Engine benutze?
Geändert von Whiz-zarD (28.01.2014 um 19:35 Uhr)
Du weißt selbst, dass dein Vergleich hängt und wir noch immer beim Maker sind.Ist das Spiel dann immer noch 11 MB groß, wenn ich stattdessen die Unreal- oder Source-Engine benutze?
--
Und du weißt, dass du von irgendeiner Engine sprichst?
Und selbst dann stimmt es nicht, da es auch beim RPG Maker sowas, wie Projekt-Dateien gibt, die größer als 0 Bytes sind.
Wäre prinzipiell immer an einer "verbesserten" Version eines Makers interessiert! Und wenn mich das Programm überzeugen kann, würde ich dafür auch zahlen.
--"Gib einem Mann Feuer, und er hat es einen Tag lang warm. Steck ihn in Brand, und er hat es warm für den Rest seines Lebens"
Nope. Siehe #44. Case closed.
--
Es wird sich hier um 100 MB gestritten, in Zeiten wo fast wirklich jeder eine schnelle Internetanbindung hat und in Zeiten, wo es schon TB-Festplatten gibt
Wir befinden uns nicht mehr im Modem und Disketten-Zeitalter ^^
Es ist niemals verkehrt die DL-Größe niedrig/gering/klein zu halten, aber ja, ansonsten stimme ich dir auch zu.Es wird sich hier um 100 MB gestritten, in Zeiten wo fast wirklich jeder eine schnelle Internetanbindung hat und in Zeiten, wo es schon TB-Festplatten gibt
Wir befinden uns nicht mehr im Modem und Disketten-Zeitalter ^^
--
Ich glaub mein altes Modem war schneller als der lausige Surfstick, den ich heutzutage habe.
Das kommt ganz darauf an wie man arbeitet.
Das RE ist ein Interpreter für die Spieldateien. Jedes Kommando im Spiel hat eine vorher fest (als Text) definierte Funktion. Als Entwickler ist es die Arbeit, dass das RE diese Funktionen alle gemäß der Definition ausführt.
Falls es im Zuge eines Patches oder Updates zu einer Änderung im Verhalten kommen sollte, dann bedeutet dies, dass sich das RE nichtmehr an die Definition hält, oder die alte Version des RE diese Funktion nicht korrekt implementiert hat.
In beiden Fällen wäre dies nicht ein Problem mit dem Produktmodell, sondern mit dem Entwickler.
Aber natürlich verstehe ich was du sagen willst. Soetwas ist immer eine gefährliche Angelegenheit und das Fehlerpotential wächst entsprechend mit der Komplexität der Anwendung.
Was die Diskussion zur Größe betrifft, so kann ich jetzt schon sagen, dass das RE wahrscheinlich nicht größer als 5mb werden wird falls wir Standard-Resourcen (Grafik, Sound, etc) außen vor lassen. Der Löwenanteil von diesen 12mb geht an plattformspezifische Bibliotheken wie zum Beispiel OpenGL und OpenAL bindings.
Seit meiner letzten Datenerhebung haben sich 3 weitere Stimmen positiv für das Projekt ausgesprochen. Vielen Dank für die rege Beteiligung soweit. Ich hoffe, dass sich noch ein paar weitere Personen dazugesellen werden.
Geändert von Cornix (28.01.2014 um 20:29 Uhr)
Und nun stell dir mal vor, dass ein Spiel nicht mehr weiterentwickelt wird. Das Spiel wäre dann nicht mehr spielbar.
Jeder Entwickler muss schauen, dass sein Spiel mit der aktuellsten Version läuft. Das würde kein kommerzieller Spieleentwickler mitmachen, weil es Unmengen an Zeit und Geld kostet.
Du wirst also eine enorm hohe Fragmentierung vorfinden, weil keiner garantieren kann, dass sein Spiel mit der aktuellsten Version läuft.
Soetwas sollte anhand eines Bugfixes oder Updates nicht möglich sein.
Alle Funktionalität, welche durch den Maker bereitgestellt wird, muss eine eindeutige textuelle Definition besitzen. Diese Definition wird sich niemals durch ein Update oder einen Patch ändern. Sie steht einmal fest und es wird an dieser Definition festgehalten.
Wenn ein Spiel entwickelt wird, werden in den Spieldateien die Funktionen des Makers verwendet. Wenn das Spiel durch ein RE abgespielt wird, dann werden die Funktionen interpretiert und ausgeführt.
Im Zuge eines Updates oder Patches kann die Implementierung der RE sich ändern, jedoch niemals das Verhalten einer Funktion. (Außer natürlich die vorherige Implementierung hat diese Funktion nicht richtig ausgeführt)
Es sollte daher niemals geschehen, dass ein Spiel nach einem Update der RE nichtmehr funktioniert. Immerhin nutzt es immernoch die selben Funktionen, und diese besitzen immernoch die selbe Definition.
Es kann natürlich passieren, dass der Entwickler des Patches oder Updates einen Fehler in das RE einbaut und etwas dummes tut. Aber im gleichen Zuge kann man auch behaupten, dass die Software von Anfang an nichts taugt, weil der Entwickler Fehler gemacht hat.
Wie gesagt: Sag niemals nie!
Ich spreche da einfach aus leidiger Erfahrung und habe fast jeden Tag damit zu kämpfen. Das ist leider der Alltag an der Software, an der ich arbeite, da sie extrem flexibel sein muss.
Wir haben in unserer Software ein C#-Compiler eingebaut, der den Binärcode in einer Datenbank hinterlegen kann, damit wir unsere Software programmtechnisch für einzelne Kunden individuell gestalten können, und immer wieder passiert es, dass kundenindividuelle Anpassungen nicht mehr funktionieren, weil sich einfach Funktionalitäten ändern. Wir haben sogar angefangen alle C#-Codeschnipsel mit in unseren Buildprozess aufzunehmen, damit wir wengistens sicher sein können, dass der Code kompilierbar ist. Ob der Code dann auch Fehlerfrei funktioniert, wird in einem umfangreichen Regressionstest überprüft. Dieser Test dauert zwei Wochen, und selbst das ist eigentlich zu wenig.
Es ist nun mal Natur, dass APIs sich im Laufe der Zeit ändern. Das lässt sich auch nicht verhindern, weil man eine Software nicht nach dem Wasserfallmodell entwickeln kann, und genau das planst du hier, und das wäre schon der Tod einer Software. Selbst du kannst dir nicht sicher sein, dass deine ausgearbeiteten Schnittstellen das Endresultat ist. Ich garantiere dir, dass es vorkommen wird, dass du drei Schritte nach hinten gehen musst, weil eine Implementierung nicht so funktioniert, wie du es dir anfänglich vorgestellt hast.
Ich bin mir sogar absolut sicher, dass ich "drei Schritte nach hinten gehen muss, weil eine Implementierung nicht so funktioniert, wie ich es mir anfänglich vorgestellt habe".
Aber ich weis auch, dass diese Phase noch lange vor der Veröffentlichung der ersten Version des Makers stattfinden soll.
Es ist eben so, dass die Maker-Software eben nicht sehr flexibel sein wird was den Funktionsumfang angeht. Die erste Version sollte bereits alle nötigen Funktionen beinhalten und implementieren; zusätzliche Funktionen sollten nicht durch Patches nachgereicht werden. Updates und Patches sollten lediglich unwesentliche Änderungen vornehmen um Performance- und/oder Speicherplatz-Optimierungen vorzunehmen. (Und natürlich Fehler zu beheben)
Ob das tatsächlich so funktionieren wird sei dahingestellt. Die Vorstellung eines Entwicklers ist immer Utopie. Aber bei den RPG-Makern hast du auch nie gesehen, dass ein großer Patch folgte, welcher zusätzliche Funktionen zu dem Event-Code hinzugefügt oder entfernt hat. Ich habe das genau so wenig vor.
Aber ich glaube wir driften hierbei zu stark von dem eigentlichen Thema ab. Danke für die unterstützenden Worte, hoffentlich wird es in der nahen Zukunft einen Thread geben, wo ich mehr auf die eigentlichen Funktionsweisen eingehen kann und solche Diskussionen besser anzusetzen sind.
Oh sorry, ganz vergessen zu erwähnen:
Ich würde definitiv einen guten Maker befürworten. Wenn er genug kann würde ich auch ohne zu zögern dafür zahlen wollen.
Und @Crowdfunding: Ich habe mal beim Durchstöbern von Kickstarter 2-3 RPG-Maker Projekte gesehen, die mehrere 100/1000 U$D erhalten haben. Erstlingsprojekte mit einem Mapping welches die Bezeichnung "Mapping" nicht einmal verdient. Würdest doch sicherlich, auch mit suboptimaler Werbung, den ein oder anderen Backer gewinnen können. Problem ist wohl eher, dass die "deutschen" Alternativen zu Kickstarter wohl nicht ganz so gehyped sind wie KS.
キャンヴァス war in der ersten Version (Midi) 11mb maximal groß. Just deal with it, dass es möglich ist.
--
Berechtigungen
Zitieren
