介绍

从Objective-C开始，我一直在做游戏。
从半年前开始，我开始使用Unity制作游戏。
本文介绍了此更改的原因以及Swift和Unity技术之间的差异。

关于我使用的技术

在这里，我将介绍我所使用的技术以及为何停止使用它。

OpenGL2

游戏正在动态地改变事物！
出于这个原因进行调查时，OpenGL适合制作动画，所以我买了一本书，学习了OpenGL。
我通过用Objective-C控制OpenGL制作了射击游戏。

退出原因

OpenGL是用于绘制2D游戏的技术，但是没有知识就很难。
例如，仅导入PNG文件并将其显示在屏幕上就需要编写大量代码。
另外，如果您控制不当，屏幕可能会闪烁或一帧之前绘制的图像可能会残留为残像。

例如，当编写一个在Dragon Quest之类的地图中四处走动的过程时，有必要在每次移动时绘制整个背景图。 (以我的技能)

无论如何，这很困难而且代码量很大，所以当我制作大约3部作品时，我决定改用另一种技术。

Cocos2d-iPhone(SpriteBuilder)

"是否有无需直接使用OpenGL就可以处理OpenGL的技术？"
我发现了Unity和Cocos2d。

我应该在此时选择Unity，但是当时Unity专用于3D，对我来说是一个很高的门槛。
另外，Cocos2d-iPhone能够用当时最新的语言Swift进行编码，因此我也选择Cocos2d-iPhone进行学习。
(为此，我提高了当时在业务中使用的Swift技能。)

由于

Cocos2d可以轻松操作OpenGL，并且还支持名为Tiled的图块映射库，因此开发速度立即得到了提高。
(在使用Cocos2d-iPhone之前，我自己读取了Tiled的数据，因此有很多错误和很多代码。)

老实说，这项技术不是最好的！我想。

退出原因

但是，当我跳到这个Cocos2d-iPhone的那一刻，对Cocos2d-iPhone的支持就结束了。
支持结束后，我已经使用了一段时间，但是每次XCode更新时，我都必须重写Cocos2d-iPhone的内容才能卡住。
(这项工作真的很痛苦。没有文献，因为它没有得到支持，这是徘徊，更改和检查Cocos2d-iPhone内容的地狱工作。)
在这里，我又迷失了露头。

SpriteKit

我不想直接触摸

OpenGL，当我想知道该怎么做时，Apple宣布了SpriteKit。
有了它，您可以直接操作OpenGL，并且由于它得到了Apple Inc.的支持，因此我跳槽了不停止支持的想法。

我不喜欢

Cocos2d-iPhone的第二支舞，所以我没有选择Cocos2d-x。
(这也是我不喜欢触摸C的原因。)

退出原因

但是，SpriteKit在许多方面都不如Cocos2d。
例如，不支持Tiled(尽管它在中间居中支持???)，所以创建地图的过程是我自己的。
另外，当我使用该工具创建Scene时，它刚刚掉线。

我已经使用了很长一段时间，但是并没有变得很方便。
显然，苹果公司不愿意改进这项技术。

斯威夫特

由于以上原因，我们将开始使用Apple的正版Swift制作比UI更面向游戏的游戏。
我决定仅在需要动画的地方使用SpriteKit。

退出原因

由于是真正的

，因此在UI周围创建时没有问题，但是由于插入SpriteKit插入动画时坐标计算方法不同，因此统一了xib文件和sks文件的可操作性很难完成它。

即使我想添加更多的动画，我也没意识到，因为上述原因，它将是复杂的代码。

为什么我改用Unity

像这样曲折，我到达了Unity。 (我觉得我走了弯路。)
在这个时代，Unity在2D游戏中也有很多成就。

选择

Unity的主要原因如下。

• 这是我看过的最主要的东西。
• 它是跨平台的。
• 有很多文献。
• 我以为只有Unity才能完成。 (实际上，编辑器必须选择VB等。)
• 可以用C#编写。 (我是一位经验丰富的C#人员。)

由于这些原因，我决定使用Unity进行游戏。

困惑点

当我开始

Unity时，最令人困惑的事情是以Scene为单位制作游戏。
使用Xcode进行游戏时，可以使用StoryBoard设置开始屏幕，也可以从AppDelegate调用sks或xib，因此很容易理解引线，但这是为了Unity我很困惑，因为找不到如此清晰的电线。
我还对"如何在Scene之间交换数据？"感到困惑。

由于每个开发人员对Prefab的看法不同，这是一种创建通用零件的方法，哪种方法最好？我很担心。

之后，担心该角色在任何文件夹结构中应该由文件夹名称更改。
(我仍然对此感到担心。)

顺便说一句，我从现代语言Swift返回到稍微古老的语言C#，所以我认为编写代码时会很不方便。
(当然，这里有一些便利，但是用以后的语言编写仍然很容易。C#选项很差，所以当您从Swift移开时，代码会感到很奇怪。Lam??bda也是多余的???它不会停止。) <铅>

改变的好点

Unity的伟大之处在于，您无需编写就无需接触OpenGL和Metal等底层。
您不必触摸SpriteKit的下层，但是编辑器经常掉下来，几乎没有可以处理的对象(甚至不能使用文本框)。因此，仅此一项便是用Unity取代它的一大优势。

左右的用户界面

这是最大的好处。
Unity很容易写在UI周围。
当我使用SpriteKit时，它通常会掉在中间，而使用Unity时，它并不会掉很多。 (很少跌倒)
此外，我擅长创建复杂的UI，Prefab的设计(这是常见的一部分)确实非常出色。

创建气氛很容易，因为当我在照明周围检查了一点时，就出现了2D Light等。

无论如何，通过搜索Google可以实现大多数事情，这是一件好事。

跨平台

此外，可以轻松支持iOS和Android是一件好事，因为每个平台的支持都很丰富。
C#还有更多代码，但是一旦我习惯了，我就不在乎了。

环绕声源

Unity也对此提供支持，能够轻松地在详细设置周围设置支持是一件好事(我指的是本书，但???)。
(有时是用XCode实现的，没有声音。)

平铺地图

它比

Cocos2d弱，但是支持围绕图块地图绘制很有帮助。
(我想将信息嵌入放置的磁贴中，但是不支持此操作。)

处理本地数据

使用XCode处理本地数据时，文件夹层次结构非常深，如果升级XCode版本，它将丢失。
但是，由于将Unity内部的本地数据输出到一个固定的文件夹，因此即使Unity的版本更改了，本地数据也不会消失很方便。
(Unity可以轻松更改版本。如果使用git管理它，则恢复它并不难。)

您不必自己制作FPS计时器

Unity应该在FPS计时器上运行，因此您不必在此处创建自己的处理程序。
在SpriteKit的情况下，对象是通过Move之类的方法移动的，但是由于C#具有协程，因此在动画制作方面我没有太多麻烦。
(我仍然不知道哪种方法更适合使用FPS或方法移动，但是当我看到类似iTweet的库时，似乎Unity中有些人希望使用方法移动。)

在OpneGL时代，我很难制作自己的FPS，因此我认为只有协程可以使编写代码变得更加容易。

可以使用ScriptableObject。

使用XCode描述周围的设置时，Plist是主要力量。
该Plist应该处于某个级别，但是随着数据量的增加，管理变得复杂。
在这方面，使用Unity的ScriptableObject(尽管我有一个习惯)，我能够自由地创建模式，这使得管理起来更加容易。
看来您也可以使用Excel等导入，但是也可以使用XCode进行导入，因此我将省略它。
(我想尽可能地在同一环境中管理数据，所以我真的不喜欢用Excel等进行转换的双重管理方法。)

左右的帐单

小型实现非常容易。
IAP允许您用很少的代码来实现它。
如果您放入收据支票。 .. ..好吧，在任何环境下都很难，不是吗？

(资产商店)

有一种机制可以让您立即购买所需的程序和资料。
我真的很感激。
我尚未在Unity上发布游戏，但是我可能在这家商店购买了数万日元或更多。
那很方便！

其他

还有其他事情，但是暂时，我写下了我能记住的要点。
就我个人而言，我认为上述提到的UI和跨平台的好处是最大的。

难点改变

但是，仍然存在一些困难。
我也写了关于混乱的文章，但是???

程序弱

现代语言通常是根据过去程序的优点编写的。
因此，它与将近15年前制作的C#有很大的不同。
对于RxSwift之类的库，最好用UniRx等代替，但是基本语法很烦人。

• 枚举不能有一个方法。 (可以扩展，但是代码分散)
• 即使枚举案例中有泄漏，也不会发生编译错误。 (我认为这是有利有弊，但是Swift的这一功能使您的工作效率更高。)
• 您不能在lambda表达式中使用诸如$0之类的缩写。 (即使是简单的lambda表达式也将是多余的。)
• 可选类型很弱(可以使用?等，但是由于它不是可选类型，因此需要进行null检查。可空表类型代码变得多余。)
• 强制转换很弱(当然不能使用if let = optional，并且不会隐式强制转换为父对象，因此您需要一一编写泛型代码。这很尴尬。)
• 在Switch语句中不能使用相同的大小写。 (因为不能说case a,b:且需要break，所以即使具有相同属性的值也必须编写代码。)
• 变量的范围有些混乱。 (退出if语句后，只能在if语句中使用的变量无法重新定义。这与如何编写程序有关，但是诸如item之类的变量在作用域内外具有不同的含义。我可以使用它在???)

• 没有flatMap系统。 (有相似和不相似的东西，但是……好吧，这是语言特性的问题，所以无法解决。我经常使用flatMap系统，因此有点麻烦。)

好吧，当我把它写出来的时候，它没有锋利的边缘???
那些从Swift移到Unity的人可能会对ラムダ，オプショナル和Enum感到"什么？"。

多屏支持

Unity与各种平台兼容，但是我觉得多屏支持有些薄弱。
如果它是Xcode，则使用Constraints支持ラベルが横に長くなったり縦に長くなっても没什么大问题。
但是，Unity不允许这样做。
您基本上将其放置在屏幕上的哪个位置？我们只能处理到这一点。 (也许)

但是，我认为这可能是优先处理速度的结果，因为使用SpriteKit时遇到了相同的问题。

滚动不良

Unity滚动被设计为在不加思索的情况下消耗大量内存。
如果您仅显示一个滚动条中的约500个项目，则仅通过显示上部即可呈现500个数据。

但是，与SpriteKit相比，??? SpriteKit没有滚动???(当然
XCode滚动有一个习惯，但是您可以放心使用它，因为它可以高速渲染。

总之，我自己解决了滚动问题。

Firebase

上的冷

可能不只是Firebase。由于可以为Android和iOS分别创建第三方，因此设置方法对于Android和iOS是不同的。
Android并不是那么糟糕，但是iOS最终需要使用Pods，因此Unity本机用户发现很难安装。
另外，有时Android和iOS之间的处理结果也不同。 (仅用于分析。Realtime database感觉相同。不支持Firestore。)

多语种为

由于

Unity遍及全球，因此我认为它是多语言支持的理想之选，但我必须自己做。
XCode实际上是相同的(我想大多数人会自己实现它，因为XCode提供的机制很难使用)。

初始化

中有陷阱

RuntimeInitializeOnLoadMethod可用于在应用启动之前进行处理???
如果您在此处阅读配置文件，发出其他线程等信息，则该应用程序有时可能会崩溃。
这只是一个习惯问题，但是它非常方便，如果您打包所有初始化处理，就会遇到一个神秘的错误(该错误在启动后立即冻结)。
我花了几个星期才注意到原因。

某些版本不起作用

这也是不可避免的，但是在Mac版本成为Catalina之后的一段时间内，即使将其从Unity转移到实际设备上，有时也无法使用。
就XCode而言，它是由同一家Apple公司生产的，因此在实际转让后它不起作用，而是???

由于它是

，因此在更改Unity版本时需要小心。

另外，如果您更改Unity的版本，则可能需要更新XCode的Pods或重新创建多语言文件，因此这是一个恶魔。

最后

最后，我写了很多问题，但这是因为我不习惯Unity，这不是一个无法解决的问题。
相反，Unity的开发效率要高得多。
如果您想制作游戏并且可以清除上面的内容，建议您选择Unity。

但是，建议为业务系统分别编写Swift和Kotlin。
不能给出关于操作系统的直接说明是有点严格的规定，并且业务程序不会太大(服务器应该能够吸收处理过程)，因此建议单独编写它们。