横屏还是竖屏、PC 还是 Web:先确定发布形态再写剧本
发布形态不是剧本写完后的包装选项。横屏或竖屏决定演员站位和字幕空间,PC 或 Web 决定输入方式、视频存储、加载策略和发行路径。最晚在三分钟原型之前,团队就应该确定一个主画幅和一个主平台。

开篇导读
发布形态不是剧本写完后的包装选项。横屏或竖屏决定演员站位和字幕空间,PC 或 Web 决定输入方式、视频存储、加载策略和发行路径。最晚在三分钟原型之前,团队就应该确定一个主画幅和一个主平台。
本文提供的是立项决策框架,不代表所有项目都必须只发布一个平台。先选主平台,是为了让第一版有可验证的技术和观看条件;移植应在核心体验稳定之后进行。
横屏和竖屏改变的不只是构图
横屏更适合多人同框、环境线索、监控画面和传统 PC/主机观看。玩家的视线可以在更宽范围内移动,字幕与选择也较容易放在画面下方或侧边。
竖屏更贴近手机单手观看,角色面部和关系冲突更容易占据画面中心,但可用于环境信息的空间更少。字幕、选项、倒计时和系统提示会争夺同一块区域。拍摄时如果没有预留安全区,后期只能遮挡表演或缩小文字。
不要默认同时拍摄一套横屏和一套竖屏。把横屏素材裁成竖屏会丢失人物关系和线索,把竖屏素材放进横屏会产生大量空白。双画幅意味着重新构图、检查字幕、导出素材和测试界面,应作为独立成本计算。
PC、Web 和移动端各有主要约束
PC 客户端适合较大视频包、键鼠或手柄输入、离线存档和 Steam 发行。它的代价是安装、Build、平台审核和更多设备差异。
Web 版本打开门槛低,便于分享原型,但浏览器自动播放规则、网络波动、缓存、解码能力和标签页切换都会影响视频体验。不能假设开发机上的高速网络代表真实环境。
移动端适合竖屏和短时体验,但需要处理触控热区、系统中断、后台恢复、存储空间、不同屏幕比例和商店规则。用户也更可能静音观看,因此字幕和非声音反馈应从第一版开始设计。
用玩家任务选择,不要用团队偏好选择
如果核心任务是比较多个监控画面并寻找细节,横屏 PC 通常更自然。如果核心任务是在短剧冲突中快速表达态度,竖屏移动端更接近真实使用情境。如果核心目标是让潜在用户无需安装就体验三分钟原型,Web 可以作为验证平台。
《零点回拨》的完整版本包含客服界面、通话记录、监控与证据比较,适合横屏 PC;但获客用的三分钟版本可以做成 Web,保留一次来电判断和一个明确后果。两者不是简单导出关系,而是完整产品与验证切片。
平台决定视频接入方案
视频能否“播放”只是最低要求。互动影游还需要提前准备下一段、在选择后迅速切换、处理暂停和恢复,并在低配置设备上保持音画稳定。
Unity 的 VideoPlayer.Prepare用于在播放前准备资源;Unreal Engine 的 Media Framework支持本地文件、流媒体、音视频轨道以及 Blueprint 和 UMG 接入;Godot 的 VideoStreamPlayer 也有自己的格式和 Web 性能限制。选择引擎前要核对目标平台与编码,而不是拍完后才发现素材需要全部转换。
建立发布形态决策表
给每个候选方案按一到五分评估:
| 维度 | 要检查的事实 |
|---|---|
| 玩家匹配 | 目标用户是否真的在该设备和场景使用 |
| 交互匹配 | 输入、文字、线索和时间压力是否自然 |
| 视听匹配 | 画幅能否容纳人物、字幕和选项 |
| 技术风险 | 视频、缓存、存档和设备差异是否可控 |
| 发行成本 | 账户、审核、素材和版本维护量 |
| 获客路径 | 玩家从哪里发现并进入作品 |
| 团队能力 | 是否拥有对应测试设备和开发经验 |
评分不是自动答案。任何“玩家匹配”或“技术风险”低于三分的方案,都应该先做针对性原型,而不是靠总分平均掉。
立项文件里写清三句话
第一句:第一版主画幅和主平台是什么。第二句:为什么它最适合目标玩家和核心任务。第三句:哪些平台暂不支持,以及重新评估的条件。
确定发布形态后,剧本才能知道一段内容可以持续多久、玩家能同时看到多少信息,以及选择应该如何出现。下一阶段要把这些约束变成核心循环。
开工前的发布形态检查
真正执行时,把目标设备、画面比例、单次体验时长、输入方式和网络条件写进同一张规格卡。再用一个包含对白、选择、字幕和视频切换的最小片段同时测试横屏与竖屏。只有团队确认构图、交互热区和素材成本都能成立,才进入完整剧本阶段。


