いやぁ。急にNeoMuplをいじりだしました。
色々やるべきことがたまっていたりするので、まずはランダム演奏で当たる確率の調整機能を作ろうかと考えていたのですが、そのためにプロジェクトを開いてファイルの内容を見ていたら読み込み部分がなんとも不恰好なことになっていたのでこっちを先に改良しようかなどと思って改変を始めたのですが、なんだかんだで結局準備の準備段階ぐらいまでで両方とも終わってしまいました。
掲示板のロボットによる迷惑書き込みへの対策を考えています。
私が目指すのは、投稿者に少しの面倒をかけて確実に迷惑書き込みを排除する方法ではなく、一般の利用者には迷惑書き込み対策なんて意識させずにロボットだけが困るようなやり方です。
それでまず考えられるのが、HTMLソースのスクランブル。
完全にまぜこぜにするのではなく、入力フォームのname属性を意味不明な言葉にしてやるのです。
しかし結果だけいうと、それでも迷惑書き込みは来ました。
ロボットかどうかは定かではないのですが。
いろんなブラウザにそれなりに対応しつつ、迷惑書き込みはできないようにしたいのです。
メモちらしのページに暴走について記述しましたよ。
ちょっと数値設定に対してデリケートすぎるんですね。
こちらのほうでは時間を掛けてやっと傷跡が戻ったところです。
とにかく極端なパラメータ変化は危ないようなのです。
Bomber丸Worldの属性攻撃について考えてます。
私は敵の属性がわからず力押しで戦ってしまうことがたびたびあり、自分のゲームでも同じようなことがみんなに起こったら嫌だなぁと思うのです。
属性を色分けしてみるとか、いっそのこと誰かが教えてくれるとか、ちゃんと考えてプレイできるような方法を考えているところです。
昨日の計算は、結局うまく係数を消すことができて、答えを導き出すことができました。
それに伴い学習帳を更新しました。
それで、メモちらしのほうもうまく機能追加できたのですが、新機能が悪かったのか、こっちの操作が悪かったのか、暴走が始まってしまいました。
時々暴走に備えてバックアップを取っていたのですが最近はバックアップをほとんどしていなくて、戻せませんでした。
う～ん、やっぱり根本的な対策が必要なのかなぁ…。
とりあえず今のところはゆっくり時間を掛けて暴走した傷跡を元に戻していこうと思います。
んで、更新しちゃいましたよ。
スクリプトのところ。
これで構文解析と字句解析ができたので一度小手調べに簡単な数式を解釈するインタープリタを作ろうともくろんでいます。
まあ、それなりに時間はかかりそうなので、途中に他の更新をはさむかもしれませんが。
メモちらしの自動調整の計算、どうもおかしいと思っていたら最初に考えた式が間違っていました。
もっとも、その間違いを直したからといって式が特別簡単になるということはなさそうなのですが。
スクリプト作成講座の記事を書いています。
結構自分でも理解してなくてしどろもどろですが、書いているうちになんとなくわかってきたような気がするので明日ぐらいにはアップできそうな気がします。
Bomber丸Worldのトップページのランダムメッセージを実はこの前こっそりJavaScriptからPHPに入れ替えていたんですが、そのせいでindex.htmlを解析してダウンロードページを自動生成するプログラムに通らなくなってしまっていたので、自動生成プログラムのほうをPHPに対応させておきました。
そして、昨日のバトル2の更なるアレンジ曲を今日作っていました。
テンポを一定にすると結構変わるものですね。
一応このアレンジは大ボス用のアレンジであり、バトル2はザコ・中ボス用です。
メモちらしの長さ自動調整アルゴリズムを考えるため計算してたんですが、計算を進めるうちに却ってややこしくなってきて、手が付けられなくなってきました。
いや、式そのものは短いんですが、どうしても勝手に決めた係数が消えてくれないんですよ。
その係数が正しければそのままでも別にかまわないんですが、消えることを前提にして考えていたため当てが外れました。
Bomber丸Worldのバトル2の曲がほぼ完成しました。
なんか、マザー3の影響を色濃く受けている部分があったりなかったりします。
ループ部分の一番最後は、ふにゃふにゃで使うつもりだったボス曲のボツ曲と同じメロディを、その前の部分はふにゃさんのこれまたボツ曲を使っています。
Bomber丸Worldではこうやっていろんな形で昔のボツ曲が姿を表すと思われるのでご覚悟を。じゃなくて、お楽しみに。
開発室のほうにもアップしてますがこっちにもアップしておきました。
ナマライザの読み込み処理、これで完成かと思いきや全く正常に動かないプログラムであることが判明！
いえ、まだ実行したわけじゃないですが、簡単なデータを想定してコードを順番にたどっていったら、まだ読み込まれていないデータを処理しようとして、データがないとして、データが丸々残ってるのに次のステップに行って、その次のステップでは次に来るデータが特定の形式であることしか想定していないので、誤った場所のデータでは当然形式が会わなくて、どんどん違うデータを生み出し続ける、ということになってしまっています。
特定のフォーマットのみに対応して高速化を図ろうという考えでしたが、ちょっといくらなんでもデータの狂いに対して弱すぎるようでした。
今の状態だと全く正しく読み込めないばかりか、その正しく読み込めないところを修正したとしても、データそのものに少しエラーがあった場合でも、どんどん誤りを蓄積してそれ以降の全てのデータに悪影響を及ぼすのです。
ログデータは行単位で記録されているので、データの破損があったとしてもそれにより信用できなくなるのは該当する行だけであり、改行コードの一つも出ればそれ以降のデータは正しい可能性が高いのです。
というわけで今後の課題は、データの正しい読み込みと、エラー時の復帰の２つになります。
末端の表示処理はまあ速度さえ気にしなけりゃそれなりに楽にできるでしょう。
データ読み込みのときにも同じことを思っていたような気がしてなりませんが。
メモちらしの改良を考えています。
どうしても粒子の数が増えてくると色々なところで腕が伸びきってしまって扱いにくくなるので、腕が必要以上に伸びないような対策を考えています。
これの根本的な原因は平方根計算をするのを嫌って反発力の算出に距離の二乗に反比例した値ではなく距離に反比例した値を使ってしまったことだったのですが、既にこの仕様で動き出してしまっている以上、この部分は現段階のメモちらしでは変更するわけには行きません。
そこで、対症療法的な考え方ですが、これ以上伸びてもらうと困るという、そういう数値を設定しておいて、腕の長さがその数値を超えている場合は腕の引っ張り強さを上げるのです。
ただ、腕が長すぎる間ひたすら上げっぱなしだと、本当は時間さえかければ規定の長さに戻るのに、その途中であっても規定の長さに達していないというだけで必要以上に腕を引っ張ってしまうので、それが暴走や、縮みすぎという結果を招く可能性が高いです。
それを防ぐには、自動で腕の引っ張り強さを下げることはしないので、とにかく腕の引っ張り強さの上げすぎに注意する必要があります。
腕が長すぎるということは、つまり、腕の引っ張り強さが弱すぎて、反発力に負けているということを意味するので、反発力≧引っ張り力である間だけ引っ張り強さを上げてゆきます。
反発力＜引っ張り力となっている間は腕は縮み、腕が縮むと反発力が上がり、引っ張り力は弱まります。
引っ張り強さが足りない場合、腕の長さが規定に達する前に再び反発力≧引っ張り力になるため、改めて引っ張り強さを上げてやります。
これを規定の長さになるまで続けてやれば、おおよそ規定の長さよりも少し短いところで腕は縮み終わるはずです。
縮みすぎたところがあれば、まあ、それを編集するのは長すぎの場合よりは簡単なので、手動で調整してもらいましょう。
