spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

1. Erfahrung. Ist quasi unbezahlbar, ich merke deutlich wie im laufe der Zeit mein Code übersichtlicher und besser strukturiert wurde. Man kann sicherlich auch hunderte Seiten Theorie sich aneignen, aber ob man das von vorne bis hinten durchhält und dann wirklich einen sehr guten Stil hat? Außerdem gibt es große Unterschiede zwischen "denken es verstanden zu haben" und "es verstanden zu haben". Ob du es verstanden hast, merkst du meist erst wenn du es tust.

2. Zeitplan? Naja, nicht wirklich schwer. Milestones sind ziemlich nett, du überlegst dir, was du alles brauchst bis zum fertigen Spiel und überlegst dir, in welchen Schritten und welcher Reihenfolge man das angehen könne, so das du zwischendurch immer schöne Zwischenversionen hast.
Für die benötigte zeit braucht man wohl wieder viel Erfahrung.

Also? Klein anfangen. Anders geht es wohl nicht, da man ohne Erfahrung irgendwie nicht weit kommt. Bei gescheiterten Großprojekten lernt man zwar auch, aber motivieren tut es wohl nicht.

Ich bin einer von der Sorte "was habe ich? was will ich? und schon gehts los!". Natürlich vergaloppiere ich mich da auch schon mal, aber dann schmeiße ich nicht einfach alles hin, sondern zerlege alles in kleine funktionseinheiten und fange an zu ordnen und zu sortieren. Nennt man glaube ich im neudeutsch refactoring . Also nur weil was uunübersichtlich geworden ist, würde ich es noch lange nicht aufgeben. Mein Zimmer ist auch meisten eher Chaos, aber dennoch kann ich mir nicht immer ein neues suchen :badgrin:

Ich kann Jonathan_Klein eigentlich nur zustimmen.

Wenn man vorhat, von Anfang an alles perfekt und sauber zu gestalten, ist das zwar ein edler Vorsatz, jedoch weit von der Realität entfernt - vor allem, wenn man noch keine Erfahrung in solchen Projekten hat. Jedoch sollte das nicht heissen, dass man sich wie Nox gleich drauf los stürzen sollte, ohne etwas zu planen, sonst - wie er selber andeutet - ist das Chaos sicher.

Gerade in der objektorientierten Programmierung ist es wichtig, dass man sich zuvor einen Überblick über das Design macht. Welche Klassen benötigt man? Wie stehen diese in Beziehung zu einander? Wie stehts mit Vererbung und Polymorphie? Wer übernimmt Grafikaufgaben? Solche Fragen sollte man sich am besten stellen, bevor man mit Programmieren beginnt. Man sollte auch Wert darauf legen, dass das Programm sauber und strukturiert geschrieben wird, da dies die Wartung und allfällige Erweiterung stark erleichtert.

Klar kann man nie alles im Voraus wissen, aber es sollte schon eine gewisse Vorstellung davon vorhanden sein, wie das Projekt ungefähr aufgebaut sein soll. Es wird so oder so passieren, dass etwas nicht nach Plan läuft; nicht zuletzt, weil man vereinfachend geplant hat und sich etwas in der Praxis nicht 1:1 umsetzen lässt. Auch dann gilt es, während des Programmierens in Ruhe zu überlegen, wie man solche Dinge am besten mit dem Rest des Projekts in Einklang bringen könnte. In solchen Situationen tendiert man schnell dazu, eine Frickellösung zu finden (im Glauben, diese sei nur von temporärer Dauer). Es geht nicht lange, bis dann der weitere Code auf diesem Gefrickel aufbaut und man sich bereits weit entfernt von seinem ursprünglichen Ziel wiederfindet, ohne etwas davon zu merken. Da lohnt sich etwas investierte Zeit für eine saubere Lösung auf jeden Fall.

Aber irgendwann sollte man auch noch zur Implementierung kommen. Wie gesagt, wird man kaum ein Projekt erstellen können, in dem alle eigenen Vorstellungen eintreffen. Man lernt immer dazu und kann sich beim nächsten Projekt bereits besser vorbereiten. Erfahrung ist eben nicht zu unterschätzen.

Also generell kann ich den Tipp geben:

Verliere nie die Ziele aus dem Auge. Schreib dir auf was du erreichen willst, welche Features du brauchst etc. Dann kannst du dir auf dem Papier eine grobe Struktur ausdenken wie du zu diesen Zielen kommen willst.

Um die Ziele zu erreichen ist es finde ich hilfreich genau aufzuschreiben welche Schritte nötig sind um das Ziel zu erreichen. Sicher muss da immer mal was geändert werden, aber es verhindert, dass man sich verhaspelt und auf einmal an Dingen bastelt die eigentlich für das Ziel nicht relevant sind. Man behält also den Weg zum Ziel im Blick.

Und ansonsten.. Es ist immer schön wenn man schnell Erfolge sehen kann. Also klein Anfangen und dann erweitern.

Zeitpläne würde ich im Hobbybereich nicht benutzen.. es soll doch Spass machen und nicht in Arbeit ausarten.

Und der wichtigste Tipp meiner Meinung nach: Papier und Stift. Man kann auf dem Papier seine Gedanken wunderbar ordnen und in Struktur bringen.

Böö nja in der letzten Vorlesung meinten sie man sollte das ganze Projekt erstmal als Graph darlegen und dann am Ende wenne glück hast automatisch generieren lassen

oookay nein das machse besser nicht

Zitat von »"Deviloper"«

Böö nja in der letzten Vorlesung meinten sie man sollte das ganze Projekt erstmal als Graph darlegen und dann am Ende wenne glück hast automatisch generieren lassen

Hehe, jedem sein fetisch *g*

Mein Lieblingsprinzip zZ. Contract First Design (allerdings noch nie in der Spieleentwicklung probiert)...wenn man das aber man verinnerlicht hat, dann ist die Chance schon sehr groß, dass man sich nicht komplett verfährt.