【ゲーム開発】Lore はローカルで使うだけならとても簡単【バージョン管理】

テキストファイルとか、Word のファイルとか、ファイルなら何でも良いんですが、この変更を記録するためのアプリです。
バックアップ用としても使えます。

これは Git の GUI アプリ

ソフト開発、ゲーム開発に限らず、絵を描いたり、CAD などで何かの設計図を作ったり、動画の編集でも、会議の資料でも、何でも良いです。
「やっぱりこれ微妙だから、昨日の状態まで戻したいな…」と思うことは、少なからずあるものです。
これを簡単にできます。

そのためには、1 時間毎とか、キリが良いタイミングとか、編集したファイルをバージョン管理アプリに登録する必要があります。
そうやって履歴を積み重ねていくことで、やっぱりこの 3 日分の変更をなかったことにしたい…となったときに、履歴から選択するだけで戻せます。
戻したけど、やっぱり最新の更新の方が良かった！となっても、最新の履歴を選択するだけです。

バージョン管理アプリが本領を発揮するのは、チームで作業をするときです。

他の人の作業を自分のローカルの作業内容に反映するということはもちろんできます。
このとき、自分の作業内容が他の人の作業内容とバッティング（コンフリクト、衝突、競合などと言う）するかどうかが分かります。

コンフリクトすると解決に時間がかかるので、そもそもコンフリクトが起きない作業分担をするか、難しい場合は、作業するファイルを他の人が変更できないようにロックをかけるのが良いです。

A さんと B さんが同じファイルを編集してコンフリクトした場合、そのファイル内の変更箇所が違う場合は、アプリ側で双方の変更箇所を合成（マージと言う）できる場合があります。

マージが無理な場合は、A さんの変更を活かすか、B さんの変更を活かすかを双方で話し合って決めます。
マージは問題になりやすいので、チーム内でルールが決まっていたります。

また、マージ機能に関しては、アプリによってはクソだったりするので、使う前によく検証した方が良いポイントです。

管理するファイルが 1 万、10 万、100 万といった膨大な数になる、50 人以上のメンバーが頻繁にリポジトリを更新する可能性がある場合、ローカルを最新の状態に更新したり、ローカルの変更をブランチにマージするときの待ち時間が長くなるようなものは使わない方が良いです。
ただ、この点については事前に確認するのが難しいです。
私が使ったものの中でしか分からないですが、無料や安価なアプリは大規模開発には向いていません。

Unreal Engine 5.8 の時点では、まだリビジョンコントロール用のプラグインがないため、エディタと連携させることはできません。
現状、UEFN のみです。

UE のエディタと連携できないというだけですので、UE のプロジェクトをフォルダごと Lore のリポジトリに放り込んで Lore でバージョン管理することは可能です。

と言っても、UE のリビジョンコントロールを使うと作業に支障が出るレベルで待ち時間が増えたりするので、私は「UE のリビジョンコントロール」は使っていません。

LoreGUI

CLI を使う方が手軽ですが、オープンソースの GUI クライアントも存在します。
ただ、CLI でのセットアップ方法が分かっていないと初期設定で躓きます。

Install にアプリのダウンロードページへのリンクがあります。

LoreGUI を使いたくなるシチュエーション
diff を確認するのは GUI の方が良いです。
CLI だとコマンドを覚える必要が出て来るので、そこに抵抗があるなら GUI の方が良いです。

UE のゲーム開発では「Perforce」（以下、P4）がよく使われます。
というより、P4 以外は UE では使い物にならないレベルで使いにくいです。

50 人を超えるような規模のゲーム開発で、ローカルのファイルを最新の状態に更新したり、ローカルの変更をサーバーに反映するときの待ち時間が全く違います。
この「待ち時間」をいかに減らすか？が開発効率に直結します。

P4 は 300 人規模でも動作がスムーズで、非常にパフォーマンスが高いですが、その代わり、細かくカスタマイズする必要があり、そこにかなりの手間がかかります。
UE でのゲーム開発は規模が大きくなりがちで、そうなると P4 の利用料が高くなるため、予算を圧迫します。

Git はローカルで編集したファイルをステージに上げることでコミットできるようになりますが、Lore もここは同じです。
Github Desktop を使っている場合、ステージに上げる操作はアプリが勝手にやってくれるので知らない人もいるんじゃないかと思います。
コマンドで言うと、Git add に相当するのが、Lore stage です。

ステージに上げたファイルをコミットすることで、ローカルのリビジョンが更新されます。
ローカルの変更をサーバーに反映するときに push します。
この仕組みと流れは、そのまんま Git です。

チーム開発なら、ブランチを作って、そのブランチで編集して、編集内容をメインブランチに反映するときにプルリクを出す…という Git のワークフローを採用することもできます。
個人作業とか、チームのルールに縛りがないなら、メインブランチで作業するのもありだと思います。

ちなみに Lore ではプルリクのことを Change Request(CR) と言います。

リビジョン内の特定の変更だけを、ブランチに反映するチェリーピックにも対応しています。
※個人のプライベートな作業でしか使っていないので、チェリーピックが必要になる状況がなく、使ったことはないです。

バイナリデータのマージは、特定の形式のものに限り、マージ専用のツールを使うことで可能です。
バイナリデータはそもそもマージできないという扱いなので、Lore の基本機能にはありません。
※何故、バイナリデータがマージできないのか？は分かりません。

以下はバイナリデータのマージ方法について Gemini に質問した時の Gemini の回答です。

専用ツール（Visual Merge / Semantic Merge）による統合
一部のファイルフォーマットや開発環境（特にゲームエンジン）では、内部構造を解釈してビジュアルにマージを行う専用ツールが用意されています。

• Unreal Engine の Blueprint Visual Merge Tool:
  UE5などでは、ブループリント（バイナリ）同士の差分をノードグラフ上でビジュアルに比較し、「どのノードや変数の変更を採用するか」を選択して統合できる機能が組み込まれています。
• 3Dモデル・画像ソフトの比較機能:
  画像や3Dアセットの場合、アルファ重ね合わせや差分表示（Diff）を行って視覚的に確認し、グラフィックソフト側で統合した新しいファイルを書き出します。

jenkins のようなものと連携する仕組みがあるのか？については調べていません。
GitLab パイプラインや GitHub アクションのようなシステムに乗っけるのは、そもそも Git じゃないので無理じゃないかと思います。
既存の Git 用のパイプラインに乗せるのは無理でも、Lore のリポジトリを監視して、リビジョンが変わってたらタスクを走らせるだけなので、Lore 用のパイプラインを作るのは不可能だとは思いません。

Perforce の Swarm のような、コードレビューの依頼を複数のエンジニアに投げて、議論できるような機能はなさそうです。
Discord を使ったり、ローカルの Web チャットや Slack などを併用する必要がありそうです。
そこら辺は、どの現場でもやってることだと思います。

今のところ気になっているのは、50 人以上の開発スタッフがひっきりなしにアセットの更新を行うようなプロジェクトでのパフォーマンスです。
数人単位なら Lore でなくても、Subversion でも何でもいいと思います。

そういった作業スタッフが多い現場での、ローカルを最新の状態に更新するときの待ち時間。
特に、実装期間の締め切りが近いときのデスマーチ状態では、頻繁かつ大量に更新されるので、そういった状況でどれくらい待ち時間が少なく、高い効率で作業できるのか？

コンフリクトが起きて、マージしなきゃならないような状況が頻繁に発生するような状況での使いやすさ。
各人がブランチを作って作業し、メインブランチに反映するときのマージにかかる手間。
マージ中にメインブランチに更新がかかって、更に別のファイルをマージしないとならなくなったり、マージ中のアセットに更新がかかってマージのし直しになるような状況での手間。

こういうダルい作業の手間をどれだけ減らせる仕組みになっているかは、かなり重要です。
こればっかりは、実際の現場でテスト運用してみないと分からないです。

そのままコミットまで進めます。
この間、sync を実行するとエラーが出ます。

自動的にマージ可能ならマージしてくれます。
自動でマージできない場合、以下の３パターンの方法でマージします。

A. 自分の変更を活かして、サーバーの変更を破棄する。
B. 自分の変更を破棄して、サーバーの変更を活かす。
C. 手動でマージして A. を行う。

サーバーの起動に必要です。
これはコマンドプロンプトでは無理です。
サーバーは更新履歴を保存する、データの保存を扱うアプリです。
サーバーを起動しなくてもローカルでの作業はできますが、push や sync など、サーバーにリクエストを投げるコマンドには失敗します。

クライアントに必要ですが、Power Shell を使っても良いです。
ローカルで編集したデータをサーバーに反映するリクエストを投げるのがクライアントです。
stage や commit はサーバーがなくてもクライアントだけでできます。

ポートが使用中かどうかはコマンドプロンプトで確認できます。
コマンドは添付画像を参照してください。
ポートが使用中の場合は、そのポートを使っているアプリを終了させる必要があります。
プロセス ID を使えば、どのアプリが使用なのか？が分かります。
プロセス ID はタスクマネージャーで確認できます。

私は Power Shell では機能過剰なので、クライアントはコマンドプロンプトを使っています。
ひとつのサーバーに対して、クライアントは複数起動する場合があります。
ありますというか、基本的にそうなります。

例えば、個人開発の場合、コードはデスクトップの WindowsPC で編集するけど、アートは MacOS のノート PC で編集する…といった使い方があると思います。
個人開発なので開発者はひとりと定義しますが、サーバー用の LinuxPC と、コード編集用の WindowsPC と、アート編集用の Mac ノート…といった環境になっている場合、それらを全て有線 LAN で接続している必要があります。
有線接続しないと、ネットワーク設定がすごくめんどくさいです。

AI に相談しても詰まったり、何日もかかったりします。
AI で情報収集して、解決方法は人間が考えるという結果になりがち…。

こういった使い方を想定している場合に、サーバー用 PC だけ外部公開（世界中の誰でもアクセスできる状態に）するのはセキュリティ上、非常に危険です。
どうしても Wifi を使ってサーバー用 PC にアクセスしたいなら、VPN を使いましょう。

外部公開するとひっきりなしに海外の色んなところからポートスキャンされます。
サーバーの外部公開がどれくらいやばいかは、以下の動画をご覧ください。

PowerShell を起動して以下のコマンドを入力します。

& "$env:USERPROFILE\bin\loreserver.exe" --config C:\loreserver\config

※先頭の & を忘れないよう注意。
※C:/loreserver/config は好きなパスに変更してください。
※管理者権限は不要なはずですが、loreserver が起動しない場合は管理者として PowerShell を起動してください。

loreserver を起動した PowerShell はそのまま触らないようにしてください。
最小化するくらいなら問題ありません。

新しい PowerShell または、コマンドプロンプトを起動して loreserver が起動しているか、アクセスできるかを確認します。

curl.exe -i http://127.0.0.1:41339/health_check

※ OK 以外が表示された場合は AI に相談してください。

新規のリポジトリを作成する手順は以下になります。
1. loreserver に新規のリポジトリを作成するリクエストを出す。
2. ローカルにリポジトリをクローン。

ひとつの loreserver で複数のリポジトリを管理できます。
そのため、既存のリポジトリに何かをするわけではなく、新しくリポジトリを作成して、その新しいリポジトリに何かをするよ…ということを loreserver に伝えます。
lore のリポジトリは、Git のリポジトリと同じ意味です。

PowerShell または、コマンドプロンプトを起動し、以下のコマンドを入力します。

lore repository create lore://127.0.0.1:41337/my-project

てきとうな場所にフォルダを新規作成します。
例として、G:\lore フォルダを新規作成。

このフォルダにリポジトリをクローンします。

PowerShell または、コマンドプロンプトを起動し、このフォルダをカレントディレクトリにします。
カレントディレクトリが C:\Users の場合、G:\lore にカレンドディレクトリを移動させるには、以下の順番にコマンドを実行します。

G:
cd lore

カレントディレクトリを移動したら、以下のコマンドを入力します。

lore repository clone lore://127.0.0.1:41337/my-project

[Warn] Cloned an empty repository without revisions – did you forget to push?
リポジトリに何もデータがない…という警告が表示されますが、空のリポジトリを作成したので問題ありません。

クローンに成功すると、新規作成したフォルダに .lore フォルダが追加されます。
※ G:\lore に my-project リポジトリをクローンすると、G:\lore\my-project フォルダが作成され、その中に .lore フォルダが追加されます。
これによって、G:\lore\my-project を lore の my-project リポジトリとして使えるようになります。
PowerShell やコマンドプロンプトを使う場合は、このフォルダにカレントディレクトリ移動してから、lore のコマンドを叩く形になります。

リポジトリに接続できるか確認します。

lore status --scan

my-project フォルダにテキストファイルとバイナリファイルを作成して、ステージに上げます。

echo "Hello, Lore" > hello.txt
fsutil file createnew sample.bin 256
lore stage hello.txt sample.bin

ここまででリポジトリの状態を確認してみます。

ローカルの変更を確定させます。まだサーバーには接続しません。

lore commit "Initial revision"

ローカルで確定させた変更をサーバーに反映します。

lore push

リポジトリの状態を確認してみます。

別の PC などで作業した内容をプッシュして、現在の PC にその内容を反映させるには、lore sync を使います。