NA *_*ker 8 c# console-application
我最近提出了一个模拟/策略游戏的想法.我已经在纸上概述了很多关于游戏机制的想法,并且有一些基本的类和对象正在工作.(我是用CNA在C#中编写的).
但令我痛苦的一件事是,我不是一个图形艺术家,并试图让任何图形编程现在让我感到沮丧.想到的一个想法是试图让整个游戏首先在文本控制台上运行.我记得小时候花了几百个小时玩Zork和Hack,我的大部分游戏元素想法都不需要实时精灵动画才能工作.
所以我在这里向社区提出的问题是,我是否应该通过专注于让它简单地以文本库模式工作然后重新组合为其提供漂亮的图形界面来保持我对概念的热情？
要么
在我试图清除我的想法的同时解决图形界面山？
在写这个问题的过程中,我想我自己回答了这个问题,但我很乐意听到人们的想法.
我认为根据您对游戏的描述,您有正确的想法.如果您将问题分开,那么您可以先实现许多业务逻辑.把它想象成一个MVC应用程序.您可以将视图留待以后实施; 只需提供一个与您的业务逻辑接口的层,您的视图就可以使用该层.
这样,您的视图(基于文本或图形)无关紧要.您只需将元数据传递到视图,视图就会决定如何呈现它.
所以我想说你的想法很好.从业务逻辑和基于文本的视图开始.这样,您就可以充实您的概念和想法,并决定将哪种数据传递给视图.记住一件事 - 在这个阶段你必须非常小心,不要让关于视图的假设泄漏到你的业务层.因此,您应该将业务层和关联的接口编码到视图中,就好像您不知道视图将是什么一样.我的意思是,因为您从基于文本的界面开始,所以不要做出与您的特定实现相关的编码决策.
一旦你拥有了所有的东西,你就可以开始学习图形并慢慢开始你的图形层.
当然,这种方法(MVC)可能不适用于所有情况,特别是当您的视图对时间要求严格时.有关更多信息,请查看以下Stackoverflow问题:
我只是想明确一点,我不是在为你的游戏提倡MVC模式 - 我只是想强调分离关注点,这样你就可以轻松地交换视图而不进行重大的重构.