IDEEN GESUCHT ZUR PROGRAMMIERUNG EINES SPIELES MIT C++
-
nachtfeuer schrieb:
Na, andere Alternativen sind auch nicht viel besser
Man muss ja auch nicht die größte Innovation programmieren und gleich ein komplett neues Genre erfinden.
Aber nehmen wir mal an, man nimmt sich jetzt folgendes vor:
Ein Top-Down-Spiel mit Wänden und Gegnern, die sich, je nach Gegnertyp, unterschiedlich verhalten.
Ziel: Alle Gegner abzuschießen ohne selbst getroffen zu werden, bevor die Zeit ausläuft.So. Ist jetzt auch nicht gerade das Allerneueste. Aber der Unterschied ist eben: Es ist nicht einfach ein Klon von einem ganz bestimmten Spiel.
Pong wird am Ende einfach nur Pong sein, und Snake einfach nur Snake. Wieso sollte ich dieser konkreten Implementierung mehr als 10 Sekunden meiner Zeit widmen?
Während die obere Idee auf ganz verschiedene Weise implementiert werden kann. Genauso wie Berzerk und Robotron 2048 zwei verschiedene Spiele sind, wird auch dieses Spiel anders sein.
Somit ist das für einen Spieler wenigstens ein bisschen interessant: Man hat eben ein neues kleines Spiel. Vielleicht ist es gut.Pong und Snake, das ist jetzt so, als wenn mir ein Programmieranfänger zeigt, wie er die Zahlen von 1 bis 10 in einer Schleife ausgegeben hat: Eine nette Übung für ihn selbst, aber nichts, wo das Programm jetzt außerhalb der Übung für irgendwas zu gebrauchen wäre.
-
Wenn es in C++ sein soll und 2D würde ich noch SFML für Fenster/Graphics/Audio/Networking empfehlen. Die API ist sauber und eher C++ig (nicht wie SDL).
Als Medien kann ich persönlich das Buch SFML Game Development empfehlen. Ich habe es selbst auch mir gegönnt und daraus gelernt wie man 2D Spiele programmiert (States, StateStack, SceneGraph, Entity, Networking, ...).
Und generell gilt, wenn man sich mit C++ nicht wohl fühlt (zumindest OOP/Klassen, lambdas, STL, smart pointer, ?), dann kann das schon mal frustrierend werden.
-
Gamaer schrieb:
Pong und Snake, das ist jetzt so, als wenn mir ein Programmieranfänger zeigt, wie er die Zahlen von 1 bis 10 in einer Schleife ausgegeben hat: Eine nette Übung für ihn selbst, aber nichts, wo das Programm jetzt außerhalb der Übung für irgendwas zu gebrauchen wäre.
Aber genau darum geht es doch! Es soll schließlich gelernt werden, wie man so ein Spiel programmiertechnisch aufzieht. Der kreative Teil der Spieleentwicklung lenkt davon nur unnötig ab. Bei Tetris und Pong ist jedem ohne Erklärung perfekt klar, was am Ende rauskommen muss, man kann sich voll darauf konzentrieren, wie man diese bekannten Ideen in Software umsetzt.
Dass das Ergebnis am Ende für die Tonne ist, weil sich ein erster Versuch eines Anfängers nicht mit den ausgereiften Profiergebnissen messen kann, ist jedem klar. Das würde aber auch für dein 'innovatives' Spiel gelten, bloß dass man unnötig mehr Arbeit reinstecken muss. Fast mit Sicherheit ist das innovative Spiel noch viel mehr ein Fall für die Mülltonne, denn Ideen für gute Spiele sind sehr viel schwieriger zu finden als man denkt; besonders für jene, die sich eher für die Programmierung interessieren als für den Designteil. Bei Pong und Tetris weiß man auf jeden Fall, dass die Idee gut ist, und man kann dann daher das Ergebnis auch mit Freude selber spielen oder Bekannten vorführen, ohne sich für das schlechte Gameplay schämen zu müssen.
Wenn jemand das erste Mal backt, sollte er schließlich am besten auch nach (einem einfachen!) Rezept vorgehen. Es wäre der Wahnsinn, zu empfehlen, gleich etwas eigenes zu kreieren. Das würde nur in irgendwelchem Mehlmatsch enden, wohingegen nach Rezept ein akzeptabler Standardkuchen heraus käme.
Die handwerkliche Umsetzung und die Schaffung neuer Ideen sind nun einmal, auf egal welchem Arbeitsfeld, völlig verschiedene Handlungsbereiche. Viele Menschen machen sogar stets nur eines von beidem, weil die Bereiche so wenig Schnittmenge haben.
-
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.
