New script coming

Post date: Sep 12, 2009 2:22:49 PM

Hey all!

I'm sure that most eventers have been in a situation where the default choice options haven't been satisfactory. It's very annoying if you want to give the player more than 4 choices. One would have to have a 'next' or 'more' choice for extra choices.

If you want to enable and disable choices then you'll need an awful number of conditional branches or many 2 choices (the choice and 'next') which is not very user friendly for the player.

I plan to create a script which can help eventers on these issues. I think I'll call it Extra Choices, but I'm not totally sure.

I consider three main areas or points which I can work at separately:

Options for displaying the choices

I say that I will allow more than 4 choices, but how should I display the choices?

There are obviously not room for them in the normal message window, so it's probably a good idea to have some sort of floating window which can be scrollable to support arbitrarily many choices.

Another thing to consider, is how to draw the choices. There are many custom message systems out there which gives the developer to customize various aspects of the messages and some allows special commands to be parsed in the messages. It can for example be to draw an item icon. It would be nice to preserve such functionality for the new choice window. It's probably unlikely that I can create a work-with-all solution, so I should instead try to design the script such that creating patches for specific message systems becomes as easy as possible.

Which choices should be shown

A section of the event can be marked by a script call at the beginning and a comment marking the end. Instead of simply finding all choices and using them all I will parse conditional branches so that choices can be disabled/enabled in game depending on conditional branches.

Another issue is about how cancel should be treated. There can really only be one cancel branch. I am thinking that the bottom-most choice command count in regards to the cancel. The bottom-most choice command which is not set on disallow. If all choices event commands disallow cancel, then canceling is disallowed.

Generating event commands for flow control

Having to put labels to ensure proper flow control is tedious and most likely error prone. I am thinking that using a comment to specify where the event will continue after the choice ends. One way to solve this issue is to change the comment into a label and putting 'go to label's at the end of all choices.

This will obviously not cover all cases, so the generation should not be enforced, but rather as a usability improving feature.

This is my thoughts at the moment. I may change them as I work on the script.