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).

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.

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.

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.