RFC: RoomScript #558
RFC: RoomScript #558
Conversation
|
This is pretty awesome. Just to be sure: You're not proposing this as an official plugin with a conversion of the given rooms but rather as a showcase of your own plugin? I really like what you did here, but I don't see it as an official plugin because we have to maintain ESC and that's already hard. 😉 I'd love to see it as your own Escoria plugin (like the way I did the Escoria ink bridge), so that the "Escoria ecosystem" grows with it. |
|
I find this very interesting. I remember that I wondered if having 1 script per room would be good or not, but I quickly ditched this idea based on my personal tastes: I feared that the script would be cluttered and hard to navigate through, since we currently don't have a good ESC editor on that matter. However, this is only a matter of personal taste and I totally agree that some could believe the contrary (too many files == messy). Maybe there is no perfect solution, I don't know.
[in order to support the local names instead of the global ids] |
Correct: not proposing it as an official plugin, just a showcase. What I would hope to achieve:
|
|
@StraToN I think the biggest thing I need is the ability for a different way to resolve identifiers to objects, particulary in ESC. For example, the way I had to rewrite all the commands in this PR so I can intercept the calls and run Also, the name resolution I add in RoomScript relies heavily on this bit: static func _resolve_item_id(item_id: String) -> String:
var room = find_room_for_item(escoria.main.current_scene)
if room:
var global_id = room.resolve_item_id(item_id)
if global_id:
return global_id
return item_idThat is, it goes through |
My high-level goal is to use my own scripting language for Escoria. This goes back to some of my original work on RoomScript: godot-escoria#558 as well as this prototype to generate ESC from my own scripting language: https://github.com/bolinfest/alt-esc-prototype/ Because godot-escoria#558 was a large change that was impractical to upstream, I decided to try to rework things as a much smaller diff so that I could unblock myself without having to maintain a fork. The crux of this commit is only a two-line change to `esc_object_manager.gd`. The rest of the changes in the commit are updates to the demo to illustrate how the feature could be used, as it changes `r3_l_exit` to be a custom instance of `ESCItem` that implements the new, optional `generate_events()` function so it can return its own `Dictionary` to map event names to `ESCEvent` instances. Though in practice, I would not expect to author this sort of code by hand. Instead, I would have my own scripting language from which I would generate files such as `l_door.gd` and `l_door_exit_scene.gd`. Though as illustrated by `_compile_event_from_esc()`, I could start by generating ESC instead of going straight to GDScript. For example, my input language might be: ``` room room03 { item l_door { event exit_scene { // ESC change_scene "res://game/rooms/room02/room02.tscn" } } item r_door { event exit_scene { // ESC change_scene "res://game/rooms/room04/room04.tscn" } } } ``` And from this, it would be fairly straightforward to generate these two `.gd` files: ```gdscript # game/rooms/room03/l_door.gd extends ESCItem func generate_events() -> Dictionary: return { "exit_scene": escoria.esc_compiler.compile([ ":exit_scene", "change_scene \"res://game/rooms/room02/room02.tscn\"", ]).events["exit_scene"], } ``` and: ```gdscript # game/rooms/room03/r_door.gd extends ESCItem func generate_events() -> Dictionary: return { "exit_scene": escoria.esc_compiler.compile([ ":exit_scene", "change_scene \"res://game/rooms/room04/room04.tscn\"", ]).events["exit_scene"], } ``` Initially, I admit this does not buy much other than making it possible to define events for multiple items in one file. Though over time, I would like to be able to more sophisticated things like you see in: https://github.com/grumpygamer/DeloresDev/blob/master/Scripts/Rooms/MainStreet.dinky While I know it is possible to extend ESC by creating my own instances of `ESCCommand`, I would prefer to have the freedom to experiment with a broarder array of constructs.
This is a demo of something I have been working on, tentatively called RoomScript.
The overarching goal is to define a room in a single file, more in the style of
Delores: A Thimbleweed Park mini-adventure:
https://github.com/grumpygamer/DeloresDev/blob/master/Scripts/Rooms/MainStreet.dinky
Today, Escoria requires a lot of names:
global_id.escfileRoomScript eliminates the individual
.escfiles. It still supports theglobal_idfield,but it often turns out to be unnecessary, as many scripts can use the existing Node
name rather than the
global_id.The
RSCRoom(which is a subclass ofESCRoom) maintains its global id,but there must be a matching
.roomfile in the same directory. Therefore,instead of having to declare the path to the
.roomfile as a property ofRSCRoom,we exploit the convention and rely on this logic instead:
Within the
.roomfile, there are simple declarations/blocks likeevent setup {}and
item button {}that contain ESC. Again, this is done in favor of the invidual.escfiles.In practice, many items support only one verb, like
lookoruse, so creating a new.escfile for each can feel like unnecessary overhead. This is also one less field youneed to enter for each item in the Godot editor.
As you can see, the end result is in
game/rooms/room02/room2.roomand all the.escfiles forroom02have been eliminated at the top of this stack, yet everythingstill works as it did before.
I certainly don't expect this PR to be accepted as-is. As you can see, the logic in
rsc_item.gdandrsc_room.gdis pretty hacky to make this work. Likewise, I hadto create parallel versions of a number of built-in commands in
addons/escoria-roomscript/commands/in order to support the local names insteadof the global ids. My hope is that we could evolve the framework to support this
style of development, even if it is still an addon.