PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Schafft es keiner Doom 3 nachzuprogrammieren?


Gast
2006-11-25, 09:53:48
Hallo, ich wollt mal etwas klarstellen:
Es stimmt doch konkret das Id Software nur 2 Programmierer hat - also Quake3Arena zumindest, so steht in Credits, nur 2 Programmierer, einer davon ist John Carmack.
bei Doom 3 hab ich nicht in die Credits reingeschaut. Bestimmt auch wenige Programmierer oder?

Nun meine Frage: warum schaffen die meisten es nicht so ein Engine nachzuprogrammieren?
Kann man sagen, Carmack ist ein Genie oder er hat einfach viel zu viel Zeit?

Wenn es nur an der Zeit liegt, könnten also rein theoretisch die Sozialempfänger auch so ein Engine nachprogrammieren, dann haben die Scheisse viel Geld oder?

Die gelbe Eule
2006-11-25, 10:13:51
Damit es völlig am Thema vorbei ist, haben durchschnittliche deutsche Sozialhilfeempfänger Zeit und Kenntnis 3D Engines zu programmieren?

ethrandil
2006-11-25, 10:34:02
Ich würde sagen Carmack ist ganz gut, hat viel Erfahrung und wird für seine Zeit bezahlt. Also wird er schon nicht zuviel davon haben.

- eth

Monger
2006-11-25, 10:39:58
Wenn du die Stencil Shader Technik meinst: darüber gibt es ja genügend öffentlich zugängliche Dokumente, und es waren auch schon einige schneller als Carmack: Thief 3 kam einige Zeit vor Doom3 raus, und hatte diese Technik auch schon.

Wenn sich zwei halbwegs gute Programmierer zwei Jahre hinsetzen, könnten sie schon sowas ähnliches programmieren. Afaik gab es auch eine Diplomarbeit die in diese Richtung ging. Aber 1) interessiert sich kein Schwein mehr für diese Technik, und 2) braucht es zu einer Engine noch weit mehr als nur den Renderkern. Die wirkliche Arbeit steckt in den ganzen Tools dazu (Leveleditor...), und dann der Erstellung des Contents.

SavageX
2006-11-25, 12:52:37
John Carmack ist schlicht und ergreifend sehr gut und wird von nVidia und Co. per Kniefall mit Dokumentation versorgt.

Und natürlich gibt es inzwischen viele (freie, ich denke, es geht Dir darum) Engines, die im Groben und Ganzen sehr ähnlich rendern.

Mal einige Beispiele:

http://xreal.sourceforge.net/xrealwiki/ScreenShots

oder

http://icculus.org/twilight/darkplaces/screenshots.html, benutzt z.B. bei http://quake10year.com/ oder http://www.nexuiz.com

oder

http://tenebrae.sourceforge.net/

oder

http://www.tenebrae2.com/

(Die Tenebrae-Engines sind aber AFAIK eher tot)

Also an Engines mangelt es erstmal nicht. Der Grund, warum, id Software und Epic dann trotzdem die hübscheren Spiele auf den Markt bringen (muss man einfach mal neidlos anerkennen): Die haben sehr talentierte Künstler, die Vollzeit und mit guter Bezahlung jahrelang an einem solchen Titel arbeiten. Der immense Schatz an Texturen, Models, Musik, SFX etc. etc. erschafft sich in der Freizeit nicht.

Deshalb sind wir von Nexuiz froh, überhaupt was spielbares auf die Beine gestellt zu haben. Trotzdem ist man aber (was die visuals angeht) ein gutes Stück von dem entfernt, was die großen Spieleschmieden heutzutage vom Stapel lassen. Mit einem 0$ Budget ist diesbezüglich einfach nichts zu machen, auch wenn man natürlich von Version zu Version hier und dort einfach runder wird. Mühsam ernährt sich das Eichhörnchen :)

DaBrain
2006-11-25, 19:22:06
Da stimme ich voll zu. Abgesehen davon kann man davon ausgehen, dass eine kommerzielle Engine besser dokumentiert und mit erheblich besseren Tools und Plugins für teure Software an die Entwickler geht.


Mit einer der oben genannten Engine zu arbeiten ist umständlicher und man wird oft nicht wissen, wie man überhaupt bestimmte Dinge als Artist erreicht.

Die Engine von Anfang an auf die spätere Arbeit der Artists auszulegen ist mit Sicherheit eine sehr komplexe Sache. Ausserdem erfordert es sehr viel Planung bevor man überhaut anfangen kann die Engine zu schreiben.


Ich bastele selber als Künstler and Freeware Spielen und hatte schon viel Spaß mit undokumentieren Features, oder Features, die man nur auf sehr umständlichem Wege ins Spiel bekommt.
Wenn man jede Bewegung einer Animation selber ausrechnen muss, lässt man es lieber. ;)

@SavageX
Nexuiz ist ein tolles Spiel! Die Engine ist mitlerweile schon ziemlich gut. Auf manchen Maps sieht man was wirklich in dem Spiel steckt.

SavageX
2006-11-25, 20:12:03
Zu den Tools muss ich einfach mal id Software lobend hervorheben: Die haben nicht nur ihre alten Engines freigegeben (davon ernähren sich die allermeisten freien shooter), sondern auch die Tools, mit denen sie seinerzeit die Inhalte erstellt haben.

Soll heissen: Die oben genannten Engines nutzen die Map-Compiler und Leveleditoren, die ursprünglich von id Software stammen. Damit muss man schonmal nicht bei null anfangen - ist aber auch nicht unbedingt auf dem heutigen Stand.



@SavageX
Nexuiz ist ein tolles Spiel! Die Engine ist mitlerweile schon ziemlich gut. Auf manchen Maps sieht man was wirklich in dem Spiel steckt.

Danke!

tokugawa
2006-11-25, 20:32:53
Hallo, ich wollt mal etwas klarstellen:
Es stimmt doch konkret das Id Software nur 2 Programmierer hat - also Quake3Arena zumindest, so steht in Credits, nur 2 Programmierer, einer davon ist John Carmack.
bei Doom 3 hab ich nicht in die Credits reingeschaut. Bestimmt auch wenige Programmierer oder?

Nun meine Frage: warum schaffen die meisten es nicht so ein Engine nachzuprogrammieren?
Kann man sagen, Carmack ist ein Genie oder er hat einfach viel zu viel Zeit?

Wenn es nur an der Zeit liegt, könnten also rein theoretisch die Sozialempfänger auch so ein Engine nachprogrammieren, dann haben die Scheisse viel Geld oder?

Wie kommst du drauf dass andere nicht "so eine Engine" nachprogrammieren können?

Doom 3 ist sehr nett für seinen Techlevel, aber der Techlevel ist nicht besonders hoch, rein von den Effekten die verwendet werden.

Gibt genug Leute, sogar Studenten, die Engines auf diesem oder höherem Techlevel programmiert haben, und das bei nicht wesentlich schlechterer Performance.

Avalox
2006-11-25, 21:57:29
Ich möchte nicht wissen, wie viele Leute in Doom3 als Grafik-, Sound- und Leveldesigner beschäftigt waren. (Am Storydesigner hat man ja offensichtlich gespart)

Eine Spieleengine ist doch von einem Spiel so weit entfernt, wie Kohlenstoff und Wasser von einer Orange.

Demirug
2006-11-25, 22:10:26
Ich möchte nicht wissen, wie viele Leute in Doom3 als Grafik-, Sound- und Leveldesigner beschäftigt waren. (Am Storydesigner hat man ja offensichtlich gespart)

John Carmack — Technical Director
Timothee 'TTimo' Besset — Network code, GtkRadiant, Linux conversions Graeme Devine — Sound engine
Seneca Menard — 3D modelling
Kenneth Scott — Lead artist
Fred Nilsson — Animation
Jim Dose — AI and scripted scenes
Robert Duffy — Lead programmer
Jan Paul van Waveren — Game engine (physics)
Tim Willits — Lead designer
Adrian Carmack — Artist
Patrick Duffy — GUI designer
Paul Jaquays — Level designer
Jerry Keehan — Level designer
Steve Rescoe - Level designer
Malvern Blackwell — Level designer
Christian Antkow — Level designer
Kevin Cloud — Artist
Todd Hollenshead — CEO

Sounds, Music und Multiplayer Maps kammen von teilweiße von externen.

tokugawa
2006-11-25, 23:10:49
Ich möchte nicht wissen, wie viele Leute in Doom3 als Grafik-, Sound- und Leveldesigner beschäftigt waren. (Am Storydesigner hat man ja offensichtlich gespart)

Eine Spieleengine ist doch von einem Spiel so weit entfernt, wie Kohlenstoff und Wasser von einer Orange.

Eine Spieleengine ist wesentlich näher an einem Spiel als es eine Grafikengine ist.

Kohlenstoff und Wasser wäre die Grafikengine.
Spieleengine ist dann schon sowas wie ein Samenkorn.
Und das Spiel ist die fertige Frucht.


Aber prinzipiell hast du recht. Erst Content erweckt ein Spiel zum Leben.

Technologisch hochstehende Engines gibt's schon viele. Aber ohne Content sieht man nicht wie gut diese sind.


John Carmack — Technical Director
Robert Duffy — Lead programmer


Das ist im Prinzip ziemlich interessant. Das heißt im Prinzip dass der John Carmack eigentlich an der konkreten Spiele-Engine nicht so viel programmiert hat, sondern hauptsächlich viel "Groundwork"-Programmierung bereitgestellt hat (vermutlich die Grafikmiddleware). Lead Programmer war ja scheinbar wer anderes.

Demirug
2006-11-25, 23:21:46
Das ist im Prinzip ziemlich interessant. Das heißt im Prinzip dass der John Carmack eigentlich an der konkreten Spiele-Engine nicht so viel programmiert hat, sondern hauptsächlich viel "Groundwork"-Programmierung bereitgestellt hat (vermutlich die Grafikmiddleware). Lead Programmer war ja scheinbar wer anderes.

Der Technical Director steht eigentlich noch über dem Lead Programer. Bei beiden Positionen ist es allerdings schwer von außen zu sagen um welchen Bereich sie sich gekümmert haben.

tokugawa
2006-11-25, 23:38:31
Der Technical Director steht eigentlich noch über dem Lead Programer. Bei beiden Positionen ist es allerdings schwer von außen zu sagen um welchen Bereich sie sich gekümmert haben.

Das weiß ich, ist bei uns genauso. Hab ja nirgends geschrieben dass der Lead Programmer über dem Technical Director steht.

Aber der Technical Director kümmert sich weniger um die direkten Belange eines Spieleprojektes, sondern eher um die programmatischen Assets der Gesamtfirma - d.h. das was ich mit Groundwork gemeint habe. Der Technical Director hat vielleicht die Middleware die das Studio verwendet zu großen Teilen geschrieben, oder diverse Teile der Asset-Pipeline.

Der Lead Programmer darf dafür sich mit dem konkreten Spiel auseinandersetzen.

Somit könnte wie gesagt die Grafik-Engine (ev. sogar etwas in die Spiele-Engine reichend) von John Carmack stammen, aber die Belange, diese Engine anzupassen an Doom 3 selbst hat der Lead Programmer erledigt.

Vom reinen Programmieraufwand dürfte der Lead Programmer selbst mehr programmiert haben als John Carmack. Als Technical Director kümmert man sich nicht mehr um jeden Teil des Codes.

ScottManDeath
2006-11-26, 00:00:00
Doom3 ist doch die Techdemo für ZFail Stencil Schatten und GeForce 1 Combiner ;)

tokugawa
2006-11-26, 00:04:08
Doom3 ist doch die Techdemo für ZFail Stencil Schatten und GeForce 1 Combiner ;)

Hui, so harsch wollt ich's nicht formulieren, obwohl das auch sehr nah an meiner Einschätzung von Doom 3 als "Spiel" ist :)

Gast
2006-11-26, 03:37:30
John Carmack — Technical Director
Timothee 'TTimo' Besset — Network code, GtkRadiant, Linux conversions Graeme Devine — Sound engine
Fred Nilsson — Animation
Jim Dose — AI and scripted scenes
Robert Duffy — Lead programmer
Jan Paul van Waveren — Game engine (physics)
Patrick Duffy — GUI designer

Das sind insgesamt 7 Programmierer und nicht 2, die an der Engine oder dessen Tools gearbeitet haben.

Gast
2006-11-26, 03:43:01
Aber prinzipiell hast du recht. Erst Content erweckt ein Spiel zum Leben.

Technologisch hochstehende Engines gibt's schon viele. Aber ohne Content sieht man nicht wie gut diese sind.

Dem stimme ich zu.

Es erinnert sich sicher noch jeder über die Kommentar, die die Programmierer von Unreal
über FarCry gesagt haben.

FarCry ist verglichen mit den anderen 3d Engines nichts besonderes, aber dieses Spiel lebt von den Texturen.

Die Texturen und die Polygonzahl können den Unterschied zwischen schlecht und Spitze bei der Bewertung eines Spieles ausmachen, woraus dann Rückschlüsse und Mutmaßungen auf die ach so gute oder schlechte Engine zurückgeführt werden.


Ich finde, eine Engine ist dann gut, wenn sie guter wartbarer Code ist und dem Künstler die Arbeit so gut wie möglich abnimmt, die Engine auch zu nutzen bzw. wenn er damit spielend das Ziel seiner Kreation erreichen kann ohne das man dafür hinterher einen Rechne benötigt, der erst in 10 Jahren entwickelt wird.

Spasstiger
2006-11-26, 03:56:57
Gerüchteweise hat John Carmack ja das Grundgerüst der Doom-3-Engine innerhalb eines Monats alleine in die Tastatur gehackt. Sicherlich hat er dabei auch Teile aus seinen alten Engines modifziert und weiterverwendet, außerdem dürfte er sehr konkrete Vorstellungen gehabt haben, was die Engine können soll.
Und das Engine-Grundgerüst stand schon im Jahr 2000 oder 2001, also lange vor Release des Spiels. John Carmack ist halt leidenschaftlicher Programmierer, wer weiß, was für verrückte Geschichten er in den letzten Jahren noch so implementiert hat.

Gast
2006-11-26, 10:18:53
LOL das passt ja gerade.
Also ich glaub John hat nich zu viel Zeit auf VOX kommt gerade ein Bericht zu kommerzieller Raumfahrt und das ist wohl zur Zeit seine Freizeitbeschäftigung. *g*

Spasstiger
2006-11-26, 12:21:47
LOL das passt ja gerade.
Also ich glaub John hat nich zu viel Zeit auf VOX kommt gerade ein Bericht zu kommerzieller Raumfahrt und das ist wohl zur Zeit seine Freizeitbeschäftigung. *g*
Damit beschäftigt er sich auch schon seit mehreren Jahren, ist eigentlich sehr bekannt in der Doom-3-Szene. Und seine Familie lässt ihm auch zunehmend weniger Zeit für Spieleentwicklung. Er hat auch mal einen Ausstieg aus der Spieleszene angedeutet, nachdem Doom 3 erschienen war. Bisher bleibt er ID Software aber treu. Er kann halt seine Wurzeln nicht verleugnen.

DaBrain
2006-11-26, 12:25:49
Ich finde, eine Engine ist dann gut, wenn sie guter wartbarer Code ist und dem Künstler die Arbeit so gut wie möglich abnimmt, die Engine auch zu nutzen bzw. wenn er damit spielend das Ziel seiner Kreation erreichen kann ohne das man dafür hinterher einen Rechne benötigt, der erst in 10 Jahren entwickelt wird.

Das sehe ich auch so.
Soetwas ist sicherlich schwieriger zu programmieren. Allerdings denke ich, dass es hauptsächlich auf eine wirklich gute Planung zusammen mit einer konsequenten Umsetzung ankommt.

Bei Open Source Engines, oder Engines, an denen nur Programmierer sitzen, fehlt oft der Dialog mit den Artists. Und genau dass kann eine (Grafik)Engine später unbrauchbar machen. Auch wenn sie noch so leistungsfähig ist.

Ich stehe selber in Verbindung mit einigen Freespace 2 Open Source Programmierern und werde (zum Glück) oft gefragt wie ein neues grafisches Feature nutzbar sein sollte.

Es ging gerade um ein erweitertes Lod System, dass mit Boxen arbeitet, die ein Objekt nur darstellen, wenn man sich in ihnen befindet. Das System war extrem umständlich für komplexe Objekte, weill man für jedes kleine Detail eine Box mit bestimmten Parametern erstellen musste.

Jetzt braucht man nur noch ein einen Wert pro Objekt setzen. Damit kann man das Feature wirklich sehr einfach nutzen.

Vorher hat es niemand verwendet(!)

Demirug
2006-11-26, 12:33:11
Soetwas ist sicherlich schwieriger zu programmieren. Allerdings denke ich, dass es hauptsächlich auf eine wirklich gute Planung zusammen mit einer konsequenten Umsetzung ankommt.

Keine noch so gute Planung besteht gegen die Realität weil im Vorfeld die Anforderungen im besten Fall ungenau und häufig sogar falsch beschrieben wurden. Wartbarkeit definiert sich ja gerade deswegen zu einem großen Teil darin wie flexibel man auf Änderungen reagieren kann. Dummerweise opfert man aber für jedes mehr an Wartbarkeit im Gegenzug Performance.