我最近提出了一个模拟/策略游戏的想法。我已经在纸上概述了很多关于游戏机制的想法，并且有一些基本的类和对象正在工作。 （我是用CNA在C＃中写的。）
对我而言，一件令人痛苦的事情是，我不是一个图形艺术家，并试图让任何图形编程现在让我感到沮丧。想到的一个想法是试图让整个游戏首先在文本控制台上运行。我记得小时候花了数百个小时玩Zork和Hack，我的大部分游戏元素想法都不需要实时精灵动画才能工作。
所以我在这里向社区提出的问题是，我是否应该通过专注于让它简单地以文本库模式工作然后重新组合给它一个漂亮的图形界面来保持我对概念的热情？
OR
在我试图清除我的想法的同时解决图形界面问题？
在写这个问题的过程中，我想我自己回答了这个问题，但我很乐意听到人们的想法。
答案 0 :(得分：7)
根据您对游戏的描述，我认为您有正确的想法。如果您将问题分开，那么您可以先实现许多业务逻辑。把它想象成一个MVC应用程序。您可以将视图留待以后实施;只需提供一个与您的业务逻辑接口的层，您的视图就可以使用它。
这样，您的视图（基于文本或图形）无关紧要。您只需将元数据传递到视图，视图就会决定如何渲染它。
所以我会说你的想法很好。从业务逻辑和基于文本的视图开始。这样，您就可以充实您的概念和想法，并决定将哪种数据传递给视图。但请记住一件事 - 在此阶段你必须非常小心不让关于视图的假设泄漏到您的业务层。因此，您应该将业务层和关联的接口编码到视图中，就像您不知道视图将是什么一样。我的意思是，因为您从基于文本的界面开始，所以不要做出与您的特定实现相关的编码决策。
一旦你拥有了所有东西，你就可以开始学习图形并慢慢启动你的图形层。
当然，这种方法（MVC）可能不适用于所有情况，尤其是当您的视图对时间要求严格时。有关更多信息，请查看这些Stackoverflow问题：
我只是想清楚一点，我不是在为你的游戏提倡MVC模式 - 我只是想强调分离关注点，这样你就可以轻松地交换视图而不进行重大的重构。
答案 1 :(得分：1)
游戏是一个复杂的项目，可以分为许多区域。这些可以是实际模块（例如，GUI渲染器或通信管理器），或者它们可以更理论或逻辑，例如“游戏设计”。
虽然所有这些部分一起工作 - 最好是和谐 - 以展现实际游戏，但每个部分也独立存在。因此，划分和分配总是一个好方向。征服。如果您对自己的想法充满信心，那么请尽可能以最简单的形式实施，这可能是一个控制台应用程序。
但是，您需要记住，虽然您可以通过单独开发每个模块来开始，但最终您需要考虑这些部分如何协同工作。这将固有地影响您的模块设计。例如，您可能会发现您的游戏逻辑运行良好，但您无法让用户在UI方面实际执行某个步骤。可玩性是游戏最重要的功能之一，你的用户界面甚至可能决定一些游戏逻辑。这个概念与将UI与逻辑分离的黄金法则相矛盾 - 但正如我所说，游戏很复杂，而对于最终产品，你经常会发现自己会弯曲一些规则。游戏与其他项目不同 - 可扩展性不是问题。可维护性非常重要，但如果您需要额外的CPU汁液，则会牺牲它...等等。
答案 2 :(得分：0)
如果我是你，我会首先创建一个基于文本的命令行界面。然后，如果您决定制作一个实际的GUI，您可以让GUI自动执行命令行游戏，这样您就不必编写游戏逻辑两次。许多工具都会使用这种方法。例如，某人将创建命令行碎片整理工具，然后有人将为该工具创建GUI“包装器”。 Sort of like what Nethack did.
答案 3 :(得分：0)
制作用户界面。保持图形简单（Paint）并专注于可用性。然后将您的游戏作为开源发布，其他人将创建漂亮的图形和酷炫的UI。
答案 4 :(得分：0)
我的建议：现在几乎没有任何软件可以单手操作。
尝试勾勒出你的想法，发布到某个地方，找到更多感兴趣的人，组建一个小组，并弄清楚你的手。
如果您的想法真的很好，您会发现更多的团队成员可以填补您在其他所需领域缺乏专业知识。
您可以尝试在网络上找到人，开始像开源项目，或者您可以尝试寻找投资者，这可以为您的业务注入资金，并且您将能够雇用专业人员。