ZFX
ZFX Neu
Home
Community
Neueste Posts
Chat
FAQ
IOTW
Tutorials
Bücher
zfxCON
ZFXCE
Mathlib
ASSIMP
NES
Wir über uns
Impressum
Regeln
Suchen
Mitgliederliste
Membername:
Passwort:
Besucher:
4441827
Jetzt (Chat):
25 (0)
Mitglieder:
5239
Themen:
24223
Nachrichten:
234554
Neuestes Mitglied:
-insane-
"Pandora's Box" von Stefan Zerbst (Stefan Zerbst)


Aufgrund der kleinen IOTW Flaute zeige ich mal wieder ein paar neue Shots des Spiele-Projekts für das im Juli erscheinende Kompendium bei Markt und Technik und hoffe damit niemanden zu langweilen :)

Zur Beleuchtung
Auf den ersten fünf Bildern sieht man verschiedene Eindrücke aus dem Testlevel. Die Helligkeit der Shots ist per Paint Shop verstärkt worden, damit man was erkennen kann, im Spiel wirkt die düstere Atmosphäre natürlich besser. Die gesamte Berechnung der Beleuchtung erfolgt in Echtzeit, das heisst die Lichtquellen können zur Laufzeit abgeschaltet werden, ihre Intensität oder Position ändern usw. Damit ist ein Level auch nahezu ohne Kompilierzeit direkt spielbar, es wird dieselbe Datei verwendet die man auch im Level-Editor bearbeitet. Einzig die Erstellung des Octrees kostet je nach Grösse des Levels beim Laden ein paar Sekunden Wartezeit. Für die Beleuchtung wird eine Grafikkarte benötigt, die Vertex- und Pixel-Shader jeweils in der Version 1.1 unterstützt.

Zu den Bottlenecks:
Die Framerate ist direkt abhängig von der Anzahl der im View Frustum liegenden, aktiven Lichtquellen, der Polygoncount ist dabei nach der Anzahl der Textur-Switches das dritte, aber eher unbedeutende Kriterium für die Performance.

Zur Struktur der Engine:
Die Gameengine verwendet für das Rendern ein Portalsystem mit handgesetzten Portalen, die auch beispielsweise durch eine geschlossene Tür deaktiviert werden. Die Kollisionsabfrage verwendet einen Octree je Sektor der dafür sorgt, dass der Spieler Treppen und Schrägen bewältigen, Absätze herunterfallen und nicht durch Wände laufen kann.

Zur Performance (auf GeForce 4 Ti 4200):
Die Performance beträgt minimal 40 fps im Fenstermodus mit 1280x1024 Desktop, bzw. 50 fps im Fullscreen Modus bei derselben Auflösung. Kleinere Auflösungen erhöhen die Framerate, da die Fillrate der Grafikkarten den Bottleneck darstellt.

Zum Editor:
Im Editor, den man im Screenshot unten rechts sieht, wird eine vereinfachte Lichtdarstellung verwendet um das Handling der Lichtquellen schneller zu machen. Aufgrund des nicht optimierten Renderns geht bei der Aktivierung der Beleuchtung im Editor die Framerate stark in die Knie. Aber bis zu 10 Lichtquellen können in beinahe flüssiger Geschwindigkeit dargestellt werden, so dass man einen guten Eindruck der späteren Beleuchtung erhält und das Licht entsprechend platzieren kann. Ebenso wie Polygone und Meshs können einzelne Lichtquellen natürlich beim Editieren ausgeblendet werden. Auch das Speichern (und Laden) einzelner Teile des Levels als sogenannte Prefabs ist möglich, so dass man nicht immer wieder dieselbe Geometrie für gleiche Objekte erstellen muss.

To-Do Liste:
o Client/Server Game-Code trennen
o Bots KI implementieren
o Shadow-Giver im Editor einbinden
o Character Animation mit Matrix Palette Skinning Shader
o Shadow Volumes der Bots

Bitte um Feedback :D






Von Header am 30.04.2003, 00:13:37 Uhr
Hi!

Das sieht wirklich super Spitze aus !!
Da fällt einem nur ein einziges Wort ein.

Respekt !!

PS: Achja, sind in der Level auch sich bewegende Object ( zb. Kran für die Kissten .. etc ) ?

Bye

Von Stefan Zerbst am 30.04.2003, 07:05:16 Uhr
Hi,

Danke :)

Bewegende Objekte gibt es schon, allerdings nur seitlich gleitende Türen. Den Kran könnte man jedoch ganz analog animieren.

Ciao,
Stefan

Von Header am 30.04.2003, 07:41:43 Uhr
Hi!

Ich dachte immer das Octree-Level-System verwendet man eher in Outdoor Engines oder ?


Bye

Von Stefan Zerbst am 30.04.2003, 08:05:43 Uhr
Hi,

beim Outdoor dient ein Octree eher dazu, sichtbare Bereiche zu bestimmen die gerendert werden müssen. Dazu verwende ich ihn nicht, sondern zur Kollisionsabfrage.

Damit ist die Komplexität des Levels (Polycount) beinahe unentscheidend für die Geschwindigkeit der Kollisionsabfrage weil man nicht sichtbare Stellen schnell aussortieren kann ;)

Andere Techniken, wie beispielsweise der BSP Baum, setzen eine besondere Anordnung der Polygone voraus. Der Octree funktioniert auf einer beliebigen Menge aus Polygonen.

Ciao,
Stefan

Von ToyToy am 30.04.2003, 08:07:40 Uhr
Sieht echt stark aus, fehlt eigentlich nur noch Bump Mapping damit Doom 3 Feeling aufkommt :)

Von Return FALSE am 30.04.2003, 09:20:26 Uhr
wirklich nicht schlecht!!!

eine sache die ich vermisse sind schatten... eines der wichtigsten sachen, wichtiger als bumpmapping. bumpmapping ist easy und schnell wenn die hardware soweit ist... aber ne wirklcih gute shadow engine. für statische
lichter kann schon im voraus der schatten recht komplex und echt berechnet werden, auch softshadows. Die Kisten, der Kran, müssten umbedingt schatten werfen.. und hut ab vor dem, welcher ne anständige framerate hinbekommt, schatten für dynamische lichtquellen zu rendern.
Mit VS kann das ShadowVolume um einiges schneller berechnet werden, leider hab ich das problem, das die Methode fehlschlägt, falls sich die kamera im Volume befindet... ich habe kürzlich eine Email von Carmack gelesen, hatte genau dasselbe problem.

Doom3, der schatten ist dort eine der hauptgründe das es so cool wirkt, unter anderem selfshadowing der wände. Ich habe ausserdem immer mühe mit durchgehend dunklen levels. Sicher gehört das dazu, aber aber so wichtig wie das Dunkle und der Schatten ist, ist auch das konsentrierte licht. Genau gleich wie dynamische schatten, kann man einen lichtschein der aus einer tür fällt in einem volume modelieren, und vor der türe aufhellen.

Alles leichter gesagt als getan, ganz klar, leider ist der konsument heute ungeheuer (und das ist noch untertrieben) verwöhnt/heikel.

aber abgesehen davon habe ich schon aktuelle kommerzielle spiele mit weniger guten grafik gesehen, und schlussendlich kommt es für mich nicht nur auf die grafik draufan (obwohl ich da leider fast allein stehe, kommt mir manchmal vor)

alles in allem kann sich diese Engine durchaus sehen lassen, die framerate ist sehr befriedigend.
:) leider kann man aus der framerate nicht so genau schätzen wie viel potenzial noch darin liegt :) ich bekomme immer nen schock wenn ich was neues implementiere, wie sie sinkt.

wenn die todo liste mit einer guten fps bis am juni steht, lohnt sich das geld für das buch sicher allemal :)

letzte frage: schreibst du vs und ps in asm, oder benutzt du cg oder HLSL (oder stellst du ein DWORD array zusammen LOL)? was für shader hast du? transformierung und beleuchtung und sonst noch was? was für beleuchtungsarten gibt es?

Gruss
Return FALSE

Von ONeinONeill am 30.04.2003, 10:09:32 Uhr
Hallo,

sieht wirklich sehr gut aus und motiviert umso mehr. Kann mich Return False aber nur anschliessen, auch die Fragen, :D!

Von Stefan Zerbst am 30.04.2003, 10:27:52 Uhr
Hi,

realistische Schatten gehören sicherlich mit zu den wichtigsten Elementen. Bisher ist es so geplant, dass nur die Bots Schatten werfen, da der Game Code so einfach wie möglich bleiben sollte. Wie ReturnFALSE schon sagte ist ein vernünftiges Schattensystem knifflig (=komplex).

Aber selbst wenn die Lichter dynamisch sind, so gibt es vieles mit dem man tricksen kann. Die meisten der Lichter werden sich ja nicht bewegen, und entweder an oder aus sein. Nur wenn ein Licht seine Position ändert müssen die Shadow Volumes der statischen Elemente neu berechnet werden. Ausserdem könnte man für die Levelpolygone ein Flag einbauen, ob sie Schatten werfen sollen oder nicht. Markante Objekte wie beispielsweise den Kran könnte man als Mesh Entites modellieren und ihnen als Eigenschaft "Cast Shadow" zuordnen. Das dürfte schon einiges zur Atmosphäre beitragen.

Was die Shader angeht, so verwende ich reine ASM Shader, bisher je zwei VS und PS an der Zahl. Ein Shader Paar ist für den Ambienten Pass und ein Shader Paar für die Passes der Lights. An Lichttypen gibt es nur Omni Lights, die mehr oder weniger Point Lights entsprechen. Damit kann man aber auch gut Spot Lights simulieren :)

Was auf den Shots auch noch nicht zu sehen ist, das ist das Material welches natürlich auch berücksichtigt wird. Bei den 3D Objekten für die Lampen sieht man nun die Textur der Lampen in vollem weiss erscheinen, und nicht so dunkel wie hier auf den Bildern.

Ciao,
Stefan

Von ONeinONeill am 30.04.2003, 10:29:27 Uhr
Wie wäre es mit einer kleinen Techdemo? Würde das Level gerne mal in Real-Time sehen!

Von Stefan Zerbst am 30.04.2003, 10:34:17 Uhr
Hi,

wir arbeiten gerade daran, einen Beta-Test Bereich für ZFX zu implementieren. Sobald der da ist werden die Tech-Demo und der Editor in ein Beta-Programm geschubst, um erst mal die Lauffähigkeit auf verschiedenen Hardwareplattformen zu evaluieren. Danach wird die Tech-Demo vor dem Druck des Buches auf alle Fälle downloadbar sein :)

Ciao,
Stefan

Von Skyrider am 30.04.2003, 10:34:40 Uhr
Hi,

sieht nicht schlecht aus! richtig gut!

wäre es nicht auch möglich zu der aktuellen geometrie (high-poly) noch eine low-poly version zu machen und darauf den octree zu bauen?
oder bremmst die füllrate der graka so sehr das der octree mit vielen polys nicht ins gewicht fällt. auf jedenfall würde man bestimmt einiges an cpu zeit sparen wenn die kollission nicht mit der high-poly version gemacht wird.

natürlich müsste man dann nebenher noch die low-poly version mit transformieren etc.

gesehen habe ich das schon bei mehreren konsolen-spielen (jump-and-runs).

was hällst du/ihr davon?

Von Stefan Zerbst am 30.04.2003, 10:40:25 Uhr
Hi,

@Skyrider
Das Abbruchkriterium der Octree-Konstruktion (Anzahl Polys je Leaf) ist frei wählbar. Beim Test auf Kollision testet man nur die OBB des Spielers gegen die AABB der Octree-Nodes und geht nur in den entsprechenden Ast. Die Performance des Octrees bei der Kollisionsabfrage ist damit relativ unabhängig von Polygoncount. Erst in einem Leaf des Octrees wird mit den dort liegenden Polygonen die eigentliche Kollisionsabfrage gemacht. Der Box-Box Test ist schnell genug, so dass man ruhig ein paar Hundert mehr oder weniger machen kann, ohne dass es dort einen Unterschied gäbe.

Ciao,
Stefan

Von Return FALSE am 30.04.2003, 11:25:07 Uhr
dieses Bild des Tages bei Flipcode ist sehr interessant, das level selber ist geschickt texturiert, aber das A und O sind die Schatten. Es wird eine interessante methode benutzt um die zu berechnenden schatten ausfindig zu machen:

http://www.flipcode.com/cgi-bin/msg.cgi?showThread=04-22-2003&forum=iotd&id=-1

Von Torsten Richter am 30.04.2003, 14:18:17 Uhr
Hallo Stefan,

nach welchen Prinzip genau modelliert man ein Level in deinen Editor?

-Blocks die mittels CSG zu einen begehbaren Sektor zusammengefaßt werden
-auf unterster Ebene mit einzelnen Vertexes und Faces (stell ich mir sehr Mühsam vor, vorallen bei großen Levels)
-wie bei Duke3D, Grundrisspolygon in 2D-Ansicht erstellen und dann nur noch Decken- Bodenhöhe einstellen und fertig ist Sektor

Von Eisflamme am 30.04.2003, 14:31:58 Uhr
Sauber, das sieht extrem super aus. oO

Von Stefan Zerbst am 30.04.2003, 14:36:53 Uhr
Hi,

@Torsten
Man modelliert zunächst auf Ebene einzelner Polygone, danach hauptsächlich über Copy'n Paste bzw. durch Prefabs. Das mag am Anfang etwas umständlich erscheinen, aber man erhält so absolute Freiheit über jeden einzelnen Vertex. Man braucht auch keine künstlichen Konstrukte wie Cut Brushes u.ä. die einen Level auch nicht übersichtlicher machen. :)

Die modellierte Geometrie unterliegt dabei keinen Beschränkungen hinsichtlich der Anordnung. Über die Prefabs kann man sich aber auch bestimmte Elemente (Türen, Treppen, Räume, Gebäude, ...) anfertigen und eine Objektdatenbank anlegen. Der erste Level ist also der schwerste, danach geht es stetig bergauf :D

Ciao,
Stefan

Von DarkAngel am 30.04.2003, 16:01:35 Uhr
Sieht wirklich nicht schlecht aus. Ich versteh bloß immer noch nicht warum du nur 1.1 Shader nimmst. oder gibt es 2.0 Alternativen? Und wie Return FALSE schon meinte, was ist mit HLSL?

Werden die Stencil Shadows mit dem VS extruiert oder berechnest du mit CPU bzw. berechnest du bei statischen Schatten vor?

Was für ein Fileformat kommt fürs Skinning dran?

Ansonsten in Sachen Levelaufbau hälst du dich ja ganz schön an Doom3 (kein BSP mehr).

@ Return FALSE: für dein Schattenproblem hat Carmack doch aber auch eine Lösung gefunden, bekannt als Carmacks Reverse. Und im allgemeine Programmierung Forum ist doch auch ein Thread mit link zu einem Artikel.

Von Tanubi am 30.04.2003, 16:26:44 Uhr
Wenn man jeden einzelnen Vertex bearbeiten kann, wie gehst du dann mit "Löchern" im Level um? Gibt es dagegen ne Absicherung, fällt man dann ins Unendliche oder was?

blutigerAnfaenger

Von Stefan Zerbst am 30.04.2003, 16:58:04 Uhr
Hi,

@BlutigerAnfänger
Löcher in der Geometrie sind möglich. Der Spieler fällt dann tatsächlich in die Unendlichkeit. Ein Level-Designer sollte so etwas also vermeiden. Aber es gibt keine Situation, wie beispielsweise bei einem BSP Compiler, wo ein Level fehlschlägt weil die Geometrie nicht 100 % korrekt aufgebaut ist :)

@DarkAngel
Zitat:
Ich versteh bloß immer noch nicht warum du nur 1.1 Shader nimmst

Nun, ich möchte beispielsweise, dass das ganze auch auf Grafikkarten der GeForce3 Ti Klasse läuft und man keine Radeon 9800 Pro braucht. Für die verschiedenen Shader-Versionen gibt es keine alternativen Passes, das überlasse ich jedem selbst. Letzten Endes demonstriert Pandora's Box auch nur die Anwendung der zuvor entwickelten Engine und ist kein kommerzielles Produkt das für jede mögliche Hardware optimal ausgelegt ist ;)

HLSL verwende ich auch nicht, weil man sich dann für eine Alternative entscheiden müsste. Nimmt man Microsofts DX HLSL oder nVidias CG? Ziel war es, die Shader sowohl direkt aus dem Quelltext als auch aus Dateien verwenden zu können, und zwar als Sources oder vorkompiliert. Man kann aber in seinen eigenen Projekten natürlich eine beliebige HLSL verwenden und diese in seinen eigenen Game-Code einbinden und der Render-DLL den kompilierten Shader übergeben.

Zitat:
Werden die Stencil Shadows mit dem VS extruiert oder berechnest du mit CPU bzw. berechnest du bei statischen Schatten vor?

Die Shadow Volumes werden per Shader extruiert und zwar zur Laufzeit. Das ist jedoch nur dann notwendig, wenn sich eine schattengebende Lichtquelle bewegt hat. Bisher ist jedoch im Game-Code die Character Animation nicht eingebunden, daher noch keine Shots mit schönen Schatten.

Zitat:
Was für ein Fileformat kommt fürs Skinning dran?

Es wird ein eigenes File-Format verwendet, jedoch wird man auch Milkshape Dateien in dieses konvertieren können.

Zitat:
Ansonsten in Sachen Levelaufbau hälst du dich ja ganz schön an Doom3 (kein BSP mehr).

Also, was den Levelaufbau angeht da halte ich mich eher an James Cameron und nicht an Doom3. Was die Technik angeht so mag der Vergleich zu Doom3 eher zutreffend sein. Das liegt aber daran, dass sich die Hardware weiterentwickelt und ein BSP mit all seinen Nachteilen (z.B. illegale Geometrie) nicht mehr in Kauf genommen werden muss. Eher im Gegenteil, strikte BSP Bäume oder originäre Portal-Engines bremsen heutige Hardware eher aus, als dass sie gutes tun.

Ciao,
Stefan

Von joeydee am 30.04.2003, 18:41:59 Uhr
Klasse Screenshots, schön gemachter Level und eine vielversprechende Framerate. Davon bin ich wohl noch Jahre entfernt :D Trotzdem werde ich mir etwas (konstruktive) Kritik erlauben:

Ja, die Schlagschatten fehlen noch, wie ein paar Kommentare früher schon gesagt wurde. Da ich mit Raytracing etwas Erfahrung habe, weiß ich, dass es hauptsächlich auf das richtige Licht ankommt, um eine Szene echt wirken zu lassen. Und das fehlt noch ein wenig. Dabei spielen schöne Texturen und Bump-Maps die untergeordnete Rolle.

Versuch doch mal jemand, einen Weißen Raum mit einem weißen Würfel, beide völlig glatt und ohne Struktur, möglichst echt zu rendern. Das ist eine echte Herausforderung (sogar für einen Fotografen im RL!), da kommt es nur noch auf die richtige Beleuchtungstechnik an. Den Unterschied sieht man hier:
http://joeydee.i-networx.de/pics/radiobox.jpg
http://joeydee.i-networx.de/pics/radiobox2.jpg
Das zweite Bild ist zwar leider nicht Echtzeit (Raytracing mit Radiosity), aber die Umsetzung wäre mittels Lightmaps kein großes Problem, denke ich.

Deswegen würde ich auf alle Fälle die Möglichkeit schaffen, statische Lichter mit einem guten Algorithmus vorzuberechnen. Diese könnten dann immer noch mit dynamisch berechneten Spielerschatten überlagert werden.

Von Stefan Zerbst am 30.04.2003, 19:01:19 Uhr
Hi,

in einem echten kommerziellen Produkt würde man sicherlich auch eine gewisse Grundierung eines Levels durch Radiosity o.ä. vorberechnen und statisch lassen. Zusätzlich würden dann dynamische Lichter ihren Anteil zur Szene dazu geben.

Ich gebe durch meine Arbeit ja auch nur einen Anstoss, Spass ist was ihr draus macht ;)

Ciao,
Stefan

Von Praios am 30.04.2003, 19:29:06 Uhr
Supi! Ich freu mich auf das Buch.

Bzgl. der Grafik:
Ich denke es geht hier hauptsächlich darum ein Spiel zu programmieren und keine Grafikdemo. Und ein Spiel soll nicht nur auf Highend-PCs laufen, sondern auf möglichst vielen PCs, damit viele es spielen können. Insofern bin ich froh, das Stefan so bodenständig ist "nur" Version 1.1 zu verwenden.
Was mich viel mehr interessiert ist die KI! Wenn die genausgut wird wie die Grafik hier wirkt, dann wird das Buch mit Sicherheit ein Bestseller.

Bzgl. der Flipcode Screenshots:
Sabotage 1942 ist ein kommerzielles Produkt, insofern kann man wohl auch eine gewisse Grafikqualität erwarten. Als Hobbyprogrammierer hat man wohl kaum die Zeit so etwas zu schaffen.

Von TCS am 30.04.2003, 19:38:47 Uhr
Hi, macht insgesamt einen sehr guten Eindruck, vor allem der Editor gefällt mir (hatte dich ja diesbezüglich mehrfach genervt hehe). Schade nur dass du ... nun ja ... nicht der beste Leveldesigner bist (vielleicht hast du auch nur sehr wenig Zeit reingesteckt). Nix fuer ungut, aber ich denke ein guter Leveldesigner würde die Qualität der Screens mindestens verdoppeln. Ansonsten weiter so...

Von joeydee am 30.04.2003, 21:59:20 Uhr
Ich dachte auch nicht, dass Du einen Radiosity- oder anderen Algorithmus implementieren solltest, das führt viel zu weit. Sondern nur gleich von vornherein die Möglichkeit für zusätzliche statische Lightmaps schaffen, die durch Deine dynamischen überlagert werden können. Lässt man die statischen weg und macht alles dynamisch, hat man Deine gezeigte Version (Buch-Standard).
Will man mehr Realitätsnähe, muss man sich selbst einen Weg ausdenken, tolle Lightmaps zu erschaffen. Aber der Platz für diese wäre bereits vorgesehen.
Nur ein Vorschlag, ist aber auch so schon gut genug!!! Ganz ehrlich!

Von Stefan Zerbst am 30.04.2003, 22:05:57 Uhr
Hi,

naja, ich habe dort keine "dynamischen Lightmaps", sondern verwende Pixel Shader um die Pixel entsprechend aufzuhellen. Es ist also keinerlei zusätzliche Textur nötig, es wird jeweils nur die Diffuse Textur verwendet.

Wenn man sich selbst Lightmaps berechnen möchte, dann ist das auch kein Problem diese im Level mit abzuspeichern, da man einem Material bis zu acht Texturen zuweisen kann ;)

Die Grundlagen sind also da.

Ciao,
Stefan

Von MK42 am 30.04.2003, 22:19:33 Uhr
Hi!

Na Stefan, das sieht doch recht ordentlich aus ... mit projezierten Lichtquellen wäre es aber besser gewesen :D

Aber irgendwo mußt Du ja auch einen Strich ziehen. Es wäre glaube ich sehr einfach Dein Code-Gerüst für einen Doom-3 Map Viewer aufzublasen.

Du solltest unbedingt die Parameter der Lichter animieren (pulsierendes Licht, flackerndes Licht, Farbe ändern) ... das erhöht die Dynamik ungemein. Solange sich Größe und Position nicht ändern bleiben auch Deine Caches valid.

Lightmaps in diese Art des Renderings zu integrieren ist eigentlich ein Kinderspiel (wirklich) ... der erste Pass zeichnet ja das ambiente 'Licht' ... mit Lightmaps kommt das halt aus der Lightmap und nicht einer festen Konstanten ambienten Farbe. Ich würde übrigens eine Art 'Photon-Shooting' zur Generierung der Lightmaps anwenden. Das kann interessantere Ergebnisse liefern wie Radiosity.

-Marco

Von ChrisM am 30.04.2003, 22:44:15 Uhr
Erstmal: Geile Screenshots, ich freu mich richtig auf das Buch! :)

So jetzt zur Kritik: Wie ich sehe, hat Zerbie sich immer noch nicht überwunden, mal die Bücherseite zu aktualisieren. Böser Stefan! :D :D

Und dann noch eine Frage: Wird es eine Art Scriptsprache (oder auch z.B, ein LUA-Interface) geben, um Lichtquellen, Türen, Schalter, Gegner und sonstige Objekte scripten zu können?

ChrisM

Von Milkshapekiller am 01.05.2003, 01:16:24 Uhr
LOL wie geil, das Buch hol ich mir. :D:D:D

Von Stefan Zerbst am 01.05.2003, 07:24:00 Uhr
Hi,

@Marco
Danke :) Also flackerndes Licht gibt es schon, pulsierendes Licht ist eine gute Idee. Einen Farbverlauf werde ich eventuell auch noch spendieren. Klar sähe das dann besser, aber der Level leidet halt stark unter Programmer's Art'n Design :D

@ChrisM
Naja, die Buchseite wird dann schon ein Update erfahren wenn es richtige Shots zu sehen gibt wo dann auch die Bots drauf sind. Was die Skripte angeht so ist es tatsächlich angedacht, die KI der Bots über Skrite zu steuern. In wie weit das zeitlich realisiert werden kann ist allerdings noch nicht abschätzbar.

Ciao,
Stefan

Von Mr.DX am 01.05.2003, 09:48:59 Uhr
Die Shots werden immer besser und erhöhen in mir die Vorfreude auf das Buch ins undendliche. In ein paar Monaten bekomme ich von meinen Eltern eh einen neuen PC spendiert, dann läuft auch alles perfekt.

Frage: Wie modellierst du die Bots und welches Format verwendest du dafür?

Von Stefan Zerbst am 01.05.2003, 10:11:44 Uhr
Hi,

@Mr.DX
Im Bot Modelling bin ich nicht so begabt, daher verwende ich bisher noch Modelle aus dem Internet für das Prototyping (von ms3d in ein eigenes Format konvertiert).

Wenn ich einen geeignetes Modell gefunden habe werde ich mal sehen ob ich die Erlaubnis für die Verwendung von dem Modeller des Characters bekomme :)

Ciao,
Stefan

Von witziok am 01.05.2003, 10:48:56 Uhr
HI Zerbst :)
das sieht ganz tool aus !!! (respekt)

ich arbeite grad auch an einen Game_LevelEditor
und muß sagen da steckt doch haufen Arbeit und nerven dahinter :)

MFG, Sebastian W.

Von Stefan Zerbst am 01.05.2003, 11:57:05 Uhr
Hi,

der Editor ist das Ergebnis von ca. 150 Stunden Arbeit, was bei einem Halbtagsjob in etwa drei Wochen Arbeit entspricht. Ein paar Stunden Entwurf und Design kommen noch mit dazu, sind aber grösstenteils dann auch on-the-fly in der Arbeitszeit mit erledigt worden (pfui) :D

Da ich mir jedoch nicht den Luxus leisten kann das Halbtags zu machen, sind glaub ich zwei, drei Monate Arbeit in dem Projekt PanBox Edit drin.

Ciao,
Stefan

Von ThunderEye am 01.05.2003, 12:38:47 Uhr
Hi,
echt genial, gefällt mir 1A! :)
Ist der Leveleditor auch zudem noch als Modeleditor verwendbar? Denn wenn man die Levels eh aus Dreiecken macht, dürfte dies keine große Hürde sein. (nur ein Vorschlag )
Ansonsten wie gesagt alles Top, ich freu mich auch schon auf den Band 3 und ich werde ihn mir sobald ich dann kohle hab, sofort kaufen. ;)
Mfg
ThunderEye

Von DarthMajor am 01.05.2003, 21:09:44 Uhr
Wow, mit Ihrem 3.Spieleprogrammierbuch ist man in der Lage solche Spiele zu programmieren?
Wenn ja, dann Respekt.
Hoffe es wird auch noch weiterhin Spieleprogrammierbücher von Ihnen geben.

Von ChrisM am 01.05.2003, 21:47:48 Uhr
Gute Frage, wie gehts nach Band 3 weiter? Evtl. mit Onlinetutorials (könnten auch gebührenpflichtig sein oder so)? Oder ein neues Buch oder sowas?

ChrisM

Von UOXGER am 01.05.2003, 22:18:39 Uhr
@ChrisM
nein nach seinem drittem Buch wird warscheinlich endlich ein bestseller Spiel rauskommen. Natürlich sollte er sich bis dahin noch mit ein paar Grafikern zusammentun!

Von Stefan Zerbst am 01.05.2003, 22:49:23 Uhr
Hi,

@DarthMajor
Ja, dazu wird man in der Lage sein, wenn man das Buch verstanden hat. Man wird sogar noch weitaus besseres hinbekommen :)

@ChrisM
Kostenpflichtige Tutorials wird es auf ZFX nie geben, aber die Webseite bleibt natürlich weiterhin bestehen. Grafiker sind eine gute Idee, ein Besteller-Spiel natürlich auch. Band 1 und 2 könnten auch eine Rundumerneuerung vertragen. Arbeit gibt es genug :D

Ciao,
Stefan

Von int am 02.05.2003, 09:12:59 Uhr
DarthMajor is cool, der Siezt die Leute :P

zum projekt muss ich sagen, dass es mir immer besser gefällt.


Von ONeinONeill am 02.05.2003, 16:42:57 Uhr
Tja,

sowas nennt man
Respekt

Von ThunderEye am 03.05.2003, 14:28:27 Uhr
Wann beginnt eigendlich der Betatest für den Editor, und was sind die Anforderungen, um an ihm teilnehmen zu können?
Mfg
ThunderEye

Von Stefan Zerbst am 03.05.2003, 15:15:18 Uhr
Hi,

die Anforderungen sind ganz allgemein, dass man schon mal mit einem solchen Editor gearbeitet hat und Screenshots seiner Arbeit vorzuzeigen hat. Das können Level für Unreal, Quake usw. sein, aber auch Milkshape, AC3D usw. Modelle :)

Der Test wird in ca. zwei Wochen beginnen hoffe ich mal. Das hängt aber auch davon ab, ab wann die Beta-Test Sektion auf der ZFX Homepage verfügbar ist (*schiel zu Steffen rüber*) :D

Ciao,
Stefan

Von @uzingLG am 04.07.2003, 14:35:56 Uhr
RESPEKT!
Ich werde mir das Buch gleich auf Amazon vorbestellen! Das 1. und das 2. Buch sind auch toll, aber wenn das 3. im selben Umfang (bezüglich Seiten) ist, übertrifft es alles! Das einzige, was ein bisschen stört ist: es werden nur eigene Formate entwickelt. Ok, beim TH Outdoor Editor aus Band 2 verstehe ich es, da gibt es ja auch kaum Standards (ich versuche mich übrigens an einem Datei-Packer für TH). Ich freu' mich auf das Buch, die Screens schauen echt toll aus!