作者kuyuzu (虫方子)
看板GameDesign
标题[请益] 初学用Unity与fungus做AVG的小问题
时间Sat Sep 25 12:08:49 2021
大家好，第一次在这版发文，如果不妥之处还请多包涵。
最近刚开始学用Unity以及Fungus插件，目标是做一个简单的文字冒险游戏，
在背景图的切换上遇到一点疑问。
比如说故事里面一共会用到ABCD四张背景图，
那麽背景图是直接当成2D sprite来理解对吗？
但因为丢进hierarchy里的东西都会在main camera显示，
所以我现在的做法是，
在剧情演出的Flowchart里，先用set active=F的指令把ABCD全部关掉，
假设一段演出内容为：
角色出现在办公室(A)>>一小段对话>>角色移动到公园(B)，
block里的指令就会是
set active=T (A) <<单独将A图(办公室背景)打开
say <<一小段对话
.
.
.
set active=F (A) <<单独将A图(办公室背景)关闭
set active=T (B) <<单独将B图(公园背景)打开
(中间省略了一些用Sreen的fade in/out去做的转场效果)
弄起来大概像这样：
https://i.imgur.com/7ssmB1j.jpg
我想问这个逻辑是OK的吗？Q皿Q
因为在Fungus插件里，character有一套很好用也很直觉的演出系统，
但背景切换我没有找到比较完整的教学，
所以想说是不是背景图、剧情CG等当成2D sprite来理解就好？
还是就AVG中场景转换这件事而言，
同样的演出效果其实有更适合或者说更对的的做法？"XDDDD
抱歉身为初学者可能连好好叙述问题都有点障碍ORZ
如果需要补充说明或者截图的话也都请再跟我说 >_____<
感谢耐心看到这边的人!!! Q皿Q
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 124.155.181.89 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/GameDesign/M.1632542932.A.4DD.html
1F：推 dklassic: 虽然没用过 Fungus 不过 09/25 12:43
2F：→ dklassic: 1. 对游戏开发来说只要呈现出来的效果正确就是对的方 09/25 12:43
3F：→ dklassic: 法，不用太战战兢兢 XD 09/25 12:43
4F：→ dklassic: 2. 把前後景理解成不同的东西本身就是没必要的，确实 09/25 12:43
5F：→ dklassic: 跟你说的一样都是图片，放在後面就变背景了，不用分那 09/25 12:43
6F：→ dklassic: 麽清楚 09/25 12:43
谢谢回应!!真的超战战兢兢，每个小改动都怕错XDDDD
因为也没有程式背景，所以会担心从很根本的地方搞错什麽，最後一发不可收拾ORZ
因为Fungus也有 sorting layer和layer的功能，就算全部当成图片也可以很清楚地
把场景(背景图)和剧情CG分开，
我原本的困惑是会不会背景也像character的演出一样已经有很主流(?)惯例的做法了，
只是我这个半路出家的新手不知道要那麽做ORZ
8F：→ oopFoo: 有中文字幕。Move To View, Fade To View来切换。 09/25 13:55
谢谢，他们官方的教学影片我有看过，
把图全部摊开(?)散布然後再用镜头去移动的做法我也考虑过，
但当时会担心位置没设好导致穿帮之类的，因为目前的背景都是一样大小，
主要演出效果像PPT那样一张一张切换，类似舞台剧换幕那样，
move to view 感觉好像比较适合动画演出？
※ 编辑: kuyuzu (124.155.181.89 台湾), 09/25/2021 17:34:15
10F：推 oopFoo: 你试试看，Move To View就是用来换Backgrounds。Unity是3D 09/25 19:25
11F：→ oopFoo: 所以有些设计跟你想用2D的想法不一样。当然你可以不跟 09/25 19:27
12F：→ oopFoo: Best Practice。但为什麽要用View是有原因的，主要是不同 09/25 19:29
13F：→ oopFoo: 机器会有不同萤幕比例，Fungus帮你处理。你不用就要自己想 09/25 19:31
14F：→ oopFoo: 办法。 09/25 19:31
原来如此，因为官方那个影片跟我另外找到的教学他们move to view 的示范
都是在同一张大於镜头的背景上做移动演出，
我对这个用法的想像好像就因此被限制住ORZ
不同萤幕那边有点不太懂，就算制作和输出的时候都把解析度限制在1920*1080
玩家端(目前预计先做PC版)也还是会出问题吗？Q皿Q
※ 编辑: kuyuzu (124.155.181.89 台湾), 09/25/2021 19:43:13
15F：推 oopFoo: Surface是3:2的萤幕，常见有16:9，16:10，旧的有4:3。手机 09/25 20:09
16F：→ oopFoo: 就百花齐放。你如果全萤幕要怎麽缩放裁剪？View帮你作好了 09/25 20:12
好的感谢，我可能需要稍微思考一下，因为如果要尝试这个做法的话，
感觉背景图素材可能也需要调整...？然後舞台运作的逻辑应该会跟原本想像的不一样，
我我我我我可能要重新构思一下如果换成这个做法，
整个演出指令的组合会变成什麽样子 >A<
※ 编辑: kuyuzu (124.155.181.89 台湾), 09/25/2021 20:55:39
17F：推 dklassic: 也是可以简单点强制视窗模式然後只有 16:9 啦 XD 09/25 21:06
18F：→ dklassic: 能针对多种比例是很理想，但也可能会变成无上限的议题 09/25 21:06
19F：→ dklassic: 像是 21:9、32:9 这种宽萤幕需要的素材规格就差很多了 09/25 21:06
20F：→ dklassic: 而实际上我想 PC 视觉小说玩家应该也不会太介意这种事 09/25 21:06
21F：→ dklassic: 情 09/25 21:06
22F：→ dklassic: 就算是老牌日本视觉小说游戏公司也鲜少支援多种比例 09/25 21:06
哈哈哈哈真的，我原本想说这是个圆梦性质的小游戏，受众大概也不广，
所以只想做电脑版然後限定1920*1080这样XDDDDD
因为美术也差不多画完了，要大幅改动我可能会直接暴毙XDDDDD
能在企划初始就规划清楚一定是最好的，
但我知道自己在程式方面的能力一定有上限(还很低)，
总之先想办法生出个能顺顺说故事的DEMO来，放宽心接受所有不完美(?
※ 编辑: kuyuzu (124.155.181.89 台湾), 09/25/2021 21:18:16
23F：推 dklassic: 加油～ 09/25 23:13
24F：→ dreamnook: 我觉得是 还在游戏公司时我写的那套也是雷同方式处置 09/26 16:18