Top-Down oder Bottom-Up beim Programmieren?
-
Da ich fast ausschließlich Sondersteuerungen programmiere und die auf Basis verschränkter Automaten, steht die Grobstruktur meist schon mit der Aufgabenstellung.
Die kniffeligen Sachen sind dann seltener wirklich neue Module, sondern Hardwareports, wenn ich auf andere Controller portiere oder neue Hardware integrieren muß. Sinnvollerweise fange ich dann meistens "unten" an, um schnell testbare Funktionen zusammenzukriegen. Da sieht man, ob und wie z.B. ein neuer Baustein in das DMAC- Konzept des Controllers (und damit auch zu meinen bestehenden Libs) paßt oder ob ich in der Ebene drüber was Neues brauche.
Also ich schmier' mir schon vorher auf, wie's aussehen soll, aber das coden fange ich eher bei den Details an, die klärungsbedürftig sein könnten.
-
ich plane grob Top-Down ("wo will ich hin? Was brauche ich? Was sind die Abhängigkeiten?") und programmiere dann Bottom-Up.
Genauer: Nach der groben Planung suche ich mir irgendein Blatt meines Programmbaumes, also eine Klasse die alleine existieren kann, programmiere die und schreibe dann direkt Unit Tests zu. Der Vorteil für mich ist, dass ich sagen kann: der Codeteil ist fertig, getstet und funktioniert. Der andere Vorteil ist: die unittests geben direkt Aufschluss darüber, ob das Interface okay ist. Naja, und dann wandere ich immer weiter den Baum nach oben immer wissend, dass ich nur auf dem aufbauen muss, was bereits fertig ist. Sehr motivierend meiner Meinung nach. Zumal man nur sehr wenig temporären Code produziert den man nur dafür braucht, dass das wenige was man hat zusammenhält...
Es führt zwar dazu, dass man eher mit unwichtigem beginnt: "Ich schreib zuerst nen Parser fürs verwendete Datenformat", aber da das eh irgendwann gemacht werden muss, bin ich damit ganz zufrieden - ich darf mich nur nicht in den Details verrennen.
-
Ich fange immer Top-Down an und baue die benötigten Komponenten dann Bottom-Up auf. Aber es ist eigentlich immer das, was mir je nach Anwendung intuitiv am sinnigsten erscheint dominant. Ich kann otze da nur zustimmen. Genau so mache ich es meist auch. Besonders der Teil mit "ich darf mich nicht in Details verrennen" hat mich zum schmunzeln gebracht
.
-
Gregor schrieb:
Hallo.
Nach welchem Ansatz geht Ihr beim Programmieren vor? Programmiert Ihr erst auf einem relativ abstrakten Level, um dann später in die Details zu gehen (Top-Down)? Oder programmiert Ihr erst die Details und fügt sie nachher zu einem Ganzen zusammen (Bottom-Up)? Oder macht Ihr es mal so und mal so?
Mir ist in letzter Zeit nämlich aufgefallen, dass meine Programmierweise recht unsystematisch ist und ich frage mich, ob es Sinn macht, das etwas zu systematisieren.
Was spricht für Top-Down, was für Bottom-Up? Was spricht dafür, eine sehr systematische Programmierweise zu haben und was spricht dafür, sich da mehr Freiheiten zu lassen? Habt Ihr eine systematische Herangehensweise ans Programmieren? Wenn ja: Erklärt Euer System bitte etwas.
Gratuliere zum Aufstieg! - "Zweifel ist das Vorzimmer zur Erkenntnis." (indisches Sprichwort) - 
- Ich habe gerade in den letzten Jahren Tonnen von Folien erstellt, die sich genau mit diesen Thema beschäftigen. Mal abgesehen von den 15 Jahren Erfahrung als Consultant, Manager und System- und Prozessingieur :). Nur wenn Du Jahre deines Lebens "geopfert" hättest, um solche im doppelten Sinne 'globalen' System zu entwickeln und ca. 3.000 € Tagessatz dafür kassierst, würdest Du den Leuten das noch für Lau im Internet stecken?! 
Und wie sogar selbst volkard endlich realisiert hat, ist das nicht nur ein Problem der SW Entwicklung, sondern ein grundsätzliches Problem der Menschen und hauptverantwortlich für die größten Probleme unserer Zeit. Ob globale Erwärmung oder Finanzkrise, ob Entscheidungsträger, Experten oder gewöhnliche Menschen:
Immer steht man vor der Entscheidung ob man Buttom-Up arbeitet - bodenständig, taktisch, quick-and-dirty, heuristisch, konservativ, formalistisch, den Status Quo erhaltend, schnell und mit wenig Aufwand im lokalen Maximum nachsteuernd, so dass wir eine 'Einweg'-Entwicklung haben.
Oder arbeiten wir Top-Down - visionär, strategisch, abstakt, langsam Resultate produzierend, bloatig, mit hohen Konfigurationsaufwand, progressiv, viele Veränderungen in Kauf nehmend, auf der Suche nach einem Maximum mit besonders hohen Fitnesswerten, so dass wir deren Bauelemente (Muster, Methoden, Prozesse, Systeme, Konzepte etc.) möglichst oft wiederverwenden können.
Und die Skalierung hängt natürlich von den Persönlichkeitstypen des Menschen und den entsprechen Umständen ab.
Alaaf!
-
Prof84 schrieb:
Und wie sogar selbst volkard endlich realisiert hat, ist das nicht nur ein Problem der SW Entwicklung, sondern ein grundsätzliches Problem der Menschen und hauptverantwortlich für die größten Probleme unserer Zeit.
Nein, davon nehme ich doch Abstand.
Es ist unter Umständen denkbar, daß es vielleicht möglicherweise ein Problem derer ist, die sich mangels Inhalten an leeren Strukturen festhalten wollen.Prof84 schrieb:
Immer steht man vor der Entscheidung ob man Buttom-Up arbeitet - bodenständig, taktisch, quick-and-dirty, konservativ, formalistisch, den Status Quo erhaltend, schnell und mit wenig Aufwand im lokalen Maximum nachsteuernd, so dass wir eine 'Einweg'-Entwicklung haben.
Bodenständig in der Softwareentwicklung ist aber TD. Konservativ ist auch TD. formalistisch ist auch TD. Lokale maxima suchend ist auch TD. Du solltest wissen, daß TD eine der Forderungen der Dokmatisten der Strukturierten Programmierung ist.
Prof84 schrieb:
Oder arbeiten wir Top-Down - visionär, startegisch, abstakt, lansam Resultate produzierend, bloatig, mit hohen Konfigurationsaufwand, progressiv, viele Veränderungen in Kauf nehmend, auf der Suche nach einem Maximum mit besonders hohen Fitnesswerten, so dass wir deren Bauelemente (Muster, Methoden, Prozesse, Systeme, Konzepte etc.) möglichst oft wiederverwenden können.
Startegisch kann beides sein. Abstakt zwar auch, aber TD tendiert gerne zu Angstlayern und damit mehr Abstaktion, oder? Langsamheit würde ich mit TD gar nicht in Verbindung bringen. Was war nochmal Rapid Prototyping? Progressiv? Ah, du meinst progressiv langsam.
-
Ich mache immer das zuerst das, was gerade ansteht, wobei fast immer die Lauffähigkeit des Programms erhalten bleibt.
Gibt es mehrere anstehende Sachen zur Auswahl, heißt es zu wählen, zum Beispiel
- Projektkritische Sachen werden vorgeholt. Kann man zeitnah 100MB strukturierte Daten ins RAM hauen? Reicht die Bandbreite des Netzes? Reicht ein Server aus? Kann man das überhaupt automatisieren? Halt so Sachen, die am Ende dafür sorgen können, daß man statt des 31.08.03 erst am 01.01.06 abgeben kann, hihi.
- Einfache Sachen werden vorgeholt, denn die kann man im ersten Anlauf hinkriegen. Und man lernt dazu, sodaß die vormals schwierigen Sachen dann auf einmal einfach sind und auch auf Anhieb funzen.
- Unabhängige Sachen, die völlig unkritisch sind, werden nach hinten geschubst. Wer braucht schon Einstellungsdialoge oder Druckfunktionalität (überhaupt eine grafische Oberfläche)?
Aber das sind nur Beispiele. Jede Aufgabe ist anders. Normalerweise (edit: Nee, idealerweise) sind Oberfläche und Programmlogik einigermaßen getrennt, in verschiedenen Verzeichnissen, in verschiedenen Projekten(im Sinne der IDE). Da wächst dann die Logik BU und die Oberfläche TD.
-
Prof84 schrieb:
Immer steht man vor der Entscheidung ob man Buttom-Up arbeitet - bodenständig, taktisch[...]
Oder arbeiten wir Top-Down - visionär, strategischAm Anfang war Bottom-Up und Top-Down noch anders (richtig) rum. Vielleicht ist es nach weiteren 6 Edits wieder richtig
-
volkard schrieb:
Ich mache immer das zuerst das, was gerade ansteht, wobei fast immer die Lauffähigkeit des Programms erhalten bleibt.
Also eher die unstrukturierte, intuitive Vorgehensweise. Warum auch nicht? Jeder wie er am besten kann.
-
volkard schrieb:
Prof84 schrieb:
Und wie sogar selbst volkard endlich realisiert hat, ist das nicht nur ein Problem der SW Entwicklung, sondern ein grundsätzliches Problem der Menschen und hauptverantwortlich für die größten Probleme unserer Zeit.
Nein, davon nehme ich doch Abstand.
Es ist unter Umständen denkbar, daß es vielleicht möglicherweise ein Problem derer ist, die sich mangels Inhalten an leeren Strukturen festhalten wollen.Liebe Leser! Hiermit dementiere ich ganz offizell mein Statement zu volkards Sichtweise, denn wie zu ersehen habe ich Ihn ganz klar überschätzt!
volkard schrieb:
Bodenständig in der Softwareentwicklung ist aber TD. Konservativ ist auch TD. formalistisch ist auch TD. Lokale maxima suchend ist auch TD. Du solltest wissen, daß TD eine der Forderungen der Dokmatisten der Strukturierten Programmierung ist.
Prof84 schrieb:
Oder arbeiten wir Top-Down - visionär, startegisch, abstakt, lansam Resultate produzierend, bloatig, mit hohen Konfigurationsaufwand, progressiv, viele Veränderungen in Kauf nehmend, auf der Suche nach einem Maximum mit besonders hohen Fitnesswerten, so dass wir deren Bauelemente (Muster, Methoden, Prozesse, Systeme, Konzepte etc.) möglichst oft wiederverwenden können.
Startegisch kann beides sein. Abstakt zwar auch, aber TD tendiert gerne zu Angstlayern und damit mehr Abstaktion, oder? Langsamheit würde ich mit TD gar nicht in Verbindung bringen. Was war nochmal Rapid Prototyping? Progressiv? Ah, du meinst progressiv langsam.
Das ist doch nur noch gequirlte Kacke. - Kein Kommentar.
Bashar schrieb:
Prof84 schrieb:
Immer steht man vor der Entscheidung ob man Buttom-Up arbeitet - bodenständig, taktisch[...]
Oder arbeiten wir Top-Down - visionär, strategischAm Anfang war Bottom-Up und Top-Down noch anders (richtig) rum. Vielleicht ist es nach weiteren 6 Edits wieder richtig
Ja, das ist doch ein schönes Beispiel: Ich überlege mir abstrakt (TD), was ich scheiben will. Erstelle den Rohentwurf. Dann drücke ich den Absenden Button, weil ich noch anderes zu tunen habe und meine Existenzberechtigung nicht dadurch fröhne, die Versionenstände von Posts anderer Mitglieder zu kontrollieren und dann editiere ich meine Posts (BU), um formal mehr der Rechtschreibung zu genügen indem ich Fehler heraushole, kleine Zusätze einzufügen oder Sachen neu zu formulieren, um meinen Konzept mehr Reife und Fähigkeiten zu geben.
Insbesondere wenn man einen Kater hat und das erst die Runde 1 ist ...
-
Prof84 schrieb:
Gratuliere zum Aufstieg! - "Zweifel ist das Vorzimmer zur Erkenntnis." (indisches Sprichwort) - - Ich habe gerade in den letzten Jahren Tonnen von Folien erstellt, die sich genau mit diesen Thema beschäftigen. Mal abgesehen von den 15 Jahren Erfahrung als Consultant, Manager und System- und Prozessingieur :). Nur wenn Du Jahre deines Lebens "geopfert" hättest, um solche im doppelten Sinne 'globalen' System zu entwickeln und ca. 3.000 € Tagessatz dafür kassierst, würdest Du den Leuten das noch für Lau im Internet stecken?! Ja, tu's doch mal, so ein "Testpackage". Gibt's sogar kostenlos von L. Ron Hubbage/Scientology.
Ich vermute eher, daß Hausmeister- Prof Nullpeilung hoch Laberbacke gar keine Ahnung vom Programmieren hat - in welcher Sprache auch immer. Prozessingenieur" - ich lach' mich tot
Was suchst Du hier überhaupt - hast Du je irgendwem geholfen? Oder immer nur Hilfe gesucht? Oder immer nur das Quatschforum bedient
Du bist nichts, kannst nichts und bist den Beweis immer schuldig geblieben, daß es anders ist. :p
-
Prof84 schrieb:
Gratuliere zum Aufstieg! - "Zweifel ist das Vorzimmer zur Erkenntnis." (indisches Sprichwort) - -Meinst Du, die Fähigkeit oder Neigung zur Selbstreflektion ist sooo außergewöhnlich?
Prof84 schrieb:
Ich habe gerade in den letzten Jahren Tonnen von Folien erstellt, die sich genau mit diesen Thema beschäftigen. Mal abgesehen von den 15 Jahren Erfahrung als Consultant, Manager und System- und Prozessingieur :). Nur wenn Du Jahre deines Lebens "geopfert" hättest, um solche im doppelten Sinne 'globalen' System zu entwickeln und ca. 3.000 € Tagessatz dafür kassierst, würdest Du den Leuten das noch für Lau im Internet stecken?!
Ich weiß nicht. Meinst Du, das würde Deinen Wert für Unternehmen schmälern? Ich meine, hier sind ja nicht unbedingt viele Leute, die direkte Konkurrenten für Dich sind. Und ich denke auch nicht, dass ein Unternehmen auf Deine Dienste verzichtet, weil Leute hier etwas über diese Thematik lesen. Insofern würde es wohl eher darauf hinauslaufen, dass Du etwas verwertest, das bei Dir eh da ist, ohne dass dies negative Auswirkungen hat. Ist das nicht eh das, was die Leute in den ganzen Fachforen hier machen? Anderen einen Einblick in ihr Fachwissen zu ermöglichen?
EDIT: Ich finde es sehr interessant, dass es bei dieser Umfrage keinen wirklich klaren Trend zu geben scheint. Alle angegebenen Ansätze scheinen von irgendwelchen Leuten verfolgt zu werden. Auch die Verknüpfung von Top-Down Planung mit Bottom-Up Implementierung scheint ein interessanter Ansatz zu sein. Warum macht man das so? Ich meine, wenn ich etwas Top-Down plane, dann habe ich doch auch eine entsprechende Vorstellung vom Resultat und eigentlich würde ich dann davon ausgehen, dass ich intuitiv auch erst die grobe Struktur realisiere.
-
Gregor schrieb:
Auch die Verknüpfung von Top-Down Planung mit Bottom-Up Implementierung scheint ein interessanter Ansatz zu sein. Warum macht man das so?
Im Vordergrund stehen vorallem Rückkopplung zum Design/Konzept und relative schnelle Prototyp.
-
Gregor schrieb:
Ich finde es sehr interessant, dass es bei dieser Umfrage keinen wirklich klaren Trend zu geben scheint. Alle angegebenen Ansätze scheinen von irgendwelchen Leuten verfolgt zu werden. Auch die Verknüpfung von Top-Down Planung mit Bottom-Up Implementierung scheint ein interessanter Ansatz zu sein. Warum macht man das so? Ich meine, wenn ich etwas Top-Down plane, dann habe ich doch auch eine entsprechende Vorstellung vom Resultat und eigentlich würde ich dann davon ausgehen, dass ich intuitiv auch erst die grobe Struktur realisiere.
Bist Du nur Labertasche oder programmierst Du selber?
Topdown Ansatz ist OK, Bottom Up realisieren Praxis. TopDown realisieren heißt Dummies zu produzieren, die so tun, als ob sie so tum würden, wie Du denkst.
Tun die "echten" Funktionalitäten oft nicht, dabnei hast Du so einen wunderbaren Dummy gebastelt. Tut leid, aber bitte nochmal.Als naturfaules Stück fang' ich wirklich bei den kritischen Sachen an und schau' zu, sie in mein Schmierfetzen- Konzept zu integrieren.
-
Gregor schrieb:
Auch die Verknüpfung von Top-Down Planung mit Bottom-Up Implementierung scheint ein interessanter Ansatz zu sein.
Ich finde es nicht ungewöhnlich. Zuerst hat man noch ein grobes Bild vor Augen. Das wird dann während der Planungsphase immer klarer, verdichtet sich, Teilprobleme kristallisieren sich heraus, man fängt an das System in kleinere Einheiten zu zerlegen usw. Wenn dann der Punkt gekommen ist, es in Code zu giessen, beginnen wir sinnvollerweise bei den atomaren Bestandteilen. Woher bekomme ich sie? Muss ich sie selbst entwickeln? Wir können diese separat testen und bauen schliesslich unser Gesamtsystem daraus zusammen. Ich denke, nicht wenige arbeiten so oder so ähnlich.
An die anderen: Streitet euch doch nicht so. Das ist ja furchtbar!
-
Baba Yaga schrieb:
Gregor schrieb:
Auch die Verknüpfung von Top-Down Planung mit Bottom-Up Implementierung scheint ein interessanter Ansatz zu sein.
Ich finde es nicht ungewöhnlich. Zuerst hat man noch ein grobes Bild vor Augen. Das wird dann während der Planungsphase immer klarer, verdichtet sich, Teilprobleme kristallisieren sich heraus, man fängt an das System in kleinere Einheiten zu zerlegen usw. Wenn dann der Punkt gekommen ist, es in Code zu giessen, beginnen wir sinnvollerweise bei den atomaren Bestandteilen.
Das dachte ich heute mittag auch irgendwann. Aber ich bin mir da niht mehr so sicher. Ja, zuerst hat man ein grobes Bild vor Augen, Top-Down. Und dann plant man rum. Aber beim rumplanen schweife ich auch schnell ab in die Bestandteile und überlege rum, wie die in groben Zügen gehen, ob sie gehen, welche Ausweikungen sie haben, und fummle sie wieder in den Hauptplan ein. Ich schätze, Planen ist nur das grobe Vorwegnehmen des Ausprogrammierens und geschieht nicht notwendigerweise in einer anderen Reihenfolge.
Gregor kann programmieren. Das merkt man gleich, wenn man sich mal mit ihm zankt. Er kann viele treffsichere Argumente aufstellen und einen damit bombardieren.
-
volkard schrieb:
Das dachte ich heute mittag auch irgendwann. Aber ich bin mir da niht mehr so sicher. Ja, zuerst hat man ein grobes Bild vor Augen, Top-Down. Und dann plant man rum. Aber beim rumplanen schweife ich auch schnell ab in die Bestandteile und überlege rum, wie die in groben Zügen gehen, ob sie gehen, welche Ausweikungen sie haben, und fummle sie wieder in den Hauptplan ein. Ich schätze, Planen ist nur das grobe Vorwegnehmen des Ausprogrammierens und geschieht nicht notwendigerweise in einer anderen Reihenfolge.
Ja das stimmt. Gegenseitige Wechselwirkungen und Seiteneffekte sollten immer berücksichtigt werden. Ideal wärs, wenn man sie ausschliessen kann. Leider gelingt das nicht immer. Ein guter Programmierer sollte wenn möglich, wenn er an einen Modul arbeitet, auch das Gesamtkonzept oder einen grossen Teil davon im Kopf haben. Divide et impera ist theoretisch ein guter Ansatz, aber verliert viel von seiner Wirksamkeit, wenn man den Überblick verloren hat.
-
Baba Yaga schrieb:
Ja das stimmt. Gegenseitige Wechselwirkungen und Seiteneffekte sollten immer berücksichtigt werden. Ideal wärs, wenn man sie ausschliessen kann. Leider gelingt das nicht immer.
Hmm.
Baba Yaga schrieb:
Gegenseitige Wechselwirkungen und Seiteneffekte sollten immer berücksichtigt werden.
Sind es nicht die g.W.u.S, die das Planen erst ausmacht?
Ich meine, zum bloßen Runterplanen (rein-planlos nur mit Top-Down) kann ich auch einen Prof nehmen, der nie selber programmiert hat, nur wird das nix.
Was das Planen ausmacht, ist vielleicht, daß man am ersten Tag aus den unzähligen Planungsmöglichkeiten bereits welche ausschließen kann, die einem ein drei Monaten erst das Knie brechen, weil Modul X und Modul Y nicht harmonieren. Oder noch besser von den noch guten Möglichkeiten sieht man eine, daß nach sechs Monaten abkacken wird, weil die Engine es einfach nicht hergeben wird, daß man zufriedenstellend foo und bar machen kann.Was waren denn meine weitsichtigtsen Entscheidungen? Mhhm. Eigentlich immer welche, wo ich das Modul schon recht detailgenau durchüberlegt habe und es paßte einfach nicht zum ganzen Rest. Da geht fühlt man sich dann ganz schlecht. Und bald geht die Warnlampe an und dann hat man auch schnell den technischen Nachweis, daß da dir Kacke am dampfen ist (wobei der Nachweis auch falsch sein kann, weil man ein supi dupi passendes Entwurfsmuster einfach nicht kennt).
-
pointercrash() schrieb:
Gregor schrieb:
Ich finde es sehr interessant, dass es bei dieser Umfrage keinen wirklich klaren Trend zu geben scheint. Alle angegebenen Ansätze scheinen von irgendwelchen Leuten verfolgt zu werden. Auch die Verknüpfung von Top-Down Planung mit Bottom-Up Implementierung scheint ein interessanter Ansatz zu sein. Warum macht man das so? Ich meine, wenn ich etwas Top-Down plane, dann habe ich doch auch eine entsprechende Vorstellung vom Resultat und eigentlich würde ich dann davon ausgehen, dass ich intuitiv auch erst die grobe Struktur realisiere.
Bist Du nur Labertasche oder programmierst Du selber?
volkard schrieb:
Gregor kann programmieren. Das merkt man gleich, wenn man sich mal mit ihm zankt. Er kann viele treffsichere Argumente aufstellen und einen damit bombardieren.
@volkard: Danke!
...aber eigentlich programmiere ich recht wenig. Ich habe in letzter Zeit zwar ein paar tausend Zeilen Code in den Rechner gehackt, aber offensichtlich habe ich immer noch keine wirkliche Systematik beim Programmieren entwickelt. Sonst würde ich solche Fragen, wie ich sie hier stelle, nicht stellen. Außerdem habe ich in letzter Zeit gemerkt, dass mir das Programmieren bei etwas komplizierteren Dingen doch recht schwer fällt und, dass ich viele Fehler mache. Ich habe letztens zum Beispiel den Ball Pivoting Algorithmus zur Oberflächenrekonstruktion zu implementieren. Es hat glaube ich gut 10 Tage gedauert, bis ich den halbwegs fehlerfrei hingekriegt hatte. Deshalb überlege ich, was ich beim Programmieren wohl falsch mache und wie ich gezielter an die Sache herangehen kann. So, dass schnell guter Code herauskommt und ich komplizierte Codeteile bei der Programmierung besser beherrschen kann.
@pointercrash(): Wie gesagt: Ich habe diesen Thread eröffnet, weil ich da bei mir ein vermutlich suboptimales Vorgehen bei der Programmierung festgestellt habe. Ich habe mir auch noch keine wirklich tiefgehenden Gedanken bezüglich des Themas dieses Threads gemacht. Die Antworten, die es in diesem Thread gab, waren für mich aber sehr interessant und ich finde, als Threadersteller muss man so etwas auch irgendwo zum Ausdruck bringen. Und wenn mehrfach ein bestimmter Ansatz genannt wird, der mich etwas überrascht, dann sag ich auch, was mich bezüglich dieses Ansatzes wundert. In dem Zusammenhang verstehe ich zumindest nicht, was das mit "labern" zu tun hat.
Naja, ich hoffe, es kommen noch viele weitere interessante Beiträge zum Thema dieses Threads. Gibt es diesbezüglich eigentlich hilfreiche Literatur?
-
Gregor schrieb:
Ich habe letztens zum Beispiel den Ball Pivoting Algorithmus zur Oberflächenrekonstruktion zu implementieren. Es hat glaube ich gut 10 Tage gedauert, bis ich den halbwegs fehlerfrei hingekriegt hatte. Deshalb überlege ich, was ich beim Programmieren wohl falsch mache und wie ich gezielter an die Sache herangehen kann. So, dass schnell guter Code herauskommt und ich komplizierte Codeteile bei der Programmierung besser beherrschen kann.
Ich habe jetzt nicht so den Eindruck, daß 10 Tage dafür grottenlangsam wären. Mein erster Baum hat viel länger gedauert, aber gut, da war ich kackboon. Meine erste Welt mit dynamischem LOD hat so lange gedauert, das sage ich mal besser nicht, diese verkackte Bäume wiedermal haben sich dauernd so dumm zusammengefaltet, daß Lücken sichtbar waren. Es könnte sein, daß ich allein zum Rollen des Raumschiffs länger gebraucht habe, als 10 Tage.
Vielleicht solltest Du mehr Gamecoders-Foren lesen. Das gibt immer wieder Auftrieb. In Sachen Suche nach Strukturiertheit glaube ich fest daran, daß Du im falschen Loch bohrst. Aber bohr weiter, so tief du kommst, und berichte!
-
volkard schrieb:
In Sachen Suche nach Strukturiertheit glaube ich fest daran, daß Du im falschen Loch bohrst.
Welches Loch hältst Du denn für besser?