如何有效开发Android游戏？[关闭]

我已经附上了我用油漆制作的流程图的图像。

该图显示了我想如何开发自己的游戏。我想要一款运行良好的游戏，它具有易于更新的智能编码，并且随着时间的推移具有广告功能。我的目标平台是Android智能手机，所有代码将使用具有XML扩展资源的Java编写，如果那很重要的话。我不是在寻找硬代码，尽管伪代码会有所帮助，但我还是更喜欢建议和专业意见。

我的问题是：

这是编写游戏程序的好方法还是有更好的方法来进行游戏？是否需要进行任何修改？任何建议都是有用的，因为我没有游戏编程方面的经验，所以我更喜欢那些写过几款游戏并且从经验中知道应该如何设置其代码才能有效运行的人的建议。

许多android游戏的范围还不够大，不足以证明保存/加载或选项/首选项的合理性，不要管自定义字符之类的东西，仅仅是因为它们在火车上临时玩了10分钟。

不要犯我在第一个android游戏中从事大范围开发时所犯的错误。制作一些较小的游戏，然后再做一些较大的游戏

Android具体细节：

结构体：

我建议将几乎所有游戏都放在一个活动类中。Android的想法是，每个活动都像一个微型应用程序，与应用程序中的其他活动半独立。该应用程序实质上是一堆活动，用户可以看到最上面的活动。

当您从顶部弹出一个对象时，它通常会被破坏，并在用户下次启动新活动（startActivity意图）时重新创建。这使得很难维护活动之间的状态，并导致单一的活动架构

您可能需要具有“新游戏/加载游戏/选项”菜单的主屏幕类型活动，并进行启动活动。但是，您最终将不得不在游戏活动中拥有一个游戏内菜单，其中将具有大多数相同的功能。

我自己的应用程序制作了一个“ MenuActivity”，它具有启动新游戏，保存，加载，更改选项的功能。然后，我的HomeActivity和GameActivity都会对此进行扩展。

由于所有内容都在一个Activity类中，因此我建议对Activity类进行分层，并使用私有，受保护和默认作用域批次。这样，您至少可以将内容拆分为不同的文件，以防止拥有一个无法管理的Activity文件。例如，对于我自己的应用程序：

GraphicsEngine extends MenuActivity。

PhysicsEngine extends GraphicsEngine。

GameLogicActivity extends PhysicsEngine。

UIActivity extends GameLogicActivity。

由于我的应用程序是3D opengl-es，因此我做的很多事情都无法进行交叉活动，因此所有内容都处于同一活动中，因此也许我偏向于使用一种活动架构

-

穿线

对于游戏活动，您有两个线程（如果正在执行3D opengl东西，则为3个线程）。UI /主线程是一个线程。这是活动开始并在其中运行并由android提供给您的线程。

该UI线程是唯一可以在其中更新UI元素（视图，布局等）的线程。它也是将运行用于用户输入的所有侦听器的线程。您看不到UI线程的任何机制，只是它在后台某个地方的循环中运行。

第二个线程，您自己做（尽管有所有缺点，我还是建议您使用AsyncTask）。这会完成您在常规游戏循环中所做的所有非UI事情，例如更新动作，计算碰撞，战斗计算等。

您将此AsyncTask线程/类作为活动的内部类。这样，您可以拥有一些Vector<Spaceship>可由UI线程和游戏循环线程访问的活动范围对象（）。

由于游戏逻辑在游戏循环线程中进行，因此这是唯一需要实际更改变量值（更新坦克速度，降低玩家生命值）的线程。UI线程仅读取值，因此应该有最少的并发问题。

棘手的是让UI线程根据游戏循环线程的请求进行更新。有两种方法可以做到这一点。如果您阅读AsyncTask文档，则它具有publishProgress（）/ onProgressUpdate（）方法。这实际上是将内容添加到UI线程的下一个要执行的循环的队列中。

处理程序执行的操作完全相同，在这里您实现handleMessage（）方法，而该方法实际上是由UI线程的下一个循环执行的。

最终，任何用户输入都位于UI线程中，您可以立即从中更新UI元素（因此在任何onClick / onTouch侦听器的实现内部）。如果您需要更新游戏对象，则可以使用同步之类的方法，也可以将自己的更新队列实现为AsyncTask，就像UI线程一样，它将在下一次执行游戏循环时进行

Android线程指南。

-

用户界面

至于单个活动中的实际UI结构，我建议使用框架布局作为基本布局。框架布局中的子元素就像队列一样工作。首先绘制第一个元素，第二个绘制在第一个元素之上，第三个绘制在第二个元素之上。

这样，您可以拥有多个XML布局文件，并且通过管理框架布局的子项，可以轻松地将视图集交换进出。

如果您始终将SurfaceView放在底部（框架布局中的第一个孩子），则可以在曲面视图的顶部使用所有常用的android视图/小部件（按钮，文本视图，滚动视图）等，游戏的图形部分。

因此，例如，如果正在加载某些内容，则可以暂停游戏循环/仅使其跳过所有内容，将不透明的“加载”屏幕添加为框架布局的最后一个子项，用户将看到“加载”出现在屏幕上，完全不知道背后有其他观点。这样，您不必删除需要花费很长时间来设置的视图，也不必在每次添加/删除视图时都会造成麻烦。

我也建议您使用View.setVisibility很多。例如，您可以将整个“库存”布局添加到基本框架布局，然后在用户单击以查看其库存时在其上设置setVisibility（View.Visible），并在他们再次关闭时将其设置为setVisibility（View.Gone）。这样，您甚至不必管理框架布局的子元素，而只需添加所有内容并在用户执行不同操作时使它们可见/不可见即可。

这有助于再次进行线程化；当用户单击以打开其库存时，将在UI线程中处理onCLickListener，使库存在其中可见，然后再次从UI线程中调用updateInventory方法，仅调用所有游戏对象上的吸气剂

这是我为先前有关单一活动/框架布局概念的问题制作的图表：

我在图中看到的很多内容都与UI相关，而且这似乎很合理。图中只有一小部分保留用于实际游戏逻辑，这非常模糊。

我想你太努力了。我建议您只是开始编写代码。选择一个特定的问题并开始解决。您将学到很多东西，以至于您对问题空间有一个更好的了解时，您将拥有完全不同（更有用）的观点。