Projektplanung

Übersicht

Sonstiges

Smalltalk

	Trust Betreff: Projektplanung	Mo, Feb 28, 2011 18:29 Antworten mit Zitat
Hallo Leute, ich würde gerne mal wissen wie ihr so vorgeht von der Idee zur Planung bishin zur Umsetzung eurer Projekte. Denn ich habe bsw. immerwieder schwierigkeiten mit der Planung bzw. der konkreten Strukturierung und Zerlegung des Projekts in kleinere Teilaufgaben. Damit meine ich jetzt nicht so einfache Dinge wie Grafik, Sound und der gleichen, sondern viel mehr die Strukturierung und Planung eures Programmaufbaus. So in etwa wie "aha dafür brauche ich eine Funktion die mir dies und das erledigt und diese wird dann in diese .bb.Datei ausgelagert usw. usf. . Wie plant man sowas am besten komplett im vorraus. Sodas man zum schluss der Planung eine strickte Liste hat, die man schön abarbeiten kann. Die meisten Projekte scheitern bei mir eben genau an diesem Problem. Nach ein paar Wochen Arbeit fängt es an unübersichtlich zu werden, nicht unbedingt der Code an sich, denn ich habe meines erachtens nach einen relativ sauberen Programmierstil, nein vielmehr das Gesamtkonzept wird unübersichtlich. Und dann fange ich an mich in den Aufgaben zu verlaufen, programmiere ein stück da und mal ein stück dort weiter. Was nach kurzer Zeit dann zum Tot des Projektes führt, da es so einfach zu anstrengend und zu frustrierend wird, unteranderem auch weil es dann kaum bis hin zu keinen fortschritten und erfolgserlebnissen mehr kommt. Lange rede kurzer Sinn - wie plant ihr eure Projekte? Habt ihr ein paar Tips diesbezüglich?

Trust

Betreff: Projektplanung

Mo, Feb 28, 2011 18:29
Antworten mit Zitat

Hallo Leute,

ich würde gerne mal wissen wie ihr so vorgeht von der Idee zur Planung bishin zur Umsetzung eurer Projekte.
Denn ich habe bsw. immerwieder schwierigkeiten mit der Planung bzw. der konkreten Strukturierung und Zerlegung des Projekts in kleinere Teilaufgaben.

Damit meine ich jetzt nicht so einfache Dinge wie Grafik, Sound und der gleichen, sondern viel mehr
die Strukturierung und Planung eures Programmaufbaus.

So in etwa wie "aha dafür brauche ich eine Funktion die mir dies und das erledigt und diese wird dann in diese .bb.Datei ausgelagert usw. usf. .

Wie plant man sowas am besten komplett im vorraus.
Sodas man zum schluss der Planung eine strickte Liste hat, die man schön abarbeiten kann.

Die meisten Projekte scheitern bei mir eben genau an diesem Problem.
Nach ein paar Wochen Arbeit fängt es an unübersichtlich zu werden, nicht unbedingt der Code an sich, denn ich habe meines erachtens nach einen relativ sauberen Programmierstil, nein vielmehr das Gesamtkonzept wird unübersichtlich.
Und dann fange ich an mich in den Aufgaben zu verlaufen, programmiere ein stück da und mal ein stück dort weiter. Was nach kurzer Zeit dann zum Tot des Projektes führt, da es so einfach zu anstrengend und zu frustrierend wird, unteranderem auch weil es dann kaum bis hin zu keinen fortschritten und erfolgserlebnissen mehr kommt.

Lange rede kurzer Sinn - wie plant ihr eure Projekte? Habt ihr ein paar Tips diesbezüglich?

	skey-z	Mo, Feb 28, 2011 20:11 Antworten mit Zitat
Erst einmal Grob gesagt Stichwort "Design Document" Wobei ich mich damit auch schwer tue, da ich lieber praktisch arbeite, als lange an der Theorie zu sitzen.
Awards: Coffee's Monatswettbewerb Feb. 08: 1. Platz BAC#57: 2. Platz Twitter

skey-z

Mo, Feb 28, 2011 20:11
Antworten mit Zitat

Erst einmal Grob gesagt Stichwort "Design Document"

Wobei ich mich damit auch schwer tue, da ich lieber praktisch arbeite, als lange an der Theorie zu sitzen.

Awards:
Coffee's Monatswettbewerb Feb. 08: 1. Platz
BAC#57: 2. Platz
Twitter

	Trust	Mo, Feb 28, 2011 21:22 Antworten mit Zitat
Ja mir geht es genauso. Aber wie geht man das am besten an und wie gestaltet man dieses "Dokument"? Macht ihr eine Art Brainstorming zu Anfang und baut dieses weiter aus. Oder macht ihr erstmal grobe Skizzen vom Programmaufbau (kapitelartig) und geht dann auf den jeweiligen Seiten weiter ins Detail? Wie macht ihr das wenn ihr ein größeres Projekt vor Augen habt?

Trust

Mo, Feb 28, 2011 21:22
Antworten mit Zitat

Ja mir geht es genauso.

Aber wie geht man das am besten an und wie gestaltet man dieses "Dokument"?
Macht ihr eine Art Brainstorming zu Anfang und baut dieses weiter aus.
Oder macht ihr erstmal grobe Skizzen vom Programmaufbau (kapitelartig) und geht dann auf den jeweiligen Seiten weiter ins Detail?
Wie macht ihr das wenn ihr ein größeres Projekt vor Augen habt?

	Lunatix	Mo, Feb 28, 2011 22:56 Antworten mit Zitat
Derzeit arbeite ich an einem größeren Projekt, basierend C++, OpenGL, NVidia PhysX und FModEx. Im wesentlichen halte(n) ich(wir) es so: Das Hauptprojekt wird in viele, kleine Teile aufgesplittet, diese Einzelteile werden dann nach und nach geschrieben und gleichzeitig getestet. Möchte man z.b. eine Kiste darstellen, braucht man dazu diverse Teile - User Interface, OpenGL -> Driver, Context, Shader, Materials, Skins, Texturen, Geometrie Objekte, Kameras, Matritzen, Vektoren usw. Somit baut im Endeffekt alles aufeinander auf und wird Stück für Stück geschrieben. Hierfür diehnt z.b. eine Todo List, ein "Rahmen Dokument" welches beschreibt, aus welchen Teilen sich das Endprodukt zusammensetzen soll. Auch anzuraten ist, wenn man eine neue Teilaufgabe erarbeitet, sich vorher ersteinmal kurz und grob eine Struktur zurechtzulegen - ob nun im Kopf oder Schriftlich kommt auf die Person drauf an. Teilweise schreibe ich mir auf was ich machen will - lese es aber hinterher meist nicht mehr, da ich als Lead Programmer sowieso den großteil des Projektes im Kopf habe Auch wichtig ist, eine Struktur festzulegen, an die sich jeder Programmierer im Team halten muss - und seien es auch solch banale dinge wie Einrückungen, oder ob alle Integer variablen nun mit einem "i" beginnen müssen oder nicht.
[size=9]Pro\|gram\|mier\|er: Ein Organismus, der Koffein in Software umwandelt. Geben Sie eine beliebige 11-stellige Primzahl ein, um fortzusetzen...

Lunatix

Mo, Feb 28, 2011 22:56
Antworten mit Zitat

Derzeit arbeite ich an einem größeren Projekt, basierend C++, OpenGL, NVidia PhysX und FModEx. Im wesentlichen halte(n) ich(wir) es so:

Das Hauptprojekt wird in viele, kleine Teile aufgesplittet, diese Einzelteile werden dann nach und nach geschrieben und gleichzeitig getestet.

Möchte man z.b. eine Kiste darstellen, braucht man dazu diverse Teile - User Interface, OpenGL -> Driver, Context, Shader, Materials, Skins, Texturen, Geometrie Objekte, Kameras, Matritzen, Vektoren usw.

Somit baut im Endeffekt alles aufeinander auf und wird Stück für Stück geschrieben. Hierfür diehnt z.b. eine Todo List, ein "Rahmen Dokument" welches beschreibt, aus welchen Teilen sich das Endprodukt zusammensetzen soll.

Auch anzuraten ist, wenn man eine neue Teilaufgabe erarbeitet, sich vorher ersteinmal kurz und grob eine Struktur zurechtzulegen - ob nun im Kopf oder Schriftlich kommt auf die Person drauf an. Teilweise schreibe ich mir auf was ich machen will - lese es aber hinterher meist nicht mehr, da ich als Lead Programmer sowieso den großteil des Projektes im Kopf habe Wink

Auch wichtig ist, eine Struktur festzulegen, an die sich jeder Programmierer im Team halten muss - und seien es auch solch banale dinge wie Einrückungen, oder ob alle Integer variablen nun mit einem "i" beginnen müssen oder nicht.

[size=9]Pro|gram|mier|er: Ein Organismus, der Koffein in Software umwandelt.
Geben Sie eine beliebige 11-stellige Primzahl ein, um fortzusetzen...

	Firstdeathmaker	Di, März 01, 2011 9:46 Antworten mit Zitat
Kein Wunder das du damit Schwierigkeiten hast, das ganze ist ein komplexes und stark diversifiziertes Thema namens [ur=http://de.wikipedia.org/wiki/Softwaretechnikl]Softwaretechnik[/url]. Es gibt verschiedene Ansätze da ran zu gehen. Ein Beispiel: Du schreibst am Anfang ein Designdokument. Darin listest du deine "Vision" auf, was die Software alles können soll. Dabei lässt du die Programmierung komplett aussen vor. In der richtigen Softwareentwicklung würden jetzt ein Lastenheft (Funktionale Anforderungen) und ein Pflichtenheft (Detaillierte technische Umsetzung) folgen. Ein Beispiel: Funktionale Anforderung: Der Spieler soll sich zu Anfang beim Spiel anmelden. Technische Umsetzung: Nach Start der Software sollen zum Anmelden 2 Eingabefelder und ein Button angezeigt werden. Das obere Eingabefeld soll den Spielernamen und das untere das Passwort aufnehmen. Das Passwortfeld soll keinen Klartext, sondern statdessen Punkte aufweisen. Beim Klick auf den "Loginbutton" soll das Passwort und der Login mit der Datenbank abgeprüft werden, und bei einem Treffer in das Menü xyz weitergeleitet werden. Bei einer falschen Eingabe soll auf der gleichen Seite ein Hinweis erscheinen, dass man es fehlerhaft war und man es noch einmal versuchen soll. Als nächsten Schritt könnte man seine Software nun grob entwerfen. Man überlegt sich z.B., was man für Akteure (Subjekte), Objekte und Funktionen (Prozesse) hat. Bei der Anmeldung wäre das z.B.: Subjekt: Spieler Objekte: Spielerdatenbank, GUI Funktionen: PrüfeLogindaten(login,passwort)::Spielerdatenbank (nicht vollständig) Aus diesem Modell leitet man dann z.B. mit UML ein detailliertes Klassendiagramm u.s.w. ab. Siehe dazu auch unter "UML" in der Wikipedia. Wie ich persönlich bei kleinen Hobbyprojekten vorgehe: 1. Ich schreibe kurz auf, was ich machen möchte. Je nach Motivation reicht das von einer Seite bis zu 30 Seiten. Z.b. für ein Spaceshooter, was für eine Handlung er haben soll, was für extra-Features er haben soll, eine beschreibung der Gegnertypen und Waffen etc. 2. Manchmal erstelle ich dann mit ArgoUML (kostenlose Software) ein Klassendiagramm. Das tue ich vor allem bei Projekten, bei denen eine saubere Struktur eine essentielle Rolle spielt, weil darauf nachher andere Sachen aufbauen sollen. Ein Beispiel dafür wäre eine GUI, oder ein Gameframework. Bei kleinen Spielen verzichte ich meistens darauf. 3. Ich fange einfach an zu Programmieren. Wenn ich vorher eine UML-Struktur gemacht habe, setze ich diese einfach um, und wenn ich merke das es so nicht geht, ändere ich die UML-Struktur. Wenn ich keine habe, habe ich trotzdem eine ungefähre Vorstellung im Kopf wie das ganze strukturiert werden soll. OOP Programmierung hilft einem da schon ganz schön. Allgemeines: Das Hauptproblem ist meistens, das man erstmal sehr viel schreiben muss bis man etwas lauffähiges sieht. Viele Sachen bestehen aus x Unterkomponenten, die alle erst einmal da sein müssen, damit man richtig los legen kann. Ich empfehle dir für die reine Spieleentwicklung am besten mit einem "Framework" zu arbeiten. Es gibt da einige im englischen Forum, die dir einiges an Strukturierungsarbeit abnehmen. Ich selbst habe mir vor einiger Zeit selbst mal ein Framework geschrieben, mit dem ich innerhalb kurzer Zeit das Basisgerüst eines Spiels (Screens, Bildschirmverwaltung, Auflösungsverwaltung und Ablauf) aufstellen kann. Dieses muss ich dann nur noch Bildschirm für Bildschirm mit Inhalten füllen. So kann man auch ohne detaillierte Konzeptentwürfen gut vorran kommen.
www.illusion-games.de Space War 3 \| Space Race \| Galaxy on Fire \| Razoon Gewinner des BCC #57 User posted image

Firstdeathmaker

Di, März 01, 2011 9:46
Antworten mit Zitat

Kein Wunder das du damit Schwierigkeiten hast, das ganze ist ein komplexes und stark diversifiziertes Thema namens [ur=http://de.wikipedia.org/wiki/Softwaretechnikl]Softwaretechnik[/url]. Es gibt verschiedene Ansätze da ran zu gehen.

Ein Beispiel:
Du schreibst am Anfang ein Designdokument. Darin listest du deine "Vision" auf, was die Software alles können soll. Dabei lässt du die Programmierung komplett aussen vor.

In der richtigen Softwareentwicklung würden jetzt ein Lastenheft (Funktionale Anforderungen) und ein Pflichtenheft (Detaillierte technische Umsetzung) folgen. Ein Beispiel:

Funktionale Anforderung: Der Spieler soll sich zu Anfang beim Spiel anmelden.
Technische Umsetzung: Nach Start der Software sollen zum Anmelden 2 Eingabefelder und ein Button angezeigt werden. Das obere Eingabefeld soll den Spielernamen und das untere das Passwort aufnehmen. Das Passwortfeld soll keinen Klartext, sondern statdessen Punkte aufweisen. Beim Klick auf den "Loginbutton" soll das Passwort und der Login mit der Datenbank abgeprüft werden, und bei einem Treffer in das Menü xyz weitergeleitet werden. Bei einer falschen Eingabe soll auf der gleichen Seite ein Hinweis erscheinen, dass man es fehlerhaft war und man es noch einmal versuchen soll.

Als nächsten Schritt könnte man seine Software nun grob entwerfen. Man überlegt sich z.B., was man für Akteure (Subjekte), Objekte und Funktionen (Prozesse) hat. Bei der Anmeldung wäre das z.B.:

Subjekt: Spieler
Objekte: Spielerdatenbank, GUI
Funktionen: PrüfeLogindaten(login,passwort)::Spielerdatenbank
(nicht vollständig)

Aus diesem Modell leitet man dann z.B. mit UML ein detailliertes Klassendiagramm u.s.w. ab. Siehe dazu auch unter "UML" in der Wikipedia.

Wie ich persönlich bei kleinen Hobbyprojekten vorgehe:
1. Ich schreibe kurz auf, was ich machen möchte. Je nach Motivation reicht das von einer Seite bis zu 30 Seiten.
Z.b. für ein Spaceshooter, was für eine Handlung er haben soll, was für extra-Features er haben soll, eine beschreibung der Gegnertypen und Waffen etc.

2. Manchmal erstelle ich dann mit ArgoUML (kostenlose Software) ein Klassendiagramm. Das tue ich vor allem bei Projekten, bei denen eine saubere Struktur eine essentielle Rolle spielt, weil darauf nachher andere Sachen aufbauen sollen. Ein Beispiel dafür wäre eine GUI, oder ein Gameframework. Bei kleinen Spielen verzichte ich meistens darauf.

3. Ich fange einfach an zu Programmieren. Wenn ich vorher eine UML-Struktur gemacht habe, setze ich diese einfach um, und wenn ich merke das es so nicht geht, ändere ich die UML-Struktur. Wenn ich keine habe, habe ich trotzdem eine ungefähre Vorstellung im Kopf wie das ganze strukturiert werden soll. OOP Programmierung hilft einem da schon ganz schön.

Allgemeines:
Das Hauptproblem ist meistens, das man erstmal sehr viel schreiben muss bis man etwas lauffähiges sieht. Viele Sachen bestehen aus x Unterkomponenten, die alle erst einmal da sein müssen, damit man richtig los legen kann.
Ich empfehle dir für die reine Spieleentwicklung am besten mit einem "Framework" zu arbeiten. Es gibt da einige im englischen Forum, die dir einiges an Strukturierungsarbeit abnehmen. Ich selbst habe mir vor einiger Zeit selbst mal ein Framework geschrieben, mit dem ich innerhalb kurzer Zeit das Basisgerüst eines Spiels (Screens, Bildschirmverwaltung, Auflösungsverwaltung und Ablauf) aufstellen kann. Dieses muss ich dann nur noch Bildschirm für Bildschirm mit Inhalten füllen. So kann man auch ohne detaillierte Konzeptentwürfen gut vorran kommen.

www.illusion-games.de
Space War 3 | Space Race | Galaxy on Fire | Razoon
Gewinner des BCC #57 User posted image

	Arrangemonk	Di, März 01, 2011 12:22 Antworten mit Zitat
es gibt 2 möglichkeiten, wie man vorgeht, 1. top down funktioniert wie eine mindmap, du schreibst dir auf, was du haben willst (spiel) machst darunter dinge, die du dafür brauchast (immer ganz grob) z.b. nen renderer(ausgabe), eingabe,savegames und das sind wieder deine dinge die du dann haben willst, dazu schreibst du wieder auf was du brauchst bis zu bei modulen, klassen und methoden angekommen bist abhängig von der komplexität kannst du dann eine schicht die dir als sinvoll erscheint (immer gleichweit vom hauptpunkt entfernt) also deine teilprojekt grenze denken, und für teilprojektgrenzen braucht man schnittstellen, wenn die definiert sind, darf nichtsmehr geändert werden, und der jenige, der eine schicht drüber arbeitet vertraut auf das interface und der darunter programmiert gegen das interface und am ende passt alles zusammen, wenn keiner schlampt 2. der bottom up ansatz ist das genaue gegenteil, da fängst du mit den basisklassen an, (meist macht man da ne common klasse dafür) wo die basystypen(Punkt, linie fläche, etc) drin sind, darauf baust du komplexere typen auf, und so weiter, bis du dein spiel hast (Achtung, der ansatz is besser für einzelpersonen, und bei projekten eher nur für die einzelprojekte bedingt geeignet)
ingeneur

Arrangemonk

Di, März 01, 2011 12:22
Antworten mit Zitat

es gibt 2 möglichkeiten, wie man vorgeht,
1. top down
funktioniert wie eine mindmap,
du schreibst dir auf, was du haben willst (spiel)
machst darunter dinge, die du dafür brauchast (immer ganz grob)
z.b. nen renderer(ausgabe), eingabe,savegames
und das sind wieder deine dinge die du dann haben willst, dazu schreibst du wieder auf was du brauchst
bis zu bei modulen, klassen und methoden angekommen bist

abhängig von der komplexität kannst du dann eine schicht die dir als sinvoll erscheint (immer gleichweit vom hauptpunkt entfernt) also deine teilprojekt grenze denken, und für teilprojektgrenzen braucht man schnittstellen, wenn die definiert sind, darf nichtsmehr geändert werden, und der jenige, der eine schicht drüber arbeitet vertraut auf das interface und der darunter programmiert gegen das interface und am ende passt alles zusammen, wenn keiner schlampt

2. der bottom up ansatz ist das genaue gegenteil, da fängst du mit den basisklassen an, (meist macht man da ne common klasse dafür)
wo die basystypen(Punkt, linie fläche, etc) drin sind, darauf baust du komplexere typen auf, und so weiter, bis du dein spiel hast (Achtung, der ansatz is besser für einzelpersonen, und bei projekten eher nur für die einzelprojekte bedingt geeignet)

ingeneur

	Midimaster	Di, März 01, 2011 13:28 Antworten mit Zitat
Das Hauptproblem, das ich oft bei Hobby-Programmierern sehe, die noch am Anfang stehen, dass sie sich viel zu komplexe Ziele setzen, agribisch bei Details beginnen und irgendwann wegen des ungeheurern Arbeitsaufwandes alles wieder hinschmeissen, bevor das Spiel je einmal gelaufen ist. Meine Grundsätze bei einem neuen Spiel sind: Zitat: Ich weiß noch nicht, was ich alles haben will... Ich weiß noch nicht, was mir noch alles einfallen wird... Ich weiß noch nicht wie die Figuren aussehen, was sie können sollen... Ich weiß noch nicht, ob ich alle techn. Probleme in den Griff bekomme... Ich weiß noch nicht, wieviel Zeit ich habe... Ich weiß noch nicht.... Daher ist meine Vorgehensweise bei Spielen eine Art "Evolutions-Theorie": Ich erstelle eine Version I des Spiels mit minimalen Anforderungen: - noch keine gezeichneten Figuren, sondern Platzhalter - Kern-Routinen gleich als Funktionen ausgliedern - es entstehen Testprogramme parallel nebenher um Teilaspekte zu checken (z.b. Sounds, Bewegungsabläufe, LAN, Perfomance) - erst mal nur ein Level, daher noch kein Feld-Editor, sonder ich schreibe das 1.Level mit einem Text-Editor - zunächst erhalten die Akteure nur wenige Eigenschaften. 1 Held der laufen kann, 1 Gegner der töten kann, 1 Hinternis, das einfach 10x auftaucht, etc... In so einer minmalen Umgebung tauchen dann oft schon die meisten Fragestellungen und Probleme auf und ich sehe, was an Arbeit auf mich zukommen wird. Oft läuft dann das Spiel bereits nach einem Tag. Nun kann ich einschätzen, ob sich die weitere Arbeit lohnt und jetzt wird täglich nur soviel verbessert, dass das Spiel am Ende des Tages auf jeden Fall wieder läuft. Nach einem Monat verabschiede ich so Version I. Fertig! Und dann beginnt die Ideensammlung für eine Version II, die dann schon mal 3 Monate dauern darf. "Evolution" weil ich etwa so programmiere wie Spieleklassiker wie "Mario" im Lauf der Jahrezehnte gewachsen sind.

Midimaster

Di, März 01, 2011 13:28
Antworten mit Zitat

Das Hauptproblem, das ich oft bei Hobby-Programmierern sehe, die noch am Anfang stehen, dass sie sich viel zu komplexe Ziele setzen, agribisch bei Details beginnen und irgendwann wegen des ungeheurern Arbeitsaufwandes alles wieder hinschmeissen, bevor das Spiel je einmal gelaufen ist.

Meine Grundsätze bei einem neuen Spiel sind:

Zitat:

Ich weiß noch nicht, was ich alles haben will...
Ich weiß noch nicht, was mir noch alles einfallen wird...
Ich weiß noch nicht wie die Figuren aussehen, was sie können sollen...
Ich weiß noch nicht, ob ich alle techn. Probleme in den Griff bekomme...
Ich weiß noch nicht, wieviel Zeit ich habe...
Ich weiß noch nicht....

Daher ist meine Vorgehensweise bei Spielen eine Art "Evolutions-Theorie":

Ich erstelle eine Version I des Spiels mit minimalen Anforderungen:

- noch keine gezeichneten Figuren, sondern Platzhalter

- Kern-Routinen gleich als Funktionen ausgliedern

- es entstehen Testprogramme parallel nebenher um Teilaspekte zu checken (z.b. Sounds, Bewegungsabläufe, LAN, Perfomance)

- erst mal nur ein Level, daher noch kein Feld-Editor, sonder ich schreibe das 1.Level mit einem Text-Editor

- zunächst erhalten die Akteure nur wenige Eigenschaften. 1 Held der laufen kann, 1 Gegner der töten kann, 1 Hinternis, das einfach 10x auftaucht, etc...

In so einer minmalen Umgebung tauchen dann oft schon die meisten Fragestellungen und Probleme auf und ich sehe, was an Arbeit auf mich zukommen wird.

Oft läuft dann das Spiel bereits nach einem Tag. Nun kann ich einschätzen, ob sich die weitere Arbeit lohnt und
jetzt wird täglich nur soviel verbessert, dass das Spiel am Ende des Tages auf jeden Fall wieder läuft.

Nach einem Monat verabschiede ich so Version I. Fertig! Und dann beginnt die Ideensammlung für eine Version II, die dann schon mal 3 Monate dauern darf.

"Evolution" weil ich etwa so programmiere wie Spieleklassiker wie "Mario" im Lauf der Jahrezehnte gewachsen sind.

	Trust	Di, März 01, 2011 21:46 Antworten mit Zitat
Also erstmal ein dickes dankeschön an euch für die präzisen Erläuterungen. @Firstdeathmaker, Arrangemonk und Lunatix Also eure Herangehensweisen klingen schon sehr professionell und auch gut durchdacht, allerdings glaube ich dass sie eher für größere Projekte gedacht sind und vorallem für ein ganzes Team aus Mitarbeitern - speziel Deine erläuterung Firstdeathmaker. Da sieht man erstmal was für ein großer Aufwand schon bei der Planung entsteht und auch wie wichtig sie bei größeren Projekten ist. @Midimaster Deine Erläuterung der Herangehensweise ist mir neu, allerdings glaube ich, dass sie grade für Hobby-Programmierer die kleine Projekte verwirklichen wollen garnicht mal so verkehrt ist. Da hast du schon recht wenn du sagst dass grade Anfänger sich bald gesagt grenzenlos überschätzen und den Arbeitsaufwand unterschätzen - ich war früher nicht anders! Ich weiß noch wie ich zu Anfang von meinem eigenen 3D-Action Rollenspiel geträumt habe, als ich es dann mit ach und krach und viel gemurkse geschafft hatte eine Welt zu erstellen wo man mit WASD-Steuerung ein Figur bewegen konnte schmiss ich das Projekt als ich merkte: "Wenn dies jetzt schon so viel arbeit ist, wie soll ich dann erst Quests und Kampf und Inventar und.. dies und jenes... und ach ich hab keine Lust mehr..., das schaffe ich nie..." Auf jedenfall werde ich deine Methode für kleinere Projekte mal ausprobieren, klingt sehr interessant! Danke an euch! Und an die anderen - nur zu... teilt mir bzw uns eure Erfahrungen bezüglich Projekte und Planung mit. Ich denke da kann jeder etwas an Tips mitnehmen, da dies ein komplexes und schwieriges Thema ist, nicht nur für Anfänger. gruß Trust

Trust

Di, März 01, 2011 21:46
Antworten mit Zitat

Also erstmal ein dickes dankeschön an euch für die präzisen Erläuterungen.

@Firstdeathmaker, Arrangemonk und Lunatix

Also eure Herangehensweisen klingen schon sehr professionell und auch gut durchdacht,
allerdings glaube ich dass sie eher für größere Projekte gedacht sind und vorallem für ein ganzes Team aus Mitarbeitern - speziel Deine erläuterung Firstdeathmaker.
Da sieht man erstmal was für ein großer Aufwand schon bei der Planung entsteht und auch wie wichtig sie bei größeren Projekten ist.

@Midimaster

Deine Erläuterung der Herangehensweise ist mir neu,

allerdings glaube ich, dass sie grade für Hobby-Programmierer die kleine Projekte verwirklichen wollen garnicht mal so verkehrt ist.
Da hast du schon recht wenn du sagst dass grade Anfänger sich bald gesagt grenzenlos überschätzen und den Arbeitsaufwand unterschätzen - ich war früher nicht anders!

Ich weiß noch wie ich zu Anfang von meinem eigenen 3D-Action Rollenspiel geträumt habe, als ich es dann mit ach und krach und viel gemurkse geschafft hatte eine Welt zu erstellen wo man mit WASD-Steuerung ein Figur bewegen konnte schmiss ich das Projekt als ich merkte: "Wenn dies jetzt schon so viel arbeit ist, wie soll ich dann erst Quests und Kampf und Inventar und.. dies und jenes... und ach ich hab keine Lust mehr..., das schaffe ich nie..."

Auf jedenfall werde ich deine Methode für kleinere Projekte mal ausprobieren, klingt sehr interessant!

Danke an euch!
Und an die anderen - nur zu... teilt mir bzw uns eure Erfahrungen bezüglich Projekte und Planung mit.
Ich denke da kann jeder etwas an Tips mitnehmen, da dies ein komplexes und schwieriges Thema ist, nicht nur für Anfänger.

gruß Trust

	FireballFlame	Mi, März 02, 2011 7:58 Antworten mit Zitat
Was Firstdeathmaker schreibt (Lastenheft->Pflichtenheft->...), ist für die Anwendungsentwicklung nützlich, macht aber bei der hobbymäßigen Spieleprogrammierung keinen Spaß^^ Ich mach es so wie Midimaster und baue mir so schnell wie möglich einen funktionsfähigen "Kern" für das Spiel, bevor ich mehr und mehr Features hinzufüge. Für einen 2D-Shooter z.B. wäre das erstmal ein Bild oder auch nur ein Rechteck, dass sich mit den Pfeiltasten bewegen lässt. Dann ein anderes Rechteck, dass beim Druck auf Leertaste losfliegt und im Fall einer Kollision ein drittes Rechteck verschwinden lässt. Sowas wie Lebensenergie, Gegner-KI und -formationen kommt erst später und Sound oder Menüs sowieso, aber ich hab dann schon mal ein funktionierendes Programm mit den grundlegenden Elementen (Spieler, Schuss, Gegner), das ich testen kann.
PC: Intel Core i7 @ 4x2.93GHz \| 6 GB RAM \| Nvidia GeForce GT 440 \| Desktop 2x1280x1024px \| Windows 7 Professional 64bit Laptop: Intel Core i7 @ 4x2.00GHz \| 8 GB RAM \| Nvidia GeForce GT 540M \| Desktop 1366x768px \| Windows 7 Home Premium 64bit

FireballFlame

Mi, März 02, 2011 7:58
Antworten mit Zitat

Was Firstdeathmaker schreibt (Lastenheft->Pflichtenheft->...), ist für die Anwendungsentwicklung nützlich, macht aber bei der hobbymäßigen Spieleprogrammierung keinen Spaß^^

Ich mach es so wie Midimaster und baue mir so schnell wie möglich einen funktionsfähigen "Kern" für das Spiel, bevor ich mehr und mehr Features hinzufüge.
Für einen 2D-Shooter z.B. wäre das erstmal ein Bild oder auch nur ein Rechteck, dass sich mit den Pfeiltasten bewegen lässt. Dann ein anderes Rechteck, dass beim Druck auf Leertaste losfliegt und im Fall einer Kollision ein drittes Rechteck verschwinden lässt. Sowas wie Lebensenergie, Gegner-KI und -formationen kommt erst später und Sound oder Menüs sowieso, aber ich hab dann schon mal ein funktionierendes Programm mit den grundlegenden Elementen (Spieler, Schuss, Gegner), das ich testen kann.

	BladeRunner Moderator	Mi, März 02, 2011 8:10 Antworten mit Zitat
Ganz wesentlicher Grund für das Scheitern der meisten Hobbyprojekte ist mangelnde Planung. Ein Kernpunkt dabei ist die sogenannte "Featureitis", d.h. es wird Feature um Feature eingebaut ohne dass der Kern des Spieles fertig (durchdacht) ist. Daher solltest Du Dir - und zwar noch bevor du auch nur eine Zeile programmierst- genaustens aufschreiben worum es in deinem Spiel geht und wie es gespielt wird. Und damit meine ich nicht: "so wie in Diablo" oder "man kann verschiedene Einheiten bauen und feindliche Gebäude übernehmen" sondern wirklich dezidierte Angaben: "Bewegen der Spielfigur: LMK auf Karte setzt Zielpunkt, existiert ein Weg (Pathfinding) läuft die Figur dorthin. KlickGeräusch als Bestätigung. Ist das Zielfeld prinzipiell begehbar, wird der Mauszeiger zu einem Fußabdruck." (Da ist nur ein winziger Aspekt, aber so genau sollte es schon sein, denn oft fallen einem erst wenn man so genau arbeitet Designmängel auf.) Zudem solltest Du Milestones verwenden, d.h. wenn Du am implementieren bist solltest Du dir kleine Teilziele setzen: Milestone 1: Karte kann gerendert werden. Bewegung mit WASD funktioniert. Programm wird per Escape verlassen. Diese Milestones müssen komplett erreicht worden sein bevor Du dir das nächste Teilziel setzt, und du darfst nichts zusätzliches reinpacken. So strukturierst Du dir deine Aufgaben von Stone zu Stone. Wichtig: Jeder Milestone muss eine spürbare Veränderung am Spiel bringen (also keine "Feinjustage unter der Haube"), denn dann wird dich das erreichen motivieren den nächsten Stone anzugehen- immerhin siehst Du das dein Projekt "wächst".
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

Mi, März 02, 2011 8:10
Antworten mit Zitat

Ganz wesentlicher Grund für das Scheitern der meisten Hobbyprojekte ist mangelnde Planung. Ein Kernpunkt dabei ist die sogenannte "Featureitis", d.h. es wird Feature um Feature eingebaut ohne dass der Kern des Spieles fertig (durchdacht) ist. Daher solltest Du Dir - und zwar noch bevor du auch nur eine Zeile programmierst- genaustens aufschreiben worum es in deinem Spiel geht und wie es gespielt wird.
Und damit meine ich nicht: "so wie in Diablo" oder "man kann verschiedene Einheiten bauen und feindliche Gebäude übernehmen" sondern wirklich dezidierte Angaben:
"Bewegen der Spielfigur: LMK auf Karte setzt Zielpunkt, existiert ein Weg (Pathfinding) läuft die Figur dorthin. KlickGeräusch als Bestätigung. Ist das Zielfeld prinzipiell begehbar, wird der Mauszeiger zu einem Fußabdruck."
(Da ist nur ein winziger Aspekt, aber so genau sollte es schon sein, denn oft fallen einem erst wenn man so genau arbeitet Designmängel auf.)

Zudem solltest Du Milestones verwenden, d.h. wenn Du am implementieren bist solltest Du dir kleine Teilziele setzen:
Milestone 1: Karte kann gerendert werden. Bewegung mit WASD funktioniert. Programm wird per Escape verlassen.
Diese Milestones müssen komplett erreicht worden sein bevor Du dir das nächste Teilziel setzt, und du darfst nichts zusätzliches reinpacken. So strukturierst Du dir deine Aufgaben von Stone zu Stone. Wichtig: Jeder Milestone muss eine spürbare Veränderung am Spiel bringen (also keine "Feinjustage unter der Haube"), denn dann wird dich das erreichen motivieren den nächsten Stone anzugehen- immerhin siehst Du das dein Projekt "wächst".

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

	ZaP	Mi, März 02, 2011 11:18 Antworten mit Zitat
Also ich benutze auch Midimasters Methode, auch wenn da die Gefahr besteht, dass man hinterher mehr Arbeit hat, wenn man etwas modifizieren möchte, wenn man nicht weit genug gedacht hat
Starfare: Worklog, Website (download)

ZaP

Mi, März 02, 2011 11:18
Antworten mit Zitat

Also ich benutze auch Midimasters Methode, auch wenn da die Gefahr besteht, dass man hinterher mehr Arbeit hat, wenn man etwas modifizieren möchte, wenn man nicht weit genug gedacht hat Smile

Starfare: Worklog, Website (download)

	Sir Gauss der III	Mi, März 02, 2011 19:28 Antworten mit Zitat
Ich Programmiere abhängig von dem wie/was mein Projekt werden soll. Da ich wenig Zeit an sich rein stecken kann habe ich eine grundstzliche Liste von Ideen die ich umsetzen möchte. Bei den Kleineren lege ich einfach los, achte dabei immer darauf so schnell wie möglich etwas zu sehen - im Grund wie Midimaster. Abweichend nur in dem Punkt, dass ich mir z.B. im Hauptmenü "tote" Einstellmöglichkeiten habe die ich im späteren Verlauf erst hinterprogrammiere. So funktioniert zuerst zwar nur "Start", "Laden" wird jedoch schon angezeigt. Damit stell ich sicher dass ich den Menüpunkt nicht vergess, sehe viel zu Beginn und freu mich jedes mal ein wenig wenn wieder etwas mehr funktioniert. Größere Projekte gehe ich anderst an. Meist liste ich vorher auf was ich alles in dem Spiel haben möchte. Dazu schaue ich mir vergleichbare Games an und überlege was diese an an interessanten Features bieten und ob und wie ich diese übernehmen will. Hier kommt zwar schon viel zu viel zusammen, macht aber nichts. Nun folgt eine Prioritätenliste. Was sollte unbedingt drin sein? in welcher tiefe? An dem Punkt fliegt so manches wieder raus und die Liste verkleinert sich. Als ersten tatsächlichen Programmierschritt lasse ich mir das Programm einige male im Kopf durchgehen. Evtl. ersichtliche Probleme oder Schwierigkeiten die auftreten könnten (Schwerkraft z.B.) teste ich in einem Probeprogramm. Einfach mal um es geschrieben zu haben. Auch hier fallen einige Punkte beiseite, da ich hier erkennen kann wie aufwändig eine Idee werden würde und ob ich bereit bin entsprechend viel Zeit dafür zu investieren. Steht die Grundstruktur so weit beginn ich wieder damit erst mal was sichtbares zu proggen. Fertige Teile , auch kleinere Segmende, lagere ich über functionen in eine andere Datei aus. Jede Funktion wird dabei nochmals detaliert beschrieben, die nötigen Fariablen und ihren Einsatz (je besser ich drauf bin desto ausführlicher) erklährt. In der Hauptdatei darf nur das Rahmenprogramm und einige wenige Funktionen die sich in Bearbeitung befinden vorhanden sein. Wie gesagt, den Aufwand betreibe ichnur bei größeren Projekten. Grus Sir Gauss

Sir Gauss der III

Mi, März 02, 2011 19:28
Antworten mit Zitat

Ich Programmiere abhängig von dem wie/was mein Projekt werden soll. Da ich wenig Zeit an sich rein stecken kann habe ich eine grundstzliche Liste von Ideen die ich umsetzen möchte.

Bei den Kleineren lege ich einfach los, achte dabei immer darauf so schnell wie möglich etwas zu sehen - im Grund wie Midimaster.
Abweichend nur in dem Punkt, dass ich mir z.B. im Hauptmenü "tote" Einstellmöglichkeiten habe die ich im späteren Verlauf erst hinterprogrammiere. So funktioniert zuerst zwar nur "Start", "Laden" wird jedoch schon angezeigt.

Damit stell ich sicher dass ich den Menüpunkt nicht vergess, sehe viel zu Beginn und freu mich jedes mal ein wenig wenn wieder etwas mehr funktioniert.

Größere Projekte gehe ich anderst an. Meist liste ich vorher auf was ich alles in dem Spiel haben möchte. Dazu schaue ich mir vergleichbare Games an und überlege was diese an an interessanten Features bieten und ob und wie ich diese übernehmen will. Hier kommt zwar schon viel zu viel zusammen, macht aber nichts. Nun folgt eine Prioritätenliste. Was sollte unbedingt drin sein? in welcher tiefe?
An dem Punkt fliegt so manches wieder raus und die Liste verkleinert sich.

Als ersten tatsächlichen Programmierschritt lasse ich mir das Programm einige male im Kopf durchgehen. Evtl. ersichtliche Probleme oder Schwierigkeiten die auftreten könnten (Schwerkraft z.B.) teste ich in einem Probeprogramm. Einfach mal um es geschrieben zu haben. Auch hier fallen einige Punkte beiseite, da ich hier erkennen kann wie aufwändig eine Idee werden würde und ob ich bereit bin entsprechend viel Zeit dafür zu investieren.

Steht die Grundstruktur so weit beginn ich wieder damit erst mal was sichtbares zu proggen.
Fertige Teile , auch kleinere Segmende, lagere ich über functionen in eine andere Datei aus. Jede Funktion wird dabei nochmals detaliert beschrieben, die nötigen Fariablen und ihren Einsatz (je besser ich drauf bin desto ausführlicher) erklährt.
In der Hauptdatei darf nur das Rahmenprogramm und einige wenige Funktionen die sich in Bearbeitung befinden vorhanden sein.

Wie gesagt, den Aufwand betreibe ichnur bei größeren Projekten.

Grus Sir Gauss

	Hummelpups	Do, März 03, 2011 10:44 Antworten mit Zitat
Vorab eine Liste zu schreiben - wie BR schon schrieb - ist erstmal die einfachste Methode um ein Spiel vorher zu planen. Nehmen wir mal an, das in unserem Hobbyprojekt Kosten, Ressourcen, Risiken usw keine Rolle spielen und wir deshalb darauf keine Acht geben müssen. Trotzdem - auch wenn wir schon einen großen Teil der Planung unbeachtet lassen können - sollte zumindest das Spielkonzept und Anforderungen sowie Ziele und Meilensteine klar definiert sein. Das größte Problem ist, das die Features oder die für uns Entwickler interessanten Codeteile zuerst versucht werden einzubauen, um zu sehen wie gut wir dieses Problem selber lösen. Nehmen wir als Beispiel, das YAN ein Inventar programmieren will, um dies auch verwenden zu können denkt er sich, er könnte ja gleich ein RPG draus machen weil darin Inventare verwendet werden. Also programmiert er los und sobald sein Inventar fertig implementiert ist, sinkt die Motivation richtung Nullpunkt. In anderen Projekten nennt man dies auch 90%-Effekt. Der "schwierige, interessante" Teil ist fertig, aber die einfachen Hauptfunktionen fehlen oder wurden nur unzureichend implementiert. Konkret um ein Projekt zu planen, auch meine Spiele schreibe ich mir zuvor Anforderungen an das Spiel auf. Diese können so aussehen: - Das Spiel nutzt ein dedizierte Server/Clientbasiertes Netzwerksystem, das selber hosten ist nicht möglich - Zu jeder Zeit kann ein Spieler maximal 2 Schusswaffen tragen, eine aus der Gruppe der Primärwaffen und eine aus der Gruppe der Sekundärwaffen. - Waffen aus der Gruppe des Equipments kann in unbestimmter ANzahl eingesammelt und verwendet werden. Dann brauchen wir Ziele, Ziele sind kleiner als Meilensteine. Meilensteine beschreiben in der reinen Lehre den Abschluss einer Phase, also Planungsphase, Entwicklungsphase, Testphase usw, wir könnten sie aber kleiner abstecken und sie für unsere kleinen Errungenschaften missbrauchen, würde ich aber nicht empfehlen. Ziele sind da etwas dynamischer und das was wir brauchen. EIn Ziel hat erstmal keinen zeitlich abgesteckten Rahmen, entweder wird ein Ziel aktuell erreicht oder nicht. Ziel1: Der Client kann sich aus dem Hauptmenü heraus mit einem Server verbinden und anschließend sein Waffenset auswählen. Die Auswahl der Waffen erscheint bei ihm selbst und bei den Mitspielern. Ziel2: Nachdem alle Spieler "Ready" geklickt haben, wechselt der Server den Spielstatus automatisch von "Lobby" nach "Spiel", der Countdown zum Spielstart startet automatisch. Ziele sind normalerweise SMART spezifisch, messbar, attraktiv, realisierbar und terminierbar. Ihr könnt auch Ziele definieren und Ihnen ein Muss/Kann Flag zuweisen. Soviel dazu. Vielleicht hat es euch ja ein wenig geholfen, ich mache das nun seit einem Jahr so und kann mich in meinen Projekten schön an meinen Aufzeichnungen orientieren. Gebot ist: Steht es nicht in den ANforderungen oder Zielen, wird es nicht eingebaut. ALso lieber alles Berücksichtigen, die Arbeit im vornherein lohnt sich.
blucode - webdesign - Ressource - NetzwerkSim BlitzBasic 2D - BlitzMax - MaxGUI - Monkey - BlitzPlus

Hummelpups

Do, März 03, 2011 10:44
Antworten mit Zitat

Vorab eine Liste zu schreiben - wie BR schon schrieb - ist erstmal die einfachste
Methode um ein Spiel vorher zu planen. Nehmen wir mal an, das in unserem
Hobbyprojekt Kosten, Ressourcen, Risiken usw keine Rolle spielen und
wir deshalb darauf keine Acht geben müssen.

Trotzdem - auch wenn wir schon einen großen Teil der Planung unbeachtet
lassen können - sollte zumindest das Spielkonzept und Anforderungen
sowie Ziele und Meilensteine klar definiert sein.

Das größte Problem ist, das die Features oder die für uns Entwickler
interessanten Codeteile zuerst versucht werden einzubauen, um
zu sehen wie gut wir dieses Problem selber lösen.

Nehmen wir als Beispiel, das YAN ein Inventar programmieren will, um
dies auch verwenden zu können denkt er sich, er könnte ja gleich ein
RPG draus machen weil darin Inventare verwendet werden. Also
programmiert er los und sobald sein Inventar fertig implementiert
ist, sinkt die Motivation richtung Nullpunkt.

In anderen Projekten nennt man dies auch 90%-Effekt. Der "schwierige,
interessante" Teil ist fertig, aber die einfachen Hauptfunktionen
fehlen oder wurden nur unzureichend implementiert.

Konkret um ein Projekt zu planen, auch meine Spiele schreibe ich mir
zuvor Anforderungen an das Spiel auf. Diese können so aussehen:

- Das Spiel nutzt ein dedizierte Server/Clientbasiertes Netzwerksystem,
das selber hosten ist nicht möglich
- Zu jeder Zeit kann ein Spieler maximal 2 Schusswaffen tragen, eine aus der
Gruppe der Primärwaffen und eine aus der Gruppe der Sekundärwaffen.
- Waffen aus der Gruppe des Equipments kann in unbestimmter ANzahl
eingesammelt und verwendet werden.

Dann brauchen wir Ziele, Ziele sind kleiner als Meilensteine. Meilensteine
beschreiben in der reinen Lehre den Abschluss einer Phase, also
Planungsphase, Entwicklungsphase, Testphase usw, wir könnten
sie aber kleiner abstecken und sie für unsere kleinen Errungenschaften
missbrauchen, würde ich aber nicht empfehlen.

Ziele sind da etwas dynamischer und das was wir brauchen. EIn Ziel
hat erstmal keinen zeitlich abgesteckten Rahmen, entweder wird
ein Ziel aktuell erreicht oder nicht.

Ziel1:
Der Client kann sich aus dem Hauptmenü heraus mit einem Server
verbinden und anschließend sein Waffenset auswählen.
Die Auswahl der Waffen erscheint bei ihm selbst und bei den Mitspielern.

Ziel2:
Nachdem alle Spieler "Ready" geklickt haben, wechselt der Server
den Spielstatus automatisch von "Lobby" nach "Spiel", der Countdown
zum Spielstart startet automatisch.

Ziele sind normalerweise SMART
spezifisch, messbar, attraktiv, realisierbar und terminierbar.

Ihr könnt auch Ziele definieren und Ihnen ein Muss/Kann Flag zuweisen.

Soviel dazu. Vielleicht hat es euch ja ein wenig geholfen, ich mache
das nun seit einem Jahr so und kann mich in meinen Projekten schön
an meinen Aufzeichnungen orientieren.

Gebot ist: Steht es nicht in den ANforderungen oder Zielen, wird es
nicht eingebaut. ALso lieber alles Berücksichtigen, die Arbeit im
vornherein lohnt sich.

blucode - webdesign - Ressource - NetzwerkSim
BlitzBasic 2D - BlitzMax - MaxGUI - Monkey - BlitzPlus

Übersicht

Sonstiges

Smalltalk

Nach Oben

BlitzBasic Portal

Projektplanung

Betreff: Projektplanung