Für Diskussionen bitte auch diese Seite verwenden!

Ich denke, es ist besser, wenn im Wiki-Artikel selbst die Punkte eingetragen werden, die non sunt disputandum, also von allen bereits abgenickt wurden. Anstatt uns im Wiki-Artikel mit Kommentaren aufzuhalten, können wir das hier tun, was neben der generellen Ordnung den netten Nebeneffekt hat, dass der Wiki-Artikel mit der Zeit zu der von Kjarrigan gewünschten TODO-Liste mutiert. ;-)

Die Kommentare sind eig auch mehr für die Stellen wo ich zu faul war oder keine Ahnung von den Details habe. Das man da zumindest erstmal sieht was bisher dazu geäußert wurde. Ein etwas objektivere Beurteilung der Passagen wäre eine Aufgabe die ich mal an die jeweiligen Experten weiterreiche :-D

--Kjarrigan 07:03, 3. Jun. 2010 (UTC)

Die bisher eingetragen Punkte bleiben am besten auf dem Artikel, diskutieren sollten wir aber hier und dementsprechend ändern. Denkt aber bitte daran, Antworten mit Doppelpunkten einzurücken und zu signieren, sodass man weiß, von wem sie ist, also:

==Vorschlag==
Das oder jenes --~~~~

:Anwort1 --~~~~
::Antwort2 --~~~~
:::Antwort3 --~~~~

Die kryptische Strichkombination erzeugt deine Signatur.

Für diverse stilistische Sachen wie fetten Text bitte RubyWiki:Hilfe lesen.

Dann fröhliches Diskutieren...

--Q 18:29, 2. Jun. 2010 (UTC)

Map-Tiles?

Die Frage möchte ich einfach mal in den Raum werfen. Wie ich schon im Foren-Thread geschrieben habe, bin ich von dem auf derart große Felder begrenzten Raster nicht begeistert. Ich denke, man sollte einen pixelgenauen Maker zur Verfügung stellen, aber ein "Hilfsraster" erlauben, also quasi einblendbare Rasterlinien, die aber nicht im späteren Spiel auftauchen sondern nur zur Orientierung beim Entwickeln dienen. Eventuell könnte man auch noch eine Art Fangeffekt einbauen, sodass man nicht versehentlich 1 Pixel daneben setzt oder soetwas. --Q 18:29, 2. Jun. 2010 (UTC)

Also zumindest für mich ist dieses Kastenraster essentiell. Das macht genau das Look-and-Feel aus das ich erwarte wenn ich ein Makerspiel spiele, weil mich das an die gute alte Gameboy/NES/SEGA Zeit erinnert. Allerdings gebe ich dir Recht, dass mehr "Leben" ins Spiel kommt, wenn man sich frei bewegen kann. (Golden Sun etwa für den GBA wäre wohl ein Bsp - was wirklich genial war ;-)). --Kjarrigan 06:06, 3. Jun. 2010 (UTC)

Golden Sun habe ich auch mal angespielt - geliehen von einem Freund glaube ich, bevor er es zurückhaben wollte. Nach dem, was ich gesehen habe, war das tatsächlich ziemlich gut. Thema Look&Feel: Natürlich hast du ja recht, eine gewisse Nostalgie ist aus der Sache nicht herauszudenken. Wer sich daran halten möchte, kann das tun, er braucht nur das Hilfsraster einzuschalten und nicht wieder auszuschalten, fertig. Was ihm jetzt noch fehlt, sind ausschließlich 32x32 Pixel große (oder kleinere) Graphiken. Eventuell könnten wir es auch so machen, dass wir standardmäßig das 32x32-Reportoire zur Verfügung stellen, aber die Möglichkeit anderer Graphiken und deren pixelexakte Platzierung erlauben.
...oder wir machen einfach das, was leichter zu programmieren ist. ;-) --Q 17:01, 3. Jun. 2010 (UTC)

Also vom Programmieraufwand und Handling sollte ein festes Raster einfacher sein, einfach weil man nicht auf so viele Dinge achten muss, wie ist der jetzt 1px zu weit rechts und fällt die Klippe runter oder bleibt er oben. Außerdem sind ja Events im Maker auf "Kästchengröße". Da kommt mir gleich noch ne Idee (unabhängig davon welches System nun wird). Man könnte die Events ja statt auf Kästchen auf eine Fläche frei wählbarer Größe anwenden (so ähnlich wie die Monsterareas). Ich hab nämliches manches Spiel gesehen wo Event X 10mal Kopiert wurde, damit das nicht nur an dem einen einzigen Feld ausgelöst wird. --Kjarrigan 05:56, 4. Jun. 2010 (UTC)

Wahrscheinlich hast du hinsichtlich des Programmieraufwands recht. Ich stelle meinen pixelexakten Wunsch zurück. Zu den Events: Ja, das ist sehr unschön gewesen und auch ich bekenne mich, die Kopiertechnik angewandt zu haben. :-) Ein Event, das sich über ein Rechteck von Felder erstreckt, ist sicher sinnvoll. --Q 14:45, 4. Jun. 2010 (UTC)

Ich bin auf jeden Fall für ein Raster, einfach aus schon genannten Gründen welche ich nicht noch einmal außeinander nehmen möchte (Events, Programmieraufwand, ...) Ansonten gibt es dazu von meiner Seite aus wenig zu sagen :-) --Crucki 21:44, 2. Jul. 2010 (UTC)

Tilesets

Ich finde Tilesets unpraktisch. Ständig muss man hoch oder runter scrollen, und am Ende ist das Objekt, das man sich an diesem oder jenem Ort wünscht, dann doch wieder in einem anderen Tileset und man muss es erst in das für diese Map gedachte einbauen. Mein Vorschlag: Wir benutzen keine Tilesets, sondern wir erlauben standardmäßig alle Graphiken auf einer Map (für vernünftiges Aussehen der Map hinterher sind wir ja nicht verantworlich ;-) ), die wir statt als Tileset einfach als Einzelgraphiken hinterlegen. Wenn man das mit einer Art "Tile-Menü" kombiniert, das der Nutzer mit Graphiken seiner Wahl anreichern kann, ohne dass die Wahl seiner Graphiken im Menü auf die erlaubten Graphiken in der Map bezogen wäre. Als Beispiel: Wenn der User meint, er würde in seinem Nadelwald gern einen Laubbaum haben, etwa um hier eine spieltechnisch oder storytechnisch besondere Stelle hervorzuheben, dann muss er nicht erst den Laubbaum in das Nadelbaum-Tileset einbauen, sondern wählt einfach sowas wie "Tile-Menü" -> "Graphik hinzufügen..." und fügt den Laubbaum in sein Tile-Menü ein. Daraufhin kann er ihn dort auswählen und auf der Map platzieren.

Möglicherweise könnte man auch die Möglichkeit anbieten, die Tile-Menü-Konfigurationen abzuspeichern, sodass man sich nicht jedes Mal alles neu zusammensuchen muss. So könnte man eventuell auch ein paar vorgefertigte Kombinationen zur Verfügung stellen, die aber vom Nutzer erweiterbar sind. --Q 18:29, 2. Jun. 2010 (UTC)

Also Einzelgrafiken halte ich für problematisch. Das werden ja dann noch mehr als beim Maker. Aber die Idee mit dem "zusammenstellen" finde ich gut. Man könnte die Elemente ja trotzdem aus einem "Tileset" im Makersinne importieren und abspeichern. So kann der normale MakerUser bei seinem Konzept bleiben und es gibt damit auch die "Standardkonfigurationen" die du angesprochast. Das dynamische Hinzufügen eines Elements funktioniert dann wie du gesagt hast über ein Menü und muss noch irgendwo festgehalten werden. Wie willst du dann eig die Mapfelder mit den Grafiken verknüpfen? Beim Maker lief das meines erachtens wie ich schon geschrieben hatte über eine relative Id zur Position im Tileset. Vllt finden wir ja auch einen Zwischenweg ;-) --Kjarrigan 06:03, 3. Jun. 2010 (UTC)

Du meinst, dass man das Tileset quasi dynamisch über das Menü anpassen kann? Das wäre prima, denn was mir bei den Tilesets eigentlich am Negativsten auffiel, war die Tatsache, dass man zum Hinzufügen von Elementen erst einmal ein einigermaßen leistungsvolles Graphikprogramm starten musste (Tabellenfunktion erforderlich; ich hab' das immer mit GIMP gemacht) und sich darin einarbeiten musste, bevor man dann sein einsam einzelnes Tile hinzufügen konnte. So wie du das beschreibst, finde ich das auch gut.
Stichwort Tile-zu-Map: Bislang hatte ich vor, alle Graphiken in Tile-Objekte zu laden und jede Map mit einer Tabelle zu assoziieren, in der die Tile-Objekte eingetragen sind (oder besser, Referenzen auf jeweils dasselbe Tile-Objekt, sodass nicht 184 Kopien desselben Tile-Objekts vorliegen). Wenn wir jedoch mit Tilesets arbeiten (die wir dann vielleicht anders nennen sollten, mal schauen...) ist denke ich eine X-Y-Tabelle auf dem Tileset das Praktischste. Da die Tilesets sich in der Größe ja während des Spiels nicht verändern, wäre das vermutlich ein Anwendungsfall für NArray, das eine schnelle C-Implementation für fixe Arrays beliebiger Dimensionalität (n-dimensional, daher der Name) bereitstellt. Das würde den Rechenaufwand etwas drücken. Es sollte aber besser vermieden werden, zur Laufzeit eine "Ausschneid-Operation" auf dem Tileset durchzuführen, das schlingt zuviel Performance. Es wäre besser, wenn die Tiles aller Tilesets bereits beim Start geladen würden, denn die Startzeit ist ja relativ egal.
Anderer Punkt: Wollen wir wie der Maker eine Begrenzung in Höhe und/oder Breite des Tilesets einführen? Wenn wir kästeln, würde ich lediglich festsetzen, dass die Tileset-Graphik sowohl in Höhe als auch Breite glatt durch 32 teilbar ist, der Rest ist egal. --Q 17:17, 3. Jun. 2010 (UTC)

Da das Thema nochmal aufkam...also ich bin nach wie vor gegen Pixelgenaue Positionierung und Berechnung. Das Argument der Freiheit und Lebendigkeit nehme ich aber zur Kenntnis und hätte einen Kompromiss vorschlag. Wir machen die Standardtilesets von 32x32, der Spieler läuft aber über ein Raster von 8x8 (oder 4x4 als absolute Untergrenze). So bleibt dem Spieler ein enormer mehraufwand für das Gestalten von Karten erspart (denn wer möchte schon statt 1er 32er 16 8er oder gar 64 4er Grafiken einzeln setzen und ich könnte auch nicht gerade behaupten, dass die Spiele die ich bisher gesehen hab mit dem "groben Raster" keine detailverliebten Maps erstellen konnten. Ein kreativer Schöpfer konnte durchaus eine schöne lebendige Atmosphäre erschaffen. --Kjarrigan 07:35, 21. Jun. 2010 (UTC)

Genaugenommen wollte ich (weiter unten beim AKS) darauf hinaus... Gut, mag sein dass ich das jetzt etwas zu naiv betrachte, aber was spricht denn dagegen, Umgebung und Charaktere konzeptionell voneinander zu trennen? Die Gestaltung der Umgebung kann (und sollte) mit den 32x32 Feldern durchgeführt werden, aber wenn man den Chara bewegt dürfte es doch relativ leicht sein, den auch nur um einzelne Pixel zu versetzen. Das einzige was da mMn jetzt Probleme machen könnte wäre die Kollisionserkennung (ergo läuft er an dem Baum vorbei oder nicht), und selbst das sollte sich elegant lösen lassen. Mal davon abgesehen, dass die Verschiebung des Charas sowieso von seiner eigenen Geschwindigkeit abhängt, er sich also im Resultat zwar pseudogerastert fortbewegt, aber rein vom Konzept her frei ist. Zumindest denke ich, dass zwischen dem dynamischen Charakter und der statischen Umgebung gar nicht so ein Zusammenhang besteht, dass man für beide das Kachelsystem umsetzen muss bzw. diese entweder/oder-Entscheidung nötig ist. --Aco 09:28, 21. Jun. 2010 (UTC)

Hm. Also grundsätzlich schubsen wir das Männel ja eh n-Pixel hin und her, da wäre auch ein n=1 möglich, Aber, was ich mir bisher schwer vorstellen kann ist die Bewegungsanimation, denn wenn wir ein festes Raster haben, dann drückt der Spieler einmal rechts. Nach dem halben Kästchen wechselt die Animation auf "Fuß vor" und dann wieder auf stand wenn der Kasten erreicht ist. Wenn der Spieler die Taste loslässt wird die aktuelle Bewegung noch zu ende geführt. Wo aber ist bei 1px Bewegung Zwischenschritt und definiertes Ende? Kollisionserkennung sollte auch bei kleinerem Raster machbar sein, da wir ja in der Regel genug Rechenpower bei den meisten erwarten können. Wir sollten vielleicht auch langsam unabhängig von der Raster größe überlegen, die Physicengine Chipmunk zu verwenden. Die funktioniert super mit Gosu - schon probiert - und übernimmt recht performant die Komplette Kollisionsverwaltung und wir müssen uns darum nicht mehr kümmern. Dann könnte ich mir vllt auch pixelgenaue Bewegung vorstellen, denn wie zBsp hier im Gosu::Chipmunk::Tutorial wird das Männel nicht um x Felder nach rechts bewegt sondernein Kraft auf den Körper x gewirkt. Je nach Trägheit kommt er dann eben eher oder später zum stehen. --Kjarrigan 13:20, 21. Jun. 2010 (UTC)

Chipmunk sieht zwar nach erstem Eindruck gut aus, aber wir müssen daran denken, dass unsere Zielgruppe keine Programmierer sind. Die hätten nun einmal am liebsten eine Methode Player.move(3), die den Spieler 3 Felder/Pixel nach rechts schiebt. Es ist schwierig, die für vorgegebene Wege notwendige Kraft abzuschätzen, ohne viel auszuprobieren... Außerdem gibt's noch ein Problem:

After looking at the Chipmunk framework, one thing I noticed was that it basically assumes that you are working with a profile oriented environment where down (the direction of gravity) is towards the bottom of the screen. What this means is that you can exploit all Chipmunk offers (e.g., gravity, friction, collision detection, etc.) for your side-scrolling games, however, top-down games, where down is out the back of the display, might limit what Chipmunk can do for you, or, at least, render it more difficult to use.

Nach dem, was ich im Tutorial-Code gesehen habe, scheint das aber nicht allzu gravierend zu sein. Letzten Endes muss ich aber noch eins zugeben: Bislang habe ich noch nie mit Vektoren gerechnet, dementsprechend schwierig tue ich mich gerade. Soweit ich das überblicken kann, sind die für Stufe 11 auch noch gar nicht vorgesehen... Nichtsdestotz werde ich mich informieren, wenn das nötig wird. --Q. 13:55, 21. Jun. 2010 (UTC)

Ja genau 3 Felder(!) nach rechts, daher bin ich nach wievor für ein Raster (auch wenn wir das gerne kleiner als 32x32 machen können). Chipmunk selbst macht aber laune und die "Anziehungskraft" nach unten kann man deaktiveren, um nur die eigens iniitiereten zu verwenden (alles schon probiert), die sind dann mehr für Leute die gerne Sonic oder Worms programmieren wollen :-D Mit Vektoren rechnen ist eig kein Problem vereinfacht gesagt ist das nur ne andere Schreibweise für Koordinaten, man schreibt x,y (und beliebig viele Dimensionen) eben nicht nebeneinander sondern untereinander. Und beim addieren und subtrahieren wird eben jede dimension einzeln berechnet (also x1 + x2, y1 + y2, usw) was dich aber eigentlich alles nicht stören braucht, da du im Programm alles wie normalen Punkt kommasepariert schreibst und er auch intern richtig rechnet. Um nun eine Kraft auf einen Körper zu geben geht man von einer anderen Vektoransicht aus - er ist ein Pfeil der vom Koordinatenursprung (0,0,0,...) auf den angebenen Punkt zeigt (zbsp 1,2,3) So lang wie der Pfeil ist so stark ist die Kraft. Also wird dann einfach Position des Körpers + Vektor = neue Position. Nun ist in der Natur natürlich alles komplexer, weil dich ja die Trägheit, die Erdanziehung, Luftwiderstand und tausend andere Dinge abbremsen, aber eben genau solche Überlegungen muss man nicht machen weil das Chipmunk übernimmt :-D und hier sind ja noch drei andere Kluge Köpfe, die das Feintunig der Kräfte dann schon übernehmen könnten. --Kjarrigan 19:46, 21. Jun. 2010 (UTC)

Hört sich ja relativ einfach an, aber warum ausgerechnet vom Ursprung aus? Eine Kraft könnte doch auch von irgendwoanders her wirken...? (Dunkel steigen gerade Erinnerungen an Physik 8.Klasse und Kräfteparallelogramme herauf... ;-) )
Aber wenn wir meine Unwissenheit einfach mal außer Acht lassen (ich kompensiere das schon irgendwie), angenommen, ein physikalisch-mathematisch absoluter Ignorant setzt sich in den Kopf, mit unserem Editor ein Spiel zu erstellen - was soll der sagen, wenn er unter dem Menüpunkt "Event bewegen" die Meldung bekommt: "Bitte gebe die anzuwendende Kraft und deren Richtung an"? Und das, obwohl er eigentlich nur den Spieler um 1 Feld nach oben bewegen wollte...
Es erscheint mir wichtig, dem Spieleentwickler auch eine Möglichkeit zu geben, ein Event/den Spieler so zu bewegen, dass er mit absoluter Sicherheit auf einen bestimmten Feld zum Stillstand kommt.
Möglicherweise habe ich das Problem aber auch noch nicht ganz verstanden, ich mache mir nur Sorgen um die Intuitivität der Makerbedienung. --Q. 17:08, 22. Jun. 2010 (UTC)

So witzig die Umsetzung per Kraft sein mag, ich glaube nicht, dass das wirklich günstig wäre. Vorschlag: Keiner sagt ja, dass man dem Entwickler nur EINE Möglichkeit zur Bewegung geben sollte. Es könnte doch verschiedene Anweisungen geben: Bewege Figur um x Felder/Pixel, Bewege Figur um x Felder mit Snap-To-Grid-Funktion, Bewege Figur zu absoluter Position (hier könnten allerdings bei Hindernissen und fehlender Voraussicht glattweg Wegfindungsalgorithmen nötig werden...).
Was die Sache mit der Schrittanimation angeht: 1. Da die Sprites eine gewisse Größe haben, lässt sich anhand dessen sicherlich eine passende "zurückzulegende Entfernung in Pixeln" bestimmen, die die Figur hinter sich bringen muss, bevor das nächste Animationsbild verwendet wird.
2. Spricht eigentlich etwas dagegen, mehr als 3 Bilder für eine Schrittanimation zu verwenden? Je mehr Bilder, desto flüssiger, und desto kleiner die benötigte Distanz, bis das nächste angezeigt wird. Und dass eine Bewegung um nur einen Pixel mithilfe der Pfeiltasten nicht umsetzbar ist sollte eigentlich klar sein. Bzw. wenn man das Timen kann, dann ist man entweder extrem schnell, oder der Walkspeed der Figur auf nahezu negative Geschwindigkeit gesetzt (ja, ich weiß dass das sonst rückwärtsgehen wäre). Und selbst wenn man 1 pix hinbekommt: man könnte immer noch den Mittelschritt erzwingen, woraufhin dann der Abschluss erfolgt. Bei 1pix gibts keine 0.5 als Schrittweite, aber ich denke das Prinzip des Aufrundens wäre hier nicht verkehrt. --Aco 18:26, 22. Jun. 2010 (UTC)

Ruby einbauen?

Das halte ich für eine essentielle Frage. Wollen wir Ruby wie der Maker einbauen, oder setzen wir eine externe Ruby-Installation voraus? Ich persönlich würde lieber die externe Ruby-Installation sehen, weil man mehr Kontrolle über das hat, was installiert ist und man selber dafür sorgen kann, auf dem aktuellen Stand zu sein. Netter Nebeneffekt: Man hat die Möglichkeit, alle Vorteile von RubyGems zu nutzen und in seinem Spiel zu nutzen. Probleme wird es dann aber beim Deployment geben; man kann ja schlecht voraussetzen, dass der Endnutzer dieselbe Ruby-Installation (Version + Gems) wie man selber hat, wenn überhaupt - insbesondere auf Windows wäre das problematisch. Interessanterweise hätten wir hier aber auch gleich die Abhilfe: Zum Deployen wäre OCRA vermutlich am geeignetsten, es kompiliert das Spiel zusammen mit Ruby-Interpreter und Gems in eine Executable. Die andere Möglichkeit, Ruby in den Maker miteinzubauen, halte ich für schwer realisierbar, weil die Maker-GUI mit ihren Funktionen selbst höchstwahrscheinlich in Ruby geschrieben wird. Ideen dazu? --Q 17:26, 3. Jun. 2010 (UTC)

Hm also für das Verbreiten eigener Spiele ist unumgänglich eine Exe mit nem integrierten Ruby zu erstellen (zumindest für die Windows User). Wer die als Spieler nicht nutzen möchte kann die dann ja ggf immer noch löschen und aus dem Editor heraus starten (was dann aber wieder Probleme mit den gems machen könnte). Schwer. Wir sollten aber vllt wirklich überlegen 1 kompilierte Exe zu erstellen die für jedes Projekt verwendet werden kann (so ist immer gegeben, dass alle den gleichen Stand haben) --Kjarrigan 06:15, 4. Jun. 2010 (UTC)

ich bin dafür das beim Maker das system weite nutzt ... und für das spiel wäre es am besten wenn man beim erstellen des spiele installers die ruby libs irgendwie mit dazu packen könnte wenn man will --Hanmac 10:52, 4. Jun. 2010 (UTC)

Der erstellen von .exe-Dateien auf Windows ist per OCRA Kinderkram. Das löst alle (Gem-)Abhängigkeiten auf und kompiliert die ganze Geschichte in eine einzelne Datei, die man dann am besten neben der Ruby-Executable des Spiels ins bin-Verzeichnis packt (da könnte man einen Menüpunkt Datei -> Kompilieren einführen). Problematisch ist das im Hinblick auf andere Systeme. Für Nutzer anderer Systeme (wie etwa Linux) kann das bloße Ruby-Skript im bin-Verzeichnis genügen. Hier tritt aber das Problem auf: Ein Windows-Nutzer hat vermutlich kein vorinstalliertes Ruby (außer wir installieren es während des Installationsvorgangs des Makers nebenbei), viele Linux-Nutzer hingegen schon (bei mir auf Ubuntu sind sie leider noch nicht so weit, aber ein sudo apt-get install ruby1.9-full kann das Problem lösen, wenn man nicht selbst kompilieren will). Die Gefahr, die ich sehe, besteht darin, dass quasi versehentlich mal ein internes, mal ein externes Ruby benutzt wird, die im schlimmsten Fall völlig unterschiedliche Versionen und Gems haben und zu seltsamen Fehlermeldungen führen würden.
Lösungsansatz: Kennt ihr Panda 3D? Das ist eine 3D-Engine, die sehr viel mit Python arbeitet und sowohl auf Windows, Mac und Linux läuft. Damit die ihre Python-Abhängigkeit in jedem Fall korrekt haben, bringen die kurzerhand ihr eigenes Python mit, in einem Unterverzeichnis python des Installationspfades. Ich denke, dass das ein guter Zwischenweg ist, bei dem die User das Maximum an Freiheit genießen und wir gleichzeitig das größtmögliche Maß an Sicherheit: Der Benutzer kann, wenn er will, das Maker-Ruby (welches wir dann aktuell halten müssen - so aber gleichzeitig garantieren, dass alle das gleiche Ruby verwenden) zu seinem PATH hinzufügen (der Windows-Installer muss das per standardmäßig angewählter Option ermöglichen) und es so zu seinem Standard-Ruby machen (es ist aber umgekehrt nicht möglich, ein anderes Ruby für den Maker zu verwenden). Wer das nicht möchte, braucht es nicht, muss aber alle Gems, die er nutzen will, separat mithilfe von soetwas wie /usr/lib/openrubyrmk/ruby/bin/gem install ein_beliebiges_gem installieren. Windows-Nutzer werden damit nicht unnötig überfordert, Linux-Enthusiasten behalten ihre Freiheiten, beliebige Installationen von Ruby nebeneinander zu haben.
Langer Rede kurzer Sinn:
Entwicklerseite
Der Spieleentwickler erhält einen Maker mit einem Ruby in einem ruby-Ordner seiner Maker-Installation, das er benutzen muss. Er kann aber dennoch Gems installieren, er muss es nur eben mit dem integrierten Ruby machen.
Spielerseite
Windows-Nutzer bekommen eine mit OCRA gepackte .exe-Datei, die alles enthält. Linux- und Mac-Benutzer benötigen ein vorinstalliertes Ruby, dessen Version und Gem-Abhängigkeiten der Entwickler angeben muss (eventuell Einführung eines Menüpunkts Datei -> Abhängigkeiten auflisten...?).
Klingt kompliziert... Hat jemand einen einfacheren Vorschlag? --Q 14:32, 4. Jun. 2010 (UTC)

Panda 3D ist auch eine gute engine ... aber ich kann mich mit python nicht so recht anfreunden ... ansonsten wäre das doch auch gut als engine für maker oder? Wenn wir das ruby beim maker dazu packen, könnte man doch im Programm eine funktion machen wie: suche nach aktuellem Ruby ... oder der schaut auf pc nach ob der pc selbst eine neuere ruby version hat (ginge aber glaub ich nur unter unix/linux oder vllt auch bei mac), bei jedem spiel dazu weis ich nicht so recht, das könnte man ja wie beim RTP des makers machen, das man das nicht immer braucht, noch ne idee bei debian: da könnte man die abhängigkeiten doch einfach machen nach der ruby version oder? (hm wie man das mit gems macht hab ich keine ahnung ...) ..... hm das wäre doch ein Feature request für deb pakete das die paket verwaltung dach rubygems suchen kann bzw das als abhänigkeiten? *träum* --Hanmac 06:45, 5. Jun. 2010 (UTC)

Panda 3D ist eine 3D-Engine. Soweit ich das verstanden habe, wollten wir uns auf zweidimensionale Spiele beschränken? Im Übrigen mag ich Ruby auch viel lieber als Python (siehe hier ;-) ).

Zitat von Hanmac:

Wenn wir das ruby beim maker dazu packen, könnte man doch im Programm eine funktion machen wie: suche nach aktuellem Ruby ... oder der schaut auf pc nach ob der pc selbst eine neuere ruby version hat (ginge aber glaub ich nur unter unix/linux oder vllt auch bei mac), bei jedem spiel dazu weis ich nicht so recht, das könnte man ja wie beim RTP des makers machen, das man das nicht immer braucht,

Warum sollte das Suchen nach einer neueren Ruby-Version nur auf unixoiden Systemen möglich sein? Ein einfaches ruby -v zeigt dir auch auf einer Windows-CMD, welches Ruby du installiert hast.
Beim Verwenden eines externen Rubys besteht immer das Risiko, dass die Grundabhängigkeiten nicht erfüllt sind. Wenn wir beispielsweise die NArray-Klasse für fixe Tabellen verwenden (wie ich schon an anderer Stelle schrieb, das ist eine schnelle C-Implementation für n-dimensionale Tabellen) und der Entwickler das narray-Gem nicht installiert hat, wird er mit einer Fehlermeldung überfallen.
Inwiefern "wie beim RTP"? Ruby ist essentiell, du kannst den Maker nicht ohne Ruby betreiben (sei es ein in die Executable eingebautes via OCRA oder ein externes).
Kannst du das mit den Debian-Paketen genauer erläutern? Willst du den Maker als Debian-Paket verpacken oder die Spiele? Und ja, man kann in .deb-Dateien Abhängigkeiten auf Paket-Versionen setzen, allerdings werden die meisten Benutzer wohl deswegen nicht ein veraltetes Ruby installieren, weswegen dann andere Anwendungen nicht mehr laufen. Und da gibt es noch ein anderes Problem: Wenn du Ruby wie ich zum Beispiel selbst kompiliert hast und es in /opt liegt und überhaupt nicht mit der Paketverwaltung interagiert hat, wird das Paket nicht erkennen, dass Ruby bereits installiert ist, denn das ruby-Paket ist ja nicht installiert. Und ja, man kann auch bei Gems eine Abhängigkeit von der Ruby-Version angeben. Ich halte das für den schlaueren Weg, das ist unabhängig von Setups wie meinem. Allerdings bin ich mir immer noch nicht ganz sicher: Willst du das fertige Spiel dann als RubyGem verpacken? Das wäre eine Lösung, die besonders für erfahrene Rubyisten interessant ist. Das Spiel sollte aber besser nicht automatisch auf den RubyGems-Index gestellt werden, sonst werden wir noch von einer Spielflut erschlagen, wenn wir nach Programmbibliotheken suchen. ;-) Wenn jemand eine Domain und einen Server bezahlt, könnten wir auch einen eigenen Gem-Server aufsetzen, nur für Spiel-Gems. Ich muss mal darüber nachdenken... --Q 07:29, 5. Jun. 2010 (UTC)

nein ich meinte nicht das spiel oder den maker als gem, sondern das beim installieren des Makers als Deb-Paket das er auch nach nötigen Gems schaut ob alle vorhanden sind, und wenn ruby selbst komplimiert ist nach /opt, müsste man es doch in PATH eintragen? bzw könnte man doch in der config des makers den pfad zur ruby version machen, das wäre doch noch besser oder? --Hanmac 07:55, 5. Jun. 2010 (UTC)

Zitat von Hanmac:

beim installieren des Makers als Deb-Paket das er auch nach nötigen Gems schaut ob alle vorhanden sind,

Das müsste sich eigentlich über ein Post-Install-Skript bewerkstelligen lassen, das dann einfach gem install xyz aufruft. Ist das Gem bereits installiert, dann wird RubyGems hierbei schlicht nichts unternehmen.

Zitat von Hanmac:

und wenn ruby selbst komplimiert ist nach /opt, müsste man es doch in PATH eintragen?

Ja, da kommt es nicht drumrum.

Zitat von Hanmac:

bzw könnte man doch in der config des makers den pfad zur ruby version machen, das wäre doch noch besser oder?

Problematisch ist das da, wo keine Ruby-Installation vorliegt... Vielleicht sollten wir so vorgehen:

1. Maker schaut bei Installation (woraus auch immer) nach, ob bereits ein Ruby >= der gebrauchten Version da ist.
2. Wenn das der Fall ist, fragt der Installer, ob dieses Ruby genommen werden soll und setzt bei Ja entsprechend einen Eintrag in der Config. Bei Nein oder wenn kein Ruby installiert ist wird ein eigenes Ruby installiert, als Subdirectory der Maker-Installation und dieses in die Config eingetragen.
3. Der Maker schaut, ob die für die Funktion des Makers erforderlichen Gems installiert sind und installiert sie bei Bedarf.
4. Der Maker ist einsatzbereit.
5. Auf der Spielerseite muss auf Linux/Mac ein vorinstalliertes Ruby der entsprechenden Version da sein und die Gem-Abhängigkeiten erfüllen (hier ist der Entwickler gefragt, siehe meinen vorigen Post für weiteres). Windows-Nutzer bekommen eine OCRA-Executable, die alles enthält.

Können wir uns darauf einigen?
PS: Die Zitat-Vorlage, die ich gerade gebastelt habe, funktioniert prima. ;-) Anwendung: <<Zitat|NameDesBenutzers|Zitattext>>, wobei die eckigen durch geschweifte Klammern zu ersetzen sind. --Q 10:42, 5. Jun. 2010 (UTC)

Engine

Mehr oder weniger sind wir bei Gosu hängengeblieben, oder? Gibt es da noch mehr zu besprechen oder kann das in den Artikel aufgenommen werden? --Q 15:34, 6. Jun. 2010 (UTC)

Wenn keiner mehr etwas sagt, übernehme ich das. --Q 13:26, 8. Jun. 2010 (UTC)

man mösste das ergebnis sehen ... bzw könne man es doch auch so machen das man die engine austauschbar machen konnte? (wenn jemand zb das ruby binding für clanlib fertig hat) --Hanmac

Eine austauschbare Engine hört sich ziemlich kompliziert an... Angenommen, wir starten mit Gosu, dann haben wir diverse Methodenaufrufe eingebaut, die die Gosu-Engine benutzen. Man müsste eine Art Zwischenlayer einbauen, an dem auf der einen Seite das Spiel hängt und davon ausgehen kann, dass die Aufrufe an dieses Layer immer das gleiche Ergebnis haben, egal, welche Engine auf der anderen Seite des Layers sitzt. Problematisch ist aber, dass der Weg durch das Layer wieder Performance kosten wird. Kjarrigan, was sagst du dazu? --Q 09:55, 12. Jun. 2010 (UTC)

Also...prinzipiell wäre eine austauschbare Engine schon nicht schlecht, aber da muss man wie du gesagt hast eine einheitliche Schnittstelle definieren. Das wird etwas schwierige aber ich denke wir sollten es versuchen. Ich bin eh dafür Grafik und Logik so weit wie möglich unabhängig zu halten. Ich versuch es auch schon weitestegehend bei meinen Gehversuchen, aber ich stoße immer wieder auf Probleme hinsichtlich Performance. Müss mer schaun. Generell sollten wir die Trennung anstreben, gerade wenn neue Gosu Versionen kommen oä. Ich schreibe mal auf meine ToDo Liste ein paar Benchmarks hinsichtlicher der Trennung --Kjarrigan 09:50, 13. Jun. 2010 (UTC)

Prima wär's schon, aber mir macht die Performance ernstlich Sorgen. Jede einzelne aufzurufende Methode muss dreimal abgewogen werden, weil sie die Ausführzeit verlangsamt. Das mögen nur Mikrosekunden sein, aber bei entsprechend vielen Aufrufen läppert sich da ganz schön was zusammen. Vorschlag: Wir passen unser Layer an die Methoden von Gosu an. Sollte die Performance nicht ausreichen, fliegt es raus und wir nehmen direkt Gosu (da gleiches Interface, kaum Codeänderungen erforderlich). Ist es aber akzeptabel, dann müssen wir für andere Engines lediglich das Layer so gestalten, dass es zum Spiel hin genauso aussieht wie das Alte (d.h. genau wie Gosu, weil das ursprüngliche Layer ja Gosu angeglichen wurde).
Wie viel Bilder pro Sekunde sollen denn etwa angestrebt werden? 100fps halte ich für unrealistisch, das dürfte mit Ruby nicht drin sein. --Q 16:05, 13. Jun. 2010 (UTC)

Also ich denke Performancetechnisch bekommen wird das schon hin. Eine 2D Anwendung frisst nicht so viel und 100fps brauchen wir nicht. Wir versuchen ja nicht mit der Maus irgendjmd dem Kopf wegzublasen sondern sind ja rein Tastaturgesteuert. Ich denke 50fps sind schon mehr als genug zumindest, wenn wir nicht pixelgenau laufen lassen ;-) Mal so grob überblickt haben wir ja nun schon einige Baustellen angesprochen. Ich denke wir können langsam mal anfangen das ein oder andere zu implementieren und erste Tests durchzuführen hinsichtlich Performance, der Integration von Gosu etc. Vllt macht jeder mal ein kleines Spiel direkt mit Gosu und wir schauen überhaupt erstmal ob Gosu uns genügt :-D --Kjarrigan 16:30, 13. Jun. 2010 (UTC)

Zitat von Kjarrigan:

ir versuchen ja nicht mit der Maus irgendjmd dem Kopf wegzublasen sondern sind ja rein Tastaturgesteuert

:D :D Das als Browserspiel und du wirst berühmt. :)
Ja, wir sollten anfangen zu coden. Ich werde mir jetzt mal ein Gosu-Tutorial vornehmen (kannst du mir eins empfehlen?) und dann was zusammenschustern. Bevor wir uns aber an den eigentlichen Code für die Spiele und den Maker machen, sollten wir vielleicht noch klären, wo wir hosten, denn ein Versionskontrollsystem erscheint mir wichtig, sodass wir ohne größeren Aufwand Features einbauen können. Ich schlage noch einmal GitHub vor, also Versionskontrollsystem git. Ist auch nicht schwer zu lernen und gibt's auch für Windows, keine Sorge ^^. Soll ich das Projekt anmelden? --Q 18:03, 13. Jun. 2010 (UTC)

Also ich habe Berufsbedingt mit CVS, SVN und aktuell Git gearbeitet (ich benutz imo nur noch git) also können wir das ruhig auf GitHub laufen lassen. Hm Tutorial ist etwas schwierig. Also ich hab mir das Tutorial auf der Googlecode-Seite angeschaut. RubyTutorial. Wenn man das nachvollzogen hat (man kann nebenher ruhig bisl spielen) gibts noch im Gem-Ordner ein paar Examples von weiteren Features (und 2 kleine Spiele). Ein weiteres Projekt zum "abkucken" ist Planets! (ein Ruby-Gosu-Minispiel, dass ich mal um ein Punktesystem erweitert hab ;-) ) Da hab ich mir nebenher auch mal Chipmunk angeschaut (eine Physic-Engine) aber sowas brauchen wir ja eig nicht :-D --Kjarrigan 05:44, 14. Jun. 2010 (UTC)

Ahrrr, Berufsprogrammierer wissen alles schon vorher! ;-)
Das Tutorial sieht soweit gut aus (ich habe mal den überflüssigen Balken aus dem Link entfernt, sonst kommt ein 404), ich werde mich da durcharbeiten und mir auch mal Planets! anschauen. Hanmac, Einwände gegen GitHub? Bevor wir irgendwo "offiziell" werden, ist denke ich Einigkeit das wichtigste...
Achso, fällt mir gerade so ein: OpenRubyRMK ist als Name angenommen? Wofür steht eigentlich das "RMK"? --Q 15:45, 14. Jun. 2010 (UTC)

R(PG)M(a)K(er) :-p Wir können aber auch Variieren: [Open]RubyR[P][G][Maker][K] Such dir was aus :-p und Versionsverwaltungen gibts ja nicht so viele, da kann man die drei schon kennen :-D Vllt find ich ja auch das kleine Spiel noch, was ich mal selber gebastelt hab. --Kjarrigan 18:34, 14. Jun. 2010 (UTC)

Scheint, als wäre der Name also in Ordnung. Die exakte Bedeutung könnten wir auch im Unklaren lassen, das ist auch ganz lustig. Hanmac, Aco: Einwände gegen GitHub? --Q 13:35, 18. Jun. 2010 (UTC)

Nö, keine Einwände. Ich bin sowieso in erster Linie zur konzeptionellen Unterstützung hier, und sollte ich doch in die aktive Programmierung einsteigen dann wärs eh nicht verkehrt, noch was neues kennenzulernen ;) --Aco 18:28, 22. Jun. 2010 (UTC)

Ich bin noch nicht so recht glücklich mit Gosu, da müsste man mich zuerst überzeugen was es alles kann -> Clanlib. da würde ich gerne weitermachen, ich brauche aber welche die sich mit Ruby-Extensions auskennen ich wollte auch sowas wie rice dazu nutzen, aber das ist nicht so ganz das ich will, deshalb brauch ich hilfe --Hanmac

Du kannst dir ja einfach mal anschauen was es alles kann ;-) Ich hab aber mal kurz bei Google nach clanlib ruby gesucht und musste feststellen, dass die Lib 2003 und die Rubybindings 2002 das letzte mal aktualsiert wurden mal davon abgesehen, dass einige Links nicht funktionieren. Wenn du eine aktuellere Adresse hast würde ich mir das mal anschaun --Kjarrigan 11:39, 24. Jun. 2010 (UTC)

ich habe mir die doku von Gosu angesehen, und ich weis nicht so recht ob das ok ist. es gibt noch nicht fertiges von clanruby, ich habe mich selbst mal dran gesetzt mit 5 Klassen oder so, aber ist noch nicht fertig, weil ich vorher sowas in der art wie Rice bräuchte (Rice selbst ist ungeeignet), dazu bräuchte ich einen der mit hilft erstmal sowas wie rice, also ein interface zu bauen auf das dann ruby zugreift --Hanmac 11:48, 24. Jun. 2010 (UTC)

Im Zusammenhang mit Rice wird oft auch rb++ genannt. Wäre das passender? -- Disclaimer: Ich habe zwar schon einige C-Extensions geschrieben, aber C++ habe ich noch nicht angefasst.
Wenn wir die Idee mit dem Layer durchsetzen, ist es eh wurscht, welche Engine sich hinter der ganzen Sache verbirgt; letztendlich musst du sie nur noch an das Layer anpassen. Dazu mache ich noch ein Extra-Thema auf. --Q. 15:11, 24. Jun. 2010 (UTC)

rb++ ist auch nur ein rice aufsatz, somit wäre das selbe problem. PS: da ruby nur in C und nicht C++ ist, muss man das ganze noch kapseln, zbw hier einiges was mir an Rice nicht gefällt

• Enum werden als Modul mit Konstanten behandelt, ich bin dafür Enum als Set von Symbolen zu behandeln (der wert wird nur intern vom system benutzt)
• es gibt nicht genug default Klassen wie Range und Time
• Die Proxy von Array und Hash sind meiner meinung nach nicht ganz ok programiert
• ich hätte auch noch eine Klasse um zugriffe wie für String.external_encoding= zu händeln weil methoden in C++ kein = haben dürfen
• Ändern des Coding standards auf C++X0 um erweitere funktion zu nutzen (das verkürzt einige überladungen auf 1)

Deswegen will ich eher ein eigenen wrapper--Hanmac

Also ich könnte wenn das mit dem "Zwischenlayer" harmoniert, die jMonkeyEngine (JAVA) hinten anbinden... Oder man bindet sie direkt an. Wozu würde man denn eigentlich diese "Austauschbarkeit" brauchen? Evtl. das der Anwender später die Engines wechseln kann...? Versteh den Zweck dahinter nicht ganz--Robin89

Der Zweck des Layers setzt sich aus zwei Teilen zusammen: Zum einen, wie du schon sagtest, dem Anwender die Engine freizustellen (auch aus lizenztechnischen Gründen). Der andere Grund ist sehr pragmatisch: Wir können uns nicht 100%ig auf eine bestimmte Engine festlegen; zwar ist Gosu offenbar am beliebtesten, aber nicht jeder denkt das. (Sorry für die späte Antwort, habe ein Weilchen nicht nach Änderungen im Wiki geschaut) --Q. 08:20, 19. Jul. 2010 (UTC)

Event-Bearbeitung

Die bisherigen Statements sind von Kjarrigan auf der Wiki-Seite ja schön zusammengefasst worden. Weitere Pros&Contras hinsichtlich DSL, endlichen Automaten und Petri-Netzen sowie einem Experten-Modus? Habe ich es richtig verstanden, das im "Experten-Modus" auf jeden Fall eine Programmierung in direktem Ruby möglich ist? --Q 15:34, 6. Jun. 2010 (UTC)

Ja so hatte ich es gedacht. Der Expertenmodus erlaubt direkt Rubyscripte zu schreiben und zu verwenden (vllt sogar extern geschrieben und eingebunden per require?). Das ist der Ort wo man sich dann so richtig austoben und die volle Bandbreite an gems etc integieren kann. Im normalo Modus würde ich nur eine festgelegte Liste von gems anbieten. (was das Verteilen wieder etwas erleichtert, denn ich denke der Großteil der Nutzer wird auf weitere Gems verzichten). Die Sache mit der DSL für den Standardmodus halte ich für ganz gut (Dafür ließe sich auch "leicht" eine passende Klick-GUI wie im Maker drüber legen). Petri-Netze konnte ich mir immer noch nicht näher anschaun, steht aber auf der ToDo ;-) --Kjarrigan 06:13, 7. Jun. 2010 (UTC)

Ich habe mich jetzt ein bisschen in die Petri-Netze eingelesen. Folgendes Beispiel (hat keinen tieferen Sinn, ich musste mir irgendwas einfallen lassen): Du benötigst zwei Schlüssel sowie einen Schalter um die erste Tür zu öffnen, worauf du irgendeinen Gegenstand bekommst. Mit Schalter 2 öffnest du Tür 3 und bekommst nochmal den gleichen Gegenstand. Diese zwei brauchst du, um Tür 3 zu öffnen, die zum Ende führt. Ich habe keine Ahnung ob das auch nur annähernd richtig ist, aber das ist das, was ich so verstanden habe. Bitte um Korrektur!
Stichwort DSL: Wir sollten uns mal überlegen, was wir für die DSL brauchen. Bevor sie implementieren, hätte ich gerne genau umrissen, was sie können muss, damit wir das von Skade beschriebene Problem, hinterher Ergänzungen vorzunehmen, nicht bearbeiten müssen. Und wie soll die Syntax aussehen? Völlig prozedural, etwa move self, :down, 3 oder eher self.move :down, 3? Andere Events als self spricht man am besten über die eindeutige ID an. --Q 13:57, 7. Jun. 2010 (UTC)

Nachdem ich mir nun auch nochmal Petrinetze angeschaut und mit einem kleinen Javatool gespielt habe meine Gedanken dazu. Also grundsätzlich klingen die nach einer feinen Sache, um Bedingungen und (Re)Aktionen abzubilden und ich sehe eigentlich auch kein Problem, dass zusätzlich(!) zur DSL zu verwenden, denn unsere DSL definiert ja in erster Linie WAS beim Event passiert (abzuarbeitende Aktionsliste), das Netz sagt uns ja WANN das Event passiert/passieren kann. Soweit meine ersten Gedanken dazu. Vielleicht find ich ja mal eine Petri-Netze-Lib zur Verwendung mit Ruby und experimentiere damit ein bisschen. (Ich seh schon, das Projekt wird mich auf jedem Fall in den verschiedensten bereichen fordern und fördern ;-) was ich allein schon bei der Vorbereitung alles gelernt hab :-p ) --Kjarrigan 13:32, 21. Jun. 2010 (UTC)

Ich seh' schon, wir haben zu viele Ideen... Wir sollten den OpenRubyRMK möglichst so aufbauen, dass ohne großen Aufwand Extras über eine Art "Plugin-System" eingebaut werden können. Das würde zudem auch Personen, die den Maker an sich gern bearbeiten möchten, zugute kommen. --Q. 17:12, 22. Jun. 2010 (UTC)

Kampfsystem und Schadensberechnung

Meinungen zu rundenbasiertem oder leistungsbasiertem System oder einem Aktionskampfsystem? --Q 15:34, 6. Jun. 2010 (UTC)

Also ich bin ja ein Freund von Rundenbasierten Kämpfen und dieses Sys gehört meiner Ansicht auch zum Look and Feel ;-) Ein AKS ist meiner Meinung nach in 2D nicht wirklich Kampf, denn man hat ja "nur" 4 Richtungen. Es gibt nur wenige LP. Man trifft oder trifft nicht. Keine ausgeklügelten Fähigkeiten. Das gern angeführte Zelda hat ja auch als Zentrales Elemente die Rätsel ;-) Kurzum, ich würde das klassische Rundenbasierte System behalten aber die Option bieten es (im Expertenmodus?) abzuschalten. Über Scripte kann man dann ein AKS nachstellen. Wir können dafür ja auch ein "Referenzsystem" beilegen. (Was meinst du eig mit leistungsbasiertem System ?) --Kjarrigan 06:01, 7. Jun. 2010 (UTC)

Stimmt, mithilfe der "vollen Ruby-Power" ;-) sollte es keine größeren Hindernisse geben, ein vernünftiges AKS "im Nachhinein" zu implementieren, wenn wir das Event-System einigermaßen praktikabel zu skripten machen. Ich hatte ja bereits an anderer Stelle erwähnt, dass meine Versuche, Events im RPGXP zu skripten, völlig fruchtlos waren. Insofern könnten wir einen rundenbasiertes System als Standard nehmen, allerdings wären bewegte Kämpfer doch eine Bereicherung, die Standbilder beim RPGXP fand ich irgendwie langweilig. Zum Thema Zelda: Ich bin ein großer Fan davon, versuche nicht mich umzustimmen ^^ Gestern mal wieder Ocarina of Time durchgespielt ^^.

Zitat von Kjarrigan:

Was meinst du eig mit leistungsbasiertem System ?

Damit meine ich, das System nicht nach Runden aufzubauen, sondern nach der "Fitness" der Kämpfer, d.h. jeder Kämpfer besitzt einen Fitnesswert, der sich im Laufe des Kampfes immer weiter ansammelt, bis er "voll" ist, wonach der Kämpfer dann irgendeine Aktion tun kann. Danach wird er geleert, und erst wenn er sich neu aufgefüllt hat, findet die nächste Aktion statt. Je nachdem, wie fit so ein Kämpfer dann ist (also um welchen Wert sich seine "Fitness" pro Sekunde oder was auffült) könnte ein Kämpfer dann durchschnittlich häufiger agieren als andere, was zu einem lebendigeren Kampf führt. Disclaimer: Das System ist nicht von mir, dass habe ich in irgendeinem anderen Spiel gesehen, das mir gerade partout nicht einfallen will. --Q 12:53, 7. Jun. 2010 (UTC)

Achso. Ja sowas hab ich auch mal in einem Spiel gesehen und war wie du sagtest durchaus dynamischer :-D Das ist aber vllt auch ein Fall für "auswechselbares" KS. Wir sollten dann doch mal die DSL und alles andere vorbereiten und dann Interessengruppen bilden, die sich dann mit den 3 (vllt bis dahin noch mehr) möglichen KS, die wir dann alle beilegen :-D (Unsere DSL müsste eig auch das AKS und das LeistungsKS abbilden können, denn so wurde es ja auch im Maker gemacht) - Das LKS sollten wir vllt auch im Auge behalten, das gefiel mir. Vielleicht hat ja auch jmd ganz ne andere Idee für ein KS --Kjarrigan 05:50, 8. Jun. 2010 (UTC)

Also ich bin mir nicht sicher, ob das, was der Maker da angeboten hat, als DSL durchgeht... Aber ich wüsste auch nicht, als was sonst.
Zumindest was die Kampfsysteme angeht, scheinen wir den Maker überholen zu können, sollten wir tatsächlich die Zeit und Lust haben, drei oder mehr verschiedene "offiziell" anzubieten! :)
Für die DSL lege ich noch einen Extra-Diskissionspunkt an. --Q 13:30, 8. Jun. 2010 (UTC)

Das Leistungsbasierte KS kenne ich als ATB (Active Time Battle) und ist ein Quasi-Standard für Final Fantasy (nicht wichtig, aber damit das mal geklärt ist, gibt massig Abwandlungen)
Zum Thema: Rundenbasiert bzw. ATB sollten dann in typischer Seitenansicht umgesetzt werden, mit kleinen Männeken die verschiedene Animationsloops für ihre Aktionen haben (ja, auch warten muss aktiv aussehen...). Dementsprechend müsste allerdings auch ein System ausgeklügelt werden, das dem Nutzer die Möglichkeit gibt, Fähigkeiten, Animationen und Chara-Status nicht nur zu erstellen, sondern auch beliebig miteinander zu kombinieren.
Ein AKS würde mehr Freiheiten bieten, wenn die Charaktere frei bewegbar sind, also sich nicht an das Raster der Map-Tiles halten müssen (was mMn in Betracht gezogen werden sollte, die Bewegungen wirken dann natürlicher). Sollte auch keine Probleme mit den Events geben, weil ja regelrecht Event-Regionen geplant sind, wenn ich das richtig aufgefasst habe. Hier gibts dann eher das Manko der einsetzbaren Fähigkeiten (QuickSlots oder nur zwei konfigurierbare Aktionstasten?). Wann wird was getroffen, wie sehen Fernkampfattacken aus (Kollisionserkennung und Kausalität der Animationen)...
Für das rundenbasierte kann man vllt noch Abwandlungen bereitstellen, hauptsächlich solche, die die Reihenfolgebestimmung/Initiative klären. Immerhin ist damit aber das klassische Repertoire erschöpft. Wer unbedingt ein System ala "Ich lege diese Fallenkarte verdeckt!" haben will, sollte dann freundlich auf die Erweiterbarkeit mittels eigenem Ruby-Code verwiesen werden--Aco 11:14, 18. Jun. 2010 (UTC)

Zitat von Aco:

Das Leistungsbasierte KS kenne ich als ATB (Active Time Battle) und ist ein Quasi-Standard für Final Fantasy (nicht wichtig, aber damit das mal geklärt ist, gibt massig Abwandlungen)

Danke für die Hilfestellung. :-) Da sieht man mal, dass ich zwar Ideen von hier und da habe, aber kaum noch selbst spiele...

Zitat von Aco:

Ein AKS würde mehr Freiheiten bieten, wenn die Charaktere frei bewegbar sind, also sich nicht an das Raster der Map-Tiles halten müssen (was mMn in Betracht gezogen werden sollte, die Bewegungen wirken dann natürlicher)

Womit wir wieder am Punkt "Tiles oder nicht?" wären. Wie ich schon schrieb, freie Bewegungen würden mir durchaus gefallen, aber der höhere Arbeitsaufwand ist nicht zu unterschätzen (und zwar nicht nur für den Programmierer, sondern auch für die CPU - pixelexakte Berechnungen werden freilich mehr Rechenleistung kosten).

Zitat von Aco:

Dementsprechend müsste allerdings auch ein System ausgeklügelt werden, das dem Nutzer die Möglichkeit gibt, Fähigkeiten, Animationen und Chara-Status nicht nur zu erstellen, sondern auch beliebig miteinander zu kombinieren.

Die Kombination der Graphiken wird in der Praxis höchstwahrscheinlich über ein Array gelöst, d.h. eine Liste, in der sämtliche zu benutzenden Graphiken für eine Animation einfach hintereinander liegen. Wie dieses Array erstellt wird, lässt sich leicht mit Zugriffsindices oder sogar -koordinaten auf Teilbereiche eines "Animations-Tilesets" lösen. --Q 13:33, 18. Jun. 2010 (UTC)

Mir ist grade noch ein KS eingefallen. Nicht, dass es wirklich für das Maker-Basis-System relevant wäre, dennoch will ichs zumindest nennen, und wenns nur als Anregung für Erweiterungen ist. Es gibt noch diese Taktik-KS, wie mans aus Shining Force (oder aktueller: Advance Wars) kennt. Man bewegt seine Einheiten auf einer Art Schachbrett und kann mit diesen verschiedene Aktionen ausführen. Jede Einheit hat natürlich nur eine begrenzte Schrittweite und Waffenreichweite. Ich denke, das Prinzip ist klar. Ich dachte, ich erwähne es mal, da es immerhin auch in den guten alten SNES-Spielen mal zur Anwendung kam. --Aco 18:34, 22. Jun. 2010 (UTC)

Das CTB (Conditional Turn-Based Battle) welches in vielen Final Fantasy Teilen verwendet wird, würde ich gerne in den Maker integrieren. Dabei ist es eigentlich auch nicht wirklich wichtig ob wir ein Raster benutzen, mit Raster würde das ganze sicher einfacher ablaufen deswegen würde ich es auch vorziehen. Das CTB ist komplett rundenbasiert und im Prinzip genau das, was schon angedacht war: Ein Kampfsystem bei welchem in einer Tabelle die Reihenfolge der Kämpfer steht; diese wird festgelegt indem verschiedene Faktoren der Kämpfer wie z.B. Geschick des Charakters oder auch Zustände wie z.B. (aus FF) Hast oder Gemach verglichen werden. Das Taktik-KS, welches von Aco erwähnt wurde kenne ich aus Fire Emblem und habe auch nur positive Erfahrungen gemacht. Am liebsten würde ich verschiedene KS integrieren und den Spieleersteller entscheiden lassen, jedoch könnte man soetwas natürlich auch noch im nachhinein einbauen :-) --Crucki 21:33, 2. Jul. 2010 (UTC)

das hier ist cool daran könnte man sich orientieren --Hanmac 09:58, 3. Jul. 2010 (UTC)

Das sieht... heftig aus. Tatsächlich wäre es wohl ein absolutes Ideal, das zu erreichen uns jedoch sicherlich die Zeit fehlt... Vielleicht auch nicht, aber da wir ohnehin grundverschiedene Kampfsystemtypen anbieten wollen, lässt sich das auch später noch nachholen.
Ich sehe schon, am Raster für den Maker scheiden sich die Geister... Ich denke, der Vorschlag "Kartenraster Ja, Eventraster Nein" ist schon ganz ordentlich, halte mich aber daraus, da ich sowohl mit dem einen System als auch mit dem anderen klarkäme. Intervention gibt es nur, wenn ich den Arbeitsaufwand explodieren sehe. ;-) --Q. 11:20, 3. Jul. 2010 (UTC)

Sound- und Graphikquellen

Für Sounds fand ich http://www.freesound.org, das aber ähnlich unserem Gosu-Problem nur nichtkommerzielle Verwendung erlaubt. Gibt es jemanden, der soundmäßig talentiert ist und ein Mikrophon für relativ brauchbare Aufnahmen besitzt? --Q 15:34, 6. Jun. 2010 (UTC)

Also ich würde für Sounds und Grafiken in den bestehenden RPGMaker Foren/Fansites/usw Leute rekrutieren, die ihre Sets vllt zur Verfügung stellen, oder für uns welche beisteuern (die Könnten dann ja als Dank als Alphatester oder so werden, wenn sie das wünschen.) Überhaupt würde ich versuchen ein paar Pro's im RPGMaken zu finden, die uns beraten können (was fehlt ihnen beim uns und beim Maker. Wo sehen sie Schwachstellen. Was braucht man am häufigsten? Es nutzt ja nichts wenn wir 100 Arbeitsstunden investieren eine Komponente zu entwickeln, die am Ende nur 0,01% der User einmal im Jahr verwenden) --Kjarrigan 06:07, 7. Jun. 2010 (UTC)

Hmmmmmmm... Das muss doch dann wie ein tätlicher Angriff auf wirklich eingefleischte Fans wirken, so nach dem Motto: "Was willst du denn hier? Wir sind hier doch eine zufriedene Gruppe, nimm deine Nachmache sonstwohin mit". Man kann doch nicht in einem Windows-Forum für Linux werben... --Q 12:58, 7. Jun. 2010 (UTC)

Nicht so pessimistisch ;-) Der optimistische Ansatz sagt, dass wir eine Reihe von Usern finden, die sich gern an unserem Maker beteilligen, weil sie die Chance haben Dinge zu ändern, die ihnen schon immer missfallen :-D Vllt kopieren die Original Maker Macher ja auch ein paar Features von uns :-p. Also wenn ich mal Zeit hab werd ich in 2-3 Makersites ne Nachricht hinterlassen, dass Ideen, Grafiker, Coder und Sound'ler gern gesehen sind (und wenn ichs tarnen muss als, "Was mich schon immer am Maker gestört hat - Umfrage" tarnen muss --Kjarrigan 13:35, 8. Jun. 2010 (UTC)

Vielleicht könnt ihr von der Seite hier was gebrauchen: http://www.pacdv.com/sounds/index.html Darf man anscheinend frei verwenden. Ansonsten bastele ich manchmal was mit MusicMaker zusammen. Hier in Spanien gibt es eine Zeitung namens ComputerMusic, die immer lizenzfreie Samples enthält, die man auch kommerziell benutzen darf, solange man nicht die einzelnen Samples anbietet. Vielleicht könnte man damit etwas basteln... --Barcellona 13:35, 19. Jun. 2010 (UTC)

Die Website sieht gut aus, die scheinen einige Sounds zu haben. Aber das schmale Statement auf der Homepage, man könne die Sounds überall frei verwenden, gibt keine rechtliche Sicherheit; ich brauche einen juristisch sicheren Text wie "All sounds files that are available from this web page (http://...) are not covered by any licensing terms and in the public domain" oder einen Verweis auf eine der CC-Lizenzen. Mit den Worten von GNU: "Frei im Sinne von Freier Rede, nicht im Sinne von Freibier." Problem dahinter sind Kabbeleien ums Urheberrecht insbesondere in Deutschland: Nur wenn der Autor eines Werks sein Werk explizit frei gibt, darf jemand dieses Werk nutzen, ohne das Urheberrecht zu verletzen (sog. "Linux-Klausel") - solange er den Namen des Autors nennt, denn es ist in Deutschland unmöglich, seine Autorschaft an einem Werk abzugeben. Ich möchte nicht, dass wir Ziel eines übereifrigen Anwalts werden... :-( --Q. 16:29, 20. Jun. 2010 (UTC)

Am Ende komponieren wir eben selber oder wandeln ein paar schöne Lieder in Midi's. Wie gesagt denke ich auch dass wir hier einige Makerquellen nutzen können, wenn wir nur fragen. Wir haben ja den "Vorteil" dass der Maker schon viele Jahre exisitert und sich eine breite Community aktiver Skripter, Zeichner, Musiker, kurzum Künstler gefunden hat die die Gemeinschaft mit Material bereichern. Außerdem haben wir erstmal andere Sorgen außer der Musik (btw würd ich mir aber eine Standardtastenbelegung wünschen um lauter oder leiser zu stellen, denn bei dem Spiel das ich gerade Spiel kann ich nur den Ton aus oder abschalten - was die Engine bereitstellt - aber leiser geht nicht. Ich höre nämlich gern mal meine eigen Musik nebenher und möchte aber die Umgebungsgeräusche und so in einem erträglichen Maß doch noch hören)--Kjarrigan 07:23, 21. Jun. 2010 (UTC)

Selbst komponieren hat was ;) Vor allem, da ich vor kurzem mal zu algorithmischer Musik recherchiert hatte, und sich hier was recht nettes finden liess: http://reglos.de/musinum/
Da spielt man ein bisl mit den Parametern rum und kriegt mit etwas Glück ganz nette Stücke. Midi natürlich.
Sonst fiele mir noch Newgrounds ein, die Werke sind zur Weiterverwendung freigegeben, man muss allerdings Namen nennen und die darauf basierenden Arbeiten unter ähnlichen Lizenzen freigeben, ausser man spricht vorher mit dem Künstler und der gibts dann auch für kommerzielle Zwecke frei... Genauen Gesetzestext kann man sich auf der Seite durchlesen. --Aco 09:50, 21. Jun. 2010 (UTC)

Guten Morgen der Herr ;-) Durch algorithmen generierte Musik ? Na da :-D Vielleicht hat ja auch jmd ein Keyboard mit entsprechenden Kabeln zum Rechner oder man nimmt gleich so ein Keyboardprogramm, allerdings kann man da nicht ordentlich spielen auf der Tastatur (habs schon versucht). Wir finden schon was. Und Volkslieder gibts es ja auch allerhand die man aufnehmen könnte (also nicht gerade deutsche, aber die Insel hat schon ein paar schöne Werke zu bieten - Old Lang Syne, Greensleves, ...) wenn man die noch durch den Mixer dreht bekommt man auch Schwungvollere Sachen :-D --Kjarrigan 10:35, 21. Jun. 2010 (UTC)

 »Muss i denn, muss i denn...« 
 ;-) Nein, ernsthaft. Ich kenne mich in der englischen Volksliederszene nicht wirklich gut aus, aber wenn's da was ansprechendes gibt... Warum nicht? Setzt aber bei der Vertonung nicht auf mich, ich bin unmusikalisch und spiele auch kein Instrument (außer das Klappern der Tasten meiner Tastatur geht als Musik durch). Interessant wird das insbesondere dann für den Spieler, wenn er die Melodie erkennt :-) --Q. 17:17, 22. Jun. 2010 (UTC)

gobale variabeln

Der maker hat ja einige globale variablen ala $game_* und wir sind ja nicht so für globalen variablen ... was aber wenn man zb in einer Instanz der Game::Enemy die Daten einer Instanz der Game::Party zugreifen will, es aber anstonsten keinen bezug gibt? ich habe das so geregelt das Game gleichzeitig als Hash fungiert ala Game[:key]#=Game::Party objekt ... auch gut, man könnte für die save files, einzig den game hash speichern oder? --Hanmac 11:46, 7. Jun. 2010 (UTC)

Prinzipiell denk ich, dass so ein Hash schon ne Option sein könnte. Aber dein Bsp versteh ich noch nicht ganz. Enemy möchte auf Party zugreifen ohne einen Bezug? Wenn wir mal davon ausgehen, dass Enemy zBsp PartyMember 1 angreift, dann muss ermittelt werden ob er trifft wieviel Schaden usw und dazu sind die Werte beider nötig. In so einem Fall würde ich die Instanz übergeben, also player.attacks(enemy). Und dann kann man ja auf alle Attribute bequem zugreifen. Ich habe mit dem Maker nicht allzulang hantiert. Was wird denn in solchen $game_* Variablen festgehalten ? --Kjarrigan 12:06, 7. Jun. 2010 (UTC)

in meinem bespiel generiert die game::enemy class die zu erhaltenen items, wenn aber bestimmte quests aktiv sind (sind in der game::party) sollen weitere items generiert werden. beim maker sind die $game_* variabeln die laufzeitvariabeln welche in die save files gespeichert werden (auser vllt game_temp), wenn man die alle auf einmal mit einem hash dumpt, schützt das auch davor das er einige objekte doppelt macht .. --Hanmac

Eine ähnliche Idee hatte ich auch schon, ich würde den Hash aber lieber als unabhängige Konstante sehen, da er ja höchstwahrscheinlich Informationen aus allen Ecken und Enden des Spiels enthalten wird (z.B. ob das Spiel im Vollbildmodus gestartet werden soll), also eine Konstante auf dem höchsten Namespace ::GAME_SETTINGS oder ::GAME_INFORMATION. --Q 13:03, 7. Jun. 2010 (UTC)

Eventhandling

So, also wie in DSL angekündigt, ein eigenes Thema. Die Idee ist momentan einen eigenen Thread zu machen für einen Timer und einen um Jobs in einer QUEUE platziert die die Hauptschleife einfach abarbeitet. Zwischenschritte in der Bewegung könnten wie folgt integriert werden: Es wird sich 1px / Neuzeichnung bewegt. Per Modulo wird nach halber Feldbreite die Grafik auf den Zwischenschritt gesetzt.

Eine Gedanke kam mir dazu noch. Wie löschen wir Elemente aus der Jobqueue? Wenn nämlich zum Bsp jmd nach rechts läuft (und die Taste gedrückt hält) werden ja ständig Laufelemente hinzugefügt. Wenn der Spieler dann aber die Taste loslässt müssten alle Laufaktionen entfernt werden und nur die letzte zu Ende geführt werden. --Kjarrigan 16:21, 13. Jun. 2010 (UTC)

Ich weiß zwar nicht, wieso sich diese penetrante Überschrift nicht nach links verschieben lässt, aber einen Job aus der Jobqueue zu löschen, sollte sich durch einen Stack erreichen lassen. Grundsätzlich wird der Job, der ausgeführt werden soll, erst einmal (per #shift) aus dem Array gezogen. Handelt es sich um einen "normalen" Job, d.h. einer, der nicht zu wiederholen ist (@repeating setzen, vielleicht?) ist er damit durch und weg. Eine zu wiederholender Job wird einfach wieder an das Ende der Jobqueue angehängt. Um einen solchen Job zum Beenden zu bewegen, brauchen wir nur eine Methode Job#stop, die @repeating auf false setzt. --Q 17:49, 13. Jun. 2010 (UTC)

Feldforschung

Ich hab mir gestern mal ein "aktuelles" von den Usern als Super bewertetes RPGMakerXP Spiel geladen und teste das nun mal an um zu sehn was moment überhaupt geht. (Hab das erste Kapitel fast durch und muss sagen, Grafikmäßig genial und das KS ist super). Ich muss dann vllt doch mal die 30tage Testversion laden, um zu sehn was der Entwickler davon selbst gebaut hat, und was der Maker standardmäßig mit sich bringt. Dann hab ich noch 2-3 Community-Seiten (auch ein Wiki) entdecken können, wo auch einiges zu den Makern und ihren Features steht. Zum Bsp gibts es mittlerweile ein "SimpleEvent" (Türen, Truhen und Teleporte, also das was einen Großteil ausmacht), was man durch einfach klicken ohne jegliches Scripten einfügen kann. - Da die Grafik denke ich auch sehr von den *sets abhängig ist, werd ich mir mal ein paar aus dem Spiel hernehmen und mit Gosu eine Map bestehend aus diesen Teilen "nachbauen" und mal vergleichen, ob wir die gute Qualität der Ausgangsdaten auch ausschöpfen können. --Kjarrigan 06:00, 16. Jun. 2010 (UTC)

Nur aus Interesse, welches denn? Ich habe seinerzeit mal "Hybris" gespielt, fand ich ganz nett, bin aber nie bis zum Ende gekommen. Inzwischen ist es zusammen mit meinem alten Windows untergegangen. :-)
Diese "SimpleEvents" hören sich gut an, je weniger Arbeit für den Spieleersteller, desto besser. Ich kann mir allerdings nicht so recht vorstellen, was Truhen und Türen so gemeinsam haben, dass man dasselbe Event dafür verwenden könnte?

Zitat von Kjarrigan:

Ich muss dann vllt doch mal die 30tage Testversion laden, um zu sehn was der Entwickler davon selbst gebaut hat

Das wird wohl nur gehen, wenn der Entwickler "quelloffen" ( :P ) arbeitet. Es würde mich wundern, wenn der RPG-Maker seine nette Option, eine einzelne Executable zu erstellen, verloren hätte.
Btw. ich habe mal ein bisschen an der Diskussionsseite rumgebastelt, das Layout stimmt jetzt wieder. Neue Themen besser vor DSL anfangen, die MediaWiki-Software macht da irgendwie Murks. --Q 19:25, 16. Jun. 2010 (UTC)

Das Spiel heißt "Charon - Dawn of a Hero" und das hab ich auf einer der Maker-Fanseiten gefunden (ich werd mal die Links hier noch ergänzen, wenn ich wieder zu Hause bin). Und die Simple Events sind getrennt schon getrennt :-p Man klickt rechts auf ein Feld und kann dort neben "Event erstellen" auch einen Unterpunkt "Einfache Events" auswählen, der aufklappt und dort sind dann die meist gebrauchten Standarddinge auswählbar.

1
2
3
4
5
6
7

+---------------+
|Event erstellen|
| . . .         |--------+
|SimpleEvent >> |Tür     |
| . . .         |Truhe   |
| . . .         |Teleport|
+---------------+--------+

und ich fürchte du hast recht mit dem "Quelloffen". Beim RPG Maker 2000 ging das eig immer wenn ich mich recht entsinne, aber das moderne Zeugs wohl nicht :-p, na dann muss ich eben mit den Grafiken vorlieb nehmen und so mit der Testversion vergleichen. Was gibts dort und was hat er :-D dann weiss ich zwar nicht wie er es gemacht hat aber was. EDIT: Ich weiss jetzt warum die Überschriften sich verschieben :-D Du darfst die "source" Elemente nicht mit "::" einrücken --Kjarrigan 05:59, 17. Jun. 2010 (UTC)

Was ein Murks mit den Doppelpunkten. Mal schauen, ob ich da einen Bug ans MediaWiki sende (muss ich zwar erst suchen, aber mal schauen). Egal, danke für die "Reproduzieranleitung"! :-)
Was die SimpleEvents angeht: Der Maker handhabt es also so, dass da ein ganz normales Event erstellt wird, nur eben mit ein paar Voreinstellungen? Na, das können wir aber auch. Ich bin dafür, den Menüpunkt für den Benutzer modifizierbar zu gestalten, sodass er auch andere Events zu diesem "Kurzzugriff" hinzufügen kann, aus Vorlagen vielleicht, die er anlegen kann.
Letzter Punkt: Wer hat sich den Quatsch mit den Truhen eigentlich ausgedacht? Ich sehe immer wieder Truhen in Videospielen aber... Welches gottverdammte Monster kommt auf die Idee, die Sachen, die es bewacht, in Truhen aufzubewahren? Warum nicht gleich noch eine Küche und einen Kleiderschrank ergänzen? :-P --Q 12:22, 17. Jun. 2010 (UTC)

Also ich finde eine "Truhe" als Sinnbild für Schatz schon in Ordnung. In den meisten Spielen sind die ja auch nur in Dungeons und Häusern und so, also da wo die auch hingehören. In nem Wald Truhen...na ok, das mag mal noch gehn, denn man kann ja schlecht "Graben" es gibt aber auch genug, die dann leicht andersfarbigen Boden machen wo man dann was finden könnte. Ein Monster das ne Kiste fallen lässt find ich allerdings auch unmöglich ;-) Aber zum Glück, ist das eher die Ausnahme. Die Idee mit den Templates für Events ist nicht schlecht. Am besten merkt sich der Editor auch die letzten Einstellungen, eines Events, so dass man im Idealfall keine oder nur wenige Anpassungen machen muss. --Kjarrigan 06:02, 18. Jun. 2010 (UTC)

Da hier grad die Truhen angesprochen werden: Wie soll das Inventory dann standardmäßig gehandhabt werden? Mögliche Varianten wären: RPGMaker-Standard (unendlich viel Platz im Rucksack, aber nur XY Stück desselben Items, weil die Zählvariable an die Obergrenze stösst, jedes Item ist stackable), Diablo-like (begrenzter Rucksackraum, Gegenstände haben eine räumliche Ausdehnung), D&D (Gewicht der Gegenstände gegen eigene Kraft). Dementsprechend Kombinationen davon, dazu dann noch ne eigene Schatztruhe um Gegenstände abzulegen etc.... Am einfachsten sollte sicherlich die erste Variante sein, aber inwieweit sollte man für die anderen Möglichkeiten schon "vorprogrammieren" bzw welche davon integrieren und zur Auswahl anbieten? --Aco 11:27, 18. Jun. 2010 (UTC)

Juhu. Schön, dass du meinem Ruf gefolgt bist ;-) @Quintus: Aco ist ein Freund von mir, den ich mal "angeheuert" habe, weil er mehr Makererfahrung hat als ich. Zwar kein Rubyist, aber was nicht ist :-p Ja, also Inventar. Kein Diablo. Beim D&D (zumindest wenn ich mich an Baldures Gate erinner) gab es sogar mal Platz+Gewicht. Hm. Also ich würde erstmal primär die gute alte Makerversion Favorisieren mit unendlich Plätzen (da ja Skills eig das gleiche Menudesign ham, wäre das also nur einmal entwickeln und eben nur einmal mit Stack einmal ohne). Öhm. Stackgrößen. 99 wars beim Maker richtig? Hm ich würde sagen dass behalten wir so bei. Da fällt mir ein. Gibts im Ruby eig Shortint ;-) Das könnte man dann ja hier verwenden zum Platzsparen :-D Da wir ja aber auch nen Expertenmodus in Erwägung ziehen sollte man vllt drüber nachdenken unseren Items eine Methode mitzugeben, um da weitere Attribute hinzuzufügen (Gewicht zbsp). Dann kann der Entwickler immer noch ein Gewichtssystem implementieren --Kjarrigan 11:42, 18. Jun. 2010 (UTC)

Je mehr wir sind, desto besser. Und Ruby oder nicht, was wir in jedem Fall benötigen, sind Ideen. Je mehr davon, desto besser. Und wie du schon sagst, Ruby lernen ist kein Problem. Ich für meinen Teil bin überhaupt erst über den RPG-Maker XP nach Ruby gekommen. ;-)

Zitat von Kjarrigan:

Am besten merkt sich der Editor auch die letzten Einstellungen, eines Events, so dass man im Idealfall keine oder nur wenige Anpassungen machen muss.

Klassischer Fall für Konfigurationsdateien, würde ich sagen. Ich bin dafür, welche in YAML zu schreiben, sodass man sie auch von Hand editieren kann. Selbstverständlich sollten wir das aber auch über die GUI des Makers ermöglichen.

Zitat von Kjarrigan:

Gibts im Ruby eig Shortint ;-) Das könnte man dann ja hier verwenden zum Platzsparen :-D

Ruby als typenunabhängige Sprache bietet das selbstverständlich nicht, es sei denn du klopfst den Unterschied zwischen Fixnum und Bignum breit... ;-)

Zitat von Aco:

Am einfachsten sollte sicherlich die erste Variante sein, aber inwieweit sollte man für die anderen Möglichkeiten schon "vorprogrammieren" bzw welche davon integrieren und zur Auswahl anbieten?

Zitat von Kjarrigan:

unseren Items eine Methode mitzugeben, um da weitere Attribute hinzuzufügen (Gewicht zbsp). Dann kann der Entwickler immer noch ein Gewichtssystem implementieren

Hm. Mit Metaprogrammierung ist das kein Problem, aber so recht gefallen mag es mir nicht, das ist eigentlich der typische Anwendungsfall für Vererbung... Moment! Der Entwickler könnte das mit Mixins lösen, oder? Er braucht sie dann nur nachträglich in die Item-Klasse integrieren. Zudem bräuchten wir eine Methode Item#can_pick_up? oder so ähnlich, die der Entwickler in seinem Mixin überschreiben kann, falls das erforderlich wird. Standardmäßig prüft diese Methode einfach nur den Stand der Zählvariablen (oder was auch immer), der Rest kann plugin-artig per Mixin erledigt werden. Quasi:

1
2
3
4
5
6
7
8
9
10
11

module MyNewItemSystem
  
  def can_pick_up?(item)
    #I don't want the player to use items, he's stupid!
    false
  end
  
end
class Item #Öffnen der bereits vorhanden Item-Klasse
  include MyNewItemSystem #Überschreibt das alte Item#can_pick_up?
end

--Q 13:18, 18. Jun. 2010 (UTC)

EDIT: Vergesst das mit den Mixins. Ich hab's gerade probiert, das Einbinden eines Mixins überschreibt keine bereits definierten Methoden. Vielleicht sollten wir irgendwas mit Vererbung machen? --Q 13:24, 18. Jun. 2010 (UTC)

es geht mit Modulen wenn man diese mittels #extend den objekten zuführt anstatt mittels include an die klasse. PS: ich nutze in meinem system codestellen, so vermeide ich alias --Hanmac 07:43, 19. Jun. 2010 (UTC)

Stimmt, das hattest du schon einmal geschrieben, ich muss mir deinen Code noch einmal ansehen. Aber was hat das mit alias zu tun? Bei Mixins gäb's auch kein alias... --Q 11:33, 19. Jun. 2010 (UTC)

ich finde es ist eine blöde idee module zu nutzen wenn man nur eine methode ändert, auserdem sind meine codestellen viel praktischer --Hanmac 18:58, 19. Jun. 2010 (UTC)

Das war nur ein Beispiel. Ich glaube nicht, dass im Endeffekt nur eine einzige Methode geändert wird, wenn man ein komplett neues Item-System einbaut. Ich habe mir noch einmal deinen Code angesehen - inbesondere L-system.rb, denn darum geht es hier wohl - und bin von dem Dreh über UnboundMethod-Objekte schwer überrascht. Das gefällt mir sehr gut! Da der Code aber nun einmal sehr dicht geschrieben ist - könntest du eventuell ein Minimalbeispiel, das nur diesen einen Gedanken verdeutlicht, extrahieren und hier posten? Es könnte auch helfen, wenn du Pseudo-Code oder eine Abarbeitungsliste (z.B. 1. Aufruf von XY zum Initialisieren von AB, 2. Aufruf von foo irgendwo, bewirkt bar...).
PS: Für die Lokalisierung von Sprachen sollten wir eine richtige Lokalisierungslibrary verwenden; siehe dazu das, was ich unter Fertiges Rohgerüst weiter unten geschrieben habe. --Q. 19:34, 19. Jun. 2010 (UTC)

Den Supercall mit den man methoden von anderen Klassen in der Kette aufrufen kann habe ich erstmal rausgenommen weil ich ihn nicht brauche --Hanmac 20:39, 19. Jun. 2010 (UTC)

CodeStellen beispiel

Die Haupt funktion

1
2
3
4
5
6
7
8
9
10

class Battler
  def skill_can_use?(skill)
    return false unless cs_skill_can_use_all(skill).all?
    result = cs_skill_can_use_any(skill)
    return result.empty? || result.any?
  end
end

class Actor < Battler
end

Einbau A

1
2
3
4
5
6
7

class Battler
#ich mach gerne solche funktionen private, weil die in der docu nichts zu suchen haben
private
def aaa_cs_skill_can_use_all(skill)
  return true
end
end

Einbau B

1
2
3
4
5
6

class Battler
private
def bbb_cs_skill_can_use_any(skill)
  return true
end
end

Einbau C

1
2
3
4
5
6

class Actor
private
def ccc_cs_skill_can_use_any(skill)
  return false
end
end

Aufruf

1
2
3
4
5
6
7
8
9
10

actor = Actor.new
actor.skill_can_use?(:xyz)
#Reihenfolge der aufgerufenen Funktionen
#cs_skill_can_use_all (nonexisting)
##Object.methodMissing
##Battler.aaa_cs_skill_can_use_all
#cs_skill_can_use_any (nonexisting)
##Object.methodMissing
##Battler.bbb_cs_skill_can_use_any
##Actor.ccc_cs_skill_can_use_any

der vorteil ist das alle 3 Einbauten völlig unabheänig sind. Klar soweit? --20:39, 19. Jun. 2010 (UTC)

Zumindest um einiger klarer... Wo ist der inhaltliche Unterschied zwischen den _all- und _any-Methoden? Ist _all so gedacht, zu fragen, ob ein Actor/Battler überhaupt Skills verwenden kann und _any die Frage nach einem bestimmten Skill ist, die nur noch abgearbeitet wird, wenn _all überhaupt zutrifft? Abgesehen davon hast du ein paar Tippfehler in deinem Code, den du hier gepostet hast: cs_skill_can_any -> cs_skill_can_use_any etc. Sonst bekommst du beim find_all-Aufruf immer ein leeres Array, was grundsätzlich zu einem Endergebnis von true führt. Btw. ich wusste gar nicht, dass man #any? und #all? auch ohne Codeblock verwenden kann, ohne einen Enumerator zu bekommen. Man lernt bei Ruby doch immer wieder Neues...
Hier noch der Code von Object#method_missing, den Hanmac nicht gepostet hat:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

class Object
  
  def method_missing(methId, *args)
    if /^cs_/.match(methId)
      @__cs_cache ||={}
      unless @__cs_cache.has_key?(methId)
        req = /_#{methId}/
        @__cs_cache[methId] = (methods | protected_methods | private_methods ).find_all { | m | req.match(m) } 
      end
      result = @__cs_cache[methId].map { |m| send(m, *args) }
      if block_given?
        return result.each {|s| yield s}
      else
        return result
      end
    else
      super
    end
  end
  
end

Vielleicht sollte man zumindest das #method_missing in ein Mixin auslagern, das dann in einigen Klassen eingemischt wird, damit wir nicht Object unnötig füllen. --Q. 09:39, 20. Jun. 2010 (UTC)

Ja das war ein tippfehler, war anscheinend schon spät. und du hast recht. das all soll schauen ob irgendwas den skill verhindert (zuwenig MP zb), weiterhin soll any schauen ob etwas den skill erlaubt (bei mir kann man skills auf verschiedene weise lernen, any schaut nach ob es bei mindestens einer davon gelernt wurde). und ja man könnte diesen methodmissing hack in ein mixin auslagern, bei mir wird das aber in so gut wie jeder Klasse gebaucht (die haben zumindest ein cs_init, wodurch ich mir beim hinzufügen eines wertes und dem startwert setzen das alias von initialize sparen kann)
weiterhin glaubst du man braucht die funktion um den cs_cache zu leeren? nachdem ein objekt erstellt wurde wird normalerweise kein einsprungpunkt erstellt. PS: man könnte den cs_cache auch zu einem Non-dumpable objekt machen, weil den braucht man ja nicht speichern oder?? --Hanmac 10:18, 20. Jun. 2010 (UTC)

Zitat von Hanmac:

weiterhin soll any schauen ob etwas den skill erlaubt (bei mir kann man skills auf verschiedene weise lernen, any schaut nach ob es bei mindestens einer davon gelernt wurde)

Ist das nicht Overhead? Du könntest dem Battler/Actor-Objekt einfach ein Attribut @skills verpassen, das die Namen der erlernten Skills als Symbole enthält. Dann reicht ein einfaches #include? zur Überprüfung aus und auch das Erlernen, auf welche Weise auch immer, ist einfacher (player.skills << :fire). Wenn das zu ungenau ist und du Informationen darüber brauchst, wie ein Skill erlernt wurde, könntest du eine Klasse Skill anlegen und die benötigten Informationen darin sammeln (und vielleicht auch gleich Dinge wie die Schadensberechnung darein stecken). Diese Skill-Objekte kannst du dann in @skills stecken.

Das ist da nicht so einfach. es gibt 2 skill klassen: die RPG::Skill, das sind die aus der Datenbank, und die Game::Skill, das sind die die der battler hat, und die skills können auch abhängig der actorclass sein, und deswegen brauch ich mehrere hash (siehe dazu meine files im forum) skill_can_use unterscheidet auch zwischen rpg und game skill, so kann man herrausfinden auf welche weise ein game skill gelernt wurde --Hanmac 17:40, 20. Jun. 2010 (UTC)

Zitat von Hanmac:

weiterhin glaubst du man braucht die funktion um den cs_cache zu leeren? nachdem ein objekt erstellt wurde wird normalerweise kein einsprungpunkt erstellt.

Wahrscheinlich nicht, aber sie frisst ja kein Brot. ;-)

Zitat von Hanmac:

PS: man könnte den cs_cache auch zu einem Non-dumpable objekt machen, weil den braucht man ja nicht speichern oder??

Ich halte das für keine gute Idee. Sonst müsste der Cache während des Spiels wieder gefüllt werden, was unnötig innerhalb des Spiels Performance frisst statt nur einmal beim Laden... --Q. 16:41, 20. Jun. 2010 (UTC)

das wäre jetzt die frage was performater wäre, aber ich bin immernoch dafür das nicht zu dumpen --Hanmac 17:40, 20. Jun. 2010 (UTC)

DSL

1
2
3
4
5

#e sei ein Event
e < 3 #3 Felder nach links
e > 3 #3 Felder nach rechts
e ^ 3 #3 Felder nach oben
e / 3 #3 Felder nach unten (bessere Vorschläge?)

Insbesondere der Operator für "nach unten" gefällt mir nicht, aber ein anderer punktloser fiel mir nicht ein. Weitere Vorschläge, Kritik? --Q 13:37, 8. Jun. 2010 (UTC)

Wir sind hier eig nur zu 3 die Diskutieren oder ;-) Also ich bin eher dafür den Punkt beizubehalten. e.up(5), e.down(3) sieht besser aus, und ist auch leichter verständlich. Eine DSL soll meines erachtens klingen wie eine "Geschichte". Dazu einfach gute Key-Words wählen ;-)

Gegen spricht eindeutig der noch größere Aufwand, und der fehlende Rubybezug. Ich bin entschieden dagegen :-D
Die Scriptsprache muss...

• Spieler manipulieren können (Bewegen, Ausrüstung, Fähigkeiten, Attribute)
• NPC's bewegen können
• Umgebung manipulieren (Hintergrundbild, -musik, Wettereffekte, Tageszeit, Bildschirmwackeln,...)
• Kamera bewegen (ich glaub ich hab dass damals über ein "unsichtbares Männel" gelöst. Ich wäre aber dafür das direkt einzubauen)
• Engine ansprechen (andere Events triggern, Skripte aufrufen, Variablen belegen/auslesen)

(Ich sollte mir vllt doch mal ne Testversion des aktuellen Makers organisieren und mal schaun was der eig so alles kann mittlerweile) --Kjarrigan 07:34, 9. Jun. 2010 (UTC)

Zitat von Kjarrigan:

Eine DSL soll meines erachtens klingen wie eine "Geschichte".

Wunderbarer Ausspurch. Warum liest man sowas nie in seinen Informatik-Arbeitsblättern? Du hast meine vollste Zustimmung. Gut, wir behalten den Punkt. Das ermöglicht außerdem auch noch einen leichteren Umstieg, wenn sich jemand entschließt, "richtig" Ruby zu lernen. Übrigens, im Forum gab es mal diesen Beitrag, das passt dazu. ;-)

Zitat von Kjarrigan:

Wir sind hier eig nur zu 3 die Diskutieren oder ;-)

Scheint so. Aber ich denke, zu dritt bekommt man auf jeden Fall mehr hin als jeder einzelne für sich. Und mal schauen, wenn das Projekt sich etablieren kann, bekommen wir wahrscheinlich noch mehr Zulauf. --Q 19:46, 9. Jun. 2010 (UTC)

Das Märchen gefällt mir sehr gut ;-) So in etwa sollte unsere DSL sein, vllt nicht ganz so sehr "leserlich", aber ich werde es mal als "Referenz" aufnehmen :-D Ich hatte auch schonmal eine erste Liste erstellt welche Befehle unsere DSL umfassen könnte, konnte die aber gezippt nicht hochladen :-( Ich werds gleich nochmal versuchen.

Edit: Hat als *tar* geklappt DSL.tar

--Kjarrigan 07:13, 10. Jun. 2010 (UTC)

Das Problem mit den ZIP-Dateien hab' ich mal an Daniel weitergeleitet. Mit etwas Glück weiß er da mehr...
Konkret zu deinen Vorschlägen: Gefällt mir im Großen und Ganzen gut (die Idee als Mixins ist super!), aber wenn du deine Dateien in UTF-8 schreibst, denke bitte daran, dass auch durch einen Magic Comment am Anfang deutlich zu machen, ich habe in dsl.rb erst einmal jede Menge Zeichensalat gesehen, bis ich auf UTF-8 umgestellt habe. Die Methode Text#print hat mich im ersten Moment irritiert, ich dachte, du hättest sie wie beim RPGXP so definiert, dass sie "richtige" GUI-Messageboxen anzeigt (also z.B. die von Windows und nicht irgendwas in-Game-artiges). Ist aber auch besser so, jene sind ja schließlich auch eher fürs Debuggen und sollten besser über eine Methode #msgbox o.ä. gelöst werden. Sämtliche Events über eine Klassenmethode [] von Player abgreifen zu wollen ist eine gute Idee, aber was passiert, wenn zwei Events den gleichen Namen haben? Verbieten wir gleiche Namen oder halten wir es wie der RPGXP und verwenden eindeutige IDs (die man dann anstatt des Namens angeben muss)? Auch sollte man über den Namen der Klasse Player nachdenken, mit "Player" assoziiere ich erst einmal den Protagonisten, also die vom Benutzer steuerbare Figur. Ein Name wie Character ist vielleicht besser, weil nicht so anstößig und ist vielleicht auch noch eher auf nicht-menschliche Dinge wie Kisten, die ja trotzdem auch hierein fallen, anwendbar (OK - ist eine Kiste ein Character...? Ich möchte eigentlich nicht den Namen "Event" übernehmen, zum einen weil das kopiert wirkt, und zum anderen, weil ich mir nicht wirklich vorstellen kann, was diese Map-Charaktere mit Events im Wortsinn zu tun haben, es handelt sich dabei weder um Veranstaltungen noch um Events, die an eine Engine weitergeleitet werden, um irgendwas auszulösen). Thema Leserlichkeit: Statt mehrzeiligem {...} würde ich do...end verwenden, weil es für einen Unbedarften vermutlich einfacher zu verstehen ist. Letzter Punkt: Anstatt true und false in Klammern als Argumente zu übergeben, ist eine -ing-Form der Methodennamen kombiniert mit dem rubyischeren = in meinen Augen besser, also etwa p.running = false. Anstatt der vielen p. könnte man auch über eine Verwendung von #instance_eval nachdenken, wodurch unser Code noch klarer zu lesen wird, etwa so:

1
2
3
4
5
6
7
8
9
10
11

player[:horst].walk do
  print("[c004400]Horst:[cdefault]Aus dem Weg, ich springe über den Abgrund")
  up(3)
  turn_to(:down)
  run(true)
  down(5)
  jump(true)
  down(15)
  jump(false)
  invisible(true)
end

Durch die Verwendung von #instance_eval setzen wir self innerhalb des Codeblocks auf das Player/Character-Objekt, wodurch die explizite Nennung des Objekts unnötig ist. Nebenbei würde ich das Element des Spielers dann einfach als Konstante Protagonist oder Player, falls mein Character-Klassenname angenommen wird, festlegen, da der ja ohnehin immer verfügbar ist.
Eine Frage noch: Was verstehst du unter dem "Rennen-Modus"? Die Geschwindigkeit eines Players/Characters könnte man doch eher ähnlich dem Maker festlegen, also durch einen Zahlenwert, quasi velocity = 2 oder soetwas? --Q 15:19, 10. Jun. 2010 (UTC)

Guten Morgen Quintus. Du hast da schon ein paar Dinge angesprochen die ich mir über Nacht hab auch noch überlegt ;-) Also das mit dem p im Block wollte ich eig auch nicht, aber auf die mit dem "nochmal" instance_eval und nem auf self gebogenem Block kam mir bei der Hitze gar nicht. Gegen do..end hab ich auch nichts. Ich nehme nur selbst lieber {}, ein end bekommen bei mir nur Module,Klassen, Methoden und ggf rescue Blöcke ;-).

Die -ing Form klingt auch nicht schlecht. So sind die "echten Methoden" von den "nur Flag"-setzenden besser Trennbar. Der Name Player war auch nur Notbehelf. Wir müssten uns bei den "Events" eh mal ein paar passende Bezeichnungen einfallen lassen. Mir gefällt nämlich eig auch nicht, dass ein NPC(,aufsammelbare Blume, ...) ein 1-Feld Event mit Grafik ist. Ich würde eher nach "Interaktionselementen" und "Drauf-Tret-Flächen" trennen. Also "Events" mit Grafik die man durch "Aktion"-Taste aktiviert und solchen die automatisch ausgelöst werden, wenn man x Betritt oder ähnlichem.

'Rennen'-Modus ist einfach schnelles laufen :-D Aber wenn du sagst das im Maker das über velocity war, dann können wir das gern so integrieren. (Meine Maker Erfahrung liegt nur schon etwas zurück, da konnt ich mich nicht dran erinnern).

Das Magic Comment wird gleich angefügt (das mach ich eig sonst immer Oo schon weil es mich nervt den SCite immer händig umzustellen) :-D

Mixins sind denk ich in mehreren Bereichen unseres Makers das Mittel der Wahl um da ne Struktur reinzubringen, Elemente auszulagern und zu warten.

Mal was neues. Neben der DSL mache ich mir gerade Gedanken darüber wie unsere Event-Maschine funktionieren soll. (von der ich gern einen Prototypen hätte um die DSL gleich mit zu testen :-p ) Momentan denke ich daran die Gosu Methoden ::button_down(id) und ::button_up(id) einfach durchzureichen und dann auszuwerten. Dabei würde ich zwischen 3 Arten "unterscheiden". 1. Die unveränderbaren Tastengebundenen Aktionen, wie Bewegen/Aktion/Beenden, 2. globale Scripte, die als Hash zur Verfügung stehen und sich während des Spiels nicht ändern und zu letzt einem dynamischen Hash, der immer gerade die Events der aktuellen Karte referenziert. Diese Hash spannt ein "Netz" über die Karte um zu wissen, wann er drauf steht. Außer den Button-Methoden, kann sonst nur der Handler durch sich selbst ausgelöst werden (als Aktion eines anderen Events, oder nach einer Bewegung die auf einem Event Feld endet). So brauchen wir keinen Pollingprozess der ständig probiert ob was pasieren könnte, sondern es wird nach jeder Spielerausgelösten Aktion geprüf (hier ist ggf für die Performance zu optimieren). Was wird aber mit "zeitgesteuerten Events" (Gibts es Tageszeitwechsel, auch wenn der Spieler keinen Schritt macht?, sollen auch Aufgaben mit Timer möglich sein?), vllt kommt noch nen Timeout oder so rein. Wenn ne Minute nix passiert, dann soll er eben mal prüfen ob was zu tun ist. Oder es läuft seperat eine Instanz nur für Zeitgesteuerte Dinge. Das wars erstmal wieder von mir. Grüße, --Kjarrigan 06:11, 11. Jun. 2010 (UTC)

Zitat von Kjarrigan:

Dabei würde ich zwischen 3 Arten "unterscheiden".

Vielleicht bin ich heute etwas langsam, aber drei Arten von was? Von Eingaben? Was haben Eingaben mit Skripten zu tun?

Zitat von Kjarrigan:

Diese Hash spannt ein "Netz" über die Karte um zu wissen, wann er drauf steht.

Dynamität kostet immer Performance. Die Karte hat eine fixe Größe, wir sollten ein zweidimensionales NArray verwenden, das dank C-Implementation sehr viel schneller unterwegs ist als wir mit Ruby.
Selbstgeschriebene Skripte legen wir am besten in einem Ordner scripts (entweder als Unterordner von lib oder direkt im Toplevel) ab, dessen Inhalt wir dann nur noch auslesen. Aber warum sollte man die Skripte als Hash anlegen? Willst du sie während des Spiels "immer mal wieder" aufrufen? Insbesondere bei Klassendefinitionen macht das doch wenig Sinn, oder?

Zitat von Kjarrigan:

Was wird aber mit "zeitgesteuerten Events" (Gibts es Tageszeitwechsel, auch wenn der Spieler keinen Schritt macht?, sollen auch Aufgaben mit Timer möglich sein?)

Das sollte sich mit einem separaten Thread doch ganz prima lösen lassen, oder? Der nebenläufige Thread fügt dann am besten einen Aufruf in eine Jobqueue ein, die normalerweise leer ist, aber in jedem Durchlauf des Mainloops einmal überprüft wird. Quasi:

1
2
3
4
5

1. Der Mainloop klappert ein JOBQUEUE-Array ab (noch leer in diesem Moment)
2. Ein in einem nebenläufigen Thread signalisierender Timer läuft ab
3. Der nebenläufige Thread platziert einen Job in der JOBQUEUE
4. Der Mainloop sieht bei seinem nächsten Durchlauf den Job in der JOBQUEUE und führt ihn aus. 
5. Der Job wird aus der JOBQUEUE entfernt.

So wird die zeitintensive Operation (das, was das Event tun soll) in den Hauptthread verlegt, obwohl das Event durch einen anderen Thread ausgelöst wird, und zudem Konflikte vermieden (was, wenn das Event sich noch während des Ausführens im Nebenthread im Hauptthread selbst auslöst?). Die JOBQUEUE-Konstante wäre dann allerdings eine shared resource und müsste mit einem Lock, vielleicht einem Mutex-Objekt, versehen werden, dessen Überprüfung jedoch auch wieder Performance kosten würde... Was meinst du dazu? --Q 15:43, 11. Jun. 2010 (UTC)

Also die 3 Arten hab ich doch danach aufgezäjlt ;-) Feste unveränderliche Skripte (auf bestimmten Tasten). Globale Skripte und Skripte die je nach Karte wechseln. In den Hash würde ich Referenzen auf das Skript hinterlegen (also das ID-Konzpet vom Maker "übernehmen"). Das NArray können wir ruhig verwenden. Mit dynamisch war nur der Wechsel der ReferenzIds im Hash gemeint. Und das "Netz" sind dan neinfach 2 NArrays, eins für die Map(grafiken) und eins für Events. Die Events auf einer Karte sind natürlich fest.

Threads hab ich bisher eher weniger in meine Überlegungen eingeschlossen, weil ich (mit 1.8) unter Windows bisher nur Ärger hatte. Ich hab in letzter Zeit auch mal bisl mit mehreren Prozessen gearbeitet (via fork), aber dass kann Windows ja auch nicht, wäre aber grade für Multicore-Rechner brauchbar. Da müss mer noch paar Konzepte erstellen. So ne Art Queue hat ich aber auch im Plan hinsichtlich Bewegungsereignissen, da ja "Zwischenschritte" gemacht werden müssen zwischen den Feldern, da die Figur ja sonst springt und Gosu auch 60mal pro sec neuzeichnet. Hier muss irgendwo noch ein Timer rein, damit die Figur "läuft" und nicht teleportiert. Mutex müsste denke ich auf jeden Fall, wenn wir beim Thread bleiben. Ích muss wohl dochmal 1.9.x hinsichtlich Thread verhalten auf meinem alten Rechner mit Windows XP testen. (Meine ToDo Liste wird immer länger) --Kjarrigan 10:49, 13. Jun. 2010 (UTC)

Ruby 1.9 implementiert Threads anders, anstatt der "Green Threads", also im Interpreter implementierten Threads, werden nun die Threads des Betriebssystems verwendet. Tatsächliche Parallelität (auf Mehrkern-Systemen) wird allerdings nicht erreicht, weil Ruby einen GIL besitzt. Der Global Interpreter Lock ist ein Relikt aus den Anfängen von Ruby, wo man von Mehrkernigkeit nicht einmal träumte. Ich hege die Hoffnung, dass er mit Ruby 2.0 entfernt wird. Für Prozesse kann man auf Windows das win32-process-Gem verwenden, aber selbst damit ist es noch recht schwierig, #fork ist nicht vernünftig implementiert (will heißen, es ist das gleiche wie system("ruby '#{$0}'")).

Zitat von Kjarrigan:

So ne Art Queue hat ich aber auch im Plan hinsichtlich Bewegungsereignissen, da ja "Zwischenschritte" gemacht werden müssen zwischen den Feldern,

Mehr oder weniger aus diesem Anlass hatte ich die auch im Kopf. Bei meinem ursprünglichen Ansatz mit Rubygame hatte ich das so gelöst, dass ich einen sich stets wiederholenden Job in der JOBQUEUE platziert hatte, der ein Event immer um 1 Pixel verschob, und sobald er eine bestimmte Anzahl an Pixeln zurückgelegt hatte (getestet per Modulo-Rechnung), wurde die Graphik des Events geändert. Nachdem es die angegebene Entfernung zurückgelegt hatte, elimierte der Job sich selbst. Auf diese Weise war kein extra nebenläufiger Thread oder Prozess notwendig. Beispiel: Ein Event soll 1 Feld hoch gehen, 1 Feld sei dabei 32x32 Pixel groß:

1
2
3
4
5
6
7
8
9
10

0. Ausgangszustand mit noch unveränderter Graphik
1. Graphik auf Stehend (nach oben gerichtet) ändern
2. 10-mal ein Pixel nach oben
3. Graphik auf Laufbild 1 (nach oben gerichtet) ändern
4. 10-mal ein Pixel nach oben (insgesamt jetzt 20 zurückgelegt)
5. Graphik auf Laufbild 2 (nach oben gerichtet) ändern
6. 12-mal ein Pixel nach oben (insgesamt jetzt 32 zurückgelegt)
7. Bei größerer Geschwindigkeit als 1px/r sicherstellen, dass das Event pixelexakt auf dem richtigen Feld steht
   (bei 3 wäre es ja beispielsweise dahinter gelandet)
8. Graphik auf Stehend (nach oben gerichtet) ändern.

Für größere Geschwindigkeiten habe ich einfach den Pixel-pro-Durchlauf-Wert (px/r, pixel per run) erhöht (wobei da das Sicherstellen der Position wichtig ist, siehe oben).
Aber sollten wir für diese Diskussion ein eigenes Thema aufmachen, das passt nicht mehr unter die Überschrift "DSL". --Q 15:57, 13. Jun. 2010 (UTC)

DSL schön und gut, aber ich finde beim maker sollte man das auch klickbar machen wie beim orginal --Hanmac 18:58, 19. Jun. 2010 (UTC)

Das schließt sich ja nicht aus. Bei Klicken werden einfach die entsprechenden Befehle eingefügt; ich glaube aber nicht, dass viele Leute beim Klicken bleiben werden, wenn sie es sehr viel schneller von Hand tippen können (weswegen ich überhaupt erst auf die Sache mit der DSL gekommen bin). Aber das dürfte wirklich keine große Herausforderung beim Einbauen sein. --Q. 16:16, 20. Jun. 2010 (UTC)

Ich denke auch das ein Zusammenklick Frontend rein muss, aber sowas lässt sich ja per Option aktivieren und deaktiveren und ist erstmal eine DSL definiert ist das drübersetzen einer Oberfläche eine reine Tippübung, da die Befehle ja klar durchstrukturiert und festgelegt sind. Die GUI schreibt dann eben ein DSL Skript im Hintergrund, so dass der User die Möglichkeit hat etwa ein Gerüst zusammzuklicken und dann den Feinschliff im Code zu tätigen --Kjarrigan 07:19, 21. Jun. 2010 (UTC)

Textausgabe

Hier mal eine erste Idee einer Textausgabe im Stile des Makers via Gosu. Hab da ein bisschen rumprobiert. Der Code ist auch noch nicht optimal aber ich denke aufgeräumt genug um ihn zu verstehen. Es gibt noch einige kleinere Probleme die am Dateiende und in Kommentaren festgehalten sind. Wer das mal ausprobieren möchte dem empfehle ich den Code erst einmal auszuführen und dann nachzusehn was gemacht wird ;-) Am Anfang erscheint übrigens ein schwarzer Bildschirm, los gehts durch drücken einer beliebigen Taste (außer ESC und Windows). Um Kriktiken und Vorschläge wird gebeten (http://wiki.ruby-portal.de/Datei:Screen.tar). Im übrigen werde ich in Zukunft immer wenn ich im Wiki eine Datei hochlade diese auf meiner Userpage verlinken. Wer als keine Lust hat den Text nach dem Link zu durchsuchen klickt nur auf meinen Namen. Der sollte zu finden sein :-p --Kjarrigan 12:20, 17. Jun. 2010 (UTC)

Sieht prinzipiell gut aus - nur läuft das bei mir nicht. Ich werde mir den Code im Laufe des Tages noch einmal vornehmen, aber soweit ich das überblicken kann, frisst mein 1.9 einige Methoden nicht, wie z.B. String#each_with_index, was in 1.9 nicht mehr existiert, weil Strings keine Enumerables mehr sind. Das lässt sich zwar mit .each_line.with_index kompensieren, allerdings bekomme ich dann zwar den ersten Text angezeigt, danach hängt das Programm aber, kein Tastendruck, weder Enter noch Escape, bewirkt irgendwas. Eine Anmerkung noch: Teste deinen Code grundsätzlich mit "ruby -dw", das zeigt dir sämtliche möglichen Warnungen und Informationen zu deinem Quellcode an. Dann wäre dir bestimmt aufgefallen, dass du Text#move_x zweimal definierst, einmal per attr_accessor und einmal als explizite Methode mit def. :-) Wie gesagt, ich werde mir das gleich mal in Ruhe vornehmen und 1.9-fertig machen oder mir eben ein 1.8 kompilieren (aber nur übergangsweise!). --Q 12:58, 18. Jun. 2010 (UTC)

EDIT: Ich habe mich mal rangesetzt und habe einen Parser für Text-Kommandos in Nachrichten-Texten geschrieben. Das Klassenmodell ist erweiterbar, solange zum Erstellen von Text-Kommandos immer die eckigen Klammern [ und ] benutzt werden, sodass man ohne große Codemodifizierung einfach eine Subklasse von Parser::GenericParser erstellen kann, in der man lediglich #parse überarbeitet (siehe am besten den Code selbst). Datei:Parser.rb.gz --Q 15:44, 18. Jun. 2010 (UTC)

EDIT2: Ich habe mich mal durch den Code gewühlt und Verbesserungen vorgenommen. Die größte Änderung ist, dass ich Dialoge und reine Texte in zwei Klassen auseinandergezogen habe, wobei Dialog jetzt eine Subklasse von Text ist. Eine andere Änderung ist, dass ich das Hauptfenster in einen Singleton geändert habe, weil ich globale Variablen nicht mag. Jetzt bekommt man mit GameWindow.instance immer die gleiche Instanz. Ansonsten halte ich es für unrealistisch, dem Hauptfenster lediglich eine Text-Instanz zuzuordnen - was, wenn jemand zwei Texte gleichzeitig anzeigen möchte, sagen wir, während ein Stadtname angezeigt wird, spricht der Spieler eine Person an? Es wäre besser, für jeden Text eine neue Text- oder Dialog-Instanz zu erstellen, die dann per Job in der Jobqueue aktualisiert wird. Hinsichtlich der DSL habe ich keinen Code geschrieben, aber am liebsten wäre mir ein Sandbox-Modell, etwa so:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

module DSL
  
  #Methoden, #Methoden...
  
end

class DSLSandboxBackend
  include DSL
end

class DSLSandboxFrontend < BasicObject
  
  FORBIDDEN_METHODS = [:eval, :system, :"`"].freeze
  
  def initialize
    @backend = DSLSandboxBackend.new
  end
  
  def method_missing(name, *args, &block)
    if FORBIDDEN_METHODS.include?(name)
      raise(Errno::EACCES, "The #{name} method isn't allowed in the DSL scope. Switch to expert mode if you want to use that method.", caller)
    end
    
    @backend.send(name, *args, &block)
  end
  
end

Das ist allerdings noch nicht wirklich ausgereift, IO.popen würde damit immer noch gehen. --Q 11:26, 19. Jun. 2010 (UTC)

EDIT3: Wie blöde muss man eigentlich sein, von Änderungen zu sprechen und den Dateilink zu vergessen? Hier ist meine modifizierte Datei: Datei:Screen3.rb.bz2. --Q 11:27, 19. Jun. 2010 (UTC)

Also ich hatte am Anfang mal eine eigene Klasse für Dialoge hab die dann aber wegrationalisiert :-D Wir können das gern trennen und jeweils neue Instanzen. Hm ich wollte Speicher sparen :-D, aber so ist natürlich das Problem mit den Parametern für best Texte nicht mehr. Aber nen Gosu Font könnten wir einen für alles benutzen (außer es sollen mehrere Fonts verwendet werden) Weil wir einmal dabei sind. Ich hab dumpf in Erinnerung das der Maker gar keine Fonts verwendet, sondern das aus einzelnen Buchstabenbildern zusammenschnipselt ? Deinen Code schau ich mir am Sonntag mal an und ich werd mir auch gleich mal noch ne 1.9.x Version auf meinen Windowsrechner ziehen, wenn wir eh damit entwickeln wollen :-p (Ich würde 1.8.7 ja gern komplett entfernen, aber solang ich das auf Arbeit noch benutze...) --Kjarrigan 17:00, 19. Jun. 2010 (UTC)

Ja, ich glaube, der Maker hat das wirklich aus einzelnen Zeichen gemacht... Da kommen wir mit dem Gosu-Font besser weg. Den können wir in dem CONFIGURATION-Hash festlegen.
Da du zwei Rubys haben wirst, solltest du nicht den automatisierten RubyInstaller nehmen, sonst bekommst du noch Probleme, wann welches Ruby benutzt wird (Stichwort: Wer im PATH zuerst kommt, mahlt zuerst). Nimm lieber das vorkompilierte .7z und ändere den PATH, wenn du das andere Ruby benutzen willst. Das kannst du auch automatisch per Skript erledigen (allerdings brauchst du dazu ein Extra-Werkzeug von Microsoft (ist kostenlos), mit Windows-Bordmitteln kann man keine Umgebungsvariablen per Skript setzen).
Hast du dir mal mein Rohgerüst angeschaut (siehe ein Thema tiefer)? --Q 17:22, 19. Jun. 2010 (UTC)

Falsch, der orginal maker hat eine Font Klasse, die nutzt die schriftarten des systems --Hanmac 18:58, 19. Jun. 2010 (UTC)

EDIT: Ich seh' gerade, setx.exe ist seit Windows Vista standardmäßig dabei. Dann brauchst du doch nichts downloaden! ;-) --Q 17:39, 19. Jun. 2010 (UTC)

So hab mir deinen Code mal angeschaut und bis auf die Tatsache, dass da bei mir im SCite unlesebare Zeichen drin stehen (Zeile 90, vor milliseconds-last) funktioniert es soweit ganz gut und gefällt mir auch vom Aufbau. Und ich habe zuhause ein Windows XP und ein Ubuntu 10.04 im Einsatz ;-) Ich bekomm das mit dem switchen zwischen den Rubyversionen schon hin ich muss nur dran denken :-D Ich werd standardmmäßig auf 1.9 einstellen und nur bei Bedarf 1.8 nehmen, denn die Heim-Test-Phase für Scripte von der Arbeit ist erstmal durch ;-) Zum Font. Gosu hat da ja die Funktion den Systemstandardfont zu nehmen. Vllt finden wir ja mal einen der uns zusagt, denn wir dann fest mitschicken, aber sonst würde ich die automatische Ermittlung bevorzugen (ist evtl nur Problematisch bei der Textbreite). Das Textmodul ist dann ja eigentlich im Rohbau fertig :-D Nun müssen noch später die Einblendung eines Hintergrunds auf Basis einer Grafik erfolgen und die Option Gesichter anzeigen zu lassen. Die Möglichkeit die Farben von Textabschnitten zu ändern stelle ich mir noch etwas problematisch vor. Man müsste ja dazu pro Farbwechsel neu eine font.draw-Methode mit der passenden Farbe aufrufen und das wort an der richtigen Stelle anzeigen lassen (also zumindest x-Berechnen). Alles machbar aber der Gedanke gefällt mir imo noch nicht so recht ;-) müss mer eben mal schaun. --Kjarrigan 07:14, 21. Jun. 2010 (UTC)

Das unlesbare Zeichen ist ein mathematisches Delta. Ich habe ganz vergessen, dass Windows-Schriften nicht besonders viel von UTF-8 halten. ;-) Wenn du rausfindest, wie du die Schriftart in SciTE ändern kannst, gebe ich dir meine Schriftarten (FreeSerif/FreeSans/FreeMono). Oder wir ändern das Delta einfach in ein d_.
Wie und ob wir Sachen wie Farbe und Gesichter implementieren, lässt sich auch später noch entscheiden. Ich habe meinen Parser absichtlich als völlig alleinstehend geschrieben, er zerlegt wirklich nur den Text in Tokens und sonst nichts. Wie diese Tokens interpretiert werden, ist eine ganz andere Frage. Stichwort Font: Was hat does not work on Linux in Font.new zu sagen? --Q. 17:35, 22. Jun. 2010 (UTC)

Fertiges Rohgerüst

So, ich habe ein Rohgerüst für die Verzeichnisstruktur des OpenRubyRMK geschrieben. Ich bitte um Beurteilungen! So wie es jetzt ist, würde ich es auch als "Initial Commit" für git verwenden - einverstanden? Datei:OpenRubyRMK.tar.bz2 --Q 14:40, 19. Jun. 2010 (UTC)
EDIT: Ich habe mal ein locale-Verzeichnis hinzugefügt. Gleichzeitig möchte ich vorschlagen, für die sprachliche Lokalisierung r18n zu verwenden. Ich bin mir nicht sicher, ob es den RPG-Maker inzwischen in verschiedenen Sprachen gibt, aber wir können das mit Sicherheit. Standardsprache sollte Englisch werden, neue Sprachen können mit r18n kinderleicht hinzugefügt werden. --Q 16:49, 19. Jun. 2010 (UTC)

den RP konnte man nicht so leicht übersetzen, weil die schriftarten im system steckten, der VX hatte die texte in einer DLL, aber besser wären sprach pakete, PS: ich habe ein L-modul zur sprachverwaltung gebaut, könnt ihr ja euch mal ansehen --Hanmac 18:58, 19. Jun. 2010 (UTC)

Oh, ich sehe deinen Post hier erst jetzt ('tschuldigung, ich kann nicht alles gleichzeit lesen... [verdammt, wo ist der :oops: Smiley aus dem Forum?] ) und da ich gerade über dein L-Modul gestolpert bin, schreibe ich gleich mal was dazu. Hast du dir r18n angesehen? Das händelt das so, dass die Sprachtexte aus externen Textdateien gezogen werden, die einfach nur YAML-formatiert sind, sodass man im Code selbst nur noch angibt "Lade Standardsprache des Systems" oder "Lade diese oder jene Sprache", den Rest erledigt r18n. Im Code schreibst du z.B. für einen Menüpunkt nur noch t.menu.file.open und bekommst dann für die jeweils gesetzte Sprache "File" oder "Datei" oder ähnliches zurück. Ich finde das einleuchtender als ein großes Hash, in dem alle Sprachen andhand von langen Einzelstrings unterschieden werden. --Q. 19:43, 19. Jun. 2010 (UTC)

Ich habe mal eine Beispiel-GUI geschrieben, die R18n für die Lokalisation verwendet. Das schönste an der ganzen Sache ist, dass jeder Depp die Anwendung übersetzen kann, er braucht nur die externen Text-Dateien editieren, keine Zeile muss er am Quellcode ändern. Wollte nun beispielsweise ein Spanier meine Test-GUI auf Spanisch statt Englisch nutzen, legt er einfach eine Datei "es.yml" im locale-Verzeichnis an und übersetzt die "en.yml". Die automatische Spracherkennung wird Spanisch erkennen und die neu angelegte Datei "es.yml" nutzen - ohne jegliche Codeänderungen. D.h. die Spracherkennung von R18n läuft so ab:

1
2
3
4

1. Lokale Systemsprache wird herausgefunden
2. Eine Übersetzungsdatei mit dem Namen der Systemsprache wird gesucht
3. Wird diese nicht gefunden, wird die Datei mit einer verwandten Sprache gesucht (z.B. de statt at für Österreich)
4. Wird diese auch nicht gefunden, wird die englische Datei zu Rate gezogen.

R18n kann aber noch mehr (das habe ich allerdings nicht eingebaut): Singular/Pluralbildung von Wörtern anhand von Lokalisierungsinformationen in der Übersetzungsdatei und automatische Erkennung von lokalen Anzeigeformaten (z.B. 1.3 in den USA und 1,3 in Deutschland). Datei:R18n-beispiel.tar.bz2 benötigt die Gems wxruby-ruby19 und r18n-desktop. --Q. 15:41, 20. Jun. 2010 (UTC)

1
2
3
4
5
6
7

/var/lib/gems/1.9.1/gems/wxruby-ruby19-2.0.0-x86_64-linux/lib/wx.rb:12:in `require': /var/lib/gems/1.9.1/gems/wxruby-
ruby19-2.0.0-x86_64-linux/lib/wxruby2.so: symbol _ZN13wxAuiNotebook7SetFontERK6wxFont, version WXU_2.8.5 not defined in file 
libwx_gtk2u_aui-2.8.so.0 with link time reference - /var/lib/gems/1.9.1/gems/wxruby-ruby19-2.0.0-x86_64-linux/lib/wxruby2.so 
(LoadError)
        from /var/lib/gems/1.9.1/gems/wxruby-ruby19-2.0.0-x86_64-linux/lib/wx.rb:12:in `<top (required)>'
        from ./testgui.rb:3:in `require'
        from ./testgui.rb:3:in `<main>'

was habe ich falsch gemacht? ich habe es in allen versionen versucht (1.8 macht syntax error und 1.9* den require error) --Hanmac 18:22, 20. Jun. 2010 (UTC)

Ah, Ubuntu Karmic oder Lucid. Das Problem tritt nur auf diesen beiden Linux-Distributionen auf, wenn ich mich richtig entsinne und die einzige Möglichkeit es zu umgehen ist, wxRuby selbst zu kompilieren. Für Ubuntu Karmic kann ich dir ein funktionierendes 32-Bit und 64-Bit-Gem geben, für Lucid habe ich nur 64-Bit da. Aber Vorsicht, das fertig kompilierte Gem hat etwa 20 MB Größe.
PS: Ich habe mal das Layout wieder richtig gerückt, dein Backtrace hat es ewig langgezogen. --Q. 18:44, 20. Jun. 2010 (UTC)

genau diese lucid version hab ich (64bit), bzw gibt es ein gem wo das sich richtig selber kompiliert? --Hanmac 19:34, 20. Jun. 2010 (UTC)

Siehe meine PN. --Q. 19:57, 20. Jun. 2010 (UTC)

Also endlich mal was zu deinem Verzeichnis. Find ich so in Ordnung und kannst du gerne als Initial verwenden, wenn du es nicht hast. Die Lokalisierung hab ich mir noch nicht angeschaut, aber werd ich mal noch bei Gelegenheit tun, allerdings ist dies ja dann schon ein recht speziefisches Problem für den Editor. Vorher müss mer ja erstmal noch die Engine bauen und mit Gosu verknüpfen bevor mer ne Oberfläche draufnageln ;-) Soll die GUI dann eig auch via Gosu werden? (Problematisch gerade Tabellen und so, also eher sowas wie FXRuby, da weiß ich aber nicht wie das mit Bildern einfügen ist) So nächstes Kapitel lesen und beantworten :-p --Kjarrigan 06:57, 21. Jun. 2010 (UTC)

EDIT: Hab mich soeben mal auf GitHub registriert (Kjarrigan) und mich bei einem gewissen Quintus als Follower eingetragen :-D, da dort ebenfalls an Bild die Münze zu sehen ist, hoffe ich ich stalke den richtigen ;-)

Komisch, auf meinen GitHub-Account hat sich gerade ein gewisser Kjarrigan gemeldet, von dem ich noch nie was gehört habe... ;-)
So, wir haben ein Repo! http://github.com/Quintus/OpenRubyRMK
Meldet euch bei mir, dann trage ich euch als böse Kollaborateure ein! --Q. 12:16, 21. Jun. 2010 (UTC)

Na dann könn mer ja loslegen wir drei Hübschen (vier wenn Aco sich zu Ruby durchringt) :-D Wie ist das nun eig mit dem GitHub Wiki. Kommen dort dann nur definitive Beschlüsse für das Projekt hin (ala Featured ToDo List usw) oder wird fortan dort diskutiert. Heut Abend werd ich daheim mal GitHub soweit einrichten, dass ein Schlüssel hinterlegt ist und ich da mitmischen kann :-D EDIT: Ich hab auch schon fast einen ersten Entwurf für ein Menu zusammen, der optisch erstmal eine Kopie des Maker(ingame)menus ist. --Kjarrigan 13:07, 21. Jun. 2010 (UTC)

r18n richtig nutzen

wenn ich eine classe RPG::Actor zb habe, und die soll eine Namens eigenschaft haben wie mach ich das am besten das der das localisiert ausspuckt? bzw wie muss ich das machen damit der auch nur einen schlüssel gibt wenn ich den als comando in einem window zb brauche? --Hanmac 19:31, 30. Jun. 2010 (UTC)

Du willst r18n im Spiel selbst nutzen? Das halte ich für gewagt, weil das für den Spieleentwickler heißt, dass er Lokalisierungsdateien anlegen muss - ich dachte eigentlich daran, es für die GUI des Makers zu verwenden. R18n liest den größten Teil der Übersetzungen aus separaten Dateien (siehe mein bereits hochgeladenes Beispiel), um die kommst du niemals herum. Angenommen, du hast eine solche Übersetzungsdatei:

1
2
3
4

menus:
  file:
    open: "Öffnen"
    new: "Neu"

, dann würdest du an den String für open über

1
2
3
4
5
6
7
8
9
10
11
12

require "r18n/desktop"

#Für automatische Sprachwahl anhand der System-
#einstellungen:
R18n.from_env("./locale")
#- ODER - 
#Für manuelle Sprachwahl, z.B. aus eine Config:
R18n.from_env("./locale", "de") #de - Deutsch

include R18n::Helpers
#...
t.menus.file.open #=> "Öffnen"

herankommen. Für jede Sprache legst du eine eigene Übersetzungsdatei im locale-Verzeichnis an; die Auswahl der richtigen übernimmt R18n.--Q. 20:23, 30. Jun. 2010 (UTC)

EDIT: Oha - mir kommt es vor, als hätten wir in diesem Bereich schon länger aneinander vorbeigeredet. Mir war nicht klar, dass du von Anfang an innerhalb des Spiels übersetzen wolltest, ich dachte du bezögest dich auf die GUI. Das ist mir erst jetzt so langsam aufgegangen... Aber das wirft eine andere Frage auf: Was genau willst du in unserem Minimal-Spiel denn übersetzen? Möchtest du vorgefertigte Dialoge anbieten? Oder möchtest du den Spieleentwicklern Multilingualisierung ermöglichen (wo ich dann R18n wieder gar nicht schlecht fände, der Einfachheit wegen)? Dieser letzte Punkt war mir bislang überhaupt nicht in den Sinn gekommen... Dann gäbe es allerdings das Textfeld in klassischer Form nicht mehr, man würde dann stattdessen einen Pfad in der Übersetzungdatei angeben, z.B. szene1.person_xyz.thrid_statement. Habe ich das richtig verstanden? --Q. 20:38, 30. Jun. 2010 (UTC)

ja für die GUI war ja klar, aber ich dacht auch für die spiele, man hat hinten in der Datenbank ein Register wo man die Strings rein schreiben kann, und der maker macht daraus dann die übersetzungsdateien, für Dialoge .. am besten so das man entweder text eingeben kann oder so einen übersetzungspfad (wenns geht ohne eval .. ), in meinem beispiel wäre glaub ich sowas hier am besten oder?:

1
2
3
4
5
6
7
8

module RPG
 class Actor
  attr_writer :name
  def name
   return t.rpg.actor[@name]
  end
 end
end

hier noch mal was anderes von http://r18n.rubyforge.org/tutorial.html

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

require "r18n/desktop"
require 'r18n-core/translated'

class Product
#  include DataMapper::Resource # ich halte datamapper für grausam,
# weil es 19 ancestors für Produkt hinzufügt, wovon einige module nicht mal einen namen haben oO
#  property :title_ru, String
#  property :title_en, String

  attr_accessor :title_ru,:title_en
  include R18n::Translated
  translations :title
end

a.Produkt.new
a.title_en = "ABC"
a.title #=> "ABC"

bzw steht da auch irgendwie nicht wie ich die localisierung mit den files koppel? --Hanmac 20:48, 30. Jun. 2010 (UTC)

Mit dem Tutorial für r18n-core bin ich auch nicht klargekommen - das ist unnötig kompliziert, mit dem Modul R18n::Translated kommst du nie in Kontakt. Nimm das Tutorial für r18n-desktop, also http://r18n.rubyforge.org/desktop.html . Das ist kürzer und einfacher, und erfüllt trotzdem alle Zwecke für die ich R18n bislang benutzt habe. Da gibt es auch ein Beispiel für die Benutzung der l-Methode zur Lokalisierung.
Erzeugung von Dateien über den Maker - hm. Der Entwickler müsste schon Übersetzungen für alle Sprachen vornehmen, in die er verteilen will, automatische Übersetzungen sind nicht inbegriffen (man könnte natürlich schummeln und sich im Hintergrund mit Googles Übersetzungsdienst verbinden, aber die Ergebnisse sind meiner Erfahrung nach grausam). Die Dialogfunktion für sowohl Text als auch "Pfade" herzurichten, ist nicht weiter schwierig, und Evil eval brauchen wir auch nicht, nicht einmal send, weil r18n so freundlich ist und das hier ermöglicht:

1
2
3
4
5

include R18n::Helper
#...
t["menus"]["file"]["open"] #=> Öffnen
#gleich wie
t.menus.file.open #=> Öffnen

Dein Actor-Beispiel irritiert mich ein wenig, soll eine Person in einer anderen Sprache anders heißen? Namen würde ich grundsätzlich unangetastet lassen, der Londoner Tower heißt auf Deutsch auch Londoner Tower und nicht "Turm von London" oder sowas... Ansonsten wäre dein Beispiel richtig, sofern du eine Übersetzungsdatei mit diesem Inhalt hast (angenommen, dein Actor heißt im englischen Original "Mathew" und @name=="Mathew"):

1
2
3

rpg:
  actor:
    Mathew: Matthias

--Q. 13:19, 2. Jul. 2010 (UTC)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

require "r18n-desktop"
include R18n::Helpers
module Translation
  def translation(*names)
    attr_writer *names
    names.each do |n|
      class_eval <<-EOS, __FILE__, __LINE__
        def #{n}(*params)
          temp = t
          self.class.name.split("::").each {|s| temp = temp[s] }
          return temp[:#{n}][@#{n},*params]
        end
      EOS
    end
  end
end

Hier meine version eines Translation modules was die files nutzt.

1
2
3
4
5
6
7

require "translation.rb"
module RPG
  class Enemy
    self.extend(Translation)
    translation :name
  end
end

1
2
3
4

RPG:
  Enemy:
    name:
      Mathew: Matthias

1
2
3

a = RPG::Enemy.new
a.name = "Mathew"
p a.name #Matthias

--Hanmac 12:59, 3. Jul. 2010 (UTC)

Das eval lässt sich aber wirklich vermeiden (Änderungen markiert):

1
2
3
4
5
6
7
8
9
10
11
12
13

module Translation
  
  def translation(*names)
    attr_writer(*names)
    names.each do |n|
      define_method(n) do |*params| #define_method
        temp = t
        self.class.name.split("::").each{|s| temp = temp[s]}
        temp[n][instance_variable_get(:"@#{n}"), *params] #instance_variable_get
      end
    end
  end
end

Aber da muss noch vernünftige Fehlerbehandlung rein: Wenn der Entwickler vergessen hat, die Übersetzung des Namens anzugeben, braucht er nicht mit einem R18n::Untranslated-Objekt konfrontiert zu werden, das ihm bei nächter Gelegenheit (d.h. bei Verwendung) um die Ohren fliegen wird. Da gehört eine Zeile wie raise(OpenRubyRMK::TranslationError, "No translation for string '#{str}'!") noch hinein, damit der Entwickler nicht raten muss, was ihm da passiert ist und warum es nicht funktioniert. --Q. 17:28, 3. Jul. 2010 (UTC)

ok mit define method gehts auch, wäre aber an der stelle das selbe. ob ich jetzt ne neue fehlermeldung brauch weis ich nicht, an dem R18n::Untranslated kann man doch sehen welcher string nicht übersetzt wurde --Hanmac

Ich mag die String-Formen von eval einfach nicht für "internen" Gebrauch. Wenn es darum geht, dem Benutzer die direkte Eingabe von Ruby-Code explizit zu ermöglichen (à la irb) geht freilich kein Weg drumherum.
Das Werfen des Fehlers halte ich für wichtig, weil es einfacher verständlich ist als etwas wie "undefined method `to_s' for R18n::Untranslated" - nicht für uns als Programmierer, aber für den typischen Maker-Entwickler, der nicht programmieren kann und mit dem dann noch folgenden Ruby-Backtrace nicht so wirklich was anfangen kann und eventuell sogar denkt "da ist ein Fehler im OpenRubyRMK!". Aber die Idee, Übersetzung per Mixin zu realisieren, halte ich für grundsätzlich gut und richtig. Bedenken habe ich nur bei den Textboxen, da ein Spiel ja gerne mal aus mehreren Hundert oder Tausend Textboxen besteht, die jede individuell benannt werden müssten, um sie eindeutig zu identifizieren. Man könnte sie durchnummerieren, aber wer weiß schon, an welcher Stelle im Spiel denn jetzt Textbox 437 auftaucht? Das ist aber ein generelles Übersetzungsproblem und ist nicht direkt an deinen Ansatz gebunden ;-) --Q. 09:00, 4. Jul. 2010 (UTC)

Copyright

Das fiel mir gerade recht aprupt ein. Wir sollten unser Repo schleunigst lizenzieren - Einwände gegen die GPL Version 3? Außerdem brauche ich noch eure E-Mail-Adressen, damit ich sie als Kontaktmöglichkeit zum Lizenzgeber angeben kann. Ihr könnt sie mir per PN senden, wenn sie nicht im Wiki stehen sollen, oder per GitHub, aber letzten Endes landen sie doch in der README, wenn auch wahrscheinlich leicht abgewandelt aufgrund vor Programmen, die Websites nach dem @-Zeichen durchsuchen und die gefundenen Adressen für Spam missbrauchen. Ich neige momentan dazu, meine E-Mail-Adresse als sutniuq@@gmx@net anzugeben, was wohl nicht gefunden werden kann. --Q. 14:04, 21. Jun. 2010 (UTC)

Da fällt mir noch was ein. Die GPL würde jeden Spieleentwickler zwingen, den Quellcode seines Spiels verfügbar zu machen... Je nachdem, wie wir das mit der Kompilierung der fertigen Spiele lösen, müssten dann bei der Kompilierung vielleicht automatisch ein 7z-Archiv mit dem Quellcode angelegt werden, dass der Spieleentwickler mitverteilen muss. Hm, da Lizenzen wie die MIT in Deutschland juristischer Quatsch sind (das Urheberrecht kann man in Deutschland eh nicht abgeben, hätte den gleichen Effekt wie "lizenzfrei"), könnte man noch über die LGPL nachdenken... --Q. 14:34, 21. Jun. 2010 (UTC)

ich hätte idee für sowas: der maker und die engine sind frei (GPL) da aber beide vom macher der spiele nicht verändert werden, müsste er sein spiel nicht unter der GPL machen oder? ich mein die gemachten spiele kann man ja von der lizenz des Makers auschließen oder? PS: meine email: hanmac@gmx.de --Hanmac 15:04, 21. Jun. 2010 (UTC)

Ah, wenn das so einfach wäre. Wenn der Spieleentwickler auf die von uns geplante weitgehende Skriptfunktion zurückgreift, hat er eine Änderung am von uns gelieferten Quellcode vorgenommen, muss sich selbst als Autor für diese Änderung angeben und muss den Quelltext mitliefern. Der Maker selbst, d.h. die GUI, ist davon tatsächlich nicht betroffen, die verteilt er ja nicht weiter - aber da wir bereits den Code für das Spiel liefern... Möglicherweise könnte man alles, was im game-Verzeichnis zu finden ist, unter die LGPL stellen, den Rest unter die GPL? Oder stellen wir dann gleich alles unter die LGPL? --Q. 15:26, 21. Jun. 2010 (UTC)

Meine E-Mail: masamunes_son(at)web.de und ich bin für die GPLv3 (Gosu und Chipmunk sind btw MIT). Das mit dem Code veröffentlichen bekommen wir schon hin, außerdem schwirrt mir was im Kopf rum mit: Man muss den Code nicht pauschal mitschicken, sondern es reicht wenn man ihn auf Anfrage ohne das der Entwickler murrt bekommt (das muss ich aber nochmal nachschlagen) --Kjarrigan 15:30, 21. Jun. 2010 (UTC)

Ich habe mir gerade sowohl GPL als auch LGPL nochmal komplett durchgelesen (ja, ich gehöre zu den Leuten, denen sowas Spaß macht! ;-) ) und ich glaube, du meinst das hier:

Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.

Sektion 6 b); wenn man Nicht-Sourcecode-Formen verteilt (d.h. Executables), dann ist einer der möglichen Wege, den Code freizugeben, eine schriftliche Notiz zu hinterlegen, dass man den Code auf Anfrage bekommen kann. Das wäre tatsächlich eine Lösung, eine solche Notiz können wir beim Kompilieren ja automatisch erzeugen und dann dem Spieleentwickler per eindringlicher Meldung deutlich machen, dass er sie nicht entfernen darf (was ja ein Verstoß gegen die GPL wäre). --Q. 15:45, 21. Jun. 2010 (UTC)

EDIT: Müssen eigentlich die wahren Namen in die Lizenz oder genügen die Pseudonyme? Why the lucky stiff hat nie seinen wahren Namen benutzt, aber er hatte auch soweit ich weiß nie einen juristischen Vorfall. --Q. 15:52, 21. Jun. 2010 (UTC)

Hm ich würde sagen "written by Kjarrigan <masamunes_son@web.de>, Quintus <xyz@mail.de>, usw" reicht :-D Obwohl der "echte" Name warsch auch nicht so kritisch wäre, da unsere Namen ja nicht einzigartig sind ;-) und solange wie keine weiteren Merkmale (Adresse) hinzufügen, kann damit niemand was anfangen. Du kannst ja eig auch einfach mal bei anderen Projekten auf gitHub schaun wie die es machen. Ich geh nu erstmal schlafen - bin müde. Bis morgen --Kjarrigan 19:53, 21. Jun. 2010 (UTC)

Soeben habe ich unser Programm unter die GPL gestellt. Wollen wir hoffen, dass es die richtige Wahl war... Brrr, ich mag es gar nicht, über Lizenzsachen nachzudenken, wenn man die Zeit viel sinnvoller hätte in Quellcodeproduktion unterbringen können! --Q. 16:19, 22. Jun. 2010 (UTC)

EDIT: Wo wir gerade bei git sind: Meint ihr, es ist sinnvoll, bereits jetzt für das jeweils nächste Ziel jedes einzelnen von uns eigene Branches anzulegen? Ich meine, "stabil" ist unser master jawohl eh nocht nicht ;-). --Q. 16:25, 22. Jun. 2010 (UTC)

Hat mal einer nachgeschaut ob das so ok ist und die spiele lizenz unabhänig von dem Program ist? PS: wenns sein muss machen wir unsere Lizenz --Hanmac 10:24, 24. Jun. 2010 (UTC)

Nach dem, was ich der GPL entnehmen konnte, wäre ein Spiel, das mit unserem Maker (sofern er unter GPL veröffentlicht ist) ebenfalls automatisch unter der GPL lizenziert; das ist, was man "virale Lizenz" nennt. Deswegen hatte ich das mit dem Hinweis vorgeschlagen. Wenn du es also besonders extrem sehen willst, nehmen wir dem Benutzer die Freiheit, sein Spiel unter eine andere Lizenz zu stellen. Im Gegensatz dazu würde die LGPL auf Unterprojekte nicht zutreffen - das ist übrigens der Grund, weshalb der GCC unter der LGPL steht. Stichwort eigene Lizenz: Kennst du jemanden, der eine Lizenz schreiben würde? Ich glaube, keiner von uns ist in der Lage, eine juristisch einwandfreie Lizenz zu formulieren, dazu brächten wir die Hilfe eines Juristen - was wiederum eine Kostenfrage ist. --Q. 15:04, 24. Jun. 2010 (UTC)

Ich hab mich nochmal informiert: die Engine muss LGPL sein sonst müssen auch die spiele GPL sein. aber da der maker unabhänig von Enine ist, kann der auch GPL sein. Beim sample wäre die Lizenz eigendlich egal, würde aber auch LGPL oder freier nehmen --Hanmac 10:28, 29. Jun. 2010 (UTC)

Das ist es, was ich mit dem Beispiel des GCC ausdrücken wollte: Die GPL zwingt jeden, der mit einem solchen Programm etwas erstellt, sein Programm unter die GPL zu stellen. Wir bleiben nur an einer Frage stehen: Wollen wir die Leute zur GPL und zur Codeoffenlegung zwingen? Ich kann darin nichts schlechtes erkennen, OpenSource ein wenig voranzutreiben. Durch den an anderer Stelle bereits vorgeschlagenen Hinweis und einer E-Mail-Angabe muss das nicht einmal schwierig für den Spieleentwickler sein. --Q. 14:09, 29. Jun. 2010 (UTC)

Engine-Layer

Wir hatten uns der Idee genähert, ein "Zwischenlayer" zwischen unsere Lib und die Engine, die die graphischen Berechnungen durchführt, zu legen. Ist ja schön und gut davon zu sprechen, aber wir sollten uns auf das Aussehen des Layers einigen. Was muss es können? Ich bin dafür, dass wir hier einfach mal ein konkretes Klassen/Modul-Gerüst definieren (sollte es mehr als ein einzelnes Modul werden), etwa so:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

module EngineLayer
  
  class Graphic
    
    def initialize(filename, x, y, z = 1)
    end
    
    def draw
    end
    
    #...
  end
  
  #...
  
end

So hätten wir zunächst einmal ein klares Ziel vor Augen: Gosu an das Layer anpassen. Später kann man dann ja eine andere Engine nehmen, die wir ebenso an das Layer anpassen (und dann vielleicht sogar dem Spieleentwickler die Wahl lassen?) --Q. 15:18, 24. Jun. 2010 (UTC)

Datei:RPGVX.tar.bz2 hier die Hilfe datei des RPGVX, enthält die Bultin-Classes (like Color und Window etc)--Hanmac 16:06, 24. Jun. 2010 (UTC)

Habe ich gleich mal reingeschaut, um einen kurzen Überblick über die neuen Features zu bekommen. Aber das RGSS werden wir doch wohl nicht 1:1 kopieren? Inspiration ist ja gut und schön, aber ich möchte es nicht auf einen Streit mit Enterbrain hinsichtlich des Interfaces ankommen lassen. --Q. 16:28, 24. Jun. 2010 (UTC)

nee muss ja nicht sein, aber nicht direkt auf die oberfälche sondern auf so ein Bitmap zu malen finde ich schon eine gute lösung, Font können wir ja schon fast von Gosu nutzen --Hanmac 16:35, 24. Jun. 2010 (UTC)

Da hier niemand sichtbare Vorstöße macht, mache ich mal einen: Datei:Engine.rb.bz2. Das ist mein allererster absolut unverbindlicher Vorschlag eines Zwischenlayers und er braucht dringend Kritik. Ich habe ihn aus den Dokumentationen von Gosu und dem RPGVX sowie meinen Erfahrungen zusammengebastelt.
Ihr könnt übrigens auch RDoc drüberlaufen lassen, sieht (zumindest mit hanna) auch ordentlich aus. --Q. 15:43, 29. Jun. 2010 (UTC)

ist schon mal ganz ok denk ich, fehlen ja noch ein wenig die funktionen, aber ohne engine kann man schecht den zwischen layer bauen, aber für anfang schon mal nicht schlecht --Hanmac 17:21, 29. Jun. 2010 (UTC)

Will ich mich nur auch mal wieder melden. Vorab. Ich bin gerade in der letzten Phase meiner Abschlussarbeit und daher wohl die nächsten 2-3 Wochen eher weniger aktiv. Zu deinem Layer. Wie Hanmac schon sagte ein verwendbarer Ansatz dem hier und da nun noch der Funktionsumfang fehlt (etwa verschiedene Farbraumumwandlungen). Die ein oder andere Methodenbenamsung sagt mir auch noch nicht zu aber das ist dann alles Spielerei (Bsp: dry_run beim Text. Ich würde sowas wie length[_of] bevorzugen. Damit versteht man eher was gemeint ist). Wo ich mir noch sorgen mache, ist Gosu in das Sprite(Group) Konzept einzupassen. Ich habe zwar noch die Anregungen von Kai(?) im Kopf, bin aber nicht sicher ob das funktioniert. Hab mir die Tage auch mal noch GL angeschaut (auch in Kombination mit Gosu) Sieht natürlich geil aus, aber die GL Syntax ist ja mal widerlich. Ich werde in meinen Schreibpausen mal weiter mit Gosu experimentieren und mal sehn wo da die Limits sind ;-) Spätestestens ab 23.Juli muss ich meine Arbeit abgeben also längstens dann sehn/hörn wir uns wieder. --Kjarrigan 05:59, 30. Jun. 2010 (UTC)

Zitat von Hanmac:

ist schon mal ganz ok denk ich, fehlen ja noch ein wenig die funktionen, aber ohne engine kann man schecht den zwischen layer bauen

Ich habe nur versucht, irgendwie ein Layer aufzustellen, Gosu integriert habe ich absichtlich noch nicht. Erst, wenn wir das Layer fertig definiert haben, sollten wir uns an den aktuellen Code machen. Nebenbei, ich halte es für schlau, nach der Layerdefinition anfallende Aufgaben zu verteilen, damit wir nicht Probleme doppelt und dreifach lösen. Aber wie gesagt, nach der Layerdefinition - vom Layer hängt ja der gesamte restliche Code ab.

Zitat von Kjarrigan:

Wo ich mir noch sorgen mache, ist Gosu in das Sprite(Group) Konzept einzupassen. Ich habe zwar noch die Anregungen von Kai(?) im Kopf, bin aber nicht sicher ob das funktioniert

Ja, Gosu ist für "Direkt-auf-den-Bildschrim-malen" ausgelegt, aber wie Hanmac schon sagte, ist ein Konzept einzelner Sprites & Groups vermutlich besser und objektorientierter. Ich werde mir da mal ein paar Gedanken zu machen.

Zitat von Kjarrigan:

Hab mir die Tage auch mal noch GL angeschaut (auch in Kombination mit Gosu) Sieht natürlich geil aus, aber die GL Syntax ist ja mal widerlich.

Mit openGL und Ruby habe ich vor allen Dingen ein massives Problem: Das ruby-opengl-Gem ist seit über einem Jahr nicht mehr geupdated worden und wartet noch immer auf das Release von OpenGL 3.0. Außerdem ist es in der aktuellen Version für MinGW-Ruby 1.9 nur mit extremen Problemen zu kompilieren. Gibt es Alternativen zu diesem speziellen Gem (nicht zu OpenGL, das ist schon in Ordnung)?

Zitat von Kjarrigan:

Spätestestens ab 23.Juli muss ich meine Arbeit abgeben also längstens dann sehn/hörn wir uns wieder.

Viel Erfolg noch einmal von mir! --Q. 16:23, 30. Jun. 2010 (UTC)

Ich bin bei Rubygems.org gerade auf Chingu ( http://github.com/ippa/chingu ) gestoßen. Kennt das einer von euch? Das setzt auf Gosu auf, hat aber zum Ziel, ein besseres/objektorientierteres/rubyischeres API zur Verfügung zu stellen. Die README auf GitHub ist sehr ausführlich, hört sich zumindest für mich ziemlich gut an. Meinungen? --Q. 11:23, 3. Jul. 2010 (UTC)

ja hab ich schon gesehen, klinht cool war mir aber zu hoch :P da brauche ich mal ein tutorial oder so, hier das habe ich auch noch gefunden : http://rubygems.org/gems/gosu_extensions --Hanmac 12:43, 3. Jul. 2010 (UTC)

Chingu ist nicht wirklich kompliziert - die haben uns nur jede Menge Arbeit abgenommen und haben z.B. GameState-Objekte, die etwa soetwas sind wie die Scenes beim RPG-Maker oder bessere Input-Verwaltung. Z.B. kannst du jetzt @player.input = {:left => :move_left} machen, da ein GameObject sämtliche typischen Operationen für Spielobjekte übernimmt. Prinzipiell sind die wohl ähnlich wie die Sprites aus dem RPG-Maker, aber allzu weit würde ich mit der Ähnlichkeit nicht gehen. Diese Gosu-Extensions sehen auch ganz interessant aus, aber wenn ich das richtig sehe, sind die Extensions vor allem Chipmunk-Integration (über die wir uns ja noch nicht wirklich einig sind) und Input-Handling, was Chingu neben vielen weiteren Dingen auch bietet. Aber es hindert uns ja nichts daran, interessante Dinge aus beiden zu nehmen, wenn uns weder das eine, noch das andere genug zusagt.
Frage: Ich habe mir zu dem Sprites & Group-Konzept ein paar Gedanken gemacht. Ist es wirklich notwendig, dass eine SpriteGroup (oder wie auch immer wir das nennen) garantiert, dass kein Pixel außerhalb ihrer Größe bemalt wird? Genügt es nicht, wenn die Positionen der einzelnen Sprites der Gruppe relativ zur Position der Gruppe sind? Warum ich frage: Einerseits müssten für den "Malbereich" Änderungen an den Bildern vorgenommen werden, die sich wohl nur mit direkten OpenGL-Aufrufen bewerkstelligen lassen (und zu den Ruby-OpenGL-Bindings habe ich meine Besorgnisse ja schon geäußert[*]), andererseits bietet uns Chingu schon ein "viewport"-Plugin, dass genau diese Relativ-Berechnungen vornimmt.
[*]Ich habe noch ein zweites Ruby-OpenGL-Binding gefunden, ffi-opengl, das etwas aktueller erscheint, aber ich glaube auch nicht auf der Höhe der Zeit ist. --Q. 09:25, 4. Jul. 2010 (UTC)

ok das sind genug argumente für Chingu, wenn das ein viewport hat nutzen wir das gleich, wie machen wir das mit den Scenes? kommt die berechungen da mit rein oder machen wir die berechnungen extra und die scenes nur zum darstellen? --Hanmac 14:04, 4. Jul. 2010 (UTC)

Nur damit der Viewport nicht überbewertet wird: Das Abschneiden der Bilder an den Viewport-Grenzen wird nicht vorgenommen. Die einzige Möglichkeit, die ich dazu sehe, ist OpenGL-Aufrufe auf den Bildern durchzuführen.
Die GameStates, die Chingu anbietet, kapseln einen eigenen Mainloop und bieten ein völlig blankes Fenster. Für uns bedeutet das, dass wir einen GameState behandeln können wie die Hauptschleife - was ja genau ist, was wir brauchen. Ob das nun Scene oder GameState heißt, ist schließlich egal. Konkret zu deiner Frage: Der GameState ist ein fast vollwertiger Mainloop. Wir werden also alles, was mit dieser Szene zu tun hat, in die #initialize-, #setup-, #update-, #draw- und #finalize-Methoden schreiben (die letzte ist besonders genial, perfekt zum Szenenwechsel!) und können die einzelnen Szenen absolut unabhängig voneinander betrachten. Zum Darstellen benutzen wir dann Chingus GameObjects. --Q. 14:36, 4. Jul. 2010 (UTC)

EDIT: Was die Viewports angeht, muss ich mich noch einmal korrgieren. Nachdem ich mir Chingus README ein wenig intensiver durchgelesen habe, scheint Chingu unter einem Viewport etwas anderes zu verstehen als wir: Chingu hält einen Viewport für die bespielbare Fläche, die über den Spielbildschirm gescrollt wird. Ist auch nett, weil es uns das Kartenscrolling abnimmt, aber hat nichts mit relativen Sprite-Gruppierungen in anderen Szenen als der Map zu tun. Also noch einmal meine Frage: Brauchen wir die Garantie, dass das Bild am Rand der Sprite-Group abgeschnitten wird? --Q. 15:09, 4. Jul. 2010 (UTC)

Es wäre schon wichtig was viewport abschneiden kann, es kann ja eine optionale Fähigkeit sein, aber das es möglich ist wäre schon wichtig --Hanmac 05:51, 9. Jul. 2010 (UTC)

Dann müssen wir uns wohl etwas tiefer in OpenGL reinknien. Was haltet ihr davon, statt des hoffungslos veralteten ruby-opengl ffi-opengl zu nehmen? Das sollte sich dank FFI auch auf Windows recht leicht erstellen lassen. --Q. 07:57, 11. Jul. 2010 (UTC)

jo wir könnten es nutzen, oder wir fragen mal die macher von Chingu ob die diese funktion einbauen können --Hanmac 13:19, 11. Jul. 2010 (UTC)

Hello again! Meine Arbeit ist so gut wie abgegeben und ich hab wieder freie Kapazitäten ;-) Also ich hab nebenher immer mal mit gelesen und mir schonmal Chingu angeschaut. Das gefällt mir ganz gut, da ich einige Sachen die dort gebaut wurden selbst ähnlich umgesetzt hab wenn ich mit gosu hantiert habe. Also von mir aus steht einer Verwendung von Chingu nichts im Weg (gerade die Sache mit Kartenscrolling gefällt mir und das Handling von Game- und Level-Objekten). Zur opengl-Sache: Also wie gesagt hab ich mich damit schonmal ganz kurz auseinandergesetzt und die Syntax war grausig, aber na gut. Soweit ich mich erinnere bietet Gosu (und damit auch Chingu?) die Möglichkeit zwischen glbegin und glend GL einzubinden, so dass wir "normal" mit unserer Grafiken verfahren könnten und dann später das Viewport (mit abschneiden und allem was dazu gehört) drüber legen. Das werd ich die Tage mal antesten inwieweit sich das realisieren lässt. Grüße --Kjarrigan 05:54, 19. Jul. 2010 (UTC)

Schön, dass du wieder da bist! Hast du auch in unserem Forum-Thread mitgelesen? Wir haben einen neuen Mitstreiter!
OpenGL: Wo hast du die Syntax nachgelesen? Ich habe mich ein wenig über die OpenGL-Website geklickt und auch eine Funktionsreferenz gefunden und sogar Tutorials zu spezifischen Themen, aber für Einsteiger in OpenGL habe ich nichts gefunden. Gibt es Funktionen, die man zum Initialisieren aufrufen muss? Zum Finalisieren? Und zum Thema ffi-opengl: Ich habe mir mal die Beispiele dazu angesehen und musste feststellen, dass "gears.rb" unbrauchbar ist (siehe http://github.com/remogatto/ffi-opengl/issues#issue/3 )und der Maintainer sich seitdem noch nicht gemeldet hat (siehe auch dort). Der "spinning cube" funktioniert zwar grundsätzlich, allerdings "spinnt" der wirklich: Der dreht sich extrem schnell. Das kann doch nicht richtig sein, oder?
Und wir müssen noch etwas bedenken: Wenn wir die Engine per Layer austauschbar machen, müssen wir auch eine Schnittstelle für OpenGL definieren... Irgendwie habe ich das Gefühl, dass das mit dem Layer doch etwas komplex wird... --Q. 08:05, 19. Jul. 2010 (UTC)

IRC?

Hat jemand die Möglichkeit, einen IRC-Bot einzusetzen? Dann könnten wir uns ein wenig flotter verständigen, in einem Channel #OpenRubyRMK auf freenode.net oder so (falls ich die Funktionsweise von IRC-Netzwerken richtig verstanden habe...). Logging wäre schlau, denke ich, damit wir später nachschauen können, was wir diskutiert haben. --Q. 08:11, 19. Jul. 2010 (UTC)

Gut, ich denke ich habe jetzt verstanden, wie ich einen Channel auf freenode.net erstelle, scheint bei denen ja sogar ohne IRC-Bot möglich zu sein. Als OpenSource-Projekt sind wir auch "on-topic", daher sollte es eigentlich keine Probleme geben. Ich bräuchte allerdings wen zum "Testen" - wenn ich den Channel registriert habe, hätte ich's schon gern, wenn einer von euch da mal kurz joinen könnte und reinschreibt "läuft". Nennt mir einen Zeitpunkt, dann werde ich etwa 10 Minuten vorher den Channel #OpenRubyRMK registrieren.
Wie man sieht, bin ich noch recht neu in Sachen IRC im Allgemeinen und Channel-Erstellung im Besonderen, daher bitte ich euch, mir meine Umstandskrämerei nachzusehen. Also, wann? --Q. 20:22, 20. Jul. 2010 (UTC)

ich bin im freenode.net angemeldet als nutzer, sag mir wann ich da rein schreiben soll und ich kanns (am we hab ich zeit) --Hanmac 20:16, 22. Jul. 2010 (UTC)

Samstag, 15 Uhr? --Q. 09:20, 23. Jul. 2010 (UTC)

OK, Test erfolgreich^^ Wir haben jetzt einen IRC-Channel #OpenRubyRMK auf Freenode. Jetzt bekommen wir vielleicht mal sowas wie eine Echzeitkommunikation hin... Auf ein fröhliches Diskutieren. Und dank dir Hanmac für's Testen. :) --Q. 13:27, 24. Jul. 2010 (UTC)

GUI des Makers

Ich habe mal ein mögliches Grundinterface für den Maker ausgearbeitet und auf GitHub gepusht, in einem Extra-Branch "gui". Geschrieben habe ich die GUI in wxRuby, was überall nativ aussehen sollte und überall ohne irgendwelche Abhängigkeiten einfach per "gem install wxruby-ruby19" verfügbar ist (mit Ausnahme von Ubuntu, da es dort momentan ein Kompatibilitätsproblem gibt. Ich habe aber auf GitHub für Ubuntu kompilierte Gems, 32- und 64-Bit, hochgeladen, sodass hier kaum Mehraufwand entsteht; ihr findet sie in bei den "Download"s unseres Repos).
Allzu viel Funktionalität ist freilich noch nicht eingebaut, nur ein ganz grober Überlick. Die Menüpunkte Datei -> Beenden und Help -> About sind schon integriert, das erfodert ja nicht viel Konsens. ;-) Wenn ihr Datei -> Öffnen ausführt, wird automatisch eine "Kartenstruktur" geladen, sodass ihr euch ein Bild machen könnt, wie ein mehrkartiges Projekt etwa aussehen würde.
Starten könnt ihr die GUI momentan, indem ihr lib/OpenRubyRMK.rb ausführt.
Für alles weitere brauchen wir mehr Einigkeit, insbesondere darüber, wie wir die Karten abspeichern. Ich möchte darum bitten, an den entsprechenden Punkten weiterzudiskutieren (Tiles oder nicht...?), damit wir endlich mal vom Fleck kommen. Korrigiert mich, wenn ich falsch bin, aber ich habe langsam das Gefühl, dass hier jeder sein eigenes Süppchen kocht. Oder aber, dass das Gefühl aufkommt, "hm, zu den Diskussionen wie sie da stehen, habe ich nichts mehr hinzuzufügen", und das ist tödlich. Dann können wir das Projekt auch gleich wieder einpacken. --Q. 15:14, 28. Jul. 2010 (UTC)

Eure Schweigsamkeit ignorierend habe ich einfach mal weitergemacht. Die GUI ist nun deutlich weiter als zuvor, wofür ich allerdings das Dateiformat für Maps habe definieren müssen. Da es sich dabei lediglich um einen gemarshalten Hash handelt, sollte es aber leicht änder- und erweiterbar sein. Außerdem habe ich mir Gedanken zum Deployment auf verschiedenen Plattformen gemacht. Ich habe dazu eine Rakefile angelegt, deren Hauptbestandteil der :compress-Task ist, welcher ein fertig verteilbares Archiv für die Plattform erstellt, auf der er ausgeführt wird (das sind momentan Windows und andere ^^). Ich habe die Startskripts in bin/ rausgeworfen und durch ein einzelnes Ruby-Skript ersetzt, die unnötige Konfigurationsdatei config/interpreter.txt habe ich entfernt. Die normale Konfigurationsdatei wird noch um den Punkt des zu verwenden Rubys erweitert. Um den fertig komprimierten OpenRubyRMK zu starten, wird man ein 1.9er Ruby mit wxruby-ruby19 sowie r18n-desktop benötigen, außer auf Windows, da wird man dank OCRA gar nichts weiteres brauchen. Der "Development"-OpenRubyRMK, d.h. die Git-sources, benötigt ein 1.9er Ruby mit allen erforderlichen Gems, wxruby-ruby19, r18n-desktop[1], gosu, chingu, was wir sonst noch verwenden wollen.
Außerdem habe ich schonmal das game/-Verzeichnis hinzugefügt, mit einem Pseudo-Spiel drin, das lediglich ein paar leere Karten definiert. Ihr könnt es laden, indem ihr über File -> Open... die .rmk-Datei im bin/-Verzeichnis von game/ auswählt. Das ganze habe ich auf meinem Ubuntu Lucid und Windows Vista ohne dazwischenliegende Codeänderung erfolgreich zum Laufen bekommen. Ladet euch bitte den gui-Branch von GitHub und sagt mir eure Meinung!

[1] r18n-desktop hat einen minimalen Bug auf Windows. In der Datei lib/r18n-desktop/win32.rb muss require 'dl/win32' durch require 'win32api' ersetzt werden. Da win32api aber deprecated ist, werde ich den Maintainer von r18n bitten, das durch einen DL-Aufruf zu ersetzen, was bei einer Funktion nicht wirklich viel Aufwand sein sollte. --Q. 21:27, 5. Aug. 2010 (UTC)

Ich bin leider noch etwas schweigsam, da zwar die Bachelorarbeit zur Bewertung raus ist, ich auf Arbeit aber gerade viel zu tun hab. Übergabe, Einarbeitung in zwei neue Projekte, das alte noch abschließen...ich versuche aber nebenher noch etwas weiter zu programmieren. Sitze momentan an einer Itemverwaltung die per YAML dumpt. Da gibt es allerdings noch paar Probleme mit Structs die als Hashkeys verwendet werden ;-) Deine verbesserte GUI schau ich mir dann mal an auf meine Kubuntu Netbook. Da es heut ja eh regnet und ich noch zwei Std Zugfahr vor mir habe. Ein sonniges Wochenende wünscht --Kjarrigan 05:42, 6. Aug. 2010 (UTC)

Schon in Ordnung, du kannst ja nichts dafür, dass du so viel zu tun hast, ich freue mich, dass sich überhaupt etwas tut. Hanmac bastelt auch noch an seinem NewRGSS, wie er mir vor ein paar Tagen im IRC verraten hat und crucki beobachtet alles interessiert. Was hältst du von der Idee mit dem persönlichen Treffen, die xylakant im Foren-Thread eingebracht hat?
Ich möchte euch alle aber gerne einladen, unser Git-Repo zu benutzen. Legt euch einen Branch für eure jeweilige Idee an, dann besteht auch die Möglichkeit, dass wir alle uns euren Code ansehen und beurteilen können. Das halte ich für besser, als wenn jeder in seinem stillen Kämmerlein allein vor sich hinwerkelt. Das wird die Zusammenarbeit hoffentlich fördern!
Mir persönlich ist es nach einem Tag Kopfschmerzen gelungen, den rake compress-Task sowohl für Linux als auch für Windows erfolgreich abzuwickeln, d.h. das Ergebnis ist jetzt benutzbar. --Q. 21:46, 6. Aug. 2010 (UTC)

selbst mit deinem wxruby gem bekomm ich diesen fehler und selbst wenn ich es mit rake neu compresse /var/lib/gems/1.9.1/gems/wxruby-ruby19-2.0.1-x86_64-linux/lib/wx.rb:12:in `require': /var/lib/gems/1.9.1/gems/wxruby-ruby19-2.0.1-x86_64-linux/lib/wxruby2.so: symbol _ZN13wxAuiNotebook7SetFontERK6wxFont, version WXU_2.8 not defined in file libwx_gtk2u_aui-2.8.so.0 with link time reference - /var/lib/gems/1.9.1/gems/wxruby-ruby19-2.0.1-x86_64-linux/lib/wxruby2.so (LoadError) --Hanmac

Was passiert, wenn du es ohne compress machst? Probiere einfach mal, den OpenRubyRMK direkt aus dem bin/-Directory zu starten.
Welche Ruby-Version hast du? Ich habe für 1.9.1-p429 auf Ubuntu 10.04 32- und 64-Bit kompiliert. --Q. 09:48, 7. Aug. 2010 (UTC)

ruby 1.9.1p378 Ubuntu 10.04 64-Bit --Hanmac 10:15, 7. Aug. 2010 (UTC)

Siehe meine PN. --Q. 10:51, 7. Aug. 2010 (UTC)

jetzt hat es funktioniert ... sieht geil aus ... wann kann der die map darstellen? --Hanmac 13:44, 7. Aug. 2010 (UTC)

Sobald wir uns darauf verständigt haben, ob Events raster-, pixel- oder wie-auch-immer-basiert sind.

--Q. 14:23, 7. Aug. 2010 (UTC)

Also ich dachte das hatten wir schon ;-) Passend zum "Bewegungs"-Raster (weil die Charaktere ja immer voll auf einem Feld stehen, also brauch mer auch kein verschobenes Event-Gitter), aber nicht auf 1 Feld begrenzt, sondern ein Rechteck über Felder (N x M). Ich schaus mir heute auch endlich an - Versprochen :-D --Kjarrigan 12:20, 9. Aug. 2010 (UTC)

OK, dann werde ich das so implementieren.
So, ich werde morgen für 2 Wochen in Urlaub fliegen (nach Tunesien) und ich weiß nicht, ob ich da unten Internet bekommen kann. Ich werde weiterarbeiten, aber wundert euch nicht, wenn ich nicht von mir hören lasse, spätestens am 25. August werde ich mich hier wieder melden (komme am Vortag zurück). Ich hoffe aber, dass ich trotzdem irgendwie hier mitlesen und -posten kann. Pushes auf das Git-Repo werde ich aber wohl nicht machen, weil ich keinen Bedarf daran sehe, verschlüsselte SSH-Verbindungen in einem Land aufzubauen, das gegen Regierungkritiker harsch vorgeht. --Q. 13:16, 9. Aug. 2010 (UTC)

Na dann wünsch ich dir bestes Badewetter und untersteh dich im Urlaub deinen Computer anzuwerfen. Wenn ich auch nur eine Nachricht von dir in den zwei Wochen sehe schick ich dir nen saftigen Virus...

Außerdem war ich mal so frei eine Mailadresse bei Google für unser Projekt einzurichten, dann müssen auf Github nicht mehr unsere "privaten" stehen und alle haben Zugriff auf gestellte Fragen etc.
Adresse: openrubyrmk@googlemail.com
Passwort schick ich den beteilligten per PN ;-) --Kjarrigan 14:10, 9. Aug. 2010 (UTC)

Das mit der Mailadresse ist eine gute Idee. Sobald du die PNs verschickt hast, sollten wir das Copyright-Statement des OpenRubyRMK anpassen und in soetwas ändern: Copyright © 2010 OpenRubyRMK development team (mit der E-Mail-Adresse als Kontaktmöglichkeit; außerdem sollte irgendwo eine Datei hinterlegt werden, wer denn das "Team" ist). Wobei auf GitHub ohnehin nicht meine "private" steht, die halte ich unter Verschluss und gebe sie nur im familiären Umfeld weiter.

Zitat von Kjarrigan:

Wenn ich auch nur eine Nachricht von dir in den zwei Wochen sehe schick ich dir nen saftigen Virus...

Soso, ich bin immer an Linux-Viren interessiert. Veröffentlichst du den dann unter GPL? ;-) Ernsthaft: Danke, ich werde das Baden genießen!
--Q. 15:07, 9. Aug. 2010 (UTC)
PS: Wie kommt's eigentlich, dass ich dich nie in #OpenRubyRMK sehe?

So, zumindest im gui-Branch sind README und Copyright-Hinweise jetzt auf "OpenRubyRMK Team" und openrubyrmk@googlemail.com gemünzt. --Q. 16:21, 9. Aug. 2010 (UTC)

Quintus retro est! Nach zwei Wochen in Tunesien fühle ich mich in einer prima Verfassung, Code zu schreiben... ;-)
Wenn ihr mal einen Blick darauf werft, was ich vorhin auf den gui-Branch gepusht habe, werdet ihr sehen, dass ich nicht ganz untätig war:

• Mapset und Map-Eigenschaften lassen sich jetzt als Extra-Fenster aufrufen
• Es gibt nun ein Plugin-System
• Ein Logger wurde hinzugefügt
• Map.new funktioniert endlich, sodass man die Mapfiles jetzt nicht mehr von Hand bearbeiten muss
• Namespace etwas aufgeräumt
• Das Mapset-Format habe ich fast vollständig zurechtgelegt, lediglich bei Feldern, die keine Graphik, aber Events (die ich übrigens Characters getauft habe) bin ich mir noch nicht ganz sicher
• Ich habe OpenRubyRMKonsole erfunden, eine Konsole für die GUI...

Der letzte Punkt war erst eine spontane Idee von mir, dann dachte ich daran, dass es im Falle von Anweisungen an den Benutzer doch viel einfacher ist, ihm zu sagen "gib das und das ein" anstatt "klick hier, klick da...". Am nützlichsten fand ich das Ding bis jetzt, um mal eben schnell ein externes Skript im Kontext des aktuellen Projekts auszuführen (im konkreten Fall, um Maps zu erzeugen). Leider funktioniert das Ding noch nicht ganz so wie ich will, ich habe ein TextCtrl genommen und ihm gewissermaßen meinen Willen "aufgezwungen", was nicht allzugut läuft. Am allerliebsten hätte ich in dem Fenster nämlich eine IRB-Sitzung im aktuellen Kontext gestartet, aber IRB weigert sich standhaft, von etwas anderem als STDIN zu lesen und selbst wenn ich die Konstante neu definiere mit einem StringIO für OpenRubyRMKonsole, läuft's auch nicht, weil #tty? dann leider false ergibt. Hat jemand Ideen dazu, wie ich ein TTY (also einen Benutzer-gibt-auf-Aufforderung-ein-Session) plattformunabhängig (vergesst nicht, das muss auch auf Windows laufen...) vortäusche?
Dann noch einmal mein Appell: Bitte, ladet euren Code doch auf unser Git-Repo, damit wir sehen können, was die anderen tun und aufeinanderzuarbeiten können. Erstellt einen neuen Branch, legt einen eigenen Ordner für euren Code an, wenn er sich noch nicht in die bestehende Ordnerstruktur integrieren kann und zeigt, was sich tut! --Q. 14:56, 24. Aug. 2010 (UTC)

mach mir mal am besten ein tut wie ich am inteligentesten ein branch mach für mein rpg zeug die sache mit dem tty? mach doch was ganz böses indem du sowas machts:

1
2
3
4
5
6

STDIN = StringIO.new
class << STDIN # oder über singletonclass
  def tty?
    return true# ist zwar böse aber was solls XD
  end
end

--Hanmac 09:03, 25. Aug. 2010 (UTC)

Du wirst lachen, aber das habe ich schon versucht. Das hilft nichts, weil Ruby irgendwo die C-Funktion isatty aufruft, anstatt die Ruby-Methode aufzurufen.
Das branching-Tutorial schreibe ich gleich in die Projekt-README, gut dass du mich drauf aufmerksam machst. --Q. 10:37, 25. Aug. 2010 (UTC)

So, die README für den gui-Branch (einsehbar unter http://github.com/Quintus/OpenRubyRMK/tree/gui ) enthält jetzt ein absolutes Mini-Howto, das aber annimmt, dass der Leser zumindest mit Alltagskommandos wie git commit vetraut ist. Wenn ihr mögt, kann ich ein ausführlicheres Git-Tutorial schreiben, aber eigentlich denke ich, dass man mit dem Pro-Git-Buch schon alles abgedeckt hat. --Q. 11:23, 25. Aug. 2010 (UTC)

Guckt eigentlich keiner von euch die E-Mails für openrubyrmk@googlemail.com nach oder wollt ihr mich einfach nur so vor mich hinwerkeln lassen? --Q. 17:08, 11. Sep. 2010 (UTC)

Marshalling

1
2
3
4
5
6
7
8
9
10
11
12
13

Item = Struct.new :name, :type, :desc, :user

require 'yaml'
YAML.load(DATA)

__END__
--- !map:Inventory 
!ruby/struct:Item ? 
  name: Flower
  type: :pot
  desc: A pretty flower to increase your health by 10
  user: 
: 1

Die Idee dahinter war, dass erstens die Item Instanzen direkt im Inventar referenziert werden und die anderen Items erst bei Bedarf nachgeladen werden (man muss ja nicht 10.000 Itemsobjekte im Speicher halten, wenn eh nur 50 gebraucht werden). Das Inventar ist ein Hash, der als Schlüssel das Item und als Wert deren Anzahl beinhaltet und genau diese Kombo { Struct=>Integer } scheint problematisch zu sein. Ideen, Vorschläge, Kritiken? :-D Grüße --Kjarrigan 09:26, 10. Aug. 2010 (UTC)

Trift das Problem auch auf wenn du Klassen nutzt anstatt Strukturen? ich hatte ein ähnliches Problem wenn ich meine items mashale. Ich hab das damit gelöst das die Klasse alle erstellten Items speichert und in den instanzen der anderen klassen intern nur die ids gespeichert werden:

1
2

p @proxy #=> <Proxy @value=[1,2,3] @type=RPG::Item>
p @proxy.to_a #=> [<RPG::Item @id=1>,<RPG::Item @id=2>,<RPG::Item @id=3>]

Das Sorgt dafür das die items nur einmal gespeichert werden. vllt hast du da ein ähnliches Problem? PS: nutzt du die Item verwaltung für das RMK? --Hanmac 09:54, 10. Aug. 2010 (UTC)

Ein kurzer Test hat ergeben....geht auch nicht. Mist :-(

Also am Anfang hab ich auch mal die Idee gehabt eine "Itemtabelle" zu machen mit fortlaufenden Id's die dann überall sonst referenziert werden. Nun hab ich aber überlegt, dass während der Laufzeit eig die häufigsten, aktiven Instanzen, die im Inventar des Spielers sind (inkl der angelegten). Alle anderen treten dann eben nur mal auf in ner Kiste oder nem Shop oä. Ich wollte also gern die "aktiven" Items direkt im Inventar als Instanz halten und die anderen bei Bedarf aus der Tabelle nachladen (ob das nun ein DB oder ne CSV oder oder ist sei mal dahingestellt). Daher bin ich erstmal von der Id-Variante abgekommen. Das ginge aber mit YAML abzubilden, da dann ein Hash ala { Item_ID => Stk } entsteht, da bin ich aber noch nicht so zufrieden damit, weil dann alle anderen Aufrufe immer darüber laufen, dass die Items via Id rausgesucht werden müssen (bei jedem Menü öffnen, benutzen, anlegen, ...). Zu deiner letzten Frage: Die Itemverwaltung ist mittelfrist für das RMK und kurzfristig mein "gewähltes Modul" um verschiedene Marshallingsachen gegenüberzustellen, weil ich denke Abhängig davon wie wir die Daten abbilden/speichern können wird die Modulverwendung erfolgen. Grüße --Kjarrigan 12:47, 10. Aug. 2010 (UTC)

Zitat von Kjarrigan:

weil dann alle anderen Aufrufe immer darüber laufen, dass die Items via Id rausgesucht werden müssen

Nein, siehe oben mein Proxy, intern sind das ids nach außen sind das Objekte. für push zb will der objekte haben, wandelt die in ids um und pusht die weiter an den inneren array. heute nachmittag poste ich mal meine proxy class --Hanmac 13:10, 10. Aug. 2010 (UTC)

Ich melde mich mal eben schnell aus dem sonnigen Urlaub ;-) (30-Minuten-Tarif hier): Eventuell ist das ein YAML-Bug. Probiere mal 1.9.2 mit Psych als YAML-Parser aus, der läuft sauberer. --Q. 15:38, 15. Aug. 2010 (UTC)

Endlich melde ich mich auch mal wieder ;-) Habe diesen Montag meine abschließende mündliche Prüfung bestanden (deshalb war ich in dessen Vorbereitung auch so still) und bin nun völlig frei von jeglichen Studienpflichten :-D Endlich wieder Freizeit nach der Arbeit. Da ich nächste Woche Urlaub habe werde ich mal deinen aktuellen GUI Stand auf Herz und Nieren prüfen ;-) Außerdem wollte ich Hanmac bitten mal seine Proxy-Klasse "offen" zu legen. Entweder als Branch oder hier im Wiki. Die täte mich sehr interessieren. Besseres Wetter und Gutes gelingen --Kjarrigan 06:43, 2. Sep. 2010 (UTC)

hier ist noch eine ältere version meiner Proxy Class

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

#hier erstmal so eine klasse wie sie bei meinen RPGs gibt
class Beispiel
  def initialize
    Beispiel.instances.push(self)
  end
#und hier methoden für die Classe
# ich nutze die klasseninstanz variable um die Objekte der Klasse zu speichern ... so spar ich mir die Globalen variabeln xD
    @instances=[]
    class << self
      attr_reader :instances
      def each(&block)
        @instances.each(&block)
      end
      def [](id)
        return @instances[id]
      end
      def instances=(array)
        @instances.replace(array)
      end
      include Enumerable
    end
end

a=Beispiel.new
b=Beispiel.new
c=Beispiel.new
p Beispiel.instances # 3 Beipiel objekte

d=Proxy.new([],Beispiel)
d[0]=c
d[1]=b
d[2]=c
d[3]=a
p d # values zeigt: [2,1,2,0]
p d.to_a # etwa so: [c,b,c,a]

--ist das so verständlich? --Hanmac 13:15, 2. Sep. 2010 (UTC)

Entschuldige dass ich erst jetzt antworte :-D Hatte ja wie gesagt Urlaub und hab in der Woche viiieeeeel Abstand zu Rechnern und Internet gehalten ;-) Wollte mich ja entspannen. Ja deine Klasse ist so sehr verständlich und ich hab das in leicht abgewandelter Form auch schonmal in paar meiner Versuche integriert. Ein paar organisatorische Probleme beim serialisieren hatte ich dennoch. Ich muss nun nur erstmal wieder raussuchen was das war, da das ja nun schon etwas zurückliegt. Ggf meld ich mich dann zum Proxy nochmal.

@Quinuts: Deine Mail ist bei mir leider etwas untergegangen, da ich in meinem Donnervogel idR nur schaue, ob es was "neues" gibt und da die schon als gelesen markiert war, hab ich die erst gesehen, nachdem du deinem Ärger hier Luft gemacht hast :-D Ab da schaue ich nun auch regelmäßig an was sich im Mailorder befindet. --Kjarrigan 11:20, 20. Sep. 2010 (UTC)