Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

Käsekönig

1x Contest-Sieger

  • »Käsekönig« ist der Autor dieses Themas
  • Private Nachricht senden

1

21.06.2013, 12:46

Strategiespiel Planung

Jetzt wo ich die Matura hinter mir hab (yippiiiiiiiie, Erleichterung, haha :D ) und 3 Monate Ferien hab, will ich mal wieder anfangen, ein klein wenig zu programmieren.
Dazu mag ich mit einem Strategiespiel "anfangen". Eigentlich ist es nicht mehr anfangen, denn ich hab sowas schon mal in "1D" begonnen (Textbasiert in der Konsole) und in 2D angefangen, was dann aber letztendlich etwas in einem Chaos geendet ist.
Meine damalige Version hatte ein Spielfeld, man konnte in Gebäuden Einheiten erzeugen, andere abschießen und man konnte die Einheiten natürlich durch die Gegend schicken.

Jetzt mag ich soetwas erneut beginnen (wieder mit C++ und SFML und zusätzlich mit SFGUI), diesmal vielleicht eine kleine Spur besser geplant, so dass ich vielleicht weiter komme als letztes Mal.
In diesem Link wurde mir damals beim Einheitenhandling sehr geholfen. Folgendes hab ich davon umgesetzt: Es gibt die Basisklasse Einheit, abgeleitete Klassen Fahrzeug und Flugzeug. Diese hatten jeweils eine Variable Fahrzeugtyp, bzw. Flugzeugtyp, wo zum Beispiel drinnen stand LEOPARD_PANZER oder EUROFIGHTER. Je nachdem, welche Einheit es war, wurde diese Einheit eben mit anderen Werten initialisiert. Das mit dem Update und Render, sowie den überladenen Funktionen hat eigentlich ganz gut funktioniert. :)

Dann hatte ich eine main.cpp, in der ich das Fenster initialisiert habe und eine Spielschleife hatte. Außerdem gab es die MainClass mit Update und Render.
Diese MainClass ist nun glaub ich mein Hauptproblem. Die ist damals riesengroß bei mir geworden, weil einfach alles da rein kam. Sie war verantwortlich dafür, heraus zu finden, wo der User hin geklickt hat, die Einheiten dementsprechend woanders hin zu schicken, Einheiten einen Abschussbefehl zu geben, die Einheiten überhaupt zu handeln (in einer Liste zu halten), genauso wie alle Gebäude und all das. Die Update-Funktion dieser Klasse hatte letztendlich wohl schon über 500 Zeilen. Ich glaub, für die meisten Programmierer sind mehr als 50 Zeilen pro Funktion schon ein Graus, 500 Zeilen sind dann auch für mich als unerfahrenen Programmierer schon einfach nur noch ein Graus.

Deswegen mag ich das diesmal besser machen und hoffe auf Vorschläge, wie ich eventuell meine Klassen einteilen kann, und wie welche Klasse mit einer anderen verstrickt ist, damit es nicht in so einem Chaos endet.

Zum Schluss also nochmal eine Erklärung zum Spiel selbst:
Das Spiel soll mit C++, SFML und SFGUI umgesetzt werden. Es stellt keine Ansprüche darauf, auch wirklich mal fertig zu werden - wenns nicht klappt, klappts eben nicht (deswegen bitte kein "mach erst mal ein Pong" - denn das hab ich schon gemacht :P ).
Es soll ähnlich dem Spiel Empire Earth sein, allerdings sollen Rohstoffe zum Beispiel nicht global verfügbar sein. Das heißt, es gibt ein Lager, von dort müssen die Rohstoffe erst geholt oder hin gebracht werden. Von dem her soll auch auf "Logistig" bei diesem Spiel etwas Wert gelegt werden. Außerdem ist die Munition der Einheiten begrenzt (sie müssen sich also immer wieder "Nachschub" holen, die auch produziert werden muss). Es soll keine Multiplayerversion davon geben, das wäre sowieso zu aufwändig für mich. Aber eventuell mal eine KI (deswegen sollt ich die von Anfang an mit einplanen), gegen die man spielen kann - zuerst muss ich mal natürlich so weit kommen, Einheiten auf das Spielfeld zu bekommen, sie zu bewegen und mit Funktionen auszustatten.

Ich hoffe, jemand liest sich diesen langen Text noch durch und macht sich die Mühe, mir zu helfen. :) Bei Unklarheiten bitte einfach fragen, wahrscheinlich fehlen noch einige essentielle Infos. ;) Vielen Dank im Voraus.

xardias

Community-Fossil

Beiträge: 2 731

Wohnort: Santa Clara, CA

Beruf: Software Engineer

  • Private Nachricht senden

2

21.06.2013, 16:12

Einheiten sind naturlich das ideale Beispiel fuer Objektorientierte Programmierung.

Jedoch wuerde ich OOP nicht nur darauf beschraenken. Wann immer eine deiner Klassen oder Funktionen zu gross wird, ueberlege wie du diese in sinnvolle Teilaufgaben aufspalten kannst. Vielleicht brauchst du eine Klasse EinheitenManager wenn in deiner MainClass zu viel Code existiert um Einheiten zu verwalten, dann vielleicht gleich noch einen BuildingManager. Oder vielleicht eine PlayerController klasse welche die Steuerung durch den Spieler aus der MainClass heraus holt. Wie genau du das machst haengt ganz von deinem Code ab.

Wenn man noch nicht viel Erfahrung mit OOP hat ist mein Tip: Mach dir selbst vorher ein wenig Gedanken darueber was dein Spiel braucht und wie du es strukturieren wuerdest (Machst du ja bereits schon :thumbup:).
Wie bei deiner MainClass wirst du dann beim coden schnell feststellen, dass die Struktur so nicht funktioniert. An der Stelle kannst du dann erneut ueberlegen wie du umstrukturieren kannst (z.B. eine Klasse in mehrere Aufspalten, oder Logik aus einer Klasse herausholen und in eine andere Klasse packen, etc).

Das ganze nennt sich Refactoring, und gehoert in groesseren Softwareprojekten zum ueblichen Entwicklungsprozess. Ausserdem lernt man so am besten welche Strukturen sich fuer welche Probleme eignen, wo sich ueblicherweise Probleme ergeben, etc.

Schorsch

Supermoderator

Beiträge: 5 145

Wohnort: Wickede

Beruf: Softwareentwickler

  • Private Nachricht senden

3

24.06.2013, 11:42

Was sich anbietet ist zum Beispiel einzelne Viewklassen zu schreiben. Diese sind für ein und Ausgabe zuständig. Bei dem normalen Spieler wäre das, rendern, Soundausgabe und Eingabe abfangen und weiterleiten. Deine KI bekommt hinterher auch eine Viewklasse. In dieser wird natürlich nicht gerendert oder auf Tastatureingaben gewartet, aber im Prinzip ist es die Sicht der KI auf die Dinge und die Eingabe der KI. Für beide schaffst du ein gleiches Interface. So gefällt es mir zumindest sehr. Wie Xardias schon angesprochen hat, Managerklassen sind oft hilfreich um die Verwaltung von Objekten zu übernehmen. Dort erledigst du erzeugen, löschen und speichern von deinen Entitäten. Das können einerseits Gebäude und Einheiten sein, vielleicht aber auch so Dinge wie Partikel kannst du mit so einer Klasse managen. Zusätzlich solltest du dir mal das Zustandsmuster(Statepattern) angucken. Oft kann man seinen Code damit ein wenig entschlacken wie ich finde. Viele benutzen es eh schon für ihre Gamestate Logik, aber mit ein wenig Nachdenken kann man viele Einsatzgebiete dafür finden. Zum Beispiel sind große if-else Konstrukte oder Switch Blöcke oft ein Zeichen für ein gutes Einsatzgebiet von States. Möglicherweise fängst du einfach an und schreibst immer mal wieder hier wie es aussieht. Dann kann man dir konkretere Tipps geben.
„Es ist doch so. Zwei und zwei macht irgendwas, und vier und vier macht irgendwas. Leider nicht dasselbe, dann wär's leicht.
Das ist aber auch schon höhere Mathematik.“

Werbeanzeige