Wie Hobby Projekt planen?

[otze]

So, jetzt ist es soweit, ich möchte mein erstes großes Softwareprojekt in Eigenregie starten. Die letzten Jahre hab ich viel mit C++ rumgespielt, kleine Sachen gemacht, und mir überlegt, wie was funktioniert. Nun solls aber mal etwas mehr sein, damit ich mir selbst zeigen kann, dass die letzten Jahre was gebracht haben :D.

Leider sind größere Hobbyprojekte etwas problematisch, und ich weis nicht genau, wie ich an die Sache rangehen soll. Es soll - wie solls auch anders sein - ein Computerspiel werden. Ideen wie es werden soll hab ich genug, daran besteht auch in den seltensten Fällen ein Mangel. Was mir fehlt, ist ein Plan.

Ich weis, dass das Projekt niemals den Status "fertig" haben wird. Um ehrlich zu sein, kann ich wohl extrem froh sein, wenn es den Status "lauffähig" hat. Und das ist meine größte Sorge. Wie kann ich ein Hobbyprojekt einer größeren Komplexität planen, ohne dass es sofort zum desaster wird? Auch wenn desaster für jemanden der vor hat in der it branche zu arbeiten sicher keine schlechte Erfahrung sind, glaube ich nicht, dass es sinnvoll ist, sehenden Auges ins offene Messer zu rennen.

Wie sieht also die Situation aus:
1. ich kann nicht davon ausgehen, dass ich die nötige zeit haben werde, um alles was ich plane(egal wie viel ich rausstreiche) zu implementieren
2.ich habe von einigen Dingen noch keine Ahnung und müsste mich reinlesen
3.es währe schön, wenn ich dieses Jahr noch mit Programmieren anfangen würde, und nicht ewig in der Planungsphase stecke
4. ich hab noch nie Software größeren maßstabs programmiert
5. Ich hab Ahnung von der Programmierung(implementation, unit tests, usw), aber kaum Ahnung von Software Design
6. selbst wenn ich Ahnung vom Design hätte, hätte ich aufgrund von 2. Ein echtes Problem bei der Planung. Wie plant man etwas, was man nicht einschätzen kann?

Das sieht verdammt schlecht aus, ich weis. In der Wirtschaft würde ich jetzt sagen: mach es nicht. Aber das ist ein Hobbyprojekt, und ich gefährde damit nur meine Freizeit, also will ichs sehr wohl machen.

Nun, gibt es für sowas Planungsansätze? Ich hab mir mehrere Dinge überlegt:
1. Ich überlege mir: was brauche ich aufjedenfall, und was davon kann alleine existieren. Die Schnittmenge implementier ich dann. Nachteil: ich hab keinen zusammenhängen Code, nur Schnipsel die eventuell irgendwann mal zusammen funktionieren könnten.
2. ich fang an irgendeinem beliebigen Punkt aus 1. an und versuch dann bottom up von dort einfach weiterzumachen. Der Nachteil ist aufjedenfall die steigende Komplexität. Je weiter ich komme, desto mehr komponenten werden für den nächsten Schritt benötigt. Irgendwann ende ich also darin, andauernd irgendwas zu Programmieren, was irgendwann eines tages eventuell teil des lauffähigen Programms werden kann(man stelle sich eine Pyramide vor, die Schicht für Schicht aufgebaut wird. Man fängt klein an, und baut dann immer wieder drum herum. Jede Schicht braucht länger als die vorhergehende).
3. Ich versuche so schnell wie möglich einen lauffähigen Prototypen zusammenzuhacken, und den dann nach und nach über die Jahre zu ersetzen. Der Vorteil wäre natürlich, dass ich am Anfang was sehe und mir wissen aneignen kann. Der Nachteil ist, dass ich mit potentiell extrem schlechten wegwerfcode als Basis arbeite, den ich dann permanent mit Anpassen muss, immer wenn ich irgendwas veränder.
4.??

Gibts dafür irgendeine *halbwegs* funktionierende Lösung? Oder ist es besser einfach reinzuspringen, und zu schauen, was so passiert, da man eh keine Ahnung hat, was auf einen zukommt?

[rüdiger]

Rapid Prototyping ist imho der beste Weg (also 3.). Schreib dein Programm also immer in kleinen Stücken, die du kompilieren kannst und die dir schon eine gewisse Funktionalität geben. Das kannst du dann immer weiter ausbauen und das bestehende Design ändern.

Wenn du alles vorher groß planst, wirst du vermutlich nie fertig, weil du nie Land sehen wirst und selbst bei genauster Planung kann es dir passieren, dass du wichtige Dinge einfach übersiehst.

[---]

auf jeden fall Rapid Prototyping ich meine wofür gibt es sonnst OOP

[TheTester]

rüdiger schrieb:

Rapid Prototyping ist imho der beste Weg (also 3.). Schreib dein Programm also immer in kleinen Stücken, die du kompilieren kannst und die dir schon eine gewisse Funktionalität geben. Das kannst du dann immer weiter ausbauen und das bestehende Design ändern.

Wenn du alles vorher groß planst, wirst du vermutlich nie fertig, weil du nie Land sehen wirst und selbst bei genauster Planung kann es dir passieren, dass du wichtige Dinge einfach übersiehst.

Auch die Arbeit mit Prototypen, die man in so ziemlich in jedem Vorgehensmodell verwenden kann, möchte geplant sein und wenn man nicht von Anfang an eine gewisse Struktur hineinbringt wird das spätere Ändern des Designs geschweigedenn das Ausbauen eine echte Qual und dann hat man schnell keine Lust mehr und der Code bleibt so wie er ist was sich dann im Endeffekt rächt, d.h. in noch mehr Arbeit niederschlägt.

Bücher über Softwaretechnik wären sicher einen Blick wert, mir war so das ich mal einen Beitrag 3-4 Bücher erwähnte. Wenn ich den hier wiederfinde verlinke ich die Bücher.

[Mr X]

Nunja, ich kann hier aus Erfahrung sprechen und stimme meinen Vorrednern zu: Rapid Prototyping ist empfehlenswert, weil man schnell was funktionierendes(und damit motivierendes) hat.

Bei mir war die Ausganslage ähnlich, aber:
5. Ich hab wenig Ahnung von der Programmierung(implementation, unit tests, usw) und kaum Ahnung von Software Design

Dennoch:
Bis jetzt funktioniert alles soweit. Wenn ich nicht weiterkomme, warte ich ein weilchen(ca. 1 Woche) und versuchs dann wieder; Notfalls frag ich dieses Forum.
Das nötige Wissen bezüglich der Implementation habe ich mir angeeignet(bin immernoch dabei)
Ich habe erstmal zu meinem Spiel ein grundlegendes Hauptmenü erstellt, das bislang nur ein neues Spiel starten kann. Derzeit kann es auch nur 1 verschiedene Karte laden. Im ersten Schritt habe ich die Anzeige dazugeschrieben(und tausendmal wieder verbessert), dann mich mit den Menüs am Rand(war erfolglos, wird später gemacht) und bin grade bei der Programmierung einer Pathfinding Funktion, damit ich meine Einheiten Bewegen kann. Danach kommt dann vielleicht Sound, oder die Implementation eines Karteneditors(damit ich schneller Karten zum Testen erstellen kann).
Immer Step by Step.
Und mit jedem Schritt verwerfe ich alten Mist, wo ich gedankenlos Programmiert habe, den ich dann zwischendurch schnell ändern muss.
Dann und wann fallen mir verbesserungen ein, die dann schnell eingebaut werden.

mfg
Mr. X

[nep]

Hm ich finde die Mischung machts.
Ich würde aber sagen dass hier am Anfang eine *genaue* Planungsphase der Schlüssel zum Erfolg ist. Damit meine ich jetzt nicht unbedingt Architektur/Design, sondern ein Planen der "Anforderungen" (oder wie auch immer du es bei dem Spiel nennnen willst).
Du sagst selbst, Ideen wie es werden soll hast du genug. Deshalb ganz wichtig: *Konkretisiere* diese Ideen und lege *genau* fest was das Spiel alles können soll, so dass du am Ende einen tatsächlichen Rahmen hast wo du eindeutig siehst was du alles machen willst. Wenn du dies tust wirst du automatisch feststellen, dass es gewisse grundlegende Dinge gibt die auf jeden Fall verwirklichen willst, während es andersrum wieder Dinge gibt die eher optional sind und die du nach hinten verschieben willst. Es ist halt wie gesagt wichtig, dass hier nicht nur "Wischiwaschi" Zeugs steht sondern alles möglichst genau schon festgelegt ist. Dabei ist die technische Seite (also wie du das realisierst, mit welchen Frameworks, Technologien usw.) total unwichtig. Das kannst du dir dann danach überlegen, wie du das alles umsetzen willst. Das ist auch nicht unbedingt gleich in einer Woche erledigt, das braucht schon etwas Zeit (wenn du es richtig machst), weil du dir hier tatsächlich schon viele Gedanken machen musst. Aber das wird dir später sehr zugute kommen, auch wenn das eher weniger Spaß macht Das ist ja auch einer der Gründe warum so viele (Spiele)Hobby-Projekte scheitern. Es gibt zwar Ideen, aber man fängt einfach mal damit an gewisse Dinge zu implementieren und merkt irgendwann dass man sich total verrannt hat, und dann isses schon zu spät und die Motivation ist auch weg.

Wie du dann später vorgehst ist wieder was anderes. Sich ein bisschen Gedanken zu machen welche Komponenten du hast und wie du die designst ist sicherlich nicht verkehrt, aber wie schon gesagt, das wird man nie shcon im Vorhinein alles perfekt festlegen können. DAs ist immer iterativ, d.h. du programmierst, und merkst auf einmal, dass du dann doch was anders machen musst. DAs ist auch okay so. Prototyping würde ich für gewisse Aspekte deines Projektes einsetzen wo du dir noch unsicher bist bzw. keine Erfahrung hast. Wenn du z.B. eine KI entwickeln musst, macht es sicher Sinn da erst mal prototypisch etwas rumzuspielen...

[rüdiger]

TheTester schrieb:

rüdiger schrieb:

Rapid Prototyping ist imho der beste Weg (also 3.). Schreib dein Programm also immer in kleinen Stücken, die du kompilieren kannst und die dir schon eine gewisse Funktionalität geben. Das kannst du dann immer weiter ausbauen und das bestehende Design ändern.

Wenn du alles vorher groß planst, wirst du vermutlich nie fertig, weil du nie Land sehen wirst und selbst bei genauster Planung kann es dir passieren, dass du wichtige Dinge einfach übersiehst.

Auch die Arbeit mit Prototypen, die man in so ziemlich in jedem Vorgehensmodell verwenden kann, möchte geplant sein und wenn man nicht von Anfang an eine gewisse Struktur hineinbringt wird das spätere Ändern des Designs geschweigedenn das Ausbauen eine echte Qual und dann hat man schnell keine Lust mehr und der Code bleibt so wie er ist was sich dann im Endeffekt rächt, d.h. in noch mehr Arbeit niederschlägt.

Ich sag ja nicht, dass man gar nicht planen soll. Ich sage nur, dass man (ohne größere Erfahrung mit der zu entwickelnden Software) oft kaum vernünftig planen kann. Daher lohnt es sich imho eher eine grobe Vorstellung zu entwickeln und dann in kleinen Schritten vorzugehen.

TheTester schrieb:

Bücher über Softwaretechnik wären sicher einen Blick wert, mir war so das ich mal einen Beitrag 3-4 Bücher erwähnte. Wenn ich den hier wiederfinde verlinke ich die Bücher.

So Bücher sind immer so eine Sache, da sie viel graue Theorie runterbeten und die Frage ist, ob man das wirklich so umsetzen oder nutzen kann bzw. will.

[Profi-Programmierer]

Plane zuerst einmal was dein Spiel können soll, das heißt schreib dir genau auf wie es sein soll, was für Einheiten usw. es geben soll.
Das ist der wichtigste Schritt sonst wirst du nie fertig werden.

Dann überlege dir ein grundlegenden Aufbau deines Spiels (ich empfehle dir Game Coding Complete 2nd Edition zu lesen, bevor du auch nur mit dem Design anfängst), also Programmiertechnisch. Hier musst du noch nicht im Detail wissen wie jede Klasse aussieht nur einen groben Überblick welche größeren Module es gibt, wie die Interaktion ungefähr aussehen soll.
Dann plane den Kommunikationsfluss dieser Module, wenn das ganze laufen soll, damit du ungefähr siehst welche Komponenten mit welcher anderen Komponente interagieren soll.

So jetzt kannst du anfangen jedes Modul zu implementieren, da du alleine bist hast du den Vorteil, dass du die Schnittstellen nicht im Vorfeld festlegen musst, sondern jederzeit flexibel anpassen kannst.

Ob du jedes Modul möglichst schnell als rudimentären Prototyp hinklatschst oder gleich richtig implementierst liegt an dir.

Ich halte es für sinnvoller die grundlegenden Teile, also die engine-nahen, gleich sauber zu implementieren, das oben drüber was man auch tatsächlich sehen kann aber ruhig im prototyping Verfahren, damit du schnell siehst ob es das ist was du willst, ob man es überhaupt implementieren kann, so wie du es dir vorgestellt hast etc.

Und nimm auf jeden Fall eine Engine und komm nicht auf die Idee diese selber zu schreiben, dann kannst du dir sicher sein, dass dein Spiel nie fertig wird, da dir einfach die Motivation verloren geht (ich spreche da aus Erfahrung).

[TheTester]

rüdiger schrieb:

[...]
Ich sag ja nicht, dass man gar nicht planen soll. Ich sage nur, dass man (ohne größere Erfahrung mit der zu entwickelnden Software) oft kaum vernünftig planen kann. Daher lohnt es sich imho eher eine grobe Vorstellung zu entwickeln und dann in kleinen Schritten vorzugehen.

rüdiger schrieb:

TheTester schrieb:

Bücher über Softwaretechnik wären sicher einen Blick wert, mir war so das ich mal einen Beitrag 3-4 Bücher erwähnte. Wenn ich den hier wiederfinde verlinke ich die Bücher.

So Bücher sind immer so eine Sache, da sie viel graue Theorie runterbeten und die Frage ist, ob man das wirklich so umsetzen oder nutzen kann bzw. will.

[/quote]

Dagegen ist ja nichts einzuwenden, welche Granularität man zugrunde legt ist Erfahrungssache wie du schon sagtest, da bin ich auch ganz deiner Meinung. Am Anfang wird es sowieso eine Spielerei mit neuen "Technologien" und Techniken. Schließlich ist noch kein Meister vom Himmel gefallen und die "graue Theorie" ist es oft wert zu wissen, da wenn die Phase der Spielerei vorbei ist man sich dann das große Ganze überlegen kann und dafür stellt die Softwartechnik eben ein gewisses Handwerkszeug dar.

Es ist ja nich so das man die Dinge aus Büchern 1:1 übernehmen muss oder sollte, aber man hat wenigstens einen Plan und dann liegt es an einem selbst inwieweit man das ausprobieren bzw. anwenden möchte. Es gehört nämlich auch eine große Portion Selbstdisziplin dazu sowas umzusetzen und nicht schleifen zu lassen, Unterstützung dabei bieten dann auch CASE-Tools und andere schicke Dinge.

[javaneser]

bin selber hobbyprogramierer und hab nach endlosen kleinen chaotischen projekten, die nie fertig wurden, mich auch mal mit dem thema befasst.

dabei hab ich ein buch gefunden: agile java development with hibernate and spring http://safari.oreilly.com/0672328968 (psst: hab ich sogar irgendwo als ebook gefunden)
dass java verwendet wird, soll dich nicht stören, der erste teil ist sehr allgemein.

in dem buch werden die techniken extreme programming (http://www.extremeprogramming.org/)
und agile model driven development (http://www.agilemodeling.com/)
vorgestellt und angewendet.

im prinzip ähnlich wie schon gesagt:
du baust deine anwendung in kleinen interationen die jede für sich funtkionsfähig ist. in jeder iteration baust du einige features ein, testest die und so weiter. so hast du nach jedem durchgang ein lauffähiges programm und du kannst die fortschritte besser verfolgen, das steigert die motivation.

am anfang ist es wichtig, die gewünschte funtkionalität runterzubrechen auf kleine schritte, die der benutzter machen kann. damit weist du sehr bald, was die anforderungen an die einzelnen module sind. daraus kannst du dann ableiten, wie deine interfaces aussehn müssen. (die solltest du nicht mehr gross ändern müssen, aber das kommt immer vor)

[otze]

Erstmal danke für die vielen Tipps :). Da muss ich mir jetzt erstmal was überlegen

[Game Coder]

Profi-Programmierer schrieb:

Plane zuerst einmal was dein Spiel können soll, das heißt schreib dir genau auf wie es sein soll, was für Einheiten usw. es geben soll.
Das ist der wichtigste Schritt sonst wirst du nie fertig werden.

Dann überlege dir ein grundlegenden Aufbau deines Spiels (ich empfehle dir Game Coding Complete 2nd Edition zu lesen, bevor du auch nur mit dem Design anfängst), also Programmiertechnisch. Hier musst du noch nicht im Detail wissen wie jede Klasse aussieht nur einen groben Überblick welche größeren Module es gibt, wie die Interaktion ungefähr aussehen soll.
Dann plane den Kommunikationsfluss dieser Module, wenn das ganze laufen soll, damit du ungefähr siehst welche Komponenten mit welcher anderen Komponente interagieren soll.

So jetzt kannst du anfangen jedes Modul zu implementieren, da du alleine bist hast du den Vorteil, dass du die Schnittstellen nicht im Vorfeld festlegen musst, sondern jederzeit flexibel anpassen kannst.

Ob du jedes Modul möglichst schnell als rudimentären Prototyp hinklatschst oder gleich richtig implementierst liegt an dir.

Ich halte es für sinnvoller die grundlegenden Teile, also die engine-nahen, gleich sauber zu implementieren, das oben drüber was man auch tatsächlich sehen kann aber ruhig im prototyping Verfahren, damit du schnell siehst ob es das ist was du willst, ob man es überhaupt implementieren kann, so wie du es dir vorgestellt hast etc.

Und nimm auf jeden Fall eine Engine und komm nicht auf die Idee diese selber zu schreiben, dann kannst du dir sicher sein, dass dein Spiel nie fertig wird, da dir einfach die Motivation verloren geht (ich spreche da aus Erfahrung).

Genau so würde ich es auch empfehlen.

[TdZ]

Das ist eine Problematik, die genau auf mich zutrifft.

Seit Jahren versuche ich mich schon in verschiedenen Projekten, meist auch Computerspiele.

Ich habe mir damit zwar eine Menge Erfahrungen gesammelt im Bezug auf die Herangehensweise bestimmter wiederkehrender Probleme, die ich nun in meiner beruflichen Tätigkeit einsetzen kann, aber niemals ein Projekt auch nur ansatzweise fertiggestellt.

Irgendwann bin ich zu folgended Schlussfolgerungen gekommen:

1. Man beschränkt sich auf die Umsetzung eines wirklich kleinen Projekts, dessen einzelne Aspekte nicht den Grad der Perfektion erreichen, den man sich erwünscht hat. Damit ist gemeint, dass es als Einzelperson schlichtweg unmöglich ist, in einer moderaten Zeitspanne zu Programmieren, Grafiken zu erstellen, Soundeffekte oder Musikstücke zu machen, ohne dass die Motivation dauerhaft erhalten bleibt. Also bleibt man folglich auf dem Boden der Tatsachen, was den Umfang des Projekts angeht.

oder

2. Wenn man absolut davon überzeugt ist, ein größeres Projekt zu starten, so sollte man sich nach Mitstreitern umsehen. Im Internet gibt es zwar tausende von solchen Leuten, aber meine Erfahrungen in der Zusammenarbeit waren eher bescheiden. Es ist also am besten, wenn man sich die benötigten Leute aus seinem Bekanntenkreis "rekrutiert", da man so besser weiß, mit wem man es zu tun hat.
Natürlich gibt es hier auch Nachteile, gerade im Bezug auf die Motivation der anderen Teammitglieder. Wenn man sich dessen aber bewusst ist und eine gewisse Dynamik in der Teambesetzung verkraften kann, so ist das eine gute Sache.

Egal, welchen Weg du einschlagen willst, an einer Sache kommt man nicht vorbei:
"Konzeption" lautet der Schlüssel zum Erfolg. Mit einem guten Konzept kannst du in der Vorphase bereits eine Menge Probleme herausarbeiten, mögliche Lösungsansätze finden oder Ideen vertiefen. Außerdem ist ein gut durchdachtes Konzept, das kurz und prägnant das Projekt umschreibt (muss ja keine 1000 Seiten sein, solang es gut die einzelnen Teilvorhaben des Projekts erläutert) äußerst vorteilhaft im Finden und Motivieren von anderen Mitstreitern.

Und noch was: Fange NIEMALS mehr als ein Projekt zur gleichen Zeit an, das hat bei mir selten ein gutes Ende genommen

Das alles sind, wie gesagt, lediglich meine Erfahrungen, die ich im Laufe der Jahre zum Thema Hobby-Projekte gesammelt habe...

[otze]

@Tdz danke dir

Ich hab schon in etwa einen Plan, wie ich das mache. Ich hab nicht vor, mich um musik oder grafiken zu kümmern, zumindest nicht mehr als notwendig. Aber ich glaube, dass ich zumindest für die grafik eventuell leute auftreiben kann, wenn ich das mit der Programmierung hinkrieg.

Ich bin mir allerdings ziemlich im klaren darüber, dass das Projekt nicht fertig wird, das stört mich aber auch nicht. Der Weg ist das Ziel und so

Die letzten Tage war ich ein wenig auf libsuche, und hab mich inzwischen von Irrlicht verabschiedet und bin zu Ogre3D übergegangen. Zwar monolithisch wie...aber trotzdem wesentlich flexibler. Als Inputsystem kommt OIS in frage, und um sound kümmer ich mich erstmal nicht. Ich hab vor mich noch ne ecke weiter auszustatten, zumindest unter linux kann man sich ja nicht über libmangel beschweren

Ich hab mir auch schon einen groben Vorgehenplan überlegt, zumindest einen Plan der aussagt was mir erstmal am wichtigsten ist.

Namentlich: Die geplante 3D Tile Engine(ersetze Grafik durch Programmierkenntnise ). Also erster großer Milestone wird eine ein Programm sein, dass eine datei ausliest und daraus dann eine Tilemap zusammensetzt. Sowas wollte ich schon immer mal machen. Wies dann weiter geht? Hmm mal schauen :).Wie gesagt, das wird die erste Große Hürde, weil man dafür schon ne Menge an Ogre rumspielen muss(eigener SceneManager...). Mit Irrlicht war das garnicht erst so ohne weiteres Möglich, von daher bin ich jetzt schon wesentlich besser dran

[3D Tiles??]

Wie darf man sich 3D-Tiles vorstellen? Würfel?

[Erhard Henkes]

Die letzten Tage war ich ein wenig auf libsuche, und hab mich inzwischen von Irrlicht verabschiedet und bin zu Ogre3D übergegangen.

Was hat Dich bei Irrlicht am meisten gestört bzw. was hat Dir dort gefehlt? Ich finde vor allem, dass die Unterstützung beim Verstehen der Klassendetails zu gering ist, z.B. existiert kein aufbauenedes Step-by-Step-Tutorial, lediglich einige Werbe-Tuts und ein zu komplexes Demo, aus dem man modular wenig Honig saugen kann. Wie ist das bei Ogre3D?

[Ogre3D Kenner]

Erhard Henkes schrieb:

Die letzten Tage war ich ein wenig auf libsuche, und hab mich inzwischen von Irrlicht verabschiedet und bin zu Ogre3D übergegangen.

Was hat Dich bei Irrlicht am meisten gestört bzw. was hat Dir dort gefehlt? Ich finde vor allem, dass die Unterstützung beim Verstehen der Klassendetails zu gering ist, z.B. existiert kein aufbauenedes Step-by-Step-Tutorial, lediglich einige Werbe-Tuts und ein zu komplexes Demo, aus dem man modular wenig Honig saugen kann. Wie ist das bei Ogre3D?

Ogre ist da ziemlich top, die haben ein Example Framework geschrieben das in den Tuts verwendet wird, das macht den ersten Einstieg sehr sehr einfach und du siehst gleich mal das higher level interface von Ogre.
Wie man Ogre initialisiert und alles kann du dann im Example Framework studieren, ist auch schön kommentiert. Inzwischen gibts aber auch einige Artikel die erklären wie man ohne dem Example Framework initialisiert, je nachdem was dir halt lieber ist.
Außerdem gibts ein Buch zu Ogre3d.

[rapso]

(ich hab hier den thread nicht gelesen, nur den ersten post, darauf die kleine antwort von mir )

geh davon aus, dass 90% der arbeit von dir gemacht werden muss. egal ob du ein team von 5 oder 50 hobbyentwicklern zusammenbimmelst. es haengt fast alles von dir ab (besonders am anfang). wenn du schon etwas fertig hast, wirst du eventuel ein paar faehige leute anlocken, aber erst ein team zu gruenden und dann das projekt starten ist meist der untergang.
entsprechend solltest du planen ;), vor allem dass planen meist keinen fortschritt beim projekt bringt, entsprechend klein solltest du die zeit fuer planen setzen.
ich hab meist ein paar globale ziele, z.b. terrain rendering, dann zerleg ich das in subziele von je ein-tag arbeit und schlussendlich wochenende fuer stabilisieren bzw feinschliff.

eventuell kannst du dir auch was fertiges schnappen und daran arbeiten. ein quake3 mod (hast ja alle sourcen), ein UT3 mod oder z.b. NVN, kann dich schnell ans eigentliche spielen bringen als alles von anfang an zu machen.

vielleicht auch mal an ein grosses, erfolgreiches hobbyprojekt anschliessen

[otze]

Erhard Henkes schrieb:

Was hat Dich bei Irrlicht am meisten gestört bzw. was hat Dir dort gefehlt? Ich finde vor allem, dass die Unterstützung beim Verstehen der Klassendetails zu gering ist, z.B. existiert kein aufbauenedes Step-by-Step-Tutorial, lediglich einige Werbe-Tuts und ein zu komplexes Demo, aus dem man modular wenig Honig saugen kann. Wie ist das bei Ogre3D?

Fangen wir mal bei den Tutorials An. Hier mal die Auswahl an offiziellen Tutorials bei Ogre3D:
http://www.ogre3d.org/wiki/index.php/Ogre_Tutorials

Merke: erst in Tutorial 6 wird man damit konfrontiert, Ogre selbst initialisieren zu müssen. In den tutorials lernt man auch mit OIS umzugehen(tut 4+5) das initialisieren lernt man hier: http://www.ogre3d.org/wiki/index.php/Using_OIS.
Naja schaus dir selbst an. Die tutorials sind zwar in Anbetracht einer Klasse mit ~200 Methoden bitter nötig, aber man kommt so wesentlich besser rein.

Ansonsten hab ich auch das gefühl, dass Ogre wesentlich einfacher zu nutzen ist. Aber das kann eventuell auch nur deswegen so sein, weil es dafür gute tutorials gibt.

Wie darf man sich 3D-Tiles vorstellen? Würfel?

ne, eher so:
http://www.activewin.com/reviews/previews/games/d/dungeon_siege/ds_beta_067.jpg

@rapso
nee modden ist nicht. Es geht mir ja nicht ums spielen. NVN mods hab ich schon gemacht, so toll fand ichs nicht, und einen fps so umzumodden dass er was anderes ist als ein fps ist auch ziemlich schwierig :).
Ich weis, dass dann 90-100% der Arbeit bei mir liegen wird. Aber das ist ja nicht so schlimm. Ich brauch keine Supertolle Grafik um zu wissen, dass mein Code funktioniert. Mir gehts prinzipiell wirklich erstmal nur um den Code, alles andere...kommt später von selbst oder garnicht