ストーリーとかは、ほとんど完成していないですがダンジョンを彷徨き回ることは出来るようになったのでテスト版を公開しました。
Wesnoth 1.14 のアドオンサーバーから取得できます。
判明済みのバグ：装飾品は装備しても効果が無い。
新機能：死んだ時にスコアと順位が表示されるようになった。
基本的に未完成品なので、クリアとかはできないです。
製作再開した Castle of evil spirit、大幅な仕様変更を開始してしばらくはキャンペーンを起動することもできない状態でしたが、ある程度イベントの整理も終わり、ようやくテストプレイが出来るまでになりました。
まず、キャンペーンを開始するまでの読み込み時間が大幅に短縮できたのは大きな収穫。今回のテストプレイではプレイヤーユニットの成長速度とアイテムのドロップ、使用に関するバグチェックを中心に進めています。結果、多数の不具合が噴出しています。特にユニットの成長速度が速すぎるのでロジックを変更する予定。
アドオンサーバーにアップできる状態になるのは、いつになることやら。
しばらく開発を止めていた Castle of evil spirit を再び製作再開しました。
これまで作った部分はかなり煩雑な作りになっており、アドオンの起動もやたら時間がかかるため大部分のイベントを再設計しています。
主な変更予定の内容
・ストーリーの大幅変更：ダンジョンに潜る事に焦点を当てて余分なお話を削除しています。
・ショップイベント廃止：上記の理由から会話イベントもほとんど無くなります。
・味方ユニット：味方ユニットを増やす方法はチャーム攻撃で仲間にするのみになります。
・アイテム交換：このイベントも廃止。
・アドオン内セーブ廃止：処理が面倒なだけで需要は無いと判断。
・アイテムドロップイベント：イベントの構造を大幅に変更。ドロップ時にアイテムが決定する仕様になり、モンスターの種類によって落とす種類が変わってくる。
廃止するイベントが大量にあるので、シナリオ遷移時の処理も軽くなる予定。
まあ、予定通りになれば良いのだけど・・・
[store_unit]を使用すると次のような変数が得られます。以下は"Elvish Shaman"の例です。
----------------------------------------------------------------
advances_to="Elvish Druid,Elvish Sorceress"
alignment="neutral"
attacks_left=1
cost=15
experience=0
extra_recruit=""
facing="ne"
flag_rgb="magenta"
gender="female"
generate_name=no
goto_x=0
goto_y=0
halo=""
hitpoints=26
id="Stag"
image="units/elves-wood/shaman.png"
image_icon=""
jamming=0
language_name=_"female^Elvish Shaman"
level=1
max_attacks=1
max_experience=32
max_hitpoints=26
max_moves=6
moves=6
name="Vowithiel"
overlays=""
profile="portraits/elves/shaman.png~RIGHT()"
race="elf"
random_traits=no
recall_cost=-1
resting=no
role=""
side=1
small_profile="portraits/elves/shaman.png~CROP(10,10,390,390)"
type="Elvish Shaman"
undead_variation=""
underlying_id=3
unrenamable=no
upkeep="loyal"
usage="healer"
variation=""
vision=-1
x=6
y=6
zoc=yes
[movement_costs]
castle=1
cave=3
flat=1
forest=1
frozen=2
fungus=2
hills=2
mountains=3
reef=2
sand=2
shallow_water=3
swamp_water=2
village=1
[/movement_costs]
[defense]
castle=40
cave=70
flat=60
forest=30
frozen=70
fungus=50
hills=50
mountains=40
reef=70
sand=70
shallow_water=80
swamp_water=70
village=40
[/defense]
[resistance]
arcane=110
blade=100
cold=100
fire=100
impact=100
pierce=100
[/resistance]
[attack]
accuracy=0
attack_weight=1
damage=4
defense_weight=1
description=_"staff"
icon="attacks/druidstaff.png"
max_range=1
min_range=1
movement_used=100000
name="staff"
number=2
parry=0
range="melee"
type="impact"
[specials]
[/specials]
[/attack]
[attack]
accuracy=0
attack_weight=1
damage=3
defense_weight=1
description=_"entangle"
icon="attacks/entangle.png"
max_range=1
min_range=1
movement_used=100000
name="entangle"
number=2
parry=0
range="ranged"
type="impact"
[specials]
[slow]
#textdomain wesnoth-help
description=_"This attack slows the target until it ends a turn. Slow halves the damage caused by attacks and the movement cost for a slowed unit is doubled. A unit that is slowed will feature a snail icon in its sidebar information when it is selected."
id="slow"
name=_"slows"
[/slow]
[/specials]
[/attack]
[modifications]
[trait]
female_name=_"female^strong"
help_text=_"<italic>text='Strong'</italic> units do 1 more damage for every successful strike in melee combat, and have 1 additional hitpoint." +
_"
While useful for any close-combat unit, strong is most effective for units who have a high number of swings such as the elvish fighter. Strong units can be very useful when a tiny bit of extra damage is all that is needed to turn a damaging stroke into a killing blow."
id="strong"
male_name=_"strong"
[effect]
apply_to="attack"
increase_damage=1
range="melee"
[/effect]
[effect]
apply_to="hitpoints"
increase_total=1
[/effect]
[/trait]
[trait]
female_name=_"female^quick"
help_text=_"<italic>text='Quick'</italic> units have 1 extra movement point, but 5% less hitpoints than usual." +
_"
Quick is the most noticeable trait, particularly in slower moving units such as trolls or heavy infantry. Units with the quick trait often have greatly increased mobility in rough terrain, which can be important to consider when deploying your forces. Also, quick units aren’t quite as tough as units without this trait and are subsequently less good at holding contested positions."
id="quick"
male_name=_"quick"
[effect]
apply_to="movement"
increase=1
[/effect]
[effect]
apply_to="hitpoints"
increase_total="-5%"
[/effect]
[/trait]
[/modifications]
[abilities]
[heals]
affect_allies=yes
affect_self=no
description=_"Allows the unit to heal adjacent allied units at the beginning of our turn.
A unit cared for by this healer may heal up to 4 HP per turn, or stop poison from taking effect for that turn.
This ability will not cure an affected unit of poison, however, only delay its effect."
female_name=_"female^heals +4"
id="healing"
name=_"heals +4"
poison="slowed"
value=4
[affect_adjacent]
[/affect_adjacent]
[/heals]
[/abilities]
[variables]
[/variables]
[filter_recall]
[/filter_recall]
[status]
[/status]
----------------------------------------------------------------
このデータは通常の変数と同じように編集する事ができます。ただし、編集の結果ユニットデータとして正しい書式でなくなった場合は想定した効果が得られません。
また、いくつかの操作はユニットに反映された段階で自動的に修正される場合があります。
さらに、よく見るとアニメーションの設定データが含まれていない事が判ります。ユニットアニメーションは[store_unit]では編集できないのです。
場合によってはシナリオの途中でユニットのデータを変更する必要が出てくる事があります。
例えば新しい武器を与えたり、HPを増やしたりなどストーリーの都合に合わせてユニットデータを編集する場合に代表的な方法が2つあります。
[object]タグを使う方法と[store_unit]タグを使う方法で、この２つにはそれぞれ長所と短所があります。
まず[object]ですが、このタグは比較的にハンドリングが簡単な事と変更内容に期間を設けられるなど細かい設定ができるのが長所です。
[object]で変更されたユニットのデータには変更内容を記録した[object]という変数が付加されます。これは[object]を使用するたびに新たに付加されるので、
頻繁にユニットデータを変更する場合はユニットデータのサイズが大きくなる傾向にあります。
対して[store_unit]の場合は、データの変更箇所を正確に指定する必要があるため少々扱い難い部分があります。
その代わりデータに[object]が付け加えられる事が無いため、頻繁にユニットデータを変更する場合には有効な方法と言えます。
さらに注意するべき点として、この２つの方法は混在させないほうが良いという事です。
[object]で変更されたユニットは[object]の有効期間が終わる等で[object]が削除される場面になると、大元のユニットファイルからユニットデータを再構築するようです。
このとき、[store_unit]によって変更されたデータは失われてしまいます。つまりユニットデータを操作する場合はどちらかの方法で統一したほうが無難という事です。
[object]によるユニットデータの操作については本家wikiのリファレンスに詳しく説明されていますので、ここでは[store_unit]について考えてみます。
[store_unit]というタグはいくつかのイベントと組み合わせてユニットデータを操作する事ができます。
基本的な使い方は、例えばこんな感じ。
----------------------------------------------------------------
イベント1：フィルターに合致したユニットを変数として複製する。（temp_unitという変数が作られます）
[store_unit]
[filter]
id = unit_id
[/filter]
variable = temp_unit
[/store_unit]
イベント2：変数を操作して、データに変更を加える。
[set_variable]
name=temp_unit.vision
add=6
[/set_variable]
とか
[set_variables]
name = temp_unit.resistance
mode = merge
[value]
add_to_arcane = -10
add_to_blade = -10
add_to_cold = -10
add_to_fire = -10
add_to_impact = -10
add_to_pierce = -10
[/value]
[/set_variables]
とか
[clear_variable]
name = temp_unit.attack[1]
[/clear_variable]
イベント3：変更した変数を元のユニットに反映させる。
[unstore_unit]
variable = temp_unit
[/unstore_unit]
イベント4：ユニットに反映後、不要になった変数を削除する。
[clear_variable]
name = temp_unit
[/clear_variable]
----------------------------------------------------------------
要はユニットの複製を作り、それを編集してオリジナルのユニットと置き換えるという操作をします。
上記のイベントの流れで、1・3・4番はほぼお約束の手順となり、2番の部分が操作するユニットデータに応じて変化します。
現在、私が制作途中のアドオン「Castle_of_evil_spirit」では[store_unit]を使用したユニットの変更が頻繁に行われます。
登場するユニットも、そのイベントが発生するのを前提にユニットファイルを作成しています。