Mission-X started as a POC plugin, which was static, meaning, each mission was a new compiled plugin.
Second iteration of the plugin was to write the mission as a simple XML file, but all features must be handed by the programmer. So new features or capabilities should have been programmed first before exposing them to designers.
Mission-X v3 will keep some of this guidelines, but it will try to give much more freedom to the designer, but in the price of higher learning curve.
So what is the main design goals for Mission-X v3 ?
The truth is, that I'm not sure just yet, but I know that I want to move most of the mission decisions to the designer, and let him/her decide.
Benefits: you can easily make complex logic tests that you could not easily done in v2.x. Instead you will have to code them yourself. You will have to learn a simple yet agile scripting language, by the name: MY-BASIC, and learn how to use the functions I will expose, so you can "fetch" information from x-plane/plugin and then make your decisions.
But lets speak about the design of a mission and the differences in versions:
In Mission-X v2.x every mission has been divided into steps. Each step has its own goal/s and simmer should complete part or all goals before moving forward to the next step.
In Mission-X v3.x every mission will have goals, a goal can be dependent on other goal or a stand alone, meaning you can complete it when ever you want. That way, there is no real order to the mission, it is almost like a big sandbox.
Now here is the problem: I thought in implementing steps and objectives as follow:
- Goal - a goal is basically a task you need to achieve. It can be as simple as "turn on plane engine" or "refuel plane" to "deliver items to X in 1 hours".
Goals can be independent or dependent to other goals. For example: "take off" goal is dependent on "roll to runway 9", that means plugin won't evaluate "take off" goal, before "roll to runway 9" is achieved.
I have not decided if a goal should define: "next_goal" or just let each "goal" define on which goal/s it dependent upon, and then "do the math" by itself. This gives much more freedom to the designer, but it can be confusing.
Goal state can be modified through script, which makes designing much more flexible, but more challenging and complex in terms of: "how to handle Objectives".
Last: If goals are so flexible, then steps are not relevant anymore.
- Step: Logical reference to 1 or more goals. This is to focus the plugin to only evaluate these goals instead of evaluating ALL goals each flight iteration.
You can have one step, or many steps, but once all steps are complete, or the "last step" is complete, mission will end.
We can create a simple flight school Circuit tutorial, where you have ~30 goals, like: fueling your plane, doing some run-up tests, reaching runway, reaching location in the air that represent progress and so on.
In this case, you can define few steps that will handle set of goals or tasks which are mandatory or optional. If all mandatory goals/tasks are done, we continue to next step.
This way the plugin will only evaluate the goals/tasks inside the step and ignore the rest.
So a step in V3 is only a logical representation of set of goals to make plugin work a little easier, But it means the the designer will have to carefully craft them.
- Objectives: Objectives are high level "TO DO" list to accomplish. An objective, just like a "step" is based on set of "goals", but this time it can point to any goal in the "goals" list. If all the goals in its list accomplished, the Objective is flags as accomplished.
Objective is not dependent on Step progress nor Step dependent on Objectives.