开发日志1——主题讨论与游戏设计

精华2025/10/13132 浏览综合
曾经的聚光灯战士又回到了这片古战场,这次依旧只有全能程序和摸鱼策划,本次比赛势要贯彻鱼群触感的教旨摸鱼到底,各位敬请见证。
初看“BUG?”这个主标题(后来发现是可去除的副标题,此乃后话),程序陷入能大干一场的狂喜之中,而策划则陷入能免于写策划案能狠狠摸鱼的狂喜之中。经过一通讨论有关基础层面的bug如何设计进游戏中后(策划只在听),咱们才在狂喜的余韵中缓过劲来,开始审视“BUG?”下面的那句附加条件“你确定这不是BUG吗?”(后来发现是关键,此乃后话)。
不难理解,这句话的发问者是玩家。而能让玩家如此发问的对象自然是游戏中某种很像bug的机制。有了这一层理解,咱们程序和策划又各端出了一份策划案,不过策划的策划案在程序的一顿痛批和工期易爆的严重警告后惨烈退场。
随后,围绕句子里所要求展示的“bug”,咱们二人就究竟是该藏好等待玩家发现还是引导让玩家有意识地挖掘这些bug机制展开了长达数小时激烈的辩论战。理论上在这样一个短的游戏时间里,能让玩家怀疑究竟是bug还是机制实际只有一两次机会,玩家遇的多了只要不傻都能意识到;而要是纠结在这一两次机会又会在游戏的整体上失去重点甚至可能被判定为脱离主题。于是咱们释怀了,大概其实根本不用想那么多,只要这次的机制看起来像常规游戏的bug就行了吧。接着敲定采用了程序的策划案。但就在程序准备着手他对开发层面bug的游戏机制大力改造时,意外陡生:咱们原本以为的主标题——没了。
TapTap
请输入文字
大概是被上一年的Light误导到,群友们大多都有被误导到,霎时间哀鸿遍野。咱们虽然考虑到了这句话,不过从来没把它当重点来,原本想好的基础bug设计也不得不更改成更为接近玩家思考模式的形式,对此程序深感遗憾。
以下是程序大大的发言:
——————————
讨论过程中,一共毙掉了多个方案,一开始打算整些硬核的题材,考虑到“bug也是有逻辑的,不是凭空出现的”,我们打算从电脑程序中bug发生的机制入手作为玩法,让玩家在游戏中运用诸如缓冲区溢出,内存泄漏,线程竞争和饥饿,死锁等令程序员红温的bug,一步步攻破模拟程序。交流过程中程序不得不时不时的补充诸如“这个bug是这么产生的”这类信息,因此考虑到巨大的理解成本,毙掉第一版方案。
鱼群触感还尝试替换发问的主体,从“玩家问”,“你确定这不是bug吗”变成“开发者问”,制作一款反驳同行开发者质疑,狡辩“这就是特性不是bug”的游戏。但很可惜讨论过程中发现玩法变得更像无厘头风格的视觉小说,推理元素要融合较为生硬,这对游戏表现力就提出了更高要求,对于没有美术的鱼群触感来说,就被直接pass了。
最后还是决定回归本源,抓住仅有一两次的窗口期,让玩家体验到“bug感”。由于鱼群触感全员车车人,就打算以弹幕游戏作为主要承载内容的基础玩法。至于鱼群触感打算如何营造bug感,就先买个关子啦~
TapTap
另:超绝2小时接近100的消息
10
1
9