(Google Admob) Ad Placements API for Unity 広告プレースメントの不具合
10-05,2022
ネットを調べると、
『AdMob広告を、Ad Placements API 広告プレースメントで簡単実装!』
みたいな記事がかなり出てきますが、
不具合らしきものを発見したので、ここに残しておきます。
最初に直面した謎現象
状況としては、
Ad Placements API 広告プレースメントを用いて、
バナー、インタースティシャル、リワードの3種類を実装してリリースしました。
ところが、１０個くらいのアプリに同様の実装をしましたが、
内２つくらいのアプリで、謎現象が発生しました。
『実機やユーザーデバイス上で、広告は表示されるのに、
そのレポートがAdmob側で反映されない』というもの。
具体的には、例えば、
バナー広告 表示回数 1021
リワード広告 表示回数 32
とか表示されているのに、
インタースティシャル広告は、存在自体がレポートされていない
・・・みたいな。
この場合、どんなにユーザーがその広告を見たとしても、
その収益は、恐らく０円になっています。
この謎現象が、自分でどんなに模索しても判明せず、
Google AdmobフォーラムやUnityフォーラムで質問したりもしましたが、回答はなく、
もちろん、検索しても、この現象のことに触れている記事はありませんでした。
謎現象の正体(予想)
これは、Unityのインスペクター上で、
AdMob Ad Placements の広告ユニットIDを変更した際、
変更しているにもかかわらず、内部的には変更されていない
・・・という不具合が、原因と思われます。
内部的には変更されていなかった、と私が判断できたのは、
自分で広告ユニットIDが間違ってないかを確認した際に、何故か、
インタースティシャル広告を実装させたオブジェクトが存在するシーンファイルが、
変更もしていないのに、
クラウド上のファイルと比較して、"更新されている状態"になっていたから。
実際には、PlasticSCMの更新リストに、触ってもいないMain.sceneファイルが追加されていたのを見て、私は不信に思い、diffしてみると・・・、
まさに、その時点で、なぜか今頃になって、インタースティシャル広告のユニットIDが、古いものから新しいものへ変更されていたのでした。
当然、それまで古いIDだったわけではもちろんなく、インスペクター上は、新しいIDでしたが、
何故かそのタイミングまで、内部的には更新されていなかった、
・・・ということが、その現象から推察できました。
しかし、そもそも、Admobの広告ユニットIDは、
多分、シーンファイルに紐づくものではなく、
プロジェクトファイルに紐づくもののはずでは…と予想します。
にもかかわらず、更新されていたのはシーンファイルの方。
これはもしかしたら、Google AD Setting上の広告ユニットIDは、
プロジェクトファイルに保存され、ちゃんと正しいIDに変更されてはいるが、
その広告ユニットを実際に適用するオブジェクトに、
何かのタイミングで、広告ユニットIDが自動的に受け渡され、
オブジェクトの方にも、そのIDが個別に保存されているのでは!?
だから、プロジェクトファイルの方、つまりGoogle AD Setting上で広告ユニットIDを変更しただけでは、オブジェクトに紐づくIDの方は更新されておらず、
おそらく、そのオブジェクトを選択するとか、開く…みたいなアクションをした時に、
自動的にそっちが更新されるような仕組みかもしれません。あるいは定期的なクロールとか。
そうであるなら、オブジェクトの方を一切いじらずに、リリースすると、
Google AD Setting上での広告ユニットIDは正しくても、
アプリ実行時、オブジェクトの方に、そのIDが受け渡されておらず、
正しいIDが送信されていない・・・、ということになってしまうのかもしれません。
オブジェクトの方にIDを受け渡す自動クロールのようなものがあるのかもしれないですが、UnityEditorや開発者の挙動によっては、それがうまくいかないケースがあったりして、プログラムがそれを保証できていない可能性があります。
これは Google Admob AD Placements が、各ユニットIDを、インスペクター上で設定できるというメリットを提供したはいいものの、その構造の不完全さのようなものだと予想します。
ここではインスペクターと便宜上言ってはいますが、実際には、エディター拡張によって入力させており、それをオブジェクト側が毎動作内で取得していくのではなく、エディター上でオブジェクトの方を更新させる、という挙動のような所に問題がありそうです。
例えば、開発状況によっては、
オブジェクトの方を先に作り、ソースも作り、全部終わったあとで、
Google AD Setting上で広告ユニットIDを設定する
・・・みたいなケースは、結構な確率で予想されます。
広告ユニットIDが判明するのは、AdMob側でアプリを登録した時であり、
アプリが完成したあとで登録して広告IDを発行させたりするならば、こういう順番は頻発します。
そしてその状況で、シーン内のオブジェクトに正しいIDが受け渡せていない場合があると、
ビルドしても、間違ったIDを、内部では使用されてしまい、
AdMob側がそれを正しく受信できないことで、上記の現象が発生するのでは、と予想します。
現実的な対策
対策１
１つは、Google AD Setting上で広告ユニットIDを設定した後は、
かならず、シーン内で広告を実装しているオブジェクトを選択したり、開いたりして、
IDが受け渡されるようにする機会を意識した方が良いでしょう。
ただ、実際どんなタイミングで受け渡されているのか不明のため、それをやっても不安ではありますが。
ちゃんと受け渡されたかどうかを確認する方法としては、
シーンファイルの中身を開き、広告ユニットIDの項目を検索してみると、出てくるので、
そのIDが正しいかどうかを確認することで、整合性を確認することができます。
対策2
もう１つの対策としては、
正規のSDKを使うです。
広告プレースメントAPIは、そもそもベータ段階のSDKであり、
ベータと明示しているので、信用が薄いことをGoogle側が提示しています。
見たところ、本家のSDKがどんどんVerupされていっているのに、
こちらはまったく更新されていないようなので、そういう面からも、使わない方が吉かと思います。
今回の報告は、私の実体験からの予想であり、
SDK内部のソースを全部見て言っている確証のあるものではないので、
あくまで報告例の１つとして、このことで困っている人の助けになればなと思い、世界に残しておきます。
タルタロスとエレボスのコード
09-27,2022
怪盗プリンスで、
死神はジスロフ達を選んだんだ!
がりゅうではなく。
そのことを踏まえたうえで、ずっとあとの臥竜の結末を思うと、
臥竜視点は一層奥が深くなるんだ。
がりゅうは、ふりまわされつづけたことには変わりないけど、
そこがよいかもしれない。
臥竜にとっては、死神は自分を選んでくれなかった。
死神が死んだ時、その悲しみからか、怒りからか、
死神の肉を食べた臥竜。
それによって、巻き込まれることのないはずの冥界の権力争いの当事者となり、
タルタロスドリームでは、
ヴィナスと死神一派の両者から、人道的とも政治的ともどちらともとれるようなひっぱりだこになってしまう。
そして、
ヴィナスによって、一度は悲恋の悲しみをすべて忘れることができたかもしれないのに、
臥竜を大切に思うがゆえに、それを止めようとする無の世界のエレボスとプリンス達。
結局は、冥界王として覚醒しつつも、
彼らの働きで、記憶を失わずにはすんだが、
死神との思い出も失わず、
だからこそ、その後も苦しみを抱えたまま、
さ迷いつづけるしかなかった臥竜。
ジスナナ新聞は、普通レベルで読むと、意味不明だけど
そのことをふまえて読むと、
がりゅうの結末は奥が深くになることに気づいた。
「死神は、がりゅぅよりジスロフを選んだ」という事実を
明確に意識しつつ読むと、
臥竜は、
心をずっと痛めながら、
ジスロフ達のことは憎んでいたはずなのに、
さまよいの果てに、
ジスロフ達のために自殺する。
振り向いてくれなかった好きな人と
同じ死に方を選んだということになる。
さいごまで臥竜視点は切なく深いんだyo。
app-ads.txt
09-14,2022
app-ads.txtの話
スマホアプリにおけるAdmob利用時、
各アプリに、app-ads.txtとの紐づけが推奨されていますが、
そんなもんはとっくの昔にやったから大丈夫・・・と思っていたら、
最近リリースしたアプリ２、３個が、紐づけできていなかったので焦りました。
・・・しかし、別に紐づけしなくても、
普通に稼働していたので、あんまり重要ではないのかもしれませんが、
それはさておき、
紐づけには、
ストアページのメタデータにおいて、
Androidは、テベロッパーサイトのURL入力が必須となり、
iOSの場合は、マーケティングサイトのURL入力が必須です。
申請フォームだけ見ると、別に必須ではない、みたいな雰囲気をかもしだしているので、
これは罠です。
で、今日はそこからもう一歩踏み込んだ話ですが、
app-ads.txtがちゃんとできてるかどうは、Admobのサイトから確認できますが、
わっかが緑色になってりゃいいんだろーくらいに思っていましたが、
アプリ一個一個を開いて詳細を見ると、
下のような警告文が。
- app-ads.txt ファイルの形式に問題があるため、広告主がファイルを正しく読み込めない場合があります。
- クローラーが判別できない非印刷文字が含まれています
なんじゃそらあああああああああ
「app-ads.txtを確認できました」みたいな文言が出てるから安心していたのに・・・。
ここにも罠がありました。
Admobは罠だらけです。
で、この警告文で検索をかけても、まったくと言っていいほどヒットしません。
は? 誰もこの問題にぶちあたっていないの?!
どういうことなの!?
で、app-ads.txtをアップロードしているプロバイダに問題があるのかと思い、
文字コードを強制的に変更させようとしたり、
別のドメインにアップロードしてみたり、
何度もUTF-8で保存しなおしたり、
色んな事を試しましたが、警告文は消えず・・・。
格闘すること数時間、
諦めてお風呂に入り、出てきてから、ふと、
「UTF-8(BOM付)で保存すること」みたいなことを書いてた記事のことを思い出し、
まさかそのサイトも罠・・・、と思い、
あえて「UTF-8(BOMなし)」で保存したら、
うまくいったー－－－－－－－－－－－－－－－－－－－－－－。
なんでそれを試してみなかったのか・・・。
UTF-8なら、どっちでもええじゃろ、みたいにも思い込んでいたのかも。
というわけで、UTF-8 (BOMなし) で、app-ads.txtを保存するのが正解でした。
これで警告文も消えました。
実は今日は、
「ユーザーの実機に広告は表示されているのに、Admobのレポートには反映されない」
という問題を抱えて、
半日過ごしていました。
その過程で、app-ads.txtに問題があるからでは・・・と思い見てみると、
上記のような警告を発見したのですが、
たぶん、それらと、Admobのレポートに反映されない問題は、無関係かと思われます。
Admobのレポートに反映されない謎問題は、
どこを検索しても出てこない・・・というか、広告自体が表示されない、という問題の記事が多すぎて、この問題だけを検索で探し出せない、という感じで、解決できずに困っています。
今までのリリースや状況と色々対照比較しても、
これぞ、というのが明確に見えてこないので、
どうせAdmob側の謎問題で、日数が経過すればケロッと反映させてくるのでは・・・
という推測が50%くらいあります。
残り50%は、何かの罠に私がひっかかっている説です。
あやしいのは、このアプリは、Admobがいつのまにかしれっとその存在をなかったことにしようとしている、Ad placementsというSDKを使用しているので、そのサポート的なものをしれっと変更させて、新規にリリースしたアプリに対してのみ、反映させなくなってしまっている可能性が残っています。
いずれにせよ、この問題は未解決のままですが、また進展があったら追記します。
というわけで、最近は以下の２つのゲームをリリースしました
スマホ脱出ゲーム第 2 弾『猫のにゃん太 vs たまみ』
スマホ脱出ゲーム第 1 弾『猫のにゃん太 vs ミケ』
[UNITY] Cinemachine 被写体のカクつき、別カメラへの遷移時の回転
08-14,2022
UNITYの、Cinemachine機能における２つの問題を抱えていました。
・１つは、被写体のカクつき。
主にプレーヤーオブジェクトで、ジャンプしたり、カメラ傍で移動したりすると、
プレーヤーだけがカクカクして映る現象。
特徴としては、通常のカメラでは発生しないという点です。
原因
ネットで調べると、
Chinemachineがupdate内で更新を行っているのに対し、
プレーヤーがFixedUpdate内で更新されているのが原因らしいというのが出てきました。
私の場合は、プレーヤーオブジェクトに対し、
Fixeddpdate内で、RigidbodyのVelocityに値を与えている構造でした。
解決策
ネットでは、以下の3つが解決策として出てきます。
・同じUpdate内ですべてをすます
・FixedUpdateの間隔を小さくする
・Rigidbody内のInterpolate設定をInterpolateにする
ところが、私の場合は、
プレーヤーオブジェクトのRigidBody内のInterpolate設定を、
既に[Interpolate]にしていました。
そこで、これを試しに[None]にすると、
なんと、解決してしまいました。
Interpolate設定って、確か、物理演算のすり抜けを防止するために、
演算の割り込み間隔をあげるものだったような・・・。
私の場合はそれが逆に、Cinemachineとの更新タイミングのズレを
生んでいたのかも。
しかし、Interpolateが必要な、たとえばレースゲームとかの場合、
困ることになりそうですが・・・ひとまず今回はこれで解決しました。
・Cinemachineの別カメラへの遷移時の問題
Aカメラ→Bカメラへ遷移する際、
Cinemachineは、この２つのブレンドを自動的に補完します。
しかし、その補完の開始地点は、
前回の遷移直前のカメラの位置へと戻るというもの。
A→ 被写体 ←B
というカメラ構造が常に固定されたようなケースでは、問題ありませんが、
A・B→ 被写体
というカメラ構造で、AとBが、移動・回転するようなケースだと
A→Bの遷移時、無駄な回転や移動が行われ、思ったような挙動になりません。
これは、片方のカメラがオフになった時、
その位置にずっと留まり続け、
再びオンになった時、その位置から補完が開始されることによって起こる弊害です。
希望としては、
再びオンになった時、もう一方のカメラと同じ位置や角度から
スタートして欲しいというケースです。
どんな時に、このケースが発生するかというと、
たぶん、Target Group cameraと、Free Look Camera の切り替えを行う際に、
この問題が最も多く発生すると思われます。
私の場合もこれでした。
・解決方法
最初はスクリプトで、
切り替え後に、オフになっていたカメラの位置を、オンになっていたカメラと
同じ位置と角度になるようにしようとしましたが、
Cinemachineのスクリプト制御は独特のようでしたので諦め、
色々と調べていると、
「遷移時、OFＦからONになった際、一方のカメラの位置へ、強制的に移動する」
というプロパティが存在することを発見しました。
Transitions項目の Inherit Position というプロパティです。
これにチェックを入れると、そうなります。
Unity公式には、
「この Virtual Camera がライブになった時に、位置を強制的に現在の Unity カメラの位置と同じにし、Virtual Camera がその遅延 (Damping) を適用できるようにすることで、ブレンドの実行を可能にします。」
と書かれていました。
これでほぼ解決しました。
ただし、これは、位置だけのようで、
角度は補完されてしまうかもしれません。
猫ちゃん運びます、よみがえれ!
07-31,2022
ここ最近は、
「猫ちゃん運びます」というスマホゲームを蘇生していました。
Apple store connectへアップロードできない戦い、
明示されていないセーフエリアとの戦い、
それから、
「SHOPボタンが押せません。これはバグなので却下します」というレビュアーに対し、
「それはグレーアウトしています。他のボタンと比較すると、色が明らかに異なり、グレーアウトしていることが分かると思います。グレーアウトは一般的に、押せないという機能を表していると思います。なぜグレーアウトにさせているかというと、最初は所持コインが0なので、SHOPヘいっても何も買えないからです」という幼稚園児に説明するように返事をすると申請が通るという低レベルの戦い、
などなどの・・・数々の戦いを経て、
ようやくVer 5.8に更新されました。
まだ、Ranking画面が無意味に狭い・・・という問題などもありますが、
ステージも、15、16が追加され、
アイテムなども追加され、
以前より少しだけ拡張されています。
とんでもない挙動を引き起こしていた自動移動床も撤廃されています。
ボタンの反応がおかしかったバグも修正されています。
もしよかったら、遊んでみてくださいませ!
スマホゲーム『猫ちゃん運びます』
