Performance meiner RPG Engine

schönen guten tag, einmal wieder melde ich mich pünktlich um die erhabene weisheit der forenmitglieder für meine zwecke zu nutzen.

Ich habe nach einiger überlegung ein kleines Script in gedanken fertig gestellt und wünsche mir von euch bitte einmal einen kommentar dazu ab zu geben ob die idee gut umsetzbar ist oder verbesserungen von nöten seien.
Besonders auf performance und vielfältigkeit der anwendungen sei zu achten.

Grobe einleitung in das thema, es geht um die umsetzung eines RPGs mit action-adventure elementen, es ist eine reine RGSS umsetzung ohne irgendwelche Event-Gui-Codes.
Hier die idee:
Die Klasse Game_Map speichert die einzelnen figuren auf einer karte wie feinde, schalter, gegenstände, grob gesagt: NPC's.
Im gegensatz zur Game_Map des standart scripts speichert sie jedoch weiterhin auch die einzelnen interaktionen mit den objekten, im Code würde es ungefähr so aussehen:

Code:

---

class Game_Map
 
  def initialize
    @npc = []
    @npc.push(Goblin.new)
    @npc.interaction("interaction_goblin")
  end
 
  def interaction_goblin
    print("Der Goblin betrachtet dich mit einem satyrischen Grinsen")
  end
 
end

---

wenn nun dem goblin der befehl 'Goblin.interaction' gegeben werden würde, würde die als '@interaction' gespeicherte Methode der Game_Map aufgerufen werden:

Code:

---

def Goblin
 
  attr_accessor :interaction
 
  def interaction
    $Game_Map.send(@interaction)
  end
 
end

---

und somit würden also die verschiedenen interaktionen mit den NPC's in der Game_Map gespeichert sein.

Bitte sagt mir eure ehrliche Meinung zu dieser Art der Durchführung und gebt wenn möglich Verbesserungsvorschläge.

Vielen Dank im Vorraus.
Cornix.

Erscheint mir zum einen ziemlich widersinnig, zum anderen bezweifle ich, daß du auf diese Art das hinkriegst, was du möchtest.

Zum Thema widersinnig:
So wie du es darstellst beinhaltet deine Klasse "Game_Map" alle Methoden für die Interaktionen mit den NPCs die auf der Map sind. Das ist eine mMn eine Vermischung der beiden Objekttypen "Map" und "NPC". Es sollte nicht von der Karte abhängen welche Interaktionen man mit einem NPC ausführen kann bzw. wie diese aussehen, sondern dies sollte nur vom NPC abhängen.
Du kannst ja problemlos auf verschiedenen Karten verschiedene NPC-Objekte platzieren die demnach auch verschiedene Interaktionen ermöglichen.
Anders ausgedrückt wo ist der Unterschied zwischen deiner Art und:

Code:

---

@npc = Goblin.new()
@npc.interaction

....

class Goblin

def interaction
 print("Der Goblin betrachtet dich mit einem satyrischen Grinsen")
end
end

---

Bei deinem Verfahren blähst du deine Game_Map-Klasse mit extrem viel Ballast auf, der logisch gar nicht zum Verhalten der Karte gehört, sondern vielmehr zum Verhalten der NPC-Objekte.

Zum zweiten:
Eine Speicherung von Methoden in objekten macht nur dann Sinn, wenn du letztlich zwei Objekte derselben Klasse haben willst, die beim selben Methodenaufruf komplett unterschiedlich funktionieren sollen.
Das wird bei deiner Art aber nur funktionieren wenn du extrem viele Methoden in deiner Game_Map definierst, was auch zu einem ziemlichen Namens-Chaos führen wird. (Wie willst du die Methoden benennen, wenn du 20 verschiedene Goblins hast, die alle unterschiedlich reagieren sollen?)

Anstatt eine bestehende Methode in ein Objekt zu packen, wie du es aktuell tust, solltest du direkt Ruby-Code in ein Objekt kapseln. Das kannst du einerseits machen indem du den Code einfach als String speicherst und zum ausführen "eval()" drüberlaufen lässt, oder du erzeugst aus dem Code direkt ein "Proc"-Objekt mittels Proc.new.
Das könnte dann so aussehen:

Code:

---

myCode = "print('Dies ist eine Testnachricht')"
# Ausführen von myCode
eval(myCode)

# Erzeugen eines Proc-Objektes, das einen Parameter entgegennimmt
myProc = Proc.new { |m| print(m) }
# Ausführen des Proc-Objektes
myProc.call("Dies ist eine Testnachricht")

---

Beides macht letztlich dasselbe, wobei ich davon ausgehe, daß die erste Variante deutlich langsamer ist. Damit könntest du aber völlig unabhängig voneinander zwei verschiedenen Goblin-Objekten zwei unterschiedliche Methoden verpassen, die diese jeweils in einer Instanzenvariable speichern und diese dann über denselben Namen aufrufen.

Ich hatte ursprünglich vor für jede Map die ich im Spiel einbaue eine eigene Unterklasse der Game_Map zu machen. Für einen Wald also eine art
"class Wald < Game_Map" diese Map speichert dann die einzelnen Interaktionsmöglichkeiten für diese spezifische Map.

Der Grund weshalb ich nicht solch eine Methode genutzt habe wie du es beschrieben hast liegt schlichtweg darin, dass ich keinerlei Ahnung hatte, dass soetwas existiert. Alles was ich über das Programmieren weis habe ich direkt oder indirekt durch beobachten und kopieren der standart RMXP Projekte gelernt.
Vielen Dank für das Aufzeigen dieser beiden Möglichkeiten.

Nebenbei, ein Frage hätte ich aber. Wenn ich nun vielerlei Objekte auf einer Map habe, gehen wir einmal von 20 Goblins aus numeriert als Goblin1 - Goblin20 und 17 davon sollen ein und die selbe Interaktionsmethode aufrufen während die übrigen 3 andere Aktionen ausführen sollen:
Würde es ncht vielfach einfacher sein die Interaktion dieser 17 Goblins in einer Methode zu verwirklichen und diese durch die Goblins aufrufen zu lassen anstatt jedem Goblin diese Methode speichern zu lassen?

Ich frage mich nur was du damit bezweckst? Warum ein so nützliches Hilfsmittel wie Events ignorieren?

Erstens bieten die standart Events des RMXP sehr viele Möglichkeiten welche ich für mein simples Spiel nicht benötige und lediglich unnötig an der Performance zerren.

Zweitens arbeite ich nicht gerne mit fremder Leute Werken, lieber erstelle ich mein eigenes Spiel vollständig selbst Klasse für Klasse.
Dadurch kenne ich genau das Material mit welchem ich arbeite auf der einen Seite und außerdem kann ich dann mit gutem Wissen behaupten es sei voll und ganz meine Arbeit gewesen.

Unter diesem Aspekt frage ich mich: Warum benutzt du ein vorgefertigtes Set von Funktionalitäten wie den Maker wenn du ehe alles selbst schreiben willst?
Ich meine, die Grafikengine ist auch von anderen geschrieben worden.

Da kannst du an sich auch gleich auf eine Engine umsteigen. Die hat dann weniger Beschränkungen als der XP.

Zitat:

---

Würde es ncht vielfach einfacher sein die Interaktion dieser 17 Goblins in einer Methode zu verwirklichen und diese durch die Goblins aufrufen zu lassen anstatt jedem Goblin diese Methode speichern zu lassen?

---

Das dürfte ziemlich egal sein. Ich würde aber eine Klasse für Interaktionen schreiben und den Goblins Instanzen dieser Klassen geben.

Code:

---

module Interaction
 
  class DoManyThings
    def initialize(interactions)
      @interactions = interactions
    end

    def execute_by(npc)
      @interactions.each {|action| action.execute_by(npc)} 
    end
  end

  class SaySomething
    def initialize(text)
      @text = text
    end

    def execute_by(npc)
      print @text
    end
  end

  # ...
 
end

# ...

@npcs = []
goblin = Goblin.new
@npcs << goblin
goblin.interaction = SaySomething.new("*Zieht eine Fratze*")

---

Zitat:

---

Zitat von Cornix

Erstens bieten die standart Events des RMXP sehr viele Möglichkeiten welche ich für mein simples Spiel nicht benötige und lediglich unnötig an der Performance zerren.

---

Dadurch wirst du kaum irgendwelche großen Performancegewinne einbringen.

Zitat:

---

Zitat von Cornix

Zweitens arbeite ich nicht gerne mit fremder Leute Werken, lieber erstelle ich mein eigenes Spiel vollständig selbst Klasse für Klasse.
Dadurch kenne ich genau das Material mit welchem ich arbeite auf der einen Seite und außerdem kann ich dann mit gutem Wissen behaupten es sei voll und ganz meine Arbeit gewesen.

---

Das Rad nicht immer neu erfinden zu wollen war eine Lektion die ich auch mal lernen musste. Du solltest dir das auch zu Herzen nehmen.

Ihr missversteht den Sinn meines Projektes. Ich habe nicht vor ein großartiges neues Spiel zu erfinden, zu erstellen und zu veröffentlichen.
Alles was ich mit diesem Projekt zu erreichen suche ist es mich mit dem Programmieren im Allgemeinen und dem RMXP im direkten besser aus zu kennen. Man könnte sagen es ist eine Art 'learning-by-doing' Prozess den ich hiermit anstrebe.
Nicht nur die grundlegenden Funktionen sondern vielmehr die Art und Weise wie man etwas umsetzt oder wie man mit möglichst großer effektivität möglichst viel erreichen kann versuche ich zu verstehen.
Der Lernprozess beim abschreiben ist allerdings nicht besonders groß und daher versuche ich so viel wie nur irgend möglich selbst zu schaffen, und gegebenenfalls um kleinere Hilfeleistungen zu fragen wo ich selbst nichtmehr weiterkommen kann.