Heutzutage games in einer Script-Sprache geschrieben, engine in c++?
-
Liege ich in der Annahme richtig, dass die Entwicklun der Spiele folgendermaßen abläuft:
- Engine in C++
- Das eigentliche Spiel in einer scripting language
(Der overhead, der durch die scripting language entsteht dürfte net allzu groß sein, da die hauptberechnung in der engine stattfindet und die letztere in C++ geschrieben ist)
Hab gehört, dass zB python in vamprie bloodlines, Söldner, Civilisation 4, Battlefield2 für die spiellogik verwendet wurde. Und Quake besitzt ja sogar eine eigene scripting language.
Zudem benutzen FarCry, World of Warcraft, Grim Fandango und Painkiller lua als scrpting Sprache.
Kann man generekk davon sprechen, dass die engien in C++ geschrieben ist und das eigentliche Spiel in einer Scriptingsprache?
-
Also das gesamte Spiel ist sicher nicht in einer Script-Sprache verfasst, aber viele Teile. (Für Addons, Modifikationen etc.) Auch dafür oft benutzt: Lua
Edit: Oh, ich seh grade, Lua war ja schon erwähnt.
-
Vllt sollte man zuerst definieren was "das eigentliche Spiel" denn überhaupt ist!
Also die KI wird wohl wahrscheinlich in moderne engines ausgelagert sein. Physikalische berechnungen auch. Also sogesehen so ziemlich alles was performancerelevant ist, ist in der engine. Daher könnte man doch sagen, dass das eigentliche game in einer scripting sprache geschrieben ist. (Wenn man das eigentliche game auf die spiellogik & co reduziert).
-
Schmidt schrieb:
Daher könnte man doch sagen, dass das eigentliche game in einer scripting sprache geschrieben ist. (Wenn man das eigentliche game auf die spiellogik & co reduziert).
Ich würde eher sagen das die Quests, KI und die Kampange in einer Skriptsprache geschrieben ist, nicht aber das "eigentliche" Spiel. Denn zu so nem Spiel gehört imho viel mehr (Ein- und Ausgabe, Grafik- und Physikberechnungen, Ereignisbehandlungen, Speicherung usw...). Meiner Meinung nach ist nur ein "kleiner" Teil des Spiels in Lua oder Phyton geschrieben. Denn das Spiel an sich könnte ja auch ohne KI und Kampange auskommen (macht dann aber weder Sinn noch Spaß).
-
Das Ganze ist vielleicht auch eher ne Sache der Entwickler-Philosophie. Manche bauen die Engine so streng auf, das man den ganzen Scriptkram rausschmeissen und sofort ein anderes Spiel draus entwickeln kann. Viele nutzen die Scripts aber vor allem deshalb, weil man so unglaublich schnell damit entwickeln kann. Script ändern, fertig. Es soll sogar Entwickler geben, die "skizzieren" ihre Applikation erstmal testweise in einer Scriptsprache und dann richtig -> Rapid Prototyping (uargs!)
-
Was heißt hier "uargs"? Nicht jedes Entwicklerteam kann mit einem verpackungsreifen Spiel an den Verhandlungstisch mit Publishern treten.
Von Ideen alleine wollen die nichts wissen, da ist RP ideal.
-
Chris++ schrieb:
Schmidt schrieb:
Daher könnte man doch sagen, dass das eigentliche game in einer scripting sprache geschrieben ist. (Wenn man das eigentliche game auf die spiellogik & co reduziert).
Ich würde eher sagen das die Quests, KI und die Kampange in einer Skriptsprache geschrieben ist, nicht aber das "eigentliche" Spiel. Denn zu so nem Spiel gehört imho viel mehr (Ein- und Ausgabe, Grafik- und Physikberechnungen, Ereignisbehandlungen, Speicherung usw...). Meiner Meinung nach ist nur ein "kleiner" Teil des Spiels in Lua oder Phyton geschrieben. Denn das Spiel an sich könnte ja auch ohne KI und Kampange auskommen (macht dann aber weder Sinn noch Spaß).
Lies mal bitte die beiträge davor. Du solltest vllt mal das Spiel von der darunterliegenden Spieleengine trennen. Ein- und Ausgabe, grafik- und Physikberechnung ist doch zum größten teil die Sache der Engine und nicht des Spiels. Das eigentliche Spiel (script) kann doch problemlos auf die Funkionalität der Engine zurückgreifen.
Heutzutage bieten Engines doch eine Menge: Grafik, Sound, Physik, Kollisionserkennung, KI(?), eventhandling und vieles mehr. Eben all das, was performancelastig ist. Über die Scripting Schnittstelle wird man schneller ud einfacherer das eigentliche Spiel entwickeln können. Der overhead der durch den aufruf der engineroutinen durch das script aufkommt ist hierbei minimal. Zudem sollte man beachten, dass heutige PCs immer schneller werden.
@Chris++: Wenn du dir eine fremde Engine zulegst und darauf dein eigenes Spiel entwickelst (in einer scripting sprache zB), dann hast du ja trotzdem dein eigenes Spiel gemacht auch wenn du keine zeile code an der engine mitprogrammier hast. Was ich damit ausdrücken will: Trennung der engine vom Spiel.
-
SeppSchrot schrieb:
Was heißt hier "uargs"? Nicht jedes Entwicklerteam kann mit einem verpackungsreifen Spiel an den Verhandlungstisch mit Publishern treten.
Von Ideen alleine wollen die nichts wissen, da ist RP ideal.Schon klar, ich ekel mich nur davor, Dinge zwei mal zu machen
-
Jo hast Recht. Ich bin halt davon ausgegangen, das wenn man z.B. bei Gothic 3 die Skripte austauscht, das man nicht gleich nen Shooter draus machen kann. Aber prinzipiell würde es doch gehen. Bestes Beispiel ist ja auch Warcraft 3 (ist mir jetzt so eingefallen). Fans haben ganze RPGs für dieses Spiel erstellt obwohl es sich eigentlich um ein Echtzeitstrategiespiel handelt.
-
Nutzt man Script-Sprachen nicht eher für Kleinigkeiten, wie das Steuern von Animationen oder irgend welche Effekte auf Karten. Quake 3 hat dafür glaube ich sogar den tcc dabei, da dort C als "Skriptsprache" genutzt wird.
Aber "Engine" ist ja eh so ein Begriff, der alles oder nichts bedeutet.
-
Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Neuigkeiten aus der realen Welt in das Forum Spiele-/Grafikprogrammierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
rüdiger schrieb:
Nutzt man Script-Sprachen nicht eher für Kleinigkeiten, wie das Steuern von Animationen oder irgend welche Effekte auf Karten. Quake 3 hat dafür glaube ich sogar den tcc dabei, da dort C als "Skriptsprache" genutzt wird.
Aber "Engine" ist ja eh so ein Begriff, der alles oder nichts bedeutet.
Schau mal unter den Abschnitt "Scripting":
http://de.wikipedia.org/wiki/Spiel-Enginehttp://de.wikipedia.org/wiki/Spiel-Engine schrieb:
Eine Scriptsprache ist meistens langsamer als andere Programmiersprachen wie etwa C++. Die Spiel-Engine selbst ist daher meistens nicht in einer Scriptsprache programmiert, sondern in aller Regel in C++. Die Spiel-Engine stellt aber meistens eine Script-Sprache zur Verfügung. Insbesondere für größere Spieleproduktionen hat sich daher eine Zwei-Schichten-Architektur etabliert: Das eigentliche Spiel wird in der Script-Sprache entwickelt, welche von der zugrundeliegenden Spiel-Engine zur Verfügung gestellt wird.
Manche Spiel-Engines greifen auf vorhandene Skriptsprachen zurück, etwa LUA. Aufgrund der besonderen Anforderungen besitzen viele Spiel-Engines eine eigene Skript-Sprache, beispielsweise UnrealScript in der Unreal-Engine, C-Script im 3D Gamestudio, oder Perch in der Shark 3D-Engine.
-
(edit: antwort an threadstarter
)
ja so laeuft es ab, es gibt sogar mehr ebenen.ganz unten ist der core, der enthaellt alle grundlegenen dinge damit man nicht auf externe dinge dieser art zugreiffen muss die oft durcheinander gemischt werden oder einfach nur unpassend sind. z.b. string-lib, container (ala vector) etc.
dann gibt es die engine, die kapselt alles noetige und ist meist asm/c/c++. Sie enthaellt rendering, resource verwaltung, scenegraph etc.
dann gibt es gamecode er erweitert fuer die das spiel spezifische dinge, die manchmal am ende in die engine wandern koennen wenn sie gut gemacht sind. z.b. logik fuer ein humpelndes monster, controlls fuer ein moped etc. das wird in c++/c#/java geschrieben.
darauf kommt das scripting, hier spielt sich alles ab was das spiel kontrolliert und oft zur laufzeit geaendert wird, weil es oft kein rein logisches element ist, sondern mit z.b. gamebalance zu tun hat. wieviele monster sollen gespawnt werden, wie weit muss der spieler fahren und wieviel zeit gibt man ihm dafuer, welche items bekommt er etc. das muss sehr kurze turn around zeiten haben und sollte kein compilieren-linken-neuladen etc. benoetigen, besonders wenn man auf konsole entwickelt. oft c#/py/lua/rudimentaere propriaetere sprachen.
ganz oben sind dann die daten, sie enthalten grundinformationen fuer ein spiel. z.b. wieviel kanonnen ein segelschiff hat, wieviel particle gespawnt werden mti welcher farbe, welche physicalischen eigenschaften objekte haben, wo die objekte sind. das wird sehr oft in tools gemacht, leveleditor/particleeditor/physiceditor/edit.exe;) und sehr oft liegen die daten dann als xml vor, bei ca 50% der faelle wuerd ich schaetzen dass die daten dann in ein spezielles read-only binaerformat gewandelt werden.
-
Die Scriptsprachen werden sicherlich auch deshlab eingesetzt, damit man auch Leute an der Entwicklung setzen kann, die nicht gerade DIE Programmierer sind. Die heutigen Spiele werden nunmal nicht mehr von Programmierern der alten Schule entwickelt. Wenn ich dran denke, das damals Manfred Trenz sein Turrican praktisch fast alleine entwickelt hat... sowohl die Programmierung, Grafik und sogar Leveldesign? Ob er da jetzt ne Scriptsprache benutzt oder das ganze in Assembler rein hackt, war damals egal. Er konnte es!
Heute mußt du für das Leveldesign Leute dran setzen, die halt Szenen u.ä. scripten sollen. Da kannst du halt jemanden ran setzen, der ebend nicht ein Programmierer ist, sondern sich Gedanken macht, ob nun das Flugzeug von oben rechts angreift oder lieber bei Ereignis B ne Kehrwende macht. Also nimmt man ne Scriptsprache die jeder schnell lernen kann. Weiterhin kann der Leveldesigner die Szenen ohne Neukompilierung ändern und immer wieder ausprobieren.
Natürlich ist das sicherlich nur ein Faktor für Scriptsprachen, aber es ist sicherlich DER Auslöser. Warum wurde z.B. LUA entwickelt? Weil eine Ingenieur-Firma was individuell selber machen wollte. Also hat man sich gedacht "Ey, Ingenieure wollen nicht proggen, die wollen hier und da ein paar Berechnungen schreiben mit ein paar Bedingungen. Also ne einfache Scriptsprache designen!"