VIP Chat mit Peter Thierolf [Neon]

Peter Thierolf von Neon stand im Chat von spieleentwickler.org Rede und Antwort.

<Peter_Thierolf>	Soll ich mich noch mal vorstellen ?
<MarcKamradt>	aber bitte. ein kleiner abriss über deine projekte / laufbahn kann nicht schaden
<Peter_Thierolf>	Ok.
<Peter_Thierolf>	Ich hab mit dem C64 angefangen, 1987 erstes Spiel veröffentlicht.
<Peter_Thierolf>	Da war ich noch Schüler, hatte aber nicht so richtig Bock aufs Abi...
<MarcKamradt>	höhö... das kenn ich
<Peter_Thierolf>	Naja, da ich mit dem ersten Teil dann schon bei Rainbow Arts untergekommen war, hab ich da halt nach Folgeaufträgen gefragt
<Peter_Thierolf>	Hab dann eine Portierung Atari ST auf C64 gemacht (schwitz...)
<Peter_Thierolf>	Später dann auf Amiga weitergemacht.
<Peter_Thierolf>	Mit zwei Kumpels (Frank Matzke und Chris Hülsbeck) Kaiko gegründet
<Peter_Thierolf>	Gem'X rausgebracht (Amiga, Atari ST, C64 und naja, so ne PC Version auch...)
<Porter>	;)
<Peter_Thierolf>	naja, dann Apidya, war nen Horizontal-shooter auf Amiga
<Guest36607>	<- Sebastian Brynckman (damit man mich einer person zuordnen kann, vielleicht kennt man mich ja ausm usf) g
<Peter_Thierolf>	Über Bluebyte veröffentlicht - die habens aber leider schlecht vermarktet :(
<Peter_Thierolf>	Naja, dann bin ich aufgrund persönlicher Schwierigkeiten unter den Gründern bei Kaiko -
<Peter_Thierolf>	naja, man kanns 'rausgeflogen' nennen.
<Peter_Thierolf>	Dann mit den Neon Jungs, die ich schon von Kaiko kannte halt Neon gegründet.
<Peter_Thierolf>	Da haben wir dann Mr Nutz gemacht, einen super Publishing-deal mit Ocean gekriegt
<Peter_Thierolf>	In dem Publishing deal waren halt Konsolenversionen drin.
<Peter_Thierolf>	Sega Saturn und Playstation...
<Peter_Thierolf>	Naja, und dann sind wir größer geworden etc...
<Peter_Thierolf>	6 Gründer, Geschäftsführer - das hat Stunk gegeben.
<Peter_Thierolf>	Dann sind 2 weggegangen, Ocean ist Pleite gegegangen...
<Peter_Thierolf>	Wir haben zwar überlebt aber sind auf die 4 Gründer und 1 Mitarbeiter zurückgeschrumpft.
<Peter_Thierolf>	Der eine ist dann irgendwann auch weg, weil er keinen Bock hatte von 4 Meistern was gesagt zu kriegen :)
<Peter_Thierolf>	Naja, danach halt Gameboy games, wiederaufbau, Deal mit JoWooD.
<Peter_Thierolf>	Diese Reihenfolge.
<Peter_Thierolf>	Und jetzt arbeiten wir an supi sachen auf PS2....
<Peter_Thierolf>	Genug ?
<CodeJack>	viel Glück dabei
<Peter_Thierolf>	danke :)
<McRam>	irgendwas bekanntes auf ps2? oder noch top secret?
<Peter_Thierolf>	Nun - einen Titel gibts noch nicht mal.
<Peter_Thierolf>	Deshalb kann ich ihn auch nicht verraten :)
<McRam>	ok :)
<Porta>	Wer ein Unternehmen mit 6 Geschäftsführern aufbaut, muss verrückt sein - imho =) - ich hatte schon damals probleme als ich 1 kollegen hatte, aber gott sei dank kam mit ihm nie ein gesellschaftervertrag zu stande
<Peter_Thierolf>	Aber es wird ein Character-bezogenes Action-adventure.
<Peter_Thierolf>	Jaja.
<Peter_Thierolf>	Das mach ich auch nie NIE wieder.
<Peter_Thierolf>	Es hat sich halt historisch so ergeben
<Peter_Thierolf>	Die Erfahrung war noch nicht gar so groß und naja
<Peter_Thierolf>	Ich war da einigermaßen relaxt.
<Peter_Thierolf>	Jetzt weiß ich mehr.
<Peter_Thierolf>	Immerhin sind von den 5 anderen noch einige dabei, mit denen ich es auch noch mal machen würde.
<Peter_Thierolf>	Ich muß auch zugeben, daß ich eigentlich ein lausiger Geschäftsmann bin.
<PeterDobrovka>	worum geht es gerade?
<Peter_Thierolf>	Jedenfalls gibt es eine Menge Sachen, die ich besser kann...
<Peter_Thierolf>	Nix eigentlich.
<Peter_Thierolf>	Frag was...
<PeterDobrovka>	woran arbeitest du gerade?
<MarcKamradt>	peter hat sich vorgestellt...
<Peter_Thierolf>	Bin Lead Programmer bei dem PS2 Titel, an dem Neon schafft.
<PeterDobrovka>	und was ist das für ein Titel?
<Peter_Thierolf>	So irre viel kann (darf) ich natürlich nicht sagen.
<CodeJack>	das Biz gehört dazu
<Peter_Thierolf>	Naja, natürlich 3d, mit Characteren. So richtung Action Adventure.
<Peter_Thierolf>	Halt konsolig...
<PeterDobrovka>	Aha. Welches sind denn deine Bereiche?
<Peter_Thierolf>	Eigentlich mach ich, wie die anderen Programmierer auch, immer das, was ansteht.
<MarcKamradt>	naja... aber es gibt ja schon so bereiche, oder?
<Peter_Thierolf>	Klar.
<PeterDobrovka>	Nicht bei Extreme Programming...
<Peter_Thierolf>	Kamera, Basisklassen
<MarcKamradt>	:-)
<Peter_Thierolf>	Also beides, nicht die Basis der Kamera
<Peter_Thierolf>	Natürlich auch Tools, Max-Plugins halt
<Peter_Thierolf>	Animationen
<PeterDobrovka>	Also was "unter der Motorhaube" ist
<Peter_Thierolf>	Auch.
<PeterDobrovka>	huch, Animationen?
<Peter_Thierolf>	Ja, die Controller-Klassen
<PeterDobrovka>	Habt ihr algorithmische Animationen?
<Peter_Thierolf>	Im moment schlagen wir uns mit LVE, Linear-velocity-extraction rum.
<Peter_Thierolf>	Wir haben auch prozedurale Anims, aber nicht so irre viel.
<Peter_Thierolf>	Halt sowas wie 'figur schaut zu anderer Figur'
<PeterDobrovka>	LVE sagt mir jetzt gerade nix...
<Peter_Thierolf>	Stell Dir vor, Der animator baut eine Anim.
<Peter_Thierolf>	Die Figur bewegt sich realistisch.
<Peter_Thierolf>	Das heißt dann, der Masseschwerpunkt bewegt sich nicht linear.
<PeterDobrovka>	nein, das tut er nicht...
<Peter_Thierolf>	Um jetzt eine vernünftige Abbildung in der Engine zur kriegen extrahiert man die lineare Bewegug
<Peter_Thierolf>	So daß man den Masseschwerpunkt linear bewegen kann und die Anim den rest ausgleicht.
<Peter_Thierolf>	Das nennt sich dann LVE.
<PeterDobrovka>	Aha!
<Peter_Thierolf>	Wir haben aber teilweise sehr komplexe Anims, die dann durch eine einzelne lineare Bewegung nicht abgebildet werden können.
<PeterDobrovka>	Das führt dann zu den Artefakten, die man immer wieder sihet
<MarcKamradt>	die anim zappelt sozusagen um ihren nullpunkt, während das programm sie linear fortbewegt
<Peter_Thierolf>	Naja, LVE sorgt halt dafür, daß man im Programm den Masseschwerpunkt linear bewegen kann, aber keine Artefakte sichtbar sind.
<PeterDobrovka>	Ah ja.
<Peter_Thierolf>	Dazu gibt es auf Gamasutra einen Artikel...
<PeterDobrovka>	Aber was nun, wenn der Grafiker schon die Animation nicht linear hingekriegt hat?
<Peter_Thierolf>	Muß er ja nicht,
<PeterDobrovka>	doch
<PeterDobrovka>	Nimm an, der linke Fu
<Peter_Thierolf>	Jede Anim hat von ihrer Startpos zu ihrem Endpunkt eine Fortbewegung.
<PeterDobrovka>	wird schneller als der rechte bewegt
<Peter_Thierolf>	Klar.
<PeterDobrovka>	das kriegst du nicht ausgebügelt
<Peter_Thierolf>	Aber der Masseschwerpunkt des Objekts bewegt sich über die Anim hinweg irgendwie.
<MarcKamradt>	genau das ist ja der "trick" mit lve
<Peter_Thierolf>	Jetzt teilst Du diese Bewegung durch die Anzahl frames.
<Peter_Thierolf>	Für jedes Frame bestimmst Du die Differenz zwischen der vom Grafiker bestimmten Pos
<Peter_Thierolf>	und deiner linear interpolierten.
<Peter_Thierolf>	Diese Differenz schreibst Du in einen Animationskanal.
<Peter_Thierolf>	An die Lineare Pos kannst Du dann z.B. Deine Kollisionsgeometrie hängen.
<PeterDobrovka>	Hm...
<PeterDobrovka>	Wie sieht es mit Figuren aus, die gewollt nonlinear laufen? Z.B. Quasimodo?
<Peter_Thierolf>	Dürfen sie gerne. Die Anim sieht hinterher genauso aus wie vorher.
<PeterDobrovka>	was anderes: was für ein Stil hat das neue Game?
<Peter_Thierolf>	Ist nur besser geeignet um z.B. mittendrin abzubrechen etc.
<Peter_Thierolf>	Da muß ich etwas vorsichtig sein - es gibt noch nichts offizielles...
<Peter_Thierolf>	Ich sag mal - nicht realistisch.
<Peter_Thierolf>	bunt, fernöstlich angehaucht.
<MarcKamradt>	naja... komm schon... ein bissel was müssen hier schon geboten bekommen
<PeterDobrovka>	Meine Güte, immer diese Geheimniskrämerei!
<Peter_Thierolf>	Soll ich screenshots posten ?
<PeterDobrovka>	Ist doch kostenlose Werbung, wenn was durchsickert
<CodeJack>	ja
<MarcKamradt>	:-) das wäre toll
<PeterDobrovka>	das muß doch im Interesse jeder Firma sein
<Peter_Thierolf>	Ich würde gerne was erzählen - aber ich habe dafür keine Kompetenzen...
<PeterDobrovka>	schaade...
<Peter_Thierolf>	Warte mal - ich mal mal einen. Den posten wir dann.
<PeterDobrovka>	du MALST einen Screenshot?
<McRam>	Und, schon irgendwelche Scriptsprachen vorhanden bzw. in Planung?
<Peter_Thierolf>	Ne.
<Peter_Thierolf>	doch.
<Peter_Thierolf>	also moment.
<Peter_Thierolf>	Hab einen Screenshot gemacht.
<Peter_Thierolf>	Jetzt weiß ich nicht, wie ich ihn posten soll...
<tibetaner>	mach doch einen, und shrink ihn auf 64x64 ;)
<Peter_Thierolf>	Marc checkt das mal.
<Peter_Thierolf>	so - scriptsprachen
<Peter_Thierolf>	Wir werden wohl keine einbauen.
<Peter_Thierolf>	Ich glaube kaum, daß wir eine brauchen.
<Peter_Thierolf>	Ich habe da inzwischen ein etwas differenziertes Verhältnis entwickelt.
<MarcKamradt>	http://www.spieleentwickler.org/shot.JPG [bild war nur temporär]
<Peter_Thierolf>	Entweder man braucht dringend eine, dann müssen das aber Programmierer bedienen...
<havok>	hm
<Peter_Thierolf>	Dann kann man gleich C++ nehmen.
<Peter_Thierolf>	Oder man braucht keine - dann muß man auch keine machen :)
<McRam>	Mhh, gescriptete Ereignisse in c++??
<DanielLudwig>	die Dateinamen sind fast so lang wie unsere g ->shot
<Peter_Thierolf>	Nicht ganz.
<Peter_Thierolf>	Es gibt sogenannte 'Trigger', die Zustände abfragen und dann Ereignisse auslösen können.
<MarcKamradt>	(ist ja nur temporär)
<Peter_Thierolf>	Davon gibt es dann halt eine Anzahl verschiedener, die man im Leveleditor setzen und verbinden kann.
<McRam>	Ist klar, aber diese Ereignisse müssen doch irgendwie gesteuert werden, wenn 'se nicht immer gleich aussehen sollen!?
<PeterDobrovka>	Ich stimme Peter zu, Scripte sind nur dann sinnvoll, wenn man eine spätere Erweiterbarkeit des Produktes plant
<Peter_Thierolf>	Klar. Das sind dann Trigger wie 'abstand vom Spieler checken'...
<PeterDobrovka>	Unddas ist bei Konsolen kaum gegeben
<Peter_Thierolf>	Die Viecher, die rumlaufen, haben eine AI, die dann abhängig von den Triggern reagiert.
<McRam>	ah so, ok..
<Peter_Thierolf>	Scripte wären bei der Art von Spiel wahrscheinlich gar nicht nötig.
<PeterDobrovka>	Sie haben eine AI?
<Peter_Thierolf>	Naja - was man so nennt.
<PeterDobrovka>	laufe richtung Spieler - beisse spieler - loop
<Peter_Thierolf>	Sie können interagieren, haben Angriffs- und Verteidigungsmuster.
<Peter_Thierolf>	Aber sie werden in hohem Masse von Leveldaten gesteuert.
<PeterDobrovka>	der arme leveldesigner
<PeterDobrovka>	wird zum programmierer
<falko_loeffler>	genau! :)
<Peter_Thierolf>	Es soll ja auch ein vorhersehbares Erlebnis werden - eher mit Halflife zu vergleichen.
<Peter_Thierolf>	Ne - der wird nicht zum Programmierer, weils ja keine Programmiersprache ist.
<Peter_Thierolf>	Man setzt Splines, editiert Wirkungsräume etc.
<PeterDobrovka>	verstehen Leveldesigner was von Splines?
<MarcKamradt>	der leveldesigner soll ja gerade NICHT programmieren
<DanielLudwig>	PeterD, wenn man es ihnen erklärt... g
<Peter_Thierolf>	Im allgemeinen sind sie doch noch schlau genug, um Punkte zu setzen, die durch eine Linie verbunden sind...
<falko_loeffler>	splines sind die broetchen mit loecher drin, gell?
<Peter_Thierolf>	Klappe - Falko.
<MarcMueller>	ja!
<PeterDobrovka>	Wirkungdsräume... das hört sich an nach Informatikvorlesung, Semester 8
<DanielLudwig>	unserer setzt mit Begeisterung Kamerafahrten
<PeterDobrovka>	Macht Zwischensequenzen bitte abbrechbar
<Peter_Thierolf>	Naja - unserer denkt er wäre ein Schriftsteller.
<Peter_Thierolf>	Wir dürfen gespannt sein...
<Peter_Thierolf>	Ne, Falko ??
<falko_loeffler>	im moment bin ich eher drehbuchautor ..
<Peter_Thierolf>	Also ein Wirkunsraum ist halt einfach das Feld, das die Figur nicht verlässt.
<PeterDobrovka>	das weiss ich doch ;)
<Peter_Thierolf>	Da idlet der dann rum.
<PeterDobrovka>	LOL
<Peter_Thierolf>	Und wenn er Dich sieht - dann pass mal besser auf.
<PeterDobrovka>	Also gut, ein Action-Adventure im Manga--Stil mit Monstern, vergleichbar Half-Life - das ist doch was, worunter man sich was vorstellen kann
<MarcKamradt>	:-)
<Peter_Thierolf>	Dann stell Dir das mal vor - dann wirst Du überrascht sein.
<Peter_Thierolf>	Das ist ja was gutes.
<PeterDobrovka>	Weiß einer, warum hier die Kulleraugen so beliebt sind?
<Peter_Thierolf>	Keine Ahnung - wir haben keine im game :)
<havok>	hört sich an wie Oni?
<Porta>	sind sie das wirklich ?
<Peter_Thierolf>	Ne - wir arbeiten nicht an oni 2.
<Peter_Thierolf>	Aber die Grafik sieht schon ziemlich cool aus.
<DanielLudwig>	ist ja schonmal die halbe miete heutzutage
<Peter_Thierolf>	Definitiv.
<Peter_Thierolf>	Wir sind halt auf PS2, da kann man nicht mal ins Mittelfeld zielen.
<Peter_Thierolf>	Entweder man macht das Full-force, Triple-A, oder man lässt es.
<Peter_Thierolf>	Und das heißt halt in jedem Bereich mindestens gleich gut wie die Konkurrenz.
<McRam>	Was gibt denn die Engine so her(light-,mip-,enviroment-,bumpmapping, textureauflösung, polys per seconds etc..?)
<tibetaner>	oder man hat ne fette lizenz ... :p
<Peter_Thierolf>	Naja - grafisch ist die Konkurrenz sehr gut...
<havok>	ist das teil wirklich so kompliziert zu programmieren wie man immer wieder hört?
<Peter_Thierolf>	Kannst Du bei www.renderware.com nachlesen.
<MarcKamradt>	:-)
<Peter_Thierolf>	Ne, PS2 geht eigentlich.
<CodeJack>	wie teuer?
<Peter_Thierolf>	Es war sicher ziemlich krass am Anfang.
<tibetaner>	was wär denn ziemlich schwer zu proggen?
<Peter_Thierolf>	Aber wir haben ja mit entsprechendem Rückenwind gestartet.
<MarcKamradt>	häh? ich finde ps2 ziemlich knackig. vor allem wenn man was auf dem IOP machen will...
<tibetaner>	also welche konsole?
<Peter_Thierolf>	Lusche.
<tibetaner>	IOP?
<tibetaner>	io port
<Peter_Thierolf>	Ich glaube gar nicht, daß eine spezielle Konsole besonders krass zu proggen ist.
<havok>	Rückenwind?
<Peter_Thierolf>	Ich habe jetzt halt schon auf ziemlich vielen gearbeitet und habe einen soliden ASM background.
<MarcKamradt>	naja... in der ps2 ist nochmal die ps1 mit drin und kümmert sich in der tat um i/o sachen... deshalb I/O prozessor
<MarcKamradt>	cd, dvd, pad, memory card, sound
<Peter_Thierolf>	Rückenwind -> die Libs von Sony sind schon sehr gut, ziemlich viele Bugs wurden schon von anderen gefunden.
<CodeJack>	Assembler ist immer noch sehr wichtig
<havok>	ah
<Peter_Thierolf>	Außerdem setzen wir auf der Renderware auf.
<Peter_Thierolf>	Auch wenn ichs net so mag :(
<Peter_Thierolf>	Konsolen haben den großen vorteil, daß die Architektur klar beschrieben ist.
<DanielLudwig>	hättet es lieber selbst gemacht? oder liegts an Renderware?
<Peter_Thierolf>	Ich hätte es lieber selbst gemacht - das Team sieht das anders.
<Peter_Thierolf>	Und das auch nicht ohne Grund.
<Peter_Thierolf>	Ne - wir haben halt nicht so irre viel Zeit.
<havok>	guter grund :)
<tibetaner>	wieso findest du renderware ncight gut?
<Peter_Thierolf>	Mit der RW konnten wir extrem schnell einen Super Prototypen hinstellen, der echt gut war.
<tibetaner>	nicht
<PeterDobrovka>	Was wäre der Grund gewesen, es selbst zu machen?
<Peter_Thierolf>	Arroganz wäre der Grund.
<DanielLudwig>	Totale Kontrolle (tm)
<PeterDobrovka>	Hm...
<Peter_Thierolf>	Irgendwie glaube ich, inzwischen mehr rausgefunden zu haben über Multi-plattform.
<Peter_Thierolf>	Totale Kontrolle ist allerdings auch ein Thema.
<DanielLudwig>	oder weil man sowas gern macht (low level) ;)
<Peter_Thierolf>	Die Jungs von der RW arbeiten ja weiter und wir müssen die Paradigmen-Wechsel in Bereichen der Engine mitmachen...
<Peter_Thierolf>	Ich machs auch gerne...
<PeterDobrovka>	Ich bin inzwischen auf dem standpunkt, daß ich ich nur noch dann etwas selber mache, wenn es keine fertige Lösung zu kaufen gibt oder sie zu teuer ist
<Peter_Thierolf>	Ich mag es, wenn die Foundation steht und nur geändert wird, wenn wir das müssen.
<Peter_Thierolf>	Dann hat man Ruhe im Projekt.
<PeterDobrovka>	ist das nicht ein Trugschluß?
<Peter_Thierolf>	Naja - eigentlich heißt zu teuer, daß die Sache selbst herzustellen teurer ist, als sie zu kaufen.
<Peter_Thierolf>	Das ist aber sehr schwer auszurechnen.
<PeterDobrovka>	Ich habe eher die Erfahrung mir eigenen Engines gemacht: irgendwas ist immer dran zu machen
<PeterDobrovka>	man wird nie fertig
<Peter_Thierolf>	Ich habe bislang immer die Technik selbst gemacht und mit Ausnahme der wahnsinnig gewordenen PC-Plattform funzt das auch ganz gut...
<Peter_Thierolf>	Das mit der eigenen Engine hängt immer ein bissel davon ab, ob man sich ins engine-machen verliebt oder streng nach Requirements vorgeht.
<Peter_Thierolf>	Die kommen dann ja von den Designern und Grafikern und werden am Anfang festgelegt.
<PeterDobrovka>	Wenn man was besser machen kann oder Geld sparen kann, dann sollte man natürlich auf jeden Fall selbst machen
<havok>	Sind bei euch die Entscheider gleichzeitig Entwickler?
<Peter_Thierolf>	Ja und nein.
<PeterDobrovka>	kann auch nicht
<havok>	sollte nicht ;)
<PeterDobrovka>	er ist lead-programmer, darf aber nichts erzählen
<Peter_Thierolf>	Die hauptsächlichen Entscheider sitzen jetzt ja bei JoWooD, und sind dort keine Entwickler (mehr).
<MarcKamradt>	wieso nicht? ich bin momentan nicht ganz schlüssig, ob so eine trennung sinnvoll ist
<PeterDobrovka>	das ist die normative kraft des faktischen
<Peter_Thierolf>	Es wäre gut, wenn die Entscheider die Entwickler ganz verstehen würden.
<PeterDobrovka>	Programmierer verdienen selten genug Geld, um zu entscheidern zu werden
<Peter_Thierolf>	???
<Peter_Thierolf>	Totaler Unsinn.
<DanielLudwig>	ich bin der Meinung, daß es die gute Mischung macht - Entscheider in beiden "Lagern"
<Peter_Thierolf>	Es kommt doch nicht auf Deinen Job an, sondern auf Deinen Charakter.
<Peter_Thierolf>	Du wirst um ein gutes Spiel machen zu können und das dann auch gut zu verkaufen Leute brauchen, die Entscheidungen in nicht-entwickelnden Bereichen treffen.
<Peter_Thierolf>	Marketing zum Beispiel.
<Peter_Thierolf>	An denen führt kein Weg vorbei - die sollte man auch rechtzeitig im Projektverlauf ins Boot holen.
<Peter_Thierolf>	Ich bin jedenfalls für kurze Entscheidungswege und pragmatische Entscheider.
<Peter_Thierolf>	Ob die was Entwickeln oder neben dem Entscheiden nur in den Sessel pupen ist mir egal.
<Peter_Thierolf>	Hauptsache sie Entscheiden - und zögern nicht alles ewig raus.
<Peter_Thierolf>	Wichtig ist allerdings, daß manche Rollen im Projekt nicht gleichzeitig mit Entwicklungsaufgaben belegt sind, weil die in einer heißen Projekt-phase dann ihre Rolle nicht mehr wahrnehmen können.
<Peter_Thierolf>	Beispiel : der Producer macht auch noch Levels.
<Peter_Thierolf>	Wenns dann krass wird, wird er Levels machen und nicht mehr Producen - das Chaos bricht aus.
<Peter_Thierolf>	Mein Gott - WELTUNTERGANG!!!
<JoBBo>	g
<DanielLudwig>	nee, nur ein unfertiges Spiel mit ner Menge Levels
<Peter_Thierolf>	vielleicht.
<Peter_Thierolf>	Obs fertig wird oder nicht hängt wahrscheinlich nicht davon ab.
<Peter_Thierolf>	Eher davon, wieviel Überziehung der Publisher toleriert.
<Peter_Thierolf>	So ab 2 Jahren wirds dann kritisch :)
<PeterDobrovka>	Habt ihr ein Budget?
<Peter_Thierolf>	Ja.
<MarcKamradt>	bei über 2 jahren ist meisten auch die engine bzw. die grafik etc. veraltet
<DanielLudwig>	wer hat keins?
<Peter_Thierolf>	Wir haben ein Zeit und ein Geld Budget.
<PeterDobrovka>	Na ja, es gibt auch monatliche Basis
<Peter_Thierolf>	Also eines zuviel :)
<MarcKamradt>	alle die sowieso kein geld für ihre arbeit bekommen
<MarcKamradt>	naja... bleibt doch noch die qualität zur skalierung
<PeterDobrovka>	Wird das Budget im Voraus bezahlt?
<Peter_Thierolf>	Nein.
<PeterDobrovka>	Aber auch nicht nach Relesase, oder?
<Peter_Thierolf>	Wir sind ja eine 100%ige Tochter der JoWooD, deshalb zahlen die monatlich.
<Peter_Thierolf>	Ein Budget haben wir aber trotzdem.
<PeterDobrovka>	Und wenn ihr es überschreitet?
<Peter_Thierolf>	Das werden wir.
<PeterDobrovka>	LOL
<Peter_Thierolf>	Und dann werden wir mal schauen...
<Peter_Thierolf>	Nein, im Ernst.
<DanielLudwig>	verhandeln, jammern, betteln, erpressen g
<PeterDobrovka>	10% aller Softwareprojekte werden innerhalb des gelpanten Zeit- und Geldrahmens fertig
<Peter_Thierolf>	Wir betreiben ziemlich viel Aufwand in der Projektplanung und versuchen das sehr gut vorher zu wissen, wieviel wir brauchen.
<MarcMueller>	@Daniel: ...und dann zu CDV wechseln :p
<DanielLudwig>	was will ich da g
<Peter_Thierolf>	Wir werden wahrscheinlich trotzdem überziehen - aber wir werden es rechtzeitig wissen.
<Peter_Thierolf>	Damit sind publisher dann schon ziemlich gut bedient.
<Peter_Thierolf>	Zumindest, wenn sie die dafür entstehende Qualität sehen.
<PeterDobrovka>	Wieviel ist denn das Budget?
<Peter_Thierolf>	So 2- 3 Millionen DM.
<Peter_Thierolf>	Oder warens 4-5 ?
<DanielLudwig>	das ist eigentlich ne "kein Kommentar" Frage
<Peter_Thierolf>	Oder 1-2?
<Peter_Thierolf>	Marc ?
<Peter_Thierolf>	Ne.
<Peter_Thierolf>	Realistisch halt.
<PeterDobrovka>	Ui! Ist da die Werbung schon drin?
<MarcKamradt>	keine ahnung
<Peter_Thierolf>	Nein.
<MarcKamradt>	zwischen 1 bis 2 mio €
<PeterDobrovka>	Andersrum gefragt: wißt ihr in etwa, wieviele Stück abgesetzt werden müssen, um in die Gewinnzone zu kommen?
<Peter_Thierolf>	Viele.
<DanielLudwig>	Wie groß ist eigentlich Neon im Moment, und sitzt ihr alle an dem Projekt?
<Peter_Thierolf>	Du fragst aber detailliert.
<MarcKamradt>	könnte man ausrechnen
<Peter_Thierolf>	Wir sind so 12 Mann an dem Projekt, aber es kommen noch mehr dazu.
<PeterDobrovka>	@marc: wenn man die Zahlen hätte
<Peter_Thierolf>	So ungefähr 6 Leute arbeiten an einem PS2 Titel.
<MarcKamradt>	ich such mal...
<Peter_Thierolf>	Sorry.
<Peter_Thierolf>	AGB.
<Peter_Thierolf>	Nicht PS2.
<DanielLudwig>	acho
<DanielLudwig>	s
<PeterDobrovka>	?
<Peter_Thierolf>	??
<MarcMueller>	GBA
<PeterDobrovka>	was redet ihr? ich verliere den Faden!
<Peter_Thierolf>	Der heißt halt AGB und nicht GBA.
<Peter_Thierolf>	Scroll rauf - such.
<MarcKamradt>	kosten + wer arbeitet bei neon an den projekten
<PeterDobrovka>	AGB = Allgemeine Geschäftsbedingungen?
<edelpils>	könnte das trotzdem jemandkurz sagen? bin grad erst reingekommen
<MarcMueller>	Advance GameBoy
<Peter_Thierolf>	Ne. Advanced Game Boy.
<DanielLudwig>	advanced gameboy
<Peter_Thierolf>	LOL
<PeterDobrovka>	Heißt der nicht Gameboy Advance?
<Peter_Thierolf>	Nicht auf der Nintendo Developer Seite.
<PeterDobrovka>	argh
<Mr_Fragman>	hehe, können sich anscheinend nicht entscheiden :)
<Peter_Thierolf>	Sorry - hat sich so in mein Gehirn gebrannt. Ich bin schon zu alt, das zu ändern.
<edelpils>	??? ich denk Gameboy Advanced?
<PeterDobrovka>	guten morgen
<Peter_Thierolf>	Lies noch mal oben nach, edel.
<edelpils>	jetzt hab ichs ja! (c:
<DanielLudwig>	also 12 Mann PS2, 6 Mann GBA, keiner mehr PC? :D
<Peter_Thierolf>	Ne, keiner mehr PC.
<tibetaner>	GBA ist umgangssprachlich für Gameboy Advance (ohne d), AGB nennt ihn dagegen nintendo
<Mr_Fragman>	:(
<Peter_Thierolf>	Außer den Tools.
<edelpils>	hmpf...naja gut
<PeterDobrovka>	PC hat ausgedient?
<PeterDobrovka>	Schade, ich bin PC-fan
<Peter_Thierolf>	Ich benutze meinen noch.
<DanielLudwig>	verstehen kann ich es ja irgendwie :)
<Peter_Thierolf>	Sonst könnte ich nicht so gut chatten...
<Peter_Thierolf>	Ich muß ehrlich sagen - die Plattform ist mir reichlich schnurz.
<PeterDobrovka>	Wie macht man eigentlich ein Spiel für die PS2?
<edelpils>	g genau, DAFÜR sind XBox & Co. noch nicht gut
<DanielLudwig>	am PC, Peter
<DanielLudwig>	g
<Peter_Thierolf>	Im Visual Studio. Da gibt es neu Integration der Compiler.
<CodeJack>	siehe Screenshot (oben)
<PeterDobrovka>	VISUAL STUDIO??
<PeterDobrovka>	Ah, stimmt!
<Peter_Thierolf>	Du hast ne PS2, die per Kabel am PC hängt und ein Filesystem emuliert.
<PeterDobrovka>	Das ist ja n Ding!
<Peter_Thierolf>	Ist eigentlich ganz locker.
<Mr_Fragman>	wär mal witzig sowas zu testen :)
<Peter_Thierolf>	Zieh Dir die Linux-PS2, da kannst Du es testen.
<PeterDobrovka>	Und habt ihr einen Controller, der an den PC angeschlossen wird?
<Peter_Thierolf>	Ne, der hängt einfach an der PS2.
<Peter_Thierolf>	Die steht hier einen halben Meter rechts auf dem Tisch.
<PeterDobrovka>	Aha, also so wie remote debugging?
<Peter_Thierolf>	So ist es.
<PeterDobrovka>	Das konnte ich mir bisher nie vorstellen.
<DanielLudwig>	darf man eigentlich die Kosten so ner DevKonsole verraten?
<Peter_Thierolf>	Das ist eigentlich Standard auf den Konsoplen.
<DanielLudwig>	oder muß ich Sony fragen?
<Peter_Thierolf>	Das geht von €10000 für ein offizielles Teil von Sony.
<PeterDobrovka>	Würde das Spiel dann auch auf dem PC laufen?
<DanielLudwig>	10000 "geht ja mal noch"
<Peter_Thierolf>	Wir arbeiten vor allem auf normalen PS2, die man von Sony ohne Kopierschutz kriegt.
<Peter_Thierolf>	Das Teil kostet dann €900.
<Mr_Fragman>	immer noch teuer genug
<MarcMueller>	Euro-Preise!
<PeterDobrovka>	warum ohne Kopierschutz?
<CodeJack>	aber besser als 10000
<Peter_Thierolf>	Dazu kommt die Soft für €5000 + €800 für die Target-Soft
<Peter_Thierolf>	Also 5000 für die Compiler etc.
<Peter_Thierolf>	Ohne Kopierschutz, damit die Target-Listener-Soft drauf läuft.
<MarcKamradt>	Info zu Gewinn für PSX-Titel: $9 Gewinn für Publisher, 20% für Devloper = $1,80... kann man Break-Even ausrechnen
<Peter_Thierolf>	Und damit man angeben kann...
<McRam>	was ist denn das für'n c complier? gnu?
<Peter_Thierolf>	Leider.
<DanielLudwig>	muß das Spiel, wenns mal fertig ist, dann noch an Sony vorbei? Wenn ja, macht ihr das oder der Publisher?
<Peter_Thierolf>	Jedes PS2 Spiel muß durch sogennante Approval bei Sony.
<McRam>	die letzte generation der psone compiler bzw. linker haben schon recht flotten code erzeugt, wie sieht das auf ps2 aus?
<MarcMueller>	Die müssen ja sicher stellen, daß es KEINEN PAtch braucht! :p
<Peter_Thierolf>	Die checken dann, ob es einwandfrei ist und allen Regeln entspricht.
<Mr_Fragman>	und wie intensiv wird da getestet?
<PeterDobrovka>	Was? 9$ für den Publisher?
<Peter_Thierolf>	Alles der Reihe nach.
<MarcKamradt>	naja... da geht mal mit dem disassembler ran... da musst du heulen
<Peter_Thierolf>	Der Code auf der PS2 ist extrem lausig.
<McRam>	assembleroptimierenrulez, eh?
<CodeJack>	genau
<MarcKamradt>	pd: kann jetzt auch nur zahlen zitieren
<Peter_Thierolf>	Es wird relativ gut geprüft, vor allem wollen die Videos haben mit dem kompletten Gameplay etc.
<DanielLudwig>	naja, ich kann mir spaßigere aufgaben vorstellen als mich durch asm code zu wühlen :)
<PeterDobrovka>	Was heißt, der Code ist lausig? Den schreibt ihr doch selber, oder meinst du das OS?
<Peter_Thierolf>	Ne, der kompilierte C++ Code.
<Peter_Thierolf>	Wenn man das per Hand machen würde wäre es 3-4 mal so schnell.
<Peter_Thierolf>	Kann man aber nicht mehr :(
<PeterDobrovka>	Hm...
<CodeJack>	leider
<PeterDobrovka>	warum nicht
<Peter_Thierolf>	Sehr leider.
<Peter_Thierolf>	Zuwenig Zeit.
<PeterDobrovka>	ach so
<MarcKamradt>	saukompliziert auf den aktuellen prozessoren
<PeterDobrovka>	ich dachte, wieder ein technischer Schmankelr
<CodeJack>	zu viel Kosten
<Peter_Thierolf>	Wenn Du 2-300.000 Zeilen Code schreibst, dann kannst Du Dir das nicht mehr leisten.
<PeterDobrovka>	Muß ja nicht alles in ASM sein
<Peter_Thierolf>	Stimmt.
<PeterDobrovka>	nur was sehr zeitkritisch ist
<McRam>	jenau
<CodeJack>	nur an den wichtigsten Stellen
<Peter_Thierolf>	Wir werden jedenfalls auch ein paar Assembler-Teile machen.
<PeterDobrovka>	na also
<Peter_Thierolf>	Freu ich mich schon drauf.
<CodeJack>	richtig
<PeterDobrovka>	welchen ASM-Code verwendet PS2?
<Peter_Thierolf>	Verschieden.
<PeterDobrovka>	das gibt es nicht
<Peter_Thierolf>	Auf der IOP-Seite ist es ein Mips R3000.
<PeterDobrovka>	Hersteller?
<Peter_Thierolf>	Mips.
<PeterDobrovka>	Und wer macht den C-compiler dafür?
<Peter_Thierolf>	Die EE basiert, glaube ich, auf einem R5500.
<Peter_Thierolf>	Dann gibts noch die Vector Units, die haben eigenen Code.
<PeterDobrovka>	Muß noch fragen, was IOP heißt
<Peter_Thierolf>	Halt Vector-Prozessor Spezial-Zeugs.
<MarcMueller>	IP Processor
<MarcMueller>	IO
<MarcKamradt>	I/O Prozessor
<PeterDobrovka>	Also mehrere Prozessoren in der Hardware, alle mit unterschiedlicher Maschienensprache?
<MarcKamradt>	die PSOne eigentlich
<Peter_Thierolf>	Das ist der Proz. aus der PS1, der macht das Teil auch kompatibel.
<Peter_Thierolf>	Ja.
<PeterDobrovka>	Hm, dann braucht ihr doch auch mehrere Compiler?
<Peter_Thierolf>	Die laufen auch alle gleichzeitig, das ist das Problem beim Verständnis und gleichzeitig die Power in der Kiste.
<MarcKamradt>	ja
<Peter_Thierolf>	Für den VU gibts keinen Compiler.
<PeterDobrovka>	vu?
<MarcKamradt>	assembler halt
<CodeJack>	Vector Unit
<MarcKamradt>	vector unit
<Peter_Thierolf>	Für den IOP und den EE-Core gibts gnus.
<MarcKamradt>	:-)
<PeterDobrovka>	hehe, gnus in der Sony-Maschine
<JoBBo>	Mehrere Prozessoren arbeiten parallel: Wie die guten alten CustomChips zu Zeiten der großen Homecomputer...
<PeterDobrovka>	kenn ich vom C64 her
<Peter_Thierolf>	Aber richtig multi-purpose Programmierbar.
<Peter_Thierolf>	Die VUs kann man mit den Vertex-Shadern in Direct-X 8 vergleichen.
<Peter_Thierolf>	Allerdings können sie auch vertexe erzeugen, was die Shader nicht können.
<McRam>	Hat die PS2 eigentlich eine art Pixelshader, kann man via ASM-Code in die Pixel-Pipline 'reinhängen'?
<Peter_Thierolf>	Und sie sind auf hardware-level dokumentiert, haben relativ viel Ram...
<MarcKamradt>	haben auch eigenen ram
<Peter_Thierolf>	Pixel-shader leider nicht.
<JoBBo>	vertexe -> vertices? :)
<Peter_Thierolf>	jaja :)
<DanielLudwig>	da gabs nen netten USF Vortrag... ich hab zwar nicht viel verstanden, aber interessant war es allemal
<Peter_Thierolf>	Im Pixel-Bereich ist die PS2 der Geforce3 weit unterlegen.
<Peter_Thierolf>	Das Teil kann nicht mal simples Multi-texturing.
<MarcKamradt>	und textur-ram ist ziemlich knapp
<McRam>	sicherlich auch wg. dem viel zu kleinen cache?
<Peter_Thierolf>	Ist eigentlich kein Cache - sondern halt das gesamte VideoRAM.
<Peter_Thierolf>	So wird es jetzt als Cache benutzt, was natürlich bandbreite zieht.
<McRam>	mit tricks kann man da aber doch sicherlich in realtime was swappen, oder?
<Peter_Thierolf>	klar.
<DanielLudwig>	gibts bei euch auch Bestrebungen Richtung X-Box oder Gamecube? Oder erstmal bedient mit PS2?
<Peter_Thierolf>	Muß man nicht mal tricksen. Das ist normale Praxis.
<Peter_Thierolf>	Ich mach gern jede Plattform. Aber nicht alle auf einmal.
<Peter_Thierolf>	Wir müssen uns erstmal auf das game konzentrieren können, weil wir gegen mächtige, große Firmen anstinken müssen und die Konkurrenz halt schon ziemlich krass ist.
	* MarcKamradt möchte gerne wissen, ob einsteiger dabei sind und wir nochmal themen wie "was muss ich machen, damit ich ein super-spieleprogrammierer werde" ansprechen sollen.
<PeterDobrovka>	Hast du eigentlich eine Vision?
<DanielLudwig>	Konkurrenz in dem Genre oder auf der Plattform?
<Peter_Thierolf>	Ich habe eine Vision.
<PeterDobrovka>	Erzähl
<Peter_Thierolf>	In dem Genre, auf der Plattform.
<DanielLudwig>	:)
<MarcKamradt>	oha
<Peter_Thierolf>	Meine Vision ist, ein Spiel herstellen zu können, das keine Kompromisse bei der Qualität machen muß, weil falsch entwickelt wurde.
<Peter_Thierolf>	Ich habe schon an so vielen Spielen gearbeitet, die schlechter wurden als sie hätten werden können, daß es eine Schande ist.
<Peter_Thierolf>	Und das ist eher ein Problem der kürzeren Vergangenheit.
<Peter_Thierolf>	Zu schnell, zu viel druck, zu wenig Verständnis von den Entscheidern, zuviele Irre im Dunstkreis des produkts...
	* havok ist Einsteiger.
<Peter_Thierolf>	Nochmal zur Konkurrenz : Wir fürchten uns nicht vor Produkten auf anderen Plattformen, das macht Sony für uns.
<DanielLudwig>	was? das fürchten?
<Peter_Thierolf>	Nein - die machen die platt.
<DanielLudwig>	achso g
<PeterDobrovka>	Wie machen die das?
<Peter_Thierolf>	Wir müssen uns aber vor Titeln auf der PS2 fürchten, weil es da schon ziemlich gute Titel gibt.
<PeterDobrovka>	Silent Hill 2?
<Peter_Thierolf>	Alles mögliche.
<PeterDobrovka>	Nochmal zur Vision: das war jetzt aber doch ein wenig allgemein formuliert. Sowas könnte jeder über jedes Spiel sagen
<DanielLudwig>	ist es dann nicht ein Risiko, gerade in diesen Bereich zu zielen?
<PeterDobrovka>	Hast du keine Vision eines bestimmten Spiels bzw. Genres?
<Peter_Thierolf>	Unser Target ist in einem etwas weniger besiedelten Bereich.
<DanielLudwig>	(nicht daß ich es nicht verstehen würde, mit Neocron hocken wir in einem ähnlichen "Boot" :) )
<Peter_Thierolf>	Ich habe keine Vision für ein ganz bestimmtes Spiel.
<Peter_Thierolf>	Da ich sowieso nicht morgen mit einem neuen anfangen könnte nutzt es doch nichts.
<Peter_Thierolf>	Der Markt ändert sich so schnell, neue Möglichkeiten werden durch neue Hardware geboren.
<Peter_Thierolf>	Während ein Spiel entsteht bekomme ich reihenweise Ideen und Lust auf bestimmte Spiele, die ich gerne machen würde.
<Peter_Thierolf>	Ich hänge nicht einem bestimmten Paradigma nach - ich möchte einfach mal mein Talent Leute perfekt zu unterhalten wirklich umsetzen können.
<Peter_Thierolf>	:)
<Peter_Thierolf>	Ich glaube auch ehrlich nicht, daß eine Spielidee so besonders ist, daß die den Erfolg bringt.
<Peter_Thierolf>	Es ist die perfekte Umsetzung eines Themas, in das man sich wirklich verliebt hat.
<PeterDobrovka>	Da stimme ich wiederum zu
<JoBBo>	Ich ebenso...
<PeterDobrovka>	Bei mir sind es die Aufbauspiele, bei anderen wahrscheinlich die Rollenspiele
<MarcKamradt>	gibt es ein spiel, das deiner vision schon ziemlich nahe kommt?
<Peter_Thierolf>	Selbst gemacht?
<PeterDobrovka>	nein
<PeterDobrovka>	oder doch
<Peter_Thierolf>	Gem'X.
<Peter_Thierolf>	Die Amiga Version.
<PeterDobrovka>	Wird das so geschrieben?
<MarcKamradt>	auch von anderen entwicklern
<Peter_Thierolf>	Da haben wir jede noch so kleine Ecke abgeschliffen und das Teil einfach perfekt machen können.
<EboMike>	whoa, voll was los in deutschland heute
<JoBBo>	Ich kenne eine Menge Amiga-Games, aber das muss mir entgangen sein...
<Peter_Thierolf>	Naja - ist über Demonware gekommen...
<Peter_Thierolf>	Von anderen Entwicklern - Half Life.
<PeterDobrovka>	Wo finden wir eine Beschreibung dazu?
<JoBBo>	Mir unbekannt.
<havok>	du hast doch auch apydia mitgemacht. das fand ich sehr geil.
<PeterDobrovka>	Du kennts HL nicht? ;)
<JoBBo>	Nein, Demonware natürlich :)
<MarcKamradt>	http://www.amigagames.com/gage/g/gem'x+.html
<JoBBo>	Thx.
<EboMike>	hehe... demonware ist schon etwas laenger unter der erde
<Peter_Thierolf>	Apidya war ganz gut aber leider weit von dem angestrebten entfernt.
<Peter_Thierolf>	Level 4 von Apidya war auch nahezu perfekt. Die anderen... naja.
<PeterDobrovka>	Hm... - Kulleraugen...
<Peter_Thierolf>	Vulcan Venture - in der Arcade.
<EboMike>	peter, mit demonware hattet ihr damals auch the power und oops up gemacht, oder?
<Peter_Thierolf>	R-Type 1 + 2 in der Arcade.
<Peter_Thierolf>	Ne. Ich habe die Dinger vertont - mehr nicht.
<EboMike>	ich vergass
	* havok liebt arcade :)
<EboMike>	stimmt, bei power hattest du musik gemacht
<EboMike>	und bei oops der chris :)
<Peter_Thierolf>	Ne - hab ich beide gemacht.
<EboMike>	oha. faux pas
<JoBBo>	Kaiko: Woran genau sind sie eigentlich gescheitert? Finanzielle oder persönliche Probleme?
<Peter_Thierolf>	Naja, war ja auch nix besonderes. Einfach weggesamplet.
<Peter_Thierolf>	Sowohl finanzielle als auch persönliche.
<JoBBo>	Verstehe...
<Peter_Thierolf>	Ich bin weg, nachdem mir von Chris und Frank gesagt wurde 'mit Dir will keiner mehr Zusammenarbeiten'.
<JoBBo>	Autsch.
<JoBBo>	Schlechtes Betriebsklima.
<havok>	Chris -> Hülsbeck?
<EboMike>	irgendwie gabs damals doch recht viele teams, die entweder ueber den tisch gezogen wurden oder von innen kaputtgegangen sind
<Peter_Thierolf>	Auf meine Frage, was ich dann hier noch soll (war der einzige Coder) wurde so ungefähr geantwortet
<MarcKamradt>	SID-Musiken von Peter sind in der HVSC-Collection: http://home.freeuk.net/wazzaw/HVSC/index2.html
<Peter_Thierolf>	'weil du ein guter coder bist'...
<Peter_Thierolf>	Naja, da bin ich halt gegangen.
<JoBBo>	:/
<Peter_Thierolf>	Es gab aber immensen finanziellen Druck. Software 2000 hatte gerade gedroht uns zu verklagen.
<JoBBo>	Weswegen?
<Peter_Thierolf>	Und dann ist der Laden an Soft2k verkauft worden und die haben ihn dann richtig kaputt gemacht.
<Peter_Thierolf>	Wir haben den Nachfolger von Gem'X, Gem'Z an Soft2k verkauft.
<JoBBo>	Ahja... Und wo war das Problem?
<Peter_Thierolf>	Dann gabs aber Schwierigkeiten, weil der Termin wegen der C64 und der PC Version nicht gehalten werden konnte.
<Peter_Thierolf>	Und die Bosse von Soft2k waren einfach - ich sags lieber nicht.
<JoBBo>	;)
<Peter_Thierolf>	Naja, ich hab gehört, die hätten ihr Geld um Soft2k zu gründen in der Hamburger Rotlicht-szene gemacht.
<Peter_Thierolf>	KA obs stimmt...
<MarcKamradt>	:-)
<EboMike>	lol
<EboMike>	waeren nicht die einzigen :-)
	[Peters Erläuterungen auf eine Frage zum Thema Turrican 3 und Factor 5 sind auf Wunsch von Factor 5 aus den Log entfernt worden.]
<MarcKamradt>	nochmal zum thema visionen: wie siehst du die zukünftige entwicklung von spielen? was wird kommen? welche techniken werden genutzt? welche genres? mobile games?
<PeterDobrovka>	Prophezeihungen gehören doch eher in die astrologie-Abteilung
<DanielLudwig>	schneller, höher, weiter?
<Peter_Thierolf>	Ich hoffe erst mal wieder auf ein Revival von 2d gameplay :)
<PeterDobrovka>	Auf Handys ganz sicher
<DanielLudwig>	in welchen sparten?
<DanielLudwig>	action?
<Peter_Thierolf>	Im moment denke ich, es gibt noch so viele ungenutzte Techniken bei der Hardware, da kann noch einiges kommen.
<JoBBo>	Die Pläne wegen guter Verkäufe, ein Turrican4 in Erwägung zu ziehen, bei dem die Feinde mit Windeln umherlaufen und man mit Babyfläschchen schiesst, hat mir engültig gezeigt, dass Factor5 etwas 'merkwürdige' Zeitgenossen waren...
<Peter_Thierolf>	Die Jungs haben sich inzwischen ihren Reichtum mehr als verdient.
<Peter_Thierolf>	Gönnen wir es ihnen.
<PeterDobrovka>	gibnts die noch?
<DanielLudwig>	sicher
<MarcKamradt>	na logo!
<PeterDobrovka>	was haben sie zuletzt gemacht?
<DanielLudwig>	in Amerika
<Peter_Thierolf>	klar. Die sind in den Staaten, haben gerade Roque Leader auf GameCube gemacht,
<MarcKamradt>	star wars von vorne bis hinten
<CodeJack>	die sind doch jetzt in den USA
<MarcMueller>	klar! Rouge Squadron (N64), Rouge Leader (GameCube)
<Peter_Thierolf>	Rogue Leader.
<JoBBo>	Jupp, die haben doch spezielle Soundkompressionsroutinen für Nintendo entworfen, oder?
<PeterDobrovka>	ach, die sind das
<Peter_Thierolf>	Was auch immer.
<MarcKamradt>	sagen wir mal: sie haben das soundsystem für nintendo entwickelt
<CodeJack>	richtig
<JoBBo>	Okay, okay...
<DanielLudwig>	obwohl ich das Starfighter-Demo(PC) recht grottig fand :)
<MarcKamradt>	vielmehr: sie habe es entwickelt und dann fand nintendo das ding besser als ihres und hats gekauft
<JoBBo>	Sie hatten nur schon beim Nintendo64 auf dem Bereich der Kompression geglänzt.
<MarcMueller>	das ist doch nicht von denen, oder?
<DanielLudwig>	ich dachte
<DanielLudwig>	(ich weiß, das soll ich lieber nicht)
<MarcMueller>	LucasArts, aber die hängen da vielleicht ja auch mit drin ;=)
<Peter_Thierolf>	Eigentlich ist es wurscht. Sie haben über eine halbe Million Rogue Squadrons verkauft, die sind jenseits von gut und Böse...
<MarcKamradt>	Besteht Interesse an dem Entwicklungsprozess bei Neon? Da könnte Peter sicher auch einiges erzählen...
<MarcKamradt>	Vom Design zum Spiel - wie geht das.... so in der Art
<CodeJack>	auf jeden Fall
	* havok würde das interessieren.
<Peter_Thierolf>	Wie ausführlich hättet ihr das gerne?
<Peter_Thierolf>	Interessiert an bestimmten Teilen?
<DanielLudwig>	wieviel Anteil hat das komplette Team z.B. beim aktuellen Projekt am Konzept?
<DanielLudwig>	oder setzt es nur um?
<Peter_Thierolf>	Es gibt ein kleines Core-Design team, das sind, glaube ich, 4 Leute.
<Peter_Thierolf>	Dei schreiben das Game Design Doc und pflegen es.
<Peter_Thierolf>	Alle können ihr Meinung loswerden und Vorschläge machen, aber das Design-Team hat die Oberhand.
<DanielLudwig>	Gabs schon vom Ursprungskonzept abweichende Kurswechsel (aus welchen Gründen auch immer)?
<Peter_Thierolf>	Es ist allerdings auch mehr als genug arbeit, die Vorstellungen des Design-Teams halbwegs in umsetzbare Features zu verwandeln.
<PeterDobrovka>	Was haben die denn für abgefahrene Ideen?
<Peter_Thierolf>	Erst mal zu den Kurswechseln:
<Peter_Thierolf>	Es gab zum Beispiel einschneidende Streichungen, kann man das als Kurswechsel beschreiben ?
<DanielLudwig>	ja, meiner Meinung nach schon
<Peter_Thierolf>	So richtig von der ursprünglichen Idee abgewichen ist es nicht, aber die Gewichtung der Teile verschiebt sich schon mal ein bißchen.
<Peter_Thierolf>	Die abgefahrenen Ideen sind ganz normale Wünsche ganz normaler High-end Spieler, die aber nicht immer realisierbar sind.
<Peter_Thierolf>	Zum Beispiel vollständig prozedurale Kleidung...
<DanielLudwig>	ohje, das kenn ich irgendwoher
<MarcKamradt>	angst
<JoBBo>	:)
<Peter_Thierolf>	tröst - das lassen wir streichen...
<MarcKamradt>	puha
<DanielLudwig>	obwohl die schlimmsten Ideen von den Fans kommen
<MarcMueller>	...aber im nächsten Projekt!! g
<Peter_Thierolf>	Fan-Ideen sind oft so schlimm, weil sie oft gar nicht zum Produkt dazupassen.
<Peter_Thierolf>	Ein Beispiel : Ein Level-orientiertes Game.
<Peter_Thierolf>	Der Fan wünscht sich 'es wär doch cool wenn man so ein Item einsammelt, daß man überall hinfliegen kann'.
<Peter_Thierolf>	Und schon das ganze design zerschossen...
<Peter_Thierolf>	Es gibt halt immer wieder so viele subtile Bedingungen die alles zusammenhalten, da kann man nicht so einfach einwirken.
<Peter_Thierolf>	Eine Spielwelt muß halt am Ende konsistent bleiben.
<Peter_Thierolf>	Gut. Ein bißchen was zu dem grundlegenden Prozess.
<Peter_Thierolf>	Zuerst machen die Designer ein Design-doc, das ganz schön gut ist (soll heißen, es ist ausgegoren.)
<JoBBo>	Ja, aber man sollte Laien nicht wirklich vorwerfen, dass sie sich darüber keine Gedanken machen. Es kommt SOOOO OFT vor, dass selbst professionelle Kunden keinen Schimmer haben, was sie genau wollen und permanent mit sich widersprechenden Anforderungen aufwarten...
<DanielLudwig>	wieviel (Vor-)Arbeit steckt da drin, zeitmäßig?
<Peter_Thierolf>	Dann gehen wir Code hin und Erfassen die Anforderungen oder Requirements an die Software, die man aus diesem Doc ableiten kann.
<Peter_Thierolf>	Sorry - war schon am schreiben.
<Peter_Thierolf>	Also - das mit den Widersprechenden Anforderungen ist jetzt gerade das wichtigste.
<Peter_Thierolf>	Es ist der Job der Coder in Interviews etc. genau herauszufinden, was der Kunde wirklich will und braucht.
<Peter_Thierolf>	Steht im Design-Doc zum Beispiel drin, wie irgendwas in Module aufgeteilt wird, dann ignorieren wir das mal gleich - schließlich sind wir die Fachleute für sowas.
<JoBBo>	Leuchet ein. Das trifft übrigens auch auf andere Berufszweige zu. (Sind ja nicht alle Coder.)
<Peter_Thierolf>	Ist klar - wir müssen halt jetzt genau rausfinden was drinsteht - und das abgrenzen.
<Peter_Thierolf>	Also den Jungs auch ganz genau erklären welche Auswirkung z.B. auf die Performance oder die Zeitplanung an bestimmten Wünschen hängen.
<Peter_Thierolf>	Naja - so erfassen wir jedenfalls die Anforderungsliste, die jeweils links in das Gamedesign-doc enthält.
<Peter_Thierolf>	Die muß dann gepflegt werden - es ist super wichtig, das Ding möglichst bis zum Master auktuell zu halten.
<Peter_Thierolf>	Aus der Anforderungsliste entwickeln wir dann die Feature-liste der Software.
<pvcf>	sag mal redet hier nur der peter oder warum sehe ich keine anderen texte?
<MarcMueller>	lol
<MarcKamradt>	:-)
<Peter_Thierolf>	Sorry.
<Peter_Thierolf>	Ist so monolog.
<Peter_Thierolf>	Aber frag ruhig was.
<MarcKamradt>	peter geht gerade mal über den entwicklungsprozess bei neon
<pvcf>	ahja, weis ja nicht warums geht ... lol
<havok>	ich find's interessant
<pvcf>	jaaa, will nix unterbrechen ;)
<Peter_Thierolf>	Also gerade gings darum, daß wir aus den Designern, die das Game-design-doc gemacht haben eine Anforderungsliste rauskitzeln.
<Peter_Thierolf>	Da steht dann drauf, was sie wirklich haben wollten.
<pvcf>	ahja, gehts jetzt darum wie man ein gutes GDD macht?
<Peter_Thierolf>	Alles weggekürzt und erklärt und abgegrenzt, so daß es wirklich eindeutig ist und das ganze rausch-gebabbel aus dem Doc weg ist.
<Peter_Thierolf>	Ne, da hat keiner gefragt...
<Peter_Thierolf>	Kann ich aber auch drüber tippen.
<MarcKamradt>	eher, wie man das doc so nutzt, das ein spiel unten rausfällt
<MarcKamradt>	erklär doch erstmal den prozess fertig...
<pvcf>	yo!
<Peter_Thierolf>	In den Requirements steht zum Beispiel bei uns drin 'BALANCIEREN auf "Baumstämmen". Baumstämme sind normale Hintergrundgrafik mit einer nur sehr '
<MarcKamradt>	dann können wir ja nochmal details besprechen
<Peter_Thierolf>	Das ist ein echtes.
<Peter_Thierolf>	Hupps - aber hinten abgeschnitten... Pech.
<Peter_Thierolf>	Könnt ihr euch das trotzdem vorstellen ?
<Peter_Thierolf>	Ne ???
<MarcKamradt>	ich schon... wie steht's mit den anderen?
<Peter_Thierolf>	Naja, hier ein anderes 'Es soll Tür bzw. Tor Objekte geben. Diese sollen auch abgeschlossen sein können.'
<MarcKamradt>	ich mache das ja auch
<DanielLudwig>	nicht so richtig, mit dem halben satz g
<Peter_Thierolf>	So. Das ist ein echtes Requirement, das aus dem Game-design-doc kommt.
<Peter_Thierolf>	Das ist auch ein ganz gutes Beispiel, um den Unterschied zwischen Requirements und Features zu erklären.
<Peter_Thierolf>	Aus diesem Teil sind eine ganze Menge Features in unserer Software entstanden.
<Peter_Thierolf>	Zum Beispiel die Tatsache, daß es dynamische Kollisionen gibt.
<Peter_Thierolf>	Also in unserer Feature-Gruppe 'Kollisionen' halt den Unterpunkt 'Dynamische Kollisionen'.
<DanielLudwig>	gäbe es die ohne die Türen nicht? :)
<Peter_Thierolf>	Vielleicht schon - aber wir gehen strikt nach den Requirements vor.
	* MarcKamradt empfiehlt folgende bücher zum thema: "software project survival guide", "mastering the requirements process", "Der Rational Uniifed Process"
<PeterDobrovka>	Ich stehe etwas auf dem Schlauch - kann es sein, daß hier halbe Sätze verschluckt werden?
<Peter_Thierolf>	??
<PeterDobrovka>	Was war mit den Baumstämmen?
<DanielLudwig>	nur der mit den Baumstämmen, Peter
<MarcMueller>	bis auf den einen mit den Baumstämmen eigentlich nicht :)
<Peter_Thierolf>	Sorry - die Baumstämme. Willst Du die noch mal ganz sehen ?
<PeterDobrovka>	ja
<Peter_Thierolf>	Hier die Baumstämme.
<Peter_Thierolf>	BALANCIEREN auf "Baumstämmen". Baumstämme sind normale Hintergrundgrafik mit einer nur sehr geringen Fläche zum drauf laufen, die jedoch mit speziellen Informationen für Steuerung und eventuell Kamera versehen sind.
<Peter_Thierolf>	Unser Baumstamm Requirement.
<PeterDobrovka>	Und das ist ein Requirement?
<Peter_Thierolf>	Jawoll.
<PeterDobrovka>	Und ein Feature wäre im Gegensatz dazu was?
<Peter_Thierolf>	Zugegebenermassen könnte man da noch etwas tech-talk rausnehmen.
<Peter_Thierolf>	Features sind bei uns eine Hierarchische Liste, ich versuche hier mal einen Auschnitt zu geben...
<pvcf>	wenn du die baumstämme nutzen könntest_
<MarcKamradt>	peter sucht beispiele
<Peter_Thierolf>	Hier eines der Features, das daraus abgeleitet ist :
<Peter_Thierolf>	Player/Reaktionen auf Umwelteigenschaften und Gegner/Handling von Oberflächeneigenschaften
<Peter_Thierolf>	Die Schrägstriche geben die Hierarchie an.
<MarcKamradt>	also: design-doc mit requirements = sicht des game-designers; features = sicht des programmierers
<PeterDobrovka>	Aha, so wird das klarer
<pvcf>	nee, features gibts erst MIT den requirements, oder?
<Peter_Thierolf>	So, ich habe einen Screenshot aus unserem Requirement-Management Programm gemacht
<Peter_Thierolf>	Marc lädt das hoch.
<Peter_Thierolf>	Die Features leiten sich aus den Requirements ab.
<pvcf>	also en featrues benötigt ein req
<MarcKamradt>	chat_2002_08_04_pt_reqman.jpg
<MarcKamradt>	yup!
<Peter_Thierolf>	Ihr seht da die Hierarchie von Features, ein Zweig ist aufgeklappt, bis zu dem gerade geposteten Punkt.
<Peter_Thierolf>	Unten könnt ihr die Requirements sehen, aus denen sich der selektierte Punkt ableitet.
<pvcf>	also so ein GDD hab ich noch nie gesehen, das ist doch eins?
<Peter_Thierolf>	Das ist keins. Das sind die Features der Software.
<Peter_Thierolf>	Das GDD ist einfach ein Word-Dokument.
<DanielLudwig>	das ist gemein, ich sehe ne menge geplanter Bewegungsarten, das macht Neugier auf mehr Infos :( ;)
<pvcf>	und was genau ist dann der screenshot?
<pvcf>	sieht praktisch aus...
<Peter_Thierolf>	Was Du siehst ist ein Database-Tool, das Requirements, Features, Releases, Milestones und Tasks verwalten kann.
<pvcf>	coool
<pvcf>	wie teuer?
<DanielLudwig>	das Milestones Icon paßt nicht g
<Peter_Thierolf>	Also wird aus dem GDD die Requirement Liste gemacht, hier reingetan und dann können die Coder loslegen ihre Features etc. draus zu machen.
<Peter_Thierolf>	Ich hatte kein anderes - das Tool ist selbst gemacht.
<MarcMueller>	also unbezahlbar ;)
<Peter_Thierolf>	Schick mir ein besseres...
<pvcf>	ahja :)
<MarcKamradt>	einfach ein :-(
<Peter_Thierolf>	Na klar. Aber Milestones sind ein :-), wenn man sie hinter sich hat.
<MarcKamradt>	ok...
<Peter_Thierolf>	Vielleicht sollte sich das Icon abhängig davon, ob mehr erfüllte oder unerfüllte Milestones in der Liste sind ändern.
<MarcKamradt>	:-)
<DanielLudwig>	da hab ich ja was angerichtet
<Peter_Thierolf>	Gut - zurück zum Thema.
<Peter_Thierolf>	Eigentlich sollte jetzt für jedes Feature mindestens ein Requirement da sein und für jedes Requirement mindestens ein Feature.
<PeterDobrovka>	Also, der Designer schreibt Rquirements, der Coder übersetzt es in features
<Peter_Thierolf>	Fast richtig - wir lassen die Designer allerdings die Requirements nicht selber schreiben sondern machen Interviews, um die zu erfahren.
<PeterDobrovka>	Ein guter Coder macht aus 10 Requirements 1 Feature, hehe
<MarcKamradt>	das wär schön
<MarcKamradt>	manchmal geht das, aber umgekehrt kommt häufiger vor
<Peter_Thierolf>	Da sprichst Du einen wichtigen Punkt an - wenn man wirklich alle Requirements hätte, dann könnte man sehr schön redundanzen eliminieren.
<Peter_Thierolf>	Leider ist es aber meistens so, daß sich Requirements im Laufe der Entwicklung ändern, welche dazukommen und andere wegfallen.
<PeterDobrovka>	Hm. - Die Designer verstehen vom Coden rein gar nichts?
<Peter_Thierolf>	Das ist einer der Gründe, das in der Datenbank zu halten, weil wir so besser tracken können, was passiert.
<Peter_Thierolf>	Die können soviel vom Coden verstehen, wie sie wollen. In diesem Projekt sind sie Designer - und wir die Coder,
<Peter_Thierolf>	die sollen ihren Job machen, wir machen unseren.
<PeterDobrovka>	Ich meine wegen der Interviews
<PeterDobrovka>	daß ihr ihnen aus der Nase ziehen müßt,was sie eigentlich wollen
<Peter_Thierolf>	Da gehts einfach darum, daß in unserem Kopf die Architektur der Engine entstehen muß, die sich dann ja auch in den Features niederlegt.
<Peter_Thierolf>	Und die Architektur gibt dann die Grenzen, in denen wir uns bewegen.
<PeterDobrovka>	Ist das eine allgemein verbreitete Art der Zusammenarbeit?
<Peter_Thierolf>	Ich hoffe.
<Peter_Thierolf>	Für die anderen.
<DanielLudwig>	auf jeden Fall nicht so formell, soviel kann ich sagen g
<PeterDobrovka>	Ich kenn das anders. Der Designer schreibt sich wie er es sich vorstellt, und der Coder muß sich dann überlegen, wie er das umsetzt
<Peter_Thierolf>	Wir müssen halt die Designer von den Auswirkungen ihrer Entscheidungen informieren, weil nur wir das abschätzen können.
<PeterDobrovka>	Reden nur im Notfall
<Peter_Thierolf>	Es gibt hunderte von Entscheidungen zu treffen und um das klären zu können muß man eben sehr viel miteinander reden.
<Peter_Thierolf>	Es ist ja gerade so, daß wir in den Interviews miteinander Reden und Wissen austauschen.
<Peter_Thierolf>	Würden die Designer einfach Requirements eingeben, die danach gelten, dann wäre eine Menge unseres Coder-Knowhows aus der Entscheidungspipeline draußen.
<Peter_Thierolf>	Naja, gleichzeitig mit den Features machen wir halt die Architektur. Das sind bei uns vereinfachte UML-Skizzen.
<Peter_Thierolf>	Vereinfacht heißt, wir schreiben nicht die ganzen Klassen auf sondern konzentrieren uns auf die Beziehungen.
<Peter_Thierolf>	Nicht mal die kompletten Interfaces landen im Diagramm - das bläht sich dann unwahrscheinlich auf.
<DanielLudwig>	ganze Klassen wäre wohl auch Overkill
<Peter_Thierolf>	Nun - wenn wir jetzt Features eingebaut haben, die aus keinem Requirement entstanden sind, dann haben wir
<Peter_Thierolf>	a) zuwenige Requirements gekriegt
<Peter_Thierolf>	(das müssen wir dann aber belegen können)
<Peter_Thierolf>	b) Features noch nicht richtig zugeordnet
<Peter_Thierolf>	c) Gold-plating betrieben.
<PeterDobrovka>	gold was?
<Peter_Thierolf>	Gold-plating wollen wir unbedingt verhindern. Das ist ein Effekt der auftritt, wenn sich Programmierer in z.B. ein cooles Interface verlieben
<Peter_Thierolf>	Und Klassen einbauen, die sie nur selber brauchen.
<DanielLudwig>	eigentlich brauchts keiner, aber dem Coder war danach g
<Peter_Thierolf>	Zum Beispiel eine Scripting-engine, die keiner braucht...
<Peter_Thierolf>	Sowas passiert sehr häufig - hab ich schon oft genug gemacht.
<DanielLudwig>	ich glaube, Spiele-Coder sind da besonders anfällig ;)
<Peter_Thierolf>	Kann schon sein.
<Peter_Thierolf>	Es kann auch der Fall auftreten, daß für Requirements kein Feature da ist.
<CodeJack>	genau
<Peter_Thierolf>	In diesem Fall wird offensichtlich einem Wunsch der Designer nicht entsprochen, also müssen Features dazugebaut werden.
<Peter_Thierolf>	Wir machen das hier relativ stur nach dem Schema, auch wenn wir schon sehen, daß es viel zu langen dauern wird.
<Peter_Thierolf>	Also, das dann umzusetzen.
<Peter_Thierolf>	Das Streichen von Sachen ist nämlich nicht unser Job, sondern das machen Producer und Designer nachdem sie die Zeitplanung gekriegt haben.
<DanielLudwig>	was wird dann gestrichen? Requirements, und damit fallen dann auch Features weg?
<Peter_Thierolf>	Jawoll.
<Peter_Thierolf>	Features können nicht gestrichen werden.
<DanielLudwig>	also im Notfall läuft die Figur halt über Baumstämme wie auf einer Straße
<Peter_Thierolf>	Naja - dann werden die Features so gruppiert, daß wir über den gesamten Projektverlauf eine vernünftig verteilte Anzahl Zwischen-releases kriegen.
<Peter_Thierolf>	So ist es.
<Peter_Thierolf>	Indem man allerdings an den Requirements streicht sieht man auch gleich, was eben wegfällt.
<Peter_Thierolf>	Streichst Du in einer ad-hoc geplanten Engine irgendein Feature, sagen wir z.B. dynamische Vertex-buffer,
<Peter_Thierolf>	dann weißt Du zunächst nicht, was Deinem Spiel am Ende fehlen wird.
<DanielLudwig>	das könnte dann zusammenfallen wie ein Kartenhaus g
<Peter_Thierolf>	Das Spiel würde halt ganz anders aussehen müssen.
<Peter_Thierolf>	Was es dann halt auch würde....
<Peter_Thierolf>	Die ganze Sache ist zugegebenermassen ziemlich formell.
<Peter_Thierolf>	Wir haben allerdings auch viel zuwenig Zeit zu verschenken.
<DanielLudwig>	ist diese Prozedur angelernt/angelesen, oder aus der Praxis entstanden?
<Peter_Thierolf>	Beides.
<Peter_Thierolf>	Wir haben einiges an Literatur verschlungen, als wir mit den herkömmlichen Methoden massive Probleme bekommen haben.
<DanielLudwig>	naja, ich seh das ganze im Prinzip auch bei uns, allerdings eben gerade nicht so formell, das geb ich zu
<Peter_Thierolf>	Dann haben wir bei bestimmten vorgeschlagenen Dingen einfach erkannt, daß sie richtig sind....
<DanielLudwig>	da muß dann das Team stimmen...
<Peter_Thierolf>	Das Team muß immer stimmen, da führt kein weg dran vorbei,
<MarcKamradt>	zum Thema Entwicklungsprozess noch interessant: Feature Driven Development / http://www.nebulon.com/articles/index.html
<Peter_Thierolf>	aber einen Höllenjob wie ein PS2 game mit fixem Zeitrahmen ohne vernünftige Methodik anzugehen ist mir etwas zu abenteurlich.
<DanielLudwig>	Marc, könntest ja mal die Empfehlungen auf deine Seite packen :)
<MarcKamradt>	werde ich
<Peter_Thierolf>	Wir habens oft anders versucht und es ist immer schiefgegangen.
<Peter_Thierolf>	Es ist halt so, daß ein einzelner Monat (geht schnell vorbei) schon soviel Kohle kostet, daß man nicht erst danach merken darf, daß man in die falsche Richtung gerannt ist.
<Peter_Thierolf>	Vor allem weil ja alles aufeinander aufbaut.
<Peter_Thierolf>	Ganz hinten sitzen immer die Leveldesigner, die armen Säue.
<PeterDobrovka>	Aber in solch ausgeklügelte Organisationnstrukturen muß man doch erst mal reinwachsen, oder?
<Peter_Thierolf>	Die müssen alles zusammenbauen, was sie von uns kriegen.
<Peter_Thierolf>	Und von den Grafikern etc.
<Peter_Thierolf>	Da muß man gar nicht so reinwachsen, weil die Sachen eigentlich in allen Teams da sind.
<Peter_Thierolf>	Jedes Team erarbeitet Requirements und Features etc.
<DanielLudwig>	bei uns ist der Lead Level einer der Entscheidungsträger, der sitzt nicht ganz hinten :)
<Peter_Thierolf>	So war das nicht gemeint, ich meinte in der Produktions-pipeline.
<PeterDobrovka>	Jedes Team erarbeitet Requirements und Features? Was sind hier Teams?
<DanielLudwig>	allerdings stimmt die Bezeichnung Level Designer schon nicht mehr g
<Peter_Thierolf>	Zum Beispiel auch der einzelne Programmierer-Designer, der das Spiel ganz alleine macht.
<MarcKamradt>	team = eine gruppe von personen, die ein projekt bearbeitet
<Peter_Thierolf>	Auch er fällt irgendwann während der Arbeit über die ganzen Anforderungen und Features etc.
<Peter_Thierolf>	Wenn er allerdings die Bedeutung nicht erkennt, dann ist die Chance groß, das er ihnen nicht den richtigen Wert beimisst.
<Peter_Thierolf>	Und dann können sich massive Probleme später im Projekt ergeben.
<Peter_Thierolf>	Nun badet der Programmier-Design-Grafiker seine Probleme selbst aus.
<Peter_Thierolf>	In unserem Projekt können die Level-designer erst dann anfangen, Produktuins Levels zu bauen, wenn die Tools fertig und stabil sind,
<Peter_Thierolf>	der Code zum Replay der Levels da ist und die Grafiken fertig sind.
<DanielLudwig>	auch ein Punkt pro Technologie-Lizensierung
<Peter_Thierolf>	Dann ist schon so wenig Zeit, daß jeden Monat drei fertige Levels entstehen müssen.
<MarcKamradt>	auf jeden fall
<Peter_Thierolf>	Und damit das geht müssen wir ganz genau wissen, was die Tools können müssen, was wir programmieren müssen etc.
<Peter_Thierolf>	Wenn das Schief geht - dann Gnade uns Gott.
<Peter_Thierolf>	Wenn man hier mit den Millionen spielt - dann muß man auch aufpassen, was man tut.
<DanielLudwig>	was ist euer Zeitrahmen? oder wurde das schon erwähnt?
<Peter_Thierolf>	Insgesamt knapp 2 Jahre, vom Startschuss (also Anfang GDD-schreiben) bis Release.
<DanielLudwig>	davon ist übrig?
<MarcKamradt>	Wir würden gerne in Kürze zum Ende der Session kommen, wenn nicht noch direkte Fragen zu angesprochenen Themen da sind...
<Peter_Thierolf>	Da muß man allerdings bedenken, daß das drei Territorien sind (Japan, Europa und US Version unterscheiden sich) und am Ende das Approval von Sony Zeit verbraucht
<Peter_Thierolf>	Übrig sind ca. 15 Monate
<DanielLudwig>	die sind schnell vorbei...
<Peter_Thierolf>	schwitz
<DanielLudwig>	dann mal zurück an die Tastaturen :)
<Peter_Thierolf>	Jetzt nicht mehr Feierabend.
<Peter_Thierolf>	Da fehlte ein Punkt...
<CodeJack>	genau
<MarcKamradt>	ok... dann sage ich jetzt mal vielen dank an alle, die da waren und sich beteiligt haben. das log wird in kürze online gestellt.
<Peter_Thierolf>	Jo - ciao allen.
<DanielLudwig>	bitte, bitte g
<havok>	super sache :)
<Peter_Thierolf>	Demnächst im USF...