PM見習いのよしなしごと

エンジニアもどきのよしなしごと改め。仕事とか関連の備忘録

Unreal Game Sync.sln を開くにあたってしたこと

1,Unreal Game Sync クイックスタートを読む docs.unrealengine.com

2, UGS リファレンスを読む docs.unrealengine.com

3、WiX について調べる。 ウェブサイトではない。 Windows Installer XML とは、XML ソース・コードから Windowsインストーラ・パッケージをビルドするツールセットです。

wix-tutorial-ja.github.io

4,WiX をインストールする

github.com

5,VS2019 を使って、UnrealGameSynx.sln を開いてみる。

6,ASP.NET などが足りないと言われたので、VisualStudio Installer 経由でインストールする。 (エラーメッセージが出た際に、インストールするかどうかを聞かれる。インストールすることを選択すれば、Visual Studio Installer が自動で立ち上がって、パッケージを選択した状態まで進めてくれる。)

7,VS2019再起動。 無事に開けた!!!

8,番外 Unreal Game Sync を実行してみる。 スタートアッププロジェクトに指定の上、F5 で開始しただけ。

f:id:usui3153m:20190908152313p:plain
UGS

起動した!!!

Helix Core の Undo Changes ってなんぞや

Undo Changes ってなんぞや

Helix Core 2019 のバージョンで、新たに追加された機能……かと思いきや、それ以前のバージョンで言われていた Backout や、Rollback をまとめたもののことのようです。

Backout : 指定のrevision(Changelist)の変更をその前の状態に戻すこと。

Rollback : 指定のファイルやフォルダの変更を特定revision以前に戻すこと。

今回 の Undo Changes は、上記2種を1つの呼び方にまとめたっていう形になります。 やれることは Backout と Rollback と同じ。

Changelist 単位での Undo

Changelist を右クリックして、Undo Changes を選択した場合は以下のようなウインドウが表示されます。

f:id:usui3153m:20190616154829p:plain
undo changes

Preview で変更をChangelistに保持する前に確認することができるようになっています。 直接 Submit することもできるようになっています。 located in : ということで、該当チェンジリストのファイルが含まれる最上位パスが指定されています。 ※パスの編集は可能なので、同一チェンジリスト内の特定のフォルダ以下のみ変更を取り消す。ということが可能かも。

フォルダ単位での Undo

特定フォルダを右クリックしてUndo Changes を選択した場合は、以下のようなウインドウが表示されます。

f:id:usui3153m:20190616155507p:plain
undo changes3

フォルダパスの再指定が可能になっています。 変更をどのリビジョンまで戻すのか、という指定方法が3種類用意されています。

ファイル単位での Undo

特定ファイルを右クリックしてUndo Changes を選択した場合は、以下のようなウインドウが表示されます。

f:id:usui3153m:20190616155116p:plain
undo changes2

ファイルパスの再指定が不可能になっています。 変更をどのリビジョンまで戻すのか、という指定方法が3種類用意されています。 また、複数ファイルを指定した状態で右クリックしたときには Undo Changes という項目自体が表示されませんでした。

どのリビジョンまで戻すのかという指定方法について

・Undo a single change while keeping subsequent changes(指定した revision or changelist まで戻す。)

・Undo a range of changes while keepeing subsequent changes(指定した 範囲の revision or changelist まで戻す。)

・Undo all changes from a selected point to the most recent version (すべての変更を指定した箇所の最新版まで戻す。)

……らしいんですが、一番上と一番下の違いが正直わかりづらいですね。 一番上に関しては、あいだの変更を保持したまま、指定のrevisionのみ無かったことにする、という解釈かと思っていたんですが、実際はファイル単位でのRollback でしたし。

今回は時間が足りなかったので、メモとして残しておきつつ、また次のときに調べたいと思います。 すでに利用されていてわかっていらっしゃる方は教えてください。

追記1

Undo a single change while keeping subsequent changes(指定した revision or changelist まで戻す。)

Twitter で諸々確認していたので、それをそのまま転記します

こちらのツイートに連なる形で書いています。

指定したリビジョン以降の変更を保持できるのは、保持できるらしく、以下の手順を行う必要があるとのこと。 [Undo a single change ...]

リビジョンを指定 [Save to Changelist] △マークが付いたファイルに対して[Get Latest Revision] ?マークが付いたファイルに対して[Resolve] [Run Marge Tool]を実行して衝突解決 *1 (p4misc さんありがとうございます…!)

Get Latest の手順を踏む必要があるのが正直だるい…。

追記2

Undo a range of changes while keepeing subsequent changes(指定した 範囲の revision or changelist まで戻す。) こちらは Single の 範囲指定したrevision での変更内容を消すよっていうもの。 衝突解決についてもSingle と同様

追記3

Undo all changes from a selected point to the most recent version (すべての変更を指定した箇所の最新版まで戻す。) こちらは、指定したrevision 以前の状態にファイルの内容を戻すやつということで、今までのRollback と変わらないものでした。 特に操作に詰まることもなかったです。反面、するっとRollback できてしまうので、やっぱり注意は必要かと。

Helix Core の Branch Mapping について

Branch Mapping ってなんぞや

P4V 上で、特定ファイルを右クリックして、Merge/Integrate っていう項目を選択すると、下記画像のようなウインドウが出てきます。 f:id:usui3153m:20190512154954p:plain

その Merge Method として表示されるものの一つです。*1 ブランチ A と ブランチ Bをマッピングする という意味で、実際の用途もその形で利用されます。

Branch Mapping を作る

新規作成できるようなので、作成してみます。 f:id:usui3153m:20190512161028p:plain

View 部分のフォーマットは、下記のような形で設定可能です。*2

指定ストリーム単位でマッピングする

//Depot/TargetStream/... //Depot/SourceStream/...

指定フォルダ単位でマッピングする

//Depot/TargetStream/TargetFolders/... //Depot/SourceStream/SourceFolders/...

指定ファイルでマッピングする

//Depot/TargetStream/TargetFolders/TargetFile //Depot/SourceStream/SourceFolders/SourceFile

Branch Mapping を選択してみた

Mainline_Development という Branch Mapping を作成したので、それを選択してみました。 f:id:usui3153m:20190512162052p:plain

Target ってなに

変更差分を反映したいマージ先のこと。

Source ってなに

変更作業を行っているストリーム、フォルダ、ファイルのこと。

Branch Mapping を使う利点

  • マージダウン・コピーアップのルールを無視できる
    • 基本ルールとして、Release ストリームに対しては、マージすることができないというものがあるのですが、Release ストリーム作成時に、MainlineやDevelopmentストリームから漏れてしまった変更を、このやり方ならマージすることができます。*3
  • 一度Branch Mapping を作ってしまえば、サーバーを共有している他のユーザーもすぐ使用できる。
    • View -> Branch Mapping と選択すると、現在作成されている Branch Mapping を検索できます。検索のデフォルト値が、 自分が作成したもののみ。となっているので注意。

このあと

Preview ボタンを押したらマージするときのファイル一覧がでてきたり、Merge ボタンをおしたら自分のローカル環境でマージされたり するんですが、そのへんの設定は 他の Merge Method の説明や、 Advanced Option の説明などを適宜行う際に改めて。

*1:残り2つはStream to stream, Specify source and target files ですが、それは別の機会に

*2:... は*みたいなもので、ストリーム下、フォルダ下のすべてのファイル。という意味です。

*3:基本的にはルール守った上で、Mainlineモデルに則った運用をするのが吉だとは思います

Perforce の Stream について

Perforce あらため Helix Core

Perforce は会社名であってソフトウェア名じゃなくなりました。(っていうのを毎回忘れそうになる) ので以降は頑張ってHelix Core で通していきたいと思います。

Stream ってなんぞや

公式のページ

https://www.perforce.com/manuals/v17.3/p4v/#P4V/streams.about.html?Highlight=streams

Mainline モデルと呼ばれる、開発フローを実現しやすくするために考えられたデータコンテナ。ファイルとかを保存するための場所。

Stream の種類をざっくり出してみる

f:id:usui3153m:20190512151725p:plain

Mainline ストリーム

  • 開発のためにファイルの更新反映を行っていくストリーム。
  • ここから派生したストリームに対してのマージは以下の通り
    • Release ストリーム:コピーアップ不可。Release ストリームが作られる際にブランチわけされたファイルを送ることはできるが、以降Mainline ストリー無の変更をReleaseストリームに反映することはできない。*1
    • Development ストリーム:マージダウン可。Development ストリームに対し、Mainline ストリームの変更をマージすることができる。

Development ストリーム

  • Mainline ストリームとは外れた、開発・研究を行うためのストリーム。
  • Mainline ストリームに反映はしたくないけど、Mainline ストリームと同様の環境でR&Dなどを行いたい。Mainline に反映できるかわからないけど、この仕様を実装してみてほしい。など、の理由で作られる(ものと思われる)
  • ここから派生したストリームに対してのマージは以下の通り。
    • Release ストリーム:マージダウン可能。コピーアップ不可。Release ストリームが作られる際にブランチわけされたファイルを送ることはできるが、以降Mainline ストリー無の変更をReleaseストリームに反映することはできない。*2
    • Mainline ストリーム:コピーアップ可。Mainlineの変更をマージしたあと、Development ストリームの内容をコピーアップすることができる。

Release ストリーム

  • Mainline で開発が終了、Fix してリリースされるバージョンが格納されるストリーム。
  • バージョンアップのたびに、Release ストリームが Mainline に紐付いて作られていくのが一般的(と思われる)
  • ここから派生したストリームに対してのマージは以下の通り。
  • Mainline , Development:マージダウン可。Release ストリーム上での修正点は、親ストリームに対してマージダウン可能。*3

Virtual ストリーム

  • 実体の存在しないストリーム。
  • 親のストリームに対して、修正が即時反映されるが、別ストリームとして作業することはできる。
  • ストリーム設定を親のストリームとは変えたものにしたい場合などに利用される。
  • 一例) 以下のニーズを満たすために、Virtualストリームを作成し、Binariesフォルダ下をサーバーから取得してこないように設定する。などの使い方がある。
    • エンジニアに対しては、UE4のエンジンフォルダ下のBinariesデータは不要である*4
    • エンジニア以外はUE4を起動するためにBinariesデータは必要。
    • 編集するプロジェクトは職種問わず同一で、即時変更が反映されるほうがいい。

Task ストリーム

  • 必要最小限のデータのみ親ストリームから取得して、作業を行うことのできるストリーム。
  • PCの容量やHelix Core サーバーの容量を圧迫しないなどのメリットがある。*5

*1:Release ストリーム作成時の設定次第では、コピーアップを許可できるらしい。

*2:1と同じ

*3:Development ストリームを親として、Release ストリームが作成可能だったため、合わせて記載している。

*4:自分たちでソースコードをビルドして、その都度生成するから

*5:ものの筆者はまだちゃんと利用したことが無いのでテストを行いたいところ。

Perforce の shelve について

Shelve ってなんぞや

直訳すると棚上げ。 changelist に入っているファイルの変更を一旦別の場所においておく機能。

shelve というコマンドを実行すると、指定したファイルの変更はp4のワークスペースではないどこかに退避され、変更前の状態に戻る。

オプションで、変更前の状態に戻した時に、revertするかどうかも選べる。(checkoutやらなにやらをしていない状態にする)

shelve することで退避したファイルについては、unshelve を使うことで、自分のワークスペースに戻すことができる。

shelve の機能を使って、他の人が退避させたファイル一覧を見たり、取得したりすることもできる。 *1

git で言うところの stash / stash pop みたいなものという認識。

*1:Helix Swarm はこの辺の機能を使ってソースレビューを実現させている。はず。

PerforceのChangelist について

Changelist ってなんぞや

checkout(edit), add, delete などなど、Depot に登録されているデータを編集、Depot にファイルを追加、Depot のデータを削除しようとしたときに、その履歴が格納される場所。Submitされる単位。Submitする際や、Default Changelist をマージなども、このChangelist単位で行うことができる。

Git とかをざっくり検索してみた感じだと、ローカルリポジトリがそれに近いものみたい。

ローカルのリポジトリにデータをCommitして、作業上きりが良ければ push する。みたいな感じに使うところが大きいけど、同じファイルに対しては、変更をしてcommit, 変更をしてcommit。みたいな形で都度、変更をコメントつきでためておくことはできない。

*1

Changelist の作り方

p4v 上で add, checkout, delete をしようとすると、ダイアログウインドウが表示されて、3つの選択肢を提示される。

  • default に追加
  • 新しくChangelist を作る。
  • すでに作られているChangelist に追加

default changelist

changelist を指定せずにファイル類を編集などすると、格納されるchangelist

複数タスクを並行して行っていない場合は、default changelist にファイルを追加する形で作業を行い、Submit する際にコメントをつけるという形でも問題ないと思う。

もし複数タスクを並行して行っている場合は、タスク単位でChangelistを分けたほうが無難。でもこのへんは各開発グループごとの運用ルール次第で良いと思う。

新しくChangelist を作る。

default changelist の項目にも触れているけれど、複数タスクを並行して作業しているときなどには、changelist を分けていたほうがいいと思う。

わかりやすいし、default changelist からデータをSubmitする時に、一部ファイルだけチェックを入れてSubmitを行うよりは、作業開始前に分けておいたほうがいい。

新しくChangelistを作る場合は、コメントが必須になる。後で編集もできるので、一時的に適当なコメントをいれてもいい。コメントにもルールが決められているなら、そちらに従ったほうが良い。

Changelistが作成されたら、その時点での revision 番号がChangelistに付与される。このChangelistをSubmitする場合、他の作業者がSubmitをしていて、revision 番号が進んでしまっていた場合は、submit時点でのrevision番号に振り直される。

コメントを記載して、追加するファイルにチェックが入っていることを確認して、決定を押せば、p4v の Pendingというリストには default changelist と、コメントが記載されていて新しく作ったchangelistが表示されているはず。

すでに作られているChangelist に追加

default とは別に選択できるChangelist がある場合で、既存のChangelist にファイルを追加したい場合はこれを選択する。

Pending というリスト上で右クリックすれば、新規でのChangelistの作成、既存のChangelistの編集、Submitなどもできる。

Changelist の編集

  • コメントの変更ができる。
  • Changelistに追加しているファイルの移動ができる。*2
  • Pending リスト内でドラッグアンドドロップして移動させることもできるし、Changelist内でチェックを外して一旦default changelist に移動させてから、別のリストに振り直すこともできる。

Changelist のSubmit

  • Pending リストから、該当のChangelistを右クリックして、Submitを選択する。
  • 一度Changelistを開いてからSubmitボタンを押す。

*1:ローカルリポジトリは、P4 でPersonal Server のほうがそれっぽいというかむしろそれだよなぁとは思いつつ、Personal Server はあんまり使ったことはないので使ってみたいところがある。

*2:Submitのときにしかできないかもといううろ覚え状態ですみません。

P4VでUE4のバージョンアップ管理

こちらは 東ゲ部 Advent Calendar 2018 10日目の記事です。 adventar.org

あんまり入ってる人がいないので、今からでも書いてやんよっていう人がいたら、書いてくださると嬉しいです。

P4Vを使って、UE4のバージョンアップ管理を行う際に、なるだけ機械的に行うため手順をまとめたので、こちらに記載しようと思います。

前提としての説明

ストリームの種類

f:id:usui3153m:20181209153726j:plain
ストリームの種類

Usuiのほうで利用しているエンジンのストリーム構成

f:id:usui3153m:20181209132314j:plain
ストリーム構成

本題

エンジンのバージョンアップ手順

f:id:usui3153m:20181209134855j:plain
エンジンのバージョンアップ手順

おまけ(現在のゲームプロジェクトでの、ストリーム構成)

f:id:usui3153m:20181209155846j:plain
ゲームプロジェクトでのストリーム構成

考えられる懸念点不明点問題点

・サーバー側で追跡されなくなったファイル群は、ローカルのワークスペースには 追跡されなくなっただけで残っている 状態になるので、動作不具合を残してしまう場合がある。

(都度Clean するとか、ローカルのワークスペース全部削除して、Get Latest し直すとかすれば良いんですけど、いくらデータ取得が早い・エンジンのバージョンアップ頻度が少ないとはいえ、その度それを開発者側にお願いするのはどうかなーと思っていたりします。)

・エンジニアが取得したくないファイルを、個別にその都度指定しないといけないため、手作業によるミスが起きそう。

(実際取得してこないといけないファイルも消してしまい、エンジニアがビルドできずに作業が止まるという問題を引き起こしてしまったことがあるので、どうにかしたい。正規表現での指定ができるようになりませんかね Perforce さん)

・エンジンの指定バージョン間の差分を、手動で取る必要があり、その都度データまるごとダウンロード・自社のPerforceサーバーに格納。というのが手間。 (エンジンの指定バージョンの差分だけ取得して自社向けのデータに反映したいんですけど、そういうことってできるんですかね Epic さん)

と、いうところでした。 東ゲ部のアドカレもう一日くらい書こうかな…。 東ゲ部と私っていう感じで。

次の日にどなたかが入ってくれるといいなーと思っているので、気が向きましたらぜひよろしくおねがいします。