Re: To use a scripting language or not to use a scripting language?
On Friday, 6 January 2017 at 21:08:46 UTC, Jordan Wilson wrote: +1 for LuaD. I'm working on a Dominion simulator (Dominion is a deck building card game), and was able to move all card logic into run time data. It was cool, but eventually had to go back to compiling the logic for performance reasons. It seems I'm going with it, at worst I'll make my own fork and add some custom features right into the language, plus let others to add their own custom scripting language (Basic, Python, etc.) support later on.
Re: To use a scripting language or not to use a scripting language?
On Friday, 6 January 2017 at 18:31:58 UTC, solidstate1991 wrote: On Friday, 6 January 2017 at 12:42:07 UTC, Adam D. Ruppe wrote: On Friday, 6 January 2017 at 09:18:16 UTC, Chris Wright wrote: Anyway. Lua would be a reasonable option to integrate. I don't think there's a high-level wrapper for it in D. check out LuaD: https://github.com/JakobOvrum/LuaD I also made my own scripting language which is nice because it is self-contained (you can compile from scratch with just two files), and super easy to integrate, but it is also slow and buggy compared to Lua, so for something serious I'd say take a gander at that luad link. I'm going to check Lua out for more once I get a bit more free time from work and studying. If it seems good enough, I might even add an alternative option for it if I decide to write my own scripting language. I already implemented an event-handling system in my engine for ease of use on input devices and the GUI called Concrete (probably I'm going to make a real portable framework on it as it looks really cool and retro). +1 for LuaD. I'm working on a Dominion simulator (Dominion is a deck building card game), and was able to move all card logic into run time data. It was cool, but eventually had to go back to compiling the logic for performance reasons.
Re: To use a scripting language or not to use a scripting language?
On Friday, 6 January 2017 at 14:49:10 UTC, Ivan Kazmenko wrote: On Friday, 6 January 2017 at 14:19:34 UTC, Anton Pastukhov wrote: As a game developer I can recommend to use Lua. This language is tradtionally used in many games/game engines. Ironically, one of D's declared selling points is, according to https://dlang.org/overview.html: Who is D For? Programmers who write half their application in scripting languages the other half in native langauges to speed up the bottlenecks. D has productivity features that make using such hybrid approaches unnecessary. The use case here is arguably different. In the ideal case, game logic scripts are editable by gamers which are not necessarily programmers. Chris Wright has already given a bunch of other reasons to use a self-contained, simple, domain-specific, and limited language in such a setting. Perhaps D will some day be usable in a language-as-a-library setting which would make it possible to use for game logic scripts, too. But considering the points above, it still won't necessarily be a good idea. Some of the top games use Python (Civilization IV) and Lua (World of Warcraft, Far Cry, SimCity 4) for scripting. Ivan Kazmenko. I second this. My engine already have some scripting (although currently untested) via XML for its map format, to make maps more portable they have a script to load tiles and sprites on command, this also enable modding to a certain degree. More scripting would enable even deeper levels of modding without hacking the executable file.
Re: To use a scripting language or not to use a scripting language?
On Friday, 6 January 2017 at 12:42:07 UTC, Adam D. Ruppe wrote: On Friday, 6 January 2017 at 09:18:16 UTC, Chris Wright wrote: Anyway. Lua would be a reasonable option to integrate. I don't think there's a high-level wrapper for it in D. check out LuaD: https://github.com/JakobOvrum/LuaD I also made my own scripting language which is nice because it is self-contained (you can compile from scratch with just two files), and super easy to integrate, but it is also slow and buggy compared to Lua, so for something serious I'd say take a gander at that luad link. I'm going to check Lua out for more once I get a bit more free time from work and studying. If it seems good enough, I might even add an alternative option for it if I decide to write my own scripting language. I already implemented an event-handling system in my engine for ease of use on input devices and the GUI called Concrete (probably I'm going to make a real portable framework on it as it looks really cool and retro).
Re: To use a scripting language or not to use a scripting language?
On Friday, 6 January 2017 at 14:19:34 UTC, Anton Pastukhov wrote: As a game developer I can recommend to use Lua. This language is tradtionally used in many games/game engines. Ironically, one of D's declared selling points is, according to https://dlang.org/overview.html: Who is D For? Programmers who write half their application in scripting languages the other half in native langauges to speed up the bottlenecks. D has productivity features that make using such hybrid approaches unnecessary. The use case here is arguably different. In the ideal case, game logic scripts are editable by gamers which are not necessarily programmers. Chris Wright has already given a bunch of other reasons to use a self-contained, simple, domain-specific, and limited language in such a setting. Perhaps D will some day be usable in a language-as-a-library setting which would make it possible to use for game logic scripts, too. But considering the points above, it still won't necessarily be a good idea. Some of the top games use Python (Civilization IV) and Lua (World of Warcraft, Far Cry, SimCity 4) for scripting. Ivan Kazmenko.
Re: To use a scripting language or not to use a scripting language?
As a game developer I can recommend to use Lua. This language is tradtionally used in many games/game engines. Ironically, one of D's declared selling points is, according to https://dlang.org/overview.html: Who is D For? Programmers who write half their application in scripting languages the other half in native langauges to speed up the bottlenecks. D has productivity features that make using such hybrid approaches unnecessary.
Re: To use a scripting language or not to use a scripting language?
On Friday, 6 January 2017 at 09:18:16 UTC, Chris Wright wrote: Anyway. Lua would be a reasonable option to integrate. I don't think there's a high-level wrapper for it in D. check out LuaD: https://github.com/JakobOvrum/LuaD I also made my own scripting language which is nice because it is self-contained (you can compile from scratch with just two files), and super easy to integrate, but it is also slow and buggy compared to Lua, so for something serious I'd say take a gander at that luad link.
Re: To use a scripting language or not to use a scripting language?
On 2017-01-06 10:18, Chris Wright wrote: Lua would be a reasonable option to integrate. I don't think there's a high-level wrapper for it in D. I don't know if it's a high-level wrapper but there's LuaD [1]. [1] http://code.dlang.org/packages/luad -- /Jacob Carlborg
Re: To use a scripting language or not to use a scripting language?
On Thu, 2017-01-05 at 22:37 +, solidstate1991 via Digitalmars-d wrote: > I'm thinking on possibly implementing a scripting language for my > game engine for general purpose and AI. At one point I was > thinking on making a scripting language based on D with > ECMAScript and Prolog/Planner influences. > The standard dynamic programming languages (scripting languages are something completely different :-) for this sort of "dynamic stuff inside static stuff" are: – Python – Lua – Lisp Choice tends to be fashion, prejudice, tribe driven. In the end they can all work fine and do the job required. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: To use a scripting language or not to use a scripting language?
On Friday, 6 January 2017 at 09:18:16 UTC, Chris Wright wrote: There's also DMDScript, which didn't compile on my system last time I tried. If anyone is too lazy too search for it: https://github.com/DigitalMars/DMDScript
Re: To use a scripting language or not to use a scripting language?
On Friday, 6 January 2017 at 09:54:32 UTC, Dmitry wrote: On Thursday, 5 January 2017 at 22:37:21 UTC, solidstate1991 wrote: I'm thinking on possibly implementing a scripting language for my game engine for general purpose and AI. At one point I was thinking on making a scripting language based on D with ECMAScript and Prolog/Planner influences. As a game developer I can recommend to use Lua. This language is tradtionally used in many games/game engines. Thirded. Lua is relatively easy to implement support for, is not too bad a language, and a lot of people are already familiar with it.
Re: To use a scripting language or not to use a scripting language?
On Thursday, 5 January 2017 at 22:37:21 UTC, solidstate1991 wrote: I'm thinking on possibly implementing a scripting language for my game engine for general purpose and AI. At one point I was thinking on making a scripting language based on D with ECMAScript and Prolog/Planner influences. As a game developer I can recommend to use Lua. This language is tradtionally used in many games/game engines.
Re: To use a scripting language or not to use a scripting language?
There are a couple reasons to make a scripting language. One is so you can treat code as data. If you have an asset pipeline, it might be handy to treat scripts as assets. If you have a scene editor, it's straightforward to plug in another type of asset instead of a weird link to a named function that has to be registered and tracked separately. Scripts are often tightly tied to levels, and by making them normal assets, you ensure that they can be versioned with their levels. Another is speed of development. Scripting languages tend to be easier to use (with a greater runtime cost in many cases). You don't have to stop the game, recompile everything, and restart -- sometimes you can just reload it on the fly. Another is to limit what you can do. Maybe you don't fully trust the people writing the scripts and want to prevent them from freely reading from the filesystem, or opening sockets, or whatever. There are a thousand and one ways to mess up any program, but you can close off a bunch of them by offering a limited scripting interface. Anyway. Lua would be a reasonable option to integrate. I don't think there's a high-level wrapper for it in D. There's also DMDScript, which didn't compile on my system last time I tried. Honorable mention to MiniD for those old enough to remember it.
To use a scripting language or not to use a scripting language?
I'm thinking on possibly implementing a scripting language for my game engine for general purpose and AI. At one point I was thinking on making a scripting language based on D with ECMAScript and Prolog/Planner influences. Basic principles for the planned scripting language: - Adding the possibility for logic programming, mainly for decision making engines, could be altered on the fly via code on the fly - Built-in support for fuzzy logic - Scripts that run either on step or time basis, intervals can be altered by code on the fly - Running from a virtual machine either directly from the source code or from bytecode - Ability to call functions through the virtual machine - Portability with certain compromises regarding to the function calls - And making this available for other projects, also making it optional for the engine as it's not crucial However I was also thinking on why not just put a few helpers into the engine's code for scripting and the AI. I already planning to create an automated animator for the engine to replace sprites if a certain time elapses (uses milliseconds as its timebase to make it independent from refresh-rate), I don't think some helpers for creating a decision making engine in D would be much harder (much easier than creating a new language).
