Background und Tiles führen keinen Code aus, also keinen bis auf das Gamemaker sagt draw da dieses Tile. Das spart Ressourcen, da du dann unter den Tiles nur zB Kollisionsobjects mit durchsichtgen sprites hast die mituntner irgendwelchen relevanten Code beinhalten, anstatt zig hundert verschiedene Objekte die alle den selben Code haben und nur eine andere Form haben.

Bitte korrigiert mich wenn ich falsch liege dass Tiles weniger Code haben und weniger Performance ziehen.

Jedenfalls brauchst du zB nur obj_player und obj_block(solid udn hausnummer 16x16px) und die geebn dir die Level form an. Drüber legst du dann alle versch Grafiken nur durch Tiles.

Sprites ohne Objekte sollen Code ausführen? Das kann ich mir nicht vorstellen.
Sie brauchen vielleicht mehr Speicher, da die interne Sprite-Repräsentation Infos über Kollisionsmasken usw. enthalten, aber ich glaube zur Laufzeit brauchen alle Varianten gleich viele Ressourcen. Der Unterschied ist also das "Drumrum", der einzelnen Bilder-"Datentypen", würde ich sagen.

Achso, ok.
Aber würde dann trotzdem empfehlen nur ein Objekt dafür zu nehmen, dass die Sprites in irgendeiner Datenstruktur hält. Gerade wenn es was größeres werden soll (ich weiß ja nicht was du vor hast), es auf alten Rechnern und in HTML5 laufen soll, macht sich das irgendwann schon schlagartig und stark bemerkbar. Also Objekte mit Sprites brauchen eindeutig sehr viel mehr Ressourcen als nur Tiles.

Hallo, du verwechselst da was... Sprites sind nicht gleich Objekte... wenn du in Objekten die Sprites bestimmst, sind das Objekte.
Lässt du durch Draw Sprite einen Sprite zeichnen, dann ist es ein richtiges Sprite, also kein Objekt, ergo kann kein Code ausgeführt werden, somit sind sie natürlich schneller als Objekte die mit Codes voll sind, ist doch eigentlich Glas klar, wenn ich was wo reinpacke, wird dieses Ding schwer

Instanzen erzeugen auf jeden Fall einen Overhead, den Tiles nicht haben. Da Tiles keinerlei Interaktionen haben, werden sie vermutlich in eine Liste gepackt, nach Tiefe sortiert und dann einfach immer stumpf durchlaufen. Wahrscheinlich werden sie zusätzlich noch ihrer Position nach sortiert, damit immer nur die sichtbaren Tiles schnell und effizient gezeichnet werden können. Du killst diesen Vorteil natürlich, wenn du regelmäßig Tiles löschst/hinzufügst, da dies einen Eingriff in diese vorsortieren Datenstrukturen erfordert.

Dass wir Instanzen manuell deaktivieren können und auch dazu angehalten sind, ist eigentlich ein ziemlich deutliches Indiz dafür, dass der GM mit vielen Objekten schlecht skaliert. Dem könnte man durch cleveres Bucketing (man packt alle Instanzen, die sich eine Eigenschaft teilen, in einen "Eimer" und muss dann nur diesen Eimer durchsuchen) oder sortierten Attributlisten (man speichert z.B. Referenzen auf alle Instanzen sortiert nach x-Position ab, um später schneller Instanzen finden zu können) beikommen, allerdings ist die Effizienz davon sehr vom Projekt abhängig und lässt sich kaum Verallgemeinern.
Wir können daher davon ausgehen, dass der GM das nur an wenigen Stellen macht.


In den Studio-Examples ist übrigens ein schönes Beispiel, wie Tiles auch Kollisionswände ersetzen können.