找回密码
 立即注册
查看: 1107|回复: 20

你为什么不用unity引擎?

[复制链接]
发表于 2020-11-23 19:00 | 显示全部楼层 |阅读模式
你为什么不用unity引擎?
发表于 2020-11-23 19:00 | 显示全部楼层
========== 鸽了半年的三更!!!!!! ===========

先贴一下目前这个 "用C++徒手撸的自娱自乐级" 游戏项目 的进度吧(流量注意):


https://www.zhihu.com/video/1221401453740564480


https://www.zhihu.com/video/1221402048060620800


https://www.zhihu.com/video/1221402156428984320

测试地图生成
https://www.zhihu.com/video/1225009261644230656
是的,你没看错!!!!!!
在消失的这几个月里,这款游戏几乎被我彻底重写了一遍。像素风变成了Cube风(本质上还是一款渲染二维图元的伪3D游戏)。原先的碰撞检测,区块生成,以及水域也都被回炉重造。
大部分修改基于现实原因。比如:像素动画制作成本过高,旧的碰撞检测效果不理想,旧的水域设计与游戏风格不匹配等等。在未来的几天,我会简单写一两篇文章来介绍这个项目(然!而!并!没!写!好!)


最后,一如之前承诺的,这个项目的 GitHub 地址在此;
    支持 Win10 / MacOSX / Linux暂需玩家自行编译,教程写在 README 中了支持绝大部分 游戏手柄 (Xbox360-Style) 内容上仍旧一片荒芜,暂时只能操纵一只鸡来遍历世界游戏中那种像鼻涕一样浮动,还会不停变色的区域叫做 “异世界入侵的生物汤”(中二)有关它的一切设计,连我自己也在琢磨中...仍存在几个难缠的巨型BUG,如果进入游戏新建存档时发生卡死,请直接退出程序,然后删除 <appRoot>/build/publish/ 目录下的 dataBase 文件夹,然后重来一遍即可...(懒惰如我)
最后的最后,我还是个C++小白,欢迎大佬们多提意见
(公开代码的一霎那无比心虚....)~~~
.

.

.

========== 老旧的原始答案 ===========

.

有一阵子闲得慌,拍大腿决心做款游戏,从零开始的那种。( 倒不是有什么大计划,只是想在人生成就簿的某一行上扎个勾 )


经过一番短暂的考察,初步选定了 C + OpenGL + Sqlite + cmake 赤贫套餐
( PS: 挣扎1周后,果断将 C 替换为了 C++,别问,真男人,打脸奏似要快!)
( PPS: 倒不是对 C 有偏见,只是... C++ 确实是懒人利器啊,懂得自然懂 )
( PPPS:  emmm... 确切地说,是 C++ 的一个子集吧,毕竟我比正常人更懒一些... )
   ( PPPPS: 我一定是被 Clang 惯坏了...  )


之后便开始了填坑生活,时断时续 一直持续到了今天。大部分和 “引擎” 二字沾边的模块都有了雏形。一阵呯嗙敲打后,整个游戏已经可以开始跑了。只不过 游戏内容部分还没正式开做,整个世界显得光秃秃的:
(进度照,临时种几颗树 撑撑场面... 美术资源是随手画的,等未来再统一翻工绘制。嫌丑的握个爪,我也嫌,2333)


原本的构思就是一款可以朝向四周无限探索的 二维-像素风-伪沙盒游戏
    像素颗粒一定要大,这样可以大幅度降低美术工作量,毕竟端尿端屎只有我一个人。 尽可能支持 场景破坏和存储。这就意味着一套特制的碰撞检测模块,和数据存储模块。不求最好,但求契合。 多多利用 perlin noise 来实现地形分布。毕竟,这款游戏的本质就是一个 “伪随机数解释器”


但不管怎样,我使用 C++ 来编程的时间还是太短了,未来指不定会在 编程风格,实现技巧上发生变化,到时再贴进度吧。(在此之前只拿 C++ 实现过一款嵌入式迷你数据库。更早之前则是在用 C 复现一个 类UNIX 迷你操作系统( 没错!统统是拍大腿项目... )


[- 插 -]
一些朋友问到是否开源:确实有开源的打算,这段时间整理中,等准备好了告诉大家(截至2019-6-2,已成功测试跨平台编译(win / mac / ubuntu),不过还有一些问题要修复,请感兴趣的朋友再耐心等几天。
[ 2020-03-12 一如上面的三更所述,这个游戏项目已经开源,欢迎大家吐槽我的糟糕代码蛤蛤蛤(心虚 + 100000...) ]




更更早之前,则是拿 unity 上架了一款这个玩意儿...
(因为没有为 developer 账户续费,这款小游戏已经彻底消失了)
吹水完毕,接下来是正题部分:
制作游戏这个行为,本身也是一局游戏

我从中获得了巨大的乐趣,等价于 花同样的时间去玩其他游戏。
unity 在很多方面为我提供了设计参考。如果说,使用 unity 去制作一款游戏 充满乐趣的话。那么从零开始,为自己的游戏实现一个 简陋但够用 的引擎,则能获得 加倍的乐趣
最后,如果你也想走 OpenGL 路线来作一把死,它的管家glfw 会为你带来小惊喜。开工前一度担心 窗口管理 和 鼠键外设输入方面的问题,没想到都被 glfw 无脑搞定了(没错,我的OpenGL 也是现学的(狗头捂脸...


[二更]

好吧,我的本职其实是 游戏美术 和 商业插画。不过近年来沉迷代码,已经很久不画私图了... 贴几张“年轻”时的渣图丢丢人:
(拖了n年,从没完工的一张图...)


(私下里更喜欢画的类型,毕竟是细画苦手...
话说当年还想以这种画风做个小游戏来着,当然那时候我还没学编程... 也许未来会试一试吧,等某天再次很闲,再次想拍大腿的时候...)
都是旧图,水平有限大佬轻拍。也许会在未来重燃画欲,暂且先在代码中醉生梦死吧~


就此打住!!!严重跑题了2333...

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

×
发表于 2020-11-23 19:01 | 显示全部楼层
现在无论自己学习还是商业项目,Unity都是首选之一。
但是也有很多不用Unity的理由,比如说:
1、Unity不开源,这是个根本问题。
2、很多游戏只是用到Unity的渲染和UI,用不到Unity的大部分特性,可用可不用。这种情况选哪个引擎都可以。
3、大型项目需要顶级优化的情况,用Unity需要自己造很多轮子,用UE也同样需要深度定制和优化。不管用哪个工作量都少不了。(现在Unity也在发展HDRP、ECS等高阶的技术,但还在比较初级的阶段,希望以后能做的更好)
游戏引擎目前还没到某个引擎一统天下的程度,有一些事实:
1、据统计,Steam平台上Unity和UE加起来也就只占大半,还有很大一部分游戏用的不太主流的引擎。
2、独立游戏界,用MonoGame引擎的也不少。甚至会自己做引擎(自己做的引擎可以只针对某个游戏特别优化,也有不少好处)。


我想说的重点是:无论哪个引擎,包括Unity和UE4,都不是坐上龙头位置就稳了,技术方面的问题,总有发展、更新和淘汰。当年Unity就是凭借新颖的设计弯道超车,说不准哪天有新的机遇,新引擎再来弯道超车一次。
我们的心态应该是:既然用了,就好好用,努力在Unity的生命期内做出好游戏。同时祈祷Unity能保持进步,尽量多坚持几年。
——————————2019年6月5日补充——————————————
最近油管上的游戏开发频道在尬吹 Godot Game Engine,说是2019年有可能爆发的一个独立游戏引擎。官网是:
Free and open source 2D and 3D game engine我下载感受了一下下,很轻量运行也很快,不过总体来说还很不完善。
优点是界面风格很像Unity,上手很快,而且有一些特色。特别是针对现在“独立游戏”的流行趋势做了一些设计。
这个真有点之前说的走“弯道”的意思,打准了“独立游戏”、“特殊风格”、“快速开发”这几个点。
不敢独享,这两天我把介绍视频加字幕搬运到B站,欢迎关注这位UP主:
哔哩哔哩 ( ゜- ゜)つロ 乾杯~ Bilibili
发表于 2020-11-23 19:02 | 显示全部楼层
这是一个提了很长时间的问题。以现在的角度来回答会很有意思。
Unity的优点之一,是简单方便易入门,所以占领了手游市场的大部分份额。这同时带来一些成见,例如“感觉Unity不太做得出来高画质的次世代游戏”。虽然事实上并非如此(可参看我的另一个回答:为什么国内那么多开发者喜欢用虚幻或者Unity?),但成见的消除需要一个过程。
Unity对H5小游戏支持不够,等到现在还只有一个试用版的TinyMode。
Unity需要自己写Gameplay, UE4可以使用它提供的Gameplay直接出Demo。
Unity的项目管理这一块有待提高,特别是多人协作开发时。
这里说了很多Unity的不足之处。但是呢,根据咱们一行人多年的研发经验来看,除了这几点,其他的都很好用。尤其是编辑器。
说到底,Unity进化了十几年,已经发展成一款非常强大的引擎。但“强大”并不意味着“适合每一个项目”。咱们广大游戏开发者,一定要清楚自己的目的是“做游戏”而不是“玩转引擎本身”。
发表于 2020-11-23 19:03 | 显示全部楼层
2019.7 更新
并没有不用了,原解释是讲如果使用 Unity 的可能原因。
在今天这个时间段,各家公司都有自家成熟的应用框架了。所以之前说的无框架问题已经不存在了。
~~~~~~~~~~~~
Unity 的一个大问题是不含游戏框架(unreal 有)所以看起来 unity 做东西很容易,其实并非如此。你学习 unity 并不会知道游戏的抽象,只能得到一个强大的编辑器和类库。需要自己做很多基础设施完善。
也许是因为中国做游戏,必须考虑服务器主导,资源远程调度,内容快速迭代,同时要面对大量不同运行环境的实际情况吧
发表于 2020-11-23 19:03 | 显示全部楼层
我不用Unity,我在Unity上自己造引擎。
Unity的人根本就不会用Unity,他们发明了SRP,结果写的HDRP效率不如我们写的MPipeline高,后处理特效(AO, SSR, TAA, Volumetric Lighting)也不如我们做的好看,扩展性也不行(只支持固定的TBDR,CBFR,很难扩展光照模型),最厉害的是,它还崩溃?!还崩溃?!你们自己写的玩意为啥会把自己的编辑器卡崩掉?
再来说DOTS,那个ECS一开始写的丑到脸都绿了,[Inject]是个什么东西能不能解释一下,面向Attribute编程的我除了在Java的Junit里见过还真没见过第二个(JUnit还是负责测试的,这个可是正规项目),然后绕了一大圈就是实现了一个自动调用的Main函数??
引擎挺强的,就是他们自己都不会用。
发表于 2020-11-23 19:03 | 显示全部楼层
Unity 的缺点很多, 比如 Bug 多, API 设计不优雅, 脚本系统性能差又不好用, 奇葩的组件设计, 蹩脚的输入管理......(详见吐槽) 好在其中大部分官方都表示正在或将要改进.

但是我们还是选择 Unity, 因为开发者对引擎的了解程度比起这个引擎是否完美对项目来说更加重要. 之前有考虑过 Unreal, 但谁能保证用 Unreal 就比用 Unity 开发效率更高, 质量更好呢?

如果说要选择其他引擎, 那么原因肯定是 Unity 存在对项目来说难以克服的问题. 好在目前还没遇到, 而且也有其他成功的游戏验证了 Unity (这些开发者被坑的飞起了吧).

吐槽1: Unity bug 多有目共睹, 它们一般 20 天就发个大版本, 如此快速的迭代后果就是不稳定, 经常还发生设计变更, 实在是......
吐槽2: 那个 sharedMesh 和 sharedMaterial 真是够了, 而且还有 sharedMaterials 这样的返回堆对象副本的 API......
吐槽3: 所有的事件回调都塞进 MonoBehavior, 既不好看也不好用. 官方说正在设计新的事件解决方案, 坐等.
吐槽4: 内置组件, 该序列化的数据不序列化, 比如 Rigidbody, 默认质心和惯性张量自动计算, 即使脚本访问修改了数据, 复制这个物体后, 质心和惯性张量还是自动计算的.
吐槽5: ......

再补充几个 Unity 的编辑器的坑吧:
编辑器 API 里各种裸 delegate 访问, 加个 event 不好吗, 某个程序员直接对 delegate 赋值其他人代码就全挂了;
编辑器里很多返回引用的 API, 上次看到一个插件, 那个作者直接修改编辑器风格, 自己的插件看起来正常了, Unity 的界面坏掉了;
写编辑器看起来不是很难, 难的是处理 Undo/Redo, 默认的 Undo 解决方案是针对序列化数据的, Undo/Redo 触发时 Unity 仅对序列化数据执行修改, 其他非序列化数据一概不管. 做个稍微复杂的的插件, Undo/Redo 就能烦死人了;
Editor 设计为特殊目录, 里面放 Editor 代码. 看起来很美好, 实际上很傻. 编辑器少不了要访问私有成员, 而且 Editor 代码不能被 Runtime 代码访问, 最后还是用 UNITY_EDITOR 包起来写到一起算了(有个小技巧, 使用 C# 的 partial 关键字来分离编辑器代码是个不错的选择);
谁能告诉我 Gizmos 和 OnSceneGUI 的本质区别? Gizmos 类不能在 OnSceneGUI 里使用, 但是它们明明看起来是一种东西; 而当你折叠一个组件后, 所有同类组件的 Gizmos 就看不见了......这个设计我始终不能理解......

再补充个: new GameObject 时, 这个 GO 属于哪个 Scene ? 新的 SceneManager 也没有解决这个问题.

成功游戏案例:
The Forest on Steam
Republique on Steam
Cities: Skylines on Steam
Ori and the Blind Forest on Steam
发表于 2020-11-23 19:04 | 显示全部楼层
用unity不能跟投资人说我们有次世代的画面表现啊 拿不多钱咋办
发表于 2020-11-23 19:05 | 显示全部楼层
为什么那么多人喜欢听人黑unity呢? 还要收集各种理由,自己用用不就知道了。

10年开始用 Unity 最近转了 Unreal,但是 Unity还在用。

你为什么不用unity引擎?
手上的VR游戏项目公司指定使用Unreal。 实际上 11年我就已经用 Unity做过VR眼镜的虚拟现实应用了,并没有啥大区别。公司指定Unreal主要是因为Unreal有良好的资源制作管线,较少的工作量就可以达到想要的画质和性能。除此之外Unreal对VR平台的集成,支持的插件等也是不错的优点。还有就是蓝图,在开发原型上可以允许非程序员参与等。Unity虽然也有各种插件可以做到这些,但毕竟不是官方的,插件更新与软件版本更新的延迟等并不如Unreal那么友好。而且Unreal有源码可以自己修改官方不支持的功能。Unity虽然很多情况下都可以解决比如自己写插件或通过反射实现但不如Unreal直接。

以后开发游戏真的只能选unity了吗?
当然不是。unity只是主流而已,并没有说你不用unity就不能开发游戏。 如果楼主的意思是unity会在以后保持主流引擎的地位么,只能说目前阶段unity免费用的人又多,而且学习成本低。 如果有更好的引擎出现自然会替代unity 当前的市场地位,就像unity 替换掉之前的各种商业引擎。至于什么时候出来就不知道了。

如果你不使用unity做游戏,是基于什么样的考虑呢?
a 有更好的通用引擎。 Unity的特点是对程序员比较友好,而且比较小巧易学。不过现在Unity已经开始变得臃肿了,官方和大量用户都在期望unity加入更多的功能,导致unity的复杂性在增加。如果有其他小巧而又能实现各种功能非常方便的引擎,我会考虑尝试的。

b 项目需求。特殊需求无法用unity实现,比如小于5mb 内存之类的要求,或直接指定引擎之类的。(其实3.x 空包3mb多记得, 可惜已经不能发布现有平台)

c unity 迭代版本太多最终变得臃肿了。这时我会考虑寻求其他的解决方案。

d 需要大型团队配合开发,并有很多非unity程序员的项目。unity一直不是非常适合大型团队。当只有我自己负责开发的时候,我可以在设计阶段就规避掉各种坑。但是多人协作的时候并不是所有人都有这种能力,而且因为项目规模我也不可能review 掉所有人的工作。

最后说下我现在觉得unity最需要改进的部分,就是gui。 我从2.5开始用的 OnGUI 到现在的 UGUI 就没有觉得 gui 好用过。这套gui做编辑器扩展真tm好用, 问题拿来做游戏就各种难用。
发表于 2020-11-23 19:06 | 显示全部楼层
    安装时拖家带口一个 Visual Studio / MonoDevelop(虽然可以关掉单独装,但本质还是装了)不喜欢大括号独占一行不喜欢切出去编辑脚本.Net 导致了 VB 的毁灭,厌恶度 +10086国内大有把 C#、Unity、游戏划等号的趋势,我非常讨厌这种趋势
看到 Godot 之后反正就是莫名顺眼,有 bug 我也乐意修,反正就是 Unity 拜拜了 :)
懒得打字嘛,点击右侧快捷回复 【右侧内容,后台自定义】
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

小黑屋|手机版|Unity开发者联盟 ( 粤ICP备20003399号 )

GMT+8, 2024-11-24 04:08 , Processed in 0.150503 second(s), 24 queries .

Powered by Discuz! X3.5 Licensed

© 2001-2024 Discuz! Team.

快速回复 返回顶部 返回列表