Update from Sync Service
This commit is contained in:
FNS Service
Vendored
+3
@@ -0,0 +1,3 @@
|
|||||||
|
{
|
||||||
|
"cssTheme": "AnuPpuccin"
|
||||||
|
}
|
||||||
Vendored
+22
@@ -0,0 +1,22 @@
|
|||||||
|
[
|
||||||
|
"obsidian42-brat",
|
||||||
|
"fast-note-sync",
|
||||||
|
"obsidian-excalidraw-plugin",
|
||||||
|
"templater-obsidian",
|
||||||
|
"dataview",
|
||||||
|
"obsidian-tasks-plugin",
|
||||||
|
"cmdr",
|
||||||
|
"calendar",
|
||||||
|
"easy-typing-obsidian",
|
||||||
|
"obsidian-hider",
|
||||||
|
"obsidian-hover-editor",
|
||||||
|
"obsidian-outliner",
|
||||||
|
"obsidian-style-settings",
|
||||||
|
"obsidian-another-quick-switcher",
|
||||||
|
"table-editor-obsidian",
|
||||||
|
"apex-dashboard",
|
||||||
|
"obsidian-annotator",
|
||||||
|
"obsidian-epub-plugin",
|
||||||
|
"obsidian-shellcommands",
|
||||||
|
"obsidian-custom-file-extensions-plugin"
|
||||||
|
]
|
||||||
@@ -1,51 +0,0 @@
|
|||||||
---
|
|
||||||
dashboard: true
|
|
||||||
banner:
|
|
||||||
quote: "The mind is everything. What you think you become."
|
|
||||||
author: "Buddha"
|
|
||||||
columns:
|
|
||||||
- name: Memo
|
|
||||||
color: "#f59e0b"
|
|
||||||
type: memo
|
|
||||||
- name: Todo
|
|
||||||
color: "#6366f1"
|
|
||||||
type: todo
|
|
||||||
- name: Projects
|
|
||||||
color: "#10b981"
|
|
||||||
type: projects
|
|
||||||
- name: Library
|
|
||||||
color: "#8b5cf6"
|
|
||||||
type: projects
|
|
||||||
---
|
|
||||||
|
|
||||||
## Memo
|
|
||||||
|
|
||||||
### 2026-05-27 memo
|
|
||||||
id: demo-memo-1
|
|
||||||
Welcome to Apex Dashboard! Click here to edit your first memo.
|
|
||||||
|
|
||||||
## Todo
|
|
||||||
|
|
||||||
### Getting Started
|
|
||||||
id: demo-todo-1
|
|
||||||
type: task
|
|
||||||
|
|
||||||
## Projects
|
|
||||||
|
|
||||||
### My First Project
|
|
||||||
id: demo-project-1
|
|
||||||
type: project
|
|
||||||
|
|
||||||
## Library
|
|
||||||
|
|
||||||
### Reading
|
|
||||||
id: demo-lib-reading
|
|
||||||
type: project
|
|
||||||
|
|
||||||
### To Read
|
|
||||||
id: demo-lib-toread
|
|
||||||
type: project
|
|
||||||
|
|
||||||
### Done
|
|
||||||
id: demo-lib-done
|
|
||||||
type: project
|
|
||||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
@@ -0,0 +1,10 @@
|
|||||||
|
~~要不就和小丑牌一样，工厂作为小丑，物流作为出牌顺序来做结算。这样是一种鼓励机制，应该能间接做到~~
|
||||||
|
https://mp.weixin.qq.com/s/LkumENVh_iCVQoI0tMTz8Q
|
||||||
|
https://mp.weixin.qq.com/s/n-9CPcDzeN2fJvm7v3OKhg
|
||||||
|
https://mp.weixin.qq.com/s/kkbaKMMuzsZZbrSQf3dfcw
|
||||||
|
https://mp.weixin.qq.com/s/6wyutmADx_2zDbdXXwOcww
|
||||||
|
拆解吸血鬼爬行者
|
||||||
|
https://mp.weixin.qq.com/s/bf4sY8YzywMYgJJqlS93OA
|
||||||
|
自我决定理论
|
||||||
|
【让游戏机制增加深度的方法-哔哩哔哩】 https://b23.tv/LBBka7n
|
||||||
|
预测玩家将如何理解你的游戏，以及他们如何与游戏互动，至关重要。
|
||||||
@@ -0,0 +1,472 @@
|
|||||||
|
<!DOCTYPE html>
|
||||||
|
<html lang="zh-CN">
|
||||||
|
<head>
|
||||||
|
<meta charset="utf-8">
|
||||||
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||||
|
<title>《范式：起源》立体交互体验拆解</title>
|
||||||
|
<style>
|
||||||
|
:root {
|
||||||
|
--paper: #ffffff;
|
||||||
|
--ink: #161616;
|
||||||
|
--muted: #6f6f6f;
|
||||||
|
--line: #d7d0c1;
|
||||||
|
--accent: #ad8d4b;
|
||||||
|
--bg: #e9e6df;
|
||||||
|
--shadow: 0 18px 40px rgba(0, 0, 0, 0.12);
|
||||||
|
}
|
||||||
|
|
||||||
|
* {
|
||||||
|
box-sizing: border-box;
|
||||||
|
}
|
||||||
|
|
||||||
|
body {
|
||||||
|
margin: 0;
|
||||||
|
background:
|
||||||
|
radial-gradient(circle at top left, rgba(255,255,255,0.8), transparent 28%),
|
||||||
|
linear-gradient(180deg, #f2efe8 0%, var(--bg) 100%);
|
||||||
|
color: var(--ink);
|
||||||
|
font-family: "Source Han Serif SC", "Noto Serif SC", "Songti SC", "SimSun", serif;
|
||||||
|
line-height: 1.85;
|
||||||
|
}
|
||||||
|
|
||||||
|
.document {
|
||||||
|
padding: 32px 16px 72px;
|
||||||
|
}
|
||||||
|
|
||||||
|
.page {
|
||||||
|
width: min(210mm, calc(100vw - 32px));
|
||||||
|
min-height: 297mm;
|
||||||
|
margin: 0 auto 24px;
|
||||||
|
background: var(--paper);
|
||||||
|
box-shadow: var(--shadow);
|
||||||
|
position: relative;
|
||||||
|
overflow: hidden;
|
||||||
|
}
|
||||||
|
|
||||||
|
.page::before {
|
||||||
|
content: "";
|
||||||
|
position: absolute;
|
||||||
|
inset: 0;
|
||||||
|
border: 1px solid rgba(0, 0, 0, 0.06);
|
||||||
|
pointer-events: none;
|
||||||
|
}
|
||||||
|
|
||||||
|
.page-inner {
|
||||||
|
padding: 24mm 21mm 24mm;
|
||||||
|
position: relative;
|
||||||
|
z-index: 1;
|
||||||
|
}
|
||||||
|
|
||||||
|
.cover {
|
||||||
|
display: flex;
|
||||||
|
align-items: center;
|
||||||
|
justify-content: center;
|
||||||
|
background:
|
||||||
|
linear-gradient(135deg, rgba(173,141,75,0.09), transparent 30%),
|
||||||
|
linear-gradient(0deg, rgba(0,0,0,0.02), rgba(0,0,0,0.02));
|
||||||
|
}
|
||||||
|
|
||||||
|
.cover .page-inner {
|
||||||
|
width: 100%;
|
||||||
|
text-align: center;
|
||||||
|
padding-top: 30%;
|
||||||
|
}
|
||||||
|
|
||||||
|
.report-title {
|
||||||
|
font-size: clamp(28px, 3.4vw, 34px);
|
||||||
|
font-weight: 700;
|
||||||
|
letter-spacing: 0.08em;
|
||||||
|
margin: 0 0 20px;
|
||||||
|
}
|
||||||
|
|
||||||
|
.report-meta {
|
||||||
|
color: var(--muted);
|
||||||
|
font-size: 14px;
|
||||||
|
letter-spacing: 0.08em;
|
||||||
|
margin: 8px 0;
|
||||||
|
}
|
||||||
|
|
||||||
|
.toc-title {
|
||||||
|
font-size: 24px;
|
||||||
|
margin: 0 0 24px;
|
||||||
|
letter-spacing: 0.08em;
|
||||||
|
}
|
||||||
|
|
||||||
|
.toc-list {
|
||||||
|
list-style: none;
|
||||||
|
padding: 0;
|
||||||
|
margin: 0;
|
||||||
|
}
|
||||||
|
|
||||||
|
.toc-list li + li {
|
||||||
|
margin-top: 10px;
|
||||||
|
}
|
||||||
|
|
||||||
|
.toc-list a {
|
||||||
|
color: inherit;
|
||||||
|
text-decoration: none;
|
||||||
|
display: flex;
|
||||||
|
align-items: baseline;
|
||||||
|
gap: 10px;
|
||||||
|
font-size: 15px;
|
||||||
|
}
|
||||||
|
|
||||||
|
.toc-label {
|
||||||
|
white-space: nowrap;
|
||||||
|
}
|
||||||
|
|
||||||
|
.toc-leader {
|
||||||
|
flex: 1;
|
||||||
|
border-bottom: 1px dotted rgba(0, 0, 0, 0.35);
|
||||||
|
transform: translateY(-4px);
|
||||||
|
}
|
||||||
|
|
||||||
|
.toc-page {
|
||||||
|
width: 24px;
|
||||||
|
text-align: right;
|
||||||
|
color: var(--muted);
|
||||||
|
}
|
||||||
|
|
||||||
|
h2 {
|
||||||
|
font-size: 28px;
|
||||||
|
margin: 0 0 24px;
|
||||||
|
padding-bottom: 12px;
|
||||||
|
border-bottom: 2px solid var(--line);
|
||||||
|
letter-spacing: 0.04em;
|
||||||
|
}
|
||||||
|
|
||||||
|
h3 {
|
||||||
|
font-size: 21px;
|
||||||
|
margin: 32px 0 14px;
|
||||||
|
letter-spacing: 0.03em;
|
||||||
|
}
|
||||||
|
|
||||||
|
h4 {
|
||||||
|
font-size: 17px;
|
||||||
|
margin: 24px 0 10px;
|
||||||
|
color: #3b3429;
|
||||||
|
}
|
||||||
|
|
||||||
|
p {
|
||||||
|
margin: 12px 0;
|
||||||
|
text-align: justify;
|
||||||
|
font-size: 15px;
|
||||||
|
}
|
||||||
|
|
||||||
|
.list-block ul,
|
||||||
|
.list-block ol {
|
||||||
|
margin: 10px 0 14px 24px;
|
||||||
|
padding-left: 16px;
|
||||||
|
}
|
||||||
|
|
||||||
|
.list-block li {
|
||||||
|
margin: 6px 0;
|
||||||
|
font-size: 15px;
|
||||||
|
}
|
||||||
|
|
||||||
|
.figure-block {
|
||||||
|
margin: 18px 0 20px;
|
||||||
|
}
|
||||||
|
|
||||||
|
.gallery {
|
||||||
|
display: grid;
|
||||||
|
gap: 12px;
|
||||||
|
align-items: start;
|
||||||
|
}
|
||||||
|
|
||||||
|
.gallery-1 {
|
||||||
|
grid-template-columns: 1fr;
|
||||||
|
max-width: 560px;
|
||||||
|
margin: 0 auto;
|
||||||
|
}
|
||||||
|
|
||||||
|
.gallery-2,
|
||||||
|
.gallery-3,
|
||||||
|
.gallery-4 {
|
||||||
|
grid-template-columns: repeat(auto-fit, minmax(180px, 1fr));
|
||||||
|
}
|
||||||
|
|
||||||
|
.gallery-item {
|
||||||
|
background: #f8f7f4;
|
||||||
|
padding: 10px;
|
||||||
|
border: 1px solid rgba(0, 0, 0, 0.07);
|
||||||
|
box-shadow: 0 8px 16px rgba(0,0,0,0.06);
|
||||||
|
}
|
||||||
|
|
||||||
|
.gallery-item.single {
|
||||||
|
padding: 12px;
|
||||||
|
}
|
||||||
|
|
||||||
|
.gallery img {
|
||||||
|
display: block;
|
||||||
|
width: 100%;
|
||||||
|
height: auto;
|
||||||
|
}
|
||||||
|
|
||||||
|
.figure-caption {
|
||||||
|
margin-top: 10px;
|
||||||
|
color: var(--muted);
|
||||||
|
font-size: 13px;
|
||||||
|
text-align: center;
|
||||||
|
}
|
||||||
|
|
||||||
|
.figure-caption.split {
|
||||||
|
display: flex;
|
||||||
|
justify-content: space-around;
|
||||||
|
gap: 12px;
|
||||||
|
}
|
||||||
|
|
||||||
|
.todo {
|
||||||
|
margin: 14px 0;
|
||||||
|
padding: 10px 14px;
|
||||||
|
border-left: 4px solid var(--accent);
|
||||||
|
background: rgba(173, 141, 75, 0.08);
|
||||||
|
color: #5d4b22;
|
||||||
|
font-size: 14px;
|
||||||
|
}
|
||||||
|
|
||||||
|
a {
|
||||||
|
color: #275d9c;
|
||||||
|
text-decoration: none;
|
||||||
|
}
|
||||||
|
|
||||||
|
a:hover {
|
||||||
|
text-decoration: underline;
|
||||||
|
}
|
||||||
|
|
||||||
|
.page-number {
|
||||||
|
position: absolute;
|
||||||
|
right: 21mm;
|
||||||
|
bottom: 12mm;
|
||||||
|
color: var(--muted);
|
||||||
|
font-size: 12px;
|
||||||
|
letter-spacing: 0.1em;
|
||||||
|
}
|
||||||
|
|
||||||
|
@media print {
|
||||||
|
body {
|
||||||
|
background: #fff;
|
||||||
|
}
|
||||||
|
|
||||||
|
.document {
|
||||||
|
padding: 0;
|
||||||
|
}
|
||||||
|
|
||||||
|
.page {
|
||||||
|
width: 210mm;
|
||||||
|
min-height: 297mm;
|
||||||
|
margin: 0;
|
||||||
|
box-shadow: none;
|
||||||
|
break-after: page;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
</style>
|
||||||
|
</head>
|
||||||
|
<body>
|
||||||
|
<main class="document">
|
||||||
|
<section class="page cover">
|
||||||
|
<div class="page-inner">
|
||||||
|
<h1 class="report-title">《范式：起源》立体交互体验拆解</h1>
|
||||||
|
<p class="report-meta">作者：孙玉杰</p>
|
||||||
|
<p class="report-meta">文档版本：26/1/30</p>
|
||||||
|
</div>
|
||||||
|
<div class="page-number">01</div>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section class="page toc-page">
|
||||||
|
<div class="page-inner">
|
||||||
|
<h2 class="toc-title">目录</h2>
|
||||||
|
<ol class="toc-list">
|
||||||
|
<li><a href="#前言"><span class="toc-label">前言</span><span class="toc-leader"></span><span class="toc-page">3</span></a></li>
|
||||||
|
<li><a href="#游戏玩法机制简述"><span class="toc-label">游戏玩法机制简述</span><span class="toc-leader"></span><span class="toc-page">3</span></a></li>
|
||||||
|
<li><a href="#操作交互设计"><span class="toc-label">操作交互设计</span><span class="toc-leader"></span><span class="toc-page">3</span></a></li>
|
||||||
|
<li><a href="#物件交互设计"><span class="toc-label">物件交互设计</span><span class="toc-leader"></span><span class="toc-page">4</span></a></li>
|
||||||
|
<li><a href="#交互模式优势与代价与解决方案"><span class="toc-label">交互模式优势与代价与解决方案</span><span class="toc-leader"></span><span class="toc-page">4</span></a></li>
|
||||||
|
<li><a href="#视听反馈设计拆解"><span class="toc-label">视听反馈设计拆解</span><span class="toc-leader"></span><span class="toc-page">7</span></a></li>
|
||||||
|
<li><a href="#瞬间响应"><span class="toc-label">瞬间响应</span><span class="toc-leader"></span><span class="toc-page">7</span></a></li>
|
||||||
|
<li><a href="#确认与引导"><span class="toc-label">确认与引导</span><span class="toc-leader"></span><span class="toc-page">7</span></a></li>
|
||||||
|
<li><a href="#视觉避让"><span class="toc-label">视觉避让</span><span class="toc-leader"></span><span class="toc-page">8</span></a></li>
|
||||||
|
<li><a href="#深度感知的视觉补偿"><span class="toc-label">深度感知的视觉补偿</span><span class="toc-leader"></span><span class="toc-page">9</span></a></li>
|
||||||
|
<li><a href="#动画编排"><span class="toc-label">动画编排</span><span class="toc-leader"></span><span class="toc-page">9</span></a></li>
|
||||||
|
<li><a href="#音效设计"><span class="toc-label">音效设计</span><span class="toc-leader"></span><span class="toc-page">10</span></a></li>
|
||||||
|
<li><a href="#判定逻辑设计拆解"><span class="toc-label">判定逻辑设计拆解</span><span class="toc-leader"></span><span class="toc-page">11</span></a></li>
|
||||||
|
<li><a href="#判定窗口"><span class="toc-label">判定窗口</span><span class="toc-leader"></span><span class="toc-page">11</span></a></li>
|
||||||
|
<li><a href="#判定容错"><span class="toc-label">判定容错</span><span class="toc-leader"></span><span class="toc-page">11</span></a></li>
|
||||||
|
<li><a href="#生存压力"><span class="toc-label">生存压力</span><span class="toc-leader"></span><span class="toc-page">12</span></a></li>
|
||||||
|
<li><a href="#谱面设计拆解"><span class="toc-label">谱面设计拆解</span><span class="toc-leader"></span><span class="toc-page">12</span></a></li>
|
||||||
|
<li><a href="#手序引导"><span class="toc-label">手序引导</span><span class="toc-leader"></span><span class="toc-page">12</span></a></li>
|
||||||
|
<li><a href="#键型设计"><span class="toc-label">键型设计</span><span class="toc-leader"></span><span class="toc-page">14</span></a></li>
|
||||||
|
<li><a href="#总结"><span class="toc-label">总结</span><span class="toc-leader"></span><span class="toc-page">15</span></a></li>
|
||||||
|
<li><a href="#引用"><span class="toc-label">引用</span><span class="toc-leader"></span><span class="toc-page">16</span></a></li>
|
||||||
|
</ol>
|
||||||
|
</div>
|
||||||
|
<div class="page-number">02</div>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
|
||||||
|
<section class="page content-page">
|
||||||
|
<div class="page-inner">
|
||||||
|
<h2 id="前言">前言</h2>
|
||||||
|
<p>本文档旨在探讨《范式：起源》的立体交互机制。通过分析其设计逻辑、感官反馈、优势与代价，解析这套设计如何塑造了空间立体感，以及如何以对视听、判定以及内容进行设计在立体交互基础上实现了对手感体验的调优。</p>
|
||||||
|
</div>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section class="page content-page">
|
||||||
|
<div class="page-inner">
|
||||||
|
<h2 id="游戏玩法机制简述">游戏玩法机制简述</h2>
|
||||||
|
<h3 id="操作交互设计">操作交互设计</h3>
|
||||||
|
<p>传统下落式音游的空间映射常常被限制在 X 轴（轨道）与 Y 轴（时间）构成的二维平面中进行演出和判定。</p>
|
||||||
|
<aside class="todo">TODO: a to b 表述更新</aside>
|
||||||
|
<p>然而，范式选择打破这一限制，扩展出 Z 轴表示深度，将玩家控制区域变化为 “四边 + 中心 + 深度” 的立体结构。</p>
|
||||||
|
<aside class="todo">TODO: 具象形容 伪3d效果 不要默认觉得读者了解音游</aside>
|
||||||
|
<p>范式的核心玩法要求玩家处理从屏幕中心向四周（上、下、左、右）发散的地键（Ground Note），同时也需要处理直接作用于屏幕中心的空键（Air Note）。</p>
|
||||||
|
<figure class="figure-block"><div class="gallery gallery-1"><div class="gallery-item single"><img src="附件/范式：起源 立体交互体验拆解/image1.png" alt="image1.png" loading="lazy"></div></div><figcaption class="figure-caption">上图蓝色区域为玩家四周判定区域</figcaption></figure>
|
||||||
|
<figure class="figure-block"><div class="gallery gallery-1"><div class="gallery-item single"><img src="附件/范式：起源 立体交互体验拆解/image2.png" alt="image2.png" loading="lazy"></div></div><figcaption class="figure-caption">上图橙色区域为玩家屏幕中心判定区域</figcaption></figure>
|
||||||
|
<h3 id="物件交互设计">物件交互设计</h3>
|
||||||
|
<p>游戏通过两类交互物件为玩家构建了游玩的立体感，并为二者在设计上担任不同的手感职能。</p>
|
||||||
|
<div class="list-block"><ul><li>地键（Ground Note）<ul><li>形态与手感：判定锚定在平面边缘，提供明确的上、下、左、右方位反馈。</li></ul><ul><li>设计意图：交互上对标传统下落式X/Y轴判定，手感类似于传统下落式音游，但地键分布在四周会带来更大的玩家手部位移。</li></ul></li></ul><ul><li>空键（Air Note）<ul><li>形态与手感：悬浮在轨道中空间的正方形物件，判定更多得体现在何时而不是何处，需要结合音乐节奏预判时机。</li></ul><ul><li>设计意图：引入了Z轴，建立纵深空间，与地键一起出现时一定程度上会增加读谱难度为玩家带来紧张感。手感从传统的点击转化到迎击。</li></ul></li></ul></div>
|
||||||
|
<aside class="todo">TODO: 手感差异在视觉上的表现 将主观体验转化为客观描述</aside>
|
||||||
|
<h3 id="交互模式优势与代价与解决方案">交互模式优势与代价与解决方案</h3>
|
||||||
|
<h4 id="优势">优势</h4>
|
||||||
|
<p>内容设计空间升维：</p>
|
||||||
|
<div class="list-block"><ul><li>相对于传统下落式音游，引入Z轴深度概念能够为游戏谱面设计新增维度，使设计者能够借这套机制设计一些特有的或者模拟街机音游的键型。</li></ul></div>
|
||||||
|
<p>大开大合的交互体感：</p>
|
||||||
|
<div class="list-block"><ul><li>四边判定会迫使玩家的手腕和小臂参与到位移中来，带来大出张与大位移能够让手感从手指操作转化为肢体运动。</li></ul></div>
|
||||||
|
<aside class="todo">TODO: 出张概念 以及 详细解释 越过判定中线</aside>
|
||||||
|
<h4 id="代价">代价</h4>
|
||||||
|
<p>手部遮挡：</p>
|
||||||
|
<div class="list-block"><ul><li>在手序设计不佳的情况下手指点击空键或上边缘时会遮挡一部分读谱区，人类的手不能调透明度也不能穿模。体现在极端情况下将右手引导至左区，将左手引导至右区时必然会遮挡住一部分音符，同时也可能发生双手打架的情况，这是大部分移动端音游都会产生的问题，对手机玩家手感影响更甚。</li></ul></div>
|
||||||
|
<aside class="todo">TODO: 出张的优势与代价 下部补充</aside>
|
||||||
|
<p>变速错觉：</p>
|
||||||
|
<div class="list-block"><ul><li>透视原理使音符在视觉上呈现非线性加速，导致越近越快，破坏了平面音游中距离等于时间的直观读谱逻辑。玩家必然更依赖音押而非目押，设备音频延迟的影响会被放大。</li></ul></div>
|
||||||
|
<aside class="todo">TODO: 玩家适应成本 判定确认极端 加速度下落式玩家比普通情况下更依赖音押或目押</aside>
|
||||||
|
<p>判定面的视觉模糊：</p>
|
||||||
|
<div class="list-block"><ul><li>Z轴上的判定是一个面而非一条线。尤其在玩家处理Slider时，手指在纵深方向上是否偏离轨道难以直观感知，容易产生莫名其妙的失误。</li></ul></div>
|
||||||
|
<aside class="todo">TODO: 学习成本</aside>
|
||||||
|
<h4 id="解决方案">解决方案</h4>
|
||||||
|
<p>针对变速错觉问题，范式除提供了音频延迟以及画面延迟的调整外，还提供了音符出现距离的调整，将音符出现距离拉近能够有效地缓解变速错觉问题。</p>
|
||||||
|
<p>但降低音符出现距离会缩减音符出现时长，导致影响玩家的信息接收量。降低音符出现距离的同时想要保持音符显示时长又需要提高谱面流速，会使不熟练的玩家难以反应。但其他轨道存在透视变速的音游也存在一样的问题，除提供的原理类似的上隐，只能靠玩家自己手动往轨道上方放纸条挡住变速区域，也牺牲了信息接收量。范式的降低音符出现距离帮助玩家省去了贴纸条的操作，作为系统功能来说，这是对变速错觉问题难以解决的妥协处理，业界也没有针对此问题的其他解决方案。信息接收量降低不完全是一件坏事，当同一时间大量音符出现在屏幕中时玩家会难以集中注意力去处理该点击哪个音符，信息接收量的降低能够提供一定的信息节食效果，帮助玩家集中注意力到该处理的音符上。</p>
|
||||||
|
<aside class="todo">TODO: 上隐下隐目的 信息量 思考速度与时间</aside>
|
||||||
|
<p><a href="<a href="https://www.bilibili.com/video/BV1N1NPe4E5R"" target="_blank" rel="noreferrer">https://www.bilibili.com/video/BV1N1NPe4E5R"</a> target="_blank" rel="noreferrer"><a href="https://www.bilibili.com/video/BV1N1NPe4E5R" target="_blank" rel="noreferrer">https://www.bilibili.com/video/BV1N1NPe4E5R</a></a></p>
|
||||||
|
<figure class="figure-block"><div class="gallery gallery-1"><div class="gallery-item single"><img src="附件/范式：起源 立体交互体验拆解/image3.png" alt="image3.png" loading="lazy"></div></div><figcaption class="figure-caption">音符出现距离设置项</figcaption></figure>
|
||||||
|
<p>手部遮挡问题的解决其一可以通过谱面的手序设计来绕过见后文手序引导分析，其二是为玩家提供物件大小调整项。足够大的物件能够为手机端玩家提供足够高的辨识度。同时游戏还提供了游戏区域比例来单独适配平板以及手机的显示区域。</p>
|
||||||
|
<figure class="figure-block"><div class="gallery gallery-1"><div class="gallery-item single"><img src="附件/范式：起源 立体交互体验拆解/image4.png" alt="image4.png" loading="lazy"></div></div><figcaption class="figure-caption">游戏区域比例设置项</figcaption></figure>
|
||||||
|
<figure class="figure-block"><div class="gallery gallery-2"><div class="gallery-item"><img src="附件/范式：起源 立体交互体验拆解/image5.png" alt="image5.png" loading="lazy"></div><div class="gallery-item"><img src="附件/范式：起源 立体交互体验拆解/image6.png" alt="image6.png" loading="lazy"></div></div><figcaption class="figure-caption split"><span>手机显示比例</span><span>平板显示比例</span></figcaption></figure>
|
||||||
|
<p>判定面的视觉模糊可以通过调整判定缓解，见后文判定容错。</p>
|
||||||
|
</div>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section class="page content-page">
|
||||||
|
<div class="page-inner">
|
||||||
|
<h2 id="视听反馈设计拆解">视听反馈设计拆解</h2>
|
||||||
|
<p>范式在立体交互的基础上通过视觉欺骗、音效播放延迟优化以及触控延迟的可控调整的实现，制作了干脆不粘手的反馈效果。</p>
|
||||||
|
<h3 id="瞬间响应">瞬间响应</h3>
|
||||||
|
<div class="list-block"><ul><li>表现：当玩家触发判定时，Note会在第一帧立刻消失，立刻播放判定音效，并在目标位置触发火花特效、判定线高亮特效以及判定结果文字特效。</li></ul><ul><li>设计意图：在缺乏音游设计知识的情况下可能会出现制作Note溶解动画的情况，</li></ul></div>
|
||||||
|
<aside class="todo">TODO: 游戏类型与动画解释 原因与影响 音效设计组合</aside>
|
||||||
|
<p>这会带来视觉残留导致手感拖泥带水。范式中Note触发即消失，并同时在判定目标位置生成触发特效，瞬间完成的视觉反馈以及音效的瞬间播放极大提高了操作的即时感。</p>
|
||||||
|
<figure class="figure-block"><div class="gallery gallery-2"><div class="gallery-item"><img src="附件/范式：起源 立体交互体验拆解/image7.png" alt="image7.png" loading="lazy"></div><div class="gallery-item"><img src="附件/范式：起源 立体交互体验拆解/image8.png" alt="image8.png" loading="lazy"></div></div><figcaption class="figure-caption split"><span>判定开始</span><span>特效响应</span></figcaption></figure>
|
||||||
|
<h3 id="确认与引导">确认与引导</h3>
|
||||||
|
<div class="list-block"><ul><li>表现：判定触发后，一条光流沿Z轴轨道向屏幕深处运动，同时火花向外爆开判定线高亮逐渐变暗，其中光流的颜色因玩家点击的Note的判定准度而变化。</li></ul><ul><li>设计意图：<ul><li>打击延伸：为Note点击带来向内方向释放感，光流颜色加上火花特效能够同时增强玩家的“点到了”以及“唉爆了个绿”的确认感。</li></ul><ul><li>视线重置：光流运动由近及远能够巧妙地将玩家视线从操作区重新引导回读谱区，为处理下一个Note做好准备。</li></ul></li></ul></div>
|
||||||
|
<figure class="figure-block"><div class="gallery gallery-3"><div class="gallery-item"><img src="附件/范式：起源 立体交互体验拆解/image9.png" alt="image9.png" loading="lazy"></div><div class="gallery-item"><img src="附件/范式：起源 立体交互体验拆解/image10.png" alt="image10.png" loading="lazy"></div><div class="gallery-item"><img src="附件/范式：起源 立体交互体验拆解/image11.png" alt="image11.png" loading="lazy"></div></div><figcaption class="figure-caption split"><span>特效起始</span><span>光流前进</span><span>特效消失</span></figcaption></figure>
|
||||||
|
<figure class="figure-block"><div class="gallery gallery-1"><div class="gallery-item single"><img src="附件/范式：起源 立体交互体验拆解/image12.png" alt="image12.png" loading="lazy"></div></div><figcaption class="figure-caption">非“完全解密”光流颜色以及评价文本</figcaption></figure>
|
||||||
|
<div class="list-block"><ul><li>特殊情况<ul><li>表现：当玩家在短时间内连续触发多个Note判定时，判定线会前一个Note判定结束亮度降低后但未完全恢复到不高亮接受下一个Note时重新将高亮重置到最高亮度。</li></ul></li></ul></div>
|
||||||
|
<aside class="todo">TODO: </aside>
|
||||||
|
<div class="list-block"><ul><li><ul><li>设计意图：能够隐性地在高密度环境下的近乎闪烁的高亮提示能为玩家保持快节奏状态下的火热手感。</li></ul></li></ul></div>
|
||||||
|
<figure class="figure-block"><div class="gallery gallery-3"><div class="gallery-item"><img src="附件/范式：起源 立体交互体验拆解/image13.png" alt="image13.png" loading="lazy"></div><div class="gallery-item"><img src="附件/范式：起源 立体交互体验拆解/image14.png" alt="image14.png" loading="lazy"></div><div class="gallery-item"><img src="附件/范式：起源 立体交互体验拆解/image15.png" alt="image15.png" loading="lazy"></div></div><figcaption class="figure-caption split"><span>第一个Note触发时高亮</span><span>第一个Note触发后高亮变暗</span><span>第二个Note触发后</span></figcaption></figure>
|
||||||
|
<h3 id="视觉避让">视觉避让</h3>
|
||||||
|
<div class="list-block"><ul><li>表现：评价文字在出现后并非静止消失，而是垂直轨道缓慢上移，并逐渐溶解。按住Hold时评价文字会一直叠加生成并重复上述生命周期。</li></ul><ul><li>设计意图：文字垂直轨道上移是一种抗干扰设计，为了不使文字挡住后方飞来的Note，防止文字遮挡谱面导致读谱失误。按住Hold时叠加出现的判定文字以及其特有的蓝色火花会给玩家一种“我正一直接着”的感觉。</li></ul></div>
|
||||||
|
<figure class="figure-block"><div class="gallery gallery-3"><div class="gallery-item"><img src="附件/范式：起源 立体交互体验拆解/image16.png" alt="image16.png" loading="lazy"></div><div class="gallery-item"><img src="附件/范式：起源 立体交互体验拆解/image17.png" alt="image17.png" loading="lazy"></div><div class="gallery-item"><img src="附件/范式：起源 立体交互体验拆解/image18.png" alt="image18.png" loading="lazy"></div></div><figcaption class="figure-caption split"><span>文字出现</span><span>文字上移</span><span>文字溶解</span></figcaption></figure>
|
||||||
|
<h3 id="深度感知的视觉补偿">深度感知的视觉补偿</h3>
|
||||||
|
<p>在平面上表现Z轴的会带来距离感缺失导致玩家不能够准确判断判定时机，范式除上文提到的出现距离调整项，还提供了一个巧妙的解决方案。</p>
|
||||||
|
<div class="list-block"><ul><li>表现：空键在平面目标点上映射方框，其中映射目标点内部方块随着空键靠近平面而逐渐填满外框时，即为最佳击打时机。</li></ul><ul><li>设计意图：将模糊的依赖于透视经验以及音乐节奏时机的判断转化为浮现式音游的图形重合判断。这为玩家提供了显性的、可训练的时机信号，能够极大地稳定Z轴交互的手感预期，使高密度情况下精确操作成为可能。</li></ul></div>
|
||||||
|
<aside class="todo">TODO: 回头拆一下cy2</aside>
|
||||||
|
<figure class="figure-block"><div class="gallery gallery-3"><div class="gallery-item"><img src="附件/范式：起源 立体交互体验拆解/image19.png" alt="image19.png" loading="lazy"></div><div class="gallery-item"><img src="附件/范式：起源 立体交互体验拆解/image20.png" alt="image20.png" loading="lazy"></div><div class="gallery-item"><img src="附件/范式：起源 立体交互体验拆解/image21.png" alt="image21.png" loading="lazy"></div></div><figcaption class="figure-caption split"><span>补偿图形出现</span><span>补偿图形重合</span><span>完成判定</span></figcaption></figure>
|
||||||
|
<h3 id="动画编排">动画编排</h3>
|
||||||
|
<p>经过对实机画面的逐帧逆向观测后，我发现游戏通过对判定动画设置了三条曲线构建了富有层次感的反馈体验。基于玩家视角的观测数据中光流、火花与评价文字在约27帧的生命周期内呈现出明显的能量分布差异，明显可以观察到动画节奏已经过仔细编排。</p>
|
||||||
|
<div class="list-block"><ul><li>光流<ul><li>表现：光流动画响应最快，在前4帧左右迅速到达峰值，随后立刻线性衰减。</li></ul><ul><li>设计意图：光流负责提供第一时间的触控确认。它负责快速反馈，同时快速的衰减和向Z轴深处的位移，起到将玩家视线从判定区引导回屏幕中心的作用。</li></ul></li></ul><ul><li>火花<ul><li>表现：火花动画起步爆发较快，但直到第9-10帧才达到峰值，比光流晚5帧。</li></ul><ul><li>设计意图：火花动画与光流动画峰值的时间错层除了体现游戏主题的信号的时序错位，更多的在视觉上能够提供一定的重量感。若火花和光流峰值完全同步则会使效果显得单薄，相对滞后的峰值能够为整体提供视觉上的厚度。</li></ul></li></ul><ul><li>评价文字<ul><li>表现：峰值最持久，在第7-13帧保持了长达数帧的峰值平台期，随后才开始衰减。</li></ul><ul><li>设计意图：评价文字的首要人物是传递信息，使玩家除观察光流颜色还能够在余光中凭判定文字确认判定结果。</li></ul></li></ul></div>
|
||||||
|
<h3 id="音效设计">音效设计</h3>
|
||||||
|
<div class="list-block"><ul><li>表现：范式的Note音效种类并不像其他移动端音游那么奢侈，反而所有Note全部使用一种音效，相当地克制。主观听感上音效和按动笔发出的声音一样清脆，音调又不像铃铛一样高，有一定厚度感，听感节奏也以快速爆发到线性衰减为主。</li></ul></div>
|
||||||
|
<aside class="todo">TODO: 音效音色设计意图以及视觉与音效联动 视听效果搭配会产生差异 &瞬间相应</aside>
|
||||||
|
<div class="list-block"><ul><li>设计意图：统一的音效除节省成本外还能够为玩家带来统一的确认感，同时音色不强求大高频，存在一定低频成分不会使玩家一直听到这一种音效感到枯燥。</li></ul><ul><li>缺陷：虽然音色设计使单音效足够耐听，但可以考虑学习《舞萌DX》或其他音游，为不同的判定制作不同的音效。使玩家在恰当的时机击打音符时获得更强烈的正反馈。</li></ul></div>
|
||||||
|
</div>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section class="page content-page">
|
||||||
|
<div class="page-inner">
|
||||||
|
<h2 id="判定逻辑设计拆解">判定逻辑设计拆解</h2>
|
||||||
|
<h3 id="判定窗口">判定窗口</h3>
|
||||||
|
<p>游戏内，物件有四级判定：</p>
|
||||||
|
<div class="list-block"><ul><li>Precisely Decrypted（±30ms，俗称“大D”）</li></ul><ul><li>Imprecisely Decrypted（±60ms，俗称“小D”）</li></ul><ul><li>Received（±120ms，俗称“绿”）</li></ul><ul><li>Lost（+120ms后未响应）</li></ul></div>
|
||||||
|
<p>其中最佳判定Precisely Decrypted的判定窗口为±30ms。这为游戏添加了一种硬核准度要求，需要玩家达成极高的准确率，同时区分开的判定的视觉效果上也能给出硬核的手感体验。</p>
|
||||||
|
<p><a href="<a href="https://zhuanlan.zhihu.com/p/517535819"" target="_blank" rel="noreferrer">https://zhuanlan.zhihu.com/p/517535819"</a> target="_blank" rel="noreferrer"><a href="https://zhuanlan.zhihu.com/p/517535819" target="_blank" rel="noreferrer">https://zhuanlan.zhihu.com/p/517535819</a></a></p>
|
||||||
|
<p><a href="<a href="http://www.gugu.fun/iidxsp/"" target="_blank" rel="noreferrer">http://www.gugu.fun/iidxsp/"</a> target="_blank" rel="noreferrer"><a href="http://www.gugu.fun/iidxsp/" target="_blank" rel="noreferrer">http://www.gugu.fun/iidxsp/</a></a></p>
|
||||||
|
<p>但手感上的硬核容易劝退音游水平不高以及完全没有接触过音游的玩家，不过范式的产品定位为硬核音游，此问题属于制作团队的取舍方向问题。</p>
|
||||||
|
<p>或可借鉴《舞萌DX》的保护套设计，被设置有保护套的音符只要在判定窗口内被点击即判定大D。将此设计应用在普通模式下，为副歌重复的配置组合的第一次重复设置保护套供玩家学习试错，或在谱面高潮结束后为低密度冷却段设置一些保护套防止玩家在情绪降温以及操作压力下降期间出现失误。同时为保留挑战性，在段位模式则不启用保护套。</p>
|
||||||
|
<h3 id="判定容错">判定容错</h3>
|
||||||
|
<p>范式中Slider无尾判设计，不需要计算松手时机。同时，按住采用的是以密度为基础的判定，判定区域可达三分之一判定线宽度，这可以让玩家不时刻关注Slider的动向，且密度判定支持玩家进行换手操作。</p>
|
||||||
|
<figure class="figure-block"><div class="gallery gallery-1"><div class="gallery-item single"><img src="附件/范式：起源 立体交互体验拆解/image23.png" alt="image23.png" loading="lazy"></div></div><figcaption class="figure-caption">判定宽容度展示</figcaption></figure>
|
||||||
|
<p>无Early Lost设计也能够让玩家过早点击时不会判错。</p>
|
||||||
|
<p>这些设计都是为立体玩法服务的减负机制，在玩家需要同时处理Z轴深度、四边位置和复杂键型时，能够减少次要细节失误带来的挫败感，让注意力集中在迎面生成的音符的打击判断上。</p>
|
||||||
|
<h3 id="生存压力">生存压力</h3>
|
||||||
|
<p>玩家每次游玩时共有100点血量可用，在普通模式下玩家最大每次失误扣血5点，最多每次回血0.5点，比例高达10:1。这创造了一定的生存压力，放大了每一次失误的负面反馈。这种如履薄冰的紧张感本身就是手感的一部分，能够让玩家保持全程高压下的专注，通关本身也能够带来强烈过后如释重负的成就手感。同时能够让技术能力不匹配当前难度谱面的玩家认识到自身水平不足，在其积累足够的能力时成功通关能够带来巨大的挑战胜利成就感。</p>
|
||||||
|
</div>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section class="page content-page">
|
||||||
|
<div class="page-inner">
|
||||||
|
<h2 id="谱面设计拆解">谱面设计拆解</h2>
|
||||||
|
<h3 id="手序引导">手序引导</h3>
|
||||||
|
<p>在传统平面音游中玩家看到音符的决策链是：看到音符->判断落点->手指移动点击，而范式中由于立体机制的存在，玩家的决策链变为：看到音符->判断类型(空/地)->判断立体位置->规划手指移动->点击。</p>
|
||||||
|
<p>手序引导直接干预了规划手指移动这一环节，它通过谱面的音符摆放位置以及视觉提示预先告诉玩家“你应该用哪根手指放哪里，另一根手指再放哪里”，能够极大地降低玩家在短时间内需要处理的信息计算量。</p>
|
||||||
|
<figure class="figure-block"><div class="gallery gallery-1"><div class="gallery-item single"><img src="附件/范式：起源 立体交互体验拆解/image24.png" alt="image24.png" loading="lazy"></div></div><figcaption class="figure-caption">手序引导其一</figcaption></figure>
|
||||||
|
<figure class="figure-block"><div class="gallery gallery-1"><div class="gallery-item single"><img src="附件/范式：起源 立体交互体验拆解/image25.png" alt="image25.png" loading="lazy"></div></div><figcaption class="figure-caption">手序引导其二</figcaption></figure>
|
||||||
|
<p>如上两图所示，绿色表示左手手指设计上的移动路径，红色表示右手手指设计上的移动路径，玩家在观察到此Slider时可以立刻识别到自己的手指应该如何摆放。图1和图2是同一谱面的连续过程，可以观察到当左右手按照预期设计摆放到图1所示位置后，在图2中可以立刻让玩家以最小的位移幅度迎接下一音符。</p>
|
||||||
|
<p>同时若没有手序引导，高难度谱面可能会变成手指在屏幕上乱打。清晰的手序引导能够教会玩家如何有章法地使用手法去游玩一段复杂的谱面，同时范式追求的模拟街机的手感也需要手序引导这种教学和体验强化手段。但谱师若在谱面上过于激进地塞穿手、反手以及跨手引导等会导致玩家学习成本提升，容易制作出褒贬不一的谱面。如《Arcaea》就有非常类似的手序引导设计，对玩不来这套的玩家来说难以适应，但这也是《Arcaea》的知名标签之一。</p>
|
||||||
|
<h3 id="键型设计">键型设计</h3>
|
||||||
|
<h4 id="节奏把控">节奏把控</h4>
|
||||||
|
<aside class="todo">TODO: 与音乐节奏关联的谱面节奏把控以及印象点设计 采音与配置（采音为骨架 键型为血肉） 虚空采音</aside>
|
||||||
|
<p>游戏可以通过将基础的物件通过手序引导摆放等手段进行编排来控制谱面游玩节奏。</p>
|
||||||
|
<p>对节奏的把控除用于服务音乐情绪，也要服务玩家对谱面的认知。范式的大部分谱面设计都遵循着“教学——展开——爆发——冷却”的节奏循环。</p>
|
||||||
|
<p>其中教学性段落用于在副歌到来前预先以副歌高潮处可能出现的键型组合的低密度版展示副歌处手序和键型动机。让玩家在低压力情况下预演复杂操作，积累信心以及认知，避免高潮到来时手足无措，同时这也是对立体机制高学习成本的直接补偿。</p>
|
||||||
|
<p>在展开段落时在已预演的操作基础上叠加空键维度或提高密度来提升挑战性，同时使玩家的注意力稳步进入到活跃状态，为高潮部分做好准备。</p>
|
||||||
|
<p>高潮段落将视觉、听觉、操作与情绪完全同步，制造心流状态。全部设计在这里集中爆发，让玩家在极限压力下成功内化整套空键映射，产生人机一体的沉浸感，失误的痛苦以及成功的狂喜在此段被最大化。</p>
|
||||||
|
<p>冷却段即休息段，给玩家降温，降低密度以及位移量，并完成音乐情感的收尾，防止玩家因为持续的高压产生疲惫以及厌倦感。</p>
|
||||||
|
<p>谱面节奏失控会严重影响玩家游玩过程中的节奏期望，进而影响手感体验。</p>
|
||||||
|
<h4 id="配置组合">配置组合</h4>
|
||||||
|
<p>除节奏外，键型配置组合本身也会给玩家带来操作上的乐趣，范式的立体交互还带来了更多的设计空间。</p>
|
||||||
|
<aside class="todo">TODO: 玩家io改变带来的设计内容空间变化</aside>
|
||||||
|
<figure class="figure-block"><div class="gallery gallery-3"><div class="gallery-item"><img src="附件/范式：起源 立体交互体验拆解/image26.png" alt="image26.png" loading="lazy"></div><div class="gallery-item"><img src="附件/范式：起源 立体交互体验拆解/image27.png" alt="image27.png" loading="lazy"></div><div class="gallery-item"><img src="附件/范式：起源 立体交互体验拆解/image28.png" alt="image28.png" loading="lazy"></div></div><figcaption class="figure-caption split"><span>滑动型</span><span>肘击型</span><span>转圈型</span></figcaption></figure>
|
||||||
|
<p>如上图中玩家在游玩这三种键型时，手部会产生大位移。同时音乐在此为Bass Drop时玩家手部位移以及心理期待会与音乐同步，提供巨大且明确的情绪释放窗口为玩家带来极大的操作爽感。</p>
|
||||||
|
<figure class="figure-block"><div class="gallery gallery-3"><div class="gallery-item"><img src="附件/范式：起源 立体交互体验拆解/image29.png" alt="image29.png" loading="lazy"></div><div class="gallery-item"><img src="附件/范式：起源 立体交互体验拆解/image30.png" alt="image30.png" loading="lazy"></div><div class="gallery-item"><img src="附件/范式：起源 立体交互体验拆解/image31.png" alt="image31.png" loading="lazy"></div></div><figcaption class="figure-caption split"><span>天地交互</span><span>交互</span><span>子弹叠</span></figcaption></figure>
|
||||||
|
<p>上图中玩家在游玩这三种键型时，通常是在音乐的Kick段。电音中Kick是一种高密度高能量的底鼓段落，游戏中将其转化为一种高速的音符交互，要求玩家的注意力以及手指在平面上的移动速度必须跟上音乐的节奏。在这种高压段落下玩家会停止思考，</p>
|
||||||
|
<p>//停止思考分情况，底力与复杂谱面解析</p>
|
||||||
|
<p>完全依靠肌肉记忆以及节奏本能进入心流状态。此时玩家不只是听见密集的鼓点，在心理上这更是自己去亲手敲出来的底鼓声，使玩家自身成为节奏的一部分。</p>
|
||||||
|
<p>交互中特殊的一点是高BPM音乐中的32分节奏不会直接转化为32分交互，而是会转化为16分或更低切分的交互。此时追求节奏的保真会影响到谱面的可玩性，甚至影响手感。</p>
|
||||||
|
<p>总的来说键型配置对玩家意味着对音乐的演绎，游玩过程中将玩家的心理期待、操作节奏以及音乐节奏相统一，随着音乐释放情绪，这成为手感的一部分，使玩家沉浸其中。</p>
|
||||||
|
</div>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section class="page content-page">
|
||||||
|
<div class="page-inner">
|
||||||
|
<h2 id="总结">总结</h2>
|
||||||
|
<p>《范式：起源》通过结合polytone以及dynamix的玩法成功构建了一套极具特色的立体交互系统。这套设计的核心价值不止在于视觉上的空间延伸，更在于其通过一系列的视觉补偿与判定优化，解决了立体空间下读谱逻辑非线性带来的手感体验难点。</p>
|
||||||
|
<p>同时在内容设计上通过手序引导、谱面节奏把控以及配置组合，给予玩家一切尽在掌控的手感体验。</p>
|
||||||
|
<p>综上，《范式：起源》的成功不仅在于交互上的创新尝试，更在于用极致的细节调优去解决潜在问题，最后给玩家交出了一套逻辑自洽、极其顺手的立体交互体验设计。</p>
|
||||||
|
</div>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section class="page content-page">
|
||||||
|
<div class="page-inner">
|
||||||
|
<h2 id="引用">引用</h2>
|
||||||
|
<p><a href="<a href="https://paradigmrebootzh.miraheze.org/wiki/%E6%B8%B8%E6%88%8F%E7%9B%B8%E5%85%B3#%E5%88%86%E6%95%B0%E8%AE%A1%E7%AE%97"" target="_blank" rel="noreferrer">https://paradigmrebootzh.miraheze.org/wiki/%E6%B8%B8%E6%88%8F%E7%9B%B8%E5%85%B3#%E5%88%86%E6%95%B0%E8%AE%A1%E7%AE%97"</a> target="_blank" rel="noreferrer"><a href="https://paradigmrebootzh.miraheze.org/wiki/%E6%B8%B8%E6%88%8F%E7%9B%B8%E5%85%B3#%E5%88%86%E6%95%B0%E8%AE%A1%E7%AE%97" target="_blank" rel="noreferrer">https://paradigmrebootzh.miraheze.org/wiki/%E6%B8%B8%E6%88%8F%E7%9B%B8%E5%85%B3#%E5%88%86%E6%95%B0%E8%AE%A1%E7%AE%97</a></a></p>
|
||||||
|
<p><a href="<a href="https://www.bilibili.com/video/BV1bN6JYkEUw"" target="_blank" rel="noreferrer">https://www.bilibili.com/video/BV1bN6JYkEUw"</a> target="_blank" rel="noreferrer"><a href="https://www.bilibili.com/video/BV1bN6JYkEUw" target="_blank" rel="noreferrer">https://www.bilibili.com/video/BV1bN6JYkEUw</a></a></p>
|
||||||
|
<p><a href="<a href="https://www.bilibili.com/video/BV1UD421g7Zi"" target="_blank" rel="noreferrer">https://www.bilibili.com/video/BV1UD421g7Zi"</a> target="_blank" rel="noreferrer"><a href="https://www.bilibili.com/video/BV1UD421g7Zi" target="_blank" rel="noreferrer">https://www.bilibili.com/video/BV1UD421g7Zi</a></a></p>
|
||||||
|
<p><a href="<a href="https://gugu.fun/yinyoutonglun/"" target="_blank" rel="noreferrer">https://gugu.fun/yinyoutonglun/"</a> target="_blank" rel="noreferrer"><a href="https://gugu.fun/yinyoutonglun/" target="_blank" rel="noreferrer">https://gugu.fun/yinyoutonglun/</a></a></p>
|
||||||
|
<p><a href="<a href="https://zhuanlan.zhihu.com/p/453517424"" target="_blank" rel="noreferrer">https://zhuanlan.zhihu.com/p/453517424"</a> target="_blank" rel="noreferrer"><a href="https://zhuanlan.zhihu.com/p/453517424" target="_blank" rel="noreferrer">https://zhuanlan.zhihu.com/p/453517424</a></a></p>
|
||||||
|
<p><a href="<a href="https://www.bilibili.com/video/BV15j411o7rA"" target="_blank" rel="noreferrer">https://www.bilibili.com/video/BV15j411o7rA"</a> target="_blank" rel="noreferrer"><a href="https://www.bilibili.com/video/BV15j411o7rA" target="_blank" rel="noreferrer">https://www.bilibili.com/video/BV15j411o7rA</a></a></p>
|
||||||
|
</div>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
</main>
|
||||||
|
</body>
|
||||||
|
</html>
|
||||||
@@ -0,0 +1,319 @@
|
|||||||
|
# 《范式：起源》立体交互体验拆解
|
||||||
|
|
||||||
|
> LaTeX 排版预览
|
||||||
|
>
|
||||||
|
> ![[拆解/附件/范式：起源 立体交互体验拆解/范式：起源 立体交互体验拆解.pdf]]
|
||||||
|
|
||||||
|
作者：孙玉杰
|
||||||
|
|
||||||
|
文档版本：26/1/30
|
||||||
|
|
||||||
|
## 前言
|
||||||
|
|
||||||
|
本文档旨在探讨《范式：起源》的立体交互机制。通过分析其设计逻辑、感官反馈、优势与代价，解析这套设计如何塑造了空间立体感，以及如何以对视听、判定以及内容进行设计在立体交互基础上实现了对手感体验的调优。
|
||||||
|
|
||||||
|
## 游戏玩法机制简述
|
||||||
|
|
||||||
|
### 操作交互设计
|
||||||
|
|
||||||
|
传统下落式音游的空间映射常常被限制在 X 轴（轨道）与 Y 轴（时间）构成的二维平面中进行演出和判定。
|
||||||
|
|
||||||
|
//todo a to b 表述更新
|
||||||
|
|
||||||
|
然而，范式选择打破这一限制，扩展出 Z 轴表示深度，将玩家控制区域变化为 “四边 + 中心 + 深度” 的立体结构。
|
||||||
|
|
||||||
|
//todo 具象形容 伪3d效果 不要默认觉得读者了解音游
|
||||||
|
|
||||||
|
范式的核心玩法要求玩家处理从屏幕中心向四周（上、下、左、右）发散的地键（Ground Note），同时也需要处理直接作用于屏幕中心的空键（Air Note）。
|
||||||
|
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image1.png]]
|
||||||
|
上图蓝色区域为玩家四周判定区域
|
||||||
|
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image2.png]]
|
||||||
|
上图橙色区域为玩家屏幕中心判定区域
|
||||||
|
|
||||||
|
### 物件交互设计
|
||||||
|
|
||||||
|
游戏通过两类交互物件为玩家构建了游玩的立体感，并为二者在设计上担任不同的手感职能。
|
||||||
|
|
||||||
|
- 地键（Ground Note）
|
||||||
|
- 形态与手感：判定锚定在平面边缘，提供明确的上、下、左、右方位反馈。
|
||||||
|
- 设计意图：交互上对标传统下落式X/Y轴判定，手感类似于传统下落式音游，但地键分布在四周会带来更大的玩家手部位移。
|
||||||
|
- 空键（Air Note）
|
||||||
|
- 形态与手感：悬浮在轨道中空间的正方形物件，判定更多得体现在何时而不是何处，需要结合音乐节奏预判时机。
|
||||||
|
- 设计意图：引入了Z轴，建立纵深空间，与地键一起出现时一定程度上会增加读谱难度为玩家带来紧张感。手感从传统的点击转化到迎击。
|
||||||
|
|
||||||
|
//todo 手感差异在视觉上的表现 将主观体验转化为客观描述
|
||||||
|
|
||||||
|
### 交互模式优势与代价与解决方案
|
||||||
|
|
||||||
|
#### 优势
|
||||||
|
|
||||||
|
内容设计空间升维：
|
||||||
|
|
||||||
|
- 相对于传统下落式音游，引入Z轴深度概念能够为游戏谱面设计新增维度，使设计者能够借这套机制设计一些特有的或者模拟街机音游的键型。
|
||||||
|
|
||||||
|
大开大合的交互体感：
|
||||||
|
|
||||||
|
- 四边判定会迫使玩家的手腕和小臂参与到位移中来，带来大出张与大位移能够让手感从手指操作转化为肢体运动。
|
||||||
|
|
||||||
|
//todo 出张概念 以及 详细解释 越过判定中线
|
||||||
|
|
||||||
|
#### 代价
|
||||||
|
|
||||||
|
手部遮挡：
|
||||||
|
|
||||||
|
- 在手序设计不佳的情况下手指点击空键或上边缘时会遮挡一部分读谱区，人类的手不能调透明度也不能穿模。体现在极端情况下将右手引导至左区，将左手引导至右区时必然会遮挡住一部分音符，同时也可能发生双手打架的情况，这是大部分移动端音游都会产生的问题，对手机玩家手感影响更甚。
|
||||||
|
|
||||||
|
//todo 出张的优势与代价 下部补充
|
||||||
|
|
||||||
|
变速错觉：
|
||||||
|
|
||||||
|
- 透视原理使音符在视觉上呈现非线性加速，导致越近越快，破坏了平面音游中距离等于时间的直观读谱逻辑。玩家必然更依赖音押而非目押，设备音频延迟的影响会被放大。
|
||||||
|
|
||||||
|
//todo 玩家适应成本 判定确认极端 加速度下落式玩家比普通情况下更依赖音押或目押
|
||||||
|
|
||||||
|
判定面的视觉模糊：
|
||||||
|
|
||||||
|
- Z轴上的判定是一个面而非一条线。尤其在玩家处理Slider时，手指在纵深方向上是否偏离轨道难以直观感知，容易产生莫名其妙的失误。
|
||||||
|
|
||||||
|
//todo 学习成本
|
||||||
|
|
||||||
|
#### 解决方案
|
||||||
|
|
||||||
|
针对变速错觉问题，范式除提供了音频延迟以及画面延迟的调整外，还提供了音符出现距离的调整，将音符出现距离拉近能够有效地缓解变速错觉问题。
|
||||||
|
|
||||||
|
但降低音符出现距离会缩减音符出现时长，导致影响玩家的信息接收量。降低音符出现距离的同时想要保持音符显示时长又需要提高谱面流速，会使不熟练的玩家难以反应。但其他轨道存在透视变速的音游也存在一样的问题，除提供的原理类似的上隐，只能靠玩家自己手动往轨道上方放纸条挡住变速区域，也牺牲了信息接收量。范式的降低音符出现距离帮助玩家省去了贴纸条的操作，作为系统功能来说，这是对变速错觉问题难以解决的妥协处理，业界也没有针对此问题的其他解决方案。信息接收量降低不完全是一件坏事，当同一时间大量音符出现在屏幕中时玩家会难以集中注意力去处理该点击哪个音符，信息接收量的降低能够提供一定的信息节食效果，帮助玩家集中注意力到该处理的音符上。
|
||||||
|
|
||||||
|
//todo 上隐下隐目的 信息量 思考速度与时间
|
||||||
|
|
||||||
|
<https://www.bilibili.com/video/BV1N1NPe4E5R>
|
||||||
|
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image3.png]]
|
||||||
|
音符出现距离设置项
|
||||||
|
|
||||||
|
手部遮挡问题的解决其一可以通过谱面的手序设计来绕过见后文手序引导分析，其二是为玩家提供物件大小调整项。足够大的物件能够为手机端玩家提供足够高的辨识度。同时游戏还提供了游戏区域比例来单独适配平板以及手机的显示区域。
|
||||||
|
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image4.png]]
|
||||||
|
游戏区域比例设置项
|
||||||
|
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image5.png]]
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image6.png]]
|
||||||
|
手机显示比例 平板显示比例
|
||||||
|
|
||||||
|
判定面的视觉模糊可以通过调整判定缓解，见后文判定容错。
|
||||||
|
|
||||||
|
## 视听反馈设计拆解
|
||||||
|
|
||||||
|
范式在立体交互的基础上通过视觉欺骗、音效播放延迟优化以及触控延迟的可控调整的实现，制作了干脆不粘手的反馈效果。
|
||||||
|
|
||||||
|
### 瞬间响应
|
||||||
|
|
||||||
|
- 表现：当玩家触发判定时，Note会在第一帧立刻消失，立刻播放判定音效，并在目标位置触发火花特效、判定线高亮特效以及判定结果文字特效。
|
||||||
|
- 设计意图：在缺乏音游设计知识的情况下可能会出现制作Note溶解动画的情况，
|
||||||
|
|
||||||
|
//todo 游戏类型与动画解释 原因与影响 音效设计组合
|
||||||
|
|
||||||
|
这会带来视觉残留导致手感拖泥带水。范式中Note触发即消失，并同时在判定目标位置生成触发特效，瞬间完成的视觉反馈以及音效的瞬间播放极大提高了操作的即时感。
|
||||||
|
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image7.png]]
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image8.png]]
|
||||||
|
判定开始 特效响应
|
||||||
|
|
||||||
|
### 确认与引导
|
||||||
|
|
||||||
|
- 表现：判定触发后，一条光流沿Z轴轨道向屏幕深处运动，同时火花向外爆开判定线高亮逐渐变暗，其中光流的颜色因玩家点击的Note的判定准度而变化。
|
||||||
|
- 设计意图：
|
||||||
|
- 打击延伸：为Note点击带来向内方向释放感，光流颜色加上火花特效能够同时增强玩家的“点到了”以及“唉爆了个绿”的确认感。
|
||||||
|
- 视线重置：光流运动由近及远能够巧妙地将玩家视线从操作区重新引导回读谱区，为处理下一个Note做好准备。
|
||||||
|
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image9.png]]
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image10.png]]
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image11.png]]
|
||||||
|
特效起始 光流前进 特效消失
|
||||||
|
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image12.png]]
|
||||||
|
非“完全解密”光流颜色以及评价文本
|
||||||
|
|
||||||
|
- 特殊情况
|
||||||
|
- 表现：当玩家在短时间内连续触发多个Note判定时，判定线会前一个Note判定结束亮度降低后但未完全恢复到不高亮接受下一个Note时重新将高亮重置到最高亮度。
|
||||||
|
|
||||||
|
//todo
|
||||||
|
|
||||||
|
- 设计意图：能够隐性地在高密度环境下的近乎闪烁的高亮提示能为玩家保持快节奏状态下的火热手感。
|
||||||
|
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image13.png]]
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image14.png]]
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image15.png]]
|
||||||
|
第一个Note触发时高亮 第一个Note触发后高亮变暗 第二个Note触发后
|
||||||
|
|
||||||
|
### 视觉避让
|
||||||
|
|
||||||
|
- 表现：评价文字在出现后并非静止消失，而是垂直轨道缓慢上移，并逐渐溶解。按住Hold时评价文字会一直叠加生成并重复上述生命周期。
|
||||||
|
- 设计意图：文字垂直轨道上移是一种抗干扰设计，为了不使文字挡住后方飞来的Note，防止文字遮挡谱面导致读谱失误。按住Hold时叠加出现的判定文字以及其特有的蓝色火花会给玩家一种“我正一直接着”的感觉。
|
||||||
|
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image16.png]]
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image17.png]]
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image18.png]]
|
||||||
|
文字出现 文字上移 文字溶解
|
||||||
|
|
||||||
|
### 深度感知的视觉补偿
|
||||||
|
|
||||||
|
在平面上表现Z轴的会带来距离感缺失导致玩家不能够准确判断判定时机，范式除上文提到的出现距离调整项，还提供了一个巧妙的解决方案。
|
||||||
|
|
||||||
|
- 表现：空键在平面目标点上映射方框，其中映射目标点内部方块随着空键靠近平面而逐渐填满外框时，即为最佳击打时机。
|
||||||
|
- 设计意图：将模糊的依赖于透视经验以及音乐节奏时机的判断转化为浮现式音游的图形重合判断。这为玩家提供了显性的、可训练的时机信号，能够极大地稳定Z轴交互的手感预期，使高密度情况下精确操作成为可能。
|
||||||
|
|
||||||
|
//todo 回头拆一下cy2
|
||||||
|
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image19.png]]
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image20.png]]
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image21.png]]
|
||||||
|
补偿图形出现 补偿图形重合 完成判定
|
||||||
|
|
||||||
|
### 动画编排
|
||||||
|
|
||||||
|
经过对实机画面的逐帧逆向观测后，我发现游戏通过对判定动画设置了三条曲线构建了富有层次感的反馈体验。基于玩家视角的观测数据中光流、火花与评价文字在约27帧的生命周期内呈现出明显的能量分布差异，明显可以观察到动画节奏已经过仔细编排。
|
||||||
|
|
||||||
|
- 光流
|
||||||
|
- 表现：光流动画响应最快，在前4帧左右迅速到达峰值，随后立刻线性衰减。
|
||||||
|
- 设计意图：光流负责提供第一时间的触控确认。它负责快速反馈，同时快速的衰减和向Z轴深处的位移，起到将玩家视线从判定区引导回屏幕中心的作用。
|
||||||
|
- 火花
|
||||||
|
- 表现：火花动画起步爆发较快，但直到第9-10帧才达到峰值，比光流晚5帧。
|
||||||
|
- 设计意图：火花动画与光流动画峰值的时间错层除了体现游戏主题的信号的时序错位，更多的在视觉上能够提供一定的重量感。若火花和光流峰值完全同步则会使效果显得单薄，相对滞后的峰值能够为整体提供视觉上的厚度。
|
||||||
|
- 评价文字
|
||||||
|
- 表现：峰值最持久，在第7-13帧保持了长达数帧的峰值平台期，随后才开始衰减。
|
||||||
|
- 设计意图：评价文字的首要人物是传递信息，使玩家除观察光流颜色还能够在余光中凭判定文字确认判定结果。
|
||||||
|
|
||||||
|
### 音效设计
|
||||||
|
|
||||||
|
- 表现：范式的Note音效种类并不像其他移动端音游那么奢侈，反而所有Note全部使用一种音效，相当地克制。主观听感上音效和按动笔发出的声音一样清脆，音调又不像铃铛一样高，有一定厚度感，听感节奏也以快速爆发到线性衰减为主。
|
||||||
|
|
||||||
|
//todo 音效音色设计意图以及视觉与音效联动 视听效果搭配会产生差异 &瞬间相应
|
||||||
|
|
||||||
|
- 设计意图：统一的音效除节省成本外还能够为玩家带来统一的确认感，同时音色不强求大高频，存在一定低频成分不会使玩家一直听到这一种音效感到枯燥。
|
||||||
|
- 缺陷：虽然音色设计使单音效足够耐听，但可以考虑学习《舞萌DX》或其他音游，为不同的判定制作不同的音效。使玩家在恰当的时机击打音符时获得更强烈的正反馈。
|
||||||
|
|
||||||
|
## 判定逻辑设计拆解
|
||||||
|
|
||||||
|
### 判定窗口
|
||||||
|
|
||||||
|
游戏内，物件有四级判定：
|
||||||
|
|
||||||
|
- Precisely Decrypted（±30ms，俗称“大D”）
|
||||||
|
- Imprecisely Decrypted（±60ms，俗称“小D”）
|
||||||
|
- Received（±120ms，俗称“绿”）
|
||||||
|
- Lost（+120ms后未响应）
|
||||||
|
|
||||||
|
其中最佳判定Precisely Decrypted的判定窗口为±30ms。这为游戏添加了一种硬核准度要求，需要玩家达成极高的准确率，同时区分开的判定的视觉效果上也能给出硬核的手感体验。
|
||||||
|
|
||||||
|
<https://zhuanlan.zhihu.com/p/517535819>
|
||||||
|
|
||||||
|
<http://www.gugu.fun/iidxsp/>
|
||||||
|
|
||||||
|
但手感上的硬核容易劝退音游水平不高以及完全没有接触过音游的玩家，不过范式的产品定位为硬核音游，此问题属于制作团队的取舍方向问题。
|
||||||
|
|
||||||
|
或可借鉴《舞萌DX》的保护套设计，被设置有保护套的音符只要在判定窗口内被点击即判定大D。将此设计应用在普通模式下，为副歌重复的配置组合的第一次重复设置保护套供玩家学习试错，或在谱面高潮结束后为低密度冷却段设置一些保护套防止玩家在情绪降温以及操作压力下降期间出现失误。同时为保留挑战性，在段位模式则不启用保护套。
|
||||||
|
|
||||||
|
### 判定容错
|
||||||
|
|
||||||
|
范式中Slider无尾判设计，不需要计算松手时机。同时，按住采用的是以密度为基础的判定，判定区域可达三分之一判定线宽度，这可以让玩家不时刻关注Slider的动向，且密度判定支持玩家进行换手操作。
|
||||||
|
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image23.png]]
|
||||||
|
判定宽容度展示
|
||||||
|
|
||||||
|
无Early Lost设计也能够让玩家过早点击时不会判错。
|
||||||
|
|
||||||
|
这些设计都是为立体玩法服务的减负机制，在玩家需要同时处理Z轴深度、四边位置和复杂键型时，能够减少次要细节失误带来的挫败感，让注意力集中在迎面生成的音符的打击判断上。
|
||||||
|
|
||||||
|
### 生存压力
|
||||||
|
|
||||||
|
玩家每次游玩时共有100点血量可用，在普通模式下玩家最大每次失误扣血5点，最多每次回血0.5点，比例高达10:1。这创造了一定的生存压力，放大了每一次失误的负面反馈。这种如履薄冰的紧张感本身就是手感的一部分，能够让玩家保持全程高压下的专注，通关本身也能够带来强烈过后如释重负的成就手感。同时能够让技术能力不匹配当前难度谱面的玩家认识到自身水平不足，在其积累足够的能力时成功通关能够带来巨大的挑战胜利成就感。
|
||||||
|
|
||||||
|
## 谱面设计拆解
|
||||||
|
|
||||||
|
### 手序引导
|
||||||
|
|
||||||
|
在传统平面音游中玩家看到音符的决策链是：看到音符->判断落点->手指移动点击，而范式中由于立体机制的存在，玩家的决策链变为：看到音符->判断类型(空/地)->判断立体位置->规划手指移动->点击。
|
||||||
|
|
||||||
|
手序引导直接干预了规划手指移动这一环节，它通过谱面的音符摆放位置以及视觉提示预先告诉玩家“你应该用哪根手指放哪里，另一根手指再放哪里”，能够极大地降低玩家在短时间内需要处理的信息计算量。
|
||||||
|
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image24.png]]
|
||||||
|
手序引导其一
|
||||||
|
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image25.png]]
|
||||||
|
手序引导其二
|
||||||
|
|
||||||
|
如上两图所示，绿色表示左手手指设计上的移动路径，红色表示右手手指设计上的移动路径，玩家在观察到此Slider时可以立刻识别到自己的手指应该如何摆放。图1和图2是同一谱面的连续过程，可以观察到当左右手按照预期设计摆放到图1所示位置后，在图2中可以立刻让玩家以最小的位移幅度迎接下一音符。
|
||||||
|
|
||||||
|
同时若没有手序引导，高难度谱面可能会变成手指在屏幕上乱打。清晰的手序引导能够教会玩家如何有章法地使用手法去游玩一段复杂的谱面，同时范式追求的模拟街机的手感也需要手序引导这种教学和体验强化手段。但谱师若在谱面上过于激进地塞穿手、反手以及跨手引导等会导致玩家学习成本提升，容易制作出褒贬不一的谱面。如《Arcaea》就有非常类似的手序引导设计，对玩不来这套的玩家来说难以适应，但这也是《Arcaea》的知名标签之一。
|
||||||
|
|
||||||
|
### 键型设计
|
||||||
|
|
||||||
|
#### 节奏把控
|
||||||
|
|
||||||
|
//todo 与音乐节奏关联的谱面节奏把控以及印象点设计 采音与配置（采音为骨架 键型为血肉） 虚空采音
|
||||||
|
|
||||||
|
游戏可以通过将基础的物件通过手序引导摆放等手段进行编排来控制谱面游玩节奏。
|
||||||
|
|
||||||
|
对节奏的把控除用于服务音乐情绪，也要服务玩家对谱面的认知。范式的大部分谱面设计都遵循着“教学——展开——爆发——冷却”的节奏循环。
|
||||||
|
|
||||||
|
其中教学性段落用于在副歌到来前预先以副歌高潮处可能出现的键型组合的低密度版展示副歌处手序和键型动机。让玩家在低压力情况下预演复杂操作，积累信心以及认知，避免高潮到来时手足无措，同时这也是对立体机制高学习成本的直接补偿。
|
||||||
|
|
||||||
|
在展开段落时在已预演的操作基础上叠加空键维度或提高密度来提升挑战性，同时使玩家的注意力稳步进入到活跃状态，为高潮部分做好准备。
|
||||||
|
|
||||||
|
高潮段落将视觉、听觉、操作与情绪完全同步，制造心流状态。全部设计在这里集中爆发，让玩家在极限压力下成功内化整套空键映射，产生人机一体的沉浸感，失误的痛苦以及成功的狂喜在此段被最大化。
|
||||||
|
|
||||||
|
冷却段即休息段，给玩家降温，降低密度以及位移量，并完成音乐情感的收尾，防止玩家因为持续的高压产生疲惫以及厌倦感。
|
||||||
|
|
||||||
|
谱面节奏失控会严重影响玩家游玩过程中的节奏期望，进而影响手感体验。
|
||||||
|
|
||||||
|
#### 配置组合
|
||||||
|
|
||||||
|
除节奏外，键型配置组合本身也会给玩家带来操作上的乐趣，范式的立体交互还带来了更多的设计空间。
|
||||||
|
|
||||||
|
//todo 玩家io改变带来的设计内容空间变化
|
||||||
|
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image26.png]]
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image27.png]]
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image28.png]]
|
||||||
|
滑动型 肘击型 转圈型
|
||||||
|
|
||||||
|
如上图中玩家在游玩这三种键型时，手部会产生大位移。同时音乐在此为Bass Drop时玩家手部位移以及心理期待会与音乐同步，提供巨大且明确的情绪释放窗口为玩家带来极大的操作爽感。
|
||||||
|
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image29.png]]
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image30.png]]
|
||||||
|
![[拆解/附件/范式：起源 立体交互体验拆解/image31.png]]
|
||||||
|
天地交互 交互 子弹叠
|
||||||
|
|
||||||
|
上图中玩家在游玩这三种键型时，通常是在音乐的Kick段。电音中Kick是一种高密度高能量的底鼓段落，游戏中将其转化为一种高速的音符交互，要求玩家的注意力以及手指在平面上的移动速度必须跟上音乐的节奏。在这种高压段落下玩家会停止思考，
|
||||||
|
|
||||||
|
//停止思考分情况，底力与复杂谱面解析
|
||||||
|
|
||||||
|
完全依靠肌肉记忆以及节奏本能进入心流状态。此时玩家不只是听见密集的鼓点，在心理上这更是自己去亲手敲出来的底鼓声，使玩家自身成为节奏的一部分。
|
||||||
|
|
||||||
|
交互中特殊的一点是高BPM音乐中的32分节奏不会直接转化为32分交互，而是会转化为16分或更低切分的交互。此时追求节奏的保真会影响到谱面的可玩性，甚至影响手感。
|
||||||
|
|
||||||
|
总的来说键型配置对玩家意味着对音乐的演绎，游玩过程中将玩家的心理期待、操作节奏以及音乐节奏相统一，随着音乐释放情绪，这成为手感的一部分，使玩家沉浸其中。
|
||||||
|
|
||||||
|
## 总结
|
||||||
|
|
||||||
|
《范式：起源》通过结合polytone以及dynamix的玩法成功构建了一套极具特色的立体交互系统。这套设计的核心价值不止在于视觉上的空间延伸，更在于其通过一系列的视觉补偿与判定优化，解决了立体空间下读谱逻辑非线性带来的手感体验难点。
|
||||||
|
|
||||||
|
同时在内容设计上通过手序引导、谱面节奏把控以及配置组合，给予玩家一切尽在掌控的手感体验。
|
||||||
|
|
||||||
|
综上，《范式：起源》的成功不仅在于交互上的创新尝试，更在于用极致的细节调优去解决潜在问题，最后给玩家交出了一套逻辑自洽、极其顺手的立体交互体验设计。
|
||||||
|
|
||||||
|
## 引用
|
||||||
|
|
||||||
|
<https://paradigmrebootzh.miraheze.org/wiki/%E6%B8%B8%E6%88%8F%E7%9B%B8%E5%85%B3#%E5%88%86%E6%95%B0%E8%AE%A1%E7%AE%97>
|
||||||
|
|
||||||
|
<https://www.bilibili.com/video/BV1bN6JYkEUw>
|
||||||
|
|
||||||
|
<https://www.bilibili.com/video/BV1UD421g7Zi>
|
||||||
|
|
||||||
|
<https://gugu.fun/yinyoutonglun/>
|
||||||
|
|
||||||
|
<https://zhuanlan.zhihu.com/p/453517424>
|
||||||
|
|
||||||
|
<https://www.bilibili.com/video/BV15j411o7rA>
|
||||||
Binary file not shown.
|
After Width: | Height: | Size: 320 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 185 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 97 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 262 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 713 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.2 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.1 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 172 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 185 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 97 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 68 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 330 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 72 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 103 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 50 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 389 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 278 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 453 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 549 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.3 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 629 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 540 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 2.0 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 382 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 273 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 2.1 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.5 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.4 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 145 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 73 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 172 KiB |
Binary file not shown.
@@ -0,0 +1,383 @@
|
|||||||
|
\documentclass[UTF8,12pt,a4paper]{ctexart}
|
||||||
|
\usepackage[margin=22mm,headheight=16pt,headsep=7mm,footskip=12mm]{geometry}
|
||||||
|
\usepackage{graphicx}
|
||||||
|
\usepackage{caption}
|
||||||
|
\usepackage{float}
|
||||||
|
\usepackage{hyperref}
|
||||||
|
\usepackage{xurl}
|
||||||
|
\usepackage{xcolor}
|
||||||
|
\usepackage{enumitem}
|
||||||
|
\usepackage{titlesec}
|
||||||
|
\usepackage{bookmark}
|
||||||
|
\usepackage[section]{placeins}
|
||||||
|
\usepackage{setspace}
|
||||||
|
\usepackage{fancyhdr}
|
||||||
|
\usepackage{fontspec}
|
||||||
|
|
||||||
|
\hypersetup{
|
||||||
|
unicode=true,
|
||||||
|
hidelinks,
|
||||||
|
pdfauthor={作者：孙玉杰},
|
||||||
|
pdftitle={《范式：起源》立体交互体验拆解}
|
||||||
|
}
|
||||||
|
\setmainfont{Times New Roman}
|
||||||
|
\setsansfont{Arial}
|
||||||
|
\setmonofont{Consolas}
|
||||||
|
\setCJKmainfont{SimSun}
|
||||||
|
\setCJKsansfont{Microsoft YaHei}
|
||||||
|
\setCJKmonofont{Microsoft YaHei}
|
||||||
|
\setCJKfamilyfont{zhhei}{Microsoft YaHei}
|
||||||
|
\setCJKfamilyfont{zhkai}{KaiTi}
|
||||||
|
\setCJKfamilyfont{zhfs}{FangSong}
|
||||||
|
|
||||||
|
\graphicspath{{./}}
|
||||||
|
\setcounter{secnumdepth}{0}
|
||||||
|
\setcounter{tocdepth}{2}
|
||||||
|
\renewcommand{\contentsname}{目\quad 录}
|
||||||
|
\setlist[itemize]{leftmargin=2.2em,itemsep=0.2em,topsep=0.4em}
|
||||||
|
\setlist[enumerate]{leftmargin=2.2em,itemsep=0.2em,topsep=0.4em}
|
||||||
|
\setlength{\parindent}{2em}
|
||||||
|
\setlength{\parskip}{0.22em}
|
||||||
|
\setlength{\textfloatsep}{10pt plus 2pt minus 2pt}
|
||||||
|
\setlength{\floatsep}{10pt plus 2pt minus 2pt}
|
||||||
|
\setlength{\intextsep}{10pt plus 2pt minus 2pt}
|
||||||
|
\setlength{\abovecaptionskip}{5pt}
|
||||||
|
\setlength{\belowcaptionskip}{0pt}
|
||||||
|
\linespread{1.12}
|
||||||
|
\raggedbottom
|
||||||
|
\pagestyle{fancy}
|
||||||
|
\fancyhf{}
|
||||||
|
\fancyhead[L]{\footnotesize\nouppercase{\leftmark}}
|
||||||
|
\fancyhead[R]{\footnotesize 《范式：起源》}
|
||||||
|
\fancyfoot[C]{\footnotesize\thepage}
|
||||||
|
\renewcommand{\headrulewidth}{0.4pt}
|
||||||
|
\captionsetup{font=small,labelformat=empty,justification=centering,singlelinecheck=false}
|
||||||
|
\setkeys{Gin}{width=\linewidth,height=0.36\textheight}
|
||||||
|
\newcommand{\figsinglewidth}{0.84\linewidth}
|
||||||
|
\newcommand{\figdoublewidth}{0.47\linewidth}
|
||||||
|
\newcommand{\figtriplewidth}{0.30\linewidth}
|
||||||
|
\newcommand{\figsingleheight}{0.24\textheight}
|
||||||
|
\newcommand{\figdoubleheight}{0.18\textheight}
|
||||||
|
\newcommand{\figtripleheight}{0.14\textheight}
|
||||||
|
\titleformat{\section}{\zihao{-3}\bfseries\raggedright}{}{0pt}{}
|
||||||
|
\titlespacing*{\section}{0pt}{1.1em}{0.45em}
|
||||||
|
\titleformat{\subsection}{\zihao{4}\bfseries\raggedright}{}{0pt}{}
|
||||||
|
\titlespacing*{\subsection}{0pt}{0.8em}{0.28em}
|
||||||
|
\titleformat{\subsubsection}{\normalsize\bfseries\raggedright}{}{0pt}{}
|
||||||
|
\titlespacing*{\subsubsection}{0pt}{0.65em}{0.15em}
|
||||||
|
\urlstyle{same}
|
||||||
|
\newcommand{\listitemline}[3]{\par\noindent\hspace*{#1\dimexpr 1.6em\relax}\makebox[1.4em][l]{#2}#3\par}
|
||||||
|
\newcommand{\singlefig}[2]{%
|
||||||
|
\begin{figure}[tbp]
|
||||||
|
\centering
|
||||||
|
\begin{minipage}[t]{\figsinglewidth}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\linewidth,height=\figsingleheight]{#1}
|
||||||
|
\par\smallskip
|
||||||
|
{\small\centering #2\par}
|
||||||
|
\end{minipage}
|
||||||
|
\end{figure}
|
||||||
|
}
|
||||||
|
\newcommand{\doublefig}[4]{%
|
||||||
|
\begin{figure}[tbp]
|
||||||
|
\centering
|
||||||
|
\begin{minipage}[t]{\figdoublewidth}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\linewidth,height=\figdoubleheight]{#1}
|
||||||
|
\par\smallskip
|
||||||
|
{\small\centering #2\par}
|
||||||
|
\end{minipage}
|
||||||
|
\hfill
|
||||||
|
\begin{minipage}[t]{\figdoublewidth}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\linewidth,height=\figdoubleheight]{#3}
|
||||||
|
\par\smallskip
|
||||||
|
{\small\centering #4\par}
|
||||||
|
\end{minipage}
|
||||||
|
\end{figure}
|
||||||
|
}
|
||||||
|
\newcommand{\triplefig}[6]{%
|
||||||
|
\begin{figure}[tbp]
|
||||||
|
\centering
|
||||||
|
\begin{minipage}[t]{\figtriplewidth}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\linewidth,height=\figtripleheight]{#1}
|
||||||
|
\par\smallskip
|
||||||
|
{\small\centering #2\par}
|
||||||
|
\end{minipage}
|
||||||
|
\hfill
|
||||||
|
\begin{minipage}[t]{\figtriplewidth}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\linewidth,height=\figtripleheight]{#3}
|
||||||
|
\par\smallskip
|
||||||
|
{\small\centering #4\par}
|
||||||
|
\end{minipage}
|
||||||
|
\hfill
|
||||||
|
\begin{minipage}[t]{\figtriplewidth}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\linewidth,height=\figtripleheight]{#5}
|
||||||
|
\par\smallskip
|
||||||
|
{\small\centering #6\par}
|
||||||
|
\end{minipage}
|
||||||
|
\end{figure}
|
||||||
|
}
|
||||||
|
|
||||||
|
\begin{document}
|
||||||
|
|
||||||
|
\begin{titlepage}
|
||||||
|
\centering
|
||||||
|
\vspace*{0.22\textheight}
|
||||||
|
{\zihao{-0}\bfseries 《范式：起源》\par}
|
||||||
|
\vspace{0.45cm}
|
||||||
|
{\zihao{2}\bfseries 立体交互体验拆解\par}
|
||||||
|
\vspace{1.8cm}
|
||||||
|
{\large 作者：孙玉杰\par}
|
||||||
|
\vspace{0.35cm}
|
||||||
|
{\normalsize 文档版本：26/1/30\par}
|
||||||
|
\vfill
|
||||||
|
\rule{0.42\linewidth}{0.6pt}\par
|
||||||
|
\vspace{0.35cm}
|
||||||
|
{\small 研究拆解文档\par}
|
||||||
|
\end{titlepage}
|
||||||
|
|
||||||
|
\tableofcontents
|
||||||
|
\clearpage
|
||||||
|
|
||||||
|
\section{前言}
|
||||||
|
本文档旨在探讨《范式：起源》的立体交互机制。通过分析其设计逻辑、感官反馈、优势与代价，解析这套设计如何塑造了空间立体感，以及如何以对视听、判定以及内容进行设计在立体交互基础上实现了对手感体验的调优。
|
||||||
|
|
||||||
|
\section{游戏玩法机制简述}
|
||||||
|
\subsection{操作交互设计}
|
||||||
|
传统下落式音游的空间映射常常被限制在 X 轴（轨道）与 Y 轴（时间）构成的二维平面中进行演出和判定。
|
||||||
|
|
||||||
|
\begin{quote}
|
||||||
|
{\color{red!70!black}\small TODO: a to b 表述更新}
|
||||||
|
\end{quote}
|
||||||
|
然而，范式选择打破这一限制，扩展出 Z 轴表示深度，将玩家控制区域变化为 “四边 + 中心 + 深度” 的立体结构。
|
||||||
|
|
||||||
|
\begin{quote}
|
||||||
|
{\color{red!70!black}\small TODO: 具象形容 伪3d效果 不要默认觉得读者了解音游}
|
||||||
|
\end{quote}
|
||||||
|
范式的核心玩法要求玩家处理从屏幕中心向四周（上、下、左、右）发散的地键（Ground Note），同时也需要处理直接作用于屏幕中心的空键（Air Note）。
|
||||||
|
|
||||||
|
\singlefig{image1.png}{上图蓝色区域为玩家四周判定区域}
|
||||||
|
\singlefig{image2.png}{上图橙色区域为玩家屏幕中心判定区域}
|
||||||
|
\subsection{物件交互设计}
|
||||||
|
游戏通过两类交互物件为玩家构建了游玩的立体感，并为二者在设计上担任不同的手感职能。
|
||||||
|
|
||||||
|
\listitemline{0}{•}{地键（Ground Note）}
|
||||||
|
\listitemline{1}{•}{形态与手感：判定锚定在平面边缘，提供明确的上、下、左、右方位反馈。}
|
||||||
|
\listitemline{1}{•}{设计意图：交互上对标传统下落式X/Y轴判定，手感类似于传统下落式音游，但地键分布在四周会带来更大的玩家手部位移。}
|
||||||
|
\listitemline{0}{•}{空键（Air Note）}
|
||||||
|
\listitemline{1}{•}{形态与手感：悬浮在轨道中空间的正方形物件，判定更多得体现在何时而不是何处，需要结合音乐节奏预判时机。}
|
||||||
|
\listitemline{1}{•}{设计意图：引入了Z轴，建立纵深空间，与地键一起出现时一定程度上会增加读谱难度为玩家带来紧张感。手感从传统的点击转化到迎击。}
|
||||||
|
\begin{quote}
|
||||||
|
{\color{red!70!black}\small TODO: 手感差异在视觉上的表现 将主观体验转化为客观描述}
|
||||||
|
\end{quote}
|
||||||
|
\subsection{交互模式优势与代价与解决方案}
|
||||||
|
\subsubsection{优势}
|
||||||
|
内容设计空间升维：
|
||||||
|
|
||||||
|
\listitemline{0}{•}{相对于传统下落式音游，引入Z轴深度概念能够为游戏谱面设计新增维度，使设计者能够借这套机制设计一些特有的或者模拟街机音游的键型。}
|
||||||
|
大开大合的交互体感：
|
||||||
|
|
||||||
|
\listitemline{0}{•}{四边判定会迫使玩家的手腕和小臂参与到位移中来，带来大出张与大位移能够让手感从手指操作转化为肢体运动。}
|
||||||
|
\begin{quote}
|
||||||
|
{\color{red!70!black}\small TODO: 出张概念 以及 详细解释 越过判定中线}
|
||||||
|
\end{quote}
|
||||||
|
\subsubsection{代价}
|
||||||
|
手部遮挡：
|
||||||
|
|
||||||
|
\listitemline{0}{•}{在手序设计不佳的情况下手指点击空键或上边缘时会遮挡一部分读谱区，人类的手不能调透明度也不能穿模。体现在极端情况下将右手引导至左区，将左手引导至右区时必然会遮挡住一部分音符，同时也可能发生双手打架的情况，这是大部分移动端音游都会产生的问题，对手机玩家手感影响更甚。}
|
||||||
|
\begin{quote}
|
||||||
|
{\color{red!70!black}\small TODO: 出张的优势与代价 下部补充}
|
||||||
|
\end{quote}
|
||||||
|
变速错觉：
|
||||||
|
|
||||||
|
\listitemline{0}{•}{透视原理使音符在视觉上呈现非线性加速，导致越近越快，破坏了平面音游中距离等于时间的直观读谱逻辑。玩家必然更依赖音押而非目押，设备音频延迟的影响会被放大。}
|
||||||
|
\begin{quote}
|
||||||
|
{\color{red!70!black}\small TODO: 玩家适应成本 判定确认极端 加速度下落式玩家比普通情况下更依赖音押或目押}
|
||||||
|
\end{quote}
|
||||||
|
判定面的视觉模糊：
|
||||||
|
|
||||||
|
\listitemline{0}{•}{Z轴上的判定是一个面而非一条线。尤其在玩家处理Slider时，手指在纵深方向上是否偏离轨道难以直观感知，容易产生莫名其妙的失误。}
|
||||||
|
\begin{quote}
|
||||||
|
{\color{red!70!black}\small TODO: 学习成本}
|
||||||
|
\end{quote}
|
||||||
|
\subsubsection{解决方案}
|
||||||
|
针对变速错觉问题，范式除提供了音频延迟以及画面延迟的调整外，还提供了音符出现距离的调整，将音符出现距离拉近能够有效地缓解变速错觉问题。
|
||||||
|
|
||||||
|
但降低音符出现距离会缩减音符出现时长，导致影响玩家的信息接收量。降低音符出现距离的同时想要保持音符显示时长又需要提高谱面流速，会使不熟练的玩家难以反应。但其他轨道存在透视变速的音游也存在一样的问题，除提供的原理类似的上隐，只能靠玩家自己手动往轨道上方放纸条挡住变速区域，也牺牲了信息接收量。范式的降低音符出现距离帮助玩家省去了贴纸条的操作，作为系统功能来说，这是对变速错觉问题难以解决的妥协处理，业界也没有针对此问题的其他解决方案。信息接收量降低不完全是一件坏事，当同一时间大量音符出现在屏幕中时玩家会难以集中注意力去处理该点击哪个音符，信息接收量的降低能够提供一定的信息节食效果，帮助玩家集中注意力到该处理的音符上。
|
||||||
|
|
||||||
|
\begin{quote}
|
||||||
|
{\color{red!70!black}\small TODO: 上隐下隐目的 信息量 思考速度与时间}
|
||||||
|
\end{quote}
|
||||||
|
\url{https://www.bilibili.com/video/BV1N1NPe4E5R}
|
||||||
|
|
||||||
|
\singlefig{image3.png}{音符出现距离设置项}
|
||||||
|
手部遮挡问题的解决其一可以通过谱面的手序设计来绕过见后文手序引导分析，其二是为玩家提供物件大小调整项。足够大的物件能够为手机端玩家提供足够高的辨识度。同时游戏还提供了游戏区域比例来单独适配平板以及手机的显示区域。
|
||||||
|
|
||||||
|
\singlefig{image4.png}{游戏区域比例设置项}
|
||||||
|
\doublefig{image5.png}{手机显示比例}{image6.png}{平板显示比例}
|
||||||
|
判定面的视觉模糊可以通过调整判定缓解，见后文判定容错。
|
||||||
|
|
||||||
|
\section{视听反馈设计拆解}
|
||||||
|
范式在立体交互的基础上通过视觉欺骗、音效播放延迟优化以及触控延迟的可控调整的实现，制作了干脆不粘手的反馈效果。
|
||||||
|
|
||||||
|
\subsection{瞬间响应}
|
||||||
|
\listitemline{0}{•}{表现：当玩家触发判定时，Note会在第一帧立刻消失，立刻播放判定音效，并在目标位置触发火花特效、判定线高亮特效以及判定结果文字特效。}
|
||||||
|
\listitemline{0}{•}{设计意图：在缺乏音游设计知识的情况下可能会出现制作Note溶解动画的情况，}
|
||||||
|
\begin{quote}
|
||||||
|
{\color{red!70!black}\small TODO: 游戏类型与动画解释 原因与影响 音效设计组合}
|
||||||
|
\end{quote}
|
||||||
|
这会带来视觉残留导致手感拖泥带水。范式中Note触发即消失，并同时在判定目标位置生成触发特效，瞬间完成的视觉反馈以及音效的瞬间播放极大提高了操作的即时感。
|
||||||
|
|
||||||
|
\doublefig{image7.png}{判定开始}{image8.png}{特效响应}
|
||||||
|
\subsection{确认与引导}
|
||||||
|
\listitemline{0}{•}{表现：判定触发后，一条光流沿Z轴轨道向屏幕深处运动，同时火花向外爆开判定线高亮逐渐变暗，其中光流的颜色因玩家点击的Note的判定准度而变化。}
|
||||||
|
\listitemline{0}{•}{设计意图：}
|
||||||
|
\listitemline{1}{•}{打击延伸：为Note点击带来向内方向释放感，光流颜色加上火花特效能够同时增强玩家的“点到了”以及“唉爆了个绿”的确认感。}
|
||||||
|
\listitemline{1}{•}{视线重置：光流运动由近及远能够巧妙地将玩家视线从操作区重新引导回读谱区，为处理下一个Note做好准备。}
|
||||||
|
\triplefig{image9.png}{特效起始}{image10.png}{光流前进}{image11.png}{特效消失}
|
||||||
|
\singlefig{image12.png}{非“完全解密”光流颜色以及评价文本}
|
||||||
|
\listitemline{0}{•}{特殊情况}
|
||||||
|
\listitemline{1}{•}{表现：当玩家在短时间内连续触发多个Note判定时，判定线会前一个Note判定结束亮度降低后但未完全恢复到不高亮接受下一个Note时重新将高亮重置到最高亮度。}
|
||||||
|
\begin{quote}
|
||||||
|
{\color{red!70!black}\small TODO: }
|
||||||
|
\end{quote}
|
||||||
|
\listitemline{1}{•}{设计意图：能够隐性地在高密度环境下的近乎闪烁的高亮提示能为玩家保持快节奏状态下的火热手感。}
|
||||||
|
\triplefig{image13.png}{第一个Note触发时高亮}{image14.png}{第一个Note触发后高亮变暗}{image15.png}{第二个Note触发后}
|
||||||
|
\subsection{视觉避让}
|
||||||
|
\listitemline{0}{•}{表现：评价文字在出现后并非静止消失，而是垂直轨道缓慢上移，并逐渐溶解。按住Hold时评价文字会一直叠加生成并重复上述生命周期。}
|
||||||
|
\listitemline{0}{•}{设计意图：文字垂直轨道上移是一种抗干扰设计，为了不使文字挡住后方飞来的Note，防止文字遮挡谱面导致读谱失误。按住Hold时叠加出现的判定文字以及其特有的蓝色火花会给玩家一种“我正一直接着”的感觉。}
|
||||||
|
\triplefig{image16.png}{文字出现}{image17.png}{文字上移}{image18.png}{文字溶解}
|
||||||
|
\subsection{深度感知的视觉补偿}
|
||||||
|
在平面上表现Z轴的会带来距离感缺失导致玩家不能够准确判断判定时机，范式除上文提到的出现距离调整项，还提供了一个巧妙的解决方案。
|
||||||
|
|
||||||
|
\listitemline{0}{•}{表现：空键在平面目标点上映射方框，其中映射目标点内部方块随着空键靠近平面而逐渐填满外框时，即为最佳击打时机。}
|
||||||
|
\listitemline{0}{•}{设计意图：将模糊的依赖于透视经验以及音乐节奏时机的判断转化为浮现式音游的图形重合判断。这为玩家提供了显性的、可训练的时机信号，能够极大地稳定Z轴交互的手感预期，使高密度情况下精确操作成为可能。}
|
||||||
|
\begin{quote}
|
||||||
|
{\color{red!70!black}\small TODO: 回头拆一下cy2}
|
||||||
|
\end{quote}
|
||||||
|
\triplefig{image19.png}{补偿图形出现}{image20.png}{补偿图形重合}{image21.png}{完成判定}
|
||||||
|
\subsection{动画编排}
|
||||||
|
经过对实机画面的逐帧逆向观测后，我发现游戏通过对判定动画设置了三条曲线构建了富有层次感的反馈体验。基于玩家视角的观测数据中光流、火花与评价文字在约27帧的生命周期内呈现出明显的能量分布差异，明显可以观察到动画节奏已经过仔细编排。
|
||||||
|
|
||||||
|
\listitemline{0}{•}{光流}
|
||||||
|
\listitemline{1}{•}{表现：光流动画响应最快，在前4帧左右迅速到达峰值，随后立刻线性衰减。}
|
||||||
|
\listitemline{1}{•}{设计意图：光流负责提供第一时间的触控确认。它负责快速反馈，同时快速的衰减和向Z轴深处的位移，起到将玩家视线从判定区引导回屏幕中心的作用。}
|
||||||
|
\listitemline{0}{•}{火花}
|
||||||
|
\listitemline{1}{•}{表现：火花动画起步爆发较快，但直到第9-10帧才达到峰值，比光流晚5帧。}
|
||||||
|
\listitemline{1}{•}{设计意图：火花动画与光流动画峰值的时间错层除了体现游戏主题的信号的时序错位，更多的在视觉上能够提供一定的重量感。若火花和光流峰值完全同步则会使效果显得单薄，相对滞后的峰值能够为整体提供视觉上的厚度。}
|
||||||
|
\listitemline{0}{•}{评价文字}
|
||||||
|
\listitemline{1}{•}{表现：峰值最持久，在第7-13帧保持了长达数帧的峰值平台期，随后才开始衰减。}
|
||||||
|
\listitemline{1}{•}{设计意图：评价文字的首要人物是传递信息，使玩家除观察光流颜色还能够在余光中凭判定文字确认判定结果。}
|
||||||
|
\subsection{音效设计}
|
||||||
|
\listitemline{0}{•}{表现：范式的Note音效种类并不像其他移动端音游那么奢侈，反而所有Note全部使用一种音效，相当地克制。主观听感上音效和按动笔发出的声音一样清脆，音调又不像铃铛一样高，有一定厚度感，听感节奏也以快速爆发到线性衰减为主。}
|
||||||
|
\begin{quote}
|
||||||
|
{\color{red!70!black}\small TODO: 音效音色设计意图以及视觉与音效联动 视听效果搭配会产生差异 \&瞬间相应}
|
||||||
|
\end{quote}
|
||||||
|
\listitemline{0}{•}{设计意图：统一的音效除节省成本外还能够为玩家带来统一的确认感，同时音色不强求大高频，存在一定低频成分不会使玩家一直听到这一种音效感到枯燥。}
|
||||||
|
\listitemline{0}{•}{缺陷：虽然音色设计使单音效足够耐听，但可以考虑学习《舞萌DX》或其他音游，为不同的判定制作不同的音效。使玩家在恰当的时机击打音符时获得更强烈的正反馈。}
|
||||||
|
\section{判定逻辑设计拆解}
|
||||||
|
\subsection{判定窗口}
|
||||||
|
游戏内，物件有四级判定：
|
||||||
|
|
||||||
|
\listitemline{0}{•}{Precisely Decrypted（±30ms，俗称“大D”）}
|
||||||
|
\listitemline{0}{•}{Imprecisely Decrypted（±60ms，俗称“小D”）}
|
||||||
|
\listitemline{0}{•}{Received（±120ms，俗称“绿”）}
|
||||||
|
\listitemline{0}{•}{Lost（+120ms后未响应）}
|
||||||
|
其中最佳判定Precisely Decrypted的判定窗口为±30ms。这为游戏添加了一种硬核准度要求，需要玩家达成极高的准确率，同时区分开的判定的视觉效果上也能给出硬核的手感体验。
|
||||||
|
|
||||||
|
\url{https://zhuanlan.zhihu.com/p/517535819}
|
||||||
|
|
||||||
|
\url{http://www.gugu.fun/iidxsp/}
|
||||||
|
|
||||||
|
但手感上的硬核容易劝退音游水平不高以及完全没有接触过音游的玩家，不过范式的产品定位为硬核音游，此问题属于制作团队的取舍方向问题。
|
||||||
|
|
||||||
|
或可借鉴《舞萌DX》的保护套设计，被设置有保护套的音符只要在判定窗口内被点击即判定大D。将此设计应用在普通模式下，为副歌重复的配置组合的第一次重复设置保护套供玩家学习试错，或在谱面高潮结束后为低密度冷却段设置一些保护套防止玩家在情绪降温以及操作压力下降期间出现失误。同时为保留挑战性，在段位模式则不启用保护套。
|
||||||
|
|
||||||
|
\subsection{判定容错}
|
||||||
|
范式中Slider无尾判设计，不需要计算松手时机。同时，按住采用的是以密度为基础的判定，判定区域可达三分之一判定线宽度，这可以让玩家不时刻关注Slider的动向，且密度判定支持玩家进行换手操作。
|
||||||
|
|
||||||
|
\singlefig{image23.png}{判定宽容度展示}
|
||||||
|
无Early Lost设计也能够让玩家过早点击时不会判错。
|
||||||
|
|
||||||
|
这些设计都是为立体玩法服务的减负机制，在玩家需要同时处理Z轴深度、四边位置和复杂键型时，能够减少次要细节失误带来的挫败感，让注意力集中在迎面生成的音符的打击判断上。
|
||||||
|
|
||||||
|
\subsection{生存压力}
|
||||||
|
玩家每次游玩时共有100点血量可用，在普通模式下玩家最大每次失误扣血5点，最多每次回血0.5点，比例高达10:1。这创造了一定的生存压力，放大了每一次失误的负面反馈。这种如履薄冰的紧张感本身就是手感的一部分，能够让玩家保持全程高压下的专注，通关本身也能够带来强烈过后如释重负的成就手感。同时能够让技术能力不匹配当前难度谱面的玩家认识到自身水平不足，在其积累足够的能力时成功通关能够带来巨大的挑战胜利成就感。
|
||||||
|
|
||||||
|
\section{谱面设计拆解}
|
||||||
|
\subsection{手序引导}
|
||||||
|
在传统平面音游中玩家看到音符的决策链是：看到音符->判断落点->手指移动点击，而范式中由于立体机制的存在，玩家的决策链变为：看到音符->判断类型(空/地)->判断立体位置->规划手指移动->点击。
|
||||||
|
|
||||||
|
手序引导直接干预了规划手指移动这一环节，它通过谱面的音符摆放位置以及视觉提示预先告诉玩家“你应该用哪根手指放哪里，另一根手指再放哪里”，能够极大地降低玩家在短时间内需要处理的信息计算量。
|
||||||
|
|
||||||
|
\singlefig{image24.png}{手序引导其一}
|
||||||
|
\singlefig{image25.png}{手序引导其二}
|
||||||
|
如上两图所示，绿色表示左手手指设计上的移动路径，红色表示右手手指设计上的移动路径，玩家在观察到此Slider时可以立刻识别到自己的手指应该如何摆放。图1和图2是同一谱面的连续过程，可以观察到当左右手按照预期设计摆放到图1所示位置后，在图2中可以立刻让玩家以最小的位移幅度迎接下一音符。
|
||||||
|
|
||||||
|
同时若没有手序引导，高难度谱面可能会变成手指在屏幕上乱打。清晰的手序引导能够教会玩家如何有章法地使用手法去游玩一段复杂的谱面，同时范式追求的模拟街机的手感也需要手序引导这种教学和体验强化手段。但谱师若在谱面上过于激进地塞穿手、反手以及跨手引导等会导致玩家学习成本提升，容易制作出褒贬不一的谱面。如《Arcaea》就有非常类似的手序引导设计，对玩不来这套的玩家来说难以适应，但这也是《Arcaea》的知名标签之一。
|
||||||
|
|
||||||
|
\subsection{键型设计}
|
||||||
|
\subsubsection{节奏把控}
|
||||||
|
\begin{quote}
|
||||||
|
{\color{red!70!black}\small TODO: 与音乐节奏关联的谱面节奏把控以及印象点设计 采音与配置（采音为骨架 键型为血肉） 虚空采音}
|
||||||
|
\end{quote}
|
||||||
|
游戏可以通过将基础的物件通过手序引导摆放等手段进行编排来控制谱面游玩节奏。
|
||||||
|
|
||||||
|
对节奏的把控除用于服务音乐情绪，也要服务玩家对谱面的认知。范式的大部分谱面设计都遵循着“教学——展开——爆发——冷却”的节奏循环。
|
||||||
|
|
||||||
|
其中教学性段落用于在副歌到来前预先以副歌高潮处可能出现的键型组合的低密度版展示副歌处手序和键型动机。让玩家在低压力情况下预演复杂操作，积累信心以及认知，避免高潮到来时手足无措，同时这也是对立体机制高学习成本的直接补偿。
|
||||||
|
|
||||||
|
在展开段落时在已预演的操作基础上叠加空键维度或提高密度来提升挑战性，同时使玩家的注意力稳步进入到活跃状态，为高潮部分做好准备。
|
||||||
|
|
||||||
|
高潮段落将视觉、听觉、操作与情绪完全同步，制造心流状态。全部设计在这里集中爆发，让玩家在极限压力下成功内化整套空键映射，产生人机一体的沉浸感，失误的痛苦以及成功的狂喜在此段被最大化。
|
||||||
|
|
||||||
|
冷却段即休息段，给玩家降温，降低密度以及位移量，并完成音乐情感的收尾，防止玩家因为持续的高压产生疲惫以及厌倦感。
|
||||||
|
|
||||||
|
谱面节奏失控会严重影响玩家游玩过程中的节奏期望，进而影响手感体验。
|
||||||
|
|
||||||
|
\subsubsection{配置组合}
|
||||||
|
除节奏外，键型配置组合本身也会给玩家带来操作上的乐趣，范式的立体交互还带来了更多的设计空间。
|
||||||
|
|
||||||
|
\begin{quote}
|
||||||
|
{\color{red!70!black}\small TODO: 玩家io改变带来的设计内容空间变化}
|
||||||
|
\end{quote}
|
||||||
|
\triplefig{image26.png}{滑动型}{image27.png}{肘击型}{image28.png}{转圈型}
|
||||||
|
如上图中玩家在游玩这三种键型时，手部会产生大位移。同时音乐在此为Bass Drop时玩家手部位移以及心理期待会与音乐同步，提供巨大且明确的情绪释放窗口为玩家带来极大的操作爽感。
|
||||||
|
|
||||||
|
\triplefig{image29.png}{天地交互}{image30.png}{交互}{image31.png}{子弹叠}
|
||||||
|
上图中玩家在游玩这三种键型时，通常是在音乐的Kick段。电音中Kick是一种高密度高能量的底鼓段落，游戏中将其转化为一种高速的音符交互，要求玩家的注意力以及手指在平面上的移动速度必须跟上音乐的节奏。在这种高压段落下玩家会停止思考，
|
||||||
|
|
||||||
|
//停止思考分情况，底力与复杂谱面解析
|
||||||
|
|
||||||
|
完全依靠肌肉记忆以及节奏本能进入心流状态。此时玩家不只是听见密集的鼓点，在心理上这更是自己去亲手敲出来的底鼓声，使玩家自身成为节奏的一部分。
|
||||||
|
|
||||||
|
交互中特殊的一点是高BPM音乐中的32分节奏不会直接转化为32分交互，而是会转化为16分或更低切分的交互。此时追求节奏的保真会影响到谱面的可玩性，甚至影响手感。
|
||||||
|
|
||||||
|
总的来说键型配置对玩家意味着对音乐的演绎，游玩过程中将玩家的心理期待、操作节奏以及音乐节奏相统一，随着音乐释放情绪，这成为手感的一部分，使玩家沉浸其中。
|
||||||
|
|
||||||
|
\section{总结}
|
||||||
|
《范式：起源》通过结合polytone以及dynamix的玩法成功构建了一套极具特色的立体交互系统。这套设计的核心价值不止在于视觉上的空间延伸，更在于其通过一系列的视觉补偿与判定优化，解决了立体空间下读谱逻辑非线性带来的手感体验难点。
|
||||||
|
|
||||||
|
同时在内容设计上通过手序引导、谱面节奏把控以及配置组合，给予玩家一切尽在掌控的手感体验。
|
||||||
|
|
||||||
|
综上，《范式：起源》的成功不仅在于交互上的创新尝试，更在于用极致的细节调优去解决潜在问题，最后给玩家交出了一套逻辑自洽、极其顺手的立体交互体验设计。
|
||||||
|
|
||||||
|
\section{引用}
|
||||||
|
\url{https://paradigmrebootzh.miraheze.org/wiki/%E6%B8%B8%E6%88%8F%E7%9B%B8%E5%85%B3#%E5%88%86%E6%95%B0%E8%AE%A1%E7%AE%97}
|
||||||
|
|
||||||
|
\url{https://www.bilibili.com/video/BV1bN6JYkEUw}
|
||||||
|
|
||||||
|
\url{https://www.bilibili.com/video/BV1UD421g7Zi}
|
||||||
|
|
||||||
|
\url{https://gugu.fun/yinyoutonglun/}
|
||||||
|
|
||||||
|
\url{https://zhuanlan.zhihu.com/p/453517424}
|
||||||
|
|
||||||
|
\url{https://www.bilibili.com/video/BV15j411o7rA}
|
||||||
|
|
||||||
|
|
||||||
|
\end{document}
|
||||||
@@ -0,0 +1,5 @@
|
|||||||
|
这是你的新*仓库*。
|
||||||
|
|
||||||
|
写点笔记，[[创建链接]]，或者试一试[导入器](https://help.obsidian.md/Plugins/Importer)插件!
|
||||||
|
|
||||||
|
当你准备好了，就将该笔记文件删除，使这个仓库为你所用。
|
||||||
@@ -0,0 +1,87 @@
|
|||||||
|
![[Pasted image 20260616203917.png]]
|
||||||
|
|
||||||
|
我有个想法，把音游里的“判定”拆成两个步骤：先定位，再判定。
|
||||||
|
|
||||||
|
大多数音游里，玩家在按下那一刻，同时完成了目标选择和时机判断。差别无非是几键、几轨，或者屏幕上的哪个点。但这个想法是把这两件事拆开：玩家先用摇杆、方向键或 `WASD`，把指针移动到 `8 向` 环形扇区中的正确位置；然后再在拍点按下确认键，完成真正的判定。
|
||||||
|
|
||||||
|
这样一来，它会让人想到 `maimai` 这种强调空间输入感的音游，但核心并不是“去敲某个外圈位置”，而是“在拍点到来前，先把自己摆到正确的位置上”。节奏不再只是等拍子，而是包含了找位、转位和压拍这三个连续动作。
|
||||||
|
|
||||||
|
## 为什么这个方向有意思
|
||||||
|
|
||||||
|
- 它把原本主要考时间窗的输入，变成同时考空间感和节奏感的输入。
|
||||||
|
- 它天然适配手柄。摇杆负责找位，面键、肩键或扳机负责确认，整个动作会比纯平铺按键更有身体参与感。
|
||||||
|
- 它的观战可读性也更强。旁观者很容易看出玩家到底是“没转到位”，还是“已经对准了，但拍点没压准”。
|
||||||
|
|
||||||
|
## 这个核心操作怎么成立
|
||||||
|
|
||||||
|
一个最自然的结构，是让判定区表现为一个 `8 向` 环形盘面。每个 `note` 对应一个扇区，玩家需要先把焦点停在正确方向，再在正确时机按下判定键。
|
||||||
|
|
||||||
|
基础输入可以理解为：
|
||||||
|
|
||||||
|
- 方向输入负责定位。
|
||||||
|
- 确认输入负责判定。
|
||||||
|
|
||||||
|
这里的固定世界方向约定也可以直接定死：`W` 在上，`S` 在下，`A` 在左，`D` 在右。旋转时改变的是 `note` 当前转到了哪个方向，不是这套方向约定本身。
|
||||||
|
|
||||||
|
这看起来像是把传统多键音游换成了圆环，但体验上的差别其实很大。传统按键音游里，按错更多像是“识谱错误”；而这里的失误，往往更像“身体没有提前到位”。这会让谱面阅读从“看见了就按”，变成“先规划动作路径，再把节奏打实”。
|
||||||
|
|
||||||
|
## 这套系统可以怎么展开
|
||||||
|
|
||||||
|
### 1. 基础 note
|
||||||
|
|
||||||
|
最基础的 `note`，不该只是“某个方向亮了就按”，而应该围绕转位本身去形成节奏句子。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 同一区连续确认，考的是稳定压拍。
|
||||||
|
- 相邻区快速切位，考的是短距离移动和节奏衔接。
|
||||||
|
- 对向区跳转，考的是提前找位和重拍落点。
|
||||||
|
- 连续重拍确认，则能把“先摆过去，再敲下去”的动作感做得非常明显。
|
||||||
|
|
||||||
|
这样一来，谱面的阅读重点就会从“这一拍按哪个键”，变成“这一小节我要怎么走位”。
|
||||||
|
|
||||||
|
### 2. 长按、滑移、连打
|
||||||
|
|
||||||
|
这套系统最自然的延展，并不是继续加更多方向，而是让“定位”本身变成一种可持续、可移动的状态。
|
||||||
|
|
||||||
|
- 长按可以理解为：保持在某个方向上持续成立，同时按节奏维持，或者在结束点释放。
|
||||||
|
- 滑移可以理解为：沿着环形扇区移动，要求玩家一边转位，一边在路径上保持时值，或者经过特定拍点。
|
||||||
|
- 连打则适合做成同一区的密集确认，或者两个相邻区之间来回切位的抖动句型。
|
||||||
|
|
||||||
|
这些内容的好处在于，它们都不是额外硬塞进来的特殊规则，而是从“先定位、后判定”这个核心里自然长出来的。
|
||||||
|
|
||||||
|
### 3. 高级机制
|
||||||
|
|
||||||
|
进阶谱面里，可以让轨道或轮盘参与变化，但判定方向本身保持固定；这更适合作为高级机关，而不是基础常态。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 整个轮盘缓慢自转，让 `note` 在屏幕上的目标方向发生变化，但 `W / A / S / D` 对应的判定方向不变。
|
||||||
|
- 某一段临时反向旋转，让既有动作路径被打乱。
|
||||||
|
- 旋转速度随乐句增强，在高潮段把身体感进一步推高。
|
||||||
|
- 自转和滑移 `note` 叠加，让玩家不只是追节拍，还要处理相对运动。
|
||||||
|
|
||||||
|
更具体地说，如果一个 `note` 原本沿着 `A` 这一侧过来，但在旋转中转到了 `W` 的位置，那么玩家此刻就该按 `W` + 确认，而不是记住它“出身于 A”。
|
||||||
|
|
||||||
|
这里最重要的是克制。只有在玩家已经熟悉静态 `8 向` 盘面之后，旋转才会成为“有意思的干扰”，而不是单纯的认知负担。
|
||||||
|
|
||||||
|
## 为什么它适合主机和 PC
|
||||||
|
|
||||||
|
这个点子天然偏手柄，但并不等于键盘只是勉强兼容。
|
||||||
|
|
||||||
|
手柄上，左摇杆或方向输入负责定位，面键、肩键或扳机负责确认，整个动作会非常接近“先把身体摆过去，再把拍点敲下去”的感觉。这种分工比传统多键平铺更容易形成空间感，也更适合主机和客厅场景。
|
||||||
|
|
||||||
|
`PC` 上则可以用 `WASD` 或方向键做 `8 向` 定位，再用 `Space` 或其他主键做确认。这样虽然少了一些摇杆的圆润感，但逻辑依然成立，而且对习惯键盘音游的玩家来说，也能很快理解“定位是持续状态，判定是独立动作”这件事。
|
||||||
|
|
||||||
|
换句话说，它不是“PC 兼容的主机玩法”，而是一套两端都能成立、但在手柄上更容易显出身体感和转位手感的结构。
|
||||||
|
|
||||||
|
## 关键难点
|
||||||
|
|
||||||
|
- 玩家必须一眼看懂自己到底是没对准方向，还是拍点没压准。不然失败反馈会很混。
|
||||||
|
- 如果滑移、快速转位和旋转轨道叠得太早，学习门槛会从“有新意”直接跳到“看不懂自己在干什么”。
|
||||||
|
- 视觉表现必须服务于动作规划。玩家需要能预判接下来应该往哪边走，而不是被迫临拍乱转。
|
||||||
|
- 如果谱面设计最后只是把它当成“八个方向的键位替代”，那这个系统的空间感优势就会消失，只剩下一层更麻烦的操作壳。
|
||||||
|
|
||||||
|
## 一句话概括
|
||||||
|
|
||||||
|
这不是把音游按键排成一个圆，而是把一次判定拆成“方向定位 + 节奏确认”，让玩家在每个拍点之前，就先参与找位、转位和动作路径的组织。
|
||||||
Binary file not shown.
|
After Width: | Height: | Size: 246 KiB |
@@ -0,0 +1,228 @@
|
|||||||
|
上级索引：[[策划索引]]
|
||||||
|
|
||||||
|
|
||||||
|
很多人一提到 IP 打造，第一反应是“做一个世界观”“做几个角色”“起一个响亮名字”。
|
||||||
|
|
||||||
|
这种理解不能说完全错，因为成熟 IP 确实常常会有鲜明设定、强识别度角色和完整世界观。但如果把 IP 打造只理解成“做一套设定外壳”，那就还是太浅了。
|
||||||
|
|
||||||
|
因为 IP 真正成立的地方，往往不是名词数量，也不是设定体量，而是玩家为什么愿意记住它、反复回到它，并且持续关心这个世界里还会发生什么。
|
||||||
|
|
||||||
|
换句话说，IP 打造不是单纯做包装，而是在搭一个能持续生长的内容核心。
|
||||||
|
|
||||||
|
## IP 打造到底在做什么
|
||||||
|
|
||||||
|
如果简单粗暴地概括，IP 打造通常是在回答下面这些问题：
|
||||||
|
|
||||||
|
- 这个作品到底想表达什么
|
||||||
|
- 玩家会因为什么情感被它抓住
|
||||||
|
- 哪些角色会承载这份情感
|
||||||
|
- 这些角色之间会形成什么关系和冲突
|
||||||
|
- 世界观怎样放大这些关系与冲突
|
||||||
|
- 这套内容为什么值得被持续扩展
|
||||||
|
|
||||||
|
也就是说，IP 打造真正要处理的，不只是“看起来像不像一个完整世界”，而是：
|
||||||
|
|
||||||
|
- 它有没有清晰母题
|
||||||
|
- 它有没有让人愿意持续关注的人物
|
||||||
|
- 它有没有能不断生产内容的关系结构
|
||||||
|
- 它的世界有没有支撑这些内容长期展开
|
||||||
|
|
||||||
|
## IP 不是先做设定，而是先抓住一个值得反复回来的核心
|
||||||
|
|
||||||
|
很多 IP 内容做不起来，并不是因为设定不够多，而是因为一开始就没有抓住真正的内容核心。
|
||||||
|
|
||||||
|
有的人会先想：
|
||||||
|
|
||||||
|
- 我要做一个很大的世界观
|
||||||
|
- 我要做一个很酷的阵营体系
|
||||||
|
- 我要做一个看起来很高级的题材组合
|
||||||
|
|
||||||
|
这些当然都可能是内容的一部分，但它们通常还不是起点。
|
||||||
|
|
||||||
|
更稳的一种方式，往往是先回到更底层的问题：
|
||||||
|
|
||||||
|
- 我到底想让人记住什么情感
|
||||||
|
- 我想讨论什么命题
|
||||||
|
- 玩家在这个作品里最应该被什么关系打动
|
||||||
|
- 这个故事最核心的矛盾是什么
|
||||||
|
|
||||||
|
也就是说，IP 打造真正的起点，通常不是百科，而是母题。
|
||||||
|
|
||||||
|
## 母题，是 IP 的情感中轴
|
||||||
|
|
||||||
|
这里说的母题，不是单纯的剧情梗概，也不是一句空泛口号。
|
||||||
|
|
||||||
|
它更像是一种会反复出现在角色选择、关系冲突和故事推进中的核心命题。
|
||||||
|
|
||||||
|
例如一个作品的母题可能是：
|
||||||
|
|
||||||
|
- 亲情与失去
|
||||||
|
- 自由与秩序
|
||||||
|
- 成长与代价
|
||||||
|
- 理想与现实
|
||||||
|
- 救赎与背叛
|
||||||
|
|
||||||
|
母题的价值，在于它能把很多看起来分散的内容串起来。
|
||||||
|
|
||||||
|
如果没有母题，角色容易只是设定拼盘，世界观容易只是名词堆积，剧情也容易变成一连串事件。
|
||||||
|
|
||||||
|
但一旦母题清楚，很多设计判断就会更容易有依据：
|
||||||
|
|
||||||
|
- 这个角色为什么会这么选
|
||||||
|
- 这段冲突为什么成立
|
||||||
|
- 这个世界为什么会长成这样
|
||||||
|
- 这个故事为什么还值得继续往下讲
|
||||||
|
|
||||||
|
所以 IP 打造里很重要的一步，不是先把内容铺大，而是先找到那条真正值得持续书写的情感中轴。
|
||||||
|
|
||||||
|
## 角色是 IP 最容易被玩家直接记住的入口
|
||||||
|
|
||||||
|
玩家通常不会先记住你的设定文档，而是先记住人。
|
||||||
|
|
||||||
|
因此，IP 里角色的作用通常不是“填进世界观里的人物单位”，而是承载玩家情感、带着玩家理解世界、并推动故事继续展开的核心媒介。
|
||||||
|
|
||||||
|
这也是为什么很多人谈到某个作品时，最先想起的往往不是百科背景，而是某个角色、某段关系、某个选择时刻。
|
||||||
|
|
||||||
|
## 一个角色是否成立，重点不只是“人设鲜明”
|
||||||
|
|
||||||
|
角色设计最容易做偏的一点，是停留在标签层。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 冷酷
|
||||||
|
- 热血
|
||||||
|
- 病娇
|
||||||
|
- 温柔
|
||||||
|
- 傲慢
|
||||||
|
|
||||||
|
这些标签可以帮助快速识别，但它们还远远不够。
|
||||||
|
|
||||||
|
因为真正让玩家记住角色的，通常不是标签，而是角色在关键处境中的稳定选择。
|
||||||
|
|
||||||
|
也就是说，角色设计通常要继续往下想：
|
||||||
|
|
||||||
|
- 这个角色真正想要什么
|
||||||
|
- 它最怕失去什么
|
||||||
|
- 它身上最大的矛盾是什么
|
||||||
|
- 它会为了什么坚持，又会为了什么妥协
|
||||||
|
- 它在压力下会做出怎样的选择
|
||||||
|
|
||||||
|
角色一旦具备这些内核，它才不只是“有设定”，而是开始变成一个能持续产出内容的人。
|
||||||
|
|
||||||
|
## 角色关系，往往比单个角色更能支撑长线内容
|
||||||
|
|
||||||
|
很多 IP 真正有生命力的地方，不只是某一个人物本身，而是人物之间的关系网络。
|
||||||
|
|
||||||
|
因为单个角色再鲜明，如果长期没有关系张力，内容很快也会变平。
|
||||||
|
|
||||||
|
常见值得持续书写的关系，往往包括：
|
||||||
|
|
||||||
|
- 同盟与背离
|
||||||
|
- 师徒与继承
|
||||||
|
- 亲情与亏欠
|
||||||
|
- 爱与无法靠近
|
||||||
|
- 理念一致但道路相反
|
||||||
|
- 彼此依赖却互相伤害
|
||||||
|
|
||||||
|
关系的价值，在于它天然会带来冲突、变化和选择。
|
||||||
|
|
||||||
|
也就是说，角色关系不是附属装饰，而是 IP 能不能持续生长的重要引擎。
|
||||||
|
|
||||||
|
如果角色之间只是静态地“互相认识”，那内容很快就会停住；但如果关系里持续存在期待、误解、利益、信任和代价，故事自然就有了继续推进的动力。
|
||||||
|
|
||||||
|
## 世界观不是背景板，而是冲突生产器
|
||||||
|
|
||||||
|
世界观最容易被做成“设定陈列室”。
|
||||||
|
|
||||||
|
看起来名词很多、历史很厚、阵营很多，但真正进入内容后，却发现这些东西并没有在驱动任何重要关系和选择。
|
||||||
|
|
||||||
|
一个有效的世界观，重点通常不在于“大”，而在于“能不能制造问题”。
|
||||||
|
|
||||||
|
也就是说，它应该至少能够支撑这些事：
|
||||||
|
|
||||||
|
- 为什么角色会处在这样的处境里
|
||||||
|
- 为什么某些冲突无法轻易解决
|
||||||
|
- 为什么不同立场之间天然会碰撞
|
||||||
|
- 为什么这个世界中的选择会有代价
|
||||||
|
|
||||||
|
所以世界观的真正作用，不是给内容贴一层高级皮，而是让角色的命运和冲突有扎实土壤。
|
||||||
|
|
||||||
|
## 好的世界观，往往既要能解释过去，也要能推动未来
|
||||||
|
|
||||||
|
一个成熟世界观通常要同时承担两层功能：
|
||||||
|
|
||||||
|
- 解释：让当前故事看起来合理
|
||||||
|
- 推动：让未来还能继续长内容
|
||||||
|
|
||||||
|
前者是在回答“为什么现在会是这样”，后者是在回答“接下来还会发生什么”。
|
||||||
|
|
||||||
|
如果世界观只能解释过去，它会更像设定资料；如果它还能不断制造新问题、新关系和新视角，它才更像真正的 IP 土壤。
|
||||||
|
|
||||||
|
这也是为什么世界观设计不能只盯历史沿革，还要看：
|
||||||
|
|
||||||
|
- 现在的秩序稳不稳定
|
||||||
|
- 不同势力之间有没有持续摩擦
|
||||||
|
- 规则有没有天然的不公平或代价
|
||||||
|
- 角色有没有可能因为这个世界而被迫改变
|
||||||
|
|
||||||
|
只有这样，世界观才不会只是静态说明书。
|
||||||
|
|
||||||
|
## IP 的识别度，不只是视觉符号，而是整体表达口径
|
||||||
|
|
||||||
|
很多人谈 IP 识别度时，容易先想到 Logo、服装、武器、颜色、标志物。
|
||||||
|
|
||||||
|
这些当然重要，但真正稳定的识别度，通常不只是视觉层，而是多层表达共同形成的结果。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 角色说话方式是否统一
|
||||||
|
- 世界中的命名方式是否统一
|
||||||
|
- 价值观和情绪气质是否统一
|
||||||
|
- 代表性场景、关系和矛盾是否反复强化
|
||||||
|
|
||||||
|
也就是说，识别度不是单个图腾，而是作品长期重复输出的那套表达习惯。
|
||||||
|
|
||||||
|
当玩家一看到某种语气、某种关系张力、某种世界气质，就能立刻联想到这个作品时，IP 才真正开始长出自己的脸。
|
||||||
|
|
||||||
|
## IP 打造最终要面对的，是“持续生产能力”
|
||||||
|
|
||||||
|
很多内容一开始也许有亮点，但没有办法持续扩展。
|
||||||
|
|
||||||
|
原因通常不是起点完全不对，而是结构不够稳。
|
||||||
|
|
||||||
|
IP 是否具备持续生产能力，往往要看这些问题：
|
||||||
|
|
||||||
|
- 母题能不能支撑多段故事
|
||||||
|
- 角色关系能不能持续变化，而不是一轮就耗尽
|
||||||
|
- 世界观能不能承载新视角、新冲突和新阶段
|
||||||
|
- 内容扩展时，是否还能维持原有气质和识别度
|
||||||
|
|
||||||
|
这也是为什么 IP 打造不能只考虑第一印象。
|
||||||
|
|
||||||
|
第一眼吸引人，只能说明它有入口；但只有当内容可以不断扩展、不断变化，同时又不丢掉核心时，它才真正具备 IP 的长线价值。
|
||||||
|
|
||||||
|
## IP 打造里一个常见误区，是把“内容多”误认为“IP强”
|
||||||
|
|
||||||
|
这是很常见的问题。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 设定文很多
|
||||||
|
- 阵营很多
|
||||||
|
- 名词很多
|
||||||
|
- 角色很多
|
||||||
|
- 历史很长
|
||||||
|
|
||||||
|
这些都可能让内容看起来很“满”，但并不自动等于 IP 强。
|
||||||
|
|
||||||
|
如果这些东西没有共同指向同一个母题，没有被角色关系真正带起来，也没有在世界里形成清晰冲突，那么它们很容易只是信息堆积。
|
||||||
|
|
||||||
|
所以 IP 强不强，最终看的不是体量，而是凝聚力。
|
||||||
|
|
||||||
|
## 总结
|
||||||
|
|
||||||
|
IP 打造并不是单纯做世界观、做角色设定或者做一个看起来完整的题材包装。
|
||||||
|
|
||||||
|
它真正要做的，是先找到一个值得持续书写的母题，再用角色、关系和世界观把这条情感中轴不断具体化，并最终沉淀成一种有识别度、也有持续生长能力的内容结构。
|
||||||
|
|
||||||
|
说到底，IP 真正成立的地方，不是它写了多少，而是它有没有让人愿意一直记着、一直跟下去。
|
||||||
@@ -0,0 +1,191 @@
|
|||||||
|
上级索引：[[策划索引]]
|
||||||
|
|
||||||
|
|
||||||
|
很多人一提到关卡策划，第一反应是“做地图的人”或者“摆场景的人”。
|
||||||
|
|
||||||
|
这种理解不能说完全错，因为关卡策划当然会碰地图、碰场景、碰路径、碰点位。但如果把关卡策划只理解成“把内容摆进一个空间里”，那就还是太窄了。
|
||||||
|
|
||||||
|
因为关卡策划真正负责的，往往不是空间本身，而是玩家在这个空间里会经历什么、看到什么、被引导去做什么，以及整段体验是如何被组织起来的。
|
||||||
|
|
||||||
|
换句话说，关卡策划不是单纯做地形，而是在设计玩家的空间体验。
|
||||||
|
|
||||||
|
## 关卡策划到底在做什么
|
||||||
|
|
||||||
|
如果简单粗暴地概括，关卡策划处理的通常是下面几件事：
|
||||||
|
|
||||||
|
- 玩家会从哪里进入一段内容
|
||||||
|
- 会在什么路径上移动、停留、观察和战斗
|
||||||
|
- 会在什么时机遇到目标、障碍、危险和奖励
|
||||||
|
- 一段内容的节奏如何推进、转折和收束
|
||||||
|
- 关卡空间如何和玩法、美术、剧情、系统共同服务体验
|
||||||
|
|
||||||
|
也就是说，关卡策划真正关心的，不只是“这个地方长什么样”，而是：
|
||||||
|
|
||||||
|
- 玩家在这里会不会迷路
|
||||||
|
- 玩家会不会觉得无聊或者过载
|
||||||
|
- 空间本身有没有支撑玩法
|
||||||
|
- 战斗、探索、解谜或叙事有没有被组织得足够清楚
|
||||||
|
|
||||||
|
## 关卡策划不是只做“地图”，而是在组织行为
|
||||||
|
|
||||||
|
空间本身并不会自动变成体验。
|
||||||
|
|
||||||
|
一个场景即便美术很好看，如果玩家进去以后不知道去哪、不知道为什么要去、也不知道这里发生什么，那它依然可能是一个失败的关卡。
|
||||||
|
|
||||||
|
所以关卡策划很核心的一点，是通过空间来组织玩家行为。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 哪条路是主路径，哪条路是支路径
|
||||||
|
- 哪个区域是观察区，哪个区域是战斗区
|
||||||
|
- 什么时候该让玩家紧张，什么时候该让玩家喘口气
|
||||||
|
- 哪些地方该藏奖励，哪些地方该放信息
|
||||||
|
|
||||||
|
从这个角度看，关卡并不是“地图 + 内容摆放”，而是一整段被编排过的体验路径。
|
||||||
|
|
||||||
|
## 关卡策划通常会接触哪些内容层
|
||||||
|
|
||||||
|
关卡策划经常碰到的内容，通常也不是只有一种。
|
||||||
|
|
||||||
|
比较常见的会包括：
|
||||||
|
|
||||||
|
- 空间布局：区域划分、路径结构、高低差、视线关系
|
||||||
|
- 流程设计：开始、推进、转折、高潮、收束
|
||||||
|
- 目标设计：玩家在这一段要完成什么
|
||||||
|
- 引导设计：怎样让玩家自然理解方向和规则
|
||||||
|
- 内容编排：敌人、机关、收集物、事件、演出如何放置
|
||||||
|
- 节奏控制：压力什么时候升，什么时候降
|
||||||
|
|
||||||
|
这些内容看起来分散，但本质上都在回答同一个问题：玩家在这段关卡里到底是怎么一步步被带着走的。
|
||||||
|
|
||||||
|
## 关卡设计的起点，通常不是先画地图
|
||||||
|
|
||||||
|
很多人会以为关卡设计的第一步是先画一张平面图，或者先堆一个场景概念。
|
||||||
|
|
||||||
|
但更合理的起点，通常还是体验目标。
|
||||||
|
|
||||||
|
在真正搭关卡之前，往往要先想清楚这些问题：
|
||||||
|
|
||||||
|
- 这一关想给玩家什么感受
|
||||||
|
- 它更偏探索、战斗、叙事、解谜，还是教学
|
||||||
|
- 玩家在这里最主要的目标是什么
|
||||||
|
- 这一关和前后内容相比，承担什么功能
|
||||||
|
- 这一关想强调的新信息、新机制或新压力点是什么
|
||||||
|
|
||||||
|
只有这些事明确之后，空间和路径才有意义。
|
||||||
|
|
||||||
|
否则很容易出现一种情况：地图本身画得很完整，但体验没有重心，玩家走完整关也不知道这一关到底想让自己记住什么。
|
||||||
|
|
||||||
|
## 空间设计，本质上是在控制信息和选择
|
||||||
|
|
||||||
|
关卡空间最重要的，不只是美术造型，而是它如何影响玩家理解世界和做出决策。
|
||||||
|
|
||||||
|
例如一个空间会直接决定：
|
||||||
|
|
||||||
|
- 玩家能不能提前看到前方危险
|
||||||
|
- 玩家是被迫穿过一条狭窄路径，还是可以选择绕路
|
||||||
|
- 战斗时有没有足够空间拉扯、躲避和观察
|
||||||
|
- 玩家会不会因为遮挡、高低差和转角而失去判断
|
||||||
|
|
||||||
|
也就是说，空间不是中性的。它本身就在改变玩法问题的性质。
|
||||||
|
|
||||||
|
同一个敌人，放在开阔地和狭窄走廊里，带来的体验完全不同；同一个解谜机制，放在清晰可视的空间和信息杂乱的空间里，玩家理解难度也完全不同。
|
||||||
|
|
||||||
|
所以关卡策划在设计空间时，本质上也在设计信息密度和选择压力。
|
||||||
|
|
||||||
|
## 路径设计，重点不只是“玩家能走过去”
|
||||||
|
|
||||||
|
一条路径能不能通，只是最基础的一层。
|
||||||
|
|
||||||
|
真正重要的是，玩家在路径上会怎么感知、怎么决策，以及这条路是不是在推着体验往正确方向走。
|
||||||
|
|
||||||
|
例如路径设计通常要考虑这些问题：
|
||||||
|
|
||||||
|
- 主线方向是否足够清楚
|
||||||
|
- 支线内容是不是值得探索
|
||||||
|
- 回头路会不会太长、太空或者太烦
|
||||||
|
- 空间节点之间的过渡是否自然
|
||||||
|
- 玩家在前进时，是否总能获得新的信息或新的期待
|
||||||
|
|
||||||
|
如果路径只是“连起来了”，但中间没有节奏、没有信息变化、也没有明确动机，那它很容易变成单纯的跑图。
|
||||||
|
|
||||||
|
## 关卡节奏，很多时候比内容量更重要
|
||||||
|
|
||||||
|
一关好不好玩，很多时候不在于塞了多少东西，而在于这些内容是怎么被编排的。
|
||||||
|
|
||||||
|
关卡节奏通常会处理这些变化：
|
||||||
|
|
||||||
|
- 什么时候让玩家观察
|
||||||
|
- 什么时候让玩家行动
|
||||||
|
- 什么时候制造第一次压力
|
||||||
|
- 什么时候抬高复杂度
|
||||||
|
- 什么时候让玩家短暂放松
|
||||||
|
- 什么时候进入高潮和收尾
|
||||||
|
|
||||||
|
如果从头到尾都维持同一种状态，关卡即便内容不少，也容易显得平。
|
||||||
|
|
||||||
|
反过来，如果节奏变化过快，玩家还没建立理解就被推到下一层压力上，也很容易觉得乱。
|
||||||
|
|
||||||
|
所以关卡策划真正做的，不只是把内容一个个放进去，而是在安排玩家的心理起伏。
|
||||||
|
|
||||||
|
## 关卡策划和战斗、文案、技术、美术天然高度耦合
|
||||||
|
|
||||||
|
关卡策划很少是一个可以独立闭门完成的岗位。
|
||||||
|
|
||||||
|
因为关卡本身就是很多内容的交汇点。
|
||||||
|
|
||||||
|
它通常要同时和这些部分发生关系：
|
||||||
|
|
||||||
|
- 和战斗策划对接敌人配置、遭遇编排和战斗空间
|
||||||
|
- 和文案策划对接世界观信息、叙事节点和环境表达
|
||||||
|
- 和技术策划对接编辑工具、性能限制和实现流程
|
||||||
|
- 和美术对接场景风格、视觉引导和空间表达
|
||||||
|
- 和程序对接机关逻辑、触发关系和交互实现
|
||||||
|
|
||||||
|
这也是为什么关卡策划不能只会“想地图”。
|
||||||
|
|
||||||
|
如果不理解战斗需求，就可能做出不适合战斗的空间；如果不理解叙事目标，就可能让剧情节点落得很空；如果不理解实现限制，方案就很容易停留在想象阶段。
|
||||||
|
|
||||||
|
## 关卡验证，往往比搭出来更重要
|
||||||
|
|
||||||
|
关卡工作还有一个特别容易被低估的点，就是验证。
|
||||||
|
|
||||||
|
因为一张图搭出来，并不等于体验成立。
|
||||||
|
|
||||||
|
很多问题只有玩家真正跑一遍时才会暴露出来，例如：
|
||||||
|
|
||||||
|
- 引导不够清楚，玩家总在错误路径上浪费时间
|
||||||
|
- 战斗点位理论上成立，但实战中视角很乱
|
||||||
|
- 节奏安排在纸面上合理，但实际玩起来过长或过碎
|
||||||
|
- 奖励点看似隐蔽有趣，实际上玩家几乎不会发现
|
||||||
|
|
||||||
|
所以关卡策划通常要反复做这些事：
|
||||||
|
|
||||||
|
- 自己反复跑流程
|
||||||
|
- 观察别人第一次进入时怎么走
|
||||||
|
- 看哪些地方玩家停住、绕路、看漏或误解
|
||||||
|
- 根据实测去调整空间、路径、引导和内容摆放
|
||||||
|
|
||||||
|
这也是为什么关卡设计不是单次产出，而更像持续迭代。
|
||||||
|
|
||||||
|
## 一个好的关卡结果，通常不只是“看起来丰富”
|
||||||
|
|
||||||
|
很多人评价关卡时，最容易先看的是“地图大不大”“内容多不多”“场景酷不酷”。
|
||||||
|
|
||||||
|
这些当然重要，但一个真正好的关卡，通常还要满足更底层的东西：
|
||||||
|
|
||||||
|
- 玩家知道自己为什么来这里
|
||||||
|
- 玩家知道大致该往哪走
|
||||||
|
- 玩家会在前进过程中持续获得新信息
|
||||||
|
- 空间本身能支撑玩法，而不是和玩法打架
|
||||||
|
- 整段体验有清楚节奏，而不是平铺直叙
|
||||||
|
|
||||||
|
如果只有视觉丰富，没有体验组织，关卡很容易变成“看起来像内容很多，但玩起来记不住什么”。
|
||||||
|
|
||||||
|
## 总结
|
||||||
|
|
||||||
|
关卡策划并不是单纯做地图的人，而是在用空间、路径、目标和节奏去组织玩家体验的人。
|
||||||
|
|
||||||
|
它既要理解玩法，也要理解场景；既要会搭结构，也要会看玩家行为；既要能做前期规划，也要能靠反复验证把体验调顺。
|
||||||
|
|
||||||
|
说到底，关卡策划真正要解决的，不是“这张图怎么摆”，而是“玩家在这个空间里，到底会经历一段怎样的游戏过程”。
|
||||||
@@ -0,0 +1,215 @@
|
|||||||
|
上级索引：[[策划索引]]
|
||||||
|
|
||||||
|
|
||||||
|
如果说“战斗策划的领域与工作内容”那一篇讲的是职责范围，那么再往下走一步，真正落到日常工作里，战斗策划最常碰到的其实是更具体的东西：
|
||||||
|
|
||||||
|
- 角色怎么设计
|
||||||
|
- 怪物怎么设计
|
||||||
|
- 一招一式该怎么拆
|
||||||
|
- 反馈和手感怎么成立
|
||||||
|
- 场景与遭遇怎么把这些内容组织起来
|
||||||
|
|
||||||
|
很多人会觉得，战斗策划的工作就是“想一个角色”或者“想一个技能”。但真做起来就会发现，战斗内容一旦开始落地，所有东西都会连在一起。
|
||||||
|
|
||||||
|
一个招式不只是动作本身，它还会牵涉到判定、位移、镜头、特效、音频、受击、资源消耗、AI 反应以及关卡空间。也正因为如此，战斗策划真正需要的，不是只会想点子，而是能把这些东西拆开来看，再重新组织起来。
|
||||||
|
|
||||||
|
## 战斗策划的具体工作对象，通常可以分成几层
|
||||||
|
|
||||||
|
如果按实际产出拆，战斗策划经常会在下面几层之间来回切换：
|
||||||
|
|
||||||
|
- 玩家角色
|
||||||
|
- 怪物或敌人
|
||||||
|
- 招式与技能
|
||||||
|
- 表现与反馈
|
||||||
|
- 战斗场景与遭遇
|
||||||
|
|
||||||
|
它们看起来是不同模块，但本质上是在共同回答同一个问题：玩家这一场战斗到底是怎么被构成的。
|
||||||
|
|
||||||
|
## 角色设计，重点不只是“这个角色会什么”
|
||||||
|
|
||||||
|
角色设计最容易做偏的一点，是把注意力全放在技能创意上。
|
||||||
|
|
||||||
|
但一个角色真正重要的，往往不是“招式看起来多酷”，而是它在战斗里承担什么功能，以及它要求玩家以什么方式去玩。
|
||||||
|
|
||||||
|
通常要先想清楚这些问题：
|
||||||
|
|
||||||
|
- 这个角色的核心定位是什么
|
||||||
|
- 它更擅长近身、远程、压制、爆发，还是周旋
|
||||||
|
- 它的风险收益关系是什么
|
||||||
|
- 它的操作门槛和上限大概在哪
|
||||||
|
- 它和现有角色相比，差异点到底是什么
|
||||||
|
|
||||||
|
只有先把角色定位讲明白，后面的动作、数值和技能结构才有依据。
|
||||||
|
|
||||||
|
否则就很容易出现一种情况：单看每个技能都不差，但合在一起并不能形成明确玩法，最后角色只是“功能很多”，却没有清晰个性。
|
||||||
|
|
||||||
|
### 角色设计通常会继续拆到这些内容
|
||||||
|
|
||||||
|
- 基础移动和站位逻辑
|
||||||
|
- 普攻结构与连段关系
|
||||||
|
- 核心技能与资源循环
|
||||||
|
- 位移、追击、控制和保命手段
|
||||||
|
- 角色在不同距离下的行为方式
|
||||||
|
- 面对常见敌人和场景时的处理能力
|
||||||
|
|
||||||
|
也就是说，角色设计不是孤立地填几个技能格子，而是在设计一个完整的操作循环。
|
||||||
|
|
||||||
|
玩家什么时候接近、什么时候试探、什么时候打满输出、什么时候撤离、什么时候交保命，通常都要靠这套循环去支撑。
|
||||||
|
|
||||||
|
## 怪物设计，重点不只是“让玩家掉血”
|
||||||
|
|
||||||
|
怪物设计的核心，也不是单纯提高难度。
|
||||||
|
|
||||||
|
更准确地说，怪物的作用是制造压力、制造判断，并迫使玩家真正使用战斗系统。
|
||||||
|
|
||||||
|
因此在做怪物时，关键通常是下面这些事：
|
||||||
|
|
||||||
|
- 它主要通过什么方式给玩家压力
|
||||||
|
- 它要求玩家做出什么应对
|
||||||
|
- 它的行为是否容易识别
|
||||||
|
- 它的招式有没有足够可读性
|
||||||
|
- 玩家能不能在看懂之后形成稳定解法
|
||||||
|
|
||||||
|
一个好的怪物，不一定特别复杂，但通常会很清楚地逼迫玩家进入某种战斗节奏。
|
||||||
|
|
||||||
|
比如有的怪负责压近身空间，有的怪负责远程骚扰，有的怪负责打断节奏，有的怪负责惩罚贪刀。它们各自的价值，不在于动作数量，而在于能不能明确地把压力送到玩家面前。
|
||||||
|
|
||||||
|
### 怪物设计往往还要继续考虑组合关系
|
||||||
|
|
||||||
|
单个怪是否成立，只是第一步。
|
||||||
|
|
||||||
|
因为实际战斗里，玩家面对的常常不是一个怪，而是一组怪、一个波次，或者一整个遭遇流程。
|
||||||
|
|
||||||
|
这时候要继续看：
|
||||||
|
|
||||||
|
- 哪些怪适合单独出现
|
||||||
|
- 哪些怪适合搭配出现
|
||||||
|
- 它们的压迫方式会不会互相抵消
|
||||||
|
- 它们叠在一起后，是变得有层次，还是只是更乱
|
||||||
|
|
||||||
|
很多怪单看没问题，一放进实战里就失控，原因往往不是单体设计错误，而是组合关系没有处理好。
|
||||||
|
|
||||||
|
## 招式拆分，决定了战斗内容能不能被真正讨论
|
||||||
|
|
||||||
|
战斗策划不一定亲自做动画，但通常必须会拆招。
|
||||||
|
|
||||||
|
因为如果不能把一招拆成清楚的结构，那么它就很难被程序、美术、动作和特效团队共同理解，更难被持续调整。
|
||||||
|
|
||||||
|
一招常见会被拆成下面几个阶段：
|
||||||
|
|
||||||
|
- 起手
|
||||||
|
- 生效
|
||||||
|
- 收招
|
||||||
|
|
||||||
|
如果再细一点，还会继续拆到：
|
||||||
|
|
||||||
|
- 前摇有多长
|
||||||
|
- 判定从什么时候开始生效
|
||||||
|
- 生效持续多久
|
||||||
|
- 角色在过程中有没有位移
|
||||||
|
- 能不能转向、打断、取消或衔接
|
||||||
|
- 命中后敌人会发生什么反馈
|
||||||
|
- 没命中时玩家要承担多大空档
|
||||||
|
|
||||||
|
这也是为什么战斗策划常常会盯着动作一帧一帧看。
|
||||||
|
|
||||||
|
因为很多体验上的差别，并不来自“有没有这个技能”，而来自这招究竟何时出手、何时命中、何时结束，以及玩家在整个过程中能否稳定理解和控制它。
|
||||||
|
|
||||||
|
### 一招一式真正要管的，通常不只是动作本身
|
||||||
|
|
||||||
|
真正落到实现里，一招经常会带着下面这些要素一起被讨论：
|
||||||
|
|
||||||
|
- 动作时长
|
||||||
|
- 位移曲线
|
||||||
|
- 判定范围
|
||||||
|
- 锁定或追踪方式
|
||||||
|
- 是否带霸体、无敌、打断或击退
|
||||||
|
- 资源消耗与冷却
|
||||||
|
- 命中后的受击、浮空、击飞或硬直
|
||||||
|
- 后续能接什么，不能接什么
|
||||||
|
|
||||||
|
所以所谓“技能设计”，本质上并不是写一句描述，而是在定义一整套时序关系和博弈关系。
|
||||||
|
|
||||||
|
## 反馈与手感，很多时候比新机制更重要
|
||||||
|
|
||||||
|
战斗内容做出来以后，玩家第一时间感受到的，往往不是规则，而是反馈。
|
||||||
|
|
||||||
|
也就是说，玩家不一定能立刻说清楚某个系统的设计逻辑，但他一定会先感受到：
|
||||||
|
|
||||||
|
- 这一刀有没有砍到人
|
||||||
|
- 这个技能打出去稳不稳
|
||||||
|
- 受击有没有力度
|
||||||
|
- 危险信号够不够清楚
|
||||||
|
- 整个战斗到底是扎实，还是发飘
|
||||||
|
|
||||||
|
因此，战斗策划经常也要盯反馈。
|
||||||
|
|
||||||
|
这里的反馈通常包括：
|
||||||
|
|
||||||
|
- 动作本身的发力感
|
||||||
|
- 命中时的停顿、震动和位移
|
||||||
|
- 特效是否能强化打击方向与力度
|
||||||
|
- 音效是否在正确时机给到确认
|
||||||
|
- 镜头是否帮助玩家理解战场，而不是制造混乱
|
||||||
|
|
||||||
|
很多设计表面上机制没问题，但玩起来就是没感觉，根源常常不在规则，而在反馈链条没有闭合。
|
||||||
|
|
||||||
|
玩家按下按键之后，如果屏幕、声音、角色动作和敌人反应之间没有形成一致的确认感，那这次攻击即便数值上已经生效，体感上也仍然像没打中。
|
||||||
|
|
||||||
|
## 场景与遭遇，不只是把怪放进去
|
||||||
|
|
||||||
|
战斗从来不是在真空里发生的。
|
||||||
|
|
||||||
|
角色和怪物设计得再完整，进到具体场景里以后，依然会受到空间和遭遇编排的强烈影响。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 场地大小是否适合当前战斗节奏
|
||||||
|
- 是否有障碍物、掩体、高低差或边缘区域
|
||||||
|
- 玩家有没有足够空间观察、闪避和拉扯
|
||||||
|
- 敌人的刷新点和出场顺序是否合理
|
||||||
|
- 波次之间有没有节奏起伏
|
||||||
|
|
||||||
|
这也是为什么战斗策划往往还得关心遭遇设计。
|
||||||
|
|
||||||
|
因为很多体验问题，表面看像角色问题，实际上可能是场地问题；表面看像怪物问题，实际上可能是出怪顺序和空间关系有问题。
|
||||||
|
|
||||||
|
## 战斗策划花掉的大量时间，其实是在调和验证
|
||||||
|
|
||||||
|
外部很容易觉得，战斗策划的工作重点在“想内容”。
|
||||||
|
|
||||||
|
但真正在项目里，很多时间其实并不是花在灵感上，而是花在下面这些事情上：
|
||||||
|
|
||||||
|
- 找参考，拆参考
|
||||||
|
- 把模糊体验翻译成可执行需求
|
||||||
|
- 在编辑器和配置里反复验证
|
||||||
|
- 和程序、动作、特效、美术持续对齐
|
||||||
|
- 调数值、调时序、调反馈
|
||||||
|
- 处理边界情况和异常情况
|
||||||
|
|
||||||
|
这也是战斗策划容易让人误解的地方。
|
||||||
|
|
||||||
|
因为外部看到的是最后那个技能、那个怪物、那场战斗，但中间真正消耗时间的，往往是大量琐碎又关键的打磨工作。
|
||||||
|
|
||||||
|
## 为什么很多战斗问题最后都得回到“拆”
|
||||||
|
|
||||||
|
战斗策划有一个很核心的能力，就是把一个笼统问题继续拆小。
|
||||||
|
|
||||||
|
例如“这个角色不好玩”，通常不是最终结论，只是一个入口。后面还得继续拆：
|
||||||
|
|
||||||
|
- 是基础操作不顺
|
||||||
|
- 还是输出循环单调
|
||||||
|
- 是招式缺少明确用途
|
||||||
|
- 还是反馈不够扎实
|
||||||
|
- 是角色本身有问题
|
||||||
|
- 还是怪物、场景和遭遇没有把它的特点发挥出来
|
||||||
|
|
||||||
|
如果不拆，很多讨论最后都会停留在“感觉不对”。而只有拆到足够具体，问题才会变成可修改、可验证的设计问题。
|
||||||
|
|
||||||
|
## 总结
|
||||||
|
|
||||||
|
战斗策划的具体工作，并不是简单地做角色、做怪或者做技能，而是把角色、怪物、招式、反馈和场景这些内容整理成一套真正能运行的战斗体验。
|
||||||
|
|
||||||
|
所以它既需要想法，也需要拆解能力；既需要判断宏观目标，也需要盯住微观细节。
|
||||||
|
|
||||||
|
说到底，战斗策划真正的工作，不是把内容“堆出来”，而是把战斗“做实”。
|
||||||
@@ -0,0 +1,157 @@
|
|||||||
|
上级索引：[[策划索引]]
|
||||||
|
|
||||||
|
|
||||||
|
很多人一提到战斗策划，第一反应是“做角色技能的人”。这种理解不能说错，但还是有点窄。
|
||||||
|
|
||||||
|
因为战斗策划真正负责的，往往不是某一个技能本身，而是玩家在战斗中从输入到反馈、从规则到内容的整套体验。
|
||||||
|
|
||||||
|
如果换个说法，战斗策划其实经常可以被理解成 Gameplay 策划里最贴近战斗体验的那一部分。它既要看宏观，也要看微观。
|
||||||
|
|
||||||
|
## 战斗策划到底在管什么
|
||||||
|
|
||||||
|
从宏观到微观来看，战斗策划通常会接触下面这些层次：
|
||||||
|
|
||||||
|
- 战斗想提供什么样的核心体验
|
||||||
|
- 战斗整体的规则、节奏和博弈关系
|
||||||
|
- 角色、镜头与操控，也就是常说的 3C
|
||||||
|
- 角色、怪物、技能、招式和遭遇内容
|
||||||
|
- 表现、反馈、可读性以及最终手感
|
||||||
|
|
||||||
|
也就是说，战斗策划并不只是“写一个技能说明”或者“填一组伤害数值”。
|
||||||
|
|
||||||
|
它真正要处理的问题是：玩家在战斗里到底要做什么，为什么这样做，以及系统怎样让这件事变得好玩、清楚、可控。
|
||||||
|
|
||||||
|
## 战斗策划可以怎么划分
|
||||||
|
|
||||||
|
如果按工作对象来分，战斗策划大致可以分成三类。
|
||||||
|
|
||||||
|
### 1. 框架型战斗策划
|
||||||
|
|
||||||
|
这类工作关注的是战斗体验的底层骨架。
|
||||||
|
|
||||||
|
它通常会思考这些问题：
|
||||||
|
|
||||||
|
- 这个游戏的战斗核心乐趣是什么
|
||||||
|
- 它更强调反应、博弈、资源管理，还是操作表演
|
||||||
|
- 基础操作和 3C 应该如何支撑这种体验
|
||||||
|
- 战斗系统要用什么规则把体验稳定地托起来
|
||||||
|
|
||||||
|
这部分工作的重点，不是先做某个角色或某个怪，而是先把“这个战斗为什么会成立”这件事定义清楚。
|
||||||
|
|
||||||
|
如果底层框架本身不稳，那么后面再往里填内容，往往也只是把问题换一种形式继续放大。
|
||||||
|
|
||||||
|
### 2. 内容型战斗策划
|
||||||
|
|
||||||
|
这类工作更偏向具体内容生产。
|
||||||
|
|
||||||
|
常见会落到下面这些对象上：
|
||||||
|
|
||||||
|
- 角色定位、技能组和动作逻辑
|
||||||
|
- 怪物行为、机制、招式与压迫方式
|
||||||
|
- 遭遇设计、波次组合和场景中的战斗编排
|
||||||
|
|
||||||
|
看起来它比框架型更“具体”，也更容易被玩家直接感知，但它并不是和框架分开的。
|
||||||
|
|
||||||
|
因为一个角色好不好玩、一个怪物压不压迫，本质上仍然是在执行更上层的战斗目标。内容如果脱离框架，最后往往会变成局部有意思，但整体很散。
|
||||||
|
|
||||||
|
### 3. 流程型或技术型战斗策划
|
||||||
|
|
||||||
|
还有一类工作，不一定每个项目都会单独设岗，但几乎每个团队都得有人做。
|
||||||
|
|
||||||
|
它更关注的是战斗内容如何被高效生产出来，例如：
|
||||||
|
|
||||||
|
- 编辑器和配置流程是否顺手
|
||||||
|
- 模板、工具和数据结构是否方便复用
|
||||||
|
- 开发、配置、验证和调试链路是否顺畅
|
||||||
|
|
||||||
|
这类工作看起来不像传统意义上的“设计”，但它直接影响战斗内容的生产效率和稳定性。
|
||||||
|
|
||||||
|
很多时候，问题不是设计不出来，而是做得太慢、改起来太痛苦、验证成本太高。流程型工作处理的，就是这些事情。
|
||||||
|
|
||||||
|
## 战斗策划的工作内容，最后通常都会落到三件事
|
||||||
|
|
||||||
|
如果再继续压缩，战斗策划的实际工作通常可以概括成三步：
|
||||||
|
|
||||||
|
- 设计
|
||||||
|
- 落地
|
||||||
|
- 打磨
|
||||||
|
|
||||||
|
### 1. 设计
|
||||||
|
|
||||||
|
战斗设计的起点，通常不是先写技能描述，而是先明确目标体验。
|
||||||
|
|
||||||
|
以角色或怪物为例，往往要先想清楚：
|
||||||
|
|
||||||
|
- 它在战斗中的功能是什么
|
||||||
|
- 它想给玩家什么感觉
|
||||||
|
- 它的节奏、距离和风险收益关系是什么
|
||||||
|
- 它和现有内容相比，差异点在哪里
|
||||||
|
|
||||||
|
等这些问题明确以后，才会继续往下拆成更具体的内容，例如：
|
||||||
|
|
||||||
|
- 有哪些基础动作和战斗行为
|
||||||
|
- 普攻、技能、位移、受击和派生怎么组织
|
||||||
|
- 招式的前后摇、范围、追踪、打断关系怎么定
|
||||||
|
- 它和镜头、锁定、碰撞、AI、关卡之间是什么关系
|
||||||
|
|
||||||
|
所以战斗设计并不是“先想到一个帅的动作，再往上补理由”，而是先明确体验目标，再让所有动作和规则围着这个目标服务。
|
||||||
|
|
||||||
|
### 2. 落地
|
||||||
|
|
||||||
|
很多人会低估这一步，但实际上，能不能落地，本身就是战斗策划能力的一部分。
|
||||||
|
|
||||||
|
因为战斗方案一旦进入实现阶段，就一定会碰到各种现实约束：
|
||||||
|
|
||||||
|
- 动画是否做得出来
|
||||||
|
- 程序状态和逻辑是否容易实现
|
||||||
|
- 特效和音频是否能把反馈撑起来
|
||||||
|
- 镜头、碰撞、锁定和场景是否会互相打架
|
||||||
|
|
||||||
|
因此战斗策划在落地阶段，通常不是把文档丢出去就结束了，而是还要继续做这些事：
|
||||||
|
|
||||||
|
- 把抽象想法翻译成团队能执行的需求
|
||||||
|
- 跟进实现过程中的偏差和问题
|
||||||
|
- 根据制作成本与实际效果调整设计
|
||||||
|
- 确认最后做出来的东西，仍然接近原本目标
|
||||||
|
|
||||||
|
说得直接一点，不能落地的设计，往往还不能算真正意义上的设计。
|
||||||
|
|
||||||
|
### 3. 打磨
|
||||||
|
|
||||||
|
战斗体验很多时候并不是在第一版方案里就确定的，而是在不断试、不断改的过程中被打磨出来的。
|
||||||
|
|
||||||
|
这一步常见会处理的内容包括：
|
||||||
|
|
||||||
|
- 输入响应是否及时
|
||||||
|
- 反馈是否明确，例如动作、特效、音效和震屏是否协同
|
||||||
|
- 招式是否可读，玩家能不能看懂危险和机会
|
||||||
|
- 节奏是否顺，战斗有没有出现明显空档或拖沓
|
||||||
|
- 强度与收益是否合理，有没有反制空间
|
||||||
|
|
||||||
|
很多战斗设计表面上看是“功能做完了”，但玩起来仍然发虚，往往就是因为打磨还不够。
|
||||||
|
|
||||||
|
真正的差别，常常不在于多了一个系统，而在于已有系统有没有被调到合适的位置。
|
||||||
|
|
||||||
|
## 为什么战斗策划很容易被误解
|
||||||
|
|
||||||
|
战斗策划最容易被误解的一点，是它最显眼的产出通常都是具体内容。
|
||||||
|
|
||||||
|
玩家能看到的是角色、怪物、技能、演出和特效，所以外部很容易把战斗策划理解成“专门做这些具体东西的人”。
|
||||||
|
|
||||||
|
但实际上，很多问题的根源并不在内容本身，而是在更上层的框架，或者更底层的流程。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 3C 不稳，角色做得再花也很难真正好玩
|
||||||
|
- 规则不清，怪物做得再复杂也可能只是徒增混乱
|
||||||
|
- 流程不顺，再好的方案最后也会被实现成本拖垮
|
||||||
|
|
||||||
|
所以战斗策划真正难的地方，不是只会做一个局部，而是既能盯住微观内容，也不会丢掉宏观判断。
|
||||||
|
|
||||||
|
## 总结
|
||||||
|
|
||||||
|
战斗策划并不是单纯做角色技能的人，而是把“战斗体验”拆成规则、内容、反馈和流程，再把这些东西重新组织起来的人。
|
||||||
|
|
||||||
|
它既包含框架层的判断，也包含内容层的生产，还包含实现过程中的协作与打磨。
|
||||||
|
|
||||||
|
说到底，战斗策划的工作，就是让玩家在按下按键之后，屏幕里发生的一切都尽可能合理、清楚，并且好玩。
|
||||||
@@ -0,0 +1,180 @@
|
|||||||
|
上级索引：[[策划索引]]
|
||||||
|
|
||||||
|
|
||||||
|
战斗设计如果只盯角色，很容易做出“自己打自己”的内容。
|
||||||
|
|
||||||
|
因为战斗真正成立，除了玩家角色以外，还必须有能给出压力、制造判断、组织节奏的对手和环境。也就是说，怪物、遭遇和场景，并不是附属品，而是战斗体验本体的一部分。
|
||||||
|
|
||||||
|
很多时候，玩家觉得一场战斗无聊、混乱或者过难，问题不一定出在角色身上，也可能出在怪物设计、出怪方式，或者场景可读性本身。
|
||||||
|
|
||||||
|
## 怪物设计的重点，在于它逼玩家做什么
|
||||||
|
|
||||||
|
怪物设计最容易犯的一个错，是只盯伤害和血量。
|
||||||
|
|
||||||
|
但一个怪物真正的设计价值，通常不在于它能不能把玩家打疼，而在于它能不能迫使玩家做出明确判断。
|
||||||
|
|
||||||
|
例如，一个怪物可能主要承担这些职责：
|
||||||
|
|
||||||
|
- 逼玩家保持移动
|
||||||
|
- 惩罚玩家贪刀
|
||||||
|
- 压缩玩家安全空间
|
||||||
|
- 打断玩家原有节奏
|
||||||
|
- 迫使玩家优先处理某个威胁
|
||||||
|
|
||||||
|
也就是说，怪物的本质作用，是把战斗系统重新推回玩家面前。
|
||||||
|
|
||||||
|
玩家只有在被迫做选择时，闪避、格挡、反击、控场、位移、爆发这些机制才会真正变得有意义。
|
||||||
|
|
||||||
|
## 一个怪物是否成立，通常要看它的压力和解法是否对应
|
||||||
|
|
||||||
|
怪物做得好的前提，并不是“越难越好”，而是压力和解法之间要能对应起来。
|
||||||
|
|
||||||
|
通常要看这些问题：
|
||||||
|
|
||||||
|
- 它是通过近身压迫、远程骚扰，还是范围威胁来制造压力
|
||||||
|
- 玩家第一次见到它时，能不能读懂危险从哪里来
|
||||||
|
- 玩家在理解之后，是否能形成稳定应对
|
||||||
|
- 这种应对是有趣的判断，还是单纯烦人的重复
|
||||||
|
|
||||||
|
如果只有压力，没有清晰解法，玩家感受到的往往不是挑战，而是混乱和挫败。
|
||||||
|
|
||||||
|
反过来，如果解法过于单一，怪物虽然不一定难，但也很容易变成流程化劳动。
|
||||||
|
|
||||||
|
所以怪物设计的关键，不只是让它“能打人”，而是让它与玩家形成有意义的对答。
|
||||||
|
|
||||||
|
## 招式可读性，是怪物设计里最容易被低估的一层
|
||||||
|
|
||||||
|
怪物的招式如果读不清，后面很多讨论都会失去基础。
|
||||||
|
|
||||||
|
因为玩家面对怪物时，首先接收到的是动作和表现，而不是底层规则说明。
|
||||||
|
|
||||||
|
因此怪物招式通常要让玩家至少能看明白这些事：
|
||||||
|
|
||||||
|
- 它是不是要出手了
|
||||||
|
- 这一招是打前方、打范围，还是打追踪
|
||||||
|
- 攻击什么时候真正生效
|
||||||
|
- 自己现在该躲、该挡，还是可以反打
|
||||||
|
|
||||||
|
这一步如果表达不清楚，玩家就很难建立稳定预期。久而久之，战斗要么变成背板，要么变成赌运气。
|
||||||
|
|
||||||
|
很多时候，所谓怪物“不讲道理”，其实不是数值太高，而是危险没有被提前说清楚。
|
||||||
|
|
||||||
|
## 单个怪能打，不代表整个遭遇就成立
|
||||||
|
|
||||||
|
怪物设计继续往下，很快就会遇到遭遇设计。
|
||||||
|
|
||||||
|
因为玩家实际面对的，通常不是孤立怪物，而是一整个战斗组合：
|
||||||
|
|
||||||
|
- 一组怪同时出现
|
||||||
|
- 怪按波次进场
|
||||||
|
- 精英怪和杂兵混编
|
||||||
|
- 某些机制在特定场景中被反复放大
|
||||||
|
|
||||||
|
这时候真正要看的，就不再只是单体行为，而是整体关系。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 哪个怪负责先手给压力
|
||||||
|
- 哪个怪负责补足视角外威胁
|
||||||
|
- 哪个怪适合后手刷新，迫使玩家转火
|
||||||
|
- 哪些怪叠在一起会形成层次
|
||||||
|
- 哪些怪叠在一起只会制造混乱
|
||||||
|
|
||||||
|
所以遭遇设计本质上是在编排战斗节奏，而不是简单地往场上摆单位。
|
||||||
|
|
||||||
|
## 波次与节奏，决定了一场战斗是不是“越来越有内容”
|
||||||
|
|
||||||
|
很多战斗的问题，并不是单点内容差，而是整场战斗没有节奏。
|
||||||
|
|
||||||
|
玩家会感觉一场战斗有趣，往往是因为它有起伏：
|
||||||
|
|
||||||
|
- 开场先给玩家建立观察空间
|
||||||
|
- 中段开始增加判断压力
|
||||||
|
- 后段再通过新单位、新位置或新机制抬高复杂度
|
||||||
|
- 最后让玩家在较高强度下完成收束
|
||||||
|
|
||||||
|
如果从头到尾都在同一强度上重复，那么战斗即便不短，也会显得平。
|
||||||
|
|
||||||
|
反过来，如果前后段变化太快，没有过渡，玩家又会觉得自己来不及理解。
|
||||||
|
|
||||||
|
所以波次设计真正处理的，是信息量和压力如何逐层递进，而不是单纯把数量越堆越多。
|
||||||
|
|
||||||
|
## 场景空间，会直接改变战斗问题的性质
|
||||||
|
|
||||||
|
很多人会把场景看成美术背景，但对战斗来说，空间本身就是规则的一部分。
|
||||||
|
|
||||||
|
例如这些因素，都会明显改变战斗体验：
|
||||||
|
|
||||||
|
- 场地大小
|
||||||
|
- 高低差
|
||||||
|
- 狭窄通道与开阔区域
|
||||||
|
- 掩体和障碍物
|
||||||
|
- 边缘区域和可掉落区域
|
||||||
|
- 镜头在该空间里是否容易失控
|
||||||
|
|
||||||
|
同一个怪，放在大场地和狭窄走廊里，带来的压力完全不是一回事。
|
||||||
|
|
||||||
|
同一个角色，放在有高低差和无高低差的空间里，位移和追击价值也会被改写。
|
||||||
|
|
||||||
|
所以很多战斗问题表面上像招式问题，往深里看其实是空间关系出了问题。
|
||||||
|
|
||||||
|
## 场景可读性，决定玩家能不能及时理解战场
|
||||||
|
|
||||||
|
除了功能空间之外，场景还会直接影响信息读取。
|
||||||
|
|
||||||
|
玩家在战斗里通常要同时看很多东西：
|
||||||
|
|
||||||
|
- 自己的位置
|
||||||
|
- 敌人的位置
|
||||||
|
- 危险区域
|
||||||
|
- 可利用空间
|
||||||
|
- 目标切换方向
|
||||||
|
|
||||||
|
如果场景本身信息过杂，或者战斗信息和背景信息混在一起，玩家就会很难稳定判断。
|
||||||
|
|
||||||
|
因此场景可读性通常要关注这些问题：
|
||||||
|
|
||||||
|
- 地面和危险区域是否足够区分
|
||||||
|
- 障碍物会不会遮挡关键动作
|
||||||
|
- 背景亮度和颜色会不会吃掉特效提示
|
||||||
|
- 镜头在狭窄空间中是否容易让玩家失去方向
|
||||||
|
|
||||||
|
很多“看不清”的问题，并不只是特效太花，也可能是场景本身没有给战斗信息留出表达空间。
|
||||||
|
|
||||||
|
## 怪物、场景和角色之间，真正要看的是彼此有没有放大对方优点
|
||||||
|
|
||||||
|
一场战斗做得好，往往不是某一个部分特别强，而是几个部分彼此能咬合起来。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 怪物的压迫方式正好逼玩家用上角色的核心机制
|
||||||
|
- 场景空间能让怪物优势成立，但又不给玩家彻底失去解法
|
||||||
|
- 波次编排能逐步放大前面已经教过的判断，而不是突然换题
|
||||||
|
|
||||||
|
反过来，如果角色、怪物和场景彼此不搭，战斗就会显得很怪。
|
||||||
|
|
||||||
|
角色明明强调机动，场地却总是太窄；怪物明明靠前摇建立可读性，场景却总用遮挡把前摇吃掉；系统明明鼓励拉扯，遭遇却总在逼玩家站桩硬换。
|
||||||
|
|
||||||
|
这类问题单看每个模块都可能不算错，但合起来就会让体验明显失真。
|
||||||
|
|
||||||
|
## 怪物与遭遇打磨，很多时候是在减法里完成的
|
||||||
|
|
||||||
|
遭遇打磨并不总是加内容，很多时候恰恰是在删。
|
||||||
|
|
||||||
|
常见会删掉或收敛的内容包括：
|
||||||
|
|
||||||
|
- 重复制造同类压力的怪
|
||||||
|
- 没有明确用途的远程骚扰单位
|
||||||
|
- 只会增加混乱的范围技能
|
||||||
|
- 在小场景里不合理叠加的高机动单位
|
||||||
|
- 看起来丰富，但实际让玩家来不及判断的信息
|
||||||
|
|
||||||
|
这也是为什么很多战斗调优，最后不是“再加一个机制”，而是“把一些不必要的东西拿掉”，让核心矛盾更清楚。
|
||||||
|
|
||||||
|
## 总结
|
||||||
|
|
||||||
|
战斗设计里的怪物、遭遇和场景，并不是角色设计之外的补丁，而是决定战斗是否真正成立的另一半。
|
||||||
|
|
||||||
|
怪物负责制造压力，遭遇负责组织节奏，场景负责提供空间与信息条件。
|
||||||
|
|
||||||
|
说到底，一场战斗是否好玩，不只是看角色能做什么，还要看对手和环境是否能把这些能力逼出来、撑起来，并且让玩家看得懂。
|
||||||
@@ -0,0 +1,153 @@
|
|||||||
|
上级索引：[[策划索引]]
|
||||||
|
|
||||||
|
|
||||||
|
战斗设计一旦继续往下拆，最容易碰到的一类工作，就是角色构建。
|
||||||
|
|
||||||
|
这里说的“角色构建”，不是单纯写一套技能说明，也不是只看角色立绘帅不帅，而是要把一个角色从概念层一路拉到可战斗、可操作、可读、可调的状态。
|
||||||
|
|
||||||
|
也就是说，战斗策划在做角色时，真正要处理的是下面这些问题：
|
||||||
|
|
||||||
|
- 这个角色在战斗里的定位是什么
|
||||||
|
- 它要通过什么方式战斗
|
||||||
|
- 玩家操作它时，主要体验是什么
|
||||||
|
- 它的招式结构该怎么围绕这个体验组织
|
||||||
|
- 动作、判定、位移、反馈和资源循环怎样互相配合
|
||||||
|
|
||||||
|
## 角色构建的起点，通常不是技能表，而是战斗定位
|
||||||
|
|
||||||
|
很多角色设计之所以会散，往往不是技能数量不够，而是没有先把角色定位讲清楚。
|
||||||
|
|
||||||
|
一个角色在进入细化之前，通常至少要先明确这些事：
|
||||||
|
|
||||||
|
- 它是近身压制、远程牵制、爆发输出，还是偏机动周旋
|
||||||
|
- 它主要依赖普攻节奏、技能循环，还是资源爆发
|
||||||
|
- 它对玩家的要求更偏反应、记忆，还是节奏控制
|
||||||
|
- 它在现有角色体系里，补的是空白，还是强化某一类成熟玩法
|
||||||
|
|
||||||
|
如果这一层没有定清楚，后面就很容易出现一个问题：每个技能单看都能成立，但合在一起并没有清晰打法。
|
||||||
|
|
||||||
|
所以角色设计的第一步，通常不是“想一个厉害的大招”，而是先回答：这个角色到底想让玩家怎么打。
|
||||||
|
|
||||||
|
## 一个角色真正会被玩家感知到的，往往是整套操作循环
|
||||||
|
|
||||||
|
玩家并不是逐条体验技能说明，而是在实际战斗中感受一整套循环。
|
||||||
|
|
||||||
|
因此，战斗策划通常要把角色的操作过程拆成一条完整链路来看：
|
||||||
|
|
||||||
|
- 怎么起手
|
||||||
|
- 怎么接近或保持距离
|
||||||
|
- 怎么形成稳定输出
|
||||||
|
- 怎么处理空档与风险
|
||||||
|
- 怎么在合适时机交位移、控制或爆发
|
||||||
|
- 怎么在打完一轮后重新回到下一个循环
|
||||||
|
|
||||||
|
这一步很重要，因为角色的“好不好玩”，很多时候并不是某个单点设计决定的，而是循环顺不顺。
|
||||||
|
|
||||||
|
有的角色技能并不复杂，但每一步都有明确用途，打起来就会很顺；有的角色功能很多，但循环不成体系，玩家就会一直觉得“能用的东西很多，但不知道什么时候该按什么”。
|
||||||
|
|
||||||
|
## 动作组织，本质上是在组织角色的战斗语言
|
||||||
|
|
||||||
|
角色设计继续往下，就会进入动作组织。
|
||||||
|
|
||||||
|
动作组织并不是动作师自己的事，战斗策划也必须介入，因为动作本身就是战斗规则的外显形式。
|
||||||
|
|
||||||
|
一个角色的动作组织，通常要考虑这些方面：
|
||||||
|
|
||||||
|
- 基础移动状态如何建立角色节奏
|
||||||
|
- 普攻几段、每段承担什么用途
|
||||||
|
- 技能是补循环、开机会，还是专门做爆发
|
||||||
|
- 位移和闪避是保命工具，还是输出链的一部分
|
||||||
|
- 空中动作、追击动作、受击动作是否需要单独成立
|
||||||
|
|
||||||
|
很多时候，角色动作不是越多越好，而是越清楚越好。
|
||||||
|
|
||||||
|
玩家需要通过动作本身，快速理解每一类行为的用途。例如哪些动作是试探，哪些动作是确认命中后才该继续按，哪些动作是高风险高收益，哪些动作打完就必须承担空档。
|
||||||
|
|
||||||
|
## 普攻和技能的关系，决定了角色是“会打”还是“会堆”
|
||||||
|
|
||||||
|
一个角色是否成型，普攻和技能之间的关系通常特别关键。
|
||||||
|
|
||||||
|
因为很多设计失败，并不是技能本身差，而是普攻、技能、位移和资源系统之间彼此割裂。
|
||||||
|
|
||||||
|
比较常见的组织方式，会围绕这些问题展开：
|
||||||
|
|
||||||
|
- 普攻是主要输出来源，还是只是过渡动作
|
||||||
|
- 技能是打断普攻节奏，还是服务普攻延展
|
||||||
|
- 资源获取来自平 A、命中、闪避，还是时间恢复
|
||||||
|
- 爆发阶段和平时阶段是否有明显切换
|
||||||
|
- 角色有没有一个清晰的“上手打法”和“进阶打法”
|
||||||
|
|
||||||
|
如果这些关系没有理顺，那么角色就会出现一种很典型的问题：按键很多，但没有主次；技能很多，但没有循环。
|
||||||
|
|
||||||
|
## 动作拆分，战斗策划通常要看到比“动画名”更细
|
||||||
|
|
||||||
|
战斗策划在和动作、程序协作时，不能只停留在“这招帅不帅”。
|
||||||
|
|
||||||
|
真正有用的讨论，通常会继续拆到下面这些层级：
|
||||||
|
|
||||||
|
- 这一招的起手是否足够清楚
|
||||||
|
- 前摇长短和风险是否匹配收益
|
||||||
|
- 生效时有没有足够稳定的命中确认
|
||||||
|
- 位移距离是否合适
|
||||||
|
- 收招空档是否会让角色陷入不合理风险
|
||||||
|
- 这招能否取消、转向、衔接或者被打断
|
||||||
|
|
||||||
|
也就是说，一招在战斗策划眼里，不是一个动作文件，而是一整段时序关系。
|
||||||
|
|
||||||
|
只要时序一变，角色体验就可能完全不同。前摇多 5 帧、命中停顿少一点、位移曲线更直一些，这些看起来像小调整，但实际都会影响手感和可用性。
|
||||||
|
|
||||||
|
## 角色设计还要同时考虑“可读性”
|
||||||
|
|
||||||
|
很多人会把可读性理解成怪物设计的事，但其实角色同样需要可读性。
|
||||||
|
|
||||||
|
因为玩家自己虽然在操作角色，但也同样需要快速理解当前状态。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 这招现在是准备阶段，还是已经生效
|
||||||
|
- 当前动作还能不能转向
|
||||||
|
- 资源是不是足够支撑后续连段
|
||||||
|
- 这次命中是安全继续，还是该立刻撤出
|
||||||
|
|
||||||
|
角色可读性做得差时，问题不一定表现为“看不懂”，也可能表现为“总觉得角色不听话”。
|
||||||
|
|
||||||
|
很多所谓手感问题，最后其实不是数值问题，而是动作、特效、镜头和状态表达没有把玩家当前能做什么说清楚。
|
||||||
|
|
||||||
|
## 角色从概念到落地，中间通常还要经历很多中间层
|
||||||
|
|
||||||
|
外部很容易觉得，一个角色的诞生路径是“想法 -> 动作 -> 完成”。但在真实项目里，中间通常还有很多层内容要被不断确认。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 角色概念和视觉形象是否支撑战斗定位
|
||||||
|
- 武器和动作幅度是否匹配战斗方式
|
||||||
|
- 动作参考和招式草图是否能支撑后续制作
|
||||||
|
- 关键 pose、节奏节点和攻击方向是否清楚
|
||||||
|
- 技能描述是否能翻译成程序与配置逻辑
|
||||||
|
- 特效和音频能否把命中感与危险感撑起来
|
||||||
|
|
||||||
|
这也是为什么战斗策划经常会反复看参考、改表、对动作、盯效果。
|
||||||
|
|
||||||
|
因为一个角色并不是靠“想法正确”就能自动成立，它必须经过层层翻译和校正，最后才会成为玩家真的能稳定操作的东西。
|
||||||
|
|
||||||
|
## 角色打磨，通常不是加内容，而是让已有内容更清楚
|
||||||
|
|
||||||
|
角色进入可玩状态之后，后面的工作重点往往就不再是疯狂加新招，而是不断把已有内容调顺。
|
||||||
|
|
||||||
|
常见的打磨方向包括：
|
||||||
|
|
||||||
|
- 哪些动作用途重叠，需要合并或简化
|
||||||
|
- 哪些动作看起来能用，实际却总在错误时机被骗出来
|
||||||
|
- 哪些连段名义上存在，但实战中很难稳定打出来
|
||||||
|
- 哪些位移太短或太长，导致距离判断混乱
|
||||||
|
- 哪些技能反馈太弱，明明命中了却不够确定
|
||||||
|
|
||||||
|
所以角色打磨真正做的，不是让角色越来越复杂，而是让它越来越明确。
|
||||||
|
|
||||||
|
## 总结
|
||||||
|
|
||||||
|
战斗设计中的角色构建，本质上不是做一份技能清单，而是在设计一个完整的战斗操作体。
|
||||||
|
|
||||||
|
它既包括定位、循环和资源，也包括动作组织、时序关系、可读性和最终手感。
|
||||||
|
|
||||||
|
说到底，一个角色是否成立，不取决于它有多少招，而取决于玩家能不能通过这套招式，稳定地理解、控制并享受它的战斗方式。
|
||||||
@@ -0,0 +1,190 @@
|
|||||||
|
上级索引：[[策划索引]]
|
||||||
|
|
||||||
|
|
||||||
|
技术策划这个岗位，经常会被误解成“两边都懂一点的人”。
|
||||||
|
|
||||||
|
这种说法不能说完全错，但如果只停在这个层面，其实还是太模糊了。因为技术策划真正的价值，不在于“懂一点策划，又懂一点技术”，而在于能不能把需求、实现和生产流程真正接起来。
|
||||||
|
|
||||||
|
换句话说，技术策划并不是一个夹在中间传话的岗位，而是一个把内容需求翻译成可执行工作流的人。
|
||||||
|
|
||||||
|
## 技术策划为什么会出现
|
||||||
|
|
||||||
|
项目一旦变大，很多问题就不再只是“功能能不能做”，而会变成下面这些：
|
||||||
|
|
||||||
|
- 内容量太大，手工生产效率太低
|
||||||
|
- 重复操作太多，返工和出错成本太高
|
||||||
|
- 策划知道自己想要什么，但不知道怎样低成本落地
|
||||||
|
- 程序能做系统，但不一定会优先照顾内容生产流程
|
||||||
|
- 美术、策划、程序之间对同一个需求的理解很容易错位
|
||||||
|
|
||||||
|
这时候，单靠普通策划写需求，或者单靠程序硬接需求，往往都会越来越吃力。
|
||||||
|
|
||||||
|
技术策划之所以存在，本质上就是为了处理这类问题：让设计需求不只是“能做”，而是“能稳定地被做出来”。
|
||||||
|
|
||||||
|
## 技术策划到底在做什么
|
||||||
|
|
||||||
|
如果简单粗暴地概括，技术策划的工作通常围绕三件事：
|
||||||
|
|
||||||
|
- 把需求拆清楚
|
||||||
|
- 把生产流程搭起来
|
||||||
|
- 把内容落地效率提上去
|
||||||
|
|
||||||
|
它既不是只管创意，也不是只管写代码，而是更关注“这套内容到底要怎样生产，才能又快、又稳、又方便迭代”。
|
||||||
|
|
||||||
|
## 第一层工作：把需求翻译成可实现的结构
|
||||||
|
|
||||||
|
很多需求在最初提出时，其实都还是比较模糊的。
|
||||||
|
|
||||||
|
例如策划可能会说：
|
||||||
|
|
||||||
|
- 我想要一个更方便配战斗参数的方式
|
||||||
|
- 我希望关卡摆放不要再纯手工做
|
||||||
|
- 这个系统最好能让非程序同学也能直接配置
|
||||||
|
- 这个功能最好能快速验证，而不是等完整开发
|
||||||
|
|
||||||
|
这些说法都能表达方向，但还不能直接变成开发任务。
|
||||||
|
|
||||||
|
技术策划在这里要做的，通常就是继续把问题往下拆：
|
||||||
|
|
||||||
|
- 这个需求真正卡住的是哪一步
|
||||||
|
- 是配置困难，还是验证困难
|
||||||
|
- 是内容量太大，还是重复劳动太多
|
||||||
|
- 哪些部分必须程序支持，哪些部分可以通过工具或流程解决
|
||||||
|
- 最终应该给使用者留下什么操作入口
|
||||||
|
|
||||||
|
也就是说，技术策划首先要做的，不是立刻做工具，而是先把“问题到底是什么”讲清楚。
|
||||||
|
|
||||||
|
## 第二层工作：搭工具，但重点不是工具本身
|
||||||
|
|
||||||
|
很多人一说技术策划，就会先想到编辑器工具、脚本工具或者自动化工具。
|
||||||
|
|
||||||
|
这些当然是技术策划常见的产出，但工具本身并不是目的。
|
||||||
|
|
||||||
|
真正重要的是，它到底解决了什么问题。
|
||||||
|
|
||||||
|
例如一个工具可能是在解决：
|
||||||
|
|
||||||
|
- 批量配置效率太低
|
||||||
|
- 关卡搭建步骤太重复
|
||||||
|
- 资源命名和引用容易出错
|
||||||
|
- 表格和引擎数据同步太麻烦
|
||||||
|
- 调试链路太长，验证一次成本太高
|
||||||
|
|
||||||
|
从这个角度看，工具只是外壳，核心仍然是工作流。
|
||||||
|
|
||||||
|
如果一个工具做出来以后，看起来很复杂，但团队并没有因此更快、更稳、更容易协作，那它大概率就不是一个真正有效的工具。
|
||||||
|
|
||||||
|
## 第三层工作：搭流程，让内容生产能放大
|
||||||
|
|
||||||
|
技术策划和普通策划一个很明显的区别，就是它会天然更关心“内容是怎么被生产出来的”。
|
||||||
|
|
||||||
|
因为很多内容问题，表面看像设计问题，实际上是流程问题。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 系统本身没问题，但每次加新内容都要程序手改
|
||||||
|
- 关卡逻辑成立，但每做一次都要重复十几步机械操作
|
||||||
|
- 策划方案清楚，但不同岗位拿到手后的执行口径不一致
|
||||||
|
- 一个小改动会牵连太多资源，导致大家不敢迭代
|
||||||
|
|
||||||
|
这时候技术策划要做的，往往就是把这些零散工作整理成更稳定的链路。
|
||||||
|
|
||||||
|
常见的方向包括：
|
||||||
|
|
||||||
|
- 做统一配置入口
|
||||||
|
- 做批处理和自动化
|
||||||
|
- 做可视化编辑器
|
||||||
|
- 做模板化生产方式
|
||||||
|
- 做校验规则和基础规范
|
||||||
|
- 缩短从“改一个参数”到“看到结果”的验证路径
|
||||||
|
|
||||||
|
很多项目到了中后期，真正拖慢开发的并不是没有想法，而是生产方式太重。所以技术策划的价值，经常体现在帮团队减重。
|
||||||
|
|
||||||
|
## 技术策划不是程序，但也不能只停在文档层
|
||||||
|
|
||||||
|
技术策划和程序的边界，很多时候容易被说混。
|
||||||
|
|
||||||
|
比较粗略地看，程序更偏向系统能力本身的实现与稳定性，而技术策划更偏向内容需求的翻译、工具入口的设计，以及流程层的组织。
|
||||||
|
|
||||||
|
也就是说，技术策划不一定负责底层系统全部实现，但至少要能回答这些问题：
|
||||||
|
|
||||||
|
- 这个需求为什么要这样拆
|
||||||
|
- 为什么这个入口应该这样给策划或美术用
|
||||||
|
- 哪些步骤必须自动化，哪些步骤不值得自动化
|
||||||
|
- 什么样的工具形态最适合当前团队
|
||||||
|
|
||||||
|
如果只会写文档，不理解引擎、数据结构和工具逻辑，那么很多“技术策划”最后还是只能停在提需求。
|
||||||
|
|
||||||
|
但反过来，如果只会做工具，不理解内容生产目标，那也很容易做出一堆看起来厉害、实际没人想用的东西。
|
||||||
|
|
||||||
|
所以技术策划真正难的地方，不是“会不会一点技术”，而是能不能让技术服务内容。
|
||||||
|
|
||||||
|
## 技术策划和普通策划、技术美术，也有明显区别
|
||||||
|
|
||||||
|
和普通策划相比，技术策划通常更关注这些事：
|
||||||
|
|
||||||
|
- 一个需求怎样更容易被重复生产
|
||||||
|
- 一个系统怎样更方便配置和验证
|
||||||
|
- 一个工具入口怎样让非程序岗位也能直接使用
|
||||||
|
|
||||||
|
和技术美术相比，技术策划虽然同样会关心流程和工具，但关注点通常更偏玩法、关卡、系统和内容工作流，而不是主要围绕美术表现、材质、渲染或资源表现管线展开。
|
||||||
|
|
||||||
|
当然，具体项目里这些边界并不总是绝对的，实际经常会互相覆盖。但从工作重心看，技术策划更像是站在内容制作这一侧，去主动借技术解决问题。
|
||||||
|
|
||||||
|
## 技术策划经常做的，不只是“提效”，还有“降理解成本”
|
||||||
|
|
||||||
|
很多人提到技术策划时，最容易想到的是效率提升。
|
||||||
|
|
||||||
|
这当然很重要，但还有一件事同样关键，就是降低理解成本。
|
||||||
|
|
||||||
|
一个好工具、一个好流程，不只是让人做得更快，也要让人更不容易做错。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 配置项命名清楚，别人一看就知道怎么填
|
||||||
|
- 编辑入口明确，少一些隐性前置步骤
|
||||||
|
- 校验和报错足够直接，而不是让使用者自己猜
|
||||||
|
- 工具只暴露真正需要调的东西，而不是把所有技术细节都甩给内容同学
|
||||||
|
|
||||||
|
从这个角度看，技术策划其实也在做一种“面向团队内部的交互设计”。
|
||||||
|
|
||||||
|
只是它服务的对象，不是最终玩家，而是项目中的内容生产者。
|
||||||
|
|
||||||
|
## 技术策划为什么经常会影响创新速度
|
||||||
|
|
||||||
|
很多团队在做新内容时，最卡的往往不是没有方向，而是试错太贵。
|
||||||
|
|
||||||
|
如果每做一个想法，都要走很长的实现链路，等多岗位联调完才能验证，那团队自然会越来越保守。
|
||||||
|
|
||||||
|
技术策划在这里的价值，就是尽量把验证成本降下来。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 让策划能更快搭原型
|
||||||
|
- 让参数改动能立即看到结果
|
||||||
|
- 让常见内容有可复用模板
|
||||||
|
- 让验证一个方案不必每次都走完整生产流程
|
||||||
|
|
||||||
|
这并不是说技术策划直接负责创新，而是它往往决定了创新有没有足够低的成本被尝试出来。
|
||||||
|
|
||||||
|
## 一个好的技术策划产出，通常会有这些特征
|
||||||
|
|
||||||
|
真正有效的技术策划产出，通常不只是“做出来了”，而是能在团队里稳定发挥作用。
|
||||||
|
|
||||||
|
一般会有这些表现：
|
||||||
|
|
||||||
|
- 别人愿意用，而不是只在演示时能用
|
||||||
|
- 降低了重复劳动，而不是把复杂度换了个地方藏起来
|
||||||
|
- 缩短了验证链路，让迭代速度明显提升
|
||||||
|
- 让内容生产的口径更统一，减少沟通误差
|
||||||
|
- 能随着项目成长继续扩展，而不是很快变成一次性脚本
|
||||||
|
|
||||||
|
如果一个工具离开原作者就没人会用，或者每次使用都得先口头教学很久，那它大概率还没有真正融入团队流程。
|
||||||
|
|
||||||
|
## 总结
|
||||||
|
|
||||||
|
技术策划不是单纯懂一点技术的策划，也不是替程序分担零碎工作的人。
|
||||||
|
|
||||||
|
它更像是内容生产链路的设计者：把需求拆开，把流程搭好，把工具做成别人愿意用的样子，再让设计、程序、美术之间的协作变得更顺。
|
||||||
|
|
||||||
|
说到底，技术策划真正要解决的，不是“这个功能怎么实现”这么单一的问题，而是“这类内容以后怎样才能更高效、更稳定地被持续生产出来”。
|
||||||
@@ -0,0 +1,181 @@
|
|||||||
|
上级索引：[[策划索引]]
|
||||||
|
|
||||||
|
|
||||||
|
很多人一提到数值策划，第一反应是“调伤害的人”。
|
||||||
|
|
||||||
|
这种理解当然不算完全错，因为战斗里的攻击、防御、血量、成长倍率，确实都离不开数值。但如果把数值策划理解成“专门调几个数字的人”，那就还是太窄了。
|
||||||
|
|
||||||
|
因为数值策划真正负责的，往往不是某个数字本身，而是这些数字如何共同构成一套稳定的游戏秩序。
|
||||||
|
|
||||||
|
说得更直接一点，数值策划不是在单独处理“100 还是 120”这种问题，而是在处理：
|
||||||
|
|
||||||
|
- 玩家多久变强一次
|
||||||
|
- 变强之后能解决什么问题
|
||||||
|
- 一场战斗该有多大压力
|
||||||
|
- 一次奖励该给玩家多强的反馈
|
||||||
|
- 资源该怎样产出、消耗和回收
|
||||||
|
- 整个游戏的成长、挑战和经济节奏是否能自洽
|
||||||
|
|
||||||
|
## 数值策划到底在做什么
|
||||||
|
|
||||||
|
如果简单粗暴地概括，数值策划做的事情，其实是在把抽象体验翻译成可计算、可调整、可验证的规则。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 想让玩家感受到成长，就不能只说“后面会更强”，而要落实到成长曲线、属性提升和关卡压力上
|
||||||
|
- 想让奖励有吸引力，就不能只说“这个奖励不错”，而要落实到获取成本、产出频率和期望收益上
|
||||||
|
- 想让战斗有张力，就不能只说“这个怪有挑战”，而要落实到伤害承受、击杀时间、容错空间和资源消耗上
|
||||||
|
|
||||||
|
也就是说，数值策划真正做的，是把原本偏主观的设计目标，落成一套能被系统稳定执行的量化关系。
|
||||||
|
|
||||||
|
## 数值策划通常在管哪些层
|
||||||
|
|
||||||
|
数值策划接触的内容，通常不只是一张战斗表，而是几条彼此咬合的链路。
|
||||||
|
|
||||||
|
比较常见的会包括：
|
||||||
|
|
||||||
|
- 战斗数值：攻击、防御、血量、伤害公式、技能倍率、冷却和命中收益
|
||||||
|
- 成长数值：等级、属性成长、强化、装备、养成消耗和战力变化
|
||||||
|
- 资源与经济：货币、材料、掉落、消耗、回收和长期资源循环
|
||||||
|
- 进度节奏：玩家在新手、中期、后期分别以什么速度解锁和积累
|
||||||
|
- 奖励设计：奖励给多少、多久给一次、玩家主观体感是否和投入匹配
|
||||||
|
|
||||||
|
这些内容表面上看是不同模块，但实际上它们经常会互相影响。
|
||||||
|
|
||||||
|
一个角色成长太快，可能会直接冲垮关卡难度；奖励发太多，可能会让养成失去节奏；资源回收不够，可能会让整个经济系统越来越松；战斗耗时太长，又会反过来影响产出效率和玩家疲劳感。
|
||||||
|
|
||||||
|
所以数值策划很重要的一点，就是不能只盯某个单表，而要一直看到系统之间的连锁反应。
|
||||||
|
|
||||||
|
## 数值问题，很多时候都不是“这个数字不对”这么简单
|
||||||
|
|
||||||
|
数值设计最常见的误区，是把问题理解成单点调参。
|
||||||
|
|
||||||
|
比如玩家说：
|
||||||
|
|
||||||
|
- 这个奖励没意义
|
||||||
|
- 这个关卡太难
|
||||||
|
- 这个角色后期没用
|
||||||
|
- 这个养成太肝
|
||||||
|
|
||||||
|
这些反馈看起来都像是“调个数字就行”，但真正的问题通常没那么简单。
|
||||||
|
|
||||||
|
例如“奖励没意义”，不一定是奖励太少，也可能是获取成本太高、反馈不够集中，或者奖励和当前玩家最缺的资源根本没对上。
|
||||||
|
|
||||||
|
“关卡太难”也不一定是怪伤害高，可能是玩家成长断层、容错太低、补给太少，或者战斗时长把压力放大了。
|
||||||
|
|
||||||
|
所以数值策划和普通印象里最大的区别之一，就是它不会只问“该改多少”，而会继续追问“这个问题到底是在哪一层失衡了”。
|
||||||
|
|
||||||
|
## 数值设计，本质上是在组织几条核心循环
|
||||||
|
|
||||||
|
一个游戏里的数值，真正要撑住的通常是下面几条循环：
|
||||||
|
|
||||||
|
- 成长循环：玩家投入资源，获得强度提升，再去挑战更高内容
|
||||||
|
- 战斗循环：玩家通过角色能力与资源管理完成一场具体对局
|
||||||
|
- 经济循环：资源不断产出、消耗、沉淀和回收
|
||||||
|
- 奖励循环：玩家完成行为后得到反馈，并形成下一轮目标
|
||||||
|
|
||||||
|
数值策划的工作，不是把这几条循环分别做出来就结束了，而是让它们彼此之间能够对得上。
|
||||||
|
|
||||||
|
例如成长速度不能快到把挑战吃掉，也不能慢到让玩家感受不到变化；奖励不能发到让资源失去价值，也不能抠到让玩家觉得所有投入都没回报。
|
||||||
|
|
||||||
|
从这个角度看，数值策划其实一直在处理“节奏”。
|
||||||
|
|
||||||
|
只是它处理的不是演出节奏，而是成长节奏、消耗节奏、收益节奏和压力节奏。
|
||||||
|
|
||||||
|
## 数值设计通常怎么开始
|
||||||
|
|
||||||
|
很多人会以为数值策划的工作起点是一张 Excel。
|
||||||
|
|
||||||
|
但实际更合理的起点，通常还是问题和目标。
|
||||||
|
|
||||||
|
一套数值在开始搭之前，往往要先回答这些事：
|
||||||
|
|
||||||
|
- 这个系统想给玩家什么感受
|
||||||
|
- 玩家大概会经历哪些阶段
|
||||||
|
- 每个阶段的主要目标是什么
|
||||||
|
- 资源是鼓励积累、鼓励消费，还是鼓励取舍
|
||||||
|
- 系统的主要压力点在哪
|
||||||
|
|
||||||
|
只有这些事先想清楚，后面的公式、区间和表格才有依据。
|
||||||
|
|
||||||
|
否则就很容易出现一种情况：表填得很多，但没有明确设计目标，最后所有数字都像是“差不多先放着”。
|
||||||
|
|
||||||
|
## 表格、公式和曲线，解决的是“可控”
|
||||||
|
|
||||||
|
数值策划当然离不开表格、公式和曲线。
|
||||||
|
|
||||||
|
但这些东西真正重要的地方，不在于看起来专业，而在于它们能让系统变得可控。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 用公式定义成长关系，是为了知道系统会怎样随等级放大
|
||||||
|
- 用曲线控制前中后期变化，是为了让玩家体验不会突然断层
|
||||||
|
- 用区间和边界控制产出消耗，是为了避免某个系统提前崩掉
|
||||||
|
|
||||||
|
很多时候，数值工作并不是追求绝对精确，而是追求“变化趋势是可以预测的，结果范围是可以管理的”。
|
||||||
|
|
||||||
|
因为游戏不是数学题。玩家行为、玩法组合、版本变化都会让结果偏移。数值策划真正需要的，不是算出一个永远正确的答案，而是搭出一套即便变化发生，也仍然方便调整的结构。
|
||||||
|
|
||||||
|
## 数值验证，比算出来更重要
|
||||||
|
|
||||||
|
数值工作还有一个特别容易被低估的点，就是验证。
|
||||||
|
|
||||||
|
因为很多数值在纸面上看没有问题，放进真实玩法里却会立刻变形。
|
||||||
|
|
||||||
|
原因很简单：玩家不是按理论值玩的。
|
||||||
|
|
||||||
|
玩家会跳步骤，会囤资源，会钻收益更高的玩法，会因为反馈强弱改变选择，也会在体验上对同样的期望值产生完全不同的体感。
|
||||||
|
|
||||||
|
所以数值策划通常还要反复做这些事：
|
||||||
|
|
||||||
|
- 看理论模型是否自洽
|
||||||
|
- 看实际玩法中玩家是否按预期运行
|
||||||
|
- 看极端情况下系统会不会被放大或被绕开
|
||||||
|
- 看主观体验和客观期望是否一致
|
||||||
|
|
||||||
|
这也是为什么数值策划不能只会算。
|
||||||
|
|
||||||
|
只会算，容易得到一个表面平衡的结果；但只有结合验证和体验，才可能得到一个真正可玩的结果。
|
||||||
|
|
||||||
|
## 数值策划为什么天然需要系统思维
|
||||||
|
|
||||||
|
数值策划和很多岗位不同的地方在于，它几乎天然要面对联动问题。
|
||||||
|
|
||||||
|
改一个掉落，可能会影响养成节奏；改一个养成消耗，可能会影响活动价值；改一个技能倍率，可能会影响角色生态；改一个体力产出，又可能会反过来改变资源市场和日常时长。
|
||||||
|
|
||||||
|
也就是说，数值策划最怕的不是“不会调”，而是只看局部。
|
||||||
|
|
||||||
|
局部看起来合理的改动，一旦放进完整系统里，有时反而会制造更大的失衡。
|
||||||
|
|
||||||
|
所以数值策划很核心的一种能力，就是始终记得去看：
|
||||||
|
|
||||||
|
- 上游资源从哪来
|
||||||
|
- 中间行为靠什么驱动
|
||||||
|
- 下游结果会沉淀成什么
|
||||||
|
- 某个改动会把压力转移到哪里
|
||||||
|
|
||||||
|
这也是为什么数值策划经常需要比别人更习惯画链路、看结构、算边界，而不是只盯某一个数。
|
||||||
|
|
||||||
|
## 一个好的数值结果，通常不只是“平衡”
|
||||||
|
|
||||||
|
很多人评价数值时，最常说的是“平不平衡”。
|
||||||
|
|
||||||
|
但一个好的数值结果，通常不只是平衡，而是同时满足几件事：
|
||||||
|
|
||||||
|
- 玩家能感受到成长
|
||||||
|
- 奖励与投入大致匹配
|
||||||
|
- 挑战和容错保持在合理区间
|
||||||
|
- 资源长期不会明显失控
|
||||||
|
- 系统后续还有继续迭代和扩展的空间
|
||||||
|
|
||||||
|
如果只追求静态平衡，最后很容易做出一个“看起来没问题，但玩起来也没什么感觉”的系统。
|
||||||
|
|
||||||
|
而游戏里的数值，很多时候不是为了静态公平，而是为了让体验有方向、有反馈，也有持续变化的空间。
|
||||||
|
|
||||||
|
## 总结
|
||||||
|
|
||||||
|
数值策划并不是专门调几个数字的人，而是在用数字组织成长、战斗、经济和奖励这几条核心循环的人。
|
||||||
|
|
||||||
|
它真正要解决的，不是某个值高了还是低了，而是整个系统能不能在玩家真实行为下，依然保持可控、自洽，并持续提供体验。
|
||||||
|
|
||||||
|
说到底，数值策划的工作，本质上是在给游戏建立秩序。
|
||||||
@@ -0,0 +1,191 @@
|
|||||||
|
上级索引：[[策划索引]]
|
||||||
|
|
||||||
|
|
||||||
|
很多人一提到文案策划，第一反应就是“写剧情的人”或者“写台词的人”。
|
||||||
|
|
||||||
|
这种理解不能说完全错，因为剧情、对白、角色文本当然都属于文案策划的工作范围。但如果把文案策划只理解成“负责写字的人”，那就还是太窄了。
|
||||||
|
|
||||||
|
因为文案策划真正负责的，往往不是某一段话本身，而是这些文字怎样帮助游戏建立语境、塑造角色、传递信息，并让玩家更容易进入这个世界。
|
||||||
|
|
||||||
|
换句话说，文案策划不是单纯在写文字，而是在给游戏组织表达。
|
||||||
|
|
||||||
|
## 文案策划到底在做什么
|
||||||
|
|
||||||
|
如果简单粗暴地概括，文案策划的工作通常围绕下面几件事展开：
|
||||||
|
|
||||||
|
- 给游戏建立世界观和整体语境
|
||||||
|
- 给角色建立性格、身份和表达方式
|
||||||
|
- 给剧情、任务和事件提供叙事支撑
|
||||||
|
- 给系统、活动和界面提供清晰且有调性的文本表达
|
||||||
|
|
||||||
|
也就是说，文案策划处理的，不只是“写得顺不顺”，而是下面这些更本质的问题：
|
||||||
|
|
||||||
|
- 玩家现在看到的这个世界，是什么气质
|
||||||
|
- 这个角色为什么会这样说话、这样行动
|
||||||
|
- 这段剧情到底想让玩家感受到什么
|
||||||
|
- 一个系统文本既要说清楚规则，又要不要保留世界观氛围
|
||||||
|
|
||||||
|
## 文案策划不是独立写作，而是服务游戏内容
|
||||||
|
|
||||||
|
文案策划和纯文学写作一个很大的区别在于，它不是孤立成立的。
|
||||||
|
|
||||||
|
小说可以靠文字本身完成大部分表达，但游戏不行。游戏的内容表达，永远要和玩法、系统、美术、演出、镜头、配音、音效一起工作。
|
||||||
|
|
||||||
|
这意味着文案策划很重要的一点，不是“写得多漂亮”，而是“写出来的东西能不能和游戏其他部分咬合起来”。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 一个角色的台词风格，要和它的外形、动作、身份设定对得上
|
||||||
|
- 一段剧情的情绪，要和演出节奏、镜头表现、音乐氛围一致
|
||||||
|
- 一个系统提示，既要让玩家看得懂，也不能完全破坏产品调性
|
||||||
|
- 一个活动包装，不能只会喊口号，还要和实际玩法内容匹配
|
||||||
|
|
||||||
|
所以文案策划真正做的，不是单纯往产品里塞字，而是让文字成为内容体验的一部分。
|
||||||
|
|
||||||
|
## 文案策划通常会接触哪些文本层
|
||||||
|
|
||||||
|
文案策划经常会处理的内容，通常不只是一种文本，而是好几层不同功能的表达。
|
||||||
|
|
||||||
|
比较常见的包括：
|
||||||
|
|
||||||
|
- 世界观文本：历史、势力、地域、文化、设定逻辑
|
||||||
|
- 角色文本：角色小传、人物关系、台词口吻、背景故事
|
||||||
|
- 剧情文本：主线、支线、任务事件、过场演出、叙事节点
|
||||||
|
- 系统文本：界面说明、功能提示、玩法引导、道具描述
|
||||||
|
- 包装文本：活动主题、宣传语、版本命名、卖点表达
|
||||||
|
|
||||||
|
这些文本看起来都叫“文案”，但它们解决的问题并不一样。
|
||||||
|
|
||||||
|
世界观文本是在回答“这是个什么样的世界”；角色文本是在回答“这个人是谁”；剧情文本是在回答“发生了什么”；系统文本是在回答“玩家现在该怎么理解和操作”；包装文本则更偏向“怎么让玩家愿意关注它”。
|
||||||
|
|
||||||
|
文案策划很重要的一点，就是知道不同文本该承担不同职责，而不是把所有地方都写成一个味道。
|
||||||
|
|
||||||
|
## 世界观的价值，不只是“设定很大”
|
||||||
|
|
||||||
|
很多人聊世界观时，容易把重点放在“设定多不多”“背景大不大”。
|
||||||
|
|
||||||
|
但世界观真正的价值，通常不在于设定堆了多少，而在于它有没有支撑游戏的整体气质和内容逻辑。
|
||||||
|
|
||||||
|
一个有效的世界观，通常至少要解决这些事：
|
||||||
|
|
||||||
|
- 给玩家一个稳定的理解框架
|
||||||
|
- 让角色、势力、地域和事件有共同语境
|
||||||
|
- 让玩法、美术和剧情在同一个方向上表达
|
||||||
|
- 让玩家觉得这个世界说得通，而不是只靠名词堆砌
|
||||||
|
|
||||||
|
也就是说，世界观不是拿来炫设定量的，而是拿来统一表达口径的。
|
||||||
|
|
||||||
|
同样是战斗、养成、探索，不同世界观会让玩家读到完全不同的感受。武侠、神话、科幻、黑暗奇幻，它们不仅是皮，也会反过来影响角色说话方式、任务命名方式，甚至系统包装方式。
|
||||||
|
|
||||||
|
## 角色塑造，重点不只是“写一个人设”
|
||||||
|
|
||||||
|
角色文案最容易做偏的一点，是只停在标签层。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 冷酷
|
||||||
|
- 热血
|
||||||
|
- 腹黑
|
||||||
|
- 温柔
|
||||||
|
|
||||||
|
这些标签当然能帮助快速理解角色，但它们还远远不够。
|
||||||
|
|
||||||
|
因为玩家真正感受到的角色，不是标签，而是角色在不同场景里的稳定表达。
|
||||||
|
|
||||||
|
文案策划在塑造角色时，通常要继续往下想：
|
||||||
|
|
||||||
|
- 这个角色的核心欲望是什么
|
||||||
|
- 它怎么看待自己、他人和世界
|
||||||
|
- 它在不同关系里说话会不会变化
|
||||||
|
- 它的表达方式和身份背景是否匹配
|
||||||
|
- 它的台词是否能体现独特性，而不是换谁说都一样
|
||||||
|
|
||||||
|
也就是说，角色塑造不是给一个人物贴几张形容词，而是让这个人物在游戏中拥有持续一致的表达逻辑。
|
||||||
|
|
||||||
|
## 剧情不是单纯讲故事，而是在组织玩家情绪
|
||||||
|
|
||||||
|
游戏剧情和传统故事写作也不完全一样。
|
||||||
|
|
||||||
|
因为游戏里的剧情，不只是“讲一段发生了什么”，还要考虑玩家什么时候被告知、什么时候参与、什么时候被推动进入下一段体验。
|
||||||
|
|
||||||
|
因此剧情文案通常要处理的不只是情节本身，还包括：
|
||||||
|
|
||||||
|
- 信息什么时候放给玩家
|
||||||
|
- 哪些内容该直接说，哪些内容该让玩家自己感受
|
||||||
|
- 节奏是应该压缩，还是应该留白
|
||||||
|
- 这段剧情之后，玩家情绪应该被推向哪里
|
||||||
|
|
||||||
|
有些剧情看起来设定不少，但玩家并不在意，往往不是故事量不够，而是信息组织方式没有服务玩家体验。
|
||||||
|
|
||||||
|
所以文案策划在写剧情时，本质上也在做节奏设计和情绪设计。
|
||||||
|
|
||||||
|
## 系统文案和包装文案，往往更考验“克制”
|
||||||
|
|
||||||
|
很多人一说文案策划，最先想到的还是剧情和角色。但实际上，系统文案和包装文案经常更考验基本功。
|
||||||
|
|
||||||
|
因为这类文本通常空间更小、信息更硬，却又不能完全丢掉产品气质。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 一个按钮名既要短，又要让人一眼知道用途
|
||||||
|
- 一个道具描述既要说明功能，又最好和世界观一致
|
||||||
|
- 一个活动标题既要有吸引力，又不能和实际内容脱节
|
||||||
|
- 一个新手提示既要清楚直接，又不能让玩家读得很累
|
||||||
|
|
||||||
|
这类文本最怕的，往往不是文笔差，而是信息不准、表达过满，或者调性和产品整体不一致。
|
||||||
|
|
||||||
|
所以文案策划并不总是在“发挥”，很多时候反而是在做减法。
|
||||||
|
|
||||||
|
## 文案策划和其他策划岗位的关系，本质上是协作关系
|
||||||
|
|
||||||
|
文案策划很少是一个完全独立闭环的岗位。
|
||||||
|
|
||||||
|
它通常要和很多岗位持续对接，例如：
|
||||||
|
|
||||||
|
- 和系统策划对接功能目的与文本信息结构
|
||||||
|
- 和战斗策划对接角色设定、技能命名和战斗表达
|
||||||
|
- 和数值策划对接奖励包装与成长反馈
|
||||||
|
- 和美术、动画、演出对接视觉表达方向
|
||||||
|
- 和配音、音频对接语气、节奏和角色声音呈现
|
||||||
|
|
||||||
|
这也是为什么文案策划不能只会写。
|
||||||
|
|
||||||
|
如果不理解玩法目标、不理解系统功能，也不理解玩家在这个阶段真正需要知道什么，那么文字就很容易变成悬空表达。
|
||||||
|
|
||||||
|
## 一个好的文案结果，通常不只是“好看”
|
||||||
|
|
||||||
|
很多人评价文案时，第一反应是“写得好不好看”“有没有金句”。
|
||||||
|
|
||||||
|
但游戏里的文案，真正好的标准往往更复杂。
|
||||||
|
|
||||||
|
通常至少要满足这些事：
|
||||||
|
|
||||||
|
- 说得清楚
|
||||||
|
- 说得对位
|
||||||
|
- 说得像这个产品会说的话
|
||||||
|
- 在该克制的时候克制，在该强化情绪的时候能拉起来
|
||||||
|
|
||||||
|
如果只有华丽辞藻，没有信息效率，玩家会觉得累；如果只有信息，没有气质，产品又会显得很空。
|
||||||
|
|
||||||
|
所以文案策划真正要处理的，不是单纯追求“文笔”，而是在信息、角色、情绪和产品调性之间找到平衡。
|
||||||
|
|
||||||
|
## 文案策划很依赖积累，但积累不只是“多读几本书”
|
||||||
|
|
||||||
|
文案策划当然需要阅读和表达能力，但真正有用的积累，并不只是文学积累。
|
||||||
|
|
||||||
|
它通常还包括：
|
||||||
|
|
||||||
|
- 对题材的理解，例如武侠、神话、科幻、奇幻分别怎么说话
|
||||||
|
- 对角色关系的观察，知道不同关系里的语言差异
|
||||||
|
- 对游戏体验的理解，知道玩家在哪些时刻需要信息，哪些时刻需要情绪
|
||||||
|
- 对市场和产品风格的感知，知道什么样的表达适合什么样的产品
|
||||||
|
|
||||||
|
也就是说，文案策划的积累，最终还是要回到“能不能服务游戏内容”。
|
||||||
|
|
||||||
|
## 总结
|
||||||
|
|
||||||
|
文案策划并不是单纯写剧情、写台词的人，而是在用文字帮助游戏建立世界、塑造角色、组织情绪并传递信息的人。
|
||||||
|
|
||||||
|
它既要能做表达，也要能做约束；既要理解文字，也要理解玩法、系统和玩家体验。
|
||||||
|
|
||||||
|
说到底，文案策划真正要解决的，不是“这句话怎么写更漂亮”，而是“这个游戏到底该怎样被玩家感受到和理解”。
|
||||||
@@ -0,0 +1,229 @@
|
|||||||
|
上级索引：[[策划索引]]
|
||||||
|
|
||||||
|
|
||||||
|
玩法设计学到一定程度之后，真正拉开差距的，往往不再只是“能不能提出一个想法”，而是能不能尽快判断这个想法到底成立不成立。
|
||||||
|
|
||||||
|
因为大多数玩法问题，并不是在脑中推演时暴露出来的，而是在玩家真正上手、真正操作、真正反复做同一件事时才会露出来。
|
||||||
|
|
||||||
|
所以玩法设计里有一个特别关键的能力，就是原型验证与迭代。
|
||||||
|
|
||||||
|
说得直接一点，好的玩法设计，不只是会想，也必须会试、会看、会改。
|
||||||
|
|
||||||
|
## 为什么玩法设计一定要重视原型
|
||||||
|
|
||||||
|
很多创意在描述阶段听起来都不错。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 玩家要通过某个机制不断做选择
|
||||||
|
- 每一次操作都会带来风险与收益博弈
|
||||||
|
- 资源会随着行动不断滚动起来
|
||||||
|
- 玩家在有限信息中追求更优结果
|
||||||
|
|
||||||
|
这些说法单独看都很合理，但它们还不能证明玩法真的成立。
|
||||||
|
|
||||||
|
因为玩家不会玩“描述”，玩家只会玩“操作后的真实体验”。
|
||||||
|
|
||||||
|
所以原型的价值就在于，它能帮助设计者尽快回答这些问题：
|
||||||
|
|
||||||
|
- 核心行动到底有没有趣
|
||||||
|
- 挑战是不是能稳定咬住行动
|
||||||
|
- 反馈是不是足够清楚
|
||||||
|
- 玩家会不会自然进入循环
|
||||||
|
- 这件事能不能让人愿意重复第二次、第三次、第五次
|
||||||
|
|
||||||
|
如果这些问题没有经过原型验证，很多设计最后都很容易停留在“听起来可以”。
|
||||||
|
|
||||||
|
## 原型的目的，不是做完整产品，而是验证最小成立单元
|
||||||
|
|
||||||
|
原型最容易被做偏的一点，就是做得太大。
|
||||||
|
|
||||||
|
一旦原型阶段就开始考虑太多外围内容，例如：
|
||||||
|
|
||||||
|
- 大量内容包装
|
||||||
|
- 完整成长系统
|
||||||
|
- 很多额外模式
|
||||||
|
- 大量美术表现
|
||||||
|
- 很重的剧情和世界观包裹
|
||||||
|
|
||||||
|
那么真正该被验证的核心，反而会被埋掉。
|
||||||
|
|
||||||
|
所以原型的正确重点，通常不是“尽量像正式产品”，而是尽量快地验证最小成立单元。
|
||||||
|
|
||||||
|
也就是说，先看最核心的那件事到底行不行：
|
||||||
|
|
||||||
|
- 这个核心行动本身是不是成立
|
||||||
|
- 配上的挑战是不是让它更有意思
|
||||||
|
- 反馈是不是能让人清楚理解因果
|
||||||
|
- 这个循环能不能自然跑起来
|
||||||
|
|
||||||
|
如果这几件事都还没站稳，就过早做外围扩展，很多时候只是在给不成立的核心套一个更华丽的壳。
|
||||||
|
|
||||||
|
## 原型阶段最该验证的，通常不是“内容够不够多”
|
||||||
|
|
||||||
|
很多团队做原型时，最容易焦虑的是内容量。
|
||||||
|
|
||||||
|
但玩法原型真正要验证的，通常不是“东西多不多”，而是下面这些更底层的问题：
|
||||||
|
|
||||||
|
- 玩家是否愿意主动做核心行动
|
||||||
|
- 玩家是不是能很快读懂系统在要求什么
|
||||||
|
- 玩家在第一次失败后，会不会想再试一次
|
||||||
|
- 玩家做成之后，反馈是不是足够强化投入感
|
||||||
|
- 玩家在重复几轮后，是进入深度，还是快速疲劳
|
||||||
|
|
||||||
|
这些问题如果没有答案，那么加再多外围系统，也不太可能真正补救。
|
||||||
|
|
||||||
|
因为玩法成立与否，最先暴露出来的永远是循环本身，而不是包装体量。
|
||||||
|
|
||||||
|
## 怎么看一个原型是不是“有潜力”
|
||||||
|
|
||||||
|
原型不一定一上来就很好玩，但它通常应该至少暴露出某种“值得继续追”的东西。
|
||||||
|
|
||||||
|
比较常见的观察点包括：
|
||||||
|
|
||||||
|
- 玩家是否会自发重复某个行为
|
||||||
|
- 玩家是否会因为一次成功而明显兴奋
|
||||||
|
- 玩家是否会在失败后立刻尝试调整策略
|
||||||
|
- 玩家是否能逐步理解系统，而不是始终困惑
|
||||||
|
- 玩家是否在一小段时间内就暴露出“再来一次”的倾向
|
||||||
|
|
||||||
|
这些现象往往比口头评价更重要。
|
||||||
|
|
||||||
|
因为很多玩家嘴上未必能准确描述问题，但行为会很诚实。
|
||||||
|
|
||||||
|
例如一个原型如果真的抓到了核心点，玩家通常会出现一些明显特征：
|
||||||
|
|
||||||
|
- 主动开始优化自己的做法
|
||||||
|
- 尝试探索系统边界
|
||||||
|
- 对反馈做出即时情绪反应
|
||||||
|
- 愿意自己给自己找目标
|
||||||
|
|
||||||
|
反过来，如果玩家只是被动把流程走完，然后没有明显情绪波动，也没有进一步尝试欲望，那么这套循环往往还不够强。
|
||||||
|
|
||||||
|
## 观察原型时，要尽量看“行为”，不要只看“反馈”
|
||||||
|
|
||||||
|
设计者在原型阶段很容易被一句话带偏。
|
||||||
|
|
||||||
|
比如玩家可能会说：
|
||||||
|
|
||||||
|
- 还行
|
||||||
|
- 挺有意思
|
||||||
|
- 好像有点难
|
||||||
|
- 我再看看
|
||||||
|
|
||||||
|
这些反馈当然有用，但很多时候并不足以支撑判断。
|
||||||
|
|
||||||
|
更可靠的往往还是行为观察，例如：
|
||||||
|
|
||||||
|
- 玩家卡在哪里
|
||||||
|
- 玩家最常忽略什么信息
|
||||||
|
- 玩家会不会无意识重复错误操作
|
||||||
|
- 玩家最兴奋的是哪一秒
|
||||||
|
- 玩家是否主动寻找更优打法
|
||||||
|
- 玩家在什么时候开始疲劳
|
||||||
|
|
||||||
|
玩法设计在原型阶段最重要的一点，就是学会从行为里读问题。
|
||||||
|
|
||||||
|
因为玩家未必会说出正确答案，但他们的行为常常已经把问题暴露得很明显。
|
||||||
|
|
||||||
|
## 玩法问题，经常要被继续拆成“行动 / 挑战 / 反馈”三类
|
||||||
|
|
||||||
|
原型一旦出问题，最怕的是只得到一句“感觉不对”。
|
||||||
|
|
||||||
|
这时候最稳的处理方式，通常还是回到核心玩法循环本身去拆。
|
||||||
|
|
||||||
|
也就是说，可以先问：
|
||||||
|
|
||||||
|
- 是行动本身不够有趣
|
||||||
|
- 还是挑战没有咬住行动
|
||||||
|
- 是反馈不够明确
|
||||||
|
- 还是三者之间没有形成稳定因果关系
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 玩家总是不想主动操作，可能是行动本身就缺少吸引力
|
||||||
|
- 玩家一直机械重复，可能是挑战没能迫使他做判断
|
||||||
|
- 玩家明明做对了却没感觉，可能是反馈没有建立确认感
|
||||||
|
- 玩家一直误解规则，可能是系统表达与挑战设计都存在问题
|
||||||
|
|
||||||
|
只要能把问题继续拆小，玩法就会重新变成可修改、可验证的东西。
|
||||||
|
|
||||||
|
## 什么时候该扩展，什么时候该收缩
|
||||||
|
|
||||||
|
原型阶段还有一个很重要的判断，就是分清现在该加东西，还是该先收回来。
|
||||||
|
|
||||||
|
很多玩法之所以越做越乱，并不是因为团队不努力，而是扩展时机不对。
|
||||||
|
|
||||||
|
通常可以这样判断：
|
||||||
|
|
||||||
|
- 如果核心循环还不稳定，就优先收缩，先把最小循环调顺
|
||||||
|
- 如果核心已经成立，但很快单调，就开始寻找合适拓展
|
||||||
|
- 如果玩家已经能理解并掌控系统，就可以继续抬高复杂度
|
||||||
|
- 如果玩家还没建立基本因果，就不要急着再加更多变量
|
||||||
|
|
||||||
|
这其实和 KES 里的顺序是一致的。
|
||||||
|
|
||||||
|
Key Point 没抓稳，就不应该急着 Expand；Expand 没整理清楚，也很难真正进入 Standard。
|
||||||
|
|
||||||
|
## 玩法迭代，很多时候不是加法，而是减法
|
||||||
|
|
||||||
|
很多设计者一发现玩法不够强，第一反应就是“再加一个系统”“再补一个功能”“再给一个外层目标”。
|
||||||
|
|
||||||
|
但实际上，很多玩法问题最后恰恰是通过减法解决的。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 删掉没有意义的中间步骤
|
||||||
|
- 合并重复表达的规则
|
||||||
|
- 减少让玩家分心的变量
|
||||||
|
- 收窄过早开放的策略空间
|
||||||
|
- 强化真正有价值的那一个反馈点
|
||||||
|
|
||||||
|
因为很多时候，玩法不是缺内容，而是缺重心。
|
||||||
|
|
||||||
|
减法的意义就在于，把真正有效的那一块重新拎出来，让玩家更清楚地感受到它。
|
||||||
|
|
||||||
|
## 从原型到产品，中间最难的一步是“保持核心不走形”
|
||||||
|
|
||||||
|
很多原型在早期其实是成立的，但往产品化走的时候反而越来越普通。
|
||||||
|
|
||||||
|
原因通常不是最初的核心不好，而是在扩展过程中不断被外围内容稀释。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 加了太多和核心无关的资源层
|
||||||
|
- 包了太多不必要的流程
|
||||||
|
- 为了做长线而把短循环拉得过重
|
||||||
|
- 为了兼容更多内容，把最初最尖锐的体验磨平了
|
||||||
|
|
||||||
|
所以玩法设计进入产品化之后，一个特别重要的能力就是持续回看：
|
||||||
|
|
||||||
|
- 现在这套内容，还在强化最初的核心点吗
|
||||||
|
- 新加的挑战是在拓展核心，还是在分散核心
|
||||||
|
- 新加的反馈是在放大体验，还是在制造噪音
|
||||||
|
|
||||||
|
如果这一步守不住，原型阶段最有价值的东西就很容易在量产过程中丢掉。
|
||||||
|
|
||||||
|
## 一个成熟的玩法设计者，最终要建立的是“试错效率”
|
||||||
|
|
||||||
|
很多人会把玩法能力理解成“脑子里点子多”。
|
||||||
|
|
||||||
|
但从长期看，真正重要的往往不是点子数量，而是试错效率。
|
||||||
|
|
||||||
|
也就是说，一个成熟设计者更像是在不断提升这些能力：
|
||||||
|
|
||||||
|
- 更快找到最小可验证单元
|
||||||
|
- 更快判断问题出在循环哪一层
|
||||||
|
- 更快分清该扩展还是该收缩
|
||||||
|
- 更快识别什么是噪音，什么是核心
|
||||||
|
- 更快把体验语言翻译成结构修改
|
||||||
|
|
||||||
|
这套能力一旦建立起来，设计就不再只是“灵感驱动”，而会逐渐变成一种更稳定的工作方法。
|
||||||
|
|
||||||
|
## 总结
|
||||||
|
|
||||||
|
玩法设计中的原型验证与迭代，本质上是在尽可能早地判断一套核心循环是否成立，并在最小成本下不断逼近那个真正有效的体验核心。
|
||||||
|
|
||||||
|
原型不是缩小版产品，而是用来验证“核心行动、挑战、反馈”是否真正咬合的工具。迭代也不只是加内容，而是通过观察、拆分、收缩和扩展，持续把玩法调向更清楚、更有力的状态。
|
||||||
|
|
||||||
|
说到底，玩法设计真正强的地方，不只是能想到一个玩法，而是能把一个还不稳定的想法，一步步试成真正成立的体验。
|
||||||
@@ -0,0 +1,179 @@
|
|||||||
|
上级索引：[[策划索引]]
|
||||||
|
|
||||||
|
|
||||||
|
玩法设计的方法，很多时候并不只有一种。
|
||||||
|
|
||||||
|
有的人习惯先从创意出发，往下搭结构；有的人更擅长先拆优秀产品，再把方法吸收回来。这两种路都能走通，关键不在于选哪一种，而在于是否真的把体验拆清楚了。
|
||||||
|
|
||||||
|
从这组内容里，一个很有价值的结论是：
|
||||||
|
|
||||||
|
- 方法是工具，不是教条
|
||||||
|
- 好玩来自体验，而不是来自名词
|
||||||
|
- 设计者要持续构建自己的设计工具箱
|
||||||
|
|
||||||
|
这三个判断放在一起，其实很重要。因为它提醒我们，玩法设计不是背几个公式，而是学会在不同问题面前，选择合适的观察和构建方式。
|
||||||
|
|
||||||
|
## 好玩的起点，往往是先认真感受
|
||||||
|
|
||||||
|
很多时候，设计者最容易跳过的一步，反而是最基础的一步：真正去感受。
|
||||||
|
|
||||||
|
我们很容易在分析里直接上概念，例如：
|
||||||
|
|
||||||
|
- 这是一套资源管理玩法
|
||||||
|
- 这是一套轻度构筑玩法
|
||||||
|
- 这是一套动作加 Roguelike 玩法
|
||||||
|
|
||||||
|
这些标签当然能帮助快速归类，但它们并不能替代体验本身。
|
||||||
|
|
||||||
|
因为玩家先感受到的，从来不是标签，而是情绪和状态。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 紧张
|
||||||
|
- 释放
|
||||||
|
- 贪心
|
||||||
|
- 后悔
|
||||||
|
- 掌控
|
||||||
|
- 惊喜
|
||||||
|
- 压迫
|
||||||
|
- 安全
|
||||||
|
|
||||||
|
如果设计者自己没有真正抓到这种体验，只是在复述外部名词，那后面的设计就很容易只剩下形式模仿。
|
||||||
|
|
||||||
|
所以玩法设计很重要的一步，是作为玩家去用力感受，然后回头追问：这种感受到底是在什么时刻、由什么机制共同触发的。
|
||||||
|
|
||||||
|
## 正向设计，是从体验目标往下搭结构
|
||||||
|
|
||||||
|
所谓正向设计，可以理解成从 0 到 1 的创造过程。
|
||||||
|
|
||||||
|
它更适合处理的问题通常是：
|
||||||
|
|
||||||
|
- 我想做一个新的玩法想法
|
||||||
|
- 我想围绕某种体验搭一个原型
|
||||||
|
- 我想先定义核心，再逐步扩展成产品
|
||||||
|
|
||||||
|
这时候比较稳的路径，通常不是一开始就铺很大，而是先往下抓住最小可成立单元。
|
||||||
|
|
||||||
|
也就是说，可以先问：
|
||||||
|
|
||||||
|
- 我想让玩家反复追求什么感觉
|
||||||
|
- 这份感觉背后的核心行动是什么
|
||||||
|
- 玩家在执行这个行动时，会遇到什么挑战
|
||||||
|
- 系统又该给出什么反馈，才能让循环成立
|
||||||
|
|
||||||
|
等核心循环成立以后，再用 KES 的方式去继续验证：
|
||||||
|
|
||||||
|
- K：这个玩法真正的核心点是什么
|
||||||
|
- E：它能通过哪些方向展开
|
||||||
|
- S：怎样把它沉淀成稳定规则和生产标准
|
||||||
|
|
||||||
|
正向设计最怕的一点，是在核心没站稳的时候就拼命加外围。
|
||||||
|
|
||||||
|
因为这样做往往会让团队误以为“内容越来越多”，但实际上真正需要反复打磨的那一小块体验还没成立。
|
||||||
|
|
||||||
|
## 逆向设计，是把“我觉得它好玩”继续拆到底
|
||||||
|
|
||||||
|
另一种很重要的方法，是逆向设计。
|
||||||
|
|
||||||
|
逆向设计不是单纯去抄别人做了什么，而是去理解：
|
||||||
|
|
||||||
|
- 它为什么这么做
|
||||||
|
- 它为什么这样做之后会有效
|
||||||
|
- 它的好玩究竟被组织在什么地方
|
||||||
|
|
||||||
|
很多人拆游戏时，容易停在表层，例如：
|
||||||
|
|
||||||
|
- 这个游戏有某个系统
|
||||||
|
- 这个游戏用了某种题材
|
||||||
|
- 这个游戏做了某个模式
|
||||||
|
|
||||||
|
这些当然是事实，但还不够。
|
||||||
|
|
||||||
|
真正有价值的逆向拆解，通常要继续追问：
|
||||||
|
|
||||||
|
- 玩家最频繁在做什么
|
||||||
|
- 系统主要在考玩家什么
|
||||||
|
- 玩家做成以后，系统怎样奖励他
|
||||||
|
- 这三者怎样形成一个稳定循环
|
||||||
|
- 这套循环后来又是怎样被扩展成完整产品的
|
||||||
|
|
||||||
|
也就是说，逆向设计不是把游戏拆成零件清单，而是把它拆成因果关系。
|
||||||
|
|
||||||
|
## 正向设计和逆向设计，最终都会回到同一套核心问题
|
||||||
|
|
||||||
|
虽然正向和逆向的起点不同，但真正走深之后，它们会汇合到同一些判断上。
|
||||||
|
|
||||||
|
无论是自己创造，还是分析别人，最后都要回答：
|
||||||
|
|
||||||
|
- 核心行动是什么
|
||||||
|
- 挑战在哪里
|
||||||
|
- 反馈怎样建立
|
||||||
|
- 核心点是否足够明确
|
||||||
|
- 拓展是怎样围着核心展开的
|
||||||
|
- 标准又怎样让这套玩法被稳定复制
|
||||||
|
|
||||||
|
这也是为什么“核心玩法循环 + KES”这套方法很适合当成工具箱的一部分。
|
||||||
|
|
||||||
|
它不是唯一方法，但它提供了一个很稳的观察框架。只要回到这几个问题上，很多看起来很散的玩法现象就会变得可讨论。
|
||||||
|
|
||||||
|
## 方法是工具，不是教条
|
||||||
|
|
||||||
|
这一点其实特别重要。
|
||||||
|
|
||||||
|
因为设计者最容易犯的一个错，就是一旦学到某套方法，就开始试图拿它解释一切，甚至强行把所有问题都压成同一种结构。
|
||||||
|
|
||||||
|
但真实设计并不是这样。
|
||||||
|
|
||||||
|
有些玩法更依赖直接原型验证，有些玩法更依赖内容编排，有些玩法更依赖系统联动，有些玩法更依赖叙事情境和情绪支撑。
|
||||||
|
|
||||||
|
因此，方法真正的价值不是替你做判断，而是帮你少走弯路。
|
||||||
|
|
||||||
|
一个成熟的设计者，最终还是要学会根据问题选工具，而不是根据工具硬找问题。
|
||||||
|
|
||||||
|
## 玩法设计中的工具箱，最终是靠长期积累形成的
|
||||||
|
|
||||||
|
所谓工具箱，并不是背下几套术语。
|
||||||
|
|
||||||
|
它更像是一种长期积累下来的判断能力：
|
||||||
|
|
||||||
|
- 我什么时候该先做原型
|
||||||
|
- 什么时候该先拆体验
|
||||||
|
- 什么时候该先找案例
|
||||||
|
- 什么时候该扩展内容
|
||||||
|
- 什么时候该收缩范围重新验证核心
|
||||||
|
|
||||||
|
这个工具箱的一部分来自方法学习，但更大的一部分来自持续实践。
|
||||||
|
|
||||||
|
尤其是在正向设计和逆向拆解之间来回切换时，设计者会慢慢发现：
|
||||||
|
|
||||||
|
- 很多优秀产品并不只是“有创意”
|
||||||
|
- 它们往往只是更准确地抓住了核心体验
|
||||||
|
- 并且把那份体验用非常稳定的结构搭了出来
|
||||||
|
|
||||||
|
## 玩法设计里一个特别常见的误区，是把“模仿形式”当成“理解体验”
|
||||||
|
|
||||||
|
这也是为什么逆向设计很重要。
|
||||||
|
|
||||||
|
如果只看到别人的形式，很容易学到表面：
|
||||||
|
|
||||||
|
- 学了某个品类的外壳
|
||||||
|
- 学了某个系统的名字
|
||||||
|
- 学了某个关卡结构
|
||||||
|
- 学了某个养成包装
|
||||||
|
|
||||||
|
但没有理解它背后的体验逻辑，最后做出来的东西就经常会显得“像”，却不“对”。
|
||||||
|
|
||||||
|
真正有价值的学习，不是抄结构外形，而是拆出：
|
||||||
|
|
||||||
|
- 哪个核心行动在驱动玩家
|
||||||
|
- 哪个挑战在持续咬住玩家注意力
|
||||||
|
- 哪个反馈在不断强化投入感
|
||||||
|
- 产品又是怎样围着这套循环搭出后续内容的
|
||||||
|
|
||||||
|
## 总结
|
||||||
|
|
||||||
|
玩法设计既可以从正向设计出发，也可以通过逆向拆解学习优秀产品。但无论从哪条路走，最后都要回到对体验本身的理解。
|
||||||
|
|
||||||
|
正向设计帮助我们从 0 到 1 搭建玩法，逆向设计帮助我们拆开别人为什么成立；而“核心玩法循环 + KES 法”则提供了一套很稳的中间框架，帮助我们把体验、结构和工程化思路接起来。
|
||||||
|
|
||||||
|
说到底，玩法设计最重要的，不是记住了多少术语，而是能不能从玩家体验出发，把“我觉得它好玩”一步步拆成真正可设计、可验证、可扩展的东西。
|
||||||
@@ -0,0 +1,244 @@
|
|||||||
|
上级索引：[[策划索引]]
|
||||||
|
|
||||||
|
|
||||||
|
很多人一提到玩法设计，第一反应是“想机制的人”或者“做点子的人”。
|
||||||
|
|
||||||
|
这种理解不能说完全错，因为玩法设计当然会涉及新机制、新规则、新组合。但如果把玩法设计只理解成“想一个新鲜点子”，那就还是太窄了。
|
||||||
|
|
||||||
|
因为玩法设计真正负责的，往往不是某一个点子本身，而是玩家在游戏里会持续做什么、面对什么、感受到什么，以及这一整套体验为什么会成立。
|
||||||
|
|
||||||
|
换句话说，玩法设计不是单纯发明一个功能，而是在组织一套能反复成立的体验循环。
|
||||||
|
|
||||||
|
## 玩法设计到底在设计什么
|
||||||
|
|
||||||
|
如果简单粗暴地概括，玩法设计通常要处理下面这些问题：
|
||||||
|
|
||||||
|
- 玩家最核心的行动是什么
|
||||||
|
- 玩家为什么愿意反复做这件事
|
||||||
|
- 系统通过什么挑战让这件事变得有意思
|
||||||
|
- 玩家完成之后，会得到什么反馈和奖励
|
||||||
|
- 这套循环如何被不断扩展，而不是很快耗尽
|
||||||
|
|
||||||
|
也就是说，玩法设计真正关心的，不只是“这个玩法新不新”，而是：
|
||||||
|
|
||||||
|
- 它有没有清晰的核心行动
|
||||||
|
- 它有没有稳定的挑战关系
|
||||||
|
- 它有没有足够明确的反馈
|
||||||
|
- 它能不能形成可持续循环
|
||||||
|
|
||||||
|
## “好玩”不是一句形容词，而是可以被拆开的结构
|
||||||
|
|
||||||
|
很多时候我们会说某个游戏“很好玩”，但如果只停在这个判断上，其实意义不大。
|
||||||
|
|
||||||
|
真正有价值的地方，在于继续追问：它到底为什么好玩？
|
||||||
|
|
||||||
|
从这组内容里，一个很重要的思路是把“好玩”拆成三层来看：
|
||||||
|
|
||||||
|
- 生理层：为什么玩家会对某种体验产生奖励感
|
||||||
|
- 结构层：这份奖励感是由哪些玩法结构构成的
|
||||||
|
- 工程层：怎样把这套结构真正设计和搭建出来
|
||||||
|
|
||||||
|
这个拆法很有价值，因为它把原本非常主观的“好不好玩”，往下拉成了可以讨论、可以设计、也可以复盘的东西。
|
||||||
|
|
||||||
|
## 好玩从体验中来，而不是从名词中来
|
||||||
|
|
||||||
|
玩法设计很容易陷入一个误区，就是先抓住某个已有品类名词，然后试图反推内容。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 我要做一个类某某玩法
|
||||||
|
- 我要做一个加了某机制的某某品类
|
||||||
|
- 我要做一个看起来很像市场上成功产品的东西
|
||||||
|
|
||||||
|
这种方式当然有时能帮助快速对齐方向，但它也很容易让设计停留在“形式模仿”。
|
||||||
|
|
||||||
|
更稳的一种做法，是先回到体验本身。
|
||||||
|
|
||||||
|
也就是说，先去想：
|
||||||
|
|
||||||
|
- 玩家在这类游戏里最强烈的感受是什么
|
||||||
|
- 这份感受是紧张、掌控、博弈、解压、成长，还是别的什么
|
||||||
|
- 玩家是在什么时刻产生这份感觉的
|
||||||
|
- 是什么行动、什么挑战、什么反馈共同触发了它
|
||||||
|
|
||||||
|
很多时候，真正值得抓住的不是品类标签，而是那个被玩家反复追求的情绪体验。
|
||||||
|
|
||||||
|
## 核心玩法循环，是玩法设计里最重要的骨架之一
|
||||||
|
|
||||||
|
如果继续往下拆，玩法设计里一个特别核心的结构，就是核心玩法循环。
|
||||||
|
|
||||||
|
这套循环可以被理解为由三部分共同构成：
|
||||||
|
|
||||||
|
- 核心行动
|
||||||
|
- 挑战
|
||||||
|
- 反馈
|
||||||
|
|
||||||
|
这三个东西看起来简单，但几乎决定了一套玩法是否成立。
|
||||||
|
|
||||||
|
### 1. 核心行动
|
||||||
|
|
||||||
|
核心行动指的是玩家在这款游戏里最频繁、最有代表性的行为。
|
||||||
|
|
||||||
|
它不是所有操作的总和，而是最能定义这款游戏体验的那个动作核心。
|
||||||
|
|
||||||
|
例如一款游戏的核心行动可能是：
|
||||||
|
|
||||||
|
- 瞄准并射击
|
||||||
|
- 走位并躲避
|
||||||
|
- 连线并消除
|
||||||
|
- 搜索并收集
|
||||||
|
- 组合并出牌
|
||||||
|
|
||||||
|
玩法设计在这里最重要的问题，不是“操作多不多”，而是“玩家最常做的事本身有没有趣”。
|
||||||
|
|
||||||
|
如果核心行动本身就不成立，后面加再多外围系统，也很难真的救回来。
|
||||||
|
|
||||||
|
### 2. 挑战
|
||||||
|
|
||||||
|
只有行动，没有挑战，体验很快就会变空。
|
||||||
|
|
||||||
|
挑战的作用，是给玩家的行动建立压力、判断和目标。
|
||||||
|
|
||||||
|
也就是说，挑战在回答：
|
||||||
|
|
||||||
|
- 玩家为什么不能闭着眼重复同一个动作
|
||||||
|
- 玩家需要观察什么、判断什么、取舍什么
|
||||||
|
- 玩家为什么会在这件事上投入注意力
|
||||||
|
|
||||||
|
挑战可能来自很多地方：
|
||||||
|
|
||||||
|
- 时间压力
|
||||||
|
- 空间限制
|
||||||
|
- 资源有限
|
||||||
|
- 敌人压迫
|
||||||
|
- 规则变化
|
||||||
|
- 信息不完全
|
||||||
|
|
||||||
|
关键不在于挑战种类多，而在于它能不能真正咬住核心行动。
|
||||||
|
|
||||||
|
### 3. 反馈
|
||||||
|
|
||||||
|
玩家做出行动、应对挑战之后，系统必须给出足够明确的反馈。
|
||||||
|
|
||||||
|
否则玩家就很难确认：
|
||||||
|
|
||||||
|
- 我刚才做得对不对
|
||||||
|
- 我有没有产生效果
|
||||||
|
- 这件事值不值得继续做
|
||||||
|
|
||||||
|
反馈可以是很多种：
|
||||||
|
|
||||||
|
- 视觉反馈
|
||||||
|
- 音效反馈
|
||||||
|
- 数值变化
|
||||||
|
- 资源获得
|
||||||
|
- 状态改变
|
||||||
|
- 情绪满足感
|
||||||
|
|
||||||
|
反馈的作用，不只是“让玩家觉得爽”，更是在帮助玩家建立因果理解。
|
||||||
|
|
||||||
|
当玩家逐渐确认“我的行动会稳定地产生我想要的结果”时，玩法循环才会真正稳起来。
|
||||||
|
|
||||||
|
## 核心玩法循环真正重要的，不是有这三项，而是它们彼此咬合
|
||||||
|
|
||||||
|
很多玩法表面上也有行动、有挑战、有反馈，但实际玩起来仍然不成立。
|
||||||
|
|
||||||
|
问题通常出在三者关系没对上。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 行动很频繁，但挑战和它没关系，导致玩家只是机械重复
|
||||||
|
- 挑战很多，但和行动无法形成有效对答，导致玩家感到混乱
|
||||||
|
- 反馈存在，但不够及时或不够明确，导致玩家感受不到掌控
|
||||||
|
|
||||||
|
所以玩法设计真正难的地方，不是列出三块内容，而是让这三块内容彼此支撑。
|
||||||
|
|
||||||
|
好的玩法循环，通常会让玩家感受到：
|
||||||
|
|
||||||
|
- 我知道自己在做什么
|
||||||
|
- 我知道系统在考我什么
|
||||||
|
- 我知道我做成之后会得到什么
|
||||||
|
|
||||||
|
## KES 法，解决的是“怎么把玩法从想法推到结构”
|
||||||
|
|
||||||
|
如果核心玩法循环解决的是“玩法由什么构成”，那么 KES 法更像是在解决“这套玩法怎样被系统化搭起来”。
|
||||||
|
|
||||||
|
从这组内容里，KES 可以被理解为三个层次：
|
||||||
|
|
||||||
|
- K = Key Point，核心点
|
||||||
|
- E = Expand，拓展
|
||||||
|
- S = Standard，标准
|
||||||
|
|
||||||
|
### K = Key Point，先找到真正不可替代的那一小块
|
||||||
|
|
||||||
|
很多玩法设计失败，不是因为没有内容，而是因为没有抓住核心点。
|
||||||
|
|
||||||
|
所谓核心点，不是“这个游戏有什么功能”，而是：
|
||||||
|
|
||||||
|
- 它最独特的体验到底是什么
|
||||||
|
- 玩家最想反复追求的那一瞬间是什么
|
||||||
|
- 核心行动、挑战和反馈中，最有辨识度的咬合关系是什么
|
||||||
|
|
||||||
|
这一层如果抓不准，后面的扩展就很容易越做越散。
|
||||||
|
|
||||||
|
因为团队会不断往里塞功能，但始终没有一个稳定中心，最后什么都有一点，却没有任何一块真正站得住。
|
||||||
|
|
||||||
|
### E = Expand，在核心成立的前提下做展开
|
||||||
|
|
||||||
|
核心点成立之后，玩法才进入真正的扩展阶段。
|
||||||
|
|
||||||
|
拓展不是无节制加内容，而是在不破坏核心的前提下，让这套循环拥有更多变化、更多深度和更长寿命。
|
||||||
|
|
||||||
|
常见的拓展方式包括：
|
||||||
|
|
||||||
|
- 增加新的情境
|
||||||
|
- 增加新的变量
|
||||||
|
- 增加新的对手或障碍
|
||||||
|
- 增加新的策略空间
|
||||||
|
- 增加成长和组合维度
|
||||||
|
- 增加内容消耗与长期目标
|
||||||
|
|
||||||
|
拓展的关键，不是让内容越来越多，而是让玩家继续围绕同一个核心获得新鲜感。
|
||||||
|
|
||||||
|
如果拓展出来的内容和核心体验没有关系，那么它往往只会增加体量，而不会增加真正的玩法价值。
|
||||||
|
|
||||||
|
### S = Standard，把经验沉淀成可复制的设计与生产标准
|
||||||
|
|
||||||
|
很多玩法原型在最初阶段看起来成立，但真正进入产品化时，问题才开始出现。
|
||||||
|
|
||||||
|
原因通常是它还只是一个“感觉得对”的局部，没有被整理成团队能稳定复用的结构。
|
||||||
|
|
||||||
|
所以 Standard 这一层很重要。它在处理的是：
|
||||||
|
|
||||||
|
- 怎样定义内容生产边界
|
||||||
|
- 怎样给后续设计提供判断标准
|
||||||
|
- 怎样让不同人扩展同一套玩法时不至于跑偏
|
||||||
|
- 怎样让节奏、数值、内容和表现有统一口径
|
||||||
|
|
||||||
|
也就是说，标准化不是为了束缚创意，而是为了让一套玩法能真正持续生产。
|
||||||
|
|
||||||
|
没有标准，团队很容易只能做出第一个好玩的原型，却很难稳定做出第二个、第三个同质量的内容。
|
||||||
|
|
||||||
|
## 为什么玩法设计不能只停在“想法不错”
|
||||||
|
|
||||||
|
很多玩法创意在最开始介绍时都听起来挺有意思。
|
||||||
|
|
||||||
|
但设计真正困难的地方，从来都不是一句话介绍，而是这个想法进入循环之后，还能不能持续成立。
|
||||||
|
|
||||||
|
通常要继续问这些问题：
|
||||||
|
|
||||||
|
- 玩家会不会真的愿意反复做这件事
|
||||||
|
- 挑战是不是足够支撑这件事而不至于很快无聊
|
||||||
|
- 反馈是不是足够明确，能让玩家学会并沉迷
|
||||||
|
- 核心点能不能被扩展，而不只是一次性点子
|
||||||
|
- 团队有没有办法把它标准化为持续内容
|
||||||
|
|
||||||
|
如果这些问题没有答案，那么所谓玩法创意往往还只是灵感，还不能算真正成型的玩法设计。
|
||||||
|
|
||||||
|
## 总结
|
||||||
|
|
||||||
|
玩法设计并不是单纯发明一个新机制，而是在围绕玩家体验，搭建一套由核心行动、挑战和反馈共同构成的循环。
|
||||||
|
|
||||||
|
而 KES 法的价值，则在于帮助设计者从“感觉这个点子挺有意思”，走到“我知道它的核心是什么、该如何扩展、又该怎样沉淀为稳定产品结构”。
|
||||||
|
|
||||||
|
说到底，玩法设计真正要解决的，不是“这个功能新不新”，而是“这套体验为什么会让玩家愿意持续玩下去”。
|
||||||
@@ -0,0 +1,133 @@
|
|||||||
|
上级索引：[[策划索引]]
|
||||||
|
|
||||||
|
|
||||||
|
很多人刚接触游戏策划时，会把它理解成“想点子的人”。这种理解不能说完全错，但如果只停在“我有一个想法”，那其实还远远不够。
|
||||||
|
|
||||||
|
因为游戏不是一个人做出来的。策划提出的内容，最终要经过程序、美术、音频、PM，甚至测试与运营的协作，才能真正变成玩家能体验到的东西。
|
||||||
|
|
||||||
|
也就是说，策划真正的工作，不只是想法本身，而是把一个模糊的需求整理成可以讨论、可以协作、也可以落地的方案。
|
||||||
|
|
||||||
|
简单粗暴地来看，游戏策划这件事，本质上是：
|
||||||
|
|
||||||
|
- 从具体的问题或需求出发
|
||||||
|
- 通过调查、分析与设计形成方案
|
||||||
|
- 再推动方案实际落地
|
||||||
|
- 最终解决问题，或者创造某种体验
|
||||||
|
|
||||||
|
## 策划为什么要写案子
|
||||||
|
|
||||||
|
如果一个想法只存在于自己脑子里，那它基本等于不存在。
|
||||||
|
|
||||||
|
美术不会知道该画什么，程序不会知道该做什么，PM也无法判断排期与风险。即便这个点子本身是对的，只要没有被表达清楚，它也很难在项目里形成真正的推动力。
|
||||||
|
|
||||||
|
所以策划案写作的核心目的，并不是“把文档写得好看”，而是把自己的思路转化成团队能共同理解和执行的内容。
|
||||||
|
|
||||||
|
换句话说，策划案本身就是协作工具。它要解决的是下面这些问题：
|
||||||
|
|
||||||
|
- 这个需求到底在解决什么
|
||||||
|
- 方案的核心机制是什么
|
||||||
|
- 为什么要这样设计，而不是那样设计
|
||||||
|
- 这件事要和哪些岗位协作
|
||||||
|
- 最终应该以什么形式落地
|
||||||
|
|
||||||
|
## 一个需求是怎么来的
|
||||||
|
|
||||||
|
很多需求的起点，其实都不是完整方案，而只是一个念头。
|
||||||
|
|
||||||
|
它可能来自老板的一句话，例如“我们要不要给这个游戏加个搜打撤玩法”；也可能来自玩家的抱怨，例如“这个奖励发出去跟没发一样”；还可能来自策划自己的复盘，例如“这个关卡是不是做得有点无聊”。
|
||||||
|
|
||||||
|
这些都还不是方案，它们只是信号。真正的策划工作，是把这些模糊信号进一步整理成可以被讨论的问题。
|
||||||
|
|
||||||
|
关键不在于“别人提了什么”，而在于“它背后真正的问题是什么”。
|
||||||
|
|
||||||
|
例如：
|
||||||
|
|
||||||
|
- 老板说想加新玩法，未必真的在意玩法名字本身，可能是在担心现有体验不够新鲜，或者留存点不够强。
|
||||||
|
- 玩家说奖励没意思，未必是奖励数值低，也可能是反馈不够明显、获取过程缺少期待感，或者奖励和玩法目标脱节。
|
||||||
|
- 自己觉得关卡不好玩，也未必是内容量不够，可能是节奏、目标提示、机制组合或者反馈出了问题。
|
||||||
|
|
||||||
|
只有先把需求背后的问题辨认出来，后面的方案才不会一开始就跑偏。
|
||||||
|
|
||||||
|
## 一个策划案通常怎么从需求走到落地
|
||||||
|
|
||||||
|
如果把过程压缩来看，通常可以分成四步：
|
||||||
|
|
||||||
|
- 一个需求
|
||||||
|
- 初版方案
|
||||||
|
- 完善方案
|
||||||
|
- 实际落地
|
||||||
|
|
||||||
|
### 1. 一个需求
|
||||||
|
|
||||||
|
这个阶段最重要的，不是立刻给答案，而是先把问题定义清楚。
|
||||||
|
|
||||||
|
至少要想明白这些事：
|
||||||
|
|
||||||
|
- 这个需求是谁提出来的
|
||||||
|
- 它希望解决什么问题
|
||||||
|
- 它影响的是哪一类玩家，或者哪一段体验
|
||||||
|
- 如果它真的被解决了，表现会是什么
|
||||||
|
- 当前有哪些资源、排期或技术限制
|
||||||
|
|
||||||
|
如果这一步没做清楚，后面的方案越完整，反而越可能是在认真做错事。
|
||||||
|
|
||||||
|
### 2. 初版方案
|
||||||
|
|
||||||
|
当问题相对明确之后，策划才开始给出第一版解决思路。
|
||||||
|
|
||||||
|
初版方案不一定要把所有细节一次讲透，但必须先搭出核心框架。也就是说，要先回答：
|
||||||
|
|
||||||
|
- 准备怎么解决这个问题
|
||||||
|
- 这个方案的核心体验是什么
|
||||||
|
- 玩家在流程中会做什么
|
||||||
|
- 系统要新增或改动哪些关键部分
|
||||||
|
|
||||||
|
这一步更像是先把骨架搭起来，确认方向是否成立，而不是一开始就把所有边角料都补满。
|
||||||
|
|
||||||
|
### 3. 完善方案
|
||||||
|
|
||||||
|
初版方向成立之后，才进入真正意义上的“写策划案”。
|
||||||
|
|
||||||
|
因为这时候文档不再只是记录想法，而是在和各岗位协作中不断补全可执行细节。
|
||||||
|
|
||||||
|
常见要补的内容包括：
|
||||||
|
|
||||||
|
- 交互流程是否清楚
|
||||||
|
- 表现需求是否足够明确
|
||||||
|
- 程序实现上有没有明显风险
|
||||||
|
- 数值、产出、成本是否合理
|
||||||
|
- 极端情况、失败情况和边界情况怎么处理
|
||||||
|
- 需要哪些埋点、配置和后续验证方式
|
||||||
|
|
||||||
|
很多方案不是死在“想法不行”，而是死在“细节没补齐”。方向对，只能说明它值得做；细节足够清楚，才说明它真的做得出来。
|
||||||
|
|
||||||
|
### 4. 实际落地
|
||||||
|
|
||||||
|
方案写完并不代表工作结束。对策划来说，落地阶段依然是工作的一部分。
|
||||||
|
|
||||||
|
因为文档只是开始，真正的结果还要看它在项目中有没有被正确理解、有没有因为实现约束发生变形，以及最终做出来的东西是否仍然在解决最初的问题。
|
||||||
|
|
||||||
|
所以策划在落地阶段通常还需要继续做这些事：
|
||||||
|
|
||||||
|
- 跟进实现过程，回答协作中的具体问题
|
||||||
|
- 根据开发、美术、排期约束调整方案
|
||||||
|
- 检查实际效果是否和原设计目标一致
|
||||||
|
- 在必要时继续迭代，而不是把文档一丢就不管了
|
||||||
|
|
||||||
|
## 所以，策划案写作到底在写什么
|
||||||
|
|
||||||
|
很多人以为策划案写作是在“写创意”，但更准确地说，它是在“写清楚一个需求如何被解决”。
|
||||||
|
|
||||||
|
它要把原本零散、主观、甚至带点直觉性的想法，整理成团队能共同推进的东西。写得越清楚，协作成本就越低；写得越模糊，后续返工和误解就越多。
|
||||||
|
|
||||||
|
因此，策划案写作的重点从来都不是辞藻，而是下面三件事：
|
||||||
|
|
||||||
|
- 问题有没有定义清楚
|
||||||
|
- 方案有没有讲明白
|
||||||
|
- 团队能不能据此把事情做出来
|
||||||
|
|
||||||
|
## 总结
|
||||||
|
|
||||||
|
游戏策划并不是单纯地“想玩法”，而是从需求出发，经过调研、分析、设计与协作，最终把某种体验真正做出来。
|
||||||
|
|
||||||
|
而策划案写作，本质上就是这个过程的外化。它不是为了证明自己有想法，而是为了让一个想法能被团队理解、讨论、修正，并最终落地成玩家真的能体验到的内容。
|
||||||
+13
@@ -2,3 +2,16 @@
|
|||||||
|
|
||||||
- [[项目管理方法]]
|
- [[项目管理方法]]
|
||||||
- [[拆解案写作方法论-交互方向]]
|
- [[拆解案写作方法论-交互方向]]
|
||||||
|
- [[策划案写作方法论-从需求到落地]]
|
||||||
|
- [[战斗策划的领域与工作内容]]
|
||||||
|
- [[战斗策划中的角色怪物与招式拆分]]
|
||||||
|
- [[战斗设计中的角色构建与动作组织]]
|
||||||
|
- [[战斗设计中的怪物遭遇与场景可读性]]
|
||||||
|
- [[技术策划的职责与工具流程]]
|
||||||
|
- [[数值策划的职责与系统设计思路]]
|
||||||
|
- [[文案策划的职责与内容表达]]
|
||||||
|
- [[关卡策划的职责与空间体验设计]]
|
||||||
|
- [[玩法设计方法论-核心玩法循环与KES法]]
|
||||||
|
- [[玩法设计中的正向设计与逆向拆解]]
|
||||||
|
- [[玩法设计中的原型验证与迭代]]
|
||||||
|
- [[IP打造方法论-母题角色与世界观]]
|
||||||
|
|||||||
Reference in New Issue
Block a user