NPCs should have an interface to Twine or Ink ... #6271

New Issue

Boot · 2024-02-08T17:19:17Z

Boot commented

2024-02-08 17:19:17 +00:00

... making it much easier for authors to create their stories and quests outside of Minetest.

Of course, this is very time-consuming. Therefore, we should try to put Minetest as a whole on this course. Not only for use in NPCs, but to generally have an interface from Mintest to Twine and vice versa. Only then can Minetest become a game engine that makes interactive games easy to realize through the integration of interacting (scripted) elements.

Here I would like to discuss the chances or alternatives.

http://www.twinery.org/

... making it much easier for authors to create their stories and quests outside of Minetest. Of course, this is very time-consuming. Therefore, we should try to put Minetest as a whole on this course. Not only for use in NPCs, but to generally have an interface from Mintest to Twine and vice versa. Only then can Minetest become a game engine that makes interactive games easy to realize through the integration of interacting (scripted) elements. Here I would like to discuss the chances or alternatives. http://www.twinery.org/

Sokomine was assigned by Boot

2024-02-08 17:19:25 +00:00

AliasAlreadyTaken added the

1. kind/enhancement

label 2024-02-08 18:08:14 +00:00

flux commented

2024-02-08 21:15:35 +00:00

http://www.twinery.org/

this seems to heavily depend on html, css, and javascript, so ... that's probably not going to happen any time soon.

> http://www.twinery.org/ this seems to heavily depend on html, css, and javascript, so ... that's probably not going to happen any time soon.

AliasAlreadyTaken commented

2024-02-09 02:14:40 +00:00

I'd like to have as many import formats as possible ofc, but that's a low prio desire.

Most important may be some Minecraft import.

I'd like to have as many import formats as possible ofc, but that's a low prio desire. Most important may be some Minecraft import.

AliasAlreadyTaken added the

2. prio/low

label 2024-02-09 02:14:46 +00:00

Sokomine commented

2024-02-14 23:22:14 +00:00

The newest version - currently beeing tested in the [b]split_core_and_editor[/b] branch - contains a function called [b]yl_speak_up.generate_next_dynamic_dialog[/b] which allows to create dynamic dialogs via code on the fly. They're created/inserted into the NPC specificly for a particular player and can be changed each time when called. They do not get saved into the normal dialogs. Target dialog to get them is d_dynamic, and they can lead back to normal dialogs.

This is of particular intrest for handling other dialog/quest formats.

The newest version - currently beeing tested in the [b]split_core_and_editor[/b] branch - contains a function called [b]yl_speak_up.generate_next_dynamic_dialog[/b] which allows to create dynamic dialogs via code on the fly. They're created/inserted into the NPC specificly for a particular player and can be changed each time when called. They do not get saved into the normal dialogs. Target dialog to get them is d_dynamic, and they can lead back to normal dialogs. This is of particular intrest for handling other dialog/quest formats.

whosit commented

2024-02-15 03:12:56 +00:00

@Sokomine

The newest version - currently beeing tested

NPCs are beeing tested:

@Sokomine > The newest version - currently beeing tested NPCs are beeing tested: ![image](/attachments/08270646-a0d2-4c58-afd0-a1ce4afd50fc)

image.png

215 KiB

Boot commented

2024-02-15 16:38:11 +00:00

The newest version - currently beeing tested in the [b]split_core_and_editor[/b] branch - contains a function called [b]yl_speak_up.generate_next_dynamic_dialog[/b] which allows to create dynamic dialogs via code on the fly. They're created/inserted into the NPC specificly for a particular player and can be changed each time when called. They do not get saved into the normal dialogs. Target dialog to get them is d_dynamic, and they can lead back to normal dialogs.

This is of particular intrest for handling other dialog/quest formats.

Even after I had it translated with a tool, I didn't understand a word of it.

> The newest version - currently beeing tested in the [b]split_core_and_editor[/b] branch - contains a function called [b]yl_speak_up.generate_next_dynamic_dialog[/b] which allows to create dynamic dialogs via code on the fly. They're created/inserted into the NPC specificly for a particular player and can be changed each time when called. They do not get saved into the normal dialogs. Target dialog to get them is d_dynamic, and they can lead back to normal dialogs. > > This is of particular intrest for handling other dialog/quest formats. Even after I had it translated with a tool, I didn't understand a word of it.

whosit commented

2024-02-15 17:06:43 +00:00

Even after I had it translated with a tool, I didn't understand a word of it.

I guess the idea is: when NPC wants to show you dialog it can ask another program "what dialog I should show now", and when player answers, NPC can ask another program "player chose this, what should I show now?" etc.
To work it needs some "glue" between NPC and that other program (which can be Twine too,). But someone needs to write the "glue" code.

> Even after I had it translated with a tool, I didn't understand a word of it. I guess the idea is: when NPC wants to show you dialog it can ask another program "what dialog I should show now", and when player answers, NPC can ask another program "player chose this, what should I show now?" etc. To work it needs some "glue" between NPC and that other program (which can be Twine too,). But someone needs to write the "glue" code.

👍 2

Boot commented

2024-02-16 12:57:31 +00:00

I think the integration of external programs into Minetest is enormously important. Twine would be a special candidate, because it already has a lot. Some has been written about this in the Minetest forum. I can imagine the storytelling as a direct overlay in the HUD, but also via NPCs. Since I can't contribute any code myself, I would like to contribute 1k€ as start of a crowdfunding for this project.

AliasAlreadyTaken commented

2024-02-17 03:27:33 +00:00

Before throwing money at a problem, let's look at what needs to be done. With the unfortunate license change in NPCs I'm searching for an external editor, which winery could provide. Twine is GPLv3 itself, so doesn't fit the bill entirely. Also, the techstack is nodejs.

This is a story with two paragraphs, where the first Paragraph ("Abschnitt") links to the second:

:: StoryTitle
Unbenannte Geschichte


:: StoryData
{
  "ifid": "6D03176B-4618-4267-908E-AF30D5EDC373",
  "format": "Harlowe",
  "format-version": "3.3.8",
  "start": "Abschnitt1",
  "zoom": 1
}


:: Abschnitt1 [test] {"position":"550,325","size":"100,100"}
test

[[Abschnitt2]]




:: Abschnitt2 {"position":"850,250","size":"100,100"}
test2

Depending on the features, the bare import should be very simple.

Before throwing money at a problem, let's look at what needs to be done. With the unfortunate license change in NPCs I'm searching for an external editor, which winery could provide. Twine is GPLv3 itself, so doesn't fit the bill entirely. Also, the techstack is nodejs. This is a story with two paragraphs, where the first Paragraph ("Abschnitt") links to the second: ``` :: StoryTitle Unbenannte Geschichte :: StoryData { "ifid": "6D03176B-4618-4267-908E-AF30D5EDC373", "format": "Harlowe", "format-version": "3.3.8", "start": "Abschnitt1", "zoom": 1 } :: Abschnitt1 [test] {"position":"550,325","size":"100,100"} test [[Abschnitt2]] :: Abschnitt2 {"position":"850,250","size":"100,100"} test2 ``` Depending on the features, the bare import should be very simple.

Boot commented

2024-02-17 15:11:12 +00:00

In the forum, someone said it would be easier to link Ink and Minetest. I can't say anything about it technically, but I'm by no means fixated on Twine. However, you can really get good results very quickly with Twine and the community seemed active to me. With Ink, you might really get the technical side right, but the Ink community already has Unity as a game engine and is unlikely to switch to Minetest. But ok, if it helps Minetest, then that would be worth a lot to me too.

AliasAlreadyTaken commented

2024-02-17 15:36:33 +00:00

The question is what purpose does it serve? If you have about 100 stories in twine and are now faced with the task to convert them to minetest NPCs that's a whole different story than "support the most famous dialog formats" in an attempt to popularize minetest and get people to switch.

Boot commented

2024-02-17 15:52:03 +00:00

Let's say I'm a teacher and I want to work on a topic with my students in a playful way. The basis could be a minimal little world in Minetest and a handful of matching mods. Ask students to complete specific tasks. However, the teacher should not write the instructions for this on the blackboard with chalk, but they should be displayed in this world. Text at startup, text for a coordinate, text for an item, text for completing a task. Text in the end credits. If the conditions for embedding texts are simple, then even a normally talented teacher can use it. Or someone like me developing a small game with Minetest and telling a story in the process. If it's easy, it will become popular. No one will change trains because of this, but they will get on.

Boot commented

2024-02-17 18:12:40 +00:00

Wow, this is getting better and better. In the forum someone wrote:

I just found there's also a Lua implementation of Ink https://github.com/astrochili/narrator, so it could be integrated in Minetest as a mod rather than a C++ engine feature.

(I can foresee that Ink support might be a little too left-field to merge into Minetest, so having it as a mod would prevent making someone maintain a Minetest+Ink fork.)

Wow, this is getting better and better. In the forum someone wrote: > I just found there's also a Lua implementation of Ink https://github.com/astrochili/narrator, so it could be integrated in Minetest as a mod rather than a C++ engine feature. > > (I can foresee that Ink support might be a little too left-field to merge into Minetest, so having it as a mod would prevent making someone maintain a Minetest+Ink fork.)

Sokomine commented

2024-02-17 18:23:20 +00:00

There are already some people who focus on MT in education. Might be worth getting into contact with them to find out what might help there. I have some of those threads open in tabs in my browser anyway and probably ought to make them aware of yl_speak_up.

I don't have any experience with Twine, Ink or similar programs. They can certainly be of help when creating dialogs and more.

As flux and AliasAlreadyTaken already stated, Twine uses JavaScript for scripting. Which is fine for its purpose - it's kind of the natural language for the web and may even be justified in this case (on almost all other web pages it's IMHO not justified/needed at all and shows just how incompetent the creators of the web page are).

MT uses lua as a scripting language. Automaticly translating code from one programming language to another is not trivial. Anything more complex than a trivial demo program is usually re-implemented in the new language. And nobody invests that much effort to translate a trivial demo program.

I'm afraid you'll have to forget about importing interactive stories that make use of all/most of Twines' capabilities.

Integrating one of those engines (Twine and/or ink) into MT sounds intresting. But that'd then be something on the engine level. I'm not even sure how much it'd actually help.

What we can do is what AliasAlreadyTaken already suggested: Import other formats partially (like those written in Twine or Ink) into the format the NPC use. This can either happen via a standalone program that's independent of MT and takes the Twine/Ink format and outputs .json files for the NPC in MT - or by using the Import dialog from the NPC in the game.

But please don't expect too much from such an import! Basic progress of the story - i.e. show this text in the NPC, offer these answers, and they lead to those new dialogs - that can very likely be done relatively quickly. Once it gets to handling variables, that already gets far more complex. And as soon as it gets into implementation details - forget about it.

Still, such an import may be helpful. People use diffrent ways to create dialog trees for NPC - anything from normal text editors, wikis, graph-based programs up to specialized things such as Twine and Ink. Just be aware that only the basics can be translated - not the more complex parts.

There are already some people who focus on MT in education. Might be worth getting into contact with them to find out what might help there. I have some of those threads open in tabs in my browser anyway and probably ought to make them aware of yl_speak_up. I don't have any experience with Twine, Ink or similar programs. They can certainly be of help when creating dialogs and more. As flux and AliasAlreadyTaken already stated, Twine uses JavaScript for scripting. Which is fine for its purpose - it's kind of the natural language for the web and may even be justified in this case (on almost all other web pages it's IMHO not justified/needed at all and shows just how incompetent the creators of the web page are). MT uses lua as a scripting language. Automaticly translating code from one programming language to another is not trivial. Anything more complex than a trivial demo program is usually re-implemented in the new language. And nobody invests that much effort to translate a trivial demo program. I'm afraid you'll have to forget about importing interactive stories that make use of all/most of Twines' capabilities. Integrating one of those engines (Twine and/or ink) into MT sounds intresting. But that'd then be something on the engine level. I'm not even sure how much it'd actually help. What we *can* do is what AliasAlreadyTaken already suggested: Import other formats *partially* (like those written in Twine or Ink) into the format the NPC use. This can either happen via a standalone program that's independent of MT and takes the Twine/Ink format and outputs .json files for the NPC in MT - or by using the Import dialog from the NPC in the game. But please don't expect too much from such an import! Basic progress of the story - i.e. show this text in the NPC, offer these answers, and they lead to those new dialogs - that can very likely be done relatively quickly. Once it gets to handling variables, that already gets far more complex. And as soon as it gets into implementation details - forget about it. Still, such an import may be helpful. People use diffrent ways to create dialog trees for NPC - anything from normal text editors, wikis, graph-based programs up to specialized things such as Twine and Ink. Just be aware that only the basics can be translated - not the more complex parts.

Boot commented

2024-02-17 19:10:14 +00:00

@Sokomine, thank you very much for your detailed comment. Yes, I think it's complex. But I also believe that at some point Minetest will need a way to integrate such texts in this form, now that it wants to be a game engine. And it needs easy-to-integrate sound and text-to-speech. If it doesn't get all that soon, then it falls under the retro rubric, but that's another topic.

Yes, for YourLand, a standalone solution is a step forward and I thank you and admire you for working on such solutions for us. Great examples that also work may motivate other coders to look for more solutions. We'll see.

@Sokomine, thank you very much for your detailed comment. Yes, I think it's complex. But I also believe that at some point Minetest will need a way to integrate such texts in this form, now that it wants to be a game engine. And it needs easy-to-integrate sound and text-to-speech. If it doesn't get all that soon, then it falls under the retro rubric, but that's another topic. Yes, for YourLand, a standalone solution is a step forward and I thank you and admire you for working on such solutions for us. Great examples that also work may motivate other coders to look for more solutions. We'll see.

AliasAlreadyTaken removed the

2. prio/low

label 2024-02-18 01:20:39 +00:00

AliasAlreadyTaken added this to the Alias@work project 2024-02-18 01:21:16 +00:00

Boot changed title from ~~NPCs should have an interface to Twine ...~~ to NPCs should have an interface to Twine or Ink ...

2024-02-19 20:46:30 +00:00

Boot commented

2024-02-19 20:50:19 +00:00

Apparently, Ink is the better choice. Unfortunately, the name of the program is very unfavorable, because there are many other programs of this name and the search engines give something about drawing. If you want to learn Ink, here is a small video series.

https://www.youtube.com/playlist?list=PLuSvdAg-FtpxCQ0SN-Da0-55woO_TkB0g

Apparently, Ink is the better choice. Unfortunately, the name of the program is very unfavorable, because there are many other programs of this name and the search engines give something about drawing. If you want to learn Ink, here is a small video series. https://www.youtube.com/playlist?list=PLuSvdAg-FtpxCQ0SN-Da0-55woO_TkB0g

Sokomine commented

2024-02-20 06:09:41 +00:00

See https://forum.minetest.net/viewtopic.php?p=433602#p433602

The ink interpreter in lua works, but...only with a few stories and probably not ideal for servers.

Still, it's a very intresting experiment. Could be very useful for adventure games.

See https://forum.minetest.net/viewtopic.php?p=433602#p433602 The ink interpreter in lua works, but...only with a few stories and probably not ideal for servers. Still, it's a very intresting experiment. Could be very useful for adventure games.

AliasAlreadyTaken commented

2024-02-20 14:25:04 +00:00

If we want to do this, we can either go the small route and have a specific import, or we can go the big route and define a common story interchange format.

Sokomine commented

2024-02-21 07:44:33 +00:00

What's very intresting about ink as well is that it's a way of writing dialog that flows relatively naturally when thinking about NPC dialogs and stories. That alone may be worth quite a bit. People need to develop their ideas somehow.

That "weaving" style of ink makes it so easy to write dialogs. Sadly that also makes direct import into NPC more difficult. The "knot"-based system (practicly the same as the Twine example AliasAlreadyTaken posted above - just minimally diffrent notation) could be imported pretty directly. In a normal ink file, both styles can be mixed, making it easier for the creator of the text.

One problem with using a dynamic dialog system/external engine (like the narrator mod) is that the dialogs are not available for editing ingame. That'd probably require some deeper interaction with the external narrator mod and may be...tricky at best.

It's also not that easy to add preconditions, actions and effects as there is no way to edit the dialogs or options as such. The standard way seems to be to use tags for that, and that might work in most circumstances. It'd require authors to know what format is expected and what is supported - and some sanity checks at runtime.

Also, NPC may participate in several quests by several authors. That needs to be handled somehow.

Plus just letting anyone upload those ink scripts would be a rather bad idea.

On the other hand the external interpreter approach (d_dynamic dialogs) makes it easier to handle diffrent input formats. BetonQuest and other MC-based formats might be of ntrest.

What's very intresting about ink as well is that it's a way of writing dialog that flows relatively naturally when thinking about NPC dialogs and stories. That alone may be worth quite a bit. People need to develop their ideas somehow. That "weaving" style of ink makes it so easy to write dialogs. Sadly that also makes direct import into NPC more difficult. The "knot"-based system (practicly the same as the Twine example AliasAlreadyTaken posted above - just minimally diffrent notation) could be imported pretty directly. In a normal ink file, both styles can be mixed, making it easier for the creator of the text. One problem with using a dynamic dialog system/external engine (like the narrator mod) is that the dialogs are not available for editing ingame. That'd probably require some deeper interaction with the external narrator mod and may be...tricky at best. It's also not that easy to add preconditions, actions and effects as there is no way to edit the dialogs or options as such. The standard way seems to be to use tags for that, and that might work in most circumstances. It'd require authors to know what format is expected and what is supported - and some sanity checks at runtime. Also, NPC may participate in several quests by several authors. That needs to be handled somehow. Plus just letting anyone upload those ink scripts would be a rather bad idea. On the other hand the external interpreter approach (d_dynamic dialogs) makes it easier to handle diffrent input formats. BetonQuest and other MC-based formats might be of ntrest.

AliasAlreadyTaken removed this from the Alias@work project 2024-03-13 12:59:23 +00:00

Sign in to join this conversation.