Womit werden Spiele programmiert?
-
Original erstellt von Netzwerk-Latenz:
**Die verwenden sicherlich Tools wie z.B. 3DGameStudio. Jedoch um einiges besser. Aber so ählich stelle ich mir die Erstellung von modernen Spielen vor. Die sind heute so kompliziert das man die Dinger nicht mehr Hardcoden kann.
**Ne.
Die machen das 'hardcode'.
Es werden aber oft riesen Librarys lizensiert, zB Grafik Engine, Physik Engine, etc.
-
Die machen das 'hardcode'.
nein
-
Die machen das 'hardcode'.
nein
doch.
[ Dieser Beitrag wurde am 15.03.2003 um 15:43 Uhr von Optimizer editiert. ]
-
Natürlich coden die die Dinger selber!! 3DGameStudio Enterprise Edition oder was!?!? Hahahaha...
Quatsch. Manchmal werden ganze Engines vermarktet, aber oft fangen die Jungens auch ganz von vorne an.
Früher - als id software die 3D-Welt revolutionierte - bestanden Gamecoder-Teams noch aus'n paar Kumpeln, die in der obligatorischen "Garage" anfingen, Spiele zu coden. Zu C-64-Zeiten genügte sogar EINER! (Manfred Trenz und Turrican)
Heutzutage ist das nicht mehr zu machen...
Wenn es noch eine relativ "kleine" Spieleschmiede gibt, dann ist das id software, das sind immer noch "relativ" wenige Leute... mit Cyber-Hirn Carmack als Haupt-Coder... Dafür bringen die aber auch nur alle paar Jährchen 'n natives Produkt raus (Quake ]|[ Arena: '99!) ... dann aber'n Brecher!
Sarge
-
Ich sags euch ganz ehrlich wie's geht: mit der Tastatur! (ok, Maus wird auch etwas benutzt!)
-
wo du recht hast, hast du recht
-
Hi,
ich fänd' ja ein funktionierendes Sprachinterface optimal.
Computer? Spiel erstellen, 3D, grosse Level und gute Gegner! ... Computer?
Ciao,
Stefan
-
wie genau ist das mit 'hardcode' gemeint?
rapso->greets();
-
Ich glaube die meinen damit, dass sie kein 3DStudio benutzen, was den Code für sie erstellt.
-
sowat macht das gamestudio? *verwundert*.. naja, sowat hab ich nie benutzt...
soweit ich weiß nutzt man heutzutage oft max/maya zum modelieren, niemand macht für seine engine heutzutage selber einen derartig komplexen editor (nichtmal ID-software). bei sowas ist nicht so sehr das coden an sich schwer, sondern ein gutes userinterface und selbst mit einem superguten muss man die grafiker foltern einen anderen editor als ihren "liebling" zu benutzen.
deswegen schreibt man nur plugins für das jeweilige dateiformat und ein paar features, maya ist da übrigens 3dsmax um einiges vorraus, aber dafür ist im editingbereich wiederum 3dsmax beliebter bei grafikern.
dann gibt es noch compositing editoren, die nutzt man um grobe spiel-level zu bauen und dann die ganzen models die's gibt dort zusammenzusetzen, das kann man sich dann in der engine gleich anschauen, daneben gibt es da extras für partikel,collision,terrain,culling...
gecodet wird heutzutage wenig spezielles, es werden (so wie die stl bei c++) module gemacht, die für die nicht-coder nutzbar sind, also z.B. ein action-reaktion (event) system, ein scripting und möglichst viel datadriven design.
hoffe ich konnte ein wenig helfen
rapso->greets();
-
Original erstellt von Maxi:
Allerdings glaub ich dass das alleine nicht zu schaffen ist, soclher sacehn zu proggen.Es gibt zwar nur noch wenige "Einzelkämpfer" in der Spieleentwicklung, ganz verschwunden sind sie aber noch nicht. Tom Sawyer (Transport Tycoon, Rollercoaster Tycoon) lässt sich z.B. lediglich die Grafiken erstellen und schreibt seine Welterfolge dann einsam im stillen Kämmerlein.
Wie Geoff Cramond (GrandPrix-Serie) nutzt er dabei übrigens ausschließlich Assembler! Soviel zum Thema 3DGameStudio.
-
Original erstellt von TDKBacke:
Es gibt zwar nur noch wenige "Einzelkämpfer" in der Spieleentwicklung, ganz verschwunden sind sie aber noch nicht. Tom Sawyer (Transport Tycoon, Rollercoaster Tycoon) lässt sich z.B. lediglich die Grafiken erstellen und schreibt seine Welterfolge dann einsam im stillen Kämmerlein.
Wie Geoff Cramond (GrandPrix-Serie) nutzt er dabei übrigens ausschließlich Assembler! Soviel zum Thema 3DGameStudio.Jo, das stimmt wohl. Seine Rollercoaster-Reihe hat der ja ziemlich alleine gecodet. Is' aber vor allem grafisch auch nicht so wirklich aufwendig. Und der 2. Teil bot ja technisch auch nichts neues. Daß der das allerdings in Assembler codet, halte ich für ein Gerücht. Mal eben für 'ne Win32-Plattform ein komplettes Game in Assembler zu proggen is' doch quasi unmöglich. Für'n paar rechenintensive Dinge nutzt der vielleicht'n paar Inline-Assembler-Routinen, aber mehr auch nicht.
Und Models werden sicher in 3D Studio Max gebaut. Teilweise mit CharacterStudio für 3DSMax. Texturen halt in Photoshop. Das denke ich auch. Und Sounds oft in SoundForge (oder wie das heißt). Kommen aber sicher auch oft von diesen 20er CD-Sets mit Hollywood-Sound-FX, oder etwas vergleichbarem.
-
Original erstellt von <Sgt. Nukem>:
Daß der das allerdings in Assembler codet, halte ich für ein Gerücht. Mal eben für 'ne Win32-Plattform ein komplettes Game in Assembler zu proggen is' doch quasi unmöglich. Für'n paar rechenintensive Dinge nutzt der vielleicht'n paar Inline-Assembler-Routinen, aber mehr auch nicht.http://www.chrissawyer.com/faq3.htm
"What language was RollerCoaster Tycoon programmed in?
It's 99% written in x86 assembler/machine code (yes, really!), with a small amount of C code used to interface to MS Windows and DirectX."
-
Das ist Absicht. Die wollen nicht das ihr dahinterkommt wie man Spiele erstellt
So halten die sich euch vom Hals. Ich sage nur die Illuminaten (oder so ählich) habe sich da breit gemacht
-
schon allein multi threads zu coden ist heavy ... :p
-
Ich behaupte auch mald as ist unmöglich.
-
Original erstellt von Netzwerk-Latenz:
Das ist Absicht. Die wollen nicht das ihr dahinterkommt wie man Spiele erstellt So halten die sich euch vom Hals. Ich sage nur die Illuminaten (oder so ählich) habe sich da breit gemacht Ahhhhrg, und Sgt. Nukem hat's verraten, da werden wohl bald ein paar Leute in schwarzen Anzügen (oder was auch immer die tragen) an seiner Tür klopfen ;).
-
Original erstellt von 1ntrud0r:
schon allein multi threads zu coden ist heavy ... :pna hoffentlich kommt niemand auf diese idee bei spielen *multithreadgänsehaut*
rapso->greets();
-
Original erstellt von rapso:
na hoffentlich kommt niemand auf diese idee bei spielen *multithreadgänsehaut*Äh warum nicht?
Was wäre den so schlimm daran?
-
1. debuggen könnte scheisse sein, es haben sich schon öfters bei mir systeme aufgehängt, wenn ich ein breakpoint in einem multithread programm setzte.. ich weiß nicht weshalb.. vielleicht bug im devstudio?
2. es gibt öfters vielzuviel verschleiss z.B. die schlaue idee in einem thread bei niedrigster priorität auf den soundbuffer zuwarten
3. es gibt noch schlauere, die render und logic in seperaten threads machen, da kann man sich dann in den kopf schiessen wenn in ein und demselben bild objeckte nichtzueinander passen
4. wenn irgendein modul in einem spiel länger als 33ms zum durchlauf braucht, dann ist es scheissen programmiert oder die mindestanforderung ist zu hoch, wobei, was gibt es schon bei einem spiel das bei einer verzögerung von 32ms nicht korrekt funktioniert?... also braucht man, wenn man ein spiel plant, keinen zusätzlichen thread.threads sollte man nur bei multiprozessor und server anwendungen machen... was ein spiel nur als server braucht.
seh ich da wat total falsch?
rapso->greets();
