自分は長い間趣味でUnreal Engineを触っていました。
初期の有料時代から触っており、アンリアルフェスには何回も参加したし、今は無きブルーマンのTシャツも持ってます。
ただ、Godotでインディーズゲームを作り始めてから、Unrealのここがしんどく、Godotに移行して良かったと思ったことが多数あったので、それをまとめてみたいと思います。
ただ、注意してほしいのは今回紹介するのはUnrealの悪いところではなく、お互いのゲームエンジンの個性です。
その個性が自分のやりたいことに合っていたかどうかの紹介であって、これだからUnrealは悪いという意味ではないのでそこだけ誤解しないようにしてください。
今回紹介してる内容は全部メリットもデメリットも両方あり、自分がやりたいこととGodotのメリットが重なっていたというだけの話です。
ちなみに自分はUnityはほとんど触ったことがないのでUnityの話は一切出てこないです。
1. Godotはアセットがテキストベース
Unrealでは基本的にアセットを.uassetのバイナリ形式で保存しています。
ですが、Godotではリソースの保存にテキストベースの.tresとバイナリの.resの両方が使えるようになっています。
開発プロジェクトでは.tresを基本的に使うのですが、これがGitとの相性が抜群に良いです。
コミット前に変更点が見られる、マージもしやすい、ファイルを管理するうえでは最高のメリットです。
Perforceを使えばバイナリでもできるのかもしれないけど使ったことがないのでわからない…
ただし、3DモデルであってもBase64エンコードされた頂点データなどがそのまま.tresに直書きされているので、重たいアセット/リソースが大量にあるゲームだとUnrealのほうが優れているでしょう。
2. エンジンのソースコードが読める
ここで言う読めるは閲覧できるという意味ではありません。
可読性の話です。
自分はC++は最小限のことしかわからないです。
そんな中、Unrealのコードを読もうとしてもマクロや最適化の嵐で理解するのにかなり時間がかかりました。
ですが、GodotのソースコードはUnrealと比べると、良く言えば素直、悪く言えば最適化なんて知るか、って感じでかなり読みやすいです。
昔SkeletalMeshがどういう構造でモデルデータを保持しているのか読もうとしたけど挫折した記憶があります。
あと個人的にUnrealのソースコードのifのネストは深すぎやしませんかね…
早期リターンするだけでもう少し読みやすくなるとは思うんだけど…
3. ブループリントはやっぱりしんどい…
Unrealを触りたての頃はブループリントは直感的だなと思ってました。
が、ゴリゴリBPで実装しようとするとテキストベースのコードよりもスパゲッティになりやすい。
本当に簡素なスクリプトならかなりいいだろうけどBPのみでゲームを丸々作るのはテキストベースのコードよりしんどみを感じました。
ただ、Godotのスクリプト言語であるGDScriptにも別のしんどさがあります。
そもそも型表現はあるけどかなり表現力が乏しく…
- range-based-forで作った変数は
Variant(いわゆるany)になるし…
for e in enemies: var enemy := e as Enemy # いつも再代入してる- 型引数はネストできないし…
var items: Array[Item] # これはできるvar cells: Array[Array[Cell]] # これはできない- 配列から要素を
getするとき型指定しないとVariantになるし…
var inventories: Array[Item]func _use_item(slot_index: int) -> void: var item: Item = inventories.get(slot_index) # Item型を明示しないとVariantになる var item := inventories[slot_index] # 演算子なら自動で解決できるが境界外にアクセスするとエラーになるinterfaceもtraitもmixinも多重継承もないし…
# えっ? interfaceが無いだって?# 大丈夫、動的スクリプト言語だからNodeから直接メソッドを呼べばいいよ# エラーが怖い? .has_method で確認すればいいじゃん!func get_instigator() -> Character: return _instigator型周りだけで余裕で3時間は話せる。
Golangが好きな自分にとってはつらい。
型たたき券はどこへ置いたっけな…
でもUnrealでもブループリントで基本のコレクション型以外で型引数使えないしな…
でもGDScriptにはそもそもSetがないしな…
(ちょっと待ってGodotのほうが劣勢じゃね…?)
やっぱり独自のスクリプト言語の実装なんてやめたほうがいいのでは…?
4. ちょっと変なことしようとするとUnrealはつらい
昔UnrealでSource EngineのマップインポーターをBPで作ろうとしてたことがあります。
ホントにホントの最小限の動作までこぎつけましたが、山盛りペペロンチーノが出来上がりました。
Source Engine内のBSPブラシをUnreal EngineのBSPブラシに変換するBPのコードはまさに変態的でした。
今のUnrealならGeometry Scriptでもう少し簡単に組めると思うけど、それでも同じ機能をGodotで実装しようと思うArrayMeshを使ってよりシンプルにより素直に書くことができる気がします。
最初ArrayMeshって言葉聞いたときに、なんで配列が関係してんだよ!
って思ったんですが本当に頂点データの配列って意味で拍子抜けした記憶があります。
話がそれましたが、バージョンアップで改善はされていると思うけど、少しそれたことをやろうとすると、Unrealだと結構しんどい印象があります。
5. やっぱりエディタが重い!
うん、いやUnrealのあの多機能さを知ってると正直「ここまで滑らかに動くのすげー!」とはなるんですけど…
そこまで機能を網羅できるほど優れたエンジニアではないのですよ…
やべっ、今日が終わる。
それではこの辺で、お暇~