Seite 1 von 1

Programm-Konzept zu meinem Mini-Spiel

Verfasst: 31.08.2017, 19:14
von starcow
Guten Abend Zusammen

Ich möchte in diesem Thread Ueberlegungen zum "Programm-Konzept" meines ersten richtigen Mini-Spiel vorstellen.
Lernerfahrung zu sammeln ist für mich dabei sehr zentral und deshalb geht es mir darum, die einzelnen Schritte einmal selbst entwerfen zu können.
Da ich noch ein Anfänger in der C++ Programmierung bin, bin ich einmal mehr auf eure kompetente Hilfe angewiesen :-D

Ich möchte noch vorausschicken, dass es mir in erster Runde nicht um die Grafik, resp. die Darstellung geht. Die Darstellung darf also sehr zweckmässig sein oder vielleicht sogar ganz fehlen. Viel wichtiger ist es mir, zu versuchen ein Konstrukt aufzubauen, welches stabil, schlicht und überschaubar ist. Im Idealfall vielleicht sogar elegant - obwohl dies mit meinen jetzigen Fähigkeiten vermutlich ein nur schwerlich erreichbares Ziel darstellt.

Also genug der langen Worte (:
Was mir vorschwebt ist folgendes:

Der Spieler soll auf einer 2D-Map eine Figur steuern können, welche folgende Aktionen beherrscht:
- Laufen
- Angreifen
- Items aufsammeln
- Items ablegen
- (Türen öffnen)

Gegner sind als bewegungslose, passive Objekte auf der Karte verteilt.
Werden sie angegriffen, verlieren sie Energie und werden gelöscht, wenn ihre Lebensenergie aufgebraucht ist.
Ich bin noch etwas unschlüssig ob ich bereits in erster Runde versuchen sollte, eine Kollisionsabfrage mit einzubauen (deshalb steht "Türen öffnen" in Klammern).

Ich habe versucht eine Art Konzept auszuarbeiten, wie das Spiel in seinem Kern konzipiert sein könnte.
Kernuberlegungen waren für mich zwei Dinge:
1) Es existiert ein Engine-Objekt, das alle weiteren Objekte verwaltet (quasi als Administrator) und die Funktionen für den eigentlichen Spielablauf zur Verfügung stellt, sowie Funktionen bereit stellt, deren Aufgaben stark generalisiert werden können und objekt-unspezifisch sind.
2) Die Objekte lassen sich miteinander verknüpfen und erlauben über ihre Methoden einen Daten-Austausch.
So soll z. B. der Spieler ein zuvor aufgesammeltes Objekt für seine Angriffs-Methode nutzen können, indem er per Get-Funktion die Attribute der Waffe anfordern kann.

An dieser Stelle mal die Grafik, die das ganze veranschaulichen soll:

Bild

Klassen-Objekte: Gelb / Zeiger: Rot / Listen: Blau
Ich hoffe es ist für euch mehr oder weniger lesbar.

Jedenfalls ist mir aber irgendwie noch nicht klar, wie ich es bewerkstelligen soll, dass ein Item auf zwei verschiedene Klassen zeigen kann.
In der Grafik fehlt z. B. noch die Klasse Kreatur. Idealerweise sollte ein Objekt-Item mit der gleichen Zeiger-Variable auf eine Player-Instanz oder eine Kreatur-Instanz zeigen können.
Das selbe gilt für die Attacken-Objekte (Ich habe mir überlegt, eine Attacke als Objekt zu designen, damit ich die Kreaturen einfach gegen die Attacken-Objekt-Liste abfragen kann).
Eine Attacke könnte ja von einem Player oder einer Kreatur kommen. Zwei separate Zeiger einzusetzen, je nach dem, wer die Attacke "besitzt", scheint mir nicht gerade elegant zu sein.

Wie denkt ihr darüber? Ich habe wirklich keine Ahnung, wie solche oder ähnliche Spiele grundsätzlich intern aufgebaut sind - und weshalb sie so aufgebaut sind.
Ich bin dankbar für jeden Input! :)

Gruss starcow

Re: Programm-Konzept zu meinem Mini-Spiel

Verfasst: 01.09.2017, 09:36
von joeydee
Hi Starcow,
grundsätzlich bist du mit deinen Gedanken auf dem richtigen Weg (Logik unabhängig von Grafik, möglichst eleganter allgemeiner Ansatz usw.)

Zu deiner Frage Kollision ja/nein:
Ja. Fange damit an. Kollisionserkennung und Feedback (physisches wie logisches) bilden einen wesentlichen Kern deiner Spielwelt:
Laufen braucht eine Kollisionsprüfung.
Angreifen braucht eine Kollisionsprüfung.
Aufsammeln braucht eine Kollisionsprüfung.
Ablegen braucht eine Kollisionsprüfung.
Türen öffnen geht z.B. über Kollisionsprüfung mit Triggern vor/hinter der Tür (mit Interaktion für aktives Öffnen, oder ohne für autom. Türen) - dann muss man nicht erst gegen die Tür stoßen.

Feinde, Angriffe etc. sind schon sehr weit gedacht. Mein Tipp für einen guten Anfang wäre:
- Figur steuern
- Allgemeine Kollisionserkennung mit Items (später Items = Wände/Hindernisse, Sammel-Items, Feinde, Trigger)
- Das physische Feedback darauf (abprallen, entlangsliden, weiterlaufen, ...)
- Das logische Feedback darauf (wer berührt was, was hat welche Auswirkungen auf wen, z.B.: Item von der Map löschen und Player-Inventar hochzählen, wenn die kollidierenden Items "Münze" und "Player" sind).

Damit solltest du schon etliche Spielideen realisieren können.

Zu deiner letzten Frage: suchtest du nach dem Vererbungsprinzip?
Typ Feind erbt von Typ Kreatur
Typ Player erbt von Typ Kreatur
Attacke muss nur Typ "Kreatur" kennen, gleiche Schnittstelle für alle; spezifiziert wird in einem Manager (Liste aller Speilobjekte). Dann muss auch "Player" nicht "FeindXY" kennen.
Entsprechend auch: Kreatur=Item, Wand=Item, Münze=Item, ... in Bezug auf obige Kollisionsgeschichte.

So ungefähr, vereinfacht gesagt, baue ich meine Sachen in der Logik auf (zuletzt z.B. "Kenneys Dreamland" aus der Action XII und "CyberHive").

Re: Programm-Konzept zu meinem Mini-Spiel

Verfasst: 03.09.2017, 22:07
von starcow
Vielen Dank joeydee, das hilft mir schonmal sehr!
Ich glaube ich verstehe jetzt, dass ich die Vererbung einsetzen muss, um dieses Verknüpfungs-Konzept umzusetzen.
Ein paar Ausführung verstehe ich aber nicht.
Was meinst du mit
Attacke muss nur Typ "Kreatur" kennen, gleiche Schnittstelle für alle; spezifiziert wird in einem Manager (Liste aller Speilobjekte). Dann muss auch "Player" nicht "FeindXY" kennen.
Was meinst du mit "spezifiziert wird in einem Manager". Ist "Manager" das, was ich jetzt als Engine bezeichnet habe? Und wie muss ich das "spezifizieren" verstehen?

Ich hab jetzt versucht, ein Vererbungs-Konzept zu skizzieren. Sollte ich über mehrere Ebenen vererben? Und wäre es von Vorteil ein Tür-Objekt ebenfalls in diese Struktur mit einzubauen?

Code: Alles auswählen

...........................Entity
............................/..|...\
........................../....|.....\
......................../......|.......\
....................../........|.........\
..................../..........|...........\
................../............|.............\
................/..............|...............\
............../................|.................\
.........Attack.............Creature..............Item
............................../...|................|....\
............................/.....|................|......\
........................../.......|................|........\
......................../.........|................|..........\
....................../...........|................|............\
...................Player.......Enemy............Weapon......Armor
Vielleicht kannst du mir noch ein paar Stichworte zur Kollisionsabfrage geben. Ist die Kollisionsabfrage ebenfalls ein Objekt, oder einfach nur eine Funktion?
Falls dir Material im Web bekannt ist, das sich dieser oder ähnlicher Thematik widmet, wäre das natürlich ideal!

Gruss starcow

Re: Programm-Konzept zu meinem Mini-Spiel

Verfasst: 07.09.2017, 16:08
von joeydee
Um deine Fragen einigermaßen befriedigend zu beantworten, müsste ich ein Buch schreiben. Und selbst das wäre wahrscheinlich nicht befriedigend.

Das meiste Material behandelt die konkrete mathematische Berechnung von Kollisionen - nicht die Organisation.
Für die Organisation gibt es fast beliebig viele Möglichkeiten, von komplexen allgemeinen Ansätzen bis zu einfachen, aber sehr spezifischen und kaum erweiterbaren Lösungen. Welche aber i.d.R. für ein ganz bestimmtes Spiel schnell implementiert sind und überschaubar funktionieren, statt ewig nicht fertig/nutzbar und viel zu sperrig zu werden. Womit alles dazwischen seine Daseinsberechtigung hat.

Ich kann daher auch nur sagen, was ich so mache/experimentiere, nicht wie "man" das macht, geschweige denn wie "man das am besten machen sollte".
Am besten ist aber eigentlich: Mache eine konkrete Spiel-Implementierung. Nicht erweiterbar, spezifisch: eine Sorte Feinde, eine Sorte Sammelobjekte, eine Sorte Hindernisse.
Wenn fertig, erweitere um einen anderen Gegnertyp, mehr Sammelobjekte, und rolle das damit erneut auf. So lernt man am ehesten was eigentlich wirklich benötigt wird, wo ewige Gemeinsamkeiten (Redundanz) herrschen, was völlig offen bleiben muss, und in welcher Form das alles wünschenswert und bequem bedienbar wäre.
Eine (wirklich nutzbare) Engine von Grund auf so zu entwerfen, dass die Objektverwaltung für alle künftig denkbaren Ideen/Funktionen/Typen in Frage kommt, ist ohne diese Erfahrung praktisch nicht möglich.

Deshalb: Schiebe das mit dem Vererbungskonzept besser weiter nach hinten, sieh das nicht als verbindliche Designgrundlage für die du dich jetzt entscheiden musst.

Du kannst z.B. so starten:
1. Bringe einen Kreis auf den Schirm, steuere diesen mit Tastatur, prüfe ob er sich innerhalb eines Rahmens befindet ("Map") und entscheide was passiert wenn eine Wand berührt wird (abprallen? entlangsliden? sterben?).
2. Bringe mehr Kreise auf den Schirm und prüfe auch auf Kollision mit diesen und triff Entscheidungen was dann passiert.
3. Du hast nun 3 Arten von "Entitäten" in deiner Welt: Map, Spieler, sonstige Kreise. Und verschiedene Arten denkbarer Kollisions-Antworten. Je Typ alles in einer eigenen separaten Klasse implementiert. Du wirst Redundanzen entdecken (Position, "kollidiert mit" - was soll passieren?, ...) und Unterschiede (wird gesteuert, steht still, hat eine ganz andere Kollsionsprüfung, kann sterben, ...)
4. Redundanzen packst du in eine gemeinsame Basisklasse, in welcher entweder a) alle Unterschiede durch das Setzen von Eigenschaften abgedeckt werden oder b) wovon die unterschiedlichen Typen erben.
5. a) gehört zu den sehr spezifischen Lösungen, einfach, gibt aber irgendwann viel Overhead in diesem "Super-Objekt" das alles sein will/kann.
6. für b): Unterschiede implementierst du in der jeweils abgeleiteten Klasse.
7. Deine Spielwelt ist nun eigentlich ein Manager, der je Update eine Liste von beliebigen Objekten durchgeht, aber alle nur auf der gemeinsamen abstrakten Basis "Entity" betrachtet (Gültigkeit des Objekte prüfen und ggf. aus der Liste löschen, Kollisionen mit anderen "Entitys" prüfen und an die betroffenen Objekte melden, usw.) ohne zu wissen was die Objekte konkret damit machen, und welchen Typ die wirklich haben. Dieser Manager behandelt also nur Gemeinsamkeiten.
8. Auch das kann dir irgendwann um die Ohren fliegen: Wenn Spieler und Blume kollidieren, entscheidet dann die eingesammelte Blume, was mit dem Spieler passiert? Oder der Spieler, was mit der Blume passiert? Oder die Welt, was mit beiden passiert wenn sie aufeinandertreffen?
9. Für Letzteres: hier kann z.B. der Manager den Typ eines Objekts mitgeteilt bekommen und darauf reagieren. Dann sind alle Entscheidungen zentral an einer Stelle implementiert (Spieler trifft Blume - was passiert; Spieler trift Monster - was passiert usw.) statt in die einzelnen Objekte verteilt.

Das nur mal so als Ansatz des Gedankens "spezifiziert wird in einem Manager" - Tja, was ist nun übersichtlicher, eleganter, bequemer zu bedienen, gut skalierbar?

Das Problem ist abstrakt gesehen ein wenig wie das Sortieren von Fotos in Ordner auf der Festplatte:
Mache ich die Ordner "Urlaub Malediven", "Urlaub Nordsee" und darin jeweils einen Ordner "Landschaften", "Familie" - oder mache ich "Landschaften" und "Familie" als übergeordnete Struktur und darin die verschiedenen Urlaube? Oder gar nach Jahreszahlen? Was wenn ich irgendwann weiter unterteilen will (Familie in "Kinder", "Verwandtschaft")? Gibt es "Pflicht"-Ordner die in jedem Unterordner vorkommen müssen? Schreibe ich bestimmte Kürzel in die Dateinamen mit rein? Oder nehme ich eine Bilddatenbank mit Tags, was aber sehr pflegebedürftig ist? Einen Tod muss ich sterben. Was optimal ist, kommt letztendlich doch sehr auf Art, Anzahl und Nutzung der Bilder an, also selbst eine ursprünglich "allgemein" angedachte Lösung wird am Ende wahrscheinlich doch sehr konkret sein.

Re: Programm-Konzept zu meinem Mini-Spiel

Verfasst: 10.09.2017, 22:10
von starcow
Erstmal vielen Dank joeydee, dass Du Dir einen solchen Schreibaufwand gemacht hast, mir dies alles zu erläutern!
Solche konkreten Ratschläge sind mir natürlich eine wirklich grosse Hilfe.
Deine Ausführungen wirken auch sehr schlüssig und ich werde mir Deinen Post auf jeden Fall als roter Faden zur Orientierung markieren.

Neben Deinem konkreten 9-Punkte Vorschlag, lese ich vor allem zwei wichtige Grundsätze aus Deinem Post:
1) Ein konkretes resp. spezifisches Design aufbauen und nicht versuchen, eine "immer gültige", universell erweiterbare, allgemeine Ideal-Lösung aufzuziehen.
2) Lieber Schritt für Schritt nach vorne gehen und gelerntes in Form einer Korrektur anbringen, anstatt zu versuchen X Schritte vorauszuplanen. Quasi: "Die Aspekte, welche ein wirklich schlaues Design ausmachen, wird man meistens erst im Umsetzungs-Prozess selbst erkennen können".
Das erinnert mich an die Maxime vieler Autoren, welche sagen, dass die guten Ideen erst beim schreiben selbst kommen. :)

Ich werde mich, mit diesen Weisheiten gewappnet, in die Aufgabe hineinstürzen und hoffentlich sehr bald ein erstes Zwischenergebnis hier präsentieren können.

Einen schönen Abend und Gruss :)
starcow

Re: Programm-Konzept zu meinem Mini-Spiel

Verfasst: 11.09.2017, 07:10
von joeydee
Ja, richtig, so bin jedenfalls ich immer am weitesten gekommen :) Dann drücke ich die Daumen dass es auch für dich ein guter Ansatz sein kann.