ホムンクルスAIについての独り言
[ラグナロクオンライン]のホムンクルスシステムで使用する ホムンクルスAIのカスタマイズについてのメモ
プロフィール

モルティシア

Author:モルティシア
何時の間にやら貧乏キャラが定着しそのまま「安ケミ」と呼ばれるようになった「安っぽいケミ」
一時休止していたものの、最近ふたたびホムンクルスのカスタムAIの開発&公開を再開
メマー無しPC3の42転職
[完全製薬・完全露店]キャラ

カテゴリー

月別アーカイブ

最近の記事

最近のコメント

最近のトラックバック

ブロとも申請フォーム

この人とブロともになる

リンク

このブログをリンクに追加する

ブログ内検索

RSSフィード

FC2カウンター

メールフォーム

名前:
メール:
件名:
本文:

スポンサーサイト
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

pairsを使ってて気がついたこと
mobdata.luaの中身を一個一個手書きで書き換えるのが非常に手間だったので
mobdataから読んだモンスターのデータを元に、自分が使い易いデータファイルを作るようなLuaプログラムを作成してました
その途中で気がついたこと
どうやらpairsは600を超えるテーブルを扱えないらしい
正確には699くらい
なのでmobdata付属のMOBDATAテーブルを全部読み込もうとしたらループが止まります
エラーじゃなくてループを勝手に脱出する様子
不便だけどwhileを使った方が安定するみたい

とりあえずmobdataからモンスター情報を自分で見易いように組替えて、データ100ずつのiniに分ける
さらにテーブル番号とモンスターの名前が分からなくなったときのために対応表も出力させて下準備完了
後は空いてる所に使いたい情報をチマチマ入れていけばデータベースは完成
明日から過去にメモ書きしたVer8でMobDataを使ってやりたいこと、を見直してアルゴリズムをあれこれ考えてみよ
ホムが自分のステを知らないっていうのが辛いです
・゚・(ノД`)・゚・
スポンサーサイト
処理の軽量化 メモ
Ver5よりチマチマと行ってきた処理の軽量化ですが、現時点のVer7で落ち着いています

AIの軽量化を考えている方の参考に、この安っぽいAIで行っている軽量化処理について書いてみたいと思います


[続きを読む...]
演算誤差に関するメモ1
9桁から演算誤差が発生
桁がでかくなるほど数値がおかしくなる
Luaでは9桁未満でないと演算不可能
プチライブラリ?
風邪で熱あるので学校休んで横になりながら頭の中でアルゴリズムをゴリゴリ考えてました
夜になってちょっと体調良くなったので動作テスト

バグとれたっぽいので公開

ボーっとする頭で1時間半くらいでぱぱーっと正常に動作するまでやっつけたやつなので負荷はあまり考えてないです
あとでまとまった時間とれたらGetActors ()でとれるIDでも並べ替えて負荷テストやってみます

とりあえず今日はここまで

現状のテーブルの全部のデータを一個一個見る方法でも特に重さは感じないのだけど、
どうせなら極限まで軽くしたいなーということでこの処理を実装
そもそもMobdataを扱う時、全てのモンスターの情報を一個一個検索すると、索敵時のGetActors ()の負荷も併せて私のPCではちょっとラグ出るのです
二分探索なら今までのテーブル検索の半分のスピードと負荷でデータを探すことが出来るのだけど、どのくらい有効なんだろ

もしこれが成功してたらAIが扱う様々なデータの検索が少しでも軽く行えるようになり、後々実装予定の様々な妄想が一歩現実に近付きます

一個一個データを見ていく線形探索より負荷が少なく早い検索アルゴリズムは他にもいくつかあるのですが、まずは仕組みが単純な二分探索方式ですね
他の検索アルゴリズムも、可能そうなら試して見たいと思います

ただ検索する前のデータのソート処理が若干重いかなというのが心配です



以下、データを昇順に並べ替える処理&その並べ替えたデータを二分探索する処理


[続きを読む...]
非先行における突然の先行化について
うちのAI用BBSに書き込みがあったので、この現象について私が知っていることをちょっとまとめてみます

経験からの認知であるため、これが正しいと言い切るつもりはありませんが
これは恐らく「さっきまで戦っていた敵」と「新しく沸いた敵」のIDが同じであった時に起こる現象だと思われます

同じ現象はデフォAIでも起こります

非先行状態のGetEnemy処理の構造上
「自分をターゲットした敵」以外を自分から殴りに行くことはありえません

非先行状態のGetEnemyの敵取得は
--
target = GetV (V_TARGET,v)
if (target == MyID) then
~~~~~~~~~~~~~~~~~~~~~~~~~~
--
といった分岐でIDを分類しています

これは「敵IDがホムンクルス自身を敵としてターゲットしているなら」
という意味です
この条件を満たさなければこの先の処理は行われません

なら何故突然ホムがアクティブ化して敵を殴りに行くのか?
原因は二つ考えられます
・「直前までホムをターゲットしていた敵」と「全く同じIDの敵」が新たに現れた
・「直前まで主人をターゲットしていた敵」と「全く同じIDの敵」が新たに現れた
この二つです

この時AI上では「敵が攻撃範囲外に逃げた」としか認識しません

その為、IDが同じであるのでその敵を殴りに行ってしまいます

さらにややこしいことにROでは「ターゲット」の「情報が上書き以外の方法でリセットされていない」様なのです
つまり、新たに同じIDのモンスターが沸いた時、そのモンスターが他のキャラを新しく殴らなければ
新しく沸いたモンスターであるにも関わらず、古い「ターゲット」情報が残っているのです

AIはこれを「自分がターゲットされている」と誤認して殴りに行ってしまいます

対策は不可能ではないでしょうが、
動作テストを行うための条件を意図的に作るのが難しくまともなテストが出来ないのと

古い敵のターゲット情報をどうやってAIに認識させるか?
モンスターが新たに沸いたということをどうAIに認識させるか?
といった問題が残っています

自動的に反撃しなくていいのなら
IDLE_STのホムの敵を取得する処理へ飛ぶ部分
[object = GetMyEnemy (MyID)]
を削除してしまえばOKです

これで勝手に殴りに行くことは殆ど無くなるでしょう

その代わり 自 衛 も し ませ ん
(しかも『「直前まで 主 人 を ターゲットしていた敵」と「全く同じIDの敵」が新たに現れた』 には対策できてないし)

個人的にはこの改造はオススメできません
どうしてもこの誤作動が気になる方だけが自己責任で行ってください

個人的には、敵を倒した後ホムがどこかへいこうとしたら
咄嗟にALT+Tでいいんじゃない?とか思っています

良い対策方法がひらめいたら随時実験して実装していきますが、これはスタック同様に仕様であると諦めた方がいいかもしれません

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。