spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

klein gar nicht, da die meist sowieso in einem Tag fertig sind, bei größeren insbesondere bei Teamarbeiten erstelle ich sowas wie ne Roadmap, jeder bringt Ideen ein und da wird ein Zeitplan wird erstellt.
Dann kommen noch 1-2 Wochen, kann auch länger sein wo man sich über die verwendete Technik im klaren wird und dort Probleme schon beseitigt (z.B. setzt man keinen Programmierer ein, der sowas noch nie gemacht hat).

Je nach Größe kommen dann auch noch "Subleader" die dann die einzelnen Bereiche leiten, aber unter mir stehen - is ja klar.

Wenn sich jemand nicht an Termine hält, oder nur Mist liefert, fliegt er.

Ich plane immer interaktiv und das geht selbst bei größeren Projekten im Team recht gut. Zwar gibt es dann ab und zu mal umbauphasen, wenn mal was überhaupt nicht passt, aber die sind meist nach 1-2 Tagen erledigt.

Ich überlege erstmal wie ich das große Projekt in viele kleine Programmteile zerlegen kann und überlege dann wie man die einzelnen Teile am besten programmieren kann. Dafür schaue ich mir einfach mal an was es für Designpatterns gibt oder überlege was ich früher benutzt haben und was nicht funktioniert hat. Dann baut sich eine erste Idee vom Design auf, diese lasse ich dann einfach mal in meinem Kopf rumschwirren und programmierer irgendwas anderes wo das Design schon klar ist und immer wenn ich Zeit habe(Straßenbahn, Schule, ...) denke ich weiter über meine Designidee nach und überlege wie ichs umsetzten will und welches Stärken und Schwächen das System hat. Irgendwann bin ich dann so weit und programmiere das Teil. Danach testet ich es und wenn es mir gefällt wird es noch mal richtig dokumentiert, dabei fallen wir immer kleine Fehler im Design auf , welche ich dann noch schnell verbesser und dann gehts weiter zum nächsten Teil.

Also bei mir ist das meist so.
1. Überleg ich mir was genau ich überhaupt machen will und was das Prog/Spiel am ende können soll
2. Ich gehe denn groben Aufbau durch und sehe ob es irgendwo Probleme gibt.
3. Probleme beseitigen
4. Je nahc größe: Feingefühl: Ich übelege nun genau z.B was für Waffen es im Spiel geben soll und lasse diese dann modellieren
5. Überschneidet sich mit 4. Während der Modellierung progge ich das Spiel/Prog

erstmal alles grob überlegen. je nach projekt größe kleineres oder größeres requirements engineering (lastenheft, pflichtenheft, grobe zeitplanung). dann hinsetzen uns das ganze so gut es geht modelieren (fmc blockdiagramme, petrinetze, klasendiagramme, sequenzdiagramme...) und dann gehts erst ans programmieren ;-)
das ganze projekt in kleinere unabhängige einheiten aufzuteilen und diese einzeln fertig zu stellen und zu testen hilft auch sehr viel.

1. Grobes durchgehen im Kopf
2. Einzelne Klassen und schwierige Stellen im Kopf durchdenken und schon fast implementieren (geht gut abends vorm einschlafen... oder bei irgendwelchen Wartepausen [zB Schlangestehen ;-)])
3. Programm schreiben

Wobei man sagen muss, dass ich allein als Programmierer arbeite, und deswegen nichts auf Papier bringen muss... Im Team würden Punkt 1 und 2 halt auf dem Papier gemacht, anstatt im Kopf...