ジャンル不定の日記です。

シンボリルドルフ系確立失敗で考え中・・・

ウイニングポスト7のシンボリルドルフ系を確立失敗したんで考え中。

http://yukiasa605.blog.fc2.com/blog-entry-44.html
↑ここで96年末に確立できたときのデータが書いてあるが、
シンボリルドルフ
トウカイテイオー
アイルトンシンボリ
ミスタールドルフ
を所有で、自家生産馬の種付け料が、
1500万
1500万
1500万
1000万
700万
しかも、ミスタールドルフが1300万。

うちのデータだと、
アイルトンシンボリは1500万行ってるが、
ミスタールドルフが400万で自家生産が350万と150万だけ。

うちで96年のパーソロン系が4.5%でシンボリルドルフが消えて3.8%になったんで、全然足りてない。
リンク先ページのデータくらい稼がせる必要がありそうだが、
シンボリルドルフの初産駒が88年で95年までに引退させるとなると5世代だけ。
できるような気がしない・・・

シンボリルドルフを所有とのことだから年間20当種付けできるが、うちは所有してないのでシンジゲートだから年間5頭程度しか種付けできないという違いがあるが、
メジロラモーヌとマックスビューティーが3冠配合できておすすめと書いてあるので、この2頭いれば狙えるか?
と考えて血統確認してみたが、
メジロラモーヌ 母父○なし 名種牡馬因子x2
マックスビューティー 母父○なし 名種牡馬因子x3
名種牡馬因子は多いが、両方共母父○が無いし、マックスビューティーの方はナスルーラがラインブレードになっててトウルビヨンもあるから血脈活性化配合が4減っちゃう。
うちで種付けしてた配合と比べて良くは無いような・・・
3冠配合なら、メジロラモーヌではなくダイナアクトレスを所有して3冠取らせて(可能?)ノーザンテースト系を確立したほうが良いような・・・

シンボリルドルフ所有とのことだが、種牡馬入りを早めてたりするのかな?
ちなみに自分はAモードだがリンク先はBモードとのこと。
Bモードの場合って所有しなくても引退年は変わるのか?

シンボリルドルフ系は無理っぽい・・・

引き続きウイニングポスト7プレイ中。

育成騎手のライバル騎手がリーディング取れずに引退して悔いが残る言ってたんで、取らせようと思ってやり直した。
特定騎手にリーディングを取らせる時は、2014年モードでは普通に取れる場合があるが、1984年モードの場合は武豊が勝ちまくる。
そこで、要らない重賞馬や、ちょうどいいレースのない所有馬を、海外に出走させて武とか上位騎手に乗らせまくる。
毎週出せば邪魔な騎手を未勝にできる。

後継種牡馬を海外に売ったら即引退されたw

引き続き ウイニングポスト7 2013 をプレイしているが、
シャダイソフィアの配合相手をバンブーアトラスにして結構強い(クラシックはナリタブライアンに持ってかれたが…)種牡馬で来てたのだが、
海外牧場がほしいとか言ってきて売ったらすぐに引退された・・・

あと、バンブーアトラス産駒で因子x2の種牡馬大量にできたが、ことごとくノーザンダンサー系で、
サンデーサイレンス産の牝馬仕入れて配合していたが、ノーザンダンサー、ナスルーラ、セントサイモンのどれかが入ってるのばっかで手詰まり感・・・

ウイニングポスト7 新系統確立

新系統の確立
  • 全子系統の総数が150系統以下。
  • 新系統の血統支配率が世界で2%以上、又は地域で5%以上。
  • 新系統に属する種牡馬が世界で5頭以上。(自身も含めて)
上記の条件を全て満たすと年末に新系統が確立される。
年末に対象馬が複数いる場合はより高齢の1系統だけが確立される。
確立済み系統の血統支配率はコースポで確認できますが、確立前の系統は確認できませんので上位系統の支配率からおおよそしかわからない。

新系統が確立されると対象馬に名種牡馬因子(銀馬マーク)がつきます。
  • 配合する繁殖牝馬に名種牡馬因子がある場合、双方の名種牡馬因子分の爆発力+。
  • 名種牡馬の直仔の繁殖牝馬は母父○となり、対象種牡馬の能力因子数x2の爆発力+。
主に上記2要素で良い産駒が作りやすくなる。
母父○の効果が能力因子数x2なので、新系統の確立は能力因子を2つ持つ種牡馬を狙って行うと良い。


血統支配率
血統支配率は、産駒の数よりも対象系統に属する種牡馬と繁殖牝馬の評価額が大きく影響する。
特に、種牡馬の種付け料が大きく影響する。
なので、単に産駒を多数輩出するだけでなく、産駒に海外ローテも含めてたくさん稼がせると支配率が上がる。

多数の種牡馬と配合すると分散してしまうので、系統確立を狙う種牡馬を絞って集中的に配合すると良い。
84年モードでプレイの場合は、史実馬を入手して海外ローテも含めて活躍させると自家生産よりも効率が良い。


親系統への昇格
子系統が親系統へ昇格すると、元々同じだった系統が別になるので血脈活性化配合がしやすくなるというメリットがある。

  1. 配下に2種類の系統が確立される。
  2. 配下に直列の系統が3つ確立される。
  3. 血統支配率が世界で10%以上、又は地域で12%以上。
上記のいずれかを満たし、昇格する系統が滅亡していない場合に親系統へ昇格する。

どれもかなり長期に渡って配合を繰り返す必要があると思いますが、
2の場合は3代連続としても末端系統から見て新規親系統は3世代前になるので血脈活性化配合がし難い。
1の場合は親が引退前に短期間で行えば3の条件に近い支配率になる。
というわけで、1と3を同時に狙う感じで子系統が2つできた場合は次世代では1つに絞る感じが良さそう。

最低限必要な種牡馬数も、
  1. 13頭
  2. 17頭
  3. 5頭
なので効率的にも2の条件が一番難しい?

ただし、親系統に昇格させなくても元々の親系統を分散させて血脈活性化配合がし難くならないようにすればいいので、
昇格を特に狙わずに元々の親系統を分散させつつ新系統を確立させていくと2の条件で親系統に昇格していくと思う。

ウイニングポスト7の配合攻略

インブリードとニックスだけで良いダビスタと違ってウイニングポスト・シリーズの配合理論は難しい。
ある程度わかったぽいのでまとめとく。
PSP版 ウイニングポスト7 2013 だが、シリーズの他タイトルでも概ね同じだと思う。

かんぱに☆ガールズの消費メモリ

メモリ512MBの Orange Pi Lite を買ってサブPCにしようかなとちょっと検討した。
前はサブPCで かんぱに☆ガールズ (ブラウザゲーム)を常時マクロしてたりしてて、サブ機ない今はメイン機でやってるのだが、
ブラウザゲームとはいえ512MBじゃ厳しいよなと・・・
というわけでtopでメモリ消費確認したらブラウザとプラグイン合わせて2GB以上持ってかれてたw
512MBじゃ全然足りないw

「かんぱに☆ガールズ」のマクロ

先日の記事で書いた、ブラウザゲーム「かんぱに☆ガールズ」のマクロですが、
その後も改良を続けて、ちょっと設定すれば環境変化に対応できる感じになったんで配布しときます。
使いたい方いたらどうぞ。
X11::GUITestでマウス操作を行うのでLinux用(X用)ですが、X11::GUITestをWin32::GuiTestに置き換えればWindowsでも使えるかも。

まだ改良とか続けていくと思います。
自動カンカンとか素材売却ができればいいんだが・・・誤操作が怖いw


配布物

内容: ブラウザゲーム「かんぱに☆ガールズ」で迷宮とクエストを残食料に応じて自動巡回する。
対象: Linux用(X用)
必要コマンド: perl , import(ImageMagick)
必要モジュール: X11::GUITest , Imager

注意事項: 自動でマウス移動とクリックが発生するプログラムです。

ダウンロード



更新履歴
[2016.11.17]
長いことアップしてませんでしたが新しいのアップしました、初期座標の自動調整機能がついてます。
初期状態で早送りになったので早送りは操作しないようになりました。
[2015.10.17]
キャラクターストーリーの自動選択に対応した。
[2015.10.14]
キャプチャファイルの作成場所を変更できるようにした。tmpfs等のramdisk使うべき。
[2015.10.12]
フォント依存と思われ、環境によって判別に成功しない箇所があったので修正。
[2015.10.09]
アップデートで再度クエスト自動選択が実装されたので対応しました。
[2015.10.02]
アップデートに対応して、クエスト選択処理を変更しました。前回と別の章のクエストは受注できなくなりました。
不具合対応で元に戻っているため、不具合対応に対応した臨時版を配信中。
[2015.10.01]
あのコがやる気全開なので、自動カンカン機能を実装した。
[2015.09.30]
早送りが失敗し難くなったはず。(早送りボタンは1クリックで2回反応する場合がある模様。バグ?)
クリック後にカーソルを元の位置に戻すようにした。
[2015.09.29]
不完全一致の判定処理を追加し、社長室と残食料の判定に誤差を許容するようにした。



判定用画像について

画像判定は縦横1pxのTIFF形式画像と、importコマンドで作成した特定位置1pxのTIFF形式スクリーンキャプチャの一致で判定します。
基本的に完全一致で判定しますが、一部の処理で誤差を許容します。
判定待ち処理で1000ループ以内に一致しない場合はアプリ終了となります。

添付画像
ファイル名
座標
用途備考
#00B0B2.tif
クエスト結果の文字色
残食料判定クエスト結果の文字はフォント依存で座標がずれる気配なので、クエスト結果の判定に使うのは辞めました。
#A09698.tif
クエストページ(迷宮選択中)の章選択の矢印(174,172)
クエストページ状態判定
#BBC726.tif
施設ページ左上の社長室に戻るボタン(82,6)
施設ページ判定アニメーションで変色します。
#D0D0D0.tif
早送りボタンの色
早送りImagerのバージョン?によって色情報の取得に誤りが生じる気配なので、置き換える必要があるかも。
早送りボタンが押されていない状態時の座標936,445で色が#D0D0D0の位置です。
#E75145.tif
ルート選択出現中の金箱(693,531)
ルート選択出現判定
#F3E7D5.tif
クエストページ(迷宮非選択中)の章選択の矢印(174,172)クエストページ状態判定
#FDFDFD.tif
選択肢ボタンの文字
未使用
#FFFFFF.tif
装備開発及びクエスト受注ボタンの文字色
装備開発・クエスト受注
キャラスト.tif
キャラクターストーリーページの82,149
未使用
クエスト.tif
クエストページの106,161
未使用
クエスト結果.tifクエスト結果画面の右下矢印(933,579)クエスト結果画面の判定アニメーションで変色します。
施設.tif
施設ページの209,445未使用
社長室.tif
社長室ページの291,305
社長室のクエストボタン判定アニメーションでタイミングにより微妙に変色します。
背景と合成されていると思われるので、社屋Lvが20以外の場合は置き換える必要があるかもしれません。
座標はアプリ左上が0,0です。



設定

macro.plの上の方に設定項目があります。

$LEFTと$TOPは環境に合わせて設定する必要があります。
章の表示位置に合わせて@QUESTを設定する必要があります。
装備開発を行うには所有レシピに合わせて@MAKE_WOOD等を設定する必要があります。

初期座標の自動調整機能つけたので$LEFTと$TOPはコメントアウトしてください。
指定されている場合は指定座標になりますので、自動でうまく行かない場合は設定してください。
デスクトップ全体の上端から590px以内の位置にゲーム画面が存在しない場合は確実に自動調整に失敗します。

変数名
説明
$LEFT
デスクトップ左端を0とした場合のアプリ左端位置。(px)
$TOPデスクトップ上端を0とした場合のアプリ上端位置。(px)
$CAP
キャプチャ画像のファイル名。頻繁に作成されるのでtmpfs等のRAMディスク上にすべきです。
$WAIT_S
短ウエイト(秒)。主に、クリック後のアプリ処理待ち用
$WAIT_L
長ウエイト(秒)。通信待ち用に用意したが、現在未使用
$WAIT_I画像判定等のループ中で使用するウエイト(秒)。
$WAIT_F
早送りクリック後の判定待ちウエイト(秒)。短いと早送り失敗する可能性があります。
$DIFF_ROOM
社長室判定の許容誤差。
社長室のクエストボタンを判定しますが、透過と思われる上にアニメーションで変色するので誤差を許容します。
社長室の判定に失敗する場合は値を大きくすれば解決するかもしれません。
$DIFF_BAR
食料・資材の残量判定の許容誤差。
バーは透過色で、背景及び秘書と合成されているため誤差を許容します。
残料の判定が正常にできない場合は値を大きくすれば解決するかもしれません。
$DIFF_ROUTE
ルート選択ボタンの判定用誤差。
大きすぎる場合も判定に失敗します。
$DIFF_RESULT
クエスト結果画面の判定の許容誤差。
$DIFF_FACILITY
施設ページの判定。
$MAKE
0=装備開発なし
1=装備開発あり
2=装備開発テスト(レシピ選択をして終了)
$MAKE_MIN
装備開発を行う最低資材量
単位は資材バーの判定範囲に対するpxで、110が最大値です。
@MAKE_WOOD
木材が多い場合に開発される装備。
@MAKE_WOOD,@MAKE_STONE,@MAKE_IRON,@MAKE_TEST
のパラメータは全て同じで、
@MAKE_WOOD=(メッセージ,装備種別,職番号,レシピ番号);
装備種別: 武器=0,防具=1,アクセ=2
職番号: 左から(ファイター=0,マジシャン=7)
レシピ番号: アイテム一覧のうち、1段目が0で5段目が4、2ページ目の1段目は5

同一でもいいので、@MAKE_WOOD,@MAKE_STONE,@MAKE_IRONの全てが設定されていないと開発しません。
クエスト巡回により新レシピを入手するとレシピ番号が変わる可能性があるので注意してください。
@MAKE_STONE
石材が多い場合に開発される装備。
@MAKE_IRON
鉄が多い場合に開発される装備。
@MAKE_TEST
装備開発テストに選択されるレシピ
@QUEST
食料がある場合はこの設定に応じたクエストが受注されます。(食料がない場合は迷宮行き)

@QUEST=(クエストID,章順位,章内順位)
@QUEST=(クエストID,職順位,職内順位)
クエストIDは1文字目が、M=メインクエスト、C=キャラクターストーリー、L=夢幻の迷宮

メインクエストの場合
章順位は、部内の章が最大5個表示されますが、1段目が0で5段目が4
章内順位は、章別のクエストが最大8個表示されますが、1段目が0で8段目が7

キャラクターストーリーの場合
職順位は、ファイターが0でマジシャンが7です。(表示順)
職内順位は、職別表示にして1段目が08段目が7。2ページ目の1段目は8。
$LABY
迷宮のルート。
変更する場合は対応処理ルーチンを作成する必要があります。
クエストIDとなるので、1文字目がLの必要があります。



処理の流れ

  1. 社長室待ち。
  2. 資材があれば開発して社長室に戻る。
  3. 食料があればクエスト、無ければ迷宮を受注。
  4. 早送りを試みる。(5クリック以内に成功しなければ諦める)
  5. クエスト別選択ルーチンがあれば、それやる。
  6. クエスト結果待ち
  7. 社長室までクリック。(100クリック以内に社長室に到達しなければアプリ終了)

終了する場合は強制終了してください。

売却・解雇は行いません。
ゴールドが尽きたら迷宮に行けず終了します。
社員数が上限に達したらクエストを受注できずに終了します。
所持限界や素材不足等で装備開発ができない場合は社長室に戻ってクエストになります。
クエスト(迷宮)を挟まず連続で開発が行われることはありません。

早送りは初期状態で選択するようになったのでマクロでは操作しなくなりました。
2015.10.02のアップデートで章選択が省略となったため、前回と別の章のクエストは受注出来ません。
メインクエストを巡回する場合、実行前に手動で目的の章のクエスト(おなじしょうなら別のでもいい)を受注してください。
2015.10.09のアップデートでキャラクターストーリーが自動選択となったため、メインクエストを受注した後の状態でキャラクターストーリーの受注はできません。
キャラクターストーリーを巡回する場合、実行前に手動でキャラクターストーリー(別キャラでもいい)を受注してください。



実行方法

./macro.pl

./macro.pl l

./macro.pl h

./macro.pl q


オプション無しで実行すると食料半分程度でクエストと迷宮が分岐します。
lオプションだと食料少なめ。hオプションだと食料多め。
qオプションつきだと装備開発を行いません。
オプションは半角スペース区切りで複数指定できます。

macro.plの位置に移動してから実行してください。
別の位置で実行したいならシェルスクリプトとか用意してください。



内部関数
関数名
書式説明
TimerClick
&TimerClick(待ち時間,横座標,縦座標,メッセージ)待ち時間が1以上なら待つ。(カウントダウン表示)
メッセージがあれば表示する。
座標をクリック。
ImageClick
&ImageClick(判定画像,横座標,縦座標,メッセージ,横座標修正,縦座標修正)引数をImageWaitに投げて戻り待ち。
座標修正がなければ判定位置、あれば判定位置に加算された位置がクリックされる。
ImageWait
&ImageWait(判定画像,横座標,縦座標,メッセージ)メッセージがあれば表示する。
座標位置の1pxキャプチャを取得して判定画像と一致するまでループ。(1000ループでアプリ終了)
アニメーションによる瞬間的誤判定防止のために再判定して一致すれば戻る。
ImageCheck&ImageCheck(判定画像,横座標,縦座標)座標位置の1pxキャプチャを取得して判定画像と一致すれば真、不一致で偽が戻る。
BarCheck
&BarCheck(判定画像,横座標,縦座標,長さ,許容誤差)
座標位置から右方向に長さ分のキャプチャを取得し、判定画像と一致する位置までの長さを返します。
許容誤差を省略した場合は100となります。
DiffWait
&DiffWait(判定画像,横座標,縦座標,メッセージ,許容誤差)

ImageWaitと同じように一致するまでループしますが、誤差を許容します。
許容誤差を省略した場合は100となります。
DiffCheck&DiffCheck(判定画像,横座標,縦座標)座標位置の1pxキャプチャを取得して判定画像との誤差を返します。
誤差は、RGB各値(0-255)を減算した絶対値を加算した値となります。
完全な白と黒を比較した場合、誤差は765となります。
RouteSelect
&RouteSelect(メッセージ,クリック位置)
クエスト別選択ルーチンの作成に使う。
クリック位置は選択肢ボタンの縦方向中央を基点にした値で、
選択肢が2つの場合は、上ボタンが-25,下ボタンが+25
選択肢が3つの場合は、上ボタンが-50,下ボタンが+50,中ボタンが0
程度が適当


クエスト別選択ルーチン

選択肢のあるクエストでは作成する必要があります。
基本的に、RouteSelect関数を並べるだけで作れます。





ブラウザゲームのマクロ作ってみた

最近ブラウザゲームの「かんぱに☆ガールズ」ってのやり始めたんだが、カード収集ゲームにしては珍しくゲームっぽくて面白い。

のだが、素材収集とかレベル上げとか作業感が強い。
そこで、ゲームのマクロ作成に初挑戦してみた。
言語は慣れたPerlで。


この手のゲーム操作自動化は、スクリーンキャプチャ取って画像解析してクリック。
って感じだとは思ったが、
  1. ImageMagickのimportコマンドで画面キャプチャ。
  2. Imagerモジュールで画像比較。
  3. X11::GUITestモジュールでマウス移動とクリック。
って感じの処理になった。

スクリーンキャプチャの画像をメモリで扱えればいいんだが、Perlで簡単にやる方法が見つからなかったんでImageMagick経由でTIFF画像作成。
TIFF形式は初めて使ったが、Linuxで使う.bmpみたいなもん?
`import -window root -crop 1x1+横座標+縦座標 capture.tif`;
って感じに。
最初は全画面から判別用の領域画像をサーチして座標を求めようとしたが、
ゲーム画面に透過箇所が多く、ほぼ全体が常時微妙にアニメーションしてるようで領域比較は難しかったのでピンポイントの1x1px画像を比較して判別するようにした。
importコマンドは-cropオプションで特定位置の画像を取れるが、helpや公式サイト見てもわかりにくい。
-cropオプションに続いて「サイズ」又は「サイズ+位置」を指定で、位置指定する場合の書式は「横幅x縦幅+横位置+縦位置」となる。
領域画像の判別が困難だったから、一度画面解析せずにタイマーのみで自動化する処理を作ったんだが、タイマーだけだとやっぱ誤差が出てダメな感じ。

Imagerモジュールで画像比較は、
my $img=Imager->new(file=>"判別用画像");
my $cap=Imager->new(file=>"キャプチャ画像");
って感じで2ファイル読み込んで、
if($img->getpixel(x=>0,y=>0)->equals(other=>$cap->getpixel(x=>0,y=>0))){
   一致
}
って感じ。
画像が両方共1pxなんで座標は0x0。

X11::GUITestモX11::GUITestモジュールは、
X11::GUITest::MoveMouseAbs(横座標,縦座標);
X11::GUITest::ClickMouseButton(X11::GUITest::M_LEFT);
って感じでマウス移動と左クリックができる。
キーボード操作なんかもできる。
最初、入力デバイスの自動操作ってどうやるんだ?
ってわけでググったが、Win32の情報がでてきてLinux用のこれ見つけるのに苦労した。



そんなわけで、「かんぱに☆ガールズ」の夢幻の迷宮とメインクエのループ作業自動化ができた。
食料確認して迷宮とメインクエを自動で分けるように作ったが、
できれば社員解雇や素材売却、自動カンカンなんかもできるようにできるといいが、難しいかな。
まあ、メインクエ1回行くのに迷宮2回として計10分以上かかるから、社員枠が10あれば3時間位動けるかな?

初めてゲーム用マクロ作ったが、今回の応用で他ゲームのも作れそう。

「神界のヴァルキリー」ってゲーム始めた

Androidで手軽に遊べて面白いゲーム無いかよく探してるが、無いんだよねえ。

以前はポチポチだけの萌えカードもやり込んだが、イベントガッツリやるだけのゲームだと張り付きになっちゃうから今はやりたくない。
今はイベントゲームやる気ないから、萌えカード収集だけのゲームではなく、ゲーム性のあるものがやりたい。

オンラインじゃなくてダウンロードタイプのゲームの方が良いんだが、
日本のダウンロードゲームはゲーム機風のRPGとかアクション性高いのとか、操作めんどそうなのばっか。
上位には海外メーカーと思われるシミュレーションゲームが多数出てくるが、洋ゲー的なのは絵的にダメ。
Androidとかタッチパネル端末ではコマンド選択とかで頻繁にタッチしたくないから、コマンド選択が頻繁に必要なRPGは向かないと思う。
アクションゲームは論外。

オンラインなら、一昔前にPCブラウザゲームで多かった「村ゲー」とか向いてると思うんだが、
Androidゲームはポチポチゲーばっか。


ってなわけで、探すだけで実際にプレイするAndroidゲームが無い状況が1年近く続いていたが、
最新ゲームでは無さそうなんだが、「神界のヴァルキリー」ってゲームやってみたら結構いい感じだった。
金使うつもりは無かったんだが、さっそく100円投入してしまったw

よくあるポチポチ萌えカードゲームなんだが、
ポチポチゲームと村ゲーが融合されたようなゲーム。
ポチポチゲームだとカード収集しかすることないから、イベント報酬のカード目当てでイベントをガッツリやってしまうが、
このゲームは村ゲーでもあるから、まったり村開発で遊べそう。
イベントはゲーム始めてから2回目なんだが、1回目のイベント終了後にすぐ次のイベ始まったから、常時イベぽい・・・

通常のポチポチゲーはカードを合成して強化して行動力のある限り歩くだけだが、
このゲームはカードの強化以外に兵力の要素があり、開発した村から得られる資源を消費して、カードに兵を配備して進行する。
行動力の要素もあるんだが、兵を消費して資源が無くて補充できないと身動きが取れなくなる。
単に強さだけで編成せずに、兵の消費が少なく済むように考えたほうが良さそう。


あと、KOEI(旧ガスト)が「アトリエ クエストボード」ってアトリエシリーズのAndroidゲーム始めるみたいで事前登録募集してるんで登録した。
KOEIの事だから大航海時代Vと同じように失敗すると思うが、ガストのアトリエシリーズはタッチパネルに向いたシリーズだと思う。
多分中身ガチャカードゲームだと思うんだが、カード課金じゃなくて調合課金だったら面白くなるんじゃないかと。