我正在开发一个单一形式的 c# 游戏，它由许多用户控件、积分面板、游戏操作的历史面板等组成。 我开发了一个 Manager 类来将 Interface 与“游戏引擎”分开，这个 Manager 类负责所有游戏逻辑。但我对我的解决方案并不满意。
那么问题来了，对于这种情况，最好的方法是什么？
一个充满用户控件的表单，通过公共属性和一个管理器类公开其对象来处理“引擎”？可以使用什么样的设计模式？游戏是c#版本的骰宝。
在此先感谢
【问题讨论】：
标签： c# .net winforms design-patterns game-engine
您已经完成了将界面与引擎分离的第一个关键步骤。通过将引擎和接口拆分为较小的组件，可以获得更多收益。例如输入控制器、渲染器、动画管理器、转向系统、单位/卡片/件或其他。
人们可以告诉你一些事情，但我的建议是不要一头扎进游戏中期望设计正确。计划通过您编写的每个游戏改进设计并从个人经验中学习。接受您的早期游戏将有糟糕的设计将使您更有效率。更重要的是保持节奏，不要陷入设计决策和模式思考中。代码混乱的完成游戏就是游戏。一个设计精良但从未完成的游戏不是。我认识的一些最有生产力的（业余）游戏开发者在他们最初的游戏中编写了可怕的代码。他们只是通过它并完成了它。
【讨论】：
如果您的游戏比简单的迷宫或其他东西更复杂，您需要分离关注点。另一位评论者提到了 MVC。我也推荐这个建议（尽管有经验的游戏开发者肯定会有更合适的方法）。
我会分几个步骤来处理它：模型、操作和交互
首先，考虑一下您将允许您的游戏处于什么状态。例如，在国际象棋中，有一个包含 8x8 方格的棋盘、两个玩家以及属于 必须占据未占用方格的任何一个玩家。因此，您的第一步是考虑如何建模游戏可能处于的允许状态：
interface IChessGame
{
IPlayer PlayerA { get; }
IPlayer PlayerB { get; }
IChessBoard ChessBoard { get; }
}
// Etc etc.
那部分是相当基础的。模型的稳健性将对实施后续步骤的难易程度产生很大影响。
接下来，想想你的游戏、应用程序等如何操纵状态。这些最终将成为你的命令的组成部分。举个静态例子：
static IChessGame MovePiece(IChessGame oldState, IChessPiece chessPiece, int[,] newLocation)
{
// Check the chess piece.
// See if the new coordinates are allowed for that piece.
// Deal with any collisions (e.g. if an opponents piece is in the square then kill it, if it's your piece then block the move, etc.)
// Generate a new, allowed, state
}
现在您有了可以操纵游戏状态的命令。您如何设计这些将在很大程度上取决于您的模型方法（可变、不可变、包含 contentChanged 事件等）
现在您有一个代表游戏状态的模型和操纵该状态的工具。最后阶段是设计一种用户可以开始使用它的方法，即 UI/控制台。
这将根据您完成其他两个步骤的准确程度而发生很大变化，但我强烈建议您执行前面的步骤而不必担心您的交互。
【讨论】：
也许您正在寻找 MVC 模式。我不是游戏开发者，但这是应用程序的标准，我将它用于大多数项目。
有很多关于如何使用这种模式的资源。 This link will show an example 如何在游戏设计中具体使用它。
MVC 模式将帮助您使用“经理”将“引擎”与“用户控件”分开。
根据您的问题，听起来您已经这样做了...？为什么您对当前的解决方案不满意？
【讨论】：