| |
|
|
| 首页 淘股吧 股票涨跌实时统计 涨停板选股 股票入门 股票书籍 股票问答 分时图选股 跌停板选股 K线图选股 成交量选股 [平安银行] |
| 股市论谈 均线选股 趋势线选股 筹码理论 波浪理论 缠论 MACD指标 KDJ指标 BOLL指标 RSI指标 炒股基础知识 炒股故事 |
| 商业财经 科技知识 汽车百科 工程技术 自然科学 家居生活 设计艺术 财经视频 游戏-- |
| 天天财汇 -> 设计艺术 -> 为什么galgame普遍使用自研引擎而不是unity/ue这种更常见的引擎呢？ -> 正文阅读 |
|
|
[设计艺术]为什么galgame普遍使用自研引擎而不是unity/ue这种更常见的引擎呢？ |
| [收藏本文] 【下载本文】 |
|
既能更好的进行多个平台的推广也不存在不满足需求的问题吧，感觉很多全年龄的gal其实蛮适合移动端的，如果能移植何必去捣鼓模拟器呢？ |
|
这俩引擎比起 krkr 之类的其实也不好用呀 写台本要给策划写专门标记语言的，开发成本不是很高，但这俩引擎至少原生都不带；现在 galgame 比较热门的技术点在跑 L2D，这两个引擎对 L2D 接入都比较差。UE 只有个很多 bug 的社区自行车，Unity 则是只能使一张 mask。对比起来拿 krkr 自己接个 cubism sdk 舒服多了；这俩引擎都收钱。 在国内大家对 Unity 比较熟悉所以用的人比较多。其次就是一些多媒体要素比较多的游戏（黄油），其实用的普遍都是 Unity，并没有普遍用自研引擎。 |
|
因为GalGame和其他游戏不一样。 GalGame需要的引擎功能非常有限也非常简单，但是却和大部分游戏不一样。 GalGame内容大头是剧本播放，辅以简单的状态（选择支）、视频播放、存档功能，就差不多了。 要玩花的，来点震动、破碎之类的简单画面效果和Live2D顶天了。 所以GalGame的引擎开发难度低，但是方向偏，和大部分游戏的引擎并不是一个路数。 因此GalGame早早就有一批自己的引擎了。后来者自然继续用。 而unity/ue的侧重方向和GalGame并不对路，用他们往往还得二次开发，并没什么优势。 而且因为GalGame的低技术含量，开发人员技术水平一般也不高，即使不考虑unity/ue本身的费用，GalGame经常也用不起。 最后，全年龄GalGame赚不赚钱是十分可疑的。尤其是对小厂来说，PC上出18X才是主战场。 |
|
ue4/unity对于gal这种游戏类型的支持还不如“橙光”，认真的… |
|
几乎百分之一百的galgame可以用PPT做出来。 当然有些某大厂出来的就会说：啊啊啊，你懂付费系统吗？你懂live2d吗？你懂数值系统吗？ 你懂PPT吗？ |
|
因为用不着啊兄弟 情况异常极端的话，用PPT都不是不能做。。。 |
|
你们无法理解日本gal小团队技术力能有多低——所有成员都不懂代码那是普遍现象，只会把官方脚本案例复制粘贴改改文本那算不错了。 unity用的C#哪有那么简单，你要他们自己实现随时存档之类的功能还不如让他们自沉东京湾。 ue用的C++，这个难度不用我说了，至于蓝图就不适合用来做gal。 我不是鄙视日本it行业，就算是日本，程序员也不是薪水很低的职业，99%的gal团队并没有固定资金来源，不可能聘请职业程序员，甚至外包定制的钱都没有，就算是比较有名的团队也可能出现请不起绘师的情况，比如《纸上魔法使》的团队ウグイスカグラ，找过一次美术外包之后，后面的据猜测大多数是早期ai还不会调参的那种绘图（没错我就是说桐叶是ai），发张给大家看看： |
|
|
ウグイスカグラ的剧本水平在gal圈里也算非常高了，该团队最近几个游戏，除了有个抄袭苍之彼方的之外，全是爆款，就这，还请不起全职美术更请不起程序，该团队每个游戏刚发售的版本几乎都不能正常运行，都是几个小时内就发布补丁，用krkr这么成熟的引擎还能这样，ウグイスカグラ团队经济实力可想而知。gal圈中上层能这个样子，再往下那就不用说了 |
|
首先，自研引擎现在已经没几家在用了，还在用的大部分也是十几年下来的惯性，新会社基本都是KIRIKIRI、NScript、Siglus之类。 其次，把同人也算进去的话，用unity的可一点也不少： |
|
|
最后，很多旧作都有官方的安卓移植版，你没见过是因为这玩意儿失败到了作盗版的都懒得盗的地步。 |
|
EVA很牛逼，但它是用来打使徒的，而不是帮加持的瓜田锄地的。 顺便我一直觉得，如果只是点点点播剧情切cg的话，PPT也可以做得很好。 |
|
开发gal engine有多简单？ 为了让《逃出青龙山》逃出橙光游戏，我花一个月完成了文字引擎开发和移植… |
|
|
（当然功能都是阉割版…） 第二，unity只是通用游戏引擎，你要基于unity开发gal不还是得有个gal引擎？ 第三，考虑到跨平台的话，要么h5要么unity，单平台引擎会被淘汰 第四，你要不要统计一下再问啊，我怀疑题目都不成立 |
|
二十年前一般人手里哪有Unity和UE 二十年后galgame圈子已经有了路径依赖，日本很多大厂都有了自己的一套东西，同人小组也一般会跟着前辈走 至于移动端，日本很多玩家有Windows掌机，不需要模拟器 国内对那些老引擎的路径依赖比日本低一些，很多galgame其实都已经上了移动端，它们中有很多也确实是web套壳，比如在TapTap上搜一下 好玩的AVG类手游推荐 | TapTap?www.taptap.com/tag/AVG 还有一些galgame不上移动端也不是技术原因，而是因为汉化和移植属于法律的灰色地带，不能让圈子过分扩大。这方面有很多争议，比如可以看看 @Icemic 的几篇文章 Icemic：一 | Narcissu：我们离合法汉化有多远？251 赞同 · 24 评论文章 |
|
|
Icemic：二 | ONScripter：向着荒野进发67 赞同 · 19 评论文章 |
|
|
Icemic：三 | ACGFuture：是非成败转头空（上篇）46 赞同 · 32 评论文章 |
|
|
Icemic：呓语 | 国产 Galgame 与错过的移动互联网29 赞同 · 44 评论文章 |
|
|
不过我个人还是希望能改变这种现状 |
|
如果大部分galgame使用的是自研引擎，那unity和ue也可以算自研引擎了…… KIRIKIRI和NScriptor是以前常用的引擎，那时候unity和ue都还没有呢，这两个引擎是开源的，任何人都能用，很多同人galgame都是靠这两个引擎做的。 现在常用的Buriko General Interpreter，算是很厉害的引擎，很多公司在用，有些公司确实自研了一些引擎，因为galgame本身技术含量不高，大部分是KIRIKIRI和NScriptor改造的，增加了自己需要的额外功能，或者增强了某些表现效果。 另外，制作galgame用unity和ue，就像用txt就能记录的内容用photoshop记录一样，绝大部分内容使用不到不说，基础的操作都变麻烦了，galgame的制作软件简单到像写小说一样就能完成，素材准备好，哗啦啦就能往下做，有多简单可以看看橙光的制作教程，录个视频教别人做游戏甚至都录不满一小时。 引擎就是为了方便人而产生的，什么方便就用什么，很简单的道理。 |
|
可能是这些galgame的开发团队已经有了自己惯用的开发框架/引擎吧。galgame的需求也相对固定，在这种情况下一直用现成的框架可以少走很多弯路。 新组建的galgame团队使用自研或专用引擎并不一定就是最优选择，例如我们团队在2019年才开了第一个galgame项目（《夏恋幻梦》），在这种情况下我们选择的是使用Unity+Naninovel来开发游戏。Naninovel可以解决80%galgame开发中的一般需求，例如打印文本，绑定台词和角色，随处存档等；而对于项目特殊的需求，Unity本身的强大扩展性（相比Galgame专用引擎）也可以让我们很方便地扩展新的游戏系统，因此对于我们来说是最合适的选择。 |
|
习惯。 大部分“老牌”gal厂商，都是在没有通用游戏引擎的时代发展起来的，自然会使用自研引擎。之后要迁移到unity的话，还需要额外学习unity；继续用之前的就不需要额外学习。 我猜测未来20年中新出现的gal公司应该会主要使用unity了。假设还有专门做gal的公司的话。 |
|
Galgame使用自研引擎的主要原因是因为它们的需求与其他游戏类型不同。自研引擎可以更好地满足这些需求，并提供更好的表现和优化。 首先，Galgame通常有大量的场景切换和对话，需要高效的文本和图片渲染，自研引擎可以更好地满足这些需求。其次，Galgame通常没有太多的复杂交互和物理模拟，相比之下，使用通用的游戏引擎可能会导致性能损失和不必要的复杂度。 此外，Galgame通常由小型团队或个人开发，他们可能没有足够的资源来购买或使用高级的游戏引擎。使用自研引擎可以为他们节省成本，并且可以根据需求进行定制。 总之，虽然使用通用的游戏引擎如Unity和UE也是可行的，但自研引擎更适合满足Galgame的特殊需求和小型团队的开发需求。 |
|
因为galgame这个领域有很多类似python这种脚本语言轻量级方案, 那为啥要去用c#和c++？ 人生苦短啊，兄弟。 |
|
你让一个不太需要3D的品类，去用一个集成大量模块以支持3D的引擎？ 其实做设计的倒是无所谓，反倒是比较折磨玩家。 |
|
先问有没有再问为什么（ 本人已知的用Unity引擎的日本galgame会社发售的游戏有三款 はちみつそふと社的アイシング-love coating-，画师是綾瀬はづき，之前的作品是音符社的Secret Agent～騎士学園の忍びなるもの～。 GIGA社的Baldr Sky Zero1+2，大名鼎鼎的格斗游戏，Baldr Sky的发售时间续作，剧情时间线上的前作。 |
|
|
|
|
|
|
|
|
还有在steam上发售，曾经被动画化的知名游戏——苍之彼方的四重奏的官方汉化版。（该做在发售时用的引擎和枕社的超级糖果为同一引擎，后因为冷饭社汉化封包难度问题该用unity高清汉化重置x） 接下来说为什么不选择用Unreal、Unity这类的现代引擎。 我是说可能，啊，有没有一种可能。 美少女游戏这类视觉系小说，在最火热的时代完全用不到，也没有现代引擎可用呢？ 众所周知早在上个世纪90年代就已经开始有已经有相当数量的galgame发售，国内知名话题作“近月少女的礼仪”的两位主原画鈴平ひろ、西又葵也在这个时期开始活跃，Baldr系列的发售时间最早作品是在1999年发售的“武装金融外传”（剧情时间的话反而是第二作BALDR BULLET，这作甚至被GIGA的母公司，台湾厂商代理，并以全年龄的形式在国内发售过） 在这个时间点的各个galgame会社是没有Unreal和Unity使用的，绝大部分都是自行使用DirectX API开发（比如Baldr系列以及后续的闪钢都是祖传的DX9-11原生引擎，使用精灵图的形式进行的格斗游戏），几乎当时每个社都有自己的开发方式。 而在进入新世纪之后，除了财大气粗依旧有能力更新自研引擎的GIGA和“花了一个亿做OP”的minori之外，其他会社基本上逐渐开始使用专用的galgame开发引擎，比如krkr、BGI等，请参考下面的回答： 请问目前为止已知的GALGAME制作引擎有什么？ - 虚無連斬的回答 - 知乎 https://www.zhihu.com/question/22981630/answer/59187494 这些引擎早在现代引擎大批量使用之前就已经被各个游戏会社所使用，且开发成本及学习成本极低，krkr的脚本是javascript，几乎可以说是以前的日本IT业界谁都会用一点的东西。 还有游戏的用户群体，绝大多数就不是拥有高性能PC的用户，当年Baldr Sky就对性能是极大的挑战，并且因为API的问题导致超过1G的内存申请会直接抛出异常然后游戏崩溃。 之后用Unity3开发的Baldr Sky Zero更是灾难，支持FXAA、SSAO技术给这款游戏带来了真次世代的画面表现，但同时糟糕的操作手感，放在当时几乎只有旗舰台式机才能流畅运行的极差优化让GIGA在Baldr Sky的剧情后续作“Baldr Hreat”里放弃了Unity，用回了原来的自研引擎。 而且放在当时已经是极其大胆的尝试了，就连同时期的手游业界，也是只有SE2014年才上线了以Unity开发的手机游戏，乖离性百万亚瑟王。 还有有没有一种可能，其实现在大多数能以移植方式在手机上玩到的日本美少女游戏，都是因为krkr本身就支持安卓系统呢？（当然还请能支持正版支持正版，不推荐这种行为） 不管是美少女游戏业界蓬勃发展的00年-10年，还是逐渐衰落的现在，程序开发自始至终都不是美少女游戏的开发主力，真正重要的是剧本和原画以及音乐，像学习成本极高的Unreal，还是相对较低的Unity，在开发成本上都比先行的引擎高太多，这才是不使用现代引擎的真正原因。 顺便高赞的煞笔回答属实给我看乐了，ウグイスカグラ在立社之初桐叶就是做为原画加入，一直当辅助原画的萩野小唄更是在曾经还是社团的时候就在其中，有大批第二原画和辅助原画出线的时候是第二作水葬银货，吹rkr着实不是好风气，说抄袭苍之彼方的四重奏的空に刻んだパラレログラム，销量甚至比发出来喷崩的冥契更高。 甚至认为ウグイスカグラ这种社团体量的会社叫做gal圈中上层，甚至说出“请不起全职美术”这种令人发笑的话，多少有点撞懂王了。 |
|
这个最关键的原因是学习成本。 galgame引擎本质上不是编程工具，而是类似于WPS、美图秀秀这种编辑器。 作为最简单的那种galgame编辑器，基本上就跟写小说一样，到位置打回车就行了，然后指定说话人、指定当前显示哪张图。 一共三种指令，上手难度极低。 而是……支持几乎所有活着的平台（电脑，手机，各种你认识不认识的掌机……后面好像还有web了） 这样的需求，并不是专业游戏开发软件擅长的，甚至说，专业游戏开发软件恰恰在做相反的事： 针对每个平台提供最优性能方案，而不追求跨平台发行 针对每个细节给出可定制接口，而不追求简单不需要配置。 最后再强调一句，我们说的galgame其实不是galgame的原意！ 我们说的这个，叫电子多媒体小说，是AVG游戏的一种特殊分支。其主要开发者，不是程序员，是小说作家！ galgame，特指的是美少女题材的电子多媒体小说。 |
|
移动端的优势是随时随地可以玩，没人会想在地铁上推galgame |
|
我是一个u3d开发者 前段时间和同事聊天说起某个项目里面的功能简单到用ppt都能做，然后就研究了下将ppt文件打包成exe的可能性... 最近要做ppt的时候，思前想后（懒得用脑）用u3d做出来了... 我要说的是，多个工具都可以实现同样目的的情况下，人们自然会选择最顺手的、学习成本最低的、后患最少的。 U3D本身可视化程度不高，需要更大学习成本。虽然说有插件可以增加可视化程度，但插件不免费、用盗版提高后患可能、用的人少代表难解决的bug越多等各种理由，更别说U3D商业用途本身不算完全免费。 之前试过几个国产的AVG引擎，用那些引擎可视化程度高，代码量很少甚至没有，轮子都是现成的，创作者可以更专注于游戏剧情等质量上，何乐而不为呢 |
|
我这就有个galgame的unity demo，unity还是5.0左右的时候就有了，功能完备，是代码苦手的好帮手。 |
|
对小成本galgame来说，unity/ue完全没有必要，因为演出方式比较简单完全没必要自己造轮子，除非你想往里面加小游戏，然而用pygame也可以写。 你拿unity写一套ui，renpy/krkr早就把整体框架流程搭完了甚至都可以开始填充内容了。况且现在renpy也有摄像机模拟，可以搞一些简单的3d演出 对商业galgame来说，一方面为了更好的演出和完善的工具链，自定义引擎可以贴合开发人员的习惯；另一方面在游戏加密上也有要求，增大解包难度也是有必要的；还有可能就是懒得用unity，学习新的东西也有成本 |
|
谢邀， 首先Galgame为什么要用unity/ue？ 个人观点，如果不打算做3d内容的话，用unity/ue纯属自找麻烦。 ue没怎么用过，但unity你要做gal的话，引擎本身对剧本播放和管理的支持是不够的，甚至可能不如直接用PPT，所以最后还是要自己写一套或者下载三方插件，自己写的话那和自研也没什么区别了，而下三方插件的话为啥不直接用专门做gal的引擎？ 另外只考虑平台迁移问题的话，个人认为web套壳才是最佳的全平台方案。 |
|
你多久不玩galgame了？ 现在那些3d小黄油，就是那种欧美白皮大胸大屁股建模，情节是我的表姐我的继母之类的 基本都是Unity套壳，而且还贴心的准备了linux和android版本，我想就是为了平台适应性 |
|
绝大多数的galgame都不会上3d和live2d，用ppt都能做。unity3d没怎么用过，UE根本没有galgame的模板，你得全部自己写 而且无论是unity还是ue，都需要比较高端的电脑来完成开发。哪怕你做一个纯2d的游戏，生成都要不少的时间 另外，上unity/ue是收费的。 虚幻引擎4收费标准是什么？?www.zhihu.com/question/40638315?utm_id=0 其实现在galgame的引擎也不少，ons、renpy之类的已经很够用了，而且其实这些引擎很多也是跨平台的。不少galgame如果有全年龄版本，一般也可以在日区的AppStore下载到移动版 |
|
哪儿有那么多自研？ 不都是 krkr 啥的做的么？ 手机端有 krkr ons 之类的模拟器啊，跑游戏没问题。。 连 rpgmaker 的模拟器都有啊。。 |
|
ue和unity因为起家时间太晚，既没经历过早期性能吃紧的时代，也没怎么做过实际上的2d游戏。 结果就是2d绘图性能以及本底优化普遍糟糕，像最早版本的EPICS store就是拿ue搓的，那开着啥都不干，都是能吃掉半个CPU核心的水平。 unity早年甚至连2d游戏引擎都不能算是，能画UI是真的，但游戏引擎意义上的2d支持其实真也没几年。 就算不说易用性，实际上这些玩意的2d效率也是完全不够的。 其次gal的需求比较简单——视频播放，脚本挂图片，文字以及链接场景，一般最多加l2d。 这有个问题是在于大部分gal公司大概率是请不起，也不需要全职程序的，只需要有人填模板，有的人会基本的程序搞搞基础维护就行。 unity和ue这种复杂结构虽然在稍大项目上会便利很多，但在简单项目上容易翻莫名其妙的船，非常浪费开发力。 |
|
nscripter、krkr、renpy：？ 数据持久化，随时回滚哪个更简单？ 那些说ppt做gal的都是怎么数据持久化的？不能存档读档回滚？一度怀疑弱智吧打过来了 |
|
|
|
|
因为属于抓兔用牛刀，UE4和U3D都是3D为主打的强大游戏引擎，就算是GODOT也不过是在2D方面有出彩表现，3D远不如UNITY3D的，那么问题来了，为什么做个GAL要用3D实力那么强大的引擎？不是多此一举吗？不是做不了，而是做出来没必要。比如你可以像原神那样，弄个3D人物站在面前和你谈恋爱，然后可以安排触碰位置，鼠标点在3D模型上人物会通过状态机系统做出不同的害羞动作或者揍你一顿等等。而且UNITY也有真菌这样的GAL插件，做出来是分分钟的事情。 说白了GAL就是一个面向过程语言一样的的顺序结构，写出来的脚本，那么C#和C++当然很容易实现了。可以在TXT文件或者JSON文件那写 [picmove left=50 right=0] say:哥哥，该起床了。 Scene conversion=1 ....... 然后读取进去用语法分析就可以做出来了。KRKR也是这种样子实现的 |
|
因为没需求呗。 日本游戏在国际化上普遍有着极为严重的编码问题，还有Sigrus的区域问题等等。 他们要是换用Unity至少编码能统一到Utf8，但事实上却是开发的时候根本没有国际化需求（特别是中文这类），也不像其他游戏那样有什么性能需求（显卡加速啥的完全不需要），既然能用为什么要换一个新的技术栈？ 另一方面相比Unity这类通用引擎，现有的Galgame引擎比较脚本化，远比写相对复杂的C#简单，好上手，而大多数galgame没有复杂的需求，在Unity没有比较好的VN框架之前，换引擎动力不大，也没有意义。 不过也有些Galgame在用Renpy之类的（日本区域很少），一些SLG/RPG也迁移到RPG Maker MV和Unity了。 |
|
很少用自研吧 像现在python热度比较高，renpy就用得挺多 |
|
问题有误，大部分公司用的也不是自研引擎，而是基于业内常见的引擎（如 NScript）进行开发。 大部分 galgame 用不到 3d 渲染能力，用个 live2d 渲染就已经有很强的表现力了。 由于常年使用某些引擎，内部积累以及行业内的解决方案已经非常完善了（如给策划用的填剧情系统），一两个程序员就能支撑起新游戏的架子，使得大部分预算都可以分配在剧本策划和美术上。 |
|
unity一点也不少啊 欧美和中文圈都挺喜欢用 另外renpy啊还有各种RPGMaker就不是通用引擎了吗 |
|
GalGame与其它类型游戏，从程序的角度来说，最显著的区别是GalGame在剧情中随时可存档，但是Unity和UE都没有对此提供任何支持，它们的脚本系统都是不支持这种灵活存档的，这就意味着，如果要用这些引擎开发GalGame，需要熟悉这些引擎，在此基础上，为这些引擎开发相应的剧本系统，相比起来，自研引擎相比改造Unity/UE，多出来的也就是一个音频系统一个UI系统，在这个开源代码满天飞的时代，这些都不是什么难点。所以不用这类商业引擎也不是不能理解。 ———————————————— 我说的“它们的脚本系统都不支持这种灵活存档”是这样的意思：galgame需要存档的状态包含了脚本解释器的指令寄存器的值，简单的理解就是需要保存执行到哪一行代码（或者哪一个代码块），读取存档后继续执行。而不管是C#还是C++或者蓝图或者Lua都是没有这个功能的，所以需要自己实现一个解释器（可能表现为对脚本代码的解释或者对数据文件的解释）。 |
|
|
| [收藏本文] 【下载本文】 |
| 上一篇文章 下一篇文章 查看所有文章 |
|
|
|
| 股票涨跌实时统计 涨停板选股 分时图选股 跌停板选股 K线图选股 成交量选股 均线选股 趋势线选股 筹码理论 波浪理论 缠论 MACD指标 KDJ指标 BOLL指标 RSI指标 炒股基础知识 炒股故事 |
| 网站联系: qq:121756557 email:121756557@qq.com 天天财汇 |