Haxe game scripting engine?

[Dlean Jeans]

I've been reading a book which has a chapter on scripting with Lua.

So I've been finding some way to enable scripting in my HaxeFlixel game project. And I chose hscript.

It has one big drawback is the shortcoming of OOP. You can't write new classes or typedefs.

Lua doesn't have direct OOP support but you can get around that with tables.

I'm not sure how this is gonna work and if the missing of OOP is gonna hinder me in the future, since I haven't get it working yet.

Are there some other options of scripting engine?

Maybe hx-lua?

Or I've heard that you can script in Python or Javascript?

[OvermindDL1]

For note, 'classes' are just groupings of function pointers and data, you should be able to emulate that in hscript just fine if I read it right (it looks like it handles function pointers without issue?).

Also, OOP is a quite a bad style and worth avoiding when possible, you should see how to better structure data, OOP has quite a lot of inefficiencies while also being more unreadable than proper styles.  :-)

[Alexander Kuzmenko]

You can use new lua target and compile Haxe directly to lua. http://haxe.org/blog/hello-lua/

вторник, 7 февраля 2017 г., 12:58:49 UTC+3 пользователь Dlean Jeans написал:

[Adam Harte]

"Also, OOP is a quite a bad style and worth avoiding when possible" & "proper styles"

Wow, that is a bold (and arrogant) statement! 

[OvermindDL1]

Heh, sorry.  ^.^

For scripting I'd never touch OOP.  OOP has its place, but it is not in a scripting language, or even in most engine design, it causes the call flow to happen in unexpected ways and causes a large amount of aliasing issues that just do not exist in most of programming styles (which causes the code to both be harder to reason about as a human and harder to optimize as a compiler).  I teach programming languages at a college as part of my day job and I consistently see people that 'grew up with OOP' know essentially nothing about the other thousands of styles out and how each is useful in their own context.  Just like OOP you could certainly squeeze any project into any of the style and they would be equally bad as how OOP is most used.  In essence, if you even think about Dependency Injection, Factories, needing to inherit from multiple interfaces or classes, or a variety of other things, then what you are currently doing should absolutely *not* be OOP and is better suited to a different style that would be easier to reason about, easier to follow, easier to compile, shorter, and more readable.

I am trying hard not to start a 'class lecture' here, but I can go on and on and on about this.  OOP itself is not bad by any stretch for what it is good at, it has just become the dominate style for so long thanks to the horrors of Java and the .NET languages that most people just cannot see using anything but the OOP Hammer to run the wiring in their house, and that is why I focus on it more than the others.  :-)

If you are curious, start Googling.  :-)