Wie fange ich am besten mit Speielprogrammierung an?

[steffen1997]

Erstmal hallo,
meine Frage ist wie ich am besten in die Spieleprogrammierung einsteige,nur so zur Info ich kann schon relativ gut c++,muss ich planen, ohne planen bin ich bisher nicht weit gekommen(in anderen projekten,nicht in der spieleprogrammierung) ,wie plant man ein Spiel denn überhaupt,ich wollte ein snakespiel mit der sfml machen und habe mir das so gedacht(Die Planung):1.Ein Punkt bewegt sich(durch den Spieler)in die verschiedenen Richtungen ,aber nach vorne immer mit einer konstanten Geschwindigkeit ,also nur die Richtung wird bestimmt.
2.Ein anderer wird zufällig auf das Spielfeld gespawnt.
3.Wenn der Spieler diesen berührt ,verschwindet er ein neuer wird zufällig erzeugt und dieser Punkt
wird hinter den eigenen gepackt.Der Spieler bekommt Punkte ,wenn er diesen Punkt eingesammelt hat.Die Punkte werden angezeigt.
4.Wenn der Spieler gegen die Wand kommt.Ist das Spiel vorbei.

[Zudomon]

Huhu!
Als ich deinen Post so gelesen habe, hab ich mir gedacht, warum nicht mal auch ein Snake programmieren...
Hier das Ergebnis

Falls du fragen hast, wie in meiner Version bestimmte Spiellogik umgesetzt ist, helfe ich dir gerne!

[steffen1997]

Wie lange dauert das ungefähr als Anfänger?Das PRoblem bei mir ist ,ich weiß nicht wie ich etwas planen muss.

[Zudomon]

Wie lange dauert das ungefähr als Anfänger?Das PRoblem bei mir ist ,ich weiß nicht wie ich etwas planen muss.

Das kann ich dir leider nicht sagen, es hängt von vielen persönlichen Faktoren ab...

Tja... planen ist so ne Sache. Ich für meinen Teil plane sowas nicht, sondern mach einfach drauf los.

Also ich könnte ja mal kurz umreißen, wie ich da gestern ran gegangen bin:
Zuerst hab ich mir überlegt, was braucht man? Das geht dann los, indem man erstmal versucht ein Quadrat auf die Form zu malen mit einer bestimmten Farbe. Hat man das geschafft wäre es gut, wenn man, da Snake ja in einem Raster unterteilt ist, durch einen Index, den man für X und Y angibt, das entsprechende Quadrat zeichnen lassen könnte. Damit die einzelnen Kästchen noch zu erkennen sind, wird dann jeweils ein Pixel von dem Quadrat weg gelassen. In der Funktion könnte man dann gleich noch einen Offset mit reinrechnen, damit die Kästchen nicht an der linken oberen Ecke der Form beginnen, sondern mit etwas Versatz... nun könnte man die gesamte Spielfläche schonmal mittels einer zweier verschachtelten Schleife, die die Zeichenfunktion aufruft, füllen. Dann zeichnet man um das ganze noch einen Rahmen, damit man die Spielfläche als solche erkennt. Als nächstes gilt es, eine Schlange zu erzeugen. Da anscheinend X und Y Werte ausreichen, um einen Punkt auf dem Feld zu bestimmen, könnte die Schlange aus einem entsprechenden Datentyp bestehen ( bei Delphi TPoint ). Und da die Schlange aus mehreren Feldern besteht, wäre ein dynamisches Array ( da die Schlange ja auch wachsen soll ) nicht schlecht. Nun braucht man eigentlich nur noch das dynamische Array mit Werten füllen und eine Funktion zu bauen, die dieses Array dann Zeichnen kann. Eine "Frucht" ist dann genau das gleiche, nur eben, dass es sich dabei nur um einen einzigen Punkt handelt... Mit einer Funktion lässt sich ein Zufallsort für die Frucht bestimmen. Damit diese aber nicht direkt auf der Schlange liegt, bräuchte man noch eine Funktion, die das feststellt. Die Funktion muss nun nur alle Schlangenfelder durchgehen und schauen, ob die an die Funktion übergeben Koordinaten ein Schlangenfeld treffen. Nun kann solange die Frucht per Zufall erzeugt werden, bis sie nicht mehr auf der Schlange liegt.
Will sich die Schlange bewegen, wird es etwas schwieriger... also was muss passieren, damit sich die Schlange bewegt? Es muss ein neues Feld bestimmt werden. Die Schlange ist so gespeichert, dass bei Index 0 der Kopf liegt. Das hatte ich so gewählt, weil sie ja nach hinten hin wächst. Also müsste man den Index 0 verschieben. Verschieben geht entweder in X oder Y Richtung jeweils um -1 oder +1... Damit der Kopf nun nicht vom Körper abreißt, wird das Array einmal von hinten nach vorne durchgegangen und jeweils die Koordinaten des davor dahinterliegenden Punktes geholt. Dabei lässt man allerdings das erste Element aus, weil es keinen Vorgänger hat. Man hat nun die Schlange um einen Punkt vorgerückt, allerdings liegt nun der Kopf auf dem Körper... nun kann dieser auch um eine Einheit auf die neue Position verschoben werden. Das ganze klappt nun ganz gut, aber wir haben da noch ein Problem, da das Bild nicht gelöscht wird, wirds mit der Schlange immer weiter voll gemalt. Also machen wir folgendes, bevor die Schlange verschoben wird, wird der letzte Punkt der Schlange mit der Hintergrundfarbe aufs Bild gezeichnet. Nun kriecht die Schlange wirklich. Nun müssen wir Tastendrücke mit einbauen. Dabei muss eigentlich nur geschaut werden, welche Pfeiltaste gedrückt wird, diese gibt die Richtung an. Wird die Richtung auch als TPoint gespeichert, muss man diese nur korrekt setzen und kann diese dann bei jedem Zeitschritt auf den Schlangenkopf addieren. Genau, dabei hab ich die Zeitschritte übergangen. Also um die zu realisieren habe ich einfach einen Timer benutzt. Diesen kannst du auf ein bestimmtes Intervall einstellen, damit die Prozedur alle paar Millisekunden ausgeführt wird.
Nachdem nun die technische Grundlage steht, muss noch ein wenig Spiellogik rein. Also wenn der Schlangenkopf, dessen Position wir immer neu bestimmen von den Koordinaten her die Spielfeldgrenze überschreiten würde, ist das Spiel verloren. Genauso, wenn man sich selbst trifft. Dafür haben wir ja glücklicherweise jetzt schon die Routine um zu prüfen, ob ein Punkt auf der Schlange liegt... also liegt die neue Position des Schlangenkopfes auf der Schlange, so ist das Spiel ebenfalls verloren. Liegt der Schlangenkopf auf einer Frucht, so wird die Frucht auf neue Koordinaten gesetzt. Auch dafür haben wir ja schon eine Funktion. Nun muss man das dynamische Array, aus welchem die Schlange besteht, einfach um ein Feld verlängern. Nun brauchen wir noch eine Zählervariable. Sie stellt die Punkte da. Auch diese wird erhöht, wenn der Schlangenkopf auf der Frucht liegt. Hier lasse ich noch das Zeitintervall des Timers mit einfließen, so erhält man für jede Frucht etwas mehr Punkte, denn außerdem wird das Zeitintervall des Timers verringert.
Nun brauchen fehlt nicht mehr viel. Zwei Buttons auf die Form gesetzt: Starten und Beenden. Beim Starten werden die ganzen Initialisierungen vorgenommen, die eine Spielrunde bestimmen, also Schlange und Schlangenlänge auf Startposition, Richtung setzen, Punkte auf 0 Setzen, Timerintervall setzen, die beiden Buttons verstecken und den Timer starten. Ist das Spiel verloren ( ja gewinnen ist nicht möglich ), dann wird eine Meldung angezeigt, der Timer wieder deaktiviert und die Buttons wieder angezeigt. Der Beenden Button ist trivial. Nun fehlt nur noch eine Kleinigkeit, die Punkte müssen noch über ein entsprechendes Label ausgegeben werden.

Das wars... schon ist das erste Spiel fertig.
Wenn du dich lange genug mit Programmieren beschäftigst, dann musst du garnicht mehr darüber nachdenken, wie das alles umgesetzt wird. Genauso wie wenn du die Treppen hoch und runtergehst... da denkst du auch nicht über das "wie" nach. Selbst wenn du anfängst sie hoch oder runterzurennen, zu springen oder sonstwas, du musst nicht jedesmal neu lernen, wie man die eine oder andere Bewegung beim Treppen erklimmen anwendet, man macht es intuitiv.

Ich hoffe mal, die Anleitung hilft dir ein wenig, das Vorgehensprinzip für so ein Spiel zu verstehen.
Vielleicht machst du ja dann mal was für eine kommende ZFX-Action. Ich würde mich freuen! :D

PS: Und vergiss nicht, das, was du hinbekommst uns im Vorstellungsthread zu präsentieren!

Happy Coding! :D

[IlikeMyLife]

Ich war noch nie wirklich ein freund von Snake... als ähnlichen Schwierigkeitsgrad lässt sich auch gut Tetris einsetzen :-)
die Planung ist in etwa gleich von der komplexität der Aufgabenstellung.

[antisteo]

Snake ist einfacher.

Aber Pong ist noch mal einfacher.

[CrystalCoder]

Alles ist immer mindestes so schwer, wie man es sich selbst macht. Und wenn man stolz auf das sein will, was man gemacht hat, macht man es sich in der Regel (vielleicht unbeabsichtigt) selbst schwerer.

Zum Thema Pong vs Snake finde ich kann man kaum ganz genau festmachen welches der beiden Spiele leicher zu programmieren wäre. Der minimalste Aufwand wäre wohl in etwa der gleiche, jedoch wird man sowieso nie an das Minimum rankommen, weil es immer darauf ankommt wie der jeweilige Programmierer denkt und etwas umsetzt.

Ich hab mal nen Breakout geschrieben, was zumindest einem Pong ähnelt. Ich kann für mich behaupten Snake würde mir wesentlich leichter fallen. um bei pong ne halbwegs anständige Reflexion des Balls zu berechnen (wenn er net gerade nur 45° Reflektionen ausführen soll) müsste ich schon etwas mehr überlegen als ich im ersten moment für ein ganzes Spielprinzip für snake zusammenkriege:

Code: Alles auswählen

- Man nehme eine STL::list für die schlange. ein element= eine pisition auf dem raster und ein richtungsvektor (nur für 4 himmelsrichtungen).
-in der schleife:
-- abfragen der tasten und neu setzen der kopf->richtung
-- ist kopf->position+kopf->richtung == futter->position dann nichts tun außer ein neues listelement (neuer Kopf) nehmen mit Richtung des alten Kopfs und listelement->position=futter->position und auf die Schlange Pushen
----- keine Bewegung
----- futter->position = random.
-- wenn nicht dann letztes element der schlange nehmen, element->richtung = kopf->richtung setzen und element->position = kopf->position + kopf->richtung
-- zum schluß prüfen:
--- ist kopf->x oder kopf->y negativ oder größer als rasterbreite bzw -höhe
----- game over
-- alles malen
-- warten bis xx millisekunden vergangen
- schleifenende

Fertig ist das snake-grundkonzept mit der zentralen funktion.
Für ein derart einfach umzusetzendes Projekt reicht wie man sieht ein einfaches Ablaufdiagramm schon vollkommen aus (was man eigentlich je nach Erfahrung wohl auch nicht unbedingt braucht)
Jedenfalls hat das jetzt länger gedauert das so aufzuschreiben als es mir eingefallen ist.

Bei Pong könnte man wohl ähnlich vorgehen aber bei der Pong-Kollisionsabfrage hätte man etwas mehr im Code zu schreiben (weil man bei Snake nur auf einen Rasterpunkt vergleichen muss und nicht auf zwei Pads, die beide beweglich sind - je nach Ballgeschwindigkeit könnte man auch Probleme damit kriegen dass man keine Kollision detektiert obwohl der Ball direkt "durch" das Pad fliegt und man damit auf echte Vektoren ausweichen muss für die Bewegungsrichtung des der Kugel).
Wenn man es dann mal geschafft hat könnte man sich nach eigentlicher Fertigstellung noch lange damit aufhalten, das ganze zu verfeinern (ohne dabei das Spielprinzip zu verändern). Z.B. Trägheit der Kugel bei Pong berücksichtigen, unterschiedliche Reflektionswikel abhängig vom Auftreffwinkel auf dem Pad verwenden. Variation der Reflektionsgeschwindigkeit (je nach Bewegungsgeschwindigkeit des Pads). Einbauen einer KI (die nicht blos die y-Position des Balls kopiert). Evtl. Hindernisse einbauen, aber das würde das Spielprinzip ändern.
Für Snake würde mir nur eine Sache einfallen: Schlange wird immer schneller (je nach Länge/Speed) - durch schrittweise Verringerung der Wartezeit am Frameende. Für alles weitere müsste man das Spielprinzip erweitern (was ich persönlich tun würde weils mir sonst zu langweilig wäre, wie z.b. Hindernisse, Bonusitems, schlangenfressende Monster auf der Spielkarte/dem Raster, etc.).

Als ich den Breakout Klon gemacht hab, wollte ich eigentlich auch nur ein Pong Spiel machen aber das war dann doch zu wenig als ich fast fertig war und habs dann etwas umgebaut - da konnt ichs also selbst nicht dabei belassen und hab mir was länger dauerndes "aufgehalst" als ursprünglich geplant. Dass einem etwas nicht reicht kommt dabei immer wieder vor, was aber nichts schlechtes heißen muss, schließlich lernt man dabei ganz gut - wobei man schon versuchen sollte etwas fertigzustellen.

Was die Planung angeht: das Beispiel oben funktioniert ganz gut für seeeeehr kleine Projekte und man steigert sich ja mit der Zeit.
Später wirst du sehr viel mehr Gedanken um die planung machen müssen, aber es nützt nichts von anfang an etwas riesiges zu planen (zumal das ohne oder mit nur wenig Erfahrung kaum machbar ist, weil man garnicht weiß was einen alles erwartet). Das soll nicht heißen, man soll ganz darauf verzichten, sondern viel mehr klein Anfangen, schnell lernen und dann steigern!
Wenn man klein anfängt dann wirken sich schlecht durchdachte Design-Entscheidungen nicht so stark aus - man kann jederzeit alles umbauen und/oder neu anfangen, ohne gleich Wochen oder Monate an Arbeit wegzuwerfen.

***Man verzeihe mir die missachtete Groß-/Klein- und evtl. Rechtschreibung. Es wird spät :D

[Zudomon]

Code: Alles auswählen

- Man nehme eine STL::list für die schlange. ein element= eine pisition auf dem raster und ein richtungsvektor (nur für 4 himmelsrichtungen).
-in der schleife:
-- abfragen der tasten und neu setzen der kopf->richtung
-- ist kopf->position+kopf->richtung == futter->position dann nichts tun außer ein neues listelement (neuer Kopf) nehmen mit Richtung des alten Kopfs und listelement->position=futter->position und auf die Schlange Pushen
----- keine Bewegung
----- futter->position = random.
-- wenn nicht dann letztes element der schlange nehmen, element->richtung = kopf->richtung setzen und element->position = kopf->position + kopf->richtung
-- zum schluß prüfen:
--- ist kopf->x oder kopf->y negativ oder größer als rasterbreite bzw -höhe
----- game over
-- alles malen
-- warten bis xx millisekunden vergangen
- schleifenende

Deine Schlange stirbt nicht, wenn sie sich selber trifft?

[CrystalCoder]

Stimmt das hab ich vergessen (wär mir wohl beim ersten Testlauf erst aufgefallen).
Ich weiß jetzt nicht wie du das bei dir gelöst hast, aber wird wohl ähnlich sein wie ich mir das denke: Als Lösung würde ich das in einer kurzen Schleife testen indem man einfach Kopf->Position+Kopf->Richtung mit SnakeElement_i->Position auf Identität prüft, wobei es nur Sinn macht (SnakeListe->Länge - 5) Elemente zu testen (weil die oberen 4 inklusive des Kopfes keine Kollision ermöglichen).
Was ich noch vergessen hab ist, dass man nicht um 180° "abbiegen" kann, das mussman entsprechend berücksichtigen wenn man die Eingaben auswertet.

Es geht aber mehr um die Vorgehensweise wie man mit solchen Projekten umgehen könnte, wenn man in der Planungsphase ist.
Ich denke so ist das schon ganz anschaulich.

Später werden die Schritte wohl auf nem höheren Level sein, sodass man nicht sofort jedes kleinste Detail aufschreibt, sondern ganze Prozesse notiert und dann in separaten Diagrammen darstellt.
Derartige Flussdiagramme können sehr nützlich sein, wenn man anfangs etwas auf eine bestimmte Art umsetzen will und später einfällt, dass es nicht optimal passt oder dass man was wichtiges vergessen hat.
Programmiert man einfach drauf los kann es später garnicht mehr so lustig sein, wenn mal was nicht passt.

[Zudomon]

Ich weiß jetzt nicht wie du das bei dir gelöst hast, aber wird wohl ähnlich sein wie ich mir das denke

Warum? Hab doch oben beschrieben, wie ich vorgegangen bin. ;)

[CrystalCoder]

Warum? Hab doch oben beschrieben, wie ich vorgegangen bin.

Ich muss zugeben, dass ich zu faul zum lesen war :D