spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich gehe einfach mal davon aus, dass du noch sehr weit am Anfang im Bereich der Programmierung bist.
Vor allem musst du dir Aneignen, wie du deine einzelnen Bestandteile am Besten gliedern/aufteilen kannst. Ich kann nur raten, wie du bisher für die Darstellung der Bilder sorgst, allerdings gehe ich davon aus, dass du beim Zeichenen der Umgebung eine Bedingung hast, in dem einen Fall die Tür zeichnest, in dem anderen Fall den Innenraum und beim Anklicken der Tür den für die Bedingung notwendigen Wert änderst. (Das ist nur eine Vermutung meinerseits, vielleicht sieht es bei dir auch anders/besser aus.)
Der Spieler deines Spiels befindet sich immer in einer bestimmten Umgebung ("Vor dem Haus", "Im Wohnzimmer", "In der Küche", ...). Diese haben eine bestimmte Einrichtung bzw. besitzen Gegenstände, mit denen man interagieren kann und Elemente, die statisch sind. Du könntest also für jedes Element (statisch oder interaktiv) eine entsprechende Grafik vorhalten, um dieses darstellen zu können.
Wenn du für die Umgebungen nun also alle Elemente beisammen hast, kannst du die Aufgabe beim Zeichnen von "Ermittle alle zu zeichnenden Elemente und zeichne diese!" in "Zeichne die Umgebung, in der sich der Spieler befindet!" umdefinieren.

Mit Hilfe der objektorientierten Analyse kann man sich anhand einer Definition (teilweise habe ich oben die Gegebenheiten entsprechend abstrakt beschrieben) auf die für ein System erforderlichen Bestandteile und die somit erforderlichen Klassen und Methoden kommen. Einfach gesagt: alle Substantive sind Kandidaten für Klassen. Ich würde in diesem Fall bereits auf die Klassen "Environment", "StaticProp" und "InteractiveObject" kommen. Das ist allerdings nur der erste Schritt für eine Klassenstruktur, wodurch wahrscheinlich noch gemeinsame Basisklassen sinnvoll sein könnten oder bestimmte Spezialisierungen nicht erforderlich sein.


Die Interaktivität bei einem Adventure ist wieder eine eigene Sache (man kann auf unterschiedliche Arten an die Sache heran gehen), sollte aber hoffentlich nicht zu schwer sein.
In den meisten Adventures kann man Objekte ansehen, benutzen, oder mit Gegenständen benutzen und man kann Gegenstände miteinander kombinieren. Es könnte also entsprechende Methoden geben, die diese Interaktionen versuchen auszuführen und einen Fehler/eine entsprechende Rückgabe liefern, wenn es nicht funktioniert, man könnte aber auch Methoden anbieten, die prüfen, ob eine entsprechende Interaktion möglich ist (damit der Charakter bspw. sagt "Nö, geht nich'!").
Interessant wird es genau dann, wenn man definieren möchte, was ein Objekt macht, wenn man es benutzt, aber ich will dir natürlich nicht den ganzen Spaß rauben.

Also ich habe Sacaldurs Comment nur halb gelesen, da ich in letzter Zeit sehr unkonzentriert bin(nix gegen dich Sacaldur ) also weiß ich nicht ob ich jetzt dasselbe sage wie er:
Ich denke mal das du einige Grundlagen wie Klassen oder Rendern von Gegenständen schon beherrschst, und nach deiner beschreibung denke ich ähnelt das ganze einem Wimmelbildspiel, aber ich lege dir jetzt mal dar, wie ICH da rangehen würde (da ich selber noch Anfänger bin, gibts keine Garantie)
Du machst erstmal das Grundgerüst für das Spiel, also alles, was du später brauchst(Framework, Timer (wichtig),eine Klasse um deine Bilder zu rendern (bei mir heißt sie immer Sprite)).
Danach würde ich folgender maßen vorgehen.
Du baust jede Map in einer extra Klasse auf, je nachdem auf welchen Punkt man drückt(bei dir die Tür) ändert sich eine Variable(die ich meist "running " nenne)diese setzt du anfangs auf 1 oder 2 , was dir halt am logischsten vorkommt. Das Level packst du mit all seinen funktionen in eine do/while schleife mit der Bedingung, das die variable immer noch deiner wahl entspricht.Vor der Schleife baust du die Map auf, z.b. eine Funktion, die auf die Tür ein Event setzt, welches dann die variable "running" ändert und auch alles, was du sonst noch so brauchst.
In die Schleife packst du dann die Funktion, die den Wahrheitsgehalt der Variable überprüft, die durch das aktivieren der Eventfunktion geändert wird.So wird innerhalb der Schleife dauerhaft überprüft, ob die Tür angedrückt wurde.
In die Schleife gehören sicherlich noch andere Funktionen (mir fallen grade spontan keine ein, da ich ein Gedächtnis wie ein Sieb habe) aber du wirst sicherlich merken, was alles in die Schleife gehört, wenn du das Programm schreibst.
unter diese Schleife baust du dann einige if Funktionen ein, eine für jedes Level, das man über das momentane Level erreichen können soll in der du überprüfst, welchen wert die Variable hat. Klickst du die Tür an, hat der Wert "running" ja nicht mehr denselben wert, wie in der bedingung der "while" schleife(zumindest sollte er das nicht)

So baut (zumindest ich) man mit einfachen, überschaubaren funktionen ein Level auf.

Für das Inventar oder ähnliche Dinge(wie z.b. den Wahrheitsgehalt, ob eine Quest noch offen ist oder schon absolviert wurde) baust du dir dann eine statische Klasse, mit Funktionen um all diese Werte zu überprüfen(natürlich müssen alle Variablen statisch sein) z.b. ob du ein Item Besitzt, oder wie viele davon.
Eine Instanz dieser Klasse MUSS in jeder anderen Level-Klasse enthalten sein, so kannst du in jedem Level überprüfen, welche Items eingesammelt wurden, welche Quests noch offen sind, und alles, was du überall im Spiel an Inhalt brauchst.

Wie du ein visuelles Inventar Programmierst weiß ich leider nicht, sonst würde ich es dir erklären, doch ich bin schon daran am Arbeiten, eines zu entwickeln.



So würde ICH das machen, wenn ich dass jetzt umständlich mache, oder gar inkorrekt bitte ich doch die Profis, mir dies zu melden, da ich(wie gesagt) noch ein Anfänger bin, der sich so ziemlich alles selbst erarbeitet hat, mit einem einzigen Buch und dem Gehirn.


Des weiteren würde ich hier mal sagen, dass(wenn du wirklich noch so wenig Erfahrung hast, wie ich das jetzt aufgegriffen habe)du dich mal mit einfachen Spielen beschäftigen solltest, die nur eine Map umfassen, und mit denen du lernst, Techniken richtig anzuwenden und (VOR ALLEM) solltest du dabei lernen, dir Techniken logisch selbst zu erschließen. Ist wirklich nicht schwer, wenn man mal angefangen hat, innovativ zu sein, kommen die Ideen wie von alleine, du musst dich nur noch drum kümmern, dass deine Idee unterm Strich auch so funktioniert, wie sie sollte.
Vorschlagen würde ich dir mal als Beginn und Einstieg ein 2d Rpg mit einem Charakter der rumrennt, und Zombies oder anderem zeugs, gegen die es sich zu verteidigen gilt. Die Grundtechniken sind relativ einfach, jedoch ist ein solches Spiel(wie ich es beschrieben habe) noch sehr ausbaufähig, d.h. die Grundarbeit ist bereits getan, du bist jedoch in der Lage zu lernen , neue Techniken, wie z.b. eine gute KI selber zu entwickeln.

wenn du mir eine Pn schickst, erkläre ich dir mal alles in Ruhe und schicke dir mal ein Projekt, dass zwar nicht funktioniert, da ich versucht habe, ob ich Arrays vergleichen kann, ohne die Buchstaben einzeln zu überprüfen, aber es zeigt das gerade erklärte System relativ gut.(Ich schreib auch Kommentare dazu dran und fasse das ganze in Funktionen wenn dir das hilft mich zu verstehen )

Viel Glück dennoch mit deinem Vorhaben

Nein, du hast nicht das gleiche wie ich beschrieben. Ich wollte auf die objektorientierte Analyse als Werkzeug innerhalb des Objektorientierten Designs (und somit der Objektorientierten Programmierung) aufmerksam machen, was du in deinem Beitrag nicht getan hast. Und nur, weil man Klassen und deren Verwendung verstanden hat, heißt das nicht, dass man Objektorientierung verstanden hat und verwenden kann.

Nichts gegen dich, Nightmaremen, allerdings denke ich, dass er bestimmte von dir genannte Punkte so nicht umsetzen kann bzw. so nicht umsetzen sollte.

1. Ein Spiel hat zwar i. d. R. eine "Hauptschleife", ggf. kann diese aber in dem verwendeten Framework liegen, sodass man selbst keine Schleife selbst implementiert, sondern nur noch die Update- und Draw-/Render-Funktionalität. Das dürfte in diesem Fall gegeben sein.
   
2. Auch wäre es besser, wenn er die von ihm gehandhabten Elemente so allgemein hält, dass es in der Update-Methode egal ist, in welchem Raum/welcher Umgebung/welcher Map er sich befindet.
   
3. Ich weiß zwar nicht, was bei dir die 1 und/oder 2 bedeuten soll, wenn es keine Anzahl (2 Schlüssel) oder ein Wert (2 Lebenspunkte) ist, dann ist der Datentyp sehr wahrscheinlich ungünstig gewählt.
   
4. Ein Raum benötigt keine Variable "running", da dieser im Gegensatz zu Personen, Threads o. ä. nicht läuft.
   
5. Events sollten per Callback (siehe Observer-Pattern) entsprechend interessierte Stellen über Änderungen informieren, die entsprechenden Stellen sollten aber nicht permanent den gewünschten Wert abfragen müssen (Polling). In diesem Fall ist es die Tür, die den Wechsel des Raums zur Folge haben soll.
   
6. Für jeden Raum eine eigene Klasse zu implementieren dürfte unnötig sein, da man grundsätzlich alle Räume und deren Inhalte gleich behandeln kann. Letztendlich sind es die darin enthaltenen Objekte, die zu Aktionen (bspw. Raumwechsel, Gegenstand aufheben, ...) führen.
   
7. Nicht die Schleife (bzw. Update-Methode) sollte prüfen, ob "die" Tür im Raum angeklickt wurde. Was angeklickt wurde wird über die Auswertung des Inputsermittelt: Wenn Maustaste gedrückt wurde: Ermittlung der Mausposition relativ zum Fenster, Ermittlung der Mausposition relativ zur Szene/zum Raum, Ermittlung des angeklickten Elements, Benachrichtigen des Elements über das Anklicken.
   

Ich denke, dass ein Point&Click-Adventure sich dürchaus im Bereich des Machbaren bewegen kann, wenn man denn die richtige Herangehensweise wählt (und ich halte einen objektorientierten Ansatz in diesem Fall für sinnvoll).