ラインブレイカ、どうせ根本から考え直すならいっそのことCで書き直して思いっきり高速化しようかななんて考えたりしてます。
アルゴリズムはある程度考えています。
バックアップはオプションじゃなくて必ず作るようにして。
日記のカテゴリに「日記」を追加しました。
日記そのものについて書いた日記もたくさんありますので。
それと、日記のファイル構造も根本から見直そうかと考えたりしています。
さすがに日記のログが1500日分を超えてファイルサイズも1MBを超えてしまうといろんな部分でつらくなってきます。
バトル4のMIDI、着実に進んでいます。
あの曲はバイオリン・ピアノ・フルート・太鼓の4つが入った曲なので、一つ一つにきっちり特徴をつけながら作っています。
爆ボンのページを更新しました。
最近は参考タイムばっかりですけどね。
ブラックシティ4面をクリアしてレインボーパレスへ、そしてレインボーパレスの1面をカード5狙いでクリアして、2～4面はそのまま一発で全アイテムを入手しました。
というわけで残すはレインボーパレス1面のカード5以外のアイテムです。
今更ながら、ラインブレイカ、めっちゃくちゃ遅いですね。
今日、27日から29日にかけて異常な数のアクセスがあったことに気付いて調べていたのですが、要らない情報の削除のためラインブレイカに通したら普段なら数分以内で終わるところが高々10倍程度のデータ量で数時間経っても終わらなくて、どうにも効率の悪いアルゴリズムを組んでしまったために行数の2乗以上のオーダーで増えているような感じがします。
だとするとメモリ使用量も不必要に多い可能性が考えられるので、一度根本からソースを見直そうと思います。
簡易アクセス解析でも似たようなところで高速化ができるかもしれませんね。
こちらは根本からではなくちょっと手直し程度で。
αゲームズのページを作ろうと色々やっていたのですが、ランキングのこととか、それぞればらばらのバージョンをどう統一するかなど、気になる部分が数多くあったのでなかなか作業が進みませんでした。
ファイル名に関しては全部全くばらばらだったので重複の心配は無かったのですけどね。
TGscriptの小吹き出しを改善しました。
これでFireFoxでもそれなりの表示ができますし、IEでもより見やすくなりました。
もっとも、FireFoxのほうではなぜか存在しないはずのスペースが表示されてしまって少し困っているのですが。
あと、表面上は何も起こっていませんが、共通処理と設定のファイルを分けました。
これは動作の変更をしたいときに設定の下までスクロールするのが面倒だったという、ただそれだけのことです。
昨日のMIDIをもうちょっとマシになるように改良していました。
この曲は聞いたとおりの曲名で、曲名通りの相手と戦うときのBGMだったりします。
マザー3のニューヨクバの画像からただのヨクバの戦闘画面風のドット絵を作ってみました。
どうせヨクバと戦うならサルサVSヨクバの夢の対決にしてみようじゃないかとか、サルサが戦うならいっそサルコも参戦させようじゃないかとか考えて作ってみました。
たぶん状況から考えて空白の3年間の出来事でしょうね。
CharaBoxに音楽や動画などのデータを画像の代わりに使えるようにしようと考えてました。
でも、やめました。
DirectShowを使って途中まで作っていたのですが、やめました。
画像との共存が面倒というのもあったのですが、キャラと音楽とか、キャラと動画とか、関わりが薄そうだな、と思いまして。
Bomber丸Worldに使うBGMの一つを作っていました。
6拍子で何かが混じってる曲です。
とりあえず全体的な雰囲気をつかむためにStringsだけで作ってみたもので、まだまだ本格的に作り出すのはこれからになりますが、今の段階でも結構問題が多そうです。
とにかく、いかにも急いで作ったような雰囲気が前面に出ているのを何とかしなければ。
そんなわけで冷めないうちにプログラミングのところを更新してきました。
今回は1回分開いたので一度に2ページ更新です。
今度からはいよいよ長い長い前置きを終えて本番のスクリプト開発に入りますよ！！
そしてついでにトップページも更新。
コンテンツ名を見ればわかるような説明は省き、もっと内容を簡潔にわかりやすく、興味を持てるように書き換えました。
そして説明一つ一つの行数を必ず2行以内に収め、あまり使わないパーツを目立たないところに移動したりもしました。
そういえばずっと前からタグ名を間違っている部分があったのに今日初めて気が付いてしまいました。
その部分は丸ごと消すつもりの部分だったので今更気付いても意味が無かったのですが…。
爆ボンのブラックシティのページも更新しました。
やっぱりどきどきモードだとハートの制限が厳しいです。
そしてごうかくタイムもフルパワーであってさえ余裕が無い。
そんなこんなで後はレインボーパレスに突入するだけのようです。
これが済んだらいよいよ最速攻略のページなんかも作り始めますよ。
auto_resourceができたのでそれ前提で作る予定のスクリプト作成も始められそうです。
木構造を作ったら後は実行すれば終わりですが、同じスクリプトをいろんな場所で使いまわす場合、実行するごとに結果の変わらない木構造を何度も使用するごとに毎回解析するのはばかばかしいので、実行環境(要するにスクリプト内で使われる変数の情報など)だけを個別に用意して木構造は既に解析済みのものを使いまわそうという魂胆です。
まあ要するに、スライムが10匹現れた場合行動パターンはみんな同じだからHPとかのパラメータだけ個別に持たせておいて行動パターンは一つで充分でしょって話です。
なんかCBWInputが使い勝手が悪いと思って変更を加えていたんですが、ものの見事に失敗しました。
CBWInputを使うときはInitとUpdateとQuitは必ず使う必要があるのですが、そのうちInitとQuitを不要にしたかったのです。
しかし、Initの時点ではCBWDrawや他のもっと低レベルな部分の初期化が済んでいないといけなくて、Quitは逆にそれらの終了処理は始まるまでに呼ばなくちゃいけなくて、それぞれコンストラクタとデストラクタに任せておくことができなくて、断念することになりました。
本当はやろうと思えばできなくもなかったのですが、改変したところで大して手間は軽減されないし、これに依存しているCBWWindowまで道連れで変更になっちゃったりして、仕様変更によって起こる面倒ごとのほうがずっと多かったのです。
ともかくソースの過去ログ残しておいて助かりました。
それと、Quitが実は省略可能じゃなかったのでドキュメントもこっそり修正しました。
auto_resourceも細かい部分で少し修正です。
リソース本体を格納しているautoobjectはコピーが作られるとポインタや参照カウントの関係上色々まずいことが起こるので、コピーコンストラスタや代入が行われるコードを書いた場合はエラーが起こるようにしたのです。
auto_resourceの動作チェックも完了しました。
auto_resourceはその特性上結構アバウトなメモリ管理をしているので許容量を超えてもメモリ解放されず、結果として許容量を超えるリソースが残ったりすることもあります。
このあたりは、小さなファイルを大量に読み込むことを想定して作ったということもあり、そもそも厳密にしたところで別の場所でメモリを湯水のように使ったりしてるはずなので、ここら辺は結構アバウトでもよいかと思われます。
ま、これは無難バージョンを使った場合のことなので厳密にやろうと思えば場合によっては最善バージョンを使えばいいだけの話ですが。
auto_resourceのリソースのメモリ解放もとりあえずできました。
あとは動作チェックと更なる改良だけですね。
auto_resourceのリソースのメモリ確保のほうは大方できました。
あとはメモリ解放のほうですね。
Bomber丸Worldのリソース管理システム(auto_resource)のメモリ管理を考えていました。
メモリ確保のほうはshared_resourceと同じで全く問題ないのですが、メモリ解放が問題なのです。
メモリ確保をしていくうちにメモリが足りなくなったら最近使われていないものからメモリを解放していくのですが、その実装方法がいくつかあって、どれを選ぶべきかというのが難しかったのです。
考えている方法は三つあって、一つ目はその時点で使われていなければ新しかろうと古かろうと片っ端から全て解放してしまうというものです。
解放の際には全てのリソースが入っているコンテナの中身を全て走査して参照カウントが0のものを全て解放します。
この方法は最も実装が簡単で消費メモリも少なくなりますが、一時的に使わなくなったりソースを後のために取っておくというauto_resourceの考え方に反してついさっきまで使っていてまたすぐ使うかもしれないものまでどんどん解放していってしまいます。
マップ切り替えなどで一度に大量のリソースを読み込んで解放する場面ではすごくまずいことになります。
二つ目の方法は、字面通り最後に使われた時間が一番古いものから順番に解放してゆく方法です。
これを現実的な処理時間で実現しようと思えば、リソース参照用のファイル名-リソースを関連付けたマップのほかに、今まで使った順番に並べられたリストが必要になり、必然的にリソース本体とは別の余計なメモリが必要になります。
更にリソース側にも、解放や順番の並び替えの高速化のためにリストやマップへのイテレータが必要になります。
リストの実装によっては更に難しいコーディングが必要になるかもしれません。
そして当然、使用するたびに使用時刻の更新やリストの並び替えが発生するのでパフォーマンスは低下します。
ファイル読み込みによるパフォーマンス低下を嫌ってauto_resouceを作ろうとしたのに全く逆効果の可能性すらあるのです。
解放の際にはリストの末尾から順番に見て行って規定のメモリ以内に収まるか全て走査し終えるまで参照カウントが0のものを解放していきます。
三つ目の方法は、上記二つの中間を取って、ある時間より古ければ数が多かろうと少なかろうと全部解放してしまうという方法です。
これであれば、一つ目の方法ほど無駄は出ませんし、順番を考える必要が無いので二つ目の方法のようにリストを保持しておく必要がありません。
解放の際には適当にしきい時刻を決め、全てのリソースが入っているコンテナの中身を全て走査して参照カウントが0かつ使用時刻がしきい時刻より古い場合には解放します。
これの問題点は、しきい時刻の決め方やリソースの使用状況によって著しく性能が変化するということです。
それぞれ長所と短所がありますが、まず一つ目の方法は通常時には問題外ですが終了時に全てのリソースを解放する必要があるときには効果を発揮します。
二つ目はリソース自体の消費メモリが大きかったり使用するときの実行時間が長いなど、欠点が問題にならないほどスケールの大きいものであれば相対的に長所のみが残って最善の手段となります。
三つ目は二つの中間的なものなので無難としかいえません。
そんなこんなで、三つとも実装してみる価値はありそうです。
GChatの管理画面の改良を行いました。
まず、辞書画面での検索機能です。
これにより辞書への重複登録ということは少なくなったはずです。
そして、なぜか今までずっと実装していなかった全ログ確認機能。
これでもう直接ログファイルを見る必要はなくなったのです。
そんなこんなでアルニックもレベル29になりました。
自分用のリンク集ページが出来上がりました。
まあ、早い話がお気に入りのPHPバージョンというわけですが。
あくまでも好みの問題なのですが、やっぱりサイドバーやメニューとしてのお気に入りよりウェブページのほうがよかったので。
そして、以前のバージョンではよく見る1ページ目の中にもほとんど見ないページがあったり、あまり見ないはずの2ページ目に実はよく見るページが紛れ込んでいたりして、手動でやっているとどうにもおかしくなるので、新バージョンではPHP+JavaScriptで自動化されています。
リンク集並べ替え機能は、JavaScriptで新しいウィンドウに目的のページを開いた後、呼び出し側のページで並べ替えスクリプト(PHP)を呼び出し、並べ替えが終わったら元のページへリダイレクトしてリンク集ページを再表示。
また、JavaScriptがOFFになっていたりブラウザの機能でクリックせずにリンクを開いた場合などは、通常のブラウザの機能としてなんら特別な処理をせずに通常の表示を行います。
この機能がまたリンクにマウスを置いた場合のステータスバーの表示の自然さを生み出します(リンクに直接JavaScriptを書いた場合は表面上無効なURLとなる)。
更に、管理ページは別ページではなくリンク集と同じページにした上JavaScriptで簡単にですが管理支援機能も作って、素早く管理できるようにしています。
また、リンク集そのものとは関係ありませんが、リンク集ページの隣にはフレームでよく使うツールを配置しています。
ついさっきですがゴキブリさんを捕獲しました。
背中の汚れ具合や足の少なさなどから見て幾多の苦難を乗り越えてきた勇者だと思われます。
処分については後で考えます。
メモちらしのバージョンアップを行いました。
内容は、まあ、日記や履歴で書いてあることそのまんまなんですが、日記のほうに書いていない、つまり今日変更したのは、バグ修正です。
実を言うと、どことも繋がっていない粒子を動かなくするという新しい仕様がうまく働いていなくて、その修正のときに見つけたものなんです。
新たに追加した粒子が初期状態としてどことも繋がっていない場合は問題なかったんですが、逆に腕を全て切り離してどことも繋がらなくなった場合に腕がなくなったことを感知できずに動いちゃったんですね。
原因は変数名の間違いでした。
このバグがあると他にどんな影響があるのかはまだ調べてませんが、もしかしたら関係ないはずの粒子が変な動きをするかもしれません。
自分専用リンク集の新バージョンを作っています。
どうにも管理しにくくなってきたのでよくアクセスする順に自動で並び替えたり、実際やるかどうかはわかりませんが公開してるほうのリンク集にあるようにタグ付けで分類したりしようと考えてます。
メテオスオンラインとやらが出るらしいですね～。パソコンで。
正直なところ、すごいと思ったところと、げんなりしたところが半々ぐらいで、差し引きなんとも思わないのと同じぐらいでした。
出そうで出なかったアイテムの登場や、滅亡条件の改良などがよかった一方、わざと削られていたはずの横移動の出現や、余計な地球人の登場など、メテオスとしてはあってはいけないと思っていたようなことが次々起こっていたりもしました。
惑星エディットができるんなら悪いところ全部帳消しにして買っちゃうんだけどな。
いや、あっても買わないかもしれないけど。
Bomber丸Worldのshared_resourceの改良版、auto_resourceの仕様を考えています。
shared_resourceの問題点は、参照カウントが0になるとすぐメモリを解放してしまう点で、0になった直後に同じリソースを使おうとすると無駄に解放と再生成の時間がかかってしまうわけです。
また、ファイル名とファイルタイプは基本的に一対一に対応するため、ファイル名でリソースを管理するshared_resouceは、読み込みアルゴリズムさえそれぞれに対して作ってやれば、内容そのものの管理はリソースの種類ごとに作らずとも一つのクラスで充分まかなえるわけです。
そんなわけで、本当に解放が必要になるときまでメモリを解放せず、リソースをその種類によらず一元管理するauto_resourceを作ろうというわけです。
XMLは、プログラム内に直接書くということも考えられるのでテキスト形式にすることに決めました。
Bomber丸Worldに使うデータの一般的な書式について考えています。
アニメーション定義ファイルにせよキャラクター定義ファイルにせよ、省略記法により手作業の手間を省くつもりが却って全体の見通しが悪くなって様々な問題を引き起こしてるんですね。
融通の利かない仕様でデータ一つ一つに対して新たなプログラムを作り直す必要があるし、手作業を前提としたファイル構造のためプログラムでの生成が難しくなったりもしました。
そこで、融通が利き、拡張性が高く、なおかつゲーム向き、そういうのがほしくなったわけです。
で、とりあえず一つのアルゴリズムでいろんなデータを読み込めて、わりと自由に要素を作れるXMLというものに着目してみました。
特定用途に使うものであり、なおかつ専用ソフトを使って編集する可能性が高いということで、読み書きに都合の良いように独自のアレンジを加えるというのもありかもしれません。
タグの管理は、同じタグがいくつもあるということもありうるのでmultimapで管理するとよいでしょうか。
もっとも、XMLのような考え方を使うとすると、正確にXMLである必要が無いどころか、実際が全くXMLからかけ離れた内容でも大きな問題はなく、初めから専用エディタでのみ作るという前提にすれば、バイナリ形式で構造的にXMLのような、というのもありかもしれません。
爆ボンのページを更新しました。
今回はいろんなステージの実際のクリアタイムです。
基本的にカード5狙いのときのクリアタイムを記録しています。
どきどきモードのアイテム集めのついでだったんですが、ブラックシティ1面で少し失敗してしまいまして、変なところでアイテム集めが滞ったりしています。
レゴのお城のページが更新完了です。
前から見たバージョンと後ろから見たバージョン、部屋を閉めたバージョンと開けたバージョンの計4つの画像があります。
メモちらしの改良をしました。
マウスの下にある粒子を光らせたり作成中の腕が粒子に吸い付くようにしたり、見た目部分での改良です。
マウスを動かしてると粒子が明滅したり、腕の先端がどこかの粒子に近付くとピキーン！とくっついたり、実用性を考えてのことだったのに、楽しさのほうをが強く感じられてしまいます。
掲示板の吹き出しが全種類用意できました。
大小と左右のバリエーション合計4種類で、感情によるパターンがない分以前のバージョンよりは少なくなっています。
さらに、ただ掲示板の普通の記事表示のみに使うとも限らないので、必要な部分は拡張も入れられるようにしています。
ただ、小バージョンについては、テーブルの使用をなくせば軽くなるかと思って別の方法を試みたのですがFireFoxで思ったように表示されなかったり、IEでも文字の位置が若干上にずれるということで、またテーブルに戻す必要が出てきそうではあります。
レゴで昔作ったお城っぽいのを復元できたのでMLCADのデータに入れたりしてます。
お城としてはあまり意味の無いギミックが入ってたりします。
今日は変換トレーニングウィザードを久々に使ってみました。
文字エンコードの問題からかかなり文字化けして登録されていたものもありましたがまたかなりの数が登録されたようです。
相変わらず変な単語も登録されてますが。
で、スクリプトの字句解析のページが完成しましたよ。
字句解析の構文解析との差異とか、実際の字句解析の方法とかを書いてます。
この調子だと次の更新までにはC++での具体的な作り方の議論にまで到達できそうな感じです。
昨日に引き続いてふにゃさんの標準ステージ16面の攻略を書きました。
最難関の13・14面は後回しです。
今日レーザーの実験をやっていたらレーザー装置が壊れました。
どう考えても予想とはかけ離れた結果だなと思っていたら、レーザーのクセに切れかけの豆電球にも劣る弱々しい光しか出していなかったのです。
しかもなぜか替えのレーザーまで不発。
他の種類では成功していたので、結局問題のレーザーはデータとして使わないことになりました。
そうそう、Bomber丸WorldのためのHTML表示クラスを作り始めました。
なんせギャルゲーに特化したyaneSDKのHTML表示だと、RPGに使った場合、どうでもいいところばかりがパワフルで、ちょっとしたことに使おうとすると酷く不便なのです。
ふにゃさんの攻略ページを更新しまくりました。
13～16面のページを用意し、うち15面を完成させました。
後残りは3つだけです。
スクリプトの続きを昨日の勢いがあるうちに書いてます。
インタープリタを作る前にまだ一つやり残したことがありましたよ。
字句解析の方法をまだ論じていなかったではないですか。
それが終わったらそれらの実装方法を書いて、そこではじめて「簡単な数式のインタープリタ」が作れるわけです。
最近は少し更新ペースを速めているのですがそれでも一回に一箇所の更新では先が思いやられます。
ActiveBasicでゲームを作る企画のときみたいに一回に数箇所一気に更新してしまうぐらいの勢いが無いと少しつらいかもしれません。
一応年内に完結させるつもりではいますので。
うん、今日が体育の日だと思ってましたが昨日だったんですね。
昨日朝気付きました。
プログラミングコーナーは無事更新できました。
今度こそはインタープリタを作れそうです。
今日書いたあの方法をプログラムとして書くことさえできれば…。
まあ、たぶん来週の更新分を書き始めればそのうち思いつくでしょう。
一応今も漠然と方法が浮かんではいるのですが、それと具体的なコードとは大きな隔たりがありますからね。
今日はパソコン周りの掃除とパソコンの配置換えをしました。
パソコン周りは普段掃除が行き届かないため凄まじい量の埃でした。
特に本体の見えない部分にあった吸気口にあった埃が酷く、熱暴走で落ちたことがあるのもこのせいかと思いました。
そしてパソコンの配置換えです。
最近周辺機器の位置関係がすごく悪くメンテナンスしにくいと感じていたのでこの機械に配置換えを、じゃなくて、本当は逆に配置換えをしようと思ったらあまりに汚くて掃除をし始めただけだったんですが。
そして配置換えの結果、本体やキーボードなどの位置関係を見直すことで埃がたまりにくく清潔に、配線を背面から側面に移動してメンテナンス性向上、配線の関係上使えなかった引き出しを有効活用しスペースの無駄を削減、かなり使いやすくなったはずです。
そしてついでにパソコン本体も分解して中を見てみました。
内部は外から見るほどは埃まみれではなく、やはり排熱問題は埃による吸気口の機能低下が原因だったようでした。
で、今はプログラミングコーナーのスクリプトのページを書いてます。
どうにも簡単なインタープリタを作るのにすらまだ早く、もう少し基礎固めが必要だったようです。
木構造を作るのに意外と難儀してます。
でも何とかできそうな見通しは立ってきたので明日あたりにでも更新しておきたいところです。
ゼルダの伝説ーふしぎの木の実のところを更新しました。
ふしぎの木の実に限定した話ではなかったのですが、これが中心となっている話だったのでふしぎの木の実の場所に収まりました。
衝撃の事実、ハイラルを沈めたのは○○○だった…！
サイト全体のスタイルシートを改良しました。
改良箇所は一箇所、thです。
特別な例外を除いて自動改行が入らないようにしました。
なぜかというとテーブルの列が多くなると一つ一つの列が狭くなってしまって滅茶苦茶縦長のページになってしまうので列の最低幅確保のために使うのです。
もちろん横幅の広いthは自動改行するような設定に戻して幅の広がりすぎを防ぎます。
これをやった理由というのが、ふにゃさんのバージョン比較ページの書き方です。
NeoMuplのバージョン比較ページも同じようにしようと思っていて、そうするとNeoMuplは更新回数がかなり多くなりますから、画面より広いテーブルになりやすいのです。
それで上記の設定変更を行ったのです。
そして、そうすると右側が切れてしまって最新バージョンの機能がわかりにくくなってしまうので、新しいバージョンを右側にするのではなく逆に左から新しい順にすることにしたのです。
爆ボンのきょくのページを分離しました。
それに伴ってずっと作り続けていたブルーリゾートのMIDIも公開です。
とはいえまだハープの打ち込みが最後まで済んでいないのですが。
今日メモちらしが原因不明の動作停止をしました。
元々暴走が怖かったため動いてるか動いてないかわからないぐらいの低速で動かしていたのでずいぶん長いこと気付きませんでした。
とりあえずソフトを再起動したら直ったのですが、止まる条件はプログラムの終了以外になかったはずだったので少し気持ち悪いです。
のんびりナマライザのログ読み込み部分の中枢が出来上がりました。
先月27日に言っていたところのファイル解析です。
まず、速度は多少遅くなるのですが、エラー処理を正しく行い、可読性の高いコードになるように、そしてもちろん正しいデータに対しては最低限正しく動くようにしました。
読み込みの都合や実際に解析するときの必要性などから一部のデータを使わないことにしたり場所を色々移動したりもしました。
掲示板の迷惑書き込み対策、もっと単純でなおかつ当たり前の方法がありました。
投稿内容反映の前に、投稿内容確認画面を入れて1ステップ多くするのです。
これにより一般のお客様には利便性が上がり、迷惑書き込みをする人には面倒になるのです。
一般のお客様から見れば、投稿結果のイメージが投稿前に確認できるし、やろうと思えばその場で修正もできるし、不適切な表現があれば警告が出るし(出せるようにしたい)、チャットのようにガンガン書き込みまくるということもないので便利さだけが大きく上がるのです。
そして迷惑書き込みをする人にとっては、一手間多くかかる(つまり2倍面倒になる)、機械での投稿がしにくくなる、ということで書き込みにくくなるのです。
NeoMuplの最新版をアップしました。
今回の改善点は演奏準備中の表示をすることにしたことです。
機能追加というほどのことでもありませんが、今演奏しようとしている曲とタイトルバーに表示されている曲が一致しないという気持ち悪さは避けられます。
ただ、同時に色々未実装な物も乗せてアップしてしまったので使い勝手はむしろ全体として悪くなっているかもしれません。
Bomber丸WorldのライブラリのページのCBWTextDIB32とshared_resourceのページができました。
あまり説明らしい説明にはなっていないのですが。
あと、キャラの行動アルゴリズムのFollowとGotoの改良を考えています。
経路を考えるのが、経路を考える必要ができた瞬間1Fだけであり、たくさんのキャラクターが同時に動こうとしたとき処理落ちが起こる可能性が高いのです。
また、負担軽減のため探索深さを少なめに設定していたせいで探索範囲が狭くなり、遠くから追いかけるということができなくなっていました。
これは、探索する側が最短経路を探すから遅いのであって、追跡される側のほうが最短経路を求める手がかりを残しながら歩いていればよかったのです。
そして、手がかりは、一度に全部用意するのではなく小出しにしていくことで処理の負担を和らげます。
掲示板にの一般の利用者に迷惑のかかりにくい迷惑書き込み対策については、一つの案として、レベル別の書き込みフォーム＆投稿内容制限の変化を考えています。
まず書き込みフォーム。
元々用途に応じて様々な形態の書き込みフォームを使うことを考えているので、普通の投稿にも様々な投稿フォームがあってもあまり問題にならないのです。
非常に大まかに分けると、簡易コメントフォームと通常書き込みフォーム。
簡易コメントフォームはテキストだけのシンプルな画面構成で誰でも書き込むことができますが、載せられる情報は少なく、ちょっとしたことで投稿内容審査に引っかかり、封印されます。
通常書き込みフォームは、クッキーと画像を使って、利用者別の投稿画面が自動的に割り当てられます。
画像には適切な代替テキストを用意せず、目で見ないと何が書いてあるかわからないようにし、入力フォーム自体の形や配置も毎回変化します。
これでロボットによる書き込みフォームの判別は難しくなります。
しかし、各入力欄のname属性がわかりやすい名前であると意味がないので、一見意味のない文字の羅列をname属性に使い、投稿された時点でCGI側で、じゃなくてPHP側で元の名前に読み替えます。
そして、元の名前と意味不明な名前の対応も、一定時間で変化します。
すると変化する時間をまたいでの投稿がまずいことになりますが、そのあたりの時間差は考慮して、正しい対応を取れるようにします。
いやぁ。急にNeoMuplをいじりだしました。
色々やるべきことがたまっていたりするので、まずはランダム演奏で当たる確率の調整機能を作ろうかと考えていたのですが、そのためにプロジェクトを開いてファイルの内容を見ていたら読み込み部分がなんとも不恰好なことになっていたのでこっちを先に改良しようかなどと思って改変を始めたのですが、なんだかんだで結局準備の準備段階ぐらいまでで両方とも終わってしまいました。
掲示板のロボットによる迷惑書き込みへの対策を考えています。
私が目指すのは、投稿者に少しの面倒をかけて確実に迷惑書き込みを排除する方法ではなく、一般の利用者には迷惑書き込み対策なんて意識させずにロボットだけが困るようなやり方です。
それでまず考えられるのが、HTMLソースのスクランブル。
完全にまぜこぜにするのではなく、入力フォームのname属性を意味不明な言葉にしてやるのです。
しかし結果だけいうと、それでも迷惑書き込みは来ました。
ロボットかどうかは定かではないのですが。
いろんなブラウザにそれなりに対応しつつ、迷惑書き込みはできないようにしたいのです。
メモちらしのページに暴走について記述しましたよ。
ちょっと数値設定に対してデリケートすぎるんですね。
こちらのほうでは時間を掛けてやっと傷跡が戻ったところです。
とにかく極端なパラメータ変化は危ないようなのです。
Bomber丸Worldの属性攻撃について考えてます。
私は敵の属性がわからず力押しで戦ってしまうことがたびたびあり、自分のゲームでも同じようなことがみんなに起こったら嫌だなぁと思うのです。
属性を色分けしてみるとか、いっそのこと誰かが教えてくれるとか、ちゃんと考えてプレイできるような方法を考えているところです。
昨日の計算は、結局うまく係数を消すことができて、答えを導き出すことができました。
それに伴い学習帳を更新しました。
それで、メモちらしのほうもうまく機能追加できたのですが、新機能が悪かったのか、こっちの操作が悪かったのか、暴走が始まってしまいました。
時々暴走に備えてバックアップを取っていたのですが最近はバックアップをほとんどしていなくて、戻せませんでした。
う～ん、やっぱり根本的な対策が必要なのかなぁ…。
とりあえず今のところはゆっくり時間を掛けて暴走した傷跡を元に戻していこうと思います。
んで、更新しちゃいましたよ。
スクリプトのところ。
これで構文解析と字句解析ができたので一度小手調べに簡単な数式を解釈するインタープリタを作ろうともくろんでいます。
まあ、それなりに時間はかかりそうなので、途中に他の更新をはさむかもしれませんが。
メモちらしの自動調整の計算、どうもおかしいと思っていたら最初に考えた式が間違っていました。
もっとも、その間違いを直したからといって式が特別簡単になるということはなさそうなのですが。
