Team

[zatzen]

Hallo!

Einfach mal ungeachtet eurer Haltung zur Teamarbeit hier ein Thread dazu.


Mir ist wohl klar, dass es viele Programmierer gibt, die gerne alles selbst machen.


Aber ich bin keiner solcher mehr.

Meine einzige Chance, nochmal DOS-mäßig kreativ zu werden sehe ich in der Teamarbeit.


Es macht dabei aber keinen Sinn, wenn mehrere Leute an dem Code arbeiten.
Allenfalls vielleicht die Abspaltung für schnelle z.B. Grafikroutinen in ASM.


Ich würde die Teamarbeit sinnvollerweise so gliedern:

- Coder (max. 2 siehe oben)
- Grafik (eventuell getrennt in Hintergrund / Sprites)
- SFX und Musik (da auch evtl. getrennt Geräusche, Sprache und Musik, aber
es sollte letztlich einer Qualitätskontrolle durch eine Person durchlaufen)
- Leveldesign oder, je nach Spiel, Script und Handlung
- letzter Punkt der mir (und typischerweise mir) einfällt:
Entwicklung optimierter Dateiformate für Grafik und Sound

Ich erinnere ich nun, was die Haupteinwände waren, die gegen Teamarbeit sprachen:

Die Unzuverlässigkeit der Teilnehmer. Diese würden angeblich nach 2 Wochen einfach vom
Projekt abspringen, oder von vornherein nicht ernsthaft bei der Sache sein.

Für mich wäre Arbeit im Team allerdings die einzige Bedingung unter der ich heute
noch in DOS kreativ tätig werden möchte. Ich bin nämlich:
- kein guter bzw. ausdauernder Grafiker
- ein mittelmäßiger Coder
- aber ein versierter (Tracker-)Musiker mit langjährig gebildetem Gehör, was auch
für SFX hilfreich ist
- ein begeisterter Entwickler von angepassten und optimierten internen Dateiformaten

Ich würde also in einem Projekt gern Musik machen und für die internen Dateiformate sorgen.
Dabei würde für mich für die Converter genug Programmierarbeit anfallen, so dass ich dahingehend
auch genug Spass habe...

Wenn ich alles alleine mache wären nur so wirklich kleine Spielchen möglich mit ziemlich
bescheidener Grafik, und mit der Gefahr, dass das ganze dann doch liegen bleibt, weil
es mich überfordert.

Aber es müsste doch möglich sein gemeinsam was auf die Beine zu stellen.
Ich denke bei allen Profis gibt es auch wenigstens eine Trennung
von Code, Grafik und Musik.

Ich kann mich gut erinnern wie das bei mir mit dem Programmieren immer war.
Man könnte sich viel besser aufs Programmieren konzentrieren wenn man sich
nicht auch noch um die Grafik kümmern muss, und umgekehrt.

Natürlich ist die Frage, wie man Vertrauen gewinnen kann, dass die
engagierten Leute bei der Stange bleiben.


Aber schreibt mal was ihr denkt...


Grüße,

Zatzen

[zatzen]

Vielleicht gibt es erfahrungsgemäß auch Vetrauenprobleme in bestimmten Bereichen.


Mal angenommen man traut dem Grafiker nicht, dann könnte man evtl. die Bedingung
stellen, dass er erst alle Grafiken fertig haben soll, bevor überhaupt der Coder anfängt,
diese zum Leben zu erwecken.

Und Sound: Falls ich den später übernehmen sollte kann ich euch schwören dass ich
euch da nicht hängen lasse. Es ist teil meiner Lebenträume, für ein Spiel Musik zu machen!

Andererseits - wenn ich da keine Persönlichkeit reinbringen darf, eben weils Teamarbeit
ist... Dann schwindet auch die Faszination zum Musik machen wieder...

Dann lieber eigenes kleines Spielchen ohne Team

[Brueggi]

Ich weiss ja nicht, an welche Art von Spiel Du denkst, aber ich glaube fast, ein großes Spiel lässt sich heute nicht mehr auf die Beine stellen. In der Regel verbringt man ca. 80% der Zeit mit dem Brötchen-Verdienen, dann gibt es noch ein Leben außerhalb von DOS (oder allgemein ohne PC) - und den letzten Rest verbringe ich dann z. B. damit meine bisherigen Programme weiter auszubauen.

Mich würde es auch in den Fingern jucken, z. B. meine Adventure-Engine vom Amiga zum PC zu portieren. Aber ich habe nicht wirklich die Zeit dazu. Wenn Du kreativ sein willst, dann sei es - aber ich würde es nicht abhängig von anderen Leuten machen. Da hab ich schon Pferde kotzen sehen, was Teamwork angeht... Vorallem dürfte es weitaus schwieriger sein, Publikum bei der Stange zu halten - da müssen möglichst schnell Resultate gezeigt werden. Und wehe dem, es ist nicht bei 24 Bit Farbtiefe und Ultra-High-Resolution.

[zatzen]

Ich gebs auch dran was im Team zu machen. Werde was mit bescheidener Grafik
machen und mich als Soundmensch kräftig austoben.
Meine Spielidee sollte was für zwei Spieler sein, Jump&Run,
aber die "Gegner" sollen keine Gefahren darstellen sondern
vor den Spielern weglaufen, und das Ziel ist dann diese
in Fallen zu drängeln. Für diese Gegner könnte ich einfach
Figuren aus NES Klassikern nehmen, dann wird das ganz
auch ein wenig interessanter.
Meine Frage wäre nur, wie time ich das ganze. Soll ne vernünftige
Framerate bekommen, die aber dann auch fest, anderes würde mir
über den Kopf steigen. Vielleicht den Timer umlenken.
Ich mach dazu aber noch eben nen Thread auf.

[DOSferatu]

Naja, wie ich vielleicht schon erwähnte, bin ich ja gerade dran, etwas in der Art zu bauen.
Level- und Sprite-Engines funktionieren ja 100%, das GameSys2 (für die Spielfigurensteuerung) funktioniert auch 100%, im Moment lege ich gerade die "letzten Handgriffe" an den Editor, mit dem man Grafiken aus Bildern auszuschneiden und in Sprites/Kacheln für Levels zu wandeln.
Subroutinen für so Dinge wie Tastenabfrage und Timerticker ändern sind bereits seit Jahren vorhanden...
Xpyderz hat ja auch schon irgendwie funktioniert - auch wenn der Code jetzt schon alt ist und ich einige Dinge heute anders machen würde. Es ist halt nur so, daß ich es mir durchaus zutraue (und auch vorhabe) noch mindestens zwei 2D Spiele zu machen:
ein Shoot-Em-Up - sowas wie Katakis/R-Type/Gradius
und
ein Jump'n'run - ähnlich wie Mario Bros./Giana Sisters, aber kein wirklicher Vergleich, da das Konzept etwas anders ist.
Ich habe auch schon Dinge in 3D programmiert - aber da müßte ich nochmal drübergehen. Das waren nur Machbarkeitskonzepte, da gehört noch etwas Performance drauf.
Naja, genug gelabert.

[zatzen]

Mein Traum ist es eigentlich auch, mal ein eigenes Adventure zu basteln.
Denn Adventures sind heute noch die Art von Spiel die ich noch am ehesten
Spiele, wenn ich überhaupt vielleicht alle 2 Monate mal was spiele.

Mir ist natürlich bekannt, dass es sowas wie AGS gibt, also eine Engine,
wo man nur noch das Scripting und die Grafiken (und Sound) beisteuern
muss.
Das ganze hat aber irgendwie ne 100seitige Anleitung und kommt mir
so kompliziert vor, dass ich denke, in der gleichen Zeit könnte ich
mir ne Engine selber programmieren, deren Konzept mir zudem
noch besser gefällt.
Ich mag mich täuschen, aber wäre ein Adventure nicht auch ohne
Script möglich? Einfach schön NICHT-objektorientiert durch Definition
von Startparametern? Vielleicht ist es einfach eine andere Herangehensweise
wie ich mir das so vorstelle.
Jedenfalls hätte ich auch Lust zu sowas, und ich denke der Code würde
zwar nicht klein, aber beherrschbar, und ich würde dann Grafiken und
Sound beisteuern und ne CONFIG, und kein Script. Also keine Ahnung,
aber sagen wir mal, ich müsste in diesem Fall das "Rad" neu erfinden,
da würde ich an scripting erstmal nicht denken.
Sowas hätte dann auch Zukunft, denn die jeweiligen Spiele könnte
man als Modul betrachten (und auch so als eine Datei "kompilieren"),
und irgendein gutgesinnter freundlicher überhilfsbereiter Mensch
könnte meine DOS-Engine dann auch nach Windows portieren.

Will also heissen, ich programmiere nicht gerne so, dass Grafiken
und Inhalt, wasauchimmer, mit dem Code verwoben sind, sondern
dass alles Modular ist, und wenn man so will nur "abgespielt" wird.

Wie sinnvoll und möglich das ist, darüber dürft ihr euch jetzt die Haare raufen.

[DOSferatu]

Ach, wieso "Haare raufen"? Normalerweise programmiert man sinnvollerweise fast immer modular.
Adventure habe ich auch schonmal (daaaamals) angefangen. Also ein Adventure wäre für mich technisch gar kein Problem - allerdings fände ich dafür ein (selbstentwickeltes) Skript schon am praktischsten.
Erklärung für Point+Click-Adventure:
Es wäre erst einmal eine Entscheidungstabelle da, die für jede Eingabe abgefragt wird.
Die hätte pro Eintrag 5 "Daten".
VERB SUBSTANTIV1 SUBSTANTIV2 ORT ZIELPOINTER
VERB wäre eines der (durchnumerierten) Verben wie "gib, nimm, benutze, rede, ziehe, drücke..."
SUBSTANTIV1 wäre der Gegenstand/Person, mit dem man das macht, kann auch 0 sein, wenn das Verb ohne Person/Gegenstand auskommt.
SUBSTANTIV2 wäre entweder 0 für nix oder <>0 für die Nummer des Gegenstands/Person. z.B. wenn man BENUTZE hat, daß man da auch "BENUTZE A MIT B"... Der würde daran, daß es dafür bei SUBSTANTIV2 Einträge gibt, immer selber das "MIT" ergänzen.
ORT wäre das "Bild"/die Lokation, wo man sich befindet. 0 wäre wieder "geht überall", ansonsten wäre es so, daß die Aktion nur an diesem Ort geht. Soll sie an mehreren Orten gehen, würde ich das "daisy-chained" machen mit so einer externen Liste (oberes Bit würde zB sagen: Chain in Liste, dann wäre die Nummer nicht der Ort, sondern die Listenposition). Könnte man auch für die anderen Daten machen. (Natürlich wäre in einem GRAFISCHEN Adventure nur ein Gegenstand "nehmbar", der sich schon am ORT befindet - andere könnte man ja nicht anklicken...)
ZIELPOINTER wäre dann der Zeiger auf das Skript, wo die Aktion ausgeführt wird. Das Skript hätte relativ einfache Befehle, daß zB ein Gegenstand erhalten/verloren werden kann oder daß eine Animation ausgelöst werden soll (deren Format wäre dann nicht Teil dieses Skripts), was auch beinhaltet, daß Personen Text ausgeben (also reden).
Wenn man dann zwei Gegenstände miteinander benutzt (sie verbindet), würde man Gegenstand 120 und Gegenstand 45 verlieren und dafür Gegenstand 217 erhalten (den kombinierten).
Die ganze Adventure-Steuerung wäre auch nicht Teil des Ausführ-Skripts, sondern wird nur davon "angestoßen" und umgekehrt, also alles modular.
Das heißt, es wäre eine Kombination aus: Grafik-/Soundroutinen, einfachen Steuerroutinen, ein einfaches Skipt (und entsprechenden Skript-Interpreter) und eine/mehrere Entscheidungstabellen nötig. Alles auch machbar mit einem selbstzuschreibenden Editor.
Die meiste Arbeit an Adventures ist meiner Meinung nach nicht die Programmierung - sondern eher (ohne feste Reihenfolge) a) die Ideen zu haben/Texte zu verfassen, b) die ganzen Grafiken zu zeichnen, c) die ganzen Sounds zu machen (Sprachausgabe wäre noch ein extra Problem, wenn man sowas will. Es ist ja kein Problem, Sprache AUSZUGEBEN. Aber man braucht ja dafür auch mehrere LEUTE, damit nicht alles klingt wie man selbst). Das ganze zu einem Adventure zusammenzuschrauben ist dann eigentlich nur noch reines Handwerkszeug.
Anmerkung: Es wäre dann sogar auch möglich, diese Ding auf den C64 zu portieren. Habe schonmal Zeug programmiert, um PC-Grafik in C64-Grafik zu wandeln. Könnte das mittlerweile jetzt noch besser.
Es ist eben ALLES nur eine Frage von ARBEIT, die man da reinstecken will und auch ZEIT, die man hat. Und man muß natürlich LUST drauf haben und dranbleiben. Ich weiß: Das Ist nicht so einfach, wenn man gleichzeitig auch noch einen JOB und andere notwendige Übel in seinem Leben zu koordinieren hat. Z.B. diese dauernde verdammte MÜDIGKEIT...

Habe mir darüber schon einige Gedanken gemacht. (Auch über "Wegfindungs"-Routinen für die "Gehe zu" Befehle.)
Aber naja. Wir werden es wohl nie erfahren, wie ein evtl. von mir gemachtes Adventure ausgesehen hätte...

[Brueggi]

Also meine A.A.S.U.-Engine ("Another Adventure Script Utility") vom Amiga war im Grunde erstmal ein Script-Interpreter. Die Raum-Scripts hat man einfach mit einem Texteditor erstellt. Angefangen hat alles mit Objekt-Definitionen, die in diesem Raum vorhanden sind. Dann folgte der "Code-Teil". Das waren im Grunde genommen einfache Dinge wie:

IF_SENTENCE "NIMM EIMER"
.
.
.
.
ENDIF

Wobei "EIMER" dann natürlich ein Objekt im Raum oder im Inventar liegen musste. Zusätzlich gab es ein SCRIPT .000, diese Anweisungen wurden IMMER ausgeführt - da es ja auch Befehle gibt, die immer laufen müssen (z. B. Inventar anschauen). "Gehe Zu" war default - die Figur hat das natürlich ohne Script gemacht.

Einige Befehle waren z. B. CreateInv zum Erzeugen eines Gegenstandes im Inventory, oder DisableInterface - für Zwischensequenzen, wo das Interface abgeschaltet werden musste.

Darüber hinaus gab es noch 256 User-Variablen (Words), die man per Befehl auslesen oder oder setzen konnte. Zum Beispiel konnte man damit diverse Flags (Tür offen/Tür zu) setzen. Es kamen dann noch weitere Verbesserungen (übergroße Räume mit Scrolling), Multi-Charakter-Unterstützung (mehrere Spieler und die jeweiligen Inventories) und sowas.

Wie auch immer - diese eben genannten Scripts wurden dann per compiler in Tokens und Parameter übersetzt. Und die fertigen Files konnte dann die Engine ausführen (für die jeweilige Plattform muss man halt die Grafik-Routinen anpassen - am Script ändert dies jedoch nichts). Im Grunde genommen ganz easy - nur eben die Arbeit, alle Räume zu zeichnen... Daran ist es gescheitert. Irgendwo dümpelt eine Version mit 10-12 Räumen herum... Ich würd die ja gerne mal fertig machen, ich bräuchte nur einen guten Grafiker und jemanden, der ein paar Ideen dazu beisteuert und eventuell mit scriptet...

Also wenn jemand ein paar coole (2D-) Grafikroutinen hat (Sprite-Routinen), dann wäre ich sofort dabei, sowas am PC aufzuziehen. Nur ist mir das echt zu viel Arbeit, das auch noch zu machen. Wie gesagt, wenn die "API" für die Grafik jemand übernimmt, kümmere ich mich um den Rest. Mich juckts förmlich in den Fingern.

[DOSferatu]

Grafikprogrammierung ist für mich kein Problem, ist quasi mein Steckenpferd.
2D Routinen (zB skalier-/spiegel-/drehbare/halbtransparente Sprites) hab ich schon als Subroutinen seit 2004 hier rumliegen. In Xpyderz oder diese TGAME.EXE (Test für meine GamsSys2 Unit), das ich mal hochgeladen habe, werden diverse Sachen davon benutzt.
Ist allerdings alles VGA (Mode-X). Es wäre zwar TECHNISCH kein Problem, das auch auf hohe SVGA/VESA Auflösungen anzupassen, ABER Grafik braucht immer wahnsinnig viel Speicher, der quasi quadratisch wächst mit höheren Auflösungen... Und wenn man nur so RealMode programmiert (wie ich), stellt sich dann schon die Frage, wo die ganzen Grafikdaten liegen sollen, wenn man z.B. mit 1024er Auflösung und 24bit Farbtiefe arbeiten will. Das nur als Anmerkung dazu.
Zu meinen Sprites:
Fähigkeiten: Größe 1x1 bis 255x255 in jeder Kombination.
- 8bit (256 Farben), mit oder ohne Palette
- 4bit (16 Farben aus 256, wenn mit Palette) - ( = halber Speicherverbrauch pro Sprite)
- X- und Y- Spiegeln (also horizontal und vertikal)
- drehen in 256 verschiedenen Winkeln
- Skalieren in 65536 Stufen, wobei 256 = 1:1 (also z.B: 64 = 1/4, oder 2048 = 8x)
- optionales Dithern (vor allem bei Vergrößerung brauchbar), so daß man keine Quadratpixel, sondern 16stufig geditherte Übergänge hat, die NICHT von Drehung beeinflußt werden (also kein Moiré)
- zusätzlicher Y-Skalierungsfaktor, der unabhängig von der Drehung eingesetzt wird, so daß man z.B. bei Bildauflösungen, die nicht 4:3 sind, dies entsprechend anpassen kann, damit "Kugeln immer rund sind"
- Eine Möglichkeit/Option, daß Sprites teilweise HINTER der "Grafik" liegen, d.h. von Teilen der vorderen Ebene verdeckt werden (wird mit einer bitweisen "BlockMap" gemacht). Allerdings sind diese noch nicht für ALLE der o.g. Fähigkeiten implementiert.
- Die Daten liegen so vor, daß man einzelne (bis zu 16) "Blöcke" (also die Grafikdaten) von Sprites ein- / ausblenden kann, wenn z.B. manche Sprites gerade nicht gebraucht werden.
- In Verbindung mit den "Block" (also Level-) Daten auch die Möglichkeit, die 16x16 Pixel Blocks, aus denen die 4-Ebenen-Levels bestehen, als Sprite darzustellen (d.h. mit den obengenannten Möglichkeiten)
- Achja, und die Darstellungsroutinen sind zu 90% in Assembler (vor allem die Schleifen)

Und es ist eben (leider) angepaßt an 8-Bit-VGA-Modi (Mode-X in allen möglichen Auflösungen), habe hier aber auch eine Routine mal basierend darauf "nachentwickelt", die auf linearen Modes (also nicht Mode-X-mäßig) läuft.

Ich vermute mal, man könnte damit schon etwas anfangen, wenn man will.
[ Ich hatte wohl damals ernsthaft daran gedacht, Spiele zu machen. (Denke ich ja heute immer noch.) Allerdings läßt sich das hier alles sehr gemächlich an - obwohl ich mittlerweile recht weit bin. - Hat aber auch lange genug gedauert. Der Level/Block/Sprite-Editor läßt sich mittlerweile recht gut an - habe am Wochenende wieder viel daran programmiert. Ich weiß nicht, woher es kommt - ich hege wohl immer noch die leise (wenn auch verschwindend geringe) Hoffnung, daß irgendwann irgendwie irgendwo irgendwer mal Lust haben wird, mit mir zusammen an einem Spielprojekt zu arbeiten - und um die Hemmschwelle zu verringern, baue ich wohl z.B. so Dinge wie diesen aufwendigen Editor... ]

[Brueggi]

Und was sollte dein Team-Kollege denn so an Können mitbringen (um mal so durch 5 Ecken hindurch anzufragen) ?

[DOSferatu]

Das hängt natürlich davon ab, welche Art von Spiel es werden soll - und auch von den Fähigkeiten der am Projekt beteiligen Leute. Solange man nicht GAR NICHTS kann, ist man ja schon eine Hilfe.
Nehmen wir z.B. an, jemand könnte überhaupt nicht programmieren - dann könnte er ja immer noch Grafiken machen oder Musiken komponieren. Nehmen wir an, jemand könnte nicht einmal das - aber hätte dafür ganz viele tolle Spielideen oder so. Und wenn jemand z.B. nicht zeichnen kann, könnte er wahrscheinlich aber immer noch Levels aus den bereits bestehenden (von anderen gezeichneten/erstellten) Elementen in einem Editor zusammenbauen.

Probleme, die dabei immer wieder entstehen, haben weniger "technische", als eher persönliche Gründe, als da z.B. wären:
1. Ungeduld. Wenn nicht alles in 1 Woche fertig ist, ist das Ende der Aufmerksamkeitsspanne erreicht. So funktioniert das nicht. Ein Spiel zu machen dauert länger als es durchzuspielen. Das muß man akzeptieren.
2. Geld. Man muß einsehen, daß man NIEMALS damit je Geld verdienen wird. (Und selbst WENN die unwahrscheinliche Möglichkeit bestünde, würde ich mich dagegen wehren, da ich nur freie Spiele mache.) Und nein das - "Es muß ja Anfangs nicht um Geld gehen, aber es wäre ein schöner Nebeneffekt." -Argument gilt hier nicht. Es für Geld zu machen, verleidet mir die Arbeit daran.
3. Größenwahn. Alles muß 1600er Auflösung mit 32bit Farbtiefe und 32stimmigen Surroundsound haben. ---- NEIN. Muß es nicht. Soll es nicht. Darf es nicht. Und wer nicht mit den Beschränkungen oder dem anvisierten Mindestsystemanforderungen klarkommt (sondern für alles 3,x GHz Quadcore mit neuester Supergrafikkarte, die alles gleich in Hardware abbildet oder so als technische Untergrenze festsetzen wil...) Der kann zu Microsoft oder Apple gehen - da arbeiten solche Leute.
4. "Mitmachen". Im Sinne von "Dabeisein ist alles". Das funktioniert so: Man schmeißt jemandem zwei/drei Ideen vor die Füße, der dann im Alleingang die ganze Arbeit macht. Nur, damit man selbst am Ende in den Credits erwähnt wird, weil man ja am Projekt "mitgearbeitet hat". - Kann man so machen. Aber nicht mit mir.
5. Konzeptlosigkeit. Alle 2 Tage am liebsten das ganze Projekt umschmeißen wollen, da man es ja nun doch lieber ganz anders will. Man könnte da argumentieren, daß man ja das bestmögliche Ergebnis haben will - ABER: Irgendwann muß man sich auch mal festlegen können, anderenfalls wird (erfahrungsgemäß) nie ein Projekt jemals fertig.
6. "Mein Part ist der wichtigste." Für die Bereiche, die man selbst bedient, ständig mehr/die meiste Speicher und Rechenzeit haben zu wollen, mit teilweise (auf die Gesamtverfügbarkeit aller Ressourcen bezogen) unrealistischen Vorstellungen. Ich sags mal so: über 600 kB sind zwar da. Aber man kann nicht 80% der Ressourcen für fotorealistische hochauflösede Vollgrafikhintergrunde verschwenden, weil das sonstige Projekt (also das Spiel) dann aus nichts weiter besteht als einer sehr tolle Grafikanzeige. Genauso geht es nicht, 80% des Ressourcen für Sound benutzen zu wollen, nur weil alles mit großen Samples in CD-Quaität vollgestopft wird. Und man kann auch nicht 80% der Ressourcen für das Programm verschwenden, weil man ein total maschinenfernes Skript benutzen will und dafür einen total aufgeblasenen Skriptinterpreter, der die meiste Zeit die Maschine zu 100% auslastet. Mit "Ressourcen" sind in diesen Fällen der verfügbare Speicher und die verfügbare Rechnerleistung (pro Sekunde) gemeint.
7. Bummeligkeit. Zwar am Projekt dranbleiben, aber auf eine Art, daß einem wegen jedes kleinen Stücks Arbeit andauernd hinterhergelaufen werden muß. Ich kann so nicht arbeiten - und wenn das derart liefe, könnte ich auch gleich alles allein machen.

Das sind nur einige der Sachen, die mir spontan so eingefallen sind. Und diese "Skills" sind erst einmal die Grundvoraussetzungen - lange bevor es überhaupt dazu kommt, was man am eigentlichen Projekt macht. Leider muß ich das so deutlich sagen. Würde ich WIRKLICH mal im Team mit jemandem arbeiten sollen, so sollte mir (bzw dem Projekt) dieser Mensch auch wirklich eine HILFE sein . anderenfalls fahre ich wirklich besser allein.

Kurze Information: Die Stelle für einen "reinen Ideengeber" wird hier schon nicht gebraucht. a) habe ich selbst genügend Ideen (so viele, daß ich gar nicht dazu komme, die alle umzusetzen) und b) sollte, selbst WENN man ein toller ideengeber ist, auch ein wenig Handwerkszeug dabei 'rumkommen. Ideen kann man sich schließlich überall holen, es gibt 7 Milliarden Leute auf der Welt, 80 Millionen leben in Deutschland. Und viele davon liefern Ideen ganz unbewußt den ganzen Tag über, ohne es selbst zu merken - oder dafür bezahlt zu werden...

Na gut, genug davon erst einmal.

[Brueggi]

Hört sich doch alles sehr vernünftig an. Dem stimme ich zu 100% zu.