Diskussionen über interessante Themen
-
Ich schreiben unsere Scripts in C++ und binden sie dynamisch in das Hauptprogramm ein.
Ja genau, Dlls unter Win und SOs unter Linux
Ich hatte mich voher mit Tcl und Lua abgequält, beide sind nicht geeignet
C++ Objekte vernünftig anzusprechen geschweige denn die Engine zu erweitern.Bei mir hat jetzt jeder Level eine eigenen shared object File, in dem der gesamte Scriptsource für den Level compiliert wurde.
Die Funktionen lade ich dann zur Runtime.
Nicht mehr benötigte Module werden über Garbage Collection aussortiert.Bin sehr zufrieden mit der Entscheidung, hat sich bisher nur bewährt.
Ok, man muß etwas mehr compilen, aber dafür brauche ich nacher keinen RuntimeInterpreter im Speicher halten und mir über die Speicherverwaltung und Parameterübergabe in Scriptfunktionen Gedanken machen.
Außerdem ist die Performance unerreicht
-
@Otze: Wenn du dich damit nicht abgeben willst, nimm Pyhton ;).
@Kane: für jedes Level eine DLL? Ist ja abgefahren. lol. Aber eine "Skriptsprache" (is ja wohl bei dir keine mehr), soll ja wohl vor allem einfach zu bedienen sein. Für dich und andere Leute, die Levels erstellen. Naja, falls ich mal genug Zeit habe ein "ernsthaftes" Spiel zu schreiben, verwende ich dafür auf jeden Fall auch wieder Python. Denn die von dir Beschriebenen Probleme gibt es damit sicher nicht. Ich glaube Performance ist bei Levelskripten auch nicht wirklich ein Problem.
-
vorallem nimmt dir dieser compilezwang die möglichkeit runtime zu scripten, du kannst also während des testes nich durchs level gehen, schalter betätigen, und im zweifelsfall vorort fixen.
aber das problem mit dem rückgabewert einer funktion geht mir nich ausm kopf,wie kann man das lösen?
(für leute die erst später zugeschaltet haben: a=b+c, b+c ist eine addition und deren rückgabewert wird a zugewiesen, wie krieg ichs hin, dass der rückgabewert der addition der gleichungsfunktion übergeben wird)
-
otze, auf die Schnelle wird kann man das schwer erklären. Am besten du liest ein Tutorial dazu.
-
Oder du kaufst dir das Drachenbuch, solltest du auf jeden Fall, wenn du das
ernsthaft machen möchtest, ohne Theorie wird es schwer.
-
-
buch is aufm weg zu mir
-
Ich gebe zu, dass ist keine Scriptsprache mehr was ich da benutze.
Ich persönlich finde Leveldesigner die nicht coden können und dann Scripts
schreiben die:
a) Speicherlecks erzeugen (von der Engine immer neue Resourcen verlangen)
b) Dinge durch Trial-and-Error lösen
c) allgemein ferhleranfällig sind oder keinen Weitblick haben
zeitaufwendiger als ein Runtime-modding.Da setze ich mich lieber selbst 5 min und schreibe einen (wiederverwertbaren)
"Script" der Türen öffnet und schließt ohne den Spieler zu zermatschen
falls er dazwischen steht.Das Compilen sehe ich eher als Vorteil, gute Compiler quitieren Fehler und
Warnungen bevor der Code in die Engine geladen wird.
Außerdem, man zeige mir eine Scriptsprache die Templates (und besonders die STL)
einbinden können ohne für jeden Rotz ne Wrapperfunktion zuschreiben.Außerdem kann ich die netten Debuggingfunktionen meines Compilers/IDE gleich
mitbenutzen.Zu Phyton:
Ich habe mal eine Präsentation zum Interfacen von OpenGL mit SWIG gesehen...
Grausam!Hab ich das "imho" vergessen ?! :p
-
Bei Python (und wahrscheinlich auch anderen Skriptsprachen), wird die STL wohl meistens überflüssig. zB Listen haben in Python die selbe Funktionalität wie std::vector, soll heissen man findet für alles ein equivalent, nur etwas bequemer zu benutzen.
Debugging ist in Python (imho) einfacher als bei C++.
Das argument mit den Leveldesignern die von coden keine Ahnung haben, ist wohl etwas kurzsichtig. Denn die, die etwas Ahnung haben, kommen mit Skripten sicher besser zurecht, als mit C++. Und denen, die keine Ahnung haben, musst es sowieso du schreiben. Wobei es sich wohl auch für Coder mit Python einfacher arbeitet als mit C++ (geht mir zumindest so).
Und pyOpenGl, finde ich nicht grausam (nach den Sampels, die ich gesehn hab). Das einzige, was wegfällt ist,
für jeden Rotz
ne Variable / nen Array zu deklarieren, per pointer an die Funktion zu übergeben und nacher eh nicht mehr brauchen zu können, weil der das Array die falsche Grösse hat / die Variable nicht den richtigen Namen. :p
Zu den Speicherlecks: in den Skripten entstehen die wohl kaum (zumindest Python hat nen hübschen Garbage Collektor), und das mit den Ressourcen von der Engine anfordern, ist wohl eher ne Frage des Interfacedesigns. :p
Naja, finde deinen Ansatz trotzdem cool, wenn auch etwas Umständlich
Besonders, wenn man was "mal so schnell" verändern will.
-
@TGGC: Ich verstehe deine Frage nicht.
Nur weil meine Scripts vorher und nicht während des Spiels compiled werden macht doch eine Scriptsprache nicht überflüssig.
Der C++Source wird eben bei einem Level dazu compiled, wie du auch ne Lightmap vorher berechnest.
Außerdem möchte ich den sehen der während das Spiel läuft, die Console öffnet
und sich sagt: "So, jetzt schreibe ich mal ingame den Script für den Lichtschalter hier".Mal im ernst die "Vorteile" von Interpretern werden, zumindest in dem Bereich überschätzt. Mandenkt sich "Die ganzen anderen Studios nehmen immer Scriptsprachen", also mach ich das auch....
Quark!
-
@ChockoCookie: Ich bin sicher das Phyton sehr viele, wenn nicht alle Bereiche die die STL bedient abgedeckt, aber ich kann in Phyton nicht hergehen und sagen:
"So du lieber Script, das ist ein Verweis auf einen std::map<string, entity*>-Objekt. Mach da mal was mit!"Und genaus das will ich!
Ich habe es satt, dass Tcl (und Phyton afaik auch) nur mit doubles, meine Engine aber mit floats arbeitet.
Ich habe es satt, dass ich mich mit Calling Conventions und ParameterStack rumschlagen muß wenn ich einen Wrapper für ein Lua-Interface schreibe, dass nacher noch von der Engine gewrappt werden muß.
Usw. usw.Edit: Rechtschreibung (die gröbsten Fehler ;))
-
Du verstehst da etwas nicht. Eine Scriptsprache benutzt man, wenn eine Anforderung des Projekts sich dadurch am leichtesten lösen lässt. Nur weil du eine solche Anforderung nicht erfüllen musst, heisst das nicht, das Scriptsprachen nichts taugen.
Bye, TGGC \-/
-
Ja gut, ist klar, das man STL Datentypen nicht so ohne weiteres zwischen C++ und anderen Sprachen (gilt nicht nur für skriptsprachen) hin und her schaukeln kann, sofern die STL dort nicht auch implementiert ist. Das ist nun mal die Krux bei gemischtsprachlichen Entwicklungsumgebungen. Aber für Levelskripting - Zwecke, dürfte das wohl nicht so oft erforderlich sein, denke ich.
Was man auch immer bei Lua machen muss, das Einbinden von Python in C++ und von C++ (modulen) in Python ist kein Problem. Ist ja direkt vorgesehen.
Das mit den doubles stimmt schon. Sehe ich aber nicht als Nachteil. Performante Teile schreibt man sowieso nicht mit Skripten.
Ich denke du hast vollkommen recht, mit dem was du sagst. Wir haben nur eine unterschiedliche Auffassung von dem, was ein Skript Interface können soll. Und man erkauft sich einfach zu viele Vorteile, als das ich darauf verzichten möchte
-
Naja ich kann euch schon verstehen
Vielleicht liegt es auch daran dass Dlls unter Windows kein
Spaziergang sind, unter System die *.so Files verwenden sieht das hingegen ganz anders aus.Wie auch immer, ich komme mit meiner Lösung am besten klar.
Habt ihr euch mal FarCry angeschaut?
Die halbe Engine besteht bei denen aus Lua.
-
Die halbe Engine besteht bei denen aus DLLs
. Und ich kann mir kaum vorstellen, das die Engine Routinen in Lua schreiben, wohl eher Spielelogik und Levelskripts.
Mann die hätten Python benutzen sollen . So wie die Leute, die Severance Blade of Darkness gemacht haben. Da konnte man mit Python Kenntnissen das halbe Spiel umbauen.
-
Ein Grund mehr für compilierte Scripts
*hehe*Ein Kopierschutz in jeder Level-Dll.
Ein Alptraum für Cracker ^^Edit: Diesen Post nicht ernst nehmen.
-
"kopierschutz?welcher kopierschutz? ach dieser kopierschutz!och..den hab ich umgangen :p"
-
Gibt eh so Kopierschutztipps, einer davon ist, mehrere DLLs gegenseitig überprüfen lassen, wenn eine manipuliert ist, silent abschmiern, oder sogar System runterfahren. *gg* extrem fies gegen cracker.
-
gecrackt wird in der exe nicht in der dll,die dll wird sogut wie immer gleich gelassen.
-
Gecrackt wir die Routine, die überprüft, ob das Teil registriert / raubkopiert / whatever ist. Wenn die nun in einer DLL steht, sind die meisten Cracker wohl so flexibel, sie auch dort zu cracken. Wenn aber mehrere Dateien sich gegenseitig überprüfen, wirds haarig. Vor allem weil der Cracker durch die Abstürze Zeit verliert.
Ach, weist du was: lies es einfach selber mal durch http://www.s-a-ve.com/faq/Anti-Cracking-Tips-2.htm
