Wie programmiert man ein Spiel?
-
Einleitung
Am Anfang steht die Idee. Man weiss in etwa wie das Spiel mal aussehen soll. Schon in dieser Phase macht man sich Gedanken dazu wie man manche Funktionen implementiert und was machbar ist. Aus diesem Grund ist es schwer als Anfänger abzuschätzen wie die Entwicklung verlaufen wird. Deshalb sollte man schon ein paar kleinere Spiel programmiert haben um in etwa zu wissen was man selber kann und was man sich an Wissen noch aneignen muss.Die Planung
Die Planung eines Spiel macht den meisten Anfänger große Probleme. Obwohl die Planung zum wichtigsten Teil gehört wird es nie möglich sein alles vorherzusehen.
Am besten macht man sich Notizen zum Ablauf des Spiels und entwickelt alles schrittweise. Bei auftretenden Fehlern ist es leichter aufkommende Probleme schneller zu lokalisieren.Die Implementierung
Nach den vorgeferitgten Skizzen beginnt man mit der schrittweisen Implementierung. Man sollte sich immer ein Ziel vornehmen was man evt. an einem Tag erreichen kann. So kann es nicht passieren das man ein nicht laufendes Programm abspeichert und nach einer Woche nicht mehr weiss welchen Teil man bearbeitet hat.Dateien auslagern
Man sollte sein Spiel so planen das es felxibel ist. Entwickelt eine Game-Engine. Diese sollte in der Lage sein, externe Dateien zu laden um damit die Level zu erstellen. Es ist auch ratsam Initialisierungswerte in externen Dateien zu speichern. So ist es auch für den Betatester möglich verschiedene Einstellungen zu testen.Datensicherheit
Versionsnummer sind in der Entwicklung sehr wichtig. Vor allem wenn man in einem Team arbeitet.
Eine Versionnummer 0.1,0.2... ist nicht sehr ratsam. Besser ist z.B. Version 0.01.04. Die erste Zahl ist 0 wenn sich das Projekt in der Entwicklung befindet. Die zweite wird geändert bei erreichen eines Entwicklungsziels. Die dritte beim beheben von Bugs. Man könnte das System noch erweitern für Grafikengine ect...
Und nicht vergessen immer wieder die aktuelle Version auf CD sichern!Design&Grafik
Man sollte nie den Fehler machen erst die Objekte zu erstellen und später das Spiel zu programmieren. Die Game Engine sollte zum größten Teil laufen, kleiner Fehler könne drin sein. Zu diesem Zweck arbeitet man auch mit Dummyobjekten.
Die Entwicklung der 3D Modele ist eine nicht zu unterschätzende Arbeit. Diese Arbeit sollte in Ruhe gemacht werden. Das kann man nur wenn man keine anderen Aufgaben hat die noch auf eine Lösung warten.Leveleditor
Die Entwicklung einers Leveleditors ist für größere Projekte unverzichtbar. Entwickelt man ein Space Combat Simulator kann man nicht für jeden Level die Objekte von Hand setzten. Idealerweise programmiert man sich einen Leveleditor in dem man die Objekte platzieren kann. Dieser Leveleditor erstellt danach eine Datei, die von der Game Engine gelesen werden kann. Deshalb ist es wichtig das die Game Engine in der Lage ist z.B. einen Soldaten zu erstellen. Sobald dieser Soldat erstellt ist muss es selbständig nach Feinden suchen und bekämpfen können. Oder man gestalltet die Engine so das man dem Soldaten verschiedene Aufgabe geben kann.Ein paar beispielhafte Aufgabe für eine Soldaten:
- An erstellter Position warten und Feinde bekämpfen
- Feind suchen und angreifen
- Position x,y,z erreichen
- Spieler begleiten
- ect...Betatest
Die Betaversion sollte man ausgiebig testen. Ein Spieler wird immer das machen was er nicht machen soll. Er wird versuchen das Ende des Terrains zu erreichen. Er wird sich ins Wasser stürzen, auf eigene Leute schießen und und und. Achtet auch darauf das die Beta Version auf unterschiedlichen Rechnern läuft mit unterschiedlicher Hardware. Es bringt nicht wenn alle Betatester eine ATI haben....
was vergessen?....
-
Von wo hast Du das denn abgeschrieben?
Ich würde mal sagen, dass das FAQ-verdächtig ist!
-
(C) Copyright bei mir. Die habe ja meine IP
Ich entwickle gerade ein Spiel und habe versucht eine Leitfaden für die Programmierer im Team zu schreibe. Aber ich bin über jede Erweiterung dankbar. Wenn es fertig ist kann man es ja in die FAQ stellen.
-
Was hast du denn bisher für Spiele programmiert ?
-
tipp :
Die Implementierung
Nach den vorgeferitgten Skizzen beginnt man ...Tipp:
Die vorgefertigten Skizzen sind eindeutig Teil der Vorbereitung. diese erst in der Implementierung zu erwähnen ist vielleicht nicht der richtige Anstz. Zur planung musst Du ein wenige mehr sagen, also mögliche Vorgehensweisen erläutern, etc.Am Besten ist es, wenn bei der Planungsphase ein Papier rauskommt, das den Spielverlauf in sämtlichen Einzelheiten beschreibt und auch schon grobe Algorithmen vorschlägt, an denen man sich orientieren kann.
Hierzu gibts Mindmaps, Brainstormings, Storyboards und noch einiges mehr, was man machen kann..(Soll ich im Treffen 2004 mal nen Projektplanungsseminar machen?
)
-
Die Planung
...Am besten macht man sich Notizen zum Ablauf des Spiels....Sollte eigentlich darauf hinweisen.
Das mit den Brainstormings sollte man erwähnen. Da hast du recht.
-
Ich weiß, dass des drauf hinweisen sollte, aber Du musst lernen, Dinge so zu erklären, dass sich der Leser wohl fühlt, was bedeutet, dass er nicht denken muss. Nix voraus setzen und lieber einiges doppelt schreiben.
Auch Tutorials schreiben muss man üben *gg+ - wobei ich jetzt nicht sagen möchte, dass ich darin perfekt bin
-
Ich weiss. Ich bin immer froh wenn ich was dazu lernen kann. Deshalb danke für die Hinweise.
-
Sorry, aber das ist aus dem Buch von TomasRiker geklaut.
-
Nö, stimmt nicht :p
Ich hab diesen Part ein bisschen mehr auseinander gezogen.
-
LUCAS schrieb:
Einleitung
...
Die Planung
... Obwohl die Planung zum wichtigsten Teil gehört wird es nie möglich sein alles vorherzusehen.
...sorry, aber LOL! Jeder (gute) Software-Entwickler Plant alles vorher. Es sollte im regelfall keine zeile code geschrieben werden bevor nicht die komplette planung steht, oder die Schnittstellen definitiv festgelegt wurden. Was soll man denn nicht vorhersehen können? Gerade bei der Spieleentwicklung kann eigentlich fast nix dazwischen kommen, da die Firmen meist nicht für einen Kunden arbeiten ( der von heute auf morgen alles anders haben möchte), sonder relativ unabhängig entwickeln.
Das das in der realität ein wenig anders aussieht ist mir klar. Dann liegt das aber nicht an irgendwelchen unvorhergesehenen Problemen, sondern ehr daran das die SW-Entwickler nicht nachgedacht haben.
Genau das thema hat mein SWE Prof. letzte woche besprochen.
-
Gerade bei der Spieleentwicklung kann eigentlich fast nix dazwischen kommen
sorry, aber LOL!
-
tonque schrieb:
Gerade bei der Spieleentwicklung kann eigentlich fast nix dazwischen kommen
sorry, aber LOL!
dann nen mir etwas. Mit begründung!! Stell dir mal vor so würde man Häuser bauen. "Oh, wir hätten vielleicht doch mit dem keller anfangen sollen". Oder wie??
-
Stell dir mal vor, der Quellcode wird gestohlen.
-
xroads42 schrieb:
dann nen mir etwas.
Zum Beispiel war doch da ein Problem mit Half-Life 2 und den NVidia-Grafikkarten. Die unterstützten irgendein "Centroid-Sampling" nicht, was man vorher aber wohl nicht wusste, und das hat zu Problemen geführt.
Es könnte außerdem passieren, dass ein Algorithmus, den man plante zu verwenden, sich als zu langsam herausstellt und man einen neuen suchen muss etc..
Was meinst Du wohl, warum die meisten Spiele unzählige Patches benötigen, bis sie einmal richtig spielbar sind? Das wäre doch wohl kaum der Fall, wenn nicht unerwartete Probleme aufträten.
-
TomasRiker schrieb:
xroads42 schrieb:
dann nen mir etwas.
Zum Beispiel war doch da ein Problem mit Half-Life 2 und den NVidia-Grafikkarten. Die unterstützten irgendein "Centroid-Sampling" nicht, was man vorher aber wohl nicht wusste, und das hat zu Problemen geführt.
Es könnte außerdem passieren, dass ein Algorithmus, den man plante zu verwenden, sich als zu langsam herausstellt und man einen neuen suchen muss etc..
Was meinst Du wohl, warum die meisten Spiele unzählige Patches benötigen, bis sie einmal richtig spielbar sind? Das wäre doch wohl kaum der Fall, wenn nicht unerwartete Probleme aufträten.Hm, ok, das mit der HW sehe ich ein.
Das mit den Algorithmus aber nicht. Es gibt Laufzeitabschätzungen ( stichwort O-notation ) für Algorithmen. Und wenn man einen neuen entwickelt sollte man so eine berechnung vorher machen, bevor man diesen in ein System einbaut.Leider steckt das Software Engeniering noch in den "Kinderschuhen". Aber für einen guten Softwareentwickler ( und damit meine ich >10 Jahre berufserfahrung ) sollte es möglich sein eine Software so zu planen, dass solche "unvorhersehbaren" ereignisse nicht eintreten, bzw. wenn man sich auf dritte verlässt ( wie z.B. das mit der GraKa), dass solche dinge handbar sind.
Die ganzen Patches liegen daran das die meisten Spiele firmen nicht die regeln des SWE-prozesses einhalten. Was meinst du was passieren würde wenn die SW eines medizinisches gerätes so programmiert werden würde. "Ach, da ist jemand gestorben. Hm, bringen wir halt einen patch raus". ok, ok, da geht auch Qualität vor Quantiät.
Das ist das Problem von Software heutzutage. Laut meinen Prof sind nur ~20% der SW im zeitramen, ~40% liegen drüber, und der rest wird gar nicht fertig gestellt... Damit sowas besser wird, wird ja auch massig geforscht.
Es ist schwierig alles zu planen. Aber man sollte nicht so herrangehen, dass man sagt, das kann ich erst sehen wenn ich das implementiere. Geht bei der Implementierung was schief, kann man ( je nach Modell - z.B. Wasserfallmodell) alles neu machen.
-
Wie programmierst du? Ich meine ein etwas größeres Projekt kann man schon nicht mehr bis ins letzt Detail planen.
Natürlich geht es nicht ohne Planung. Doch ein Programmieranfänger wird schon hier seine Probleme haben. Oder kennst du Projekte die gleich von Anfang an 100% liefen?
Ich habe mal gelesen das es billiger ist eine Software zu implementieren und danach auftretende Fehler zu beseitigen. Als alles von Anfang an zu 100% bis in letzte Detail zu planen.
-
xroads42 schrieb:
Was meinst du was passieren würde wenn die SW eines medizinisches gerätes so programmiert werden würde. "Ach, da ist jemand gestorben. Hm, bringen wir halt einen patch raus". ok, ok, da geht auch Qualität vor Quantiät.
Die müssen sich ja auch nicht mit verschiedener Hardware und scheiß Treibern rumplagen...
Nach Deiner Argumentation dürften die Chips in so "lebensbedrohenden" Dingen wie Fahrzeugen ja auch einwandfrei funktionieren.
Tun sie aber nicht! Da fällt einem Golf mal mitten im Überholmanöver der Motor aus, weil die CPU irgendwie wat anders sah als der Fahrer. Meinem Vater sind bei voller Fahrt im Winter mal ohne ersichtlichen Grund alle Fenster und Schiebedach aufgegangen, in einem 7er BMW wohlgemerkt!
Les mal Auto Motor & Sport...
Und Konsolenspiele sind - bei milchmädchenrechnung gleicher Komplexität - ja nun (meistens) absolut bugfrei.
Die Komplexität des "Baukasten-System PC" mit GraKa vom Hersteller X, Prozzi von Y, und CD-ROM von Z sollte nun mal nicht unterschätzt werden...