基于5层模型&对象的游戏描述法

madmonkey

对我很新鲜...

看完没什么感触,对不起楼主啊!

弱弱的问句，流程图能做到同样的事不...？类似问题我都是画流程图...

zfscnu

恩~~~ 流程图可以做同样的事情、、、、而且GD-BFO中也不是没有流程图

正如面向对象做的事情，面向流程也是可以做到的，而且面向对象中也有流程

不过GD-BFO是整体地去描述，流程图A与流程图B的联系是什么？再用一个流程图来描述？流程图与资源的关系是什么？如果其中一个有些变化，影响多大？、、、、、


恩~~顺便说下，网络游戏可以说涉及了电脑编程几大应用，比如数据库编程，网络编程，图象编程、、、、游戏策划真的可以通过几张流程图+说明文字来“指导”程序来“创造”游戏？有时我黑暗地猜测，当项目进行中时，程序跑来要XX流程图，是不是作为以后出问题可以推卸的借口：看，这是策划给我的流程图和说明，我照着做了，什么？硬直状态？我不清楚哦，他又没有说、、、、、、、（当然我未入行，这些都是我凭职场经验猜测的）

在看到很多在职策划写着：以后会写XXX系统，那就会更好玩了、、、、、、、每当看到这些文字，我都会感到些奇怪，一份没有约束力、还可能是以后背黑锅的“证据”的文档，在创造XXX系统中有多大的影响力？到底是你写，还是程序通过看你的文档后凭他自己的理解写的？

一份文档的作用仅仅是把一个可能懂或者不懂的程序员短时间“熏陶”或者“提升”游戏理解？然后程序就自己写代码、、、提升的效果取决于两个要素：程序员自身游戏理解，策划的“说教”水平。恩~~~或者策划需要修炼 传教 技能。

storm1986

首先回复楼上的，流程图和UML图没有可比性。UML图能够包含的信息要多得多。

UML的强项在需求分析上，USE CASE事件流描述和USE CASE框图是基础，通过它们理清需求是软件设计的第一步。功能和界面框架在这个阶段都可以根据用例事件流设计好。
楼主的图侧重分析技术原理了，和策划最关心的问题有偏差。我觉得策划要学UML的话应着重理解“用例模型”。

另外，个人觉得画UML图最好用RATIONAL软件，专业又方便。