Mich stört bei solchen Projekten immer, dass jedes Projekt seine eigene Scriptsprache entwickelt. Wieso nicht eine DSL basierend auf einer etablierten Sprache wie Lua oder EcmaScript basteln? Wenn es nicht Sandboxed sein muss gerne auch Python, Ruby oder Scala.
Ok, die Entwicklung von dem Ding liegt wohl über 10 Jahre zurück; damals waren Lua oder auch EcmaScript bei weitem noch nicht so verbreitet wie heute. Insofern erklärt das vielleicht ein wenig den Standpunkt der Entwickler.
Es gibt leider genügend andere Beispiele; "Battle for Wesnoth" ist so ein prominentes (Ja, es gibt mittlerweile da auch Lua-Support - aber nur als Ergänzung zu WML).
Andere Projekte wie "OpenTTD" setzen auf Exoten wie Squirrel. Ok, besser als was hausgemachtes, aber auch nicht der Weisheit letzter Schluss.
Aha. Wo ist dein Problem? Ist ja nicht so, dass es jetzt super schwer wäre, diese zu lernen, da die meisten dieser Sprachen ja eh C-ähnlich sind. Und Geschwindigkeit scheint auch nicht so das Problem zu sein, zumindest bei sog. Exoten, die du hier nennst. Und ihre Manpower auf eine andere Sache verwenden würden diese Entwickler eh nicht. Und nicht jeder möchte riesen Runtimes einbetten, wie man die bei Scala hätte und manche hätten gerne native Klassen und andere Features und nutzen dann halt Squirrel, Angelscript oder Croc. Bei Invertika ist man z.B. dabei Lua durch Angelscript zu ersetzen.
Ich habe kein Problem. Ich sehe es nur kritisch, dass DSLs, die auf wenig verbreiteten Sprachen basieren, potenzielle Entwickler abschrecken. Das ist jetzt natürlich nicht messbar.
Wenn ich Lust habe, ein Szenario / Script zu entwickeln, will ich nicht erst Sprache XY lernen, sondern gerne auf etwas zurückgreifen, was ich schon kenne. Und genau das hat mich bei einigen Spielen tatsächlich abgeschreckt, etwas beizusteuern.
Prinzipiell kann man solche Interfaces auch so bauen, dass die Sprache, in der die eigentliche Spiellogik geschrieben ist, egal ist. Letztlich landet man dann aber direkt auf der Ebene der aufgabenspezifischen VM, und der geneigte XYZ-Sprachfreund müsste das Binding seiner Sprache dann selbst schreiben. Damit ist wenig gewonnen.
Ein altes, prominentes Beispiel ist die Z-Machine. Dafür gibt es etliche (wenn auch exotische) Sprachbindings. Letztlich stürzen sich aber inzwischen doch alle auf Inform7, um damit Textadventures zu entwickeln, weil die Tools gut sind und man damit die breiteste Helferbasis hat.
Oder, um mal von den Spielen wegzukommen: CGI. Das ist eine wirklich simple, wohldefinierte Schnittstelle, die man nun mit wirklich *jeder* Sprache simpel nutzen kann. Trotzdem denken immer noch mehr als 50% der Leute, dass man dazu Perl benutzen müsste, eine Sprache, die angesichts der Write-Only-Qualitäten ihrer Apologeten keine Feinde mehr braucht. Folglich will keiner CGI benutzen, sondern das direkt im Serverkontext machen, und da dann unbedingt mit PHP, weil geht ja nicht anders *FALSCH*. Geht natürlich anders, macht aber kaum einer.
Oder, um mal von den Spielen wegzukommen: CGI. Das ist eine wirklich simple, wohldefinierte Schnittstelle, die man nun mit wirklich *jeder* Sprache simpel nutzen kann. Trotzdem denken immer noch mehr als 50% der Leute, dass man dazu Perl benutzen müsste, eine Sprache, die angesichts der Write-Only-Qualitäten ihrer Apologeten keine Feinde mehr braucht.
Perl ist nicht mehr und nicht weniger read-only als andere Sprachen auch. Perl stellt alle Mittel bereit, die nötig sind, um wartbaren Code zu schreiben; wenn jemand trotzdem unwartbaren Code schreibt, dann ist es also die Schuld des Programmierers.
Folglich will keiner CGI benutzen
Zum einen halte ich Deine zugrunde liegende Annahme für falsch (ich denke nicht, dass die meisten denken, man müsste Perl verwenden, um CGI-Anwendungen zu schreiben), zum anderen ist CGI vor allem deswegen unbeliebt, weil es einfach langsam ist. Es ist gnadenlos ineffizient, für jeden Request einen neuen Prozess starten zu müssen, vor allem, wenn dabei aufwändige Schritte wie z. B. das Parsen eines Perl-Scripts jedes mal wieder durchgeführt werden müssen.
kann man damit nen shooter adventure machen ? ^^
Was ist ein Shooter Adventure? Abwechselnd Rätsel lösend rumlaufen und Moorhuhnjagd? Dann ja.
so was wie portal meine ich! ^^
Mich stört bei solchen Projekten immer, dass jedes Projekt seine eigene Scriptsprache entwickelt. Wieso nicht eine DSL basierend auf einer etablierten Sprache wie Lua oder EcmaScript basteln? Wenn es nicht Sandboxed sein muss gerne auch Python, Ruby oder Scala.
Ok, die Entwicklung von dem Ding liegt wohl über 10 Jahre zurück; damals waren Lua oder auch EcmaScript bei weitem noch nicht so verbreitet wie heute. Insofern erklärt das vielleicht ein wenig den Standpunkt der Entwickler.
Es gibt leider genügend andere Beispiele; "Battle for Wesnoth" ist so ein prominentes (Ja, es gibt mittlerweile da auch Lua-Support - aber nur als Ergänzung zu WML).
Andere Projekte wie "OpenTTD" setzen auf Exoten wie Squirrel. Ok, besser als was hausgemachtes, aber auch nicht der Weisheit letzter Schluss.
Aha. Wo ist dein Problem?
Ist ja nicht so, dass es jetzt super schwer wäre, diese zu lernen, da die meisten dieser Sprachen ja eh C-ähnlich sind.
Und Geschwindigkeit scheint auch nicht so das Problem zu sein, zumindest bei sog. Exoten, die du hier nennst. Und ihre Manpower auf eine andere Sache verwenden würden diese Entwickler eh nicht.
Und nicht jeder möchte riesen Runtimes einbetten, wie man die bei Scala hätte und manche hätten gerne native Klassen und andere Features und nutzen dann halt Squirrel, Angelscript oder Croc. Bei Invertika ist man z.B. dabei Lua durch Angelscript zu ersetzen.
Wenn ich Lust habe, ein Szenario / Script zu entwickeln, will ich nicht erst Sprache XY lernen, sondern gerne auf etwas zurückgreifen, was ich schon kenne. Und genau das hat mich bei einigen Spielen tatsächlich abgeschreckt, etwas beizusteuern.
Frohe Wehnachten. Was hälst du von XML für diesen Zweck?
Prinzipiell kann man solche Interfaces auch so bauen, dass die Sprache, in der die eigentliche Spiellogik geschrieben ist, egal ist. Letztlich landet man dann aber direkt auf der Ebene der aufgabenspezifischen VM, und der geneigte XYZ-Sprachfreund müsste das Binding seiner Sprache dann selbst schreiben. Damit ist wenig gewonnen.
Ein altes, prominentes Beispiel ist die Z-Machine. Dafür gibt es etliche (wenn auch exotische) Sprachbindings. Letztlich stürzen sich aber inzwischen doch alle auf Inform7, um damit Textadventures zu entwickeln, weil die Tools gut sind und man damit die breiteste Helferbasis hat.
Oder, um mal von den Spielen wegzukommen: CGI. Das ist eine wirklich simple, wohldefinierte Schnittstelle, die man nun mit wirklich *jeder* Sprache simpel nutzen kann. Trotzdem denken immer noch mehr als 50% der Leute, dass man dazu Perl benutzen müsste, eine Sprache, die angesichts der Write-Only-Qualitäten ihrer Apologeten keine Feinde mehr braucht. Folglich will keiner CGI benutzen, sondern das direkt im Serverkontext machen, und da dann unbedingt mit PHP, weil geht ja nicht anders *FALSCH*. Geht natürlich anders, macht aber kaum einer.
Dasselbe gilt natürlich auch für Fast CGI, WCGI etc.