Wieso kann man die Figuren bei "Super Mario" von außen beeinflussen?

[Peter Griffin]

Seht euch das mal an: www.youtube.com/watch?v=-jbFjhBYCjg

Wieso funktioniert das? Also nicht, wie er diesen Emulator programmieren konnte, sondern wieso das Spiel das zulässt. Wenn ich ein Spiel programmieren würde, wären die ganzen Figuren nichts weiter als ein paar Integervariablen im Speicher und die Grafikroutine würde dann mithilfe dieser Variablen die aktuelle Spielszenerie aufbauen. Das heißt, auch wenn man den Speicherbereich der ausgegebenen Grafik abfangen würde, könnte man damit nicht das Gameplay beeinflussen:

foreach (Sprite sprite in Sprites)
    backBuffer.DrawImage(Graphics.GetImageFromID(sprite.ID), sprite.X, sprite.Y);

backBuffer.DrawToScreen();

Keine zusätzliche Manipulation des Bildes könnte die Sprite-Variablen beeinflussen.

Also wieso können in dem Video die Sprites durch die Luft gewirbelt werden?

[SeppJ]

Ganz einfach: Du beeinflusst die paar Integervariablen im Speicher.

[Peter Griffin]

Und das soll hier passiert sein? Dass der Benutzer physisch auf eine Figur klickt, der Emulator dann die Position ermittelt und dann durch alle Variablen im Speicher durchgeht und guckt, auf welchen Gegner gerade geklickt wurde, um dessen Werte zu manipulieren? Glaub ich nicht. Mir sieht das eher so aus, als würden die Sprites hier komplett freiliegen und als würde es keine Unterscheidung zwischen innerer Spiellogik und Grafikausgabe geben.

[Ein ehemaliger Benutzer]

Mithilfe des Emulators kann er doch natürlich "tracen" wo das ganze Zeug gespeichert wird.

[SeppJ]

Peter Griffin schrieb:

Und das soll hier passiert sein? Dass der Benutzer physisch auf eine Figur klickt, der Emulator dann die Position ermittelt und dann durch alle Variablen im Speicher durchgeht und guckt, auf welchen Gegner gerade geklickt wurde, um dessen Werte zu manipulieren? Glaub ich nicht. Mir sieht das eher so aus, als würden die Sprites hier komplett freiliegen und als würde es keine Unterscheidung zwischen innerer Spiellogik und Grafikausgabe geben.

Häh, woran willst du das denn gesehen haben? Wenn ich mir das so angucke, sieht das für mich genauso aus wie ich es geschrieben habe. Das sieht man zum Beispiel an diesen grünen Rechtecken um die anklickbaren Gegenstände.

[nman]

Peter Griffin schrieb:

Mir sieht das eher so aus, als würden die Sprites hier komplett freiliegen und als würde es keine Unterscheidung zwischen innerer Spiellogik und Grafikausgabe geben.

Klar, genau so soll das ja auch aussehen. Ist ein sehr nett gemachtes User-Interface.

(Bei PaintShop Pro oder Photoshop oder Gimp oder … sieht es auch so aus, als würdest Du mit Deinem Mauscursor auf den Bildschirm malen, nicht so, als würde das Betriebssystem die Mausposition tracken und das Grafikprogramm dann eine Bitmaske auf eine Ebene anwenden und dabei Mauskoordinaten interpolieren. Das bleibt verborgen, wenn der Interface Designer alles einigermaßen richtig macht.)

[Tobiking2]

Peter Griffin schrieb:

Und das soll hier passiert sein? Dass der Benutzer physisch auf eine Figur klickt, der Emulator dann die Position ermittelt und dann durch alle Variablen im Speicher durchgeht und guckt, auf welchen Gegner gerade geklickt wurde, um dessen Werte zu manipulieren? Glaub ich nicht.

Guck dir doch einfch das Script dazu an: http://fceultra.svn.sourceforge.net/viewvc/fceultra/fceu/output/luaScripts/SMB-Mouse.lua?revision=1256&view=markup

An einer Stelle im Speicher steht z.B. die Bildschirmposition und an einer anderen Stelle steht eine Liste der Monster. Klickt man nun auf eine Stelle auf dem Bildschirm kann man das in Levelkoordinaten umrechnen und herausfinden welches Monster man geklickt hat. Bewege ich nun die Maus kann ich die Mausposition wieder in Levelkoordinaten umrechnen und schreibe den Wert in den Speicher. Das Spiel merkt davon nichts und zeichnet die Monster ganz normal an der Stelle die im Speicher steht.