楼上的朋友所说个人认为一些纰漏.
第一,不要在设计时经常改动设计方案,否则工期会延误. 难道在编码和设计的时候经常改动? 在设计的时候改动与后期的改动谁会带来比较大的损失呢?况且软件危机是怎样产生的? 这是软件工程出现的原因吧,所以首先分析好你的游戏框架,多花时间分析上!.
第二,网络版则必须写 软件设计概要书 和 用户使用说明书...任何上规模的软件项目可以不写说明书? 具体点吧,保留下最本质的数据流图,更多的文档资料所带来的结果就是让你的软件更容易维护,即可测性,可修改性,可理解性都必须具备..
如果只是几百或者1千行并且不是太复杂的小游戏的话,并且不希望非常大的扩展下去,那就随便画画草图脑子有个大概思路就差不多可以开始了.
如果楼主想用vb做,那可能不太合适,本人也只是用过它做过一些俄罗斯方块,贪食蛇之类的小游戏还有类似斗地主那样的牌类游戏.
简单的说吧,首先你要知道你想做什么,并且可以用VB实现吗?如果可以继续分析,怎样做? 用什么样的技术?等确定了之后,大概的将编码写在纸上,如果自己觉得逻辑合适就将其输入电脑运行之,并在输入电脑运行之后不段调试尽量多找一些难发现的错误..
不管你拿那种语言编游戏 你必须知道游戏需要的参数
如果是单机版你最后先把设计思路和目的想清楚,不要在设计时经常改动设计方案,否则工期会延误.
如果是网络版则必须写 软件设计概要书 和 用户使用说明书
别看麻烦但是对你以后的开发很有帮助!
呵呵,我用VB编过一个贪吃蛇,``你要不要,但是代码可能不是很经典, 因为那是我刚学编程时做的一个```
光说不干是做不出来的