[{"data":1,"prerenderedAt":179},["ShallowReactive",2],{"\u002F2022-09-20-log-of-fail":3},{"id":4,"title":5,"body":6,"date":164,"description":12,"extension":165,"meta":166,"navigation":172,"path":173,"seo":174,"stem":175,"tags":176,"__hash__":178},"blogs\u002F_legacy\u002F2022\u002F2022-09-20-log-of-fail.md"," 失败记录",{"type":7,"value":8,"toc":152},"minimark",[9,13,17,20,23,29,34,37,40,43,46,50,53,62,65,68,71,74,77,80,83,86,89,92,95,98,101,104,107,110,113,116,119,127,130,133,136,139,142,146,149],[10,11,12],"p",{},"失败记录，希望下次是成功记录。",[14,15,16],"h2",{"id":16},"产品与市场",[10,18,19],{},"前面很长一段时间都在纠结叙事、玩法设计，但是总有种在原地转圈的感觉。因为游戏不是几天就能做成的，可能一开始觉得很棒的主意，后面却变得不是那么有趣了。",[10,21,22],{},"最近偶然看《Start small, Stay small》，感觉有受到一些启发",[24,25,26],"blockquote",{},[10,27,28],{},"Product Last. Marketing First.",[24,30,31],{},[10,32,33],{},"Market comes first, marketing second, aeshetic third, and functionality a distant fourth.",[10,35,36],{},"首先要思考的是，这个游戏是面向什么类型的玩家的。",[10,38,39],{},"放到Steam上的游戏和放到Switch上的游戏，其玩家群体会差别很大。",[10,41,42],{},"《魔女之家》和《零》，虽然可以都算作恐怖游戏，其面对的玩家群体却不见得完全相同。",[10,44,45],{},"没有一个目标市场就很难对产品进行定义，没有产品定义就很难形成企划。在企划形成前纠结叙事与玩法的设计是非常没有意义的。毕竟，有的游戏类型完全不需要叙事，有的则相反。产品没有定义会导致想法失控，各种各样的想法都觉得不错，都想放进来。最终使得项目变成一个四不像，连自己都看不下去。",[47,48,49],"h3",{"id":49},"定位",[10,51,52],{},"前几天看到的GDC演讲里，有大佬介绍自己是如何做出一些决策的。",[10,54,55],{},[56,57,61],"a",{"href":58,"rel":59},"https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=YaUdstkv1RE",[60],"nofollow","GDC-# Solo Development: Myths, Reality and Survival Strategies",[10,63,64],{},"感觉最好的方法，就是首先找到一个现有的成熟的产品类型，然后在这个类目内的设计上做简单的修改或者叠加。",[10,66,67],{},"一次想要做很多事情，更容易导致失控。",[47,69,70],{"id":70},"招募",[10,72,73],{},"前段有尝试自己进行一些网上的招募，感觉挺失败的。",[10,75,76],{},"总结下，除非有明确的商业计划，不要招募。",[10,78,79],{},"但是实际上，有明确商业计划的情况下，更好的选择是进行外包。",[10,81,82],{},"否则需要花费大量的时间去与人沟通，如果自己的商业目标都不明确，就更难说服别人参与进来。尤其是这边目前每天的时间非常有限，更加难以与其他人同步状态。",[14,84,85],{"id":85},"原型",[10,87,88],{},"原型很重要，任何想法要首先完成Prototype来验证是否真的好玩。",[10,90,91],{},"由于平时程序的习惯太重了，会想着找出实现玩法需要做的工作，然后就开始推进了。由于平时不是很有时间，会演变成花了很多时间最后却不觉得玩法有趣的情况。",[10,93,94],{},"有的时候为了弥补沉没成本，会想着如何添加新的东西进去挽救下，导致情况越来越糟糕。",[10,96,97],{},"做原型的话，就只要把最核心的部分做出来就可以了。",[10,99,100],{},"验证玩法有趣再推进才是正确的做法。一些细节的部分，就算做出来了，如果玩法本身没有什么有趣的部分，最后就只是在浪费时间而已。",[10,102,103],{},"比如存檔系統，如果要在設計不明瞭的情況下，兼容所有情況的可恢復性的話，會變得很複雜。",[10,105,106],{},"对于优化也是一样，过度的优化是没有意义的。在原型完成，确定要继续推进之后再优化也不迟。组件的性能提升完全不是原型阶段应该关心的问题。系统架构、优化，都应该放到一边。",[14,108,109],{"id":109},"避免过度计划",[10,111,112],{},"不要追求完美的计划",[10,114,115],{},"产品是在不断的迭代中完成的。",[10,117,118],{},"犯的一个错误是：",[24,120,121,124],{},[10,122,123],{},"一直想要完成一个“完美”的脚本，而试图完成一个“完美”的大纲",[10,125,126],{},"但是，何为完美？当前在技术上是否有实现的可能性？这些都没有考虑。",[10,128,129],{},"实际开始做发现：应该先将基础的部分做好。然后在其基础上看是否需要优化表现。",[10,131,132],{},"在实际操作之前我们能考虑到的东西都是有偏颇的，尤其是产品本身连个影子都没有的时候。很多一开始考虑的东西到最后或许会变成过度设计。",[10,134,135],{},"所以或许计划需要完备，多考虑可能会失败的地方。但是计划不要完美，完美就是不考虑任何错漏的地方，那是不可能的。",[10,137,138],{},"实际做的时候会遇到的困难只有实际做的时候才会发现，计划时需要多保留余地，而不是追求完美。",[10,140,141],{},"实际操作后的感想：开始作之后发现需要解决的问题完全是不同方面的…………",[14,143,145],{"id":144},"summary","Summary",[10,147,148],{},"其实这边是对缓存的笔记的重新合并，主要是为了梳理一下自己的思路。",[10,150,151],{},"因此前后可能没有逻辑关系。",{"title":153,"searchDepth":154,"depth":155,"links":156},"",2,3,[157,161,162,163],{"id":16,"depth":154,"text":16,"children":158},[159,160],{"id":49,"depth":155,"text":49},{"id":70,"depth":155,"text":70},{"id":85,"depth":154,"text":85},{"id":109,"depth":154,"text":109},{"id":144,"depth":154,"text":145},"2022-09-20","md",{"layout":167,"excerpt":168},"post",{"type":7,"value":169},[170],[10,171,12],{},true,"\u002F2022-09-20-log-of-fail",{"title":5,"description":12},"_legacy\u002F2022\u002F2022-09-20-log-of-fail",[177],"narrative","FzYUgYfJnnE98VaWxtjDFiVPOc-HWcClK9H22tuYyis",1788763177015]