A long ago requested feature from mapmakers and player is to have a choice in missions. It is coming to Knights Province Alpha 11. With this new feature missions can ask player in a convenient way to make some choice. No more “enable this house repair to get A and train a scout to get B”.
Let’s explore the details. This is how the typical script for the interactive messages going to look like:
Actions.PlayerMessageWithButtons(-1, 'MessageWithButtons prompting player to choose an option', ['Option 1', 'Option 2'], [1,2], True);
procedure OnScriptButtonClick(aPlayer: Integer; aTag: Integer);
Actions.PlayerMessageOpen(-1, 'Player ' + IntToStr(aPlayer) + ' has chosen button #' + IntToStr(aTag) + ' how cool is that!');
The script above has 2 main parts: message instantiation and click event handler. Instantiated message looks like so, with up to 8 buttons for now:
When a button gets clicked, the message closes itself and sends an event to the script.
In our example we just show another message with the event arguments, but mapmaker can write any other script (give wares, destroy houses, spam enemies, reveal fog of war, proclaim victory or defeat and much more):
And now to some technical details for mapmakers – click event has to be separate from the message instantiation (aka asynchronous) because of several reasons:
- Dynamic script occurs within the main game update loop, which is separate from UI loop. This means that script can request a message to be shown, but the message can be shown (and processed) only after the game tick is done.
- All player input has to go through recording mechanism (which is required for replays) and that mechanism basically works as <game update> <player input> <game update> <player input> … Since button clicks are player input, then need to go into the next tick.
- Messages can be blocking (modal) or non-blocking. With non-blocking messages player can click the buttons at any time later in the game (or do not click any of them at all).
- Since messages do not get deleted, player can click the same button over and over again. Emitting the click event again and again.
- Last, but not least – given multiplayer architecture, player input needs to be sent to all other players and acknowledged before it can be executed. This can take up to several dozens of ticks
Finally, this is just a prototype. If all goes well, choice and interactivity can become much more sophisticated. Dialogs, other kinds of controls (text inputs, checkboxes, etc.), controls in the overlay area, etc.