Ich dachte die Phase kindischer Bemerkungen hätten wir hinter uns. Wenn das schon wieder losgeht, muss ich diesen Thread in den Kindergarten verschieben.

Nachträgliches Hinzufügen von Skript zu einem gepublishten Game geht im kostenlosen lite-C das keinen Compiler hat. Sonst gehts nicht ohne Compilieren.

Zusatz-Code kann man per DLL hinzucompilieren wie ChrisB sagt, dafür brauchst du C++. Interpretierte Sprachen wie Torque script, LUA oder Python sind langsam und das Anpassen ist wohl auch ein bisschen aufwendig für eine ernstzunehmende Alternative.

Ich finds nur schwach, zu erwarten, dass JCL mit allem immer treu aushilft. Oder habt ihr euch mit 3D GameStudio auch eine Lizens zum Anschnautzen des Chefentwicklers gekauft? (Und das war jetzt kein Kindergarten, sondern eine längst überfällige Meinung.)

Was auch noch eine sinnvolle Alternative sein kann ist der C#-Wrapper. Ich weiß nicht mehr sicher, wo über den was stand (das wisst ihr sicher besser), jedenfalls ist hier ein hübscher Link dazu:

http://www.codeproject.com/KB/cs/csi.aspx

Eventuell (wenn du nicht den Wrapper verwenden kannst, falls es den überhaupt schon gibt) könntest du den Interpreter ja als DLL einbinden.

Viele Grüße & einen frohen dritten Advent morgen,
Joey

@Joey:



Und vice versa?

@Tobias:

TorqueScript ist langsamer als kompilierter C/C++-Code aber nicht unbedingt viel langsamer. Mal davon abgesehen verwendet Crytek für ihre Engine u.a. auch LUA. Und die Typen sollten es wissen.

Ich denke, das sollten wir Mercuryus überlassen. Er ist ja kein Amateur. Ich bin mir sicher, er will nicht das ganze Spiel mit diesem externen Skript programmieren, sondern nur Teile davon auslagern. Genau das ist der Sinn von Skriptsprachen wie z.B. LUA.

Vielen Dank für das rege Interesse an diesem Thema.

Aus den vielen Antworten habe ich für mich folgendes herauslesen können:


Das währe die beste Lösung, wenn man doch nur kommerzielle Produkte damit erstellen dürft und die Scripte sicher verborgen (z.B. wrs-Archiv) werden könnten.

Ein eigener Interpreter einer beliebingen Scriptsprache (LUA/c-script/C#/eigene) integriert oder als ext. Plugin
Sicher eine elegante Lösung, sehr flexibel nur leider im aktuellen Projekt kaum zu realisieren (zeitlich/finanziell)

Die Spiellogik in eine Hochsprache auslagern und als Plugin (DLL) der Basisengine (mit einem universellen Objektframework für alle Entites) hinzufügen.
Die Idee gefällt mir sehr gut, leider habe ich hierfür noch zu wenige Erfahrung mit den Schnittstellen zwischen DLL's und der Engine um hier eine Aufwandsabschätzung zu wagen.

Danke auf jeden Fall soweit...

mercuryus

PS:
Ich komme noch nicht ganz von der Idee mit dem execute ab...
In der Hilfe wird von Varieblenänderungen gesprochen, im Beispiel wird aber direkt mit c-script-funktionen auf Entities Einfluss genommen.
Wenn ick also c-script einsetze, könnte ich ALLE Funktionen/Varieblen/Entites über execute beeinflussen.
Also ein extern eingelesenes Script zeilenweise an execute übergeben?
Wie würde es sich bei Events verhalten?

du müsstest das ganze script als eine eingabezeile ausführen, sonst hast du ein problem mit funktionsblöcken. soweit ich mich erinnern kann, müsste das dann gehen. ich hab in der kommandozeile öfters kleine funktionen geschrieben, die z.b. ein objekt dauerrotieren lassen (nur ein beispiel). natürlich wäre es interessant, ob es dabei ein zeichenlimit gibt.

gruß,
joey.

Hi,

unter C-Script gibt es eine ganz einfache Lösung, aufgrund des speziellen Compilers.

Statt

include "bla.wdl"

einfach

include "bla.txt"

schreiben.

Die Textdatei enthält das Script, welches anschliessend nach dem Publishen geändert werden kann.

Zu dem ganzen Offtopic Kram sag´ ich jetzt nicht viel.
Im Grunde habe ich Joeys Meinung.
Die Aussage von Jcl war jetzt nicht gerade sarkastisch oder unflätig - ich denke er hat wirklich nicht verstanden worum es geht.

Man muß dabei halt immer bedenken, daß man so auch Tür und Tor aufmacht für Cheats und Sauereien, da man mit C-script mehr oder weniger an der direkten Quelle hockt.

Da macht es vielleicht doch wieder mehr Sinn, sich Richtung LUA und Python umzuschauen. Wäre natürlich schon sehr geil, wenn LUA als Live-Scriptsprache direkt von A7 unterstützt wird, aber bisher wurd glaube ich auch noch nicht so groß danach geschrien.

"Sensible" Scriptteile können ja als wrs gepackt werden und die offenen Scriptteile können als "txt" vorliegen.

Ausserdem gibt es unter C-Script in der Pro Version die Möglichkeit den Selbsttest der Engine auszuschalten. Aber dann liegen alle Scripte offen. Die Vorgehensweise mit der "txt" Endung erlaubt mehr Sicherheit.

Ja, das ist alles richtig, meitne ich aber nicht.

Theoretisch(!) ist halt mit C-Script alles manipulierbar, auch Sachen, die es garnicht sein sollen.
Klar man sieht die variablen etc. nicht, aber zum Rumspielen lädt das geradezu ein, und irgendsoein Spinner findet dann schon ne bereits existierende Variable, um wieder irgendwas zu drehn

Mit ner externen Sprache hat man zumindest die Möglichkeit, manipulierbare Objekte sozusagen freizsuchneiden, und auf den Rest keinen Zugriff erlauben.

Zumindest sollte man sowas bedenken.