spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich denke das lässt sich auch mit allen gängigen 3D Engines vereinbaren. Es sollten eigentlich alle auch 2D unterstützen, also können wir getrost 2D Grafiken als Grundlage nehmen.

Wäre natürlich cool, wenn jemand aus der Community Grafiken zeichnen mag. Ansonsten würde ich spätestens morgen Abend ein paar assets zur Verfügung stellen.

Gut, das stimmt. Zumindest für Engines a la Unity/UE sollte das ja kein Problem darstellen. Dann bräuchten wir noch 3D Modelle.

Umfangstechnisch:
Wäre es besser, einen Prototypen des Spiels(also wie vorher beschrieben) zu machen, oder sollen wir lieber direkt das Komplettpaket inkl. GUI, Optionsmenü etc. anbieten?

Zweiteres fände ich besser, würde dann aber auch die Komplexität nach oben treiben und ggf. übers Ziel hinausschießen.

Zitat von »BlueCobold«

Was brauchst du schon groß für ein Breakout? Quader. Mit denselben Bildern als Texturen drauf, die die 2D-Variante des Spiels ebenfalls verwenden würde...

Naja das hängt halt vom Umfang mit ab. Wenn wir jetzt noch Partikeleffekte, variable Powerups und sondergleichen dazuhauen ist das ja schon ein bisschen mehr. Als Grundspiel ist das natürlich schon einfacher.

Da gibt es kein Problem, ich möchte lediglich sichergehen, dass das alles klar ist bzw. offen sein für Ideen. Jetzt können wirs noch machen, mittendrin die Meinung zu ändern ist schwerer.

Aber fassen wir das Ganze mal zusammen. Ich würde folgendes vorschlagen:

Spiel:
Breakout Klon
Grafikset:
Vorgegeben.
Wir werden aller Wahrscheinlichkeit nach das Kenney Donation Pack für die Assets verwenden.

Umfang:
Auf jeden Fall ein komplett spielbares Level.
Spielprinzip dürfte jedem klar sein:
Der Spieler kontrolliert ein Paddle, das er nach links und rechts bewegen kann. Innerhalb eines geschlossenen Bereiches(Bildschirmrand, "Box"), ist es nun das Ziel, mit einem Ball auf Blöcke zu treffen, die dann kaputtgehen. Sind alle Blöcke zerstört, ist das Spiel vorbei.

Der Ball bewegt sich hier wie bei Pong von selbst und muss vom Spieler lediglich abgefangen werden bzw. durch Kollision in andere Richtungen gelenkt werden. Trifft der Ball den unteren Bildschirmrand, verliert der Spieler ein Leben und der Ball spawnt erneut.

Meiner Meinung nach sollte das beinhalten:
- Level: Ein hardgecodetes Level
- Bewegliches Paddle, das mit Hilfe gängiger Methoden(Pfeiltasten, A und D) bewegt werden kann. Die Bewegungsgeschwindigkeit sollte dabei sinnvoll gewählt werden.
- Ein Ball, der in der Mitte erscheint, eine zufällige Richtung/Geschwindigkeit(?) annimmt und dann mit Spielern, Wände und Blöcken kollidiert.
- > Bei der Kollision mit der Wand wird Richtung gespiegelt, ebenso bei Blöcken. Geschwindigkeit sollte hier gleich bleiben
- > Bei der Kollision mit dem Spieler wird die Geschwindigkeit verändert und genauso wie die Richtung abhängig von Spielergeschwindigkeit(und Richtung) sowie Aufprallpunkt verändert. Im Prinzip wie man es aus Pong und Breakout eben kennt.
- Power Ups die Ball und Paddle beeinflussen. Geschwindigkeit, Größe, Menge.
- GUI mit Punkte- und Lebensanzeige

Hier würde ich vorschlagen, bei einzelnen Parametern erstmal Freiheit zu lassen. Allerdings sollten wir schon zusehen, dass am Ende jeder auch tatsächlich ein Breakout hat!

Was meiner Ansicht nach auch noch nett wäre, aber eventuell was für später ist. D.h. diese Sachen sind optional:

- Vollständiges Menü: Starten, Optionen, Schließen
- > Tastenbelegung
- Juicing
- Erweiterung des Spiels


Dokumentation:

Die Dokumentation der Entwicklung ist wichtig, denn am Ende soll das Ganze ja auch durchgerabeitet bzw. nachvollzogen werden können.
Ich würde da am liebsten keine Vorgaben machen aber einige Stichpunkte sind da doch zu beachten:

1) Das Ganze richtet sich an Anfänger bzw. Umsteiger, die noch nicht fit genug sind sich das selbst zu erarbeiten. Es gilt also: Lieber etwas mehr erklären, als zu sparen.
2) Best Practices einhalten! Jedenfalls so gut man eben kann. Tricksen ist Jedermanns Alltag aber wenn man es vermeiden kann, sollte man das tun.
3) Sauberen, kommentierten Code. Dann kann man später in der Dokumentation sich auf das wesentliche konzentrieren.
4) Ich würde davon ausgehen, dass der Leser eine gewisse Vorerfahrung hat im Programmieren. Also man sollte nicht erklären müssen, was Arrays sind. Bei der Verwendung von smart_pointern sollte man aber schon kurz darauf eingehen, was das ist und wieso man es benutzt. (Hier reicht dann eine kurze Erklärung mit ggf. Verweisen auf weiterführende Seiten)
5) Es ist ok, das Spiel an sich fertig zu machen und dann am Ende die Dokumentation. Wenn man sie allerdings von Anfang an macht, dann fällt es einem leichter.

Das wäre zumindest jetzt erstmal der Stand der Dinge aus meiner Sicht. Wenn das für jeden so angenehm ist, könnte im Prinzip schon begonnen werden. Ansonsten natürlich einfach Vorschläge posten.

Ich werd die nächsten Tage mehr eingespannt sein in der Arbeit, aber dennoch versuchen, bis zum Wochenende sowohl Wiki-Seite angelegt, grundlegende Inhalte und Grafiken eingepflegt zu haben.