Zitat Zitat
1) Woher kommt denn @damage_displays, die wird in deinem Code doch garnicht angelegt, oder täusche ich mich da? Außerdem ist der " ||= "-Operator den du hier bentuzt ist eine Veroderung von [] (einem leeren Array (?)) mit sich selbst. Bewirkt das etwas?
Ja =P Weil in Ruby die boolsche Algebra nicht nur auf boolschen Werten, sondern auf allen Objekten arbeitet. Ein Objekt zählt dann als "wahr", wenn es nicht false und nicht nil ist. Wenn du also schreibst (5 or 3) dann ist das Ergebnis ein wahrer Wert, nämlich 5 (nicht true!). Genauso ist das Ergebnis aus (nil or 2) gleich 2, das Ergebnis aus (1 and "Hallo") ist "Hallo" usw.
Die Operation
Code: 
x ||= y
# ist das selbe wie
x || (x = y)
# und das ist das selbe wie
if x then
  x
else
  x = y
end
In dem obigen Codebeispiel heißt das:
Code: 
displays = (@damage_displays ||= [])
# ist dasselbe wie
if @damage_displays then
  displays = @damage_displays
else
  @damage_displays = []
  displays = @damage_displays
end
Nur in 1 Zeile gegossen. Zugegeben, dass ist vielleicht nicht so offensichtlich. Aber diese Art den ||= Operator zu verwenden ist in Ruby üblich und verbreitet. Wenn man es einmal verstanden hat ist es ja auch ganz logisch. x ||= y heißt eben: Setze x auf y wenn x noch keinen Wert hat (oder false ist).

Zitat Zitat
3) Aber was macht die dritte Zeile Code hier? Ist das eine Methode? Wo ist die denn definiert? Oder ist das die Variable displays, aber du machst ja nichts damit, oder?!
Die dritte Zeile ist einfach der Rückgabewert der Methode. Man hätte auch return displays schreiben können. Aber in Ruby ist immer der letzte ausgeführte Wert einer Methode der Rückgabewert. Das return ist also optional. Wer imperative Sprachen wie Java oder C gewohnt ist, mag das fehlende return ja vermissen. Aber gerade in funktionalen Sprachen ist das schon lange üblich, dass return wegzulassen. Du schreibst in der Mathematik ja auch nicht f(x) = return x**2.

Zitat Zitat
4) Über update_damage_displays rufst du doch einfach die alte update-Methode aus Game_Screen auf, stimmts? (verstehe die alias Funktion noch nicht so recht, die bentutzt man ja um quasi die alte Methode zu erhalten und neue Befehle hinzu zu fügen, weil man hier update nicht komplett überschreiben will)
Genau. Hier ist ein kurzes Tutorial zu dem alias Befehl. In aller Kürze: Alias kopiert eine Methode unter einem neuen Namen. Die neue Methode verhält sich dabei exakt wie die alte. Der Trick ist jetzt, die alte Methode zu überschreiben und ihr ein neues Verhalten zu definieren und dabei die neue Methode aufrufen um das alte Verhalten einzufügen.

Zitat Zitat
5) Jetzt bin ich wieder verwirrt weil doch " @sprite_damage_displays ||= []" nichts tut, @sprite_damage_displays ist ja einfach leer?
Wieder genau dasselbe wie oben. Im Grunde genommen hatte ich nur keine Lust, auch noch die initialize Methode zu erweitern.

Zitat Zitat
6) "@sprite_damage_displays[displays.size..-1].each {|display| display.dispose}" Druchläuft das @sprite_damage_displays-Array und führt auf alle display die dispose Methode aus.
Nur die überschüssigen. Wenn der displays Array nur 5 Game_DamageDisplay Elemente beinhaltet, in unserem @sprite_damage_displays Array aber 8 Sprites liegen, dann müssen 3 Sprites gelöscht werden (die ja überschüssig sind). Im Grunde genommen musst du halt dafür sorgen, dass für jeden Game_DamageDisplay auch ein Sprite_DamageDisplay zur Verfügung steht. Wenn ein Game_DamageDisplay hinzukommt, musst du auch einen Sprite hinzufügen. Wird einer gelöscht, musst du auch einen Sprite löschen.
In den Standardscripten des Makers wird so etwas immer vermieden, in dem einfach feste Limits gesetzt werden. z.B. legt der Maker immer 50 Pictures an, egal ob alle 50 Pictures gerade gebraucht werden. Dadurch spart sich der Maker immer den Array mit Sprite_Picture "synchron" mit dem Array mit Game_Picture zu halten. Der Nachteil: Der Nutzer darf nicht mehr als 50 Pictures anzeigen, obwohl das technisch eigentlich kein Problem wäre. Durch diesen etwas komplizierteren Code erlauben wir dem Benutzen, beliebig viele DamageDisplays anzuzeigen.

Zitat Zitat
Was passiert denn hier? Also der Sinn dahinter ist, entweder einen neuen Spirte zu zeichnen oder einen bestehenden zu refreshen, aber die Syntax macht mich fertig
1. Wenn noch kein Sprite_DamageDisplay an Position index steht, dann erzeuge einen.
2. Rufe danach refresh auf und übergib das Game_DamageDisplay dem Sprite als Parameter. Der Sprite sollte in der Methode dann die Schadensanzeige zeichnen.

Die dispose Methode muss btw. auch gealiased werden, das hatte ich ganz vergessen.