Androidのゲームアプリを開発する際の設計思想について

Question

## テーマ、知りたいこと Androidのゲームアプリを開発する際に、不具合、かくつき、スマホの発熱が少なく、かつメンテナンス性の高いコーディングができるような設計方法を知りたい。 ## 背景、状況 13年間自営でシステム開発等をしております。主に個人事業主向けの業務システムをJava言語で開発しておりましたが、これからはスマホアプリ開発を主軸にと考えています。今回初のスマホアプリ開発（ゲーム）を始めようとしているところですが、デスクトップアプリやWEBアプリ開発と勝手が大きく違い色々と飲み込み切れていない状況です。難しく考え過ぎているのかもしれないですが頭の中を整理するためにも、まずは僕の理解や考えを書きますのでご意見ご指摘をいただけたら嬉しいです。 Javaで開発する予定で最初はハクスラRPGのような描画頻度の少ないゲームを作り、後々は2Dアクションゲームにもチャレンジしたい。 ## Androidアプリ開発についての自己理解 Android Studioを触って理解したことを箇条書きにしてみます。 - AndroidManifest.xmlのactivityタグ内にintent-filterタグを書くとファーストビューのactivityを指定できる。 - エントリポイント自体はAndroid SDKが隠蔽していて、OSの判断でアプリのプロセスが破棄される。 - Applicationクラスのサブクラス内のonCreateメソッドがプログラマーにとっての実質的なエントリポイント。 - onDestroyメソッドできちんと終了処理を書かないと、ユーザーに迷惑をかけるアプリになりかねないかも。 - Activityクラスはアプリ画面を構築するためのクラス。intentメソッドを呼ぶと他のActivityに遷移できる。 - savedInstanceState変数はアプリ再開時の復元に必要で、スマホを横にする別のアプリを開いた等ちょっとしたことで復元が必要になるため重要。 - Serviceクラスはバックグラウンド処理を書くためのクラスで、ここに書いたことをOS側が把握して何らかの恩恵があるんじゃないか？と思っている。 - 描画用のコンポーネントとしてはViewはゲームに向かない。再描画中にユーザー操作を受け付けられない仕組みになってしまっている。 - SurfaceViewは別スレッド（SurfaceHolderの実装クラス）で描画するのでViewよりはゲーム向き。 - Open GLは3Dゲーム向き。SurfaceViewより処理が速い反面、2Dゲームを前提とした作りではない。 - libgdxはアンチウィルスソフトに弾かれる。 - VulkanはC++。 - 現在はKotlinでJetpack ComposeというUIツールキットを活用することをGoogle公式は推している。 - Jetpack Composeは再描画のタイミングをツールキット側が自動で判断する。 ## 自分の考えと疑問点描画関係は2DゲームならSurfaceView、3DゲームならOpen GLと考えている。 libgdxは良さそうだけど、アンチウィルスの誤作動だとしても弾かれるのはビジネス用途的にNG。 VulkanはC++の学習コストが高そうで、Composeは再描画方式がゲーム向きでないと考えている。再描画やアニメーションのスレッド処理は、ScheduledExecutorServiceクラスのscheduleWithFixedDelayメソッドの利用を考えている。万が一、処理が1フレームに収まらない可能性を考えると、１フレームの時間が多少ずれてもscheduleメソッドの方が良い？ Runnableでwhileループする方法はCPU消費が激しいのでNG。ゲームの画面遷移については2通りの方法を思いついているけど、知識も経験も乏しくどちらにする決めかねている。他にもっと良い方法があれば知りたいし、そもそもにどのようにするのが一般的なのかを知らない。 1. 素直にゲーム画面毎にActivityとSurfaceViewを作る。まずはタイトル画面のActivityとSurfaceViewを作り、ゲーム画面で「はじめから」や「つづきから」をタップすると、次の画面のActivityにintentするイメージ。実装が楽そうでメンテナンス性も良さそう。半面、複数のActivityを用意することや頻繁にActivity遷移を行うことがオーバーヘッドに繋がるのではないかという懸念がある。また、画面遷移する毎に前画面のスレッドを止めて、遷移後画面のスレッドを開始する実装にも違和感がある。ゲーム開始から終了まで単一のスレッドを使いまわしても良いのでは？という疑問。 2. それぞれひとつのActivityとSurfaceViewの中で描画、イベント処理等を行う。まずは下記のように画面の状態をenum型でラベル化する。 ```Java public enum ViewType{ TITLE, OPTION, LOAD, SAVE, STORY, SETUP, BATTLE; } ``` 下記のように描画、イベント処理等を行う。画面状態に対して、SurfaceViewに描画処理するクラスやイベント処理するクラスをマッピングする。あくまでイメージを伝えるために大雑把に書いていますので、細かい部分のツッコミは無しでお願いします。 ```Java public class GameView extends SurfaceView implements SurfaceHolder.Callback{ private ViewType currentViewType; //Drawerのサブクラスで画面毎の初期描画を行う。 private HashMap drawerMap; //Touchableインターフェースが実装されたDrawerサブクラスにタッチイベント処理を書く。 private HashMap touchableMap; private AnimationQueue animationQueue; public GameView(Context context, int defaultFrameRate){ super(context); ...中略... drawerMap.get(currentViewType).draw(); ScheduledExecutorService service = Executors.newSingleThreadScheduledExecutor(); service.scheduleWithFixedDelay(() -> { animationQueue.drawFrames(); }, 0, 1000000 / defaultFrameRate, TimeUnit.NANOSECONDS); } public final boolean onTouchEvent(MotionEvent event) { touchableMap.get(currentViewType).touch(event); } } ``` アニメーションは上記コードにあるDrawerクラスのコレクションとして実装する。コレクションの要素に何も描画しないEmptyDrawerクラスを含める事もできる。描画済みのDrawerクラス要素はコレクションから削除される。主にタッチイベントからアニメーションが追加されたり、ループしたいアニメーションが画面表示時に追加されるイメージ。 ```Java public final class Animation extends CopyOnWriteArrayList{ public Animation(Drawer... drawers){ ...略... } public final void drawFrame(){ remove(0).draw(); } } ``` 現在の画面でアニメーション描画が必要になる度このキューにAnimationインスタンスが追加される。各フレームごとにキューに追加されたアニメーションが描画される。空になった要素（Animationインスタンス）はコレクションから削除される。画面遷移時はキューの中身が強制的に破棄される。 ```Java public final class AnimationQueue extends CopyOnWriteArrayList{ public final void drawFrames(){ if(isEmpty())return; TreeSet removeSet = new TreeSet<>(); for(int i = 0; i < size(); i++){ get(i).drawFrame(); if(get(i).isEmpty()){ removeSet.add(i); } } for(int i: removeSet.descendingSet()){ remove(i); } } } ``` 上手く実装出来ればライブラリ化して今後様々な作品に使いまわせそうだけど、回りくどく実装する分拡張性に問題が出てきそうでもある。

Accepted Answer

まず、技術選定が必要な気がします。TakaiYさんがおっしゃているように、スマホゲームならUnityが定番になります。Javaでゲームを作った場合は、主力からは外れるので、ある程度のリスク管理が必要だと思います。

今後どのような方向に進むかによって、以下のように技術選定をする必要がありそうです。
- 業務アプリの延長で（普通のアプリのような）ゲームを作りたい場合: Kotlin + Jetpack Compose
- 将来的にゲーム業界の仕事もやる場合: Unity or Unreal Engine
- スマホゲームに特化したい場合: Unity or Godot
- 3Dをリアルに表現したり、VTuberのような3Dライブの仕事をやりたい場合: Unreal Engine
- リスクを負ってもJavaでやりたい場合: libgdx + Java

特に、ゲームエンジンを選択しない場合は、車輪の再開発となり、ゲームエンジン相当のプログラムを自作することになるので相当なリスクになると思います。

また、スマホゲームを（売り上げて）主力事業にしたいのであれば、先に企画が重要です。これは普通のアプリ開発にも言えるのですが、競合分析や市場調査などをしないと、そもそも売り上げが期待できないからです。

※ 例えば、競合の（ハクスラRPGの作者さんの）SNSを見たり、技術blogなどを見るのも推奨します。その方がUnityを使っているのであれば、Unityでは同じゲームが作れるという保証にもなります。売上を公開している方であれば、なお参考になると思います。

いずれにしても、スマホアプリ開発は思い切った決断で、とても良いと思いますので応援しております。

Answer

時間とか工数とか全く考えずにただ質問を一読してのイメージなのですが。

パソコン用業務アプリから Android 用ゲームというのは、少々跳び過ぎではないでしょうか。
環境も対象も全く違うのでは手を付けるものがアレコレ有って大変そうです。
例えば先ずは業務アプリをパソコンから Android に移植する形で違いを知ってからゲームに移行するとか、逆にパソコンでゲームを作ってからそれを Android に移植する形にするとかの方が、一度にやることが少なくて済むような気がします。

Android での java 開発で書かれていることで少し書かせていただきますと、大分以前にカスタム View によるキャラクタ移動と SurfaceView に画像を書き込む形でのキャラクタ移動を比べたとき、カスタム View の方が滑らかだったことがありました。
原因は確定しなかったのですが、 SurfaceView はダブルバッファが無いだか無効だかだろうと思われました。
イメージとしては断然 SurfaceView を使うべきだろうと思っていましたが、違う場合もあるかもしれませんということで。
他に、Android アプリとしての開始は一般的には Activity の onCreate かなとか、画面遷移を頻繁にするなら Activity では無く Fragment かなとか、この辺は業務アプリの画面を作られると色々出てくると思います。ダイアログ1つ取っても、表示中に画面回転したりアプリを切り替えられたらどうなるか、対応するにはどうするかとかありますので。

そして、ゲームエンジンを使うなら Unity は確かパソコンでも出来たかと。
ゲームの業界は全く知らないですが、パソコンで作ってスマホに移す形でも『スマホ用ゲームを作る』は達成出来るのではないでしょうか。

テーマ、知りたいこと

背景、状況

Androidアプリ開発についての自己理解

自分の考えと疑問点

関連した質問