(See part 1 here)
As promised, we’re getting into the “phases” section now. Phases are the main unit of the game flow – they are sequences of occurences, that may be repeated and nested as neccessary. Occurences may be, at least for now, of one of three types: events, actions, or calls to other phases.
So let’s see what it looks like in the file. First of all, there’s one tag other than <phase> that need to be under <phases>, and it’s called “initialphase”. This is a simple text tag, with the ID of the phase in which the game starts. When the game is loaded, that will be the phase that would start running.
Everything else goes under <phase> tags. A phase tag currently has these subtags: <id> is a string identifier for the phase, and must be unique for each phase tag. <name> is optional, and is a string name for the phase that might be displayed to the user under certain conditions (more on that when we get to defining tables, and talk a little about the user interface of Sunflower games). <table> is another optional tag, which suggests a new table for this phase to take place in. This will probably be very rare, it’s only for when your game has several parts that are so drastically different from each other, that they take place in a completely different table. Finally, the most important and most complicated part is the <occurences> tag, where we list the actual things that happen during the phase.
The three types of occurences:
Things that happen automatically and instantaneously, behind the scenes. The engine takes care of those and the players need not be aware of them at all. This can be cards moving from zone to zone, variables changing values, scripts being run, and so on. Represented by an <event> tag, and inside it the appropriate tag for the specific event type.
Anything that requires input from the player. Choosing a card or moving a card will probably be the most common ones. Each action type is represented by a different tag, a list of all available actions will come soon.
<postscript>Player1Faction = cardProperty(selectedCard,”Faction”)</postscript>
Each specific event or action type will have their own subtags available, but these subtags may be used for any event or action:
– <prescript> is a script that runs before the event or action. If it’s an event, the actual event will run right after the prescript. If it’s an action, the prescript will run after the user performed the action, but before anything else (most notably condition evaluation, see later).
– <postscript> is a script that runs after the event or action. If a condition exists, the postscript will only run if the condition succeeded.
– <condition> will contain a boolean value, which, if evaluated to false, will cause the event to not run (if no condition tag exists, the event will run always). Several conditions may be placed, in which case you may also include a <conditiontype> tag, whose value is either “and” or “or”, and determines if all conditions must be true for the event to run, or if one is enough. By default, “and” mode is used – meaning every condition must be true for the event to run. If the parent tag is an action, not an event, then the condition is evaluated after the user performed the action (and after the prescript, if there is one), and will determine if the action succeeded – if the condition returns false, the action is considered as not done and the postscript will not run.
All of the above tags are optional.
– Phase calls: The main mechanism for creating the game flow – a phase can call another phase to run, as many times as needed. Includes the subtags <phaseid> and <iterations> – the former is the string ID of the phase you want to run, the latter is the number of times to run it (type “infinity” for infinite times). It’s also possible to make phases skippable – in that case, you can choose a minimum and maximum number of calls, and if the player tries to skip, the engine will check if the minimum number of times has been performed yet. If so, the skip will work. To do so, put a triple dash “—” between the two numbers.
Example phase call:
Another option is to put an <until> tag, which will contain a boolean condition evaluated every time we’re going to call the phase, and as soon as the condition evaluates to false we stop calling it.
That’s it about rulesets for now. Next we’ll take a look at making tables, to start making the appearance of our games.