失败记录

20 Sep 2022 narrative

失败记录，希望下次是成功记录。

产品与市场

前面很长一段时间都在纠结叙事、玩法设计，但是总有种在原地转圈的感觉。因为游戏不是几天就能做成的，可能一开始觉得很棒的主意，后面却变得不是那么有趣了。

最近偶然看《Start small, Stay small》，感觉有受到一些启发

Product Last. Marketing First.

Market comes first, marketing second, aeshetic third, and functionality a distant fourth.

首先要思考的是，这个游戏是面向什么类型的玩家的。

放到Steam上的游戏和放到Switch上的游戏，其玩家群体会差别很大。

《魔女之家》和《零》，虽然可以都算作恐怖游戏，其面对的玩家群体却不见得完全相同。

没有一个目标市场就很难对产品进行定义，没有产品定义就很难形成企划。在企划形成前纠结叙事与玩法的设计是非常没有意义的。毕竟，有的游戏类型完全不需要叙事，有的则相反。产品没有定义会导致想法失控，各种各样的想法都觉得不错，都想放进来。最终使得项目变成一个四不像，连自己都看不下去。

前几天看到的GDC演讲里，有大佬介绍自己是如何做出一些决策的。

感觉最好的方法，就是首先找到一个现有的成熟的产品类型，然后在这个类目内的设计上做简单的修改或者叠加。

一次想要做很多事情，更容易导致失控。

前段有尝试自己进行一些网上的招募，感觉挺失败的。

总结下，除非有明确的商业计划，不要招募。

但是实际上，有明确商业计划的情况下，更好的选择是进行外包。

否则需要花费大量的时间去与人沟通，如果自己的商业目标都不明确，就更难说服别人参与进来。尤其是这边目前每天的时间非常有限，更加难以与其他人同步状态。

原型很重要，任何想法要首先完成Prototype来验证是否真的好玩。

由于平时程序的习惯太重了，会想着找出实现玩法需要做的工作，然后就开始推进了。由于平时不是很有时间，会演变成花了很多时间最后却不觉得玩法有趣的情况。

有的时候为了弥补沉没成本，会想着如何添加新的东西进去挽救下，导致情况越来越糟糕。

做原型的话，就只要把最核心的部分做出来就可以了。

验证玩法有趣再推进才是正确的做法。一些细节的部分，就算做出来了，如果玩法本身没有什么有趣的部分，最后就只是在浪费时间而已。

比如存檔系統，如果要在設計不明瞭的情況下，兼容所有情況的可恢復性的話，會變得很複雜。

对于优化也是一样，过度的优化是没有意义的。在原型完成，确定要继续推进之后再优化也不迟。组件的性能提升完全不是原型阶段应该关心的问题。系统架构、优化，都应该放到一边。

不要追求完美的计划

产品是在不断的迭代中完成的。

犯的一个错误是：

一直想要完成一个“完美”的脚本，而试图完成一个“完美”的大纲

但是，何为完美？当前在技术上是否有实现的可能性？这些都没有考虑。

实际开始做发现：应该先将基础的部分做好。然后在其基础上看是否需要优化表现。

在实际操作之前我们能考虑到的东西都是有偏颇的，尤其是产品本身连个影子都没有的时候。很多一开始考虑的东西到最后或许会变成过度设计。

所以或许计划需要完备，多考虑可能会失败的地方。但是计划不要完美，完美就是不考虑任何错漏的地方，那是不可能的。

实际做的时候会遇到的困难只有实际做的时候才会发现，计划时需要多保留余地，而不是追求完美。

实际操作后的感想：开始作之后发现需要解决的问题完全是不同方面的…………

其实这边是对缓存的笔记的重新合并，主要是为了梳理一下自己的思路。

因此前后可能没有逻辑关系。