Wir bauen ein Game ...

Übersicht BlitzBasic FAQ und Tutorials

Neue Antwort erstellen

BladeRunner

Moderator

Betreff: Wir bauen ein Game ...

BeitragDi, Mai 11, 2004 19:55
Antworten mit Zitat
Benutzer-Profile anzeigen
Wir bauen ein Game.

Also denn, lasst uns über die grundlegenden Mechanismen eines (aus aktuellem Anlass) Egoshooters und was viel wichtiger ist - über die Schritte bis zum programmieren- reden.
Zu Beginn erst mal eine Anmerkung: wer erwartet hier den funktionsfähigen Code eines Shooters zu finden ist fehl am Platz. Es geht hier darum Konzepte zu vermitteln und nicht mundgerechte Häppchen in selbigen zu schieben.

Aus meiner nun ca. einjährigen Erfahrung mit dem Blitzforum haben sich einige Defizite offenbahrt die ich mit diesem Beitrag versuchen werde auszuräumen.

Eine weit verbreitete Ansicht (grade unter den Jüngeren) ist es, dass man ohne Models, Meshes, Sounds und ähnliche Nettigkeiten kein Game zustandebringt. Das ist vollkommen FALSCH. Wer z.B. die Muße hat ältere Testberichte über HL2 rauszukramen, wird feststellen, dass es Bilder gibt auf denen ganze Levels aus einfachen Blöcken bestehen, welche mit einer grell-orangenen Einheitstextur überzogen wurden. Dies bringt uns zu ...

LEKTION 1: Der Code macht das Game, aber ... !

Du hast dir also BB3D (die Demo) installiert oder bist gar stolzer Besitzer von BB3D und brennst nun auf dein erstes Game! Einen Egoshooter! Renés Buch liegt aufgeschlagen neben Dir und alles was du noch brauchst sind ein paar schicke Wummenmeshes und Gegner und .... *skrieeeg* FALSCH !!!!
Der Code macht das Spiel, aber Du brauchst:

- Eine Idee/Story. Um was geht es bei deinem Game. Wer ist die Hauptfigur? Warum ist sie da wo sie ist? Was ist ihre Aufgabe?
Viele Neulinge machen den Fehler einfach mal draufloszuprogrammieren, um nach Stunden (Tagen?) festzustellen, dass das Game was sie zusammengeschustert haben, recht langweilig ist (und auch sie nicht mehr bei der Stange hält). Oder dass sie nit wissen wie es denn nun weiter gehen soll. Oder welches Feature sinnvoll wäre.
Daher ist es nicht verkehrt sich Gedanken über die Story (den Plot) des Games zu machen.
Sich einfach mal hinzusetzen und sich aufzuschreiben was einem so in den Sinn kommt. Auch wenn man nicht gut zeichnen kann: ein paar Skizzen vertiefen die Vorstellung dessen was man erwartet.
Idealerweise denkt man sich die Story (wie in einem Film) aus und beschreibt quasi das Game wie eine fertige Geschichte. Das ergibt den Weg den der Player nun beschreiten muß.
Weiterführend ergeben sich daraus:

- erste Gedanken zur Spielmechanik. Welche Waffen hat der Spieler? Wie kann er sie einsetzen (Welche Moves hat er)? Welche Möglichkeiten zur Interaktion bestehen sonst noch (mal ehrlich: nur ballern ist stupide... )? Gibt es besondere Gegenstände? Welche Arten von Gegnern gibt es? Wie verhalten sie sich? Jetzt kommen wir (ansatzweise) in Codenähe:

- erste Abstraktionen und Überlegungen zum Codeaufbau:
Also, laut deinem bis dato erstellten Design-Dokument (und nichts anderes haben wir im Ansatz gemacht...) soll E. Shooter unter anderem an ein SGX-3005-Sniperrifle kommen... nun können wir aber schlecht ein Exemplar in den Monitor stopfen -zum einen weil es das Ding ja nicht gibt, zum andern weil das Game ja trotzdem nicht wüsste was es damit anfangen soll. Höchste Zeit sich über Eigenschaften Gedanken zu machen:
Was macht die Wumme aus ? Ich hab mal kurz nachgedacht und denke folgende Punkte sind wichtig:
- Kaliber (Welche Munition?)
- Ladekapazität (wieviel davon?)
- Feuergeschwindigkeit (Zeit zwischen zwei mal abfeuern)
- Ladegeschwindigkeit (Zeit zum Magazinwechsel)
- Reichweite (wie weit ballert das Ding?)
- Genauigkeit (wieviel Abweichung vom Fadenkreuz möglich?)
- Besondere Eigenschaften (Zielfernrohr, Dauerfeuer etc...)

Das schreit doch nach einem Type, oder ?
Natürlich ist die Liste noch zu erweitern und den anderen Waffen anzupassen, aber insgesamt ist das sehr vielversprechend.
Ebenso geht man auch mit allen anderen "Objekten" im Spiel vor. So kann zum Beispiel im Type "Enemy" wichtig sein:
-Art
-Position (x,y,z)
-Bewaffnung
-Panzerung und Healthpoints
-Zustand (zB. Attacke oder Flucht. abhängig von der KI)
-Animationsphase

Aber auch allgemeine Überlegungen sind hier sinnvoll: Hunde werden im Rudel jagen, während sich der Sniper allein verschanzt. Um mehr "Feeling" zu erzeugen, sollten auch solche "Kleinigkeiten" in die Überlegungen mit eingehen.
Man sollte in diesem frühen Stadium nicht zu Codespezifisch werden. Wir sind immer noch auf einem Level, der mehr auf Beschreibungen und Ideen basiert denn auf Code u./o. Machbarkeit. Allerdings nähern wir uns ersten Versuchen an.

Allein die Mannigfaltigkeit der Ideen welche in dieser Phase aufkommen können kann absolut erschlagend wirken. Alles sauber notieren hilft weiter, später wird sich nach und nach herauskristallisieren was umsetzbar ist und wo sich offenkundig Fehler eingeschlichen haben, oder auch was bei näherer Betrachtung einfach nur unnötig ist.

LEKTION 2: Der Code macht wirklich das Game!

Gut, du hast nun ne Story, bist sie komplett durchgegangen und hast versucht, den Objekten im Game Eigenschaften zuzuweisen. Deine Ideen (mit einigen Zeichnungen) und grundsätzliche Gedanken zur Levelstruktur liegen fein säuberlich geordnet auf deinem Schreibtisch.
Nun wird es Zeit daraus was zu bauen was den Compiler füttern kann.
Ich persönlich halte es für eine Gute idee zu Beginn all die Überlegungen (von denen man glaubt dass sie von Nutzen sein werden) in ausführlich auskommentierte Variablen/Type-Deklarationen umzuwandeln. Ein gewisser Style bei der Namensgebung erleichtert das spätere Weiterprogrammieren. So könnte alles was später mit Gegnern zu Tun hat im Namen mit ENEMY_ beginnen. (sinnvolles Stichwort ist hier wohl : Ungarische Notation).
Nächster sinnvoller Schritt wäre das Erstellen einer simplen Grundengine, um alles was da noch kommen mag, testen zu können (Kamera, einfache Kollisionsabfrage, Möglichkeit zum freien Bewegen).
Dies sollte in BB3D kein großes Problem darstellen.
Nun geht es darum all die ermittelten Eigenschaften der Objekte mit "Leben" zu füllen.
Du hast in deinem Waffen-type den Eintrag Ladegeschwindigkeit? Was muss der Rechner tun wenn der Spieler die taste für´s Nachladen drückt? Setze das in Code um, immer Stück für Stück. Teste den Code immer (auch mit unmöglichen) Beispielwerten ob er erwartungsgemäß funktioniert.
Im Fall der Nachladezeit wäre beim Drücken der Nachladetaste ein der NachladeZeit entsprechender Timer zu starten, bis zu dessen Ablauf die Waffe nicht gefeuert werden kann. Zu Ende Des Timers wird Der Munitionswert angepasst. Es sollte jedoch kein Delay verwendet werden, da es das Game ausbremst. Vielmehr wäre es interessant, den Ladevorgang zB durch wechseln der Waffe abbrechen zu können. Wichtig dabei ist (man kann es nie oft genug sagen): kommentieren was Das Zeug hält und Testen,Testen,Testen.
Ich empfehle jeden "funktionalen Block" auch so zu erstellen: sprich als in sich weitestgehend gekapselte Funktion. Wer Performance-Ängste hat, kann zur Vollendung dass Ganze dann gern in einen Pott werfen, aber aus einem Pott Funktionen zu machen dürfte schwer fallen.



To be continued...
Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI

Stolzer Gewinner des BAC#48, #52 & #92

BladeRunner

Moderator

BeitragDi, Mai 18, 2004 1:56
Antworten mit Zitat
Benutzer-Profile anzeigen
... und nun: Teil Zwo der Saga.

BladeRunner hat Folgendes geschrieben:
Zuallererst einmal dies: Mir wurde gesagt dass hier wohl eine Diskussion über dieses Tutorial stattgefunden hat (deren Reste jedoch augenscheinlich beseitigt wurden). Ich hab das Ganze versäumt, kenne den genauen Inhalt also nicht. Nur eines:
Mir geht es hier nicht darum allgemeingültige Wahrheiten aufzustellen. Was ich hier bieten möchte sind Denkanstöße und kleine Wegweiser. Schlußendlich wird hier beschrieben wie ich die ganze Angelegenheit sehe. Wenn also irgendjemand das Ganze besser kann (oder auch nur glaubt es zu können): immer her damit ! Mach deinen eigenen Thread auf und erleuchte uns mit deinen Weisheiten. Ich bin immer bereit Neues zu lernen.

Ich persönlich mache jedoch jetzt mit meiner eigenen Sichtweise weiter und werde mich auch an die Maxime hier im FAQ-Forum halten und keinerlei Diskussion betreiben (wer unbedingt was ablassen möchte: PM oder neuer Thread im OT. Ich will ja niemand hier mundtot machen...)

Aber zurück zum Tutorial:


Ich sprach gegen Ende von Teil Eins davon die Objekte mit "Leben" zu füllen. Dies ist quasi der fundamentale Kern des Programmierens und leider auch der am meißten mißverstandene, denn viele setzen "belebt" mit schöner Optik gleich.
Ironischerweise muß man zum beleben eines Games etwas tun was dem (realen) Leben sehr abträglich wäre: Das Objekt in seine Kernbestandteile zerlegen und auch diese (sehr nüchtern) als pure Ansammlung von Zahlen und Anweisungen sehen.
Womit wir auch wieder bei meinem Lieblingssatz (den ich sehr mag) wären: Der Code macht das Spiel ...
Was nutzt einem der tollste (volltexturierte und wutschnaubende) Söldnermesh mit all seinen Animationsphasen wenn es aussieht als würde er übers Schlachtfeld schweben (oder durch Wände läuft; auf den Spieler nicht reagiert; nicht mal eine Tür öffnen kann)? Was bringt die Tolle AK74SU als Waffenmodell wenn man nicht in der Lage ist sie zu positionieren. Oder sie sich nicht "echt" anfühlt (kein Rückstoß, abartig schnelles Serienfeuer etc.).
Und hier setzt das Programmieren an. Das Zerlegen des Objektes (Söldner, AK, Camera, Healthkit etc. etc.) in seine Eigenschaften und diese dann weiter in logische Schritte welche soweit abstahiert sind, dass man sie in Befehle umsetzen kann, in handlich-kleine Stückerl Code.

Das wird jetzt einigen nicht gefallen, aber JA : Coden ist Arbeit! Und es ist vorallem Kopfarbeit denn das Wenigste wird im Endeffekt über die Tastatur gejagt. Coden ist kalte unbarmherzige Mathematik - und ekelhaft intolerante Logik. Es ist sicher oftmals ratsam sich das Teilproblem welches man gerade behandelt auf ein Stück Papier zu schreiben (zu malen ?) und zu Versuchen es in logische Schritte aufzuteilen / in Formeln zu packen, Gerne auch anhand von Beispielen (Papier - das mag vielleicht altmodisch anmuten, aber: es funktioniert [seit über 3000 Jahren]).
BladeRunner hat Folgendes geschrieben:
Sorry für diesen Absatz liebe Mods, ich konnte ihn mir nicht verkneifen. Wenn er zu offensiv sein sollte fühlt euch frei ihn kommentarlos zu löschen:
Bestes Beispiel für planloses Coden sind Fragen wie:
" Wie sagt man dem BB dass er 3 Raumschiffe immer so von links nach rechts fliegen lassen soll ohne dass die zusammenstoßen, am besten mit Codebeispiel und Schiffs-GfX.Danke." (Ich denke einer bis mehrere hier sollten sich angesprochen fühlen).
Diese Fragen setzen am falschen Punkt an und das rührt daher dass der Fragende keinerlei Gedanken an potentielle Lösungen verwandt hat. Es gibt keinen MoveGraphicsAvoidingCollisions(ship1,ship2,ship3)-Befehl.Was es aber gibt ist die Möglichkeit das Problem auf das Wesentliche zu reduzieren: Bewegung eines Objektes und Prüfen auf Kollisionsgefahr. Und diese könnte man weiter zerlegen. Das geht zwar nicht pronto aber man würde daraus für die weiteren Codes im Leben was lernen.

Ich habe im ersten Teil das Beispiel mit der Nachladezeit gebraucht; noch sehr vage und unvollständig aber genau darauf läuft es hinaus: Man sollte nicht mehr das Sniperrifle sehen sondern (am Ende eines längeren Entwicklungsvorganges) die Variable "weapon\reloadtime" und wie sie beeinflusst werden kann (welche Parameter vonnöten sind) um das gewünschte Ergebnis zu erhalten.
Wenn man beim Finden der Lösung klug vorangeht (und sich bemüht Lösungen zu Finden welche allen potentiellen Exemplaren eines Objektes gerecht werden) hat man bald ein System von Funktionen welche mit einem Mindestmaß an Anstrengung zusammengefügt werden können.

Ich habe bei meinen Überlegungen das Sniperrifle als Beispiel genommen. Das soll (Gott bewahre !) nicht heissen dass dies der Punkt ist an dem man den Code beginnen sollte. Es war ein willkürliches Beispiel dafür wie solche Überlegungen laufen können (sollten ?).
Ich denke hier muß jeder seinen eigenen Weg finden, gerade (oder noch dazu) weil auch jedes Game andere Schwerpunkte setzt und auch verlangt.

[Anmerkung: Noch bevor eine Zeile Code steht sollte eh das Ganze auf Papier quasi fertig sein, inclusive kompletter Story, "Komplettlösung", Beschreibung zu allen wichtigen Objekten und deren Eigenschaften, besonderen Features und und und...)]

War diesmal eher "philosophisch" nichtsdestotrotz jedoch (so denke ich) sehr wichtig....
Aber: genug gelabert für dieses Mal....

[blink] INSERT COIN TO CONTINUE [/blink]
Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI

Stolzer Gewinner des BAC#48, #52 & #92

Neue Antwort erstellen


Übersicht BlitzBasic FAQ und Tutorials

Gehe zu:

Powered by phpBB © 2001 - 2006, phpBB Group