Project1

标题: 由Roll A Ball进行扩展的游戏策划 [打印本页]

作者: 唯道集虚    时间: 2016-8-3 23:31
标题: 由Roll A Ball进行扩展的游戏策划
这本来是手头的一个无聊之作,本来是用Unity制作的。但想了想,毕竟是策划,都是通用的。我也就在6R做些交流了。发布出来灌灌废水集思广益也是不错的。只是给新手做参考的一篇小文章。


普及

什么是Unity?
Unity是一个可以用于多平台多领域的游戏开发引擎。是全国最热门的游戏开发工具。但在个人看来,关键是在思路。开发工具并不重要,
什么是Roll A Ball?
Roll A Ball是一个Unity官方最简单的一个案例游戏。由玩家控制一个小球滚动并吃掉所有食物、显示胜利界面。算是Unity开发者的“HelloWorld”之作。




正文

        对于这个游戏,完全是一个用于新手的存在。本身没有什么游戏性,甚至不值得被称作“游戏”。但是,我还是希望把这个作品融入自己的创意。由于现在技术有限,所有后文的想法与技术相呼应,以可行性为先,算是一个简单的策划案了。同时,为了文章兼容性,这里不讨论技术,只讨论策划。
        当我做完了这个Roll A Ball简单范例之后,我开始想在原游戏的基础上进行扩展。扩展之后的游戏以下简称RABP(Roll A Ball Plus).
        RABP是一个收集类游戏。在一个关卡中,收集所有的“能量”,即可通关。而其唯一的难度就是找寻“能量”。这时,游戏本身的游戏性并没有太多。所以,我计划通过“敌人”的形式来改变这一现状。
        当主角去收集“能量”时,主角需要不断地进行移动。而物理系统为我提供了惯性。而主角一旦不小心撞上了“敌人”,就会损失掉一个生命值。主角初始只有一个生命值,生命值可以通过收集“能量”来进行补充。全部毁掉了之后就无法继续游戏了。游戏将会出现失败相关的GUI。
        “敌人”的存在无疑加大了游戏的游戏性。但由于生命值的设定问题,整体游戏性还是偏低。但还有另一个因素:移动的敌人。
        所谓“移动的敌人“并不是”随机“进行移动,而是在一定范围内移动。将关卡中的敌人设定为按照一定路径进行移动。这样一方面减少了游戏BUG的可能性,另一方面还可以通过一些精妙的移动轨迹设计提升难度,必要时候还可以以此来使玩家强行扣除生命值。
        游戏建模采用体素,制作成本低,无需授权。所谓的体素,就是“立体的像素”,类似于《记忆碑谷》《劳拉GO》等游戏都是采用体素建模的。我专注于写脚本,没有太大精力去设计关卡,这也就成为了最合适的。
        游戏的通关是以成功完成所有关卡为准的。游戏没有存档的设定,且游戏流程很快。游戏通关后可以获得一些永久性质的周边奖励。
        这无疑不是一个标准的游戏策划案。只是为了给大家提供一个”关卡“游戏的思路。

       
作者: ⑨姐姐    时间: 2016-8-4 12:34
从“关卡”的角度,有一些问题可以继续深入地探讨一下:

· 系统设计为关卡提供了足够大的空间吗?也就是说,在新要素有限的前提下(比如核心机制+1种敌人),能够有多少变化的关卡设计方式,还是会让玩家觉得玩法都差不多,大同小异?在玩家已经习惯旧要素的时候,加入新要素,能不能真正给人带来新鲜感?甚至说,如果采用“新要素爆发”的设计方式,在设计要素的时候是不是有足够的广度,还是会受到系统机制的各种制约?

· 这样的设计和其他游戏不同在哪里?重力影响下的平衡球滚动,和收集过关的流程机制,都在不少游戏里能看到身影。这两者互相结合,能不能创造出新的设计方向?有的时候,一个关卡设计,是不是甚至还不如不加入重力的要素,直接作为平面过关的关卡来使用?

· 有没有什么细节设计的点子?比如,敌人“按照一定路径移动”这句话本身有些单调,可以具体展开如:
> 山猫:在同一层上以圆形轨迹运动一周,然后跳到上一层或下一层,继续以圆形轨迹运动一周。作为一种标准的敌人而存在,但比同层的往复轨迹更加有趣味性,适用于开阔的地形。
> 石像鬼:间隔性地运动与停止,运动时缓慢接近玩家,停止时没有伤害判定。多个同时存在时用来封锁玩家的移动,增加时间压力;单个存在时可以作为可移动的物理障碍利用。

另外两个小概念:
收集类游戏我以往接触的概念中指的是 这种这种 ,和过关类的游戏有点区别……

体素一般指的是 这种这种 ,楼主提到的风格一般叫做 low poly
作者: 唯道集虚    时间: 2016-8-4 14:48
本帖最后由 唯道集虚 于 2016-8-4 15:20 编辑
⑨姐姐 发表于 2016-8-4 12:34
从“关卡”的角度,有一些问题可以继续深入地探讨一下:

· 系统设计为关卡提供了足够大的空间吗?也就是 ...


先对于概念问题解释一下:
这本是一个偏基础向的帖子,所以我就没有太注意场景建模方面的叙述。
但事实上,low poly本身是一个比较大的概念。而体素与Low Poly之间的关系有很多说法,有人说Low Poly属于体素,有人说体素属于Low Poly。不得不说,两者是不同的。但就从概念而言,说其两者是继承关系也未尝不可。Low Poly本身的概念很难一句话说清楚,我就以体素来描述了。
而事实上,我的游戏是体素+Low Poly两种形式相结合的。体素建模成本较低,我使用的是MagicaVoxel。而Low Poly更多是一种点缀。
为了迎合论坛中大多都是使用RM制作平面游戏的朋友,我并没有详细叙述游戏的细节。事实上,游戏同时有三个相机——远景、近景、Main。
远景,是以层叠的体素为主,这样可以充实游戏的背景画面。
近景,是以简单的Low Poly为主,包括一些石头、球。为了玩家的聚焦,灯光较暗,元素较少。
由于Low Poly本身的特性,这些建模也相对简单,能够在较短的时间完成。
Main,就是主相机了。
这本身可能会因混搭而不和谐。但再不济,将近景完全改成黑色,在游戏屏幕的下方放置一些GUI。

其次就是确实有一个概念错误。这不属于传统的收集类游戏。
私不打算将游戏地图全开放,玩家算是要跟着地图走。剧情上是收集能量,但主要的挑战还是途中的敌人。
这从某种程度上来讲,是一个节奏加快的“劳拉GO”。敌人路径、速度不变,碰到之后就会扣除生命。只不过与之不同的是,玩家可以控制游戏人物的速度。一个游戏引擎内置的Rigidbody组件再加上敌人的设计,就可以让难度提升很多。

至于关卡问题,其中的“新元素”,个人以为是可以加入的。但目前为止,时机尚不成熟。
“Super Meat Boy”全程无所谓的“新元素”。
然而如果想达到这种境界,是需要一个很好的关卡设计师的。我可以写组件,做模板,以及基础的美术@轩辕大将军 工作。但这种“关卡设计”,在下是没有太多基础的。而相信作为一个开发流程短、适合新手的小型独立游戏项目,想要有一些精妙的关卡设计,是几乎不可能的。
所以,我对这个项目的定位是:“游戏的通关是以成功完成所有关卡为准的。游戏没有存档的设定,且游戏流程很快。”
这无疑是一个很糟糕的设定。
但为了游戏的“精”,我不得不牺牲掉一些元素。毕竟光是Low Ponly,就不应全程只是那几个模型。
如果这是一个20min流程的独立游戏,但游戏细节到位,体验良好,也未尝不可。
在很短的游戏流程中,也就没必要再加入新的元素了。
只要保持游戏的“精品”属性,短一些,也没什么——毕竟论坛中很少有人是全职游戏开发者的。

至于细节设计,感觉确实有待加强。

并且感谢你的回复和建议。





欢迎光临 Project1 (https://rpg.blue/) Powered by Discuz! X3.1