2025.02.17
Youtube「ARブロック崩し」のPMが伝えたかった本当のコンセプト
#電子工作 #OpenCV #Python #raspberry pi #Youtube
トップ ＞ 技術ナレッジのアーカイブ > Youtube「ARブロック崩し 」のPMが伝えたかった本当のコンセプト
2025.02.17
#電子工作 #OpenCV #Python #raspberry pi #Youtube
テクノプロ・デザイン社のYoutubeチャンネルに「ロボット×ゲームでARブロック崩し作ってみた」が公開されました。今回は、動画の作成動機、制作のコンセプトなどを当時PMだった中山さんに聞きました。
2015年にテクノプロ・デザイン社に新卒で入社。
東京開発センター(現在のハードウェア開発センター 東京事業所)に2年間配属後、多岐に渡る派遣先に配属し、現在も技術派遣社員として業務を行う。
YouTubeの企画は今回が初の試みとなった。趣味は映画鑑賞、特にSF、MARVELシリーズ等。
直感的でイメージのしやすいゲームに、技術領域を関連付けることが出来たら、技術に興味がなかった人も関心を持ってもらえるようになるんじゃないかという想いがありました。
実は今回の企画に至るまで、ツールの許諾や使用料金、又、目新しさを求めた、などの理由で何度か企画をボツにしました。いずれも、一般的にイメージがしやすくなるものと、技術領域を組み合わせたものでした。
動画内の解説パートでも、なるべく専門用語のみを並べることなく、実機や図、コードを出して解説しました。
一方、今回の動画ではphytonや通信、電子工作など様々な技術をいくつか散りばめています。それらについて知っている方が「(作成について)もっと良い方法を知っているのに！」「こういう風に作ってみては？」と議論が巻き起こることも期待していました。
本企画は当初、小中学生の夏休みの宿題をターゲットにしていました。
言葉を聞いただけですぐに思い浮かぶ「ブロック崩し」、身近ではないけれど言葉として浸透している「AR」それらを組み合わせて、本業エンジニアとして仕事をしている大人たちがゲームを作ったらどんなことが出来るのだろう、という想いから始まりました。
「ARブロック崩しを作る」だけであれば、既製品のMRゴーグルと開発元が推奨しているスクリプトを組み合わせれば、それだけで実現は可能だと思います。
ただ誰しもが思いつく方法でやるだけじゃ面白くないよね。というのと、３D化など将来の『拡張性』を考え、また、最終的にはゲーム性や見栄え以上にどのような技術を詰め込んで解説するか、に重きを置きました。
また、各異分野のメンバーを集めてチームとして結果を出そうと思いました。そうすることで、工程を各技術を細かく分類し、各領域の解説パートはより詳しい内容になりました。
今回は二次元コードひとつでゲーム画面全体を表示させるということをやりましたが、 例えば、二次元コードに限らずマーカーをいろんなところにおいて、それぞれがブロックになっている(ペットボトル置いたらそこにブロックがある)、とか、 3D化した際は視点の変更に追従して3Dブロックの見え方が変わる、とか、 構想だけは盛沢山ありました。
時間が限らているので基本の動きだけなんとか作りましたが、
動画の中でも言っている通り、本来ここがスタートで、もっと改善していけたら面白いなあと思っています。
ですので、できなかったことを挑戦してくれる人がいたらうれしいですね。
最後バタバタしてしまった加速度センサーと通信については、移動体があって、2次元コードでゲーム画面が表示されているだけだったら、
技術的な面白みが少なくなってしまうということで、
厳しいかもしれないというのが分かっていながら残したという形でした。
実装していたゲーム画面用の二次元コードとは別に、
移動体用の二次元コードを使えば、加速度センサーやBluetooth通信というものを使わずに
もっとスムーズに動くものができていたと思います。
ちなみに、全くどうしようもならないという状況に陥ったら、
上記の移動体にも二次元コードを載せるやり方で完成させる案もありました。
ですので、動画をまた見ていただけたらわかると思いますが、
移動体にはQRコード取り付け用のマジックテープがついていたりします。
結局、なんとか動く状態は作れたのでそのまま突っ走りました。
動画内ではARマーカーはブロック崩しの描画位置決めに使われていました。これはつまり、画面の中に2Dのゲーム画面が存在していて、画面の中の画面を操作することになり、操作性悪化を招いているのではないかと思われますが、ブロック崩しの画面だけにしなかった理由はなんですか？
中山 ー 今回は単純にどこにゲーム画面を表示するかのために使いました。
当初の構想では3D化も視野にいれていたので、二次元コードをどのような角度から読んでいるかによって、
ゲームも長方形ではなく奥行がある台形になっていたり、そのようなことができればと考えていました。
また今回の企画に「画像認識」という技術ワードを用いたものを作成したい想いがあり、どのようにすれば連携出来るか？と考えていました。
動画内ではARマーカーを検出した位置にブロック崩しのゲーム画面を描画しています。 ARマーカーは基本的に画像を描画するものですが、ARマーカーの位置にどうやってゲーム画面を描画しているのでしょうか？ 大まかに「ゲームプログラム→ゲーム描画→ゲームスクショ→OpenCV画面でマーカー位置にゲームスクショを描画」というゲーム画面を毎回スクショしてARマーカーの位置に描画しているのではないかと思われます。この辺りで無駄に処理増やして負荷がかかりラグが起きた一因になったのではないでしょうか？
中山 ー 今回のブロック崩しの作成は画像ではなく、プログラム上で図形を描画しています。表示方法は、マーカーの座標を取得し、その座標を元に描画にしています。ブロック崩しの描画は、1ループの中で1回となっております。
また、3Dに拡張することを考えていたので、合成プログラムを採用していました。
ゲーム自体は時間周期を固定して動かしていて、間に合っていない挙動はなかったので、
そのあたりの処理のせいということはありませんでした。
動画内の課題として挙がった加速度センサが原因によるラグの発生についてです。
加速度とは単位時間当たりの速度のことをいい、その加速度を測定するICが加速度センサです。よって取得できる値は速度ということになります。
移動体が動いたときバーを動かす場合に反映すべきデータは何か？と考えたとき移動体が移動した量、つまり、距離と考えます。
動画内ではおそらく距離ではなく速度を渡しているのではないでしょうか。
加速度センサから距離を計算する方法はあるみたいですが、かなり複雑な計算が必要そうですがそのあたりの実装の状況はどうだったのでしょうか？
中山 ー 確かにゲーム性や完成度だけを考えたら全く妥当じゃないです。
加速度の計算については、結論から言うと、正しい計算式を確認した上で簡素化しています。
距離を出すには、微分積分の考えが必要なのですが、
★移動距離とX座標は同じ距離でも単位が異なるため、変換のための定数が必要
★時間周期が一定なので、例えばで簡単に書きますが(1/2)*(加速度)*(時間の2乗)も定数×加速度に置き換えられる
★最終的に加速度を速度に変換する部分、速度を距離に変換する部分ともに、それぞれ加速度や速度に定数をかける形になる
というところから、簡易的な変換にしました。
とどのつまり、加速度の積み合わせが速度であり、速度の積み合わせが距離、という考えです。このあたりは動画でも触れています。
他にも赤外線を用いて距離を算出する方法も考案されましたが、移動体に赤外線を用いる仕組みはマイクロマウスで既によく行われているため、それだと面白みがないよね、折角なら他のセンサーを用いたい、という話し合いもありまして、チャレンジングな試みとなりましたが、今回は加速度センサを使用しました。
時間に制約があったことです。
皆、派遣先が異なるので一堂に会して作業することができません。よって残業時間に各々の担当パートの作成を行い、進捗はオンラインで確認し合ってました。
そのような状況でありながら、各エンジニアが課題に対処していたのは素晴らしい事だと思います。例えば用意したraspberrypiのパワーが足りなければ昇圧回路を既に作成していて解決済みであったり、早い段階で実際にブロック崩しが出現するところを見させていただき、打ち合わせのたびに進捗がありワクワクしました。
驚いたことに、今回、大部分のソースコードにpythonを使用していますが、3人とも今まで使用経験が無かったことです。 使ったことの無いものに対するチャレンジの精神と、実際にやれてしまう対応力にとても驚きました。 苦労はあったものの、業務と同じくチームで行うことにこだわった結果、困難を乗り越えられたと思います。
動画では木下さんがベテランエンジニアに質問するというQ＆A形式でしたが、そのQAはリハーサル時にアドリブを交えることによって実際の疑問から出たもの採用しています。質問する木下さんもエンジニアであるからこそ的確な質問を見つけ自然なやり取りが出来ました。
結果、技術についてわかりやすい解説になったのではないかと思います。
LineではQRコードから登録していただくか「友だち追加」ボタンから登録できます。メールで登録ご希望の方はこちらから
※登録頂いた個人情報は次の目的で利用します。 ①テクノヒントからの情報発信②テクノヒント運用に関するアンケート依頼の案内など
