Idee für Event System

[XRPG]

Hallo Community,

ich eröffne diese Thema da ich euch um etwas Hilfe bitten möchte. Es geht um Ideen und Anregungen für den Aufbau eines eigenen Event Systems für Spiele. Hintergrund der ganzen Geschichte ist, dass ich zur Zeit ein bisschen vor mich hin programmiere und so etwas ähnliches plane. Natürlich lassen sich Spiele auch ohne ein solches System programmieren. Sagen wir jedes Objekt eines Spiels wird direkt gescriptet und kann dabei einen von Grund aus verschiedenn Aufbau haben. Der Nachteil daran ist natürlich, dass es viel Zeit in Anspruch nimmt, verschiedene Aktionen per Hand zu programmieren und das ganze einfach und überschaubar zu verwalten. Deswegen hab ich mir überlegt ein einheitliches System zu schaffen und bin natürlich sofort auf ein Maker ähnliches System gekommen. Event System, Maker? Naja, jeder der sich etwas mit dem Maker beschäftigt hat kennt sicherlich das RPG Maker Event System. Ihr habt das Event Layer angewählt, macht einen Doppelklick und der Event Manager öffnet sich. Hier und da lassen sich Einstellungen vornehmen und dann ist da natürlich noch der zusammenklickbare Code der zur Laufzeit interpretiert wird. Das ganze ist dabei stark auf die Bedürfnisse des Maker angepasst. Ich möchte das Ganze jedoch ein wenig weiterentwickeln und brauche dazu Ideen. Ein Problem welches ich dabei hab ist, dass man nahezu alles mögliche verbauen könnte. Jedoch muss ich Prioritäten setzen, welche Features die Wichtigsten sind und welche am meisten gebraucht werden usw.. ich probier es noch ein wenig genauer zu beschreiben..

Insgesamt kann man sagen, dass sich das System trotz aller Freiheiten auf ein Tile-Based Game bezieht. Was nicht zwingend heißen muss das es ein klassisches Rollenspiel seien muss. Es könnte auch für Action oder Jump and Run Spiele dienen (natürlich 2D). Es gibt also ein Raster(16x16 px) und jedes Event kann sich in einem dieser Raster befinden. Die Events sind dabei in einer Liste gespeichert die zur Laufzeit durchlaufen wird. Es wird also jedes Event angesprochen und ausgeführt. Ihr merkt schon, es ist dem Maker sehr ähnlich. Doch was soll das Event bei Ausführung alles für Möglichkeiten haben? Einige Ideen die auch schon Ansatzweise im Maker vorhanden sind:

1. Grafik des Objekts: Anders als im Maker sind die Grafik Größen frei wählbar (und nicht nur 24x32 px). Animationen können selbst zusammengeklickt werden. Es gibt also keine Begrenzung der Frames in einer Animation..

2. Bewegung des Objekts: Anders als im Maker muss dies nicht zwingend im Raster sein, sondern kann auch pixelweise geschehen. Eine nette Idee die mir dabei kam ist Pfadpunkte zu nutzen. Also man gibt zB 5 Koordinaten an, und diese werden dann nacheinander per Pathfinding abgeklappert. Das erleichtert das lästige rumgeteste mit den Move Routen.

3. Variablen des Objekts: Für nützliche Werte wie zB HP und ATK eines Objekts soll es eigene Variablen geben. Wenn man also die HP oder ATK speichern will braucht man nicht für jedes Objekte eigene Variablen in der Variablen Liste anzulegen oder umständliche Mechanismen einbauen die das handlen. Außerdem soll es einen Initialisierungsblock pro Seite geben, dieser wird wirklich nur einmal durchlaufen. Dort könnten zB die Startwerte für Energie und Lebensdauer festgelegt werden. Ein wichtiger Mechanismus könnte dabei direkter Zugriff auf Monsterwerte sein. Ich denke dabei an Monster die man in der Gamedatenbank anlegen kann, dessen Werte man direkt per Variable auslesen kann. Gleiche Gegnertypen müssten so nicht umgeschrieben werden, sondern könnten einfach per Copy&Paste weiterverwendet werden.

4. Optionale aufrechterhaltung von Werten: Sobald man eine Karte verlässt werden Events zurückgesetzt. Dies könnte man optinal verhindern indem man z.B. ein Haken setzt der die Variablen in ein Cache zwischenspeichert. Etwas aufwändig, aber wahrscheinlich sehr nützlich.

Das waren ein paar grundsätzliche Ideen. Da es ähnlich wie im Make zusammenklickbaren Code geben soll, welcher zur Laufzeit interpretiert wird, kann man die Event Befehle natürlich noch extrem erweitern. Dabei kamen mir folgende Ideen:

1. Mehr Macht für Events: Events haben in mancherlei Hinsicht einen sehr eingeschränken Funktionsumfang. Es sollte zB Möglich sein, dass ein Event, neue Events generieren kann. Dazu könnte man fertige Schablonen in der Datenbank hinterlegen, die nur noch mit Werten gefüllt werden. Ein Event Emitter sozusagen.. nützlich ist sowas für allerlei Dinge. Ich denke da an Maps die eine bestimmte Anzahl an Gegnern generiert bevor es weiter geht. Das kann dann natürlich auch zufällig passieren. Sinnvoll ist sowas alle Male.. und es verhindert lästige Copy&Paste arbeiten.

2. Mehr Manipulationsmöglichkeiten der Karte: Das betrifft einzelne Tiles und deren Kollision. Die sollte man natürlich ändern können um neue Funktionen zu verwirklichen.

3. Pictures: Joa.. die Picture Funktion wird neu aufgelegt. Besonders hilfreich dabei wären Picture Zeiger, also keine festen Picture IDs, oder sogar ein fester Satz Pictures für jedes Objekt. Außerdem die Möglichkeit Änderungen sofort wirksam zu machen, ohne jedesmal den Move Picture Befehlt aufzurufen. Beim erstellen des Pictures könnte man direkt vorgegeben Variablen setzten. zB this Object - Position X , oder so ähnlich.

Eine grundsätzliche Änderungen die ich dabei vornehmen will, die aber vllt den Umfang einschränkt (deswegen bin ich mir nicht sicher), ist z.B. die Abschaffung der Event Seiten. Wie kann man aber Events erstellen die Unterschiedliche Fähigkeiten haben, ohne Seiten zu benutzen? Was könnte ein Ersatz für Event Seiten sein? Vieleicht separierbare Code Bereiche, die jeweils ihre eigenen Startbedingungen haben?

Was habt ihr für Vorschläge? Denk an Zeiten in denen ihr euch mit dem Maker Events geplagt habt und euch bessere Systeme gewünscht habt. Was fehlt euch um die Arbeit zu erleichtern? Welche coolen Features fehlen um ein Spiel dynamischer zu gestalten?

Für diejenigen die Interesse haben, ich freue mich auf Vorschläge.. und wenn es sich nur um triviale Dinge handelt. Bisher ist alles nur theoretisch und sollte nicht als Endprodukt angesehen werden. Es könnte auch einfach eine Interessante Überlegung sein ;D

Bye

PS: Ich hoffe mal, das passt hier in den Talk Bereich. Es bezieht sich nicht direkt auf den Maker, hat jedoch viel damit zu tun. Aber passt es in den Technik Bereich, da bin ich mir auch nicht sicher, ach egal

[Bananen-Joe]

Wieder so einer...
...nun da das Bioshock 2 Setup was brauch hier ein Vorschlag zu deinen ersten Anführungen:

Ich würde es cool finden, wenn es Templates für Events gibt, welche mit Hilfe klassischer Vererbung erweitert werden können.
Beispielsweise könntest du dann im Maker statt einen "normalen" Events ein "Monster" (z. B. für Action Adventures) platzieren.
Das Monster-Event ist zwar auch ein Event, implementiert aber nicht die Standardfunktionen wie Ansprechen, ...

So mit ein paar Vererbungsbäumen sähe das ganze dann recht cool aus.

Nun das war mal ein Vorschlag.
Viel Glück und so.

BTW: Viele deiner Anmerkungen wie "Ändern eines Pictures nicht über feste Id sondern über Pointer" gehen bereits jetzt schon über Patches, wie Cherry's PicPointerPatch oder mein DestinyPatch (siehe beides im entsprechenden Unterforum).

MfG Bananen-Joe

[XRPG]

Danke für deine Antwort, wenigstens einer der etwas dazu sagt^^

Wieder so einer...
...nun da das Bioshock 2 Setup was brauch hier ein Vorschlag zu deinen ersten Anführungen:

Ähm, was genau meinst du damit?

Hab deinen und Cherry's Patch schon ausgiebig getestet. Doch wie bei allen Patches finde ich die neuen Möglichkeiten arg eingeschränkt. Man kann mit dem Destiny Patch zwar einiges anstellen, jedoch ist der Aufwand, um relativ einfache Funktionen wie z.B. Textboxen zu realisieren, ziemlich groß. Das müsstest du auch an der Resonanz bemerkt haben. Ich halte den Destiny Patch für ziemlich revolutionär, dennoch benutzt ihn fast niemand. Warum ist das wohl so? Ich glaube, jegliche externe Anwendung wird zunächst kritisch betrachtet. Es erfordert ja einiges an Einarbeitungszeit und an Kenntis um eure Patches sinnvoll einzubauen. Klar sind sie letzten Endes "leicht" zu implementieren, aber dennoch ist es extra Arbeit, die für den normalen Maker zusätzlicher Ballast ist. Nun, würdest du dich der Erstellung eines eigenen Makers widmen, wie groß schätzt du den Aufwand? Es ist zwar mega viel Planung und Arbeit, aber das Ergebnis wäre umso revolutionärer. Also ich finde.. anstatt alte Funktionen mit umständlichen Rumgebiege aufzuwerten, sollten erfahren Leute größere Ziele anstreben. Du merkst doch auch, dass die meisten Makerer auf Patches verzichten, da die Arbeit ohne Patches leichter fällt. Mit einem neuen System würde das nicht passieren. Ich schweife aber vom Thema ab.. es geht um Ideen für ein neues System, sry für den kritischen Blick an euerer Arbeit^^

Templates sind gut.. ja sowas könnte ich mir vorstellen. Gerade für verschiedene Genres in einem Maker wäre das eine Erleichterung. Ich bin aber noch etwas skeptisch. Warum den Funktionsumfang eines Events einschränken, wenn das Monster Event ebenfalls Fähigkeiten wie "Ansprechen" bekommen könnte? Eventuell hab ich etwas missverstanden, du müsstest schon etwas genauer auf die Vererbung eingehen.

Mir ist Letztens noch etwas nützliches eingefallen. Es betrifft die Gestaltung der Event Befehle. Im Maker gibt es ja nur drei Seiten die alle Befehle auf einen Haufen enthalten. Ich finde Registerkarten für "Spieler", "Gegner" und "Map" Befehle um einiges Übersichtlicher. Für schnelleres Arbeiten und so.. gerade wenn nochmals die doppelte Anzahl an Befehlen enthalten sein wird.

Finde die Resonanz auf dieses Thema etwas lasch. Wo bleiben denn eure Ideen? Es geht schließlich um die Erschaffung eines neuen Systems. Auch wenn vorerst nur konzeptionell geschieht.. ein bisschen mehr Beteiligung wäre schön ;D

Bye

[derula]

Zitat von XRPG

Nun, würdest du dich der Erstellung eines eigenen Makers widmen, wie groß schätzt du den Aufwand? Es ist zwar mega viel Planung und Arbeit, aber das Ergebnis wäre umso revolutionärer.

Es haben eben viele schon dasselbe versucht und nach einigen Jahren Arbeit aufgegeben. Das einzige Projekt, das im Moment noch nicht gecancelt ist, ist Open Game Studio. Ich kann dir höchstens raten, dort mitzumachen; allein wirst du vermutlich nicht fertig, und Darkas braucht bei OGS auch Unterstützung.

Zitat von XRPG

Finde die Resonanz auf dieses Thema etwas lasch. Wo bleiben denn eure Ideen? Es geht schließlich um die Erschaffung eines neuen Systems. Auch wenn vorerst nur konzeptionell geschieht.. ein bisschen mehr Beteiligung wäre schön ;D

Naja. Wir haben alle paar Monate hier einen (wie du am Anfang von BJ's Post sehen kannst), der so ein System machen will und um Resonanz fragt. Es gibt Threads, die voll von Resonanz und Ideen sind (z.B. hier). Da dein Projekt allein aus Erfahrungswerten (Statistik) mit ziemlich hoher Wahrscheinlichkeit eh scheitert, möchte keiner seine Energie dafür verschwenden.


Meine Meinung zu "Klickskriptsystemen", Patches und RGSS: Die Leute, die den RPG Maker entdecken, wollen einfach auf einfache Weise spielerisch Spiele erstellen. Sie sehen den RM und was andere damit gemacht haben, und sehen dass man alles nur mit Klicks machen kann. Daher vermuten sie, dass es einfach sein muss. Tatsächlich sind komplexere Skripte im Klicksystem meiner Meinung nach schwerer umzusetzen als mit echtem Skripting, die meisten verstehen das nur nicht / wollen es nicht glauben. Sie denken auch, Scriptsprachen sind schwer zu lernen und kommen deshalb nicht in Frage. Tatsächlich sind sie nur etwas schwerer zu lernen als die Klicksprache, da man die Befehle tatsächlich auswendig können muss und sich nicht durchklicken kann. Aber nicht viel schwerer! Und wenn man sie ein mal kann, kann man in der Skriptsprache viel schneller und erfolgreicher arbeiten. Der einzige Vorteil, den das Klicksystem noch hat, sind, dass keine Syntaxfehler bei Befehlen auftreten können.

Dass Skripte abgesehen von Syntaxfehlern fehleranfälliger sind, halte ich für ein Gerücht. Die meiste Logik muss man in beiden Systemen ziemlich ähnlich umsetzen, und wenn jemand einen Fehler in der Skriptsprache macht, hätte er denselben Fehler auch in der Klicksprache gemacht.

Fazit: Eine Skriptsprache zu lernen ist die kleinste Hürde für Klicksprachenbenutzer, aber aus Angst oder Ehrfurcht glauben sie das nicht. Und das ist nur natürlich, denn wenn sie keine Ehrfurcht vor Skripting hätten, wären sie nicht zum RPG Maker gekommen. Aber sie haben Unrecht; die Programmierlogik ist in beiden Varianten genau gleich kompliziert.


Soviel zu deinen Bemerkungen, dass Makerer etwas Einfacheres haben wollen. Ansonsten kann ich dir nur raten, Darkas zu helfen; er plant ein Klicksystem, das vollautomatisch in ein Skript umgewandelt wird (evtl. auch rückwärts), was evtl. helfen könnte, Makerern die Angst vor Skripten zu nehmen.

[Bananen-Joe]

Zitat von XRPG

Ähm, was genau meinst du damit?

Hat derula ja schon beantwortet.

Zitat von XRPG

Ich halte den Destiny Patch für ziemlich revolutionär, dennoch benutzt ihn fast niemand. Warum ist das wohl so?

Nun das ist alles eine Frage der Zielgruppe.
Die Zielgruppe war niemals Standard-RPG-Makerer (zumindest bei mir).
Bzw. bestand die Zielgruppe eher aus Leuten, die programmieren können.

Zitat von XRPG

Nun, würdest du dich der Erstellung eines eigenen Makers widmen, wie groß schätzt du den Aufwand? Es ist zwar mega viel Planung und Arbeit, aber das Ergebnis wäre umso revolutionärer. Also ich finde.. anstatt alte Funktionen mit umständlichen Rumgebiege aufzuwerten, sollten erfahren Leute größere Ziele anstreben.

Etwas vergleichbares hatte ich schonmal irgendwo gepostet.
Und mir schwirren auch einige Ideen für eine Art Maker im Kopf rum.
Das mit dem Templatesystem war nur ein Beispiel.

Aber wie bei so vielen Projekten ist auch hier das Problem, dass ich als Mensch mit einer 40 Std. Arbeitswoche nur eine arg begrenzte Freizeit zur Verfügung habe.
Und von der Freizeit geht sicherlich nochmal die Hälfte für Sport drauf (inkl. Reiseweg und den Pausezeiten, wo ich zu K.O. zum Denken bin).

Zitat von XRPG

Templates sind gut.. ja sowas könnte ich mir vorstellen. Gerade für verschiedene Genres in einem Maker wäre das eine Erleichterung. Ich bin aber noch etwas skeptisch. Warum den Funktionsumfang eines Events einschränken, wenn das Monster Event ebenfalls Fähigkeiten wie "Ansprechen" bekommen könnte? Eventuell hab ich etwas missverstanden, du müsstest schon etwas genauer auf die Vererbung eingehen.

Nun ich habe mich wohl etwas unklar ausgedrückt.
Im wesentlichen dachte ich an eine Verwendung von klassischen Dingen wie Klassen, Templates und Interfaces.

Wenn ich so drüber nachdenke sollte man vielleicht lieber nur von Klassen und Interfaces sprechen.

Nun in meinem Beispiel gibt es einige Grundklassen für Events und so.
Beispielsweise könnten dies normale Menschen, Schalter, Monster, usw. sein.
Diese verfügen über verschiedene Schnittstellen (= Interfaces) über welche diese im Spiel interagieren können.
Diese werden (wie in der Dreckssprache Java, welche uns aber immerhin die einfachvererbung gut strukturiert hat) implementiert.

Wenn du beispielsweise ein Monster hast, das von mir aus von der BasisEvent-Klasse erbt, dann kannst du per Klick immernoch das "Ansprech"-Interface implementieren.
Auf diese hinzugefügte Schnittstelle kann man dann z. B. per Skript (ob jetzt grafisch oder nicht ist wurscht) reagieren.
Also wenn der Held z. B. das Monster anspricht.
Ebenso denkbar wären Negativ-Interfaces, welche bestimmte Schnittstellen wieder entfernen (wenn z. B. ein Event alle Eigenschaften eines Monsters haben soll, aber nicht angreifbar sein soll).

Templates sollte in meiner vorherigen Erläuterung mehr so etwas wie Vorlagen (also vorkonfiguriertes Zeugs) sein. Nicht so etwas wie in C++.

Zitat von derula

Dass Skripte abgesehen von Syntaxfehlern fehleranfälliger sind, halte ich für ein Gerücht. Die meiste Logik muss man in beiden Systemen ziemlich ähnlich umsetzen, und wenn jemand einen Fehler in der Skriptsprache macht, hätte er denselben Fehler auch in der Klicksprache gemacht.

Ein vergleichbares Thema hatte ich neulich auf der Arbeit, als ich beim Hauptstandort war, wo die Leute mit Labview programmieren.
Die Programmierung erfolgt dort nur über Schaltpläne und somit eben grafischen Symbolen.
Ich machte einen Witz im Sinne von "Ihr programmiert nicht - ihr konfiguriert!".
Da war dem Kollegen das Thema wohl bewusst und er erzählte was von seinem Studium, da sein Professor genau dieses Thema "ist grafische Programmierung das gleiche wie Programmierung" behandelt hatte.
Der Professor kam zu folgendem Schluss, welchen ich auch für sehr sinnvoll erachte:
"Eine Programmiersprache (egal ob Text/Grafik) ist eine Programmiersprache, wenn sie in der Lage ist ihren eigenen Compiler zu schreiben."
Nun das klingt meiner Meinung nach sehr einleuchtend; und der Kollege hatte zum Beweis einen simplen Compiler mit Labview geschrieben.


Nun noch zum Thema Aufwand:
Ich habe mal drüber nachgedacht und denke, dass es möglich wäre einen Maker (sagen wir mal RM2K-Klon) in 7 Tagen (also 7 x 24 h = 168 h) zu entwickeln.
Dazu aber noch folgende Bedingungen:

1. Verwendung fertiger Systeme (z. B. wxSmith zur Dialogerzeugung, ADO mit MDAC für die Spieldatenbank oder eine fertige Skriptsprache die über 'ne DLL eingebunden wird)
2. Man muss bereits über ausreichend Erfahrung mit den zu verwendenden Mitteln verfügen
3. Zeit zur Grafikerstellung/zum Erzeugen von Beispielspielen zählt nicht mit
4. Planung, Programmierung und Test zählen mit
5. Da man die Zeit nicht am Stück machen kann, zählt die Summe der Teilstücke

Grund zu meiner Behaupung ist die Tatsache, dass viele Funktionen (wie z. B. Eventsysteme) einfach nur wiederholte Arbeit darstellen.
So stellt es beispielsweise kein Problem dar mit einer anständigen IDE den DataBase-Editor, o. ä. nachzubauen.

MfG Bananen-Joe

[XRPG]

@ Bananen-Joe:
So wie ich das sehe sind die bisherigen Versuche an mangelnder Planung und Aufwandsabschätzung gescheitert. Es scheint auch so als wolle man immer das Maximale an Features bieten. Wenn wir uns aber die Com anschauen will jeder mittelsständige Maker doch nur eines.. leichte Bedienbarkeit. Minimiert man die Features bekommt man ein gut überschaubares System, welches nur noch auf seine Implementation wartet. Ein minimiertes System bringt nur Vorteile. Ich denke aus heutiger Sicht müssten die Features des bisherigen Makers (2k, 2k3) um einiges leichter zu realisieren sein als im letzten Jahrzehnt. Erweitert man das Ganze mit 32-Bit Farben.. ein paar Grafikfunktionen und einem besser zu Bedienbaren Skript-Klick System, wäre das doch schon ein großer Sprung. Klar wäre es kein Ultra-System.. aber es wäre ein Aufwertung die sich die Makerschaft wünscht. Ich behaupte, dass der RmXP es nicht geschafft hat. Er ging in die falsche Richtung. Der Absatzmarkt hat sich viel zu drastisch in den etwas professionelleren Bereich geschoben. Die einfachen Funktionen die geblieben sind waren nicht zufriedenstellend und boten nicht wirklich etwas Neues.

Doch nun etwas zum Aufwand. Ich finde eine Zeit von 7 Tagen schon sehr realistisch. Doch die 7 Tage sollten dann wirklich nur für das pure Runtertippen gezählt werden. Eines vergisst du aber noch. Nämlich die Engine die mit den erzeugten Daten das Spiel zum laufen bringt. Man kann ein schön gedachtes System angelegt haben, das alles Mögliche enthält. Jedoch sollte die Engine es aber auch gut umsetzen. Plant man die Speicherung der Daten falsch, erhöht sich der Aufwand der Engine drastisch. Wenn man den Maker zusammenfassen sollte, so macht er doch letztlich nichts anderes als die zusammengeklickten Events und Daten aus der Database (und Maps), in Dateien zu speichern. Es ist nichts kompliziertes. Alle gesammelten Daten werden in geeigneter Reihenfolge gespeichert, und das so, dass sie auf den einfachsten Wege geladen werden können. Datenbank, Karten und Kartenstruktur, eine Projektdatei die das ganze zusammenhält - und fertig. Der Maker selbst besteht dabei nur aus GUIs die leere Container füllen. Und vielen Sicherheitsabfragen.. wie immer. Je nachdem wie routiniert man ist, sollte es also in diesem Zeitraum möglich sein.

Zu den Templates. Vielleicht denkst du da schon wieder zu kompliziert. Wofür DLLs mit Skriptsprachen? Wenn die Möglichkeiten eingegrenzt werden, kann man sich doch leicht einen Interpreter für die Engine schreiben. Vererbungsstrukturen, Klassen und Interfaces sollten Sache des Programmierers bleiben. Objektorientierung ist ein tolles Konzept und großes Hilfsmittel für Projekte. Aber es muss keineswegs die universelle Lösung für Systeme sein. Klar programmiere ich in der Engine und im Maker Objektorientiert.. aber sollte man dieses Wissen wirklich für die Nutzung eines Makers vorraussetzen? Wir befinden uns schon wieder im falschen Absatzmarkt. Es geht zu sehr in den proffessionellen Bereich. Auch wenn ich deine Idee nicht schlecht finde möchte ich keine komplexen Systeme einbauen, wenn es doch leichter geht. Die Interfaces werden im Hintergrund genutzt. Da nicht jedes Event alle Funktionen braucht müssen also nur die nötigsten Interfaces implementiert werden. Hat man ein reines Update-Event, so kümmert sich die Engine selbst darum das kein Graphic Interface implementiert wird.

Dieser Thread war eigentlich dazu gedacht den "normal" Makerer zu fragen was er bei der Erstellung eines Spiels vermisst... reduziert auf das Event System natürlich. Aber eure Meinungen sind mir auch wichtig. Mir ist bewusst , dass ihr lächelt und denkt: "Noch so einer der viel will aber nichts schafft." Das stört mich aber nicht weiter. Es ist ja wirklich so, dass es haufenweise Leute gibt die es gerne möchten, es aber dann Dank mangelnder Kentniss oder Motivation fallen lassen. Jedoch geht es bei mir erst einmal um den theoretischen Bereich.. und Anschließend wird abgewogen ob es für mich machbar ist oder nicht. So sollte man Software angehen, finde ich.

Bye

[Bananen-Joe]

Zitat von XRPG

Wenn wir uns aber die Com anschauen will jeder mittelsständige Maker doch nur eines.. leichte Bedienbarkeit. Minimiert man die Features bekommt man ein gut überschaubares System, welches nur noch auf seine Implementation wartet.

Darum sprach ich auch bei den 7 Tagen von einer Art RM2K-Klon.

Zitat von XRPG

Ein minimiertes System bringt nur Vorteile.

Jein.
Als ich früher noch mit VB6.0 programmiert habe, war ich erst froh, dass es so einfach ist.
Doch irgendwann stößt man immerwieder an die Grenzen, sodass man Funktionen über die WinAPI einbinden muss oder später sogar (da VB extrem langsam ist) eigene DLLs (in anderen Sprachen) schreiben muss.

Der Kern sollte selbstverständlich einfach sein.
Doch sollte zumindest die Möglichkeit offen stehen das System (via Scripting) zu erweitern.

Zitat von XRPG

Ich denke aus heutiger Sicht müssten die Features des bisherigen Makers (2k, 2k3) um einiges leichter zu realisieren sein als im letzten Jahrzehnt.

Direct3D gab's schon damals. Die wollten nur eine möglichst niedrige Systemanforderung haben.
Und das hat der Maker auch - die Spiele (und der Maker) liefen sogar auf meinem Pentium 1.

Zitat von XRPG

Ich behaupte, dass der RmXP es nicht geschafft hat. Er ging in die falsche Richtung.

Nun in anderen Ländern wird er afaik häufiger eingesetzt als in Deutschland. Da gibt es auch einen Thread drüber...

Zitat von XRPG

Doch nun etwas zum Aufwand. Ich finde eine Zeit von 7 Tagen schon sehr realistisch. Doch die 7 Tage sollten dann wirklich nur für das pure Runtertippen gezählt werden. Eines vergisst du aber noch. Nämlich die Engine die mit den erzeugten Daten das Spiel zum laufen bringt.

Die habe ich nicht vergessen. 7 Tage = Planung, Implementierung und Test von Maker und Engine.

Zitat von XRPG

Plant man die Speicherung der Daten falsch, erhöht sich der Aufwand der Engine drastisch.

Deswegen sprach ich auch davon möglichst viel fertige Systeme zu nehmen. z. B. ADO (ActiveX Data Objects) - das ist eine hübsche kleine Schnittstelle von Microsoft. Damit kannst du beispielsweise über MDAC auf Access-Datenbanken (mdb-Dateien; kannst du benutzen, wenn du Office hast) zugreifen.
Der Maker macht nebenbei kaum was anderes:
Die Spieldatenbank, etc. ist auch nur eine Datenbank, die von einer Standard-Delphi Klasse gelesen/geschrieben wird.

Zitat von XRPG

Wofür DLLs mit Skriptsprachen?

Wie kommst du denn jetzt da rauf?
Hatte ich doch nix von geschrieben; auch nicht im Bezug auf die Event-Templates.

Zitat von XRPG

Klar programmiere ich in der Engine und im Maker Objektorientiert.. aber sollte man dieses Wissen wirklich für die Nutzung eines Makers vorraussetzen?

Nun es gibt Systeme, wo es vorausgesetzt wird, aber ich denke man könnte das ganze auch gut im Hintergrund behandeln, sodass es für einen nur dann interessant wird, wenn man daran rumfummeln will.

Zitat von XRPG

Dieser Thread war eigentlich dazu gedacht den "normal" Makerer zu fragen was er bei der Erstellung eines Spiels vermisst... reduziert auf das Event System natürlich.

Na ja, in diesem Forum sind nicht viele Leute aktiv. Am wenigsten von allen noch Leute, die mit dem Maker arbeiten.
Aber du hast doch sicherlich auch in anderen Foren wie dem Quartier Threads eröffnet?

Zitat von XRPG

Aber eure Meinungen sind mir auch wichtig. Mir ist bewusst , dass ihr lächelt und denkt: "Noch so einer der viel will aber nichts schafft." Das stört mich aber nicht weiter. Es ist ja wirklich so, dass es haufenweise Leute gibt die es gerne möchten, es aber dann Dank mangelnder Kentniss oder Motivation fallen lassen. Jedoch geht es bei mir erst einmal um den theoretischen Bereich.. und Anschließend wird abgewogen ob es für mich machbar ist oder nicht. So sollte man Software angehen, finde ich.

Na ja, wenn du den Aufwand abschätzt und dann sagst "ist zu viel", dann hatten wir doch Recht.

MfG Bananen-Joe

[XRPG]

Bisher finde ich den Aufwand immernoch sehr überschaubar. Ich hab die Idee also noch nicht fallen gelassen ;D
Was hält dich eigentlich davon ab einen Maker zu schreiben? Hab deinen Post wohl etwas überlesen. Also wenn du die Planung in die 7 Tage mit einbeziehst finde ich es doch leicht unrealistisch. Das Ergebniss sollte schon Fehlerfrei sein und auch eine ergonomische Oberfläche bieten. Bei solchen Sachen vergeht die Zeit meist schnell^^
Auf fertige Datenbank Systeme möchte ich verzichten. Die Dateihaltung schreibe ich dann lieber selber. Da es sich um eine einfache Datenbank handelt müsste man das relativ schnell hinbekommen.

Bye

[Bananen-Joe]

Zitat von XRPG

Was hält dich eigentlich davon ab einen Maker zu schreiben?

RL. Abgesehen davon bin ich immernoch an der Nachfolgeversion des DestinyPatches dran.

Zitat von XRPG

Also wenn du die Planung in die 7 Tage mit einbeziehst finde ich es doch leicht unrealistisch.

Nun ich gehe ja auch von einem kleinen Maker aus.
Abgesehen davon sind es ja keine 168 Stunden am Stück, sodass man wohl bei jeder Stunde volle Kapazitäten mitbringt (weil man z. B. ausgeruht ist).
Außerdem sollten ja halt möglichst viele fertige Systeme verwendet werden - also auch Datenbanksysteme.
Wenn man sowas noch selbst schreiben muss, dann dauert es natürlich länger.

MfG Bananen-Joe

[XRPG]

Ich merke schon.. die Skepsis ist zu groß.
Nun, da es wohl nichts bringt in der Öffentlichkeit Fragen zu stellen werde ich mich wohl auf meine eigenen Erfahrungen verlassen müssen. Erwartet nichts in 7 Tagen (xD), aber hier endet es definitiv nicht. Falls ihr wollt könnt ihr weiterhin Ideen posten.. mit "Du schaffst es nicht!" kann ich jedoch nichts anfangen ;D

@Derula:
Hab vorhin ein bisschen durch den OGS-Sourcecode geschaut. Gefällt mir überhaupt nicht.. vor allem die Oberfläche und das ganze XML rumgespiele =|