spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Den Punkt Compilieren/Übersetzen würde ich beim Sprachvergleich komplett raus lassen, da es prinzipiell nicht mehr so große Unterschiede gibt. Die Umwandlung in eine Zwischensprache (auch Bytecode genannt) ist eigentlich gang und gebe. Selbst aktuelle C++ Compiler erzeugen (spätestens bei aktivierter link-time-optimization) Bytecode. Was sich dann unterscheidet ist, wie mit dem Bytecode vorgegangen wird. Bei C++ wird normalerweise dann der Linker direkt den Maschinencode generieren, was man dann als ahead of time (AOT) bezeichnet. Bei Java/C# etc. wird der Maschinencode erst während der Ausführung auf dem Zielsystem generiert, was dann just in time (JIT) genannt wird. Allerdings kann z.B. der gcj Java Bytecode auch AOT in Maschinencode umwandeln. Bei Skriptsprachen wird der Bytecode dann in der Regel wirklich interpretiert. Wobei es z.B. für Lua auch eine JIT Implementierung gibt.

Skriptsprache sind für mich Sprachen in denen man Skripte schreibt, beispielsweise innerhalb eines Leveleditors. Quasi eine Weiterentwicklung von Triggern mit denen man komplexere Storyabläufe oder das Verhalten von NPC's kontrollieren kann. Man benutzt Skripte um irgendwelche Kleinigkeiten zu ändern, für die es sich nicht lohnt das Programm neu zu kompilieren oder (wenn man aus Sicht des Kunden denkt) um ein Programm anzupassen, dass eigentlich schon fertig ist.
Soweit ich mich erinnere ist die KI in FarCry in Lua umgesetzt worden. Das zeigt natürlich, wie mächtig so etwas sein kann, allerdings frage ich mich, warum solch fundamentalen Dinge nicht einfach nativ in C++ gemacht wurden.

Vermutlich weil jede popelige Änderung oder Modding bei Hardcoding ausfällt oder unnötig kompliziert wird.

@Tobiking:
Meine Aussage im allgemeinen sollte ja eigentlich sein, dass man da wenig unterscheiden kann. Aber egal
@Jonathan Klein:
Im Prinzip geht der Trend dort hin, immer mehr über Skripte zu lösen. Man schreibt eine Engine mit allen benötigten Funktionen die das Spiel benötigt. Performancelastige Aufgaben werden dann normalerweise auch hier gelöst. Die eigentliche Logik des Spiels wird dann hinterher über Skripte gelöst. Als Beispiel hierfür nenne ich mal Unity3D oder die Unreal Engine. Die Vorteile dafür liegen ja eigentlich auf der Hand. Die Entwicklung mit "Skriptsprachen" ist im vergleich zu zum Beispiel C++ recht einfach und der Entwickler hat weniger zu beachten. Diese Skripte lassen sich schnell austauschen und für den Entwicklungszyklus können Skripte direkt als Quellcode geladen und interpretiert werden, wodurch Zeit zum kompilieren gespart wird. Je nach Umsetzung könnten auch Skripte zur Laufzeit angepasst werden. Das hängt dann aber immer mit dem jeweiligen System zusammen.

Ich finde eine recht generelle Art eine Skriptsprache zu definieren ist:
Eine Skriptsprache wird nicht direkt vom Betriebssystem ausgeführt, sondern braucht ein weiteres Programm zur Ausführung welches wiederum vom Betriebssystem ausgeführt wird.

Mfg Helco

Dann sind Java und C# für dich Skriptsprachen.

Richtig.
Bei der .NET Framework gibt es ebenfalls ein externes Programm, wobei dieses direkt von Microsoft mit den Betriebssystemen kommt, es also zu diskutieren gilt ob man dieses Programm jetzt als Teil von Windows zuordnet oder nicht. Falls nicht ist dementsprechend auch C# (und damit natürlich auch alle anderen verwalteten Sprachen wie C++/CLI, F#, VB.NET) eine Skriptsprache.

Nach Deiner Definition, Helco, ist Javascript nicht in allen Browsern eine Script-Sprache, in anderen schon.

Dazu müsste das Javascript in eine exe bzw. dll compiliert werden, was doch nicht so abläuft?
Zu der .NET Framework (welche den zugegeben verwirrenden Teil meiner Meinung enthält) habe ich mich nochmal informiert, sodass ich jetzt klar als Fakt sage: CIL in das die verwaltenden Sprachen compiliert wird ist ein Skriptsprache aufgrund seines Interpreters, der nicht in den Kernel des Betriebssystem eingelassen ist.

man kann aber nicht danach gehen, ob eine Sprache oder deren Kompilat direkt von einem Betriebssystem ausgeführt werden kann
eine Sprache definiert an und für sich nicht die Ausführungsumgebung
einerseits wäre es möglich, einen C oder C++ Interpreter zu schreiben, andererseits wäre es möglich, Compiler für JavaScript zu schreiben (in gewisser Weise scheint dies in diversen Browsern ja bereits vorhanden zu sein, oder?

ein bisschen rumspielen mit Google hat mich zu einem Java Compiler gebracht, der den Java-Code in nativen Maschinencode umwandeln kann
normalerweise würden die Java Programme ja in der JRE laufen und somit Java eine Skriptsprache sein, aber ist Java durch diesen Kompiler jetzt auf einmal doch wieder eine "normale" Programmiersprache?
und es ist möglich, C++ in CIL-Code zu kompilieren
wird C++ dadurch jetzt zu einer Skriptsprache?

in gewisser Weise wollte BlueCobold das ja auch schon andeuten...