Das Framework setzt man auf indem man ein Root Objekt anlegt. Dieses Root Objekt beinhaltet ein Layer-Faktory Objekt. Root übernimmt die Kontroll- und Steuerfunktione, Layerfaktory übernimmt das erzeugen und addressieren der Layer Objekte. Layer Objekte sind einzelne Ebenen die von unterschiedlichen Typen sein können. Es gibt im Framework viele vordefinierte Typen, über die selbst abgeleitete Layerfaktory können aber eigenen Typen und abgeleitet Typen erzeugt werden. Ein Layer, Ebene, wird als eigenständiges Objekt gesehen, das auch alleine existieren kann. <§f=Aufgaben von Root:§> Das Framework benötigt eine bestimmte Organisation. Die Wurzel von allem ist das Root Objekt. Das Root Objekt steuert zwei Actor Queues und ein State Object. LAYERFACTORY QUEUE. =ul> Begriffserklärungen: CActor Objekte zeigt. \GLOBALOBJECT .... Eine Global-Object ist ein vordefinierter Layer der im Framework ausprogrammiert ist und verwendet werden kann. \STATE ... Ein logischer Zustand des Spiel. Als States kann man definieren: Intro, Heuptmenü, LevelInit, Level, Gameover, Hiscore und dergleichen. \STATEOBJECT ... Objekt abgeleitet von CRoot. Über Root kann mit initstate und newstate ein State Objekt erzeugt werden. =ul> Globale Objekte sind vorprogrammierte Layer die entweder wichtig für das funktionieren für das Framework sind oder einfach für viele Gameprojekte Standardmässig Verwendung finden. Beim Initialisieren vom Root Objekt werden die globalen Layer Objekte eingehängt. Layer Objekte sowie Root und alle globalen Objekte verstehen Kommandos in Form von Asciistrings. Jedes Objekt hat eine Message Funktion der dieser String übergeben wird. Root hat für die Verteilung der Messages auch noch zwei Funktionen: Root::SendMsg() und Root::HiPriMsg(). Root::SendMsg() speichert die Message auf eine Queue die am Ende eines Frameloops abgearbeitet wird. Root nimmt die erste message aus der queue und iterriert alle Objekte durch. iterriert die Objekte sofort durch, auch während des Frameloops. Für jedes der einzelnen STATES bei einem Game ist auch eine eigene Programmierung nötig. Ein Menü tut einfach etwas anderes als ein Level Programm. Diese States werden in STATE Objekte abgebildet die vom Root geladen und initialisiert werden können. Bei Spielstart wird in der Root InitPlayfield Methode neben dem Bildschirm Modus daher auch der erste Game-State gesetzt. Ein Satewechsel passiert wieder durch die Root Funktionen newstate oder initstate. Dieses Framework ist so aufgesetzt, dass jeder Sate ein eigenes Verzeichnis mit einem state.cfg File besitzt. Die Verzeichnissstruktur und der Filename von state.cfg ist frei wählbar, für die Dokumentation und für die Beispiele sind die Vorgaben folgende: 1) Hauptverzeichnis für GameResourcen: data 2) Für jeden State ein Subverzeichnis 3) Das State Initialisierungsskript heisst state.cfg Die Fileorganisation beginnt ab dem Root Verzeichnis. Damit ist das Verzeichnis gemeint indem sich die Game Exe befindet. Innerhalb dieses Root Verzeichnisses können beliebige Unterverzeichnisse angelegt werden. Organisatorisch sollte man die einzelnen Game-States auch in verschiedene Verzeichnisse legen: 
   [root]
   /game.exe
   /data/
   |    /intro/
   |    |     /background.png
   |    |     /state.cfg
   |    |
   |    /menu/
   |         /menubkgnd.png
   |         /menutilemap.png
   |         /wave1.wav
Der Bildschirm wird in Layer Schichten aufgebaut, d.h. jeder Layer hat eine zorder. Das Background Object hat die zorder 0, danach wird aufsteigend, der zorder nach, jedes der anderen Layer darüber gezeichnet. Layer mit gleicher zorder werden in unbestimmter Reihenfolge gezeichnet. Der Wert für zorder ist frei wählbar, sollte aber Raum für das nachträgliche einfügen von layers vorhanden sein. Beispielprojekt: ZOrderSample.zip