Struktur/Aufbau eines Spiels
Übersicht

TritiumBetreff: Struktur/Aufbau eines Spiels |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Moin,
vorab: Ist eigentlich keine Design-Frage, wusste aber nicht, wo ich sonst fragen soll. Falls nötig also bitte verschieben. Nun zur Frage: Ich mache mir momentan Gedanken darüber, ob es "allgemeingültige" Strukturen für den funktionellen Teil eines Spiels (Code) gibt, die sich in allen Genres anwenden lassen. Also quasi ein Code-Grundgerüst, das erstmal vollkommen unabhängig vom eigentlichen Spielinhalt ist, und auf dem man aufbauend (durch das Gerüst dann strukturierter und effektiver/effizienter) dann das eigentliche Spiel implementiert. Wie macht Ihr das? Kennt Ihr Links, die mit der Thematik zu tun haben? Bin um jede Anregung dankbar ![]() (Es geht hier nicht um ein konkretes Projekt, es ist eine allgemeine und eher theoretische Frage) |
||
![]() |
BladeRunnerModerator |
![]() Antworten mit Zitat ![]() |
---|---|---|
100% allgemeingültig lässt sich das nicht beantworten - ein Textadventure hat ja zB ein komplett anderes Interface als ein Egoshooter. Auch die Logik im Hintergrund ist komplett anders.
Ein 2d JnR wird auch komplett andere Mechaniken brauchen als zB ein Schach. Dennoch gibt es weitreichende Gemeinsamkeiten: Jedes Spiel was auch nur im Ansatz grafikbasierte Ausgabe besitzt wird eine Zeichenlogik brauchen, die man dann überladen kann. Auch ein UI muss bei jedem Game vorhanden sein. Allerdings beschränkt sich dann die Anzahl wiederverwendbarer Zeilen enorm. Pseudo-Code: [AUSKLAPPEN] Init() Mainloop( UserInput() Evaluate() Draw() ) CleanUp() Sollte wohl das Minium darstellen. Ich verwende gern Gamestates um die Schaltlogik in der Evaluation zu beeinflussen, sowas lässt sich auch als schön als eigene Singleton implementieren. |
||
Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92 |
![]() |
Jolinah |
![]() Antworten mit Zitat ![]() |
---|---|---|
Was für jede Spiellogik sehr nützlich sein kann sind - wie bereits erwähnt - Gamestates. Etwas weiter geführt könnte man z.B. eine Statemachine oder einen Behavior Tree umsetzen, mit dem sich dann die Logik von einzelnen Objekten oder vom ganzen Spiel abbilden lässt.
Im wesentlichen gibt es immer einen Zustand in dem sich das Spiel oder ein Objekt gerade befindet. In diesem Zustand werden bestimmte Aktionen ausgeführt. Entweder werden diese Aktionen immer wieder ausgeführt (so lange der Zustand aktiv bleibt) oder die Aktionen werden nur einmal ausgeführt und danach wird ein anderer Zustand aktiviert. Eine Aktion könnte auch direkt veranlassen, dass ein anderer Zustand aktiviert wird usw... Wenn man das objektorientiert umsetzt, könnte man die Aktionen jeweils als Types/Klassen definieren. Dadurch können Aktionen in mehreren Zuständen wiederverwendet werden. Wenn man die Aktionen abstrakt hält, könnte man diese auslagern und sogar in mehreren Spielen verwenden. Die Aktionen haben Eigenschaften, mit denen sich die Aktion beeinflussen lässt und evtl. auch Eigenschaften und Methoden die von aussen wieder ausgelesen werden können. Sie können Events auslösen auf die der Zustand reagieren kann um zum nächsten Zustand zu wechseln. Das soweit nur als Idee. Es gibt sicher noch viele andere Ansätze. Aber allgemein könnte man sagen, es muss wahrscheinlich etwas sein, das selbst keine Logik vorgibt, aber es zulässt jegliche Logik damit strukturiert zu modellieren. |
||
PhillipK |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Ich habe bereits vor guten 2-3 jahren "GameStates" für mich entdeckt.
Diese enthalten ein grundlegendes gerüst, OOP basiert, wovon ich diverse objekte spiel/programmlogiken extenden kann. ACHTUNG: Mir fällt keine NICHT OOP basierte möglichkeit für das folgende ein. Hör einfach auf zu lesen, wenn du kein oop hast D: Du sparst einfach deine nerven. Ein Gamestate bildet in sofern also ein Interface, allerdings ist das für meine abstraktion nichtmehr möglich. Grundlegend sieht es so aus: - Class GameState. Enthält diverse globale funktionen wie "MakeActive" "CloseActive" "Render" "Update". MakeActive verwaltet einen stack mit aktiven Gameobjekten. Es gibt immer ein Aktives GameState, welches render und update aufrufe erhält. CloseActive schließt eben dieses aktive und holt das letzte GameState vom stack. Keins mehr vorhanden? Programm ende. Render leitet eine reihe von aufrufen an diverse methoden an das aktive GameState-objekt weiter. Ein beispiel könnte sein: Draw() DrawOverlay() Dabei wird vor Draw() die Matrix gesichert, und nach Draw() wieder zurückgesetzt. Ebenso vor DrawOverlay() und danach. So kann man zb im Draw() die eigentliche Zeichensachen regeln, in DrawOverlay() so dinge wie eine HUD oder andere Gui Elemente. Update() leitet lediglich ans Aktive GameState den update-methoden aufruf weiter. Mein " Hauptprogramm" ist dahingehend extrem klein: 1) Diverse globale ressourcen laden (fonts zb) 2) Ein GameState starten (beispiel: GameState.MakeActive( new MainMenu()) 3) Loop: GameState.Render(), GameSTate.Update() Alles weitere wird in den GameState objekten durch überladung der Draw(), DrawOverlay() und Update() methoden geregelt. Hier mal mein Monkey-Gamestate. Sollte einigermaßen leserlich sein ![]() BlitzMax: [AUSKLAPPEN] #GAMESTATE_DRAW_GUI_KEEPER=1 (GuiKeeper ist ein Verwalter für GuiObjekte, ebenfalls aus einem privaten modul) Dieses System findet auch verwendung in meinem ersten spiel. Hier sind alle möglichen "Menus" sowie die spielsache eigene GameStates. Hauptmenu -> klick auf neues spiel -> Levelselection gamestate starten. Von dort kann man zu "ingame" gelangen (Levelselection kommt NICHT auf den stack.) Ingame kann man gewinnnen ( WinningScreen Gamestate) oder verlieren ( LooseScreen GameState). Ingame kommt NICHT auf den stack. Beendet man den win / loss screen, wird MainMenu wieder vom stack geholt. Man hat eine voll funktionsfähige und logische verkettung von diversen Fenstern / Ingame sachen. |
||
Übersicht


Powered by phpBB © 2001 - 2006, phpBB Group