KT AlephAlpha erfüllt seinen Traum: KT – The Game. Heute: "Teil 2: Das Konzept - 1. Akt"

schreibt doch nen Java Game kann man dann Plattformunabhänig zocken und ich denke du wirst jetzt nicht die grafikbombe wie Crysis hinzaubern deswegen sollte das ja auch gut machbar sein.

Über meine Intention mit diesem Projekt habe ich eigentlich in den vorangehenden Beiträgen schon genug gesprochen, deswegen konzentriere ich mich jetzt auf die Tools, mit denen ich arbeiten werde.


1. Versionsmanagement

Wenn man schon mal an einem längeren Dokument gearbeitet hat, kennt man vielleicht das folgende Problem: Man hat vor Tagen / Wochen einen Abschnitt völlig umgeschrieben oder sogar gelöscht, nur um im Nachhinein zu der Ansicht zu kommen, die alte Version war im Vergleich zur neuen doch ganz gut.
Bei Software-Projekten verhält es sich nicht anders: oft spielt man so lange mit dem existierenden Code herum, bis nichts mehr funktioniert. Dass der Code auf dutzende Dateien verteilt und mehrere tausend Zeilen lang ist, macht es nicht besser.
Hier kommt das Versionsmanagement ins Spiel.
Mit Hilfe von Revisionen – so etwas wie Backups - ist es möglich, Dateien oder auch nur einzelne Codeausschnitte wieder auf eine alte Version zurückzusetzen, verschiedene Versionen zu vergleichen oder Versionen zusammenzufügen. Der Benutzer hat dabei volle Kontrolle, welche Dateien eines Projekts der Versionskontrolle unterliegen sollen und wie oft eine neue Revision erstellt werden soll.
Wenn man schon mal an einem größeren Projekt, vielleicht auch mit mehreren Leuten, gearbeitet hat, wird ein Programm zum Versionsmanagement schnell unverzichtbar.

Für mein Spieleprojekt habe ich mich für das Tool „Mercurial“ entschieden. Als Einzelkämpfer ist für mich die Art des Versionsmanagement-Tools mehr oder weniger egal, solange ich mich damit wohl fühle. Ich hätte genauso gut zu „Subversion“ oder „git“ greifen können.


2. Software-Entwurf

Man kann sich nicht einfach dazu entschließen, ein Software-Projekt zu starten, sich hinsetzen und anfangen Code zu schreiben. Das geht vielleicht noch bei ganz einfachen Programmen oder wenn man eine bestimmte Art von Programm schon öfter geschrieben hat und keine große Neuorganisation des Codes vorsieht.
Da ich aber nun mal bei null beginne und mich auch nicht mit x Jahren Erfahrung bei der Spieleprogrammierung brüsten kann, muss ich meinen Code sorgfältig planen.
Die Struktur, der man seinen Code unterwirft, wird maßgeblich vom Programmierparadigma bestimmt, dem man sich (auch mit der Wahl der Programmiersprache) verschreibt, etwa dem Paradigma der prozeduralen Programmierung, der aspektorientierten Programmierung oder der objektorientierten Programmierung, nach welchem ich arbeiten werde.
Ich werde auf das Thema Softwareentwurf in einem zukünftigen Beitrag noch näher eingehen, deswegen sei hier nur gesagt, dass die objektorientierte Programmierung verlangt, das Programm in mehrere, interagierende und kommunizierende Teile zu zerlegen. Würde man das in reiner Textform bewerkstelligen, verlöre man schnell den Überblick, da die Querverweise zahlreich und kompliziert sind. Deswegen gibt es eine Reihe von standardisierten Diagrammen, sogenannte UML-Diagramme, die einem das Leben erleichtern.
Da ich alleine Arbeite, habe ich freie Hand, wie viel Zeit und Arbeit ich in die Diagramme stecke. Bis zu einem gewissen Grad kann man sagen, dass die Implementierung umso schneller vonstattengeht, je mehr Zeit man mit der Planung verbringt. Ich möchte es bei einem vernünftigen Maß belassen und werde mich auf ein Klassendiagramm – dort sieht man die einzelnen Elemente des Programms und wie sie zusammenhängen- und einige Sequenzdiagramme – beschreibt die Kommunikation zwischen den Elementen anhand von Fallbeispielen - beschränken.

Ein ganz schönes Freeware-Tool, um diese Aufgabe zu bewältigen, ist StarUML. Das ist vergleichsweise komfortabel zu bedienen und die Diagramme sehen schön aus.
Viele UML-Programme bieten auch die Möglichkeit, aus dem Diagramm gleich ein Codegerüst zu erstellen. Ich bin jedoch aus mehreren Gründen kein Freund davon und werde davon nicht Gebrauch machen.



3. Programmiersprache

Die Wahl der Programmiersprache, ein leidiges Thema. Manchmal habe ich den Eindruck, die Frage nach der bevorzugten Programmiersprache ist die Gretchenfrage für Programmierer. Da wird von Dingen wie „Mächtigkeit“ einer Programmiersprache und ähnlichen sinnfreien Dingen gesprochen, vergleichbar mit dem teils absurd geführten Konsolenkrieg alter Tage.
Ich bin ein großer Freund von Programmiersprachen mit hohem Abstraktionsgrad, das heißt, ich will mich nicht mehr als nötig mit Hardware-Details, Speichermanagement oder Speicheradressierung herumschlagen müssen. Ich habe während des Studiums viel Java gelernt, eine Sprache die meiner Meinung nach schön strukturiert, für vieles gedacht, aber zu nichts zu gebrauchen ist.
C#, das von Microsoft entwickelte Konkurrenzprodukt, habe ich schon einmal für eine kleine Anwendung für ein Telekommunikationsunternehmen verwendet und war sehr angetan. Die Struktur ist gut wie bei Java, aber im Gegensatz zu Suns Sprache wissen auch die Endprodukte zu überzeugen. C# ist die Sprache meiner Wahl für dieses Projekt.


4. Entwicklungsumgebung

Die Wahl der Entwicklungsumgebung ist für so manchen ähnlich heikel wie die der Programmiersprache. Für jedermann ist etwas geboten: Die absoluten Nerds verwenden Texteditoren wie Emacs oder vi in Verbindung mit Kommandozeilen-Befehlen, andere hätten gerne eine leicht zu bedienende, übersichtliche Oberfläche und wieder andere möchten das volle Programm, eine mit allerlei Tools vollgestopfte Entwicklungs-Suite bei der schon die Flut an Buttons, Statusleisten, Kontextmenüs und Optionen ein leichtes Gefühl der Beschränktheit des menschlichen Geistes hervorrufen kann.
Ich persönlich bevorzuge die übersichtliche Variante mit Tendenz zur Suite. Emacs und vi sind ohne Zweifel fantastische Editoren, deren Bedienung aber monatelanges Training voraussetzt, worauf ich nicht wirklich Lust habe. Entwicklungs-Suiten sind andererseits meist sehr teuer, aufwändig zu konfigurieren oder für mich manchmal schlicht zu unübersichtlich, zumal ich auch von 90% der angebotenen Funktionen selten bis nie Gebrauch mache.
Ich werde deshalb vorerst mit Visual Studio Express 2010 arbeiten, welches ich in diesem Projekt auch zum ersten Mal benutze. Dort habe ich die für mich wichtigsten Funktionen vereint:

• Projekt-Browser. Zeigt die Dateien an, die zum Projekt gehören.
• schnelles Kompilieren. übersetzt den Programmcode in eine Ausführbare Datei.
• Syntax-Highlighting. Unterlegt bestimmte Teile des Codes farbig, um ihn besser lesbar zu machen.
• Auto-Vervollständigung. Ganz wichtig, wenn man nicht wirklich jede Funktion beim Namen kennen will.
• Debugger. Hilft beim Auffinden von Fehlern im Code.

Ich denke, damit bin ich gerüstet, um meinen Entwurf auch in Code umsetzen zu können. Zu meinen Zeiten als Student hatte ich noch Zugriff auf eine Vollversion von Visual Studio 2008. Das war eigentlich auch sehr schön, als Hobbyentwickler kann ich mir das aber jetzt nicht mehr leisten.




5. Libraries

Ich will mein Spiel selbst programmieren. Ich will keine Baukasten à la RPG Maker benutzen, sondern von Grund auf alles selber machen. Andererseits möchte ich mir das Leben auch nicht unnötig schwer machen. Um das zu vermeiden, greife ich, wie jeder andere Programmierer auch, auf existierende Bibliotheken und Frameworks zurück.
Dabei handelt es sich um Sammlungen von Funktionen, Datenstrukturen und Schnittstellen, für die sich schlaue Leute lange den Kopf zerbrochen haben, um Lösungen zu Problemen bereit zu stellen, vor denen Programmierer immer wieder stehen. Darunter fallen etwa Dinge wie die Kommunikation mit der Hardware, Netzwerkunterstützung, parallele Programmierung oder schnelle Arithmetik. Wollte man das alles selber schreiben, stünde man vor einer Lebensaufgabe und am Ende wäre das Ergebnis meist doch schlechter als wenn man gleich die vorhandenen Bibliotheken genutzt hätte.
Für dieses Projekt greife ich auf das .Net- und das XNA-Framework zurück.
Die .Net-Library ist sehr umfangreich und stellt sozusagen das grundlegende Arbeitsmaterial für alle Arten von Projekten bereit. Ob man nun mit Zeichenketten (also Text), Dateien oder Datenbanken zu tun hat, es ist immer toll, eine so gut sortierte und umfangreiche Library zur Verfügung zu haben.
Erweitert wird es durch das XNA-Framework, welches speziell auf die Entwicklung von Spielen zugeschnitten ist. Geboten sind hier unter anderem die Integration von sehr vielen Medien-Formaten, wie etwa JPG, PNG, WAV etc., Implementierungen von Operationen der Linearen Algebra (Matrix- und Vektor-Multiplikation) und weitere mathematische Hilfsmittel wie Kurveninterpolation.


6. Weitere Tools

Neben den eben beschriebenen Hilfsmitteln verwende ich Programme für speziellere Einsatzgebiete, wie etwa Mathematica, und auch noch Programme und Helferlein, die wohl fast jedem bekannt sind und deshalb keiner größeren Erklärung bedürfen, unter anderem: Paint, Word, Notepad, sowie Zettel und Stift.
Gerade ohne die beiden letztgenannten wäre mein Projekt tot, noch bevor es überhaupt geboren worden wäre.


So, das war also der erste Teil. Ich hoffe, es war für euch einigermaßen interessant zu lesen und freue mich über Verbesserungsvorschläge für zukünftige Einträge aber auch über Kommentare zum Gesagten.

Feine Sache Würde mich gern anbieten dich bei Sounds und Musik zu unterstützen. Sag mir was du brauchst und ich schau ob ich dir evtl weiterhelfen kann.

AlphaAlpha: das ist ja richtig arbeit... Mensch, ich hoffe du behälst deinen spass daran und verzweifelst an einen bestimmten Punkt nicht. Viel Erfolgt bei deinem Projekt, das ganze KT bleibt dran und schaut neugierig zu. =)

wielang wird das ca dauern bis du uns etwas grafischen präsentieren kannst ? scheint bis zu dem pkt ja noch einiges an aufwand zu sein

Versteh nur nicht ganz die Einzelkämpferposition. Wenn das so viel Arbeit ist, warum dann nicht ein Team bilden?

Liest sich super

Urgs schrieb:

Versteh nur nicht ganz die Einzelkämpferposition. Wenn das so viel Arbeit ist, warum dann nicht ein Team bilden?

Zum Vergrößern anklicken....

Wahrscheinlich weils sein Traum ist und er das alleine schultern will. Kann ich bei sowas verstehen, dass er da nix abgeben will.
Viel Arbeit bedeutet ja nicht unbedingt, dass es keinen Spaß macht. Es gibt ja auch erfüllende Arbeit.

Tolles Update
Finde das ganze richtig spannend und lege schon mal Punkte bereit für den XBLIG Release
Falls du bei deinem Contra/Gunstar Heroes Konzept bleibst, noch eine kurze Anregung zum Gameplay...
Mach bitte nicht den Fehler wie Twisted Pixel mit Comic Jumper, dass die Standardgegner viel zu viel Gesundheit haben und man ewig auf die ballern muss - das war total ermüdend und lahm. Spannender sind mehr aber dafür schwächere Gegner.

C# ist die Sprache meiner Wahl für dieses Projekt.

Zum Vergrößern anklicken....

Da du offensichtlich Ahnung von dem Ganzen hast, wirst du wahrscheinlich kein Kursbuch zu C# benötigen, aber falls du oder jemand anderes hier sich dafür interessieren sollte, kann ich das C# Yellow Book von Rob Miles empfehlen. Die neueste Version (2010) gibt es auch wieder kostenlos im Netz - einfach mal googeln.

Scheint gleichzeitig eine Art Tutorial für Softwareprogrammierung zu sein. Weiter so.

Ich bin wirklich mal gespannt. Das mit dem Tut-Charakter bislang finde ich auch toll !

AlephAlpha schrieb:

Es kann aber auch ganz anders laufen, und das Spiel erscheint nächstes Jahr für Xbox Live Arcade .

Zum Vergrößern anklicken....

Wenn es zumindest bei den xBox Indie Games landet, wäre das schon genial.


Viel Spaß und viel Glück.

Need Update ....

Ich denke, Ende dieser Woche werde ich wieder etwas schreiben.
Real Life hatte mich in den letzten beiden Wochen ziemlich eingespannt, aber ich hab ja auch keinen Stress mit dem Projekt.

du könntest ja auch irgendein strategiegame programmieren
siehe etliche ps3 und xbox games
oder online games wie grepolis

So, weiter geht's.
Zunächst einmal möchte ich mich für die Verzögerung des Artikels entschuldigen. Allerdings ist die Erstellung des Spielkonzepts für mich die wichtigste Phase des Projekts und ich möchte hier nichts überstürzen und mir ganz genau überlegen, wie das Spiel am Ende aussehen soll. Deswegen wird die das Konzept auch in mehreren Teilen vorgestellt. Es gibt viel zu schreiben.
Bevor ich beginne, möchte ich auch noch auf einige Anmerkungen hier im Thread eingehen:

• Vielen Dank für alle, die mir Unterstützung zugesagt haben. Ich werde mit ziemlicher Sicherheit darauf zurückgreifen und freue mich schon auf eine Zusammenarbeit.

• Es wird sicher noch etwas dauern, bis ich graphische Ergebnisse vorweisen kann. Wenn aber mal die eigentliche Programmierung begonnen hat, sollte relativ bald etwas kommen. Das darf man sich aber nicht so vorstellen, wie Videos / Bilder von irgendwelchen Alpha-Versionen von kommerziellen Projekten. Das ganze wird viel Experimenteller und grundlegender aussehen und damit – so hoffe ich – auch interessanter für euch.

• Aus mehreren Gründen verwirkliche ich das Projekt zu großen Teilen alleine. Ich habe gelernt, dass Teamarbeit über das Internet sehr problematisch ist, wenn das Projekt eine gewisse Komplexität erreicht. Im Internet gibt es oft Probleme mit Hierarchien zwischen den Beteiligten, viel zu oft Streitereien oder einfach nur verschiedene Auffassungen, in welcher Intensität an dem Projekt gearbeitet werden soll. Den ganzen Stress möchte ich mir Ersparen. Ein zweiter Punkt ist, dass , wie ja schon angesprochen wurde, es sich hier um meinen Traum handelt, bei dem ich mir ungern von anderen reinreden lassen möchte

• Strategiespiele sind nicht mein Genre. Das würde erst einmal enorme Einarbeitungszeit bedeuten. Ganz davon abgesehen, brauchen Strategiespiele oft eine ganze Horde an Testern, um wirklich ausbalanciert zu sein. Diese steht mir aber nicht zur Verfügung.
Genug davon, konzentrieren wir uns auf:

Das Spielkonzept – Die kritischste Phase (Teil 1)

Als Spieler weiß man es immer besser. Teils ungläubig wird man Zeuge von Gameplay-Design Fehlern, die einem so offenkundig und ungeschönt ins Auge stechen, dass man zu dem Schluss kommen könnte, die Macher spielten ihre eigenen Machwerke nicht.

Mir geht es genauso. Bei manchen Blockbustern sitze ich nur Kopfschüttelnd vor dem Bildschirm. Jetzt stehe ich auf der anderen Seite: Ich möchte ein Konzept entwerfen, dass dem Spieler Spaß macht. Und plötzlich sieht man, wie schwierig diese Aufgabe eigentlich ist, wenn man einen gewissen Grad an Komplexität mit einbringen möchte, d.h. das Spiel gehaltvoller als ein Flash-Game machen will. Es ist für mich die vermutlich kritischste Phase in meinem Projekt. Hier werden die Weichen gestellt, die bestimmen, ob mein Spiel am Ende Spaß macht oder nicht - ob sich die Spieler über das Spiel ärgern und abschalten, oder ob sie sich über ein eigenverschuldetes Ableben der Spielfigur ärgern und es voller Ehrgeiz immer und immer wieder versuchen Ich möchte anhand einer Beschreibung meines bisherigen Vorgehens versuchen, zu schildern, vor welchen Problemen ich stand und auch noch stehe.

Zunächst geht es darum, sich für ein Genre zu entscheiden. Wie in jedem passioniertem Spieler schlummern auch in mir Ideen für unzählige faszinierende Szenarien – Abenteuer Homer‘schen (der Dichter, nicht der User) Ausmaßes, für Adventures, Action-Adventures, Rollenspiele, First Person Shooter oder auch Ideen für Spiele, die in kein Genre so richtig passen. Aber das ist als Hobbyprojekt einfach nicht durchzuführen. Ich muss darauf achten, dass sich der Aufwand für Story, Grafik und Sound in einem vernünftigen Rahmen halten. Für mich war es deshalb nur logisch, an einem 2D-Shooter zu arbeiten. Ich liebe das Genre und schon oft genug wurde bewiesen, dass auch mit geringen Mitteln großartige Spiele entstehen können. 2D Run & Guns sind fantastisch. Jedoch, so habe ich den Eindruck, hat sich da seit den 90ern auch nicht mehr viel getan. Das Genre ist also geradezu perfekt für einen eingebildeten und ambitionierten Hobby-Designer wie mich.

So habe ich mich also für ein Genre entscheiden. Der nächste Schritt ist nun, heruauszuarbeiten, was an einem solchen Spiel Spaß macht. Nur wenn ich das verstehe, kann ich versuchen darauf aufzubauen. Diese Punkte scheinen mir persönlich für den Spielspaß besonders wichtig:

• Der Spieler als Herrscher des Chaos. Weniges ist bei Action-Spielen befriedigender, als das gegnerische Heer als One-Man-Army ins Chaos zu stürzen, dabei aber stets das Gefühl der absoluten Kontrolle zu haben. Diese Momente möchte ich in mein Spiel bringen.

• Die Möglichkeit der steten Verbesserung. In allen Action-Spielen hat die Spielfigur ein festgelegtes Repertoire an Handlungsmöglichkeiten. Leider geht der Trend immer mehr dazu, diese Aktionen relativ unflexibel und für eng eingegrenzte Einsatzgebiete zu designen. Das möchte ich nicht. Ich will, dass der Spieler die Freiheit hat, die Aktionen nach seinen Vorlieben kombinieren zu können und auch nach mehreren Durchgängen noch Raum für Verbesserungen seiner Technik erkennen kann.

• Das Gefühl der Durchschlagskraft. Für diesen Punkt ziehe ich ein Negativbeispiel heran: Das Spiel MicroBot (ich empfehle, Videos dazu anzusehen, es sieht nämlich fantastisch aus) hat ein super Setting, welches auch noch hervorragend umgesetzt ist. Das ist so lange ansprechend, bis man auf das Gameplay stößt. Hauptkritikpunkt ist das Gefühl, den Gegnern kein wirkungsvolles Arsenal entgegensetzen zu können – Schussrate und Schadenshöhe sind einfach zu gering. In meinem Spiel möchte ich, dass der Spieler das Gefühl hat, mit seiner Feuerkraft ganze Landstriche dem Erdboden gleich machen zu können. Ich möchte dies mit einer hohen Schussfrequenz, grafisch effektreichen Projektilen, vielen Explosionen und einer großen Bandbreite an Nehmerqualitäten der Gegner erreichen.

• Geschwindigkeit. Das Hauptaugenmerk bei einem Action Spiel liegt bei mir immer noch auf der Action. Die wird am besten vermittelt, wenn die Spielgeschwindigkeit relativ hoch gehalten wird. Mir ist aufgefallen, dass das bei Run & Gun Spielen eher selten der Fall ist. Dementsprechend versuche ich hier, einen anderen Weg als viele Entwickler einzuschlagen.

• Unmittelbare Bewertung der Spieler-Aktionen. Es muss Klarheit darüber herrschen, welche Aktionen dem Spieler helfen und welche ihm schaden. Es ist wichtig, dass diese Bewertung unmittelbar erfolgt, so dass der Lerneffekt für den Spieler so schnell wie möglich eintritt und er in Zukunft intuitiv schlechte Aktionen vermeidet und gute Aktionen herbeiführt.

• Klares Fehler-Feedback. Macht der Spieler einen Fehler, so muss klar werden, worin dieser Fehler bestand. Es muss z.B. bei einem Ableben der Spielfigur deutlich werden, wodurch es herbeigeführt wurde, etwa durch die Berührung eines gegnerischen Projektils oder durch die Berührung schädlicher Hindernisse (z.B. Lava)

• Minimaler Aufwand bei der Steuerung bei gleichzeitig nötiger haptischer Bestätigung. Die grundlegenden Regeln eines Shooters sind einfach: Hier sind die Gegner, mach sie platt. Ebenso einfach sollte auch die Steuerung sein. Abstrakt betrachtet kann ein Shooter teilweise auch als Reaktionstest gesehen werden. Wenn ich aber erst überlegen oder lange trainieren muss, um zu wissen, welche Taste welche Aktion bewirkt, so läuft das gegen das Naturell des Spiels. Allerdings darf die Steuerung auch nicht zu einfach gestaltet werden. In den meisten 2D-Shootern schießt man ununterbrochen. Man könnte also die Spielfigur einfach automatisch - ohne Knopfdruck - schießen lassen. Trotzdem wird das aus einem guten Grund nicht gemacht: Der Spieler muss wissen, dass er derjenige ist, der die Aktionen vollbringt. Dies entsteht durch den Knopfdruck., welcher die haptische Bestätigung der Aktion des Spielers bietet. Der Einfluss der Haptik wird von Spielern oft unterschätzt, ist aber beim Spieldesign ein wichtiger Einflussfaktor. Wer den Schuss Knopf bei Action-Spielen umso fester drückt, je intensiver das Spielgeschehen auf dem Bildschirm ist, wird wissen, was ich meine.

Das kann man nun so feststellen, genauso sehen oder anzweifeln und andere Kriterien als wichtig bewerten. Wenn man als Designer aber einen gewissen Satz an derartigen Regeln als gültig ansieht, steht man vor der elementaren Herausforderung des Spiele-Designs, die den gesamten Prozess auch zu einer Kunst erhebt: Es gilt, ein Spielekonzept aufzustellen, welches die oben genannten Punkte so gut wie möglich umsetzt. Es müssen alle Details des Spiels herausgearbeitet werden: Von offensichtlichen Dingen wie dem Aktionsrepertoire der Spielfigur, den vorhandenen Waffen oder der Gegnerarten, bis zu oft unbeachteten Dingen wie der Entfernung der Kamera zum Spielgeschehen, dem Grad der Beschleunigung und dem Bremsverhalten der Spielfigur, der Farbgebung von Hintergründen und Projektilen oder der Entscheidung, wie weit die Spielregeln an bestimmten Punkten im Spiel abgeändert werden dürfen, um Abwechslung zu bieten, den Spieler aber nicht zu stark vom bisherigen Spielablauf zu entfremden.

Damit beschließe ich für heute meine ersten Ausführungen zum Spielkonzept. Im nächsten Update werde ich dann wohl den Pfad der allgemein gehaltenen Ausführungen verlassen und näher auf das von mir erstellte Konzept eingehen. Wie immer freue ich mich über Feedback und Anregungen.

Apropos: Mir ist noch nicht ganz klar, ob ich den Thread hier in diesem Stil weiterführe – wenige, aber lange Updates – oder ob ich kürzere Beiträge poste, die dafür dann aber häufiger erscheinen. Was ist euch lieber?

Erstmal, danke für das klasse Posting!

AlephAlpha schrieb:

Was ist euch lieber?

Zum Vergrößern anklicken....

In einem anderen Forum, indem jemand sein gigantisches Heimkino-Projekt als Thread-Tagebuch präsentiert hat, fand ich seine "Zwitterform" super.

Er hat immer wieder mit kürzeren Beiträgen die Leserschaft am laufenden gehalten, und zusätzlich immer wieder umfangreichere "Learnings", wie er es nannte, gepostet. Darin hat er seine Erfahrungen und neu gewonnenes Wissen nochmal als Quintessenz sozusagen, aufgearbeitet.

Klasse Update

Häufigere, dafür kürzere Postings fände ich auch besser, da man dann besser 'folgen' kann.
Spielt aber keine grosse Rolle.

sehr interessant zu sehen, was du dir da gedanklich bisher aufgebaut hast

bin schon sehr gespannt wie das dann im Konkreten alles geplant wird


P.S.: bin auch eher der Freund der kürzeren Wasserstandsmeldungen anstatt langer Wochenberichte. Da brauchst du dir imo auch keine Sorge machen, dass das Protokollieren dadurch qualitativ weniger wertvoll wäre.

produktionsstop ?