IDEEN GESUCHT ZUR PROGRAMMIERUNG EINES SPIELES MIT C++
-
Gamaer schrieb:
Wie wär's denn mal mit was Eigenem?
Wieso wird immer Pong, Snake und Tetris vorgeschlagen? Weil es einfach zu programmieren ist?
weil du dich auf ein programmierproblem fokusieren willst, was schon herausforderung genug ist. eigene regeln und systeme zu entwickeln kannst du machen, wenn dir die implementierung keine probleme bereitet, denn wenn du zuviele vorhaben auf einmal hast, bekommst du am ende keiene sache fertig.
spiel 2.0 kann ja was eigenes sein.
-
Na, dann reicht aber echt auch nur, ein Viereck über den Bildschirm zu bewegen.
Durch Mauern soll er nicht laufen können (Kollisionsabfrage mit Level) und bei Berührung mit einem anderen Viereck kommt ein Sound (Kollisionsabfrage mit anderen Sprites).
Läuft man in eine Wand, während man eine bestimmte Taste gedrückt hält, verschwindet diese Wand (zerstörbares Spielfeld).
Wenn's wirklich nur um Programmiertechniken gehen soll, dann ist das ausreichend.
Dann muss man nicht Zeit verschwenden mit Tetris oder Snake, wo es neben den speziellen Spieleprgrammiersachen ja auch ganz allgemeine Regeln gibt (Wenn Linie voll, dann Linie löschen), die jetzt eher mit Programmierung allgemein zu tun haben und die in einem späteren Spiel sowieso wieder ganz anders sind.
-
da hast du recht, wenn die motivation egal ist, kann er ein paar triviale schleifen oder EVA systeme programmieren. Wenn jedoch etwas mehr motivierendes, ohne viel mehr nono-programming aufwand gewuenscht ist, ist ein clone von existierenden spielen eine valide alternative.
-
Gamaer schrieb:
Na, dann reicht aber echt auch nur, ein Viereck über den Bildschirm zu bewegen.
Durch Mauern soll er nicht laufen können (Kollisionsabfrage mit Level) und bei Berührung mit einem anderen Viereck kommt ein Sound (Kollisionsabfrage mit anderen Sprites).
Läuft man in eine Wand, während man eine bestimmte Taste gedrückt hält, verschwindet diese Wand (zerstörbares Spielfeld).
Es würde reichen, ja. Aber es ist der gleiche Aufwand, ein bekannt gutes Spielprinzip zu implementieren, und man hat dann hinterher ein brauchbares Spiel. Ein eigenes Spielprinzip von Grund auf zu Designen ist hingegen viel aufwändiger und die Chancen stehen gut, dass das selbst erfunden Spielprinzip keine Spaß macht.
Wenn's wirklich nur um Programmiertechniken gehen soll, dann ist das ausreichend.
Dann muss man nicht Zeit verschwenden mit Tetris oder Snake, wo es neben den speziellen Spieleprgrammiersachen ja auch ganz allgemeine Regeln gibt (Wenn Linie voll, dann Linie löschen), die jetzt eher mit Programmierung allgemein zu tun haben und die in einem späteren Spiel sowieso wieder ganz anders sind.Wie man Spielregeln implementiert ist für dich kein Teil der Spieleprogrammierung?
-
Mangelnde Ideen für Spiele waren noch nie ein Problem für mich. Eher mangelnde Zeit und Disziplin zur Realisierung dieser Ideen.
Fällt dir wirklich nichts ein? Es gibt so viele Möglichkeiten. Manche Leute lassen sich auch von älteren Retro Spielen inspirieren. Der Vorteil dabei wäre auch dass die Spiele damals simpler waren.
Und hin und wieder findet man sogar ein Spielprinzip dass es heute gar nicht mehr gibt
-
Wenn wir jetzt sowieso schon bei 2D/2,5D sind, werfe ich einfach mal Tower Defense in den raum.
Das grundlegende Prinzip sollte jedem bekannt sein und dennoch laesst es mehr als genug Spielraum fuer eigene Regeln und Design.
-
Ja, klar, ein Anfänger wie hASCII_Cpp programmiert mal eben nen Tower-Defense in C++. Ihr habt alle einen an der Klatsche. Damit wird er doch nie fertig.
Hier, DAMIT fängt man mal an:
https://tinodidriksen.com/2003/05/but-can-you-make-pong/Wenn man das fertig hat (und fertig heisst FERTIG, nicht halbfertig), erst dann sollte man sich an kompliziertere Sachen dranwagen.
-
Pong: Collision detection, simple graphics/sprites, punkte zaehlen, win condition.
TD (ohne pathfinding): collision detection, mehrere maps mit definierten pfaden => sprite, tower class (mit damage), (lebens)-punkte zaehlen, win condition.
Ich behaupte ein simples TD in 2D ist nicht anspruchsvoller als eine Pong in 2D.
Vorteil von TD: du kannst es stetig erweitern (pathfinding/maps, tower types, enemy types).
-
Cardiac schrieb:
Ich behaupte ein simples TD in 2D ist nicht anspruchsvoller als eine Pong in 2D.
Dann hast du keinen Plan.
-
Richtig....die konversation musste ja schliesslich so enden.
-
Ähm ja. Wenn das nicht nur ein kleines Übungsprojekt ist, muss er sich später sowieso für eine größere Game Engine entscheiden.
Und wenn es C++ sein soll dann kommt die Unreal Engine 4 und die Cryengine in Frage. Wobei die Programmierung in UE4 um Welten besser dokumentiert ist.
Ein Tower Defense lässt sich damit relativ einfach entwickeln.https://docs.unrealengine.com/latest/INT/Programming/Introduction/
-
Kann ein Mod bitte mal den Titel des Threads korrigieren? Die ausschließliche Großschreibung entfernen. Sieht ja schlimm aus.
-
Cardiac schrieb:
Ich behaupte ein simples TD in 2D ist nicht anspruchsvoller als eine Pong in 2D.
Vorteil von TD: du kannst es stetig erweitern (pathfinding/maps, tower types, enemy types).99% der Arbeit bei einem TD ist balancing. (Und ein spassloses spiel zu coden ist sicher nicht das ziel wenn du ein spiel coden willst.) Wenn du dazu anfaenger bist und garnicht weisst wie data driven gearbeitet wird, wie du automatische regressiontests bzw replays machen kannst, dann wirst du sehr viel zeit mit testen und nicht programmieren verbringen.
Fuer anfaenger, zum lernen, eignen sich spiele die
1. nur durch simple, wohldefinierte spielmechanik funktionieren (ja, das kann man auch fuer komplexe spielsysteme machen, aber wir sprechen von anfaengern)
2. wenig spieleebenen haben (z.b. kein "shop" "trade" usw.)
3. tick basierend, sodass rendering/simulation nicht seperiert werden muss (oder das spiel auf anderen systemen als auf dem entwickelt wurde nicht total achterbahn faehrt)ich wuerde TDs problematisch in allen 3 punkten ansehen. aber auch sowas wie BreakOut kann wegen punkt 3. probleme machen. Textadventure koennten wegen 2. problematisch sein. Tetris, pacman, oder puzzler sind mMn trivialer fertig zu bekommen.
