啊说的是，是我的失误。简要介绍下游戏吧：

游戏设定在近未来，地球面临危机，紧要关头火箭的零件失窃。玩家将扮演一位“不能使用武力”的安保机器人，通过自己的铁嘴，去把失窃的零件“要”回来。

————

引擎：rpg maker（本次gamejam是rm官方主办，所以限定使用他们的引擎）

游戏类型：rpg

预计游戏时间：1小时

结局数量：1个（会有显著的通关提示）

附一张截图

哎呀，看来肥哥们似乎不太感兴趣|д` )

不要紧！( `д´)既然是分享，那我就把自己开发过程中遇到的问题和经验一并说说，算是抛砖引玉吧。如果有独立开发想法的朋友可以参考一下，如果有成熟经验的肥哥也请指正一下。

开始之前最后宣传下我的游戏啦。游戏的特色是“用吵架代替战斗”，敌我双方在战斗中消耗自己的肺活量，用激烈言辞来降低对方的意志力，或者用话术给对方施加压力。将对方意志力降低到0时，则取胜。

附一张战斗图

(=ﾟωﾟ)=先声明哦，我只有开发小游戏项目的经验，所以如果想开发大项目，或许我的经验并不适用，仅供大家参考。如果有成熟开发经验的肥哥，欢迎随时批评指正。

在我看来，开发本质上和项目管理区别不大。需要有日程安排和节点。正式开发之前，为自己定好开发流程就像为项目定好节点一样重要。比如先做什么后做什么，哪部分花的时间多一点，哪部分少一点，都要规划好 ( ﾟ∀ﾟ)

我习惯设定的节点顺序是：立项、制作雏形、小测试、正式开发、测试、发布。

至于开发的日程，我采用的是倒排工期——从截稿日往前推时间。4月6日截稿，而我是2月7日报名，中间有58天（8周）。但我是业余开发，而且时间相对长，给自己留的时间也相对长。

具体安排如下：我打算提前1周上交，为自己留下宣传造势的窗口。在这之前留1周用来测试和修bug。然后3周用来正式开发。然后5天用来小测试，10天用来制作雏形，5天用来立项。

所以最后的计划就是(＾o＾)ﾉ：
2月12日：完成立项。
2月22日：完成雏形制作。
2月27日：完成雏形的测试和修正。
3月20日：开发完毕。
3月27日：完成测试和debug并上传游戏。
剩余时间：在论坛和社交平台宣传。

>>No.65776630
>>No.65778723
成功引起两位肥哥注意 |∀ﾟ
欢迎各位来体验哈

补充一下刚刚提到的日程安排。实际这次比赛期间我遇到比较多的突发情况，导致实际日程与计划日程出入巨大(|||ﾟДﾟ)

当我解决完所有突发情况，已经是3月21日了，距离截稿仅剩2周( ;ﾟдﾟ)

当时我只完成了立项，啥都没开发。说实话有点沮丧和慌张但是因为已经有了计划，所以按照原计划进行紧急调整：

3月23日：确定一个易开发的玩法，完成雏形并同步完成测试( `д´)。
4月2日：完成开发
4月5日：完成测试并且上传。

计划难免会发生变动，而且我的实际开发日程又跟这个紧急调整后的计划有出入⊂彡☆))д`)（后面我会讲到）。

那么这个计划是不是没用了呢？¯\_(ツ)_/¯ 当然有用！有计划一来可以让自己心里踏实，二来可以防止自己在某个步骤沉浸太久无法自拔，三来面对紧急情况你可以根据已有的进度，从计划中压缩调整其他的步骤时长。

总而言之，如果好的开头是成功的一半，那么做好计划至少是成功的四分之一(ノﾟ∀ﾟ)ノ

>>No.65788556
感谢肥哥游玩！( `д´)7

剧情能获得肯定让我很惊喜，因为说实话不太擅长写剧本。这个剧本也是反复想了好久才确定的。

玩法和流程上的问题肥哥说的很中肯。本来还构想了一些与“语言”和“逻辑”相关的谜题和剧本分支。但是时间太紧了，只能立刻收束剧本，将玩法集中在战斗上。流程短也是因为时间不够了。为了追求完整性，快速收尾整合成现在这样。

这个游戏做完以后是有意向继续把它扩充一下的，另外重新做一个更大体量的游戏。也欢迎肥哥提点建议，到时给大家分享一下。

抱歉上周是全天候加班的一周。

终于要迈出第一步啦——立项。

可能有小肥就要问了：肥哥啊，这项该怎么立啊。哎小肥别急，这立项可要通盘考虑呀。

（1）确定引擎
既然是RM官方的活动，自然没什么好说的，引擎当然是RPG maker啦。我想对擅长mv，所以决定就是它了。

（2）确定玩法
那么有小肥就会问了：肥哥呀，是不是确定了引擎我就能把游戏做出来了呢？

这当然是远远不够的啦。游戏是一个互动娱乐产品，所以它的核心部分就是和玩家互动。那么该怎么互动呢？这个问题的答案就是你的游戏的核心玩法。

我打算做个传统回合制战斗游戏。但只是这样还是不够的，由于时间有限，继续挖掘玩法不太现实，于是我的思路是对它进行一个简单的包装。

于是三个要素跳入我的脑海：包龙星骂大海、人工智能、2032年小行星撞地球。然后把这几个元素在脑子里糅合。
(つ@⊂) 啪！
我要做个“小机器人用嘴炮拯救地球的游戏”！

所以我的包装思路是做成“嘴炮战斗”。


（3）确定剧情
其实在上面一步为游戏进行包装的时候，设定了一个主题。那么这个剧情就是围绕这个主题展开的。

所以这个环节我只用一个流程图写下了故事大纲。

（4）确定美术风格
严格的来说，游戏作为设计产品，是要为玩家服务的。美术作为游戏产品的一个重要部分，自然也应该向玩家审美能力看齐。

但是嘛(ゝ∀･) 早就想尝试拼贴形式和超现实主义了( ﾟ∀。) 所以这次决定任性一回，把拼贴和超现实主义确定为美术风格。

（小肥们不要乱学这种立项思路，用什么样的风格一定要斟酌好( ´_ゝ`)）


（5）确定音效风格
音效我是一窍不通，而且时间有限，所以决定采用官方dlc的通用音效。

那么至此，立项就完成啦。

又是忙里忙外的一周|д` )

上周我们说完了立项，此刻呢各位肥哥脑子里对于自己的游戏大概有了一个相对明晰的概念了。接下来，终于要开工啦！

那么有小肥不禁就要问了：肥哥啊，我该先从哪里做起呀( ﾟ∀ﾟ)？

这位小肥问得好呀。立项完毕之后第一步要做的就是做一个玩法雏形。主要目的就是验证你的想法的可行性。

所以呢，首先要列一张清单，包含你要表现的核心玩法、主要交互行动、美术素材、音效、核心插件功能测试。

比如这个游戏，我选择把开头的一段作为这个游戏的雏形，清单如下：

核心玩法 - 战斗系统、状态效果；

主要交互 - 与指挥官、npc对话；

核心插件 - Q系列插件主要功能测试；

美术素材 - 地图背景1张，场景内主要人物及npc、敌人战斗图、主角行走图；

音效 - 无。


总之核心目的就是把核心玩法和特色展示出来。按照这个清单准备好各样素材，然后开工制作雏形即可。

制作完毕之后立刻进行小范围测试，突出一个快。快速验证玩法，听取反馈做出调整。确保你的雏形是可行的，吸引人的。

至此，雏形制作完毕，可以放心大胆的正式开发啦。

此刻的各位肥哥已经完成了雏形制作，并且雏形得到了空前的喜爱。所以各位肥哥的开发必将一帆风顺。

正式开发的流程就比较简单了。各位肥哥要做的就是把剧本扩展完，然后按照自己写的剧本，把自己的核心玩法、美术素材、音效素材安插进去。

比如我把之前的剧本进行扩展，列出每个剧情阶段的场景（地图）、主要npc、主要战斗。

然后按照如下顺序进行开发：
1、画完所有地图；
2、找到所有其他美术素材；
3、添加音效；
4、逐个场景进行搭建，并测试本场景内的事件完整度；
5、每完成两到三个场景，适时测试。

通过这个流程把所有场景搭建完毕。

实际上这十来天的时间几乎80%都用来画场景了。这也是前面说的计划赶不上变化的原因。

所以正式开发的真正难题是工期安排。很多你在立项时设想的估时并不准确，这就需要在开发时安排好时间，确保在时间节点完成你的进度。

上面提到我做的第一步是扩充剧情。那么有小肥就要问了：俺不中咧肥哥，俺要做一个超级玛丽，没有剧情可咋整(・∀・)

我说小肥不要急。这里我要修正上一贴我的一个说法，与其说第一步是扩充剧情，不如说这一步是：

关！卡！设！计！

这下小肥应该有思路了吧。关卡就是给玩家设计的挑战。

比如我的rpg游戏，我的关卡就是剧情里的一个又一个节点。比如第一个节点是打沙包，挑战的难点在于让玩家击败沙包；第二个节点是出门杀，挑战的难点是让玩家躲过去。

我要做的就是用剧情把这些节点联系起来，我会把剧情扩充成这样：

接到指挥官指令 - 〔节点1〕去打沙包训练 - 存档 - 〔节点2〕出门

(＾o＾)ﾉ那么这段关卡设计就算完成啦。

如果小肥要做超级玛丽，当然也是一样的思路。

比如第一个“挑战”是踩蘑菇精，第2个挑战是跳过水管，第3个挑战是变大之后吃高处的金币。

那么小肥要做的就是把它们按顺序串联起来。

这时候又有小肥要问啦，肥哥呀，那我把这些挑战按顺序塞得满满的是不是就完美啦(*´∀`)

哎呀呀小肥，可不是这样滴。关卡设计的难点就在于让玩家觉得挑战不算太难，以至于沮丧；但又没那么简单，让玩家感觉无聊。

而且挑战的密度也要合理。你把所有的挑战一股脑的塞进去，岂不是让玩家懵了。

比如你要做超级玛丽。那就要精打细算，开头多少个格子是安全的，然后走几步遇到蘑菇精，踩死蘑菇精之后，玩家大概有一点点成就感，然后给玩家留几秒的放松时间，下一个挑战是跳过水管，然后再放几个安全的平地砖块，紧接着安排头顶的升级砖块，后面是一个需要变大之后的玛丽飞檐走壁才能通过的小难关。

所以正确的做法是一边设计关卡，一边揣测玩家的心理。给玩家一点小成就感，并且让玩家适当的放松，然后给玩家上强度。循环往复。

如果让我重新概括一下正式开发的流程，那就是：
1、关卡设计
2、安置素材和挑战
3、及时中途测试

好耶得到了肥哥们的认可(`ε´ )，记录下来既是为了分享经验，也是巩固思路。如果能帮到各位找到开发的思路那就再好不过了

各位肥哥经过一番苦干，大家的游戏已经基本落地了(ゝ∀･) 自己的游戏马上要问世了，提前祝贺各位肥哥。

心急的小肥就要问了：肥哥呀，今晚游戏就能完工打包，明天是不是就能发布了呀(*´∀`)

小肥还真是心急呢。完工的游戏当然可以随时发布，但是小肥呀，你也不想你的游戏一上线爆出恶性bug然后就差评如潮吧(`ヮ´ )

所以在发布之前的最后一步就是：

测！试！

虽然开发过程中各位肥哥做了大量中途测试，但并不可能保证已经排除了所有bug。更加重要的是，关卡设计的趣味性、数值设计的合理性都需要验证。因此最终的测试必不可少。

大家可以把游戏发给自己信得过的朋友（避免商业泄密嘛），让他们从以下几个角度测试一下：

1、是否有恶性bug（例如崩溃报错、角色或界面卡住无法移动等）
2、是否有普通bug（例如音乐、图片无法正常加载）
3、是否有设计缺陷（例如数值设计不合理，关卡太难或太简单、玩法有问题、剧情/音乐/美术不讨喜）

根据玩家的反馈及时做出修改。根据问题严重程度和剩余时间，优先解决bug，然后解决设计缺陷。

在此提醒，bug是客观存在的问题，是必须要解决的。而设计缺陷往往是玩家的主管体验和感受，作为开发者要谨慎甄别，选择采纳。

例1、我的游戏在测试中，有朋友A反映剧情不够吸引人，他参照的对象是星穹铁道，举例了崩铁的人物设计、世界观塑造等等，目前我的剧情设计太浅薄；但也有朋友B反映剧情轻松有趣，他也不喜欢大段文字。

这时候就要仔细斟酌了。我的开发目标是在有限时间内应对比赛，如果继续深化剧情需要更多时间，另一方面我更倾向用玩法侧面展示世界观，而不靠文字。所以这个朋友A的建议我选择不采纳，以后开发续作的时候会加以考虑。

例2、朋友C反映某关卡太难，朋友D表示难度可接受。

这时候我选择继续扩大测试范围。紧接着，朋友E、F也说关卡太难。现在看来，大多数人认为关卡难度过高。所以我选择调低关卡难度/给玩家更多提示。


这样的测试我做了好几轮，图中就是我记录下的所有问题。每当出现新问题就记下来，解决以后就打勾。

多轮测试后，游戏的问题被解决完毕，现在，肥哥们，把你们的游戏端上来！震撼所有人！( `д´)9

———————————————

到此为止，我的开发笔记就结束了。希望能给没开发过游戏的肥哥们一些启发。独立开发困难重重，但是最难不过现在行动。加油啊，肥哥们，游戏界下一个新星一定是你(ゝ∀･)

发到太急忘了发图