---

こんばんは。今更ながら「じょしらく」が面白いぽりです。


１．せいさくにっき


今はリアルの方がかなり忙しくて、なかなか製作に手をつけられてません。ウディタ新聞も遅れがちでごめんなさい。

いや本当に暇なくてウディタにも触れてないし、ゲームも少し前に教えてもらった「分裂ガール」以外やってなかったりします。

（「そういえばお前一昨日ラブプラスやってたよな」という意見は受け付けない）


ところで製作自体の前回からの進捗状況は、

システム：90%→93%
パズル：23/50(46%)→30/50(60%)
シナリオ：3/9(33%)→4/9(44%)
マニュアル：0%→0%
 
ってな感じ。「忙しいって言う割にはパズルの進行具合が大きいな」と思うかもしれませんが、汎用化システムの大好きなぽりが以前に頑張って「DBに数値入れるだけの４～５分ぐらいで１コース作れる」システムを組んだためです。ぶっちゃけパズルデザイン考えるほうが数十倍時間かかってます。


みなさんも暇なうちに「忙しくなっても製作ができるように汎用性持たせておく」ことは非常に大切だと思うので、面倒くさがらずに。ってこれゲーム製作に限った話でもありませんけどね。




２．コモンイベント整理とかデータベース整理とか

じゃあ、そんなにシステムを重視する人のコモンイベントとかどんなのなの？という意見もありそうなので公開。コモンイベントとユーザーDBです。


（コモンイベント　システム進捗93%ってことなのでこれ以上大きくは増えないでしょう）



（ユーザーDB。可変DBも３個ぐらいしか使ってません。）




こんなもんです。マジで。だから整理とか今まで１度も考えたことがない。

自作システムとか好きなぽりがどうしてこんなに少ないイベント数なのか、まぁ答えは簡単で、「何でもかんでも１つのイベント・データベースで全部やろうとするから」なのですけど。

ぽりは「処理１つにつき、出来うる限り１つのイベント枠で収めたがる」タイプなのです。区切る必要を感じない上に、「イベント呼び出し」多用したら重くなっちゃうというのが理由なのですが。


それはぽりの過去作に置いても同様で、「あたまの中のゆうしゃ様」の戦闘処理は全部１イベント(565行)、「EOF -End of File」も移動・クリックの監視が１イベント(142行)、右画面のメニューバーも全部の処理を１イベントで(317行)やってます。これはひどい。



※ちなみにこの方法、ぽりは慣れてるから問題ないのですが、バグ原因を探すのが大変・変数領域確保が面倒などあるので、耐性のない方が安易に行うと動悸・息切れなどの症状を起こし最悪死に至る可能性がございます。今のはさすがに言いすぎですが、バグ修正時に文字通り「死ねる」のは確かです。




３．チェックサム補足

ついったーで言ってた「チェックサム」についてちょいとだけ補足。ウディタサーチに「講座:小技・コネタ」で登録した以上、そういうネタも扱って行かなくちゃいけないしね。

長いので続きは下から。

---

さて、チェックサムというのは簡単にいうと「チェックするためにサム（合計）する変数」です。何言ってるかわからないと思うけどこれが答えです。


さて、ゲーム製作者にとって恐れるべきことは
１．ゲームそのものを改造される
２．ゲームの"セーブデータ"を改造される

の２つなんじゃないかなー、と思います。１をされちゃったらもうどうしようもないけど、２の「セーブデータ改造」ならある程度抗うことが出来るのです。


改造対策として一番簡単なのが「ステータスを調べて異常に高かったらゲームオーバー」っぽいですね。（情報提供ありがとうございます）簡単な話、改造する人って改造して何するかといえば「HPを9999にする」とか「攻撃力を999に」とかがメインですから、HPが9999だったら改造認定するとか言うのも確かに理にかなった話。


さてこれの問題点は２つ。

１．じゃあ9998に改造すればバレないよね？
２．努力だけで9999まで到達した人も改造認定されちゃうよね？
 

そこで、こういう事を起こさない改造対策として「チェックサム」を行うのです。上の方法が「ステータスが高かったら改造認定」だとしたら、チェックサムは「ステータスが変わるイベントを起こしてないのにステータスが変わってたら改造認定」です。



チェックサムのやり方は簡単。「チェックしたい変数群の合計を覚えておいて都度確認する」です。


改造チェックをしたい変数を仮に「攻撃力,防御力,精神力,敏捷性」とします。
例：攻撃:100　防御:50　精神:100　敏捷:50
↓
新しい変数（ここでは「チェックサム」）を用意し、「攻撃力+防御力+精神力+敏捷性」を保存しときます
例：攻撃:100　防御:50　精神:100　敏捷:50　チェックサム:300
↓
（もしここで攻撃が改造されたとします）
例：攻撃:999　防御:50　精神:100　敏捷:50　チェックサム:300
↓
時々チェックサムと「攻撃力+防御力+精神力+敏捷性」が間違ってないかチェックします
例：攻撃力+防御力+精神力+敏捷性=1199　チェックサム=300なのでおかしい！



これならば「改造ならば高くしようが低く使用が気づく」「努力でステータス上げてる人は絶対出会わない」ですね。
※「装備変更」などのステータスが変わるときにチェックサムの値も変わるので、都度変えとかないと「装備変えただけで改造認定された」とかなりかねないので注意してくださいね！





さて最後に発展型。
上のチェックサムは「改造したこと」は分かるけど「どこが改造されたか」「改造される前のステータスはいくつだったのか」がわかりません。これを考慮した発展型チェックサムも考えてみましょう。

※注意
この方法、元ネタが「ハミング符号」という普通にいろんなソフトで使われてるアルゴリズムのため、難易度高いです。計算とか苦手な方は読んで混乱する恐れがあるので注意。





１．改造をチェックする変数をV1,V2,V3,V4、チェックサムをC1,C2,C3とする（チェックサム３つにつき、変数４つまでチェック可能です）

２．以下のとおりにチェックサムを保存する
C1=V1+V2+V4
C2=V1+V3+V4
C3=V2+V3+V4


３．時々チェックサムと変数の合計が間違ってないかチェックする

４．間違ってた場合と改造前の数値は下の表のようになる

間違ってたチェックサム	改造されたと予想される変数	改造前の数値
C1のみ	C1	V1+V2+V4
C2のみ	C2	V1+V3+V4
C3のみ	C3	V2+V3+V4
C1,C2	V1	C1-(V2+V4)
C1,C3	V2	C1-(V1+V4)
C2,C3	V3	C2-(V1+V4)
C1,C2,C3	V4	C1-(V1+V2)

どこが改造されたのかがわかる上に改造前の数値まで分かるなんてなんと便利！と思うでしょうが、同時に２つ以上のステータスが改造されてたら誤検知するのが問題ですね。（V1とV2を同時に改造したらV4が改造されてる扱いになる）

なので一般的な場合ではこの方法は不便です。状況によりけり、ですね。