Reimplement some built-in entities in Lua

[ekureina]

Related to #495. Put built-in entities into Lua files (using custom entities). Package it with the engine. Allow individual quests to ask for individual entities as needed. This can reduce the size of quests not using built-in entities (the stated reason for keeping them around is because many games use them). What do you think, @christopho, @Renkineko?

[Renkineko]

Yep, we will try to simulate at least bow and boomerang. If it's successful, we can imagine putting these entities in the demo quest, so makers can just copy and paste them into their own. We think yesterday that we can imagine a release of this system on 1.4

[christopho]

Indeed, we should remove some built-in entities that are too specific and provide them as Lua custom entities. But not all of them. This is not possible for all of them, but more importantly, this is not desirable for all of them. We still want to provide C++ built-in entities like tiles, dynamic tiles, the hero, enemies, pickable treasures, separators, destinations, etc.

The weight of Lua scripts is insignificant in the quest size as soon as your quest has sounds, musics and images.

So, we have to determine which entity types should be removed (reimplemented in Lua):

• Shop treasure? I'm not sure about them. It is handy to use them in the editor: you can directly fix the price and the treasure in a dialog, and most games need that. But they are not customizable enough.
• Crystal
• Crystal block
• Stairs? They are clearly too specific, so their place should be in the quest side, but they might be hard to program in pure Lua.
• Bomb
• Explosion
• Fire
• Arrow
• Hookshot
• Boomerang

[Renkineko]

Totally agreed for Crystal Block and secondary weapons. I suppose most of them are customizable via metatables (example : hookshot could be sensitive to hookables entities, which are set via a metatable, right ?).

[christopho]

You mean adding on the metatable of chests and destructibles a method is_hookable() that returns true ? Brillant! Because for now, there is no way to customize where the hookshot can get attached to.

[Renkineko]

Yep, sorry I was writing while talking at work so my text wasn't very clear x)

So maybe the method could return more information (like if it's a hookable-go-to-hero or hookable-move-the-hero entity. Example : items are hookable-go-to-hero because when hookshot touch the item, the item is moved to the hero and the hero stay at his place ; chests are hookable-move-the-hero because when hookshot touch the chest, the chest stay at his place and the hero is moved to the chest).

More interesting I think, two methods (don't know what name they could have), and maybe a third method "is_hookable" which return is_method_1_hookable() or is_method_2_hookable().

[christopho]

Right, I didn't think of pickable treasures.

[ekureina]

All good ideas. 1.4 sounds like a good release date, if not earlier. We can flesh out the system as time progresses.

[ekureina]

For entities that is good for the editor to use, we could always have a sample custom entity that is loaded into the quest when it is chosen in the editor.

[wrightmat]

I definitely agree that the weapons should be in Lua whenever possible, since it's much more customizable. I'd say start with hookshot, arrows and boomerang since they're probably the easiest (and there's already an open issue about the customizability of arrows).
Fire, explosion and bombs would seem like a logical second phase, since they are kind of similar to one another as well. Scripting these entities could also lead to more options such as ice or electricity (shooting from something like fire).

[ekureina]

Made a repository where we can put our scripts for converted lua entities. solarus-lstd. Anyone who wants to get added as a contributor can certainly be added.