EventScriptは実装が二転三転している部分ですが、現在の作業レベルと進捗状況から、実装可能なEventScriptとは何かを見積もった結果、以下の構造で構築していくことに決めました。
この方向性が変わる可能性は、作業レベルの向上、または低下に因る事をここに明記しておきます。
FTEのイベントスクリプトは大別すると以下の３つで構成されます。
システムイベント, メインイベントで共有される変数の初期化を行います。
毎ターン何度も発生する浮動イベント群です。
メインイベントとは分離されています（ライバル国制御を除く)
特定条件で発生する一般的なイベントです。
このイベント群でストーリーを構成します。
システムイベントの特徴は状況に応じて何度も発生し、半永久的に変化を生む事にあります。
プレイヤーの対応するマスターによって特定のマスターにフォーカスを当てます。
フォーカスの当たったマスターは比較的有利な補正がかかり、プレイヤーにとって強敵となります。
この要素はシステムイベントの域を越えた処理を行うので実装された場合、除去できません。
特定のフラグ等の条件を得点に換算して総合評価値を算出する。
詳細は未定。
毎ターン１エリアを無作為登録します。
登録されたエリアでは災害が起こります。
災害の起きたエリアは備え（＝災害対策能力を持つ人材）がない限り、莫大な被害を受けます。
特定のイベント人材の行動を制御するイベントです。システムイベントの大半を占めます。
参照：EHA詳細
FTEでは増えるのも減るのもデフォより勢いを上げるという方向性を目指しています。
特定エリア固有のパラメータ制御を行います。
時期・状況などのパラメータに対応して自己パラメータを上昇／下降させる。
災害イベント制御の本体も各エリア毎に実装される。
mirror自身がFTEに求めているボリュームと、現実に可能な作業量とを一致させた場合･･･
また、興味もない出来事が与えるプレイヤー側へのストレス、その軽減を重要な事項と位置付けるならば、メインイベントに求められるセンテンスの最大数は30以下(10クリック以内で終了)です。
30以下のセンテンスにて一つの完結した事象を表現し、プレイヤーにとって難解になり過ぎないものとして伝える為には、まず作る側が十分な事前情報を持つことが必要になると思います。(よほどの非凡な作文センスが無い限りは）
そのため、FTEではストーリー構築において、そのための十分な資料を組み立てる事を最重要の課題としています。
また、資料さえ確保できれば、方向転換もそう難しくないものと思われます。
例えば逆の方向性であるストーリーの完全・詳細実装（いわばデジタルノベル化）を採用することになったとしても、資料を参照しての人海戦術で実現可能です。
また、そのような実装を別のコンテンツで公開するということもできるでしょう。
原案に時間はかけられない。でも詳細は固めたいというジレンマがあります。
なので、原案を可能な限り即物的な、成果物の集まりとして構築していきます。
そのために一つの原案を２つの原案のかけらに分割します。
このどちらかをその時の必要と意欲に応じて「適当」に作り、それをもとに過程バージョンの間は仮実装を進めるという形で構築していきます。
ひたすら書き散らされたストーリーの断片を、後期バージョンで選別・確定し、一つの完成されたイベントに進展させます。
詳しくは別の資料（メインイベント仕様の作り方）に記述します。
いくつか変数・フラグを予約します。