PM見習いのよしなしごと

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

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 さん)

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

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

Victory Pluginのご紹介

この記事はUnrealEngine 4 (UE4) 其の弐 Advent Calendar 2015の18日目の記事です。

qiita.com

気づいたら開発者っていうよりも、UE4関連の情報を共有・拡散する人になりつつあるUsuiと申します。

昨日は@tarotarokunさんの、「C++を使ったSocketを使った通信周りの書き方」という記事でした。ゲーム同士の通信だけではなく、昨今注目されているIoTデバイスにも応用が利くということで、そちら方面にも興味がある身としては、非常に為になる内容でした。ありがとうございます!

 

さて、今回はVictoryPluginの概要と導入手順、また用意されているブループリントノードを何点か紹介したいと思います。

プラグインを導入した上でのパッケージング等については触れておりませんので、その点ご了承ください。

また、間違いがありましたら、やんわり指摘いただけると助かります(苦笑)

 

VictoryPluginとは?

forums.unrealengine.com

C++コードからしか使用できない機能をブループリントで使えるようにしよう!」という意図の元で、現在も機能の追加が行われているプラグインです。

中身は凡そ200~300個のブループリントのノード群で構成されており、数学計算補助、各種ファイルの読み書き、物理、アニメーション、ネットワークなど、その種類も多岐に渡っています。

 

開発をメインで行っているのは、Rama Iyerさん。

VictoryPlugin以外にも、様々な知見をForumsやEpic Wiki、ご自身のサイトへ投稿されていらっしゃいます。最近Twitterも始められたようです。

RamaさんのTwitter:@ue4code

ご自身が更新したForumsの告知等を行っていらっしゃいますので、興味がわいた方はフォローしてみてはいかがでしょうか?

 

VictoryPluginの導入

  1. Rama's Vertex Snap Editor Plugin - Epic Wikiにアクセスします。

  2. Plugin Release Dates and UE4 Engine Versionsと記載された下に、UE4のエンジンバージョンに対応したVictory Pluginのバージョン(リリース日付)が記載されています。今回はUE4.9.2に対応している「October 14th, 2015」をダウンロードします。

  3. File:VictoryPlugin.zip - Epic Wikiにアクセスし、先ほど確認した日付のzipファイルをダウンロードします。Date/Time欄のリンクをクリックすれば、ダウンロードが始まります。

  4. zip形式のファイルとなっているので、それを解凍します。
  5. 導入したいUE4のプロジェクトフォルダの下(Config, Content等と同じ場所)に、「Plugins」フォルダがあるかを確認します。無ければ作成します。
  6. Pluginsフォルダの下に、先ほど解凍したフォルダをコピーします。
  7. UE4エディタを起動します。
  8. メニューから編集->Pluginsを選択します。
  9. 以下の画像のようにProject下に、Victory Pluginという項目が出来ていること、その中のVictory Editor & Blueprint Libraryの、Enabledのチェックが入っているかを確認し、入っていなければチェックを入れます。            f:id:usui3153m:20151213071911p:plain

  10. ブループリントのEventGraph(レベルブループリントでも、アクターに紐づくブループリントでも、どれでも構いません。)で右クリックをし、ブループリント上で使用可能なノードの一覧を表示させ、「Victory BP Library」という項目が追加されていることを確認します。  f:id:usui3153m:20151217003450p:plain

以上で導入は終了です。

 

ブループリントノードの紹介

膨大なブループリントノードの中から何個か紹介したいと思います。

あえてばらばらのジャンルから抜き出して記載していますので、見づらいかもしれませんが、その点ご了承ください。

キー入力周りに関しては、黒幕さんがまとめてくださっていますので、そちらを参考のほど。

qiita.com

 

JoyFileIO_GetFiles

f:id:usui3153m:20151215174106p:plain

引数

 Root Folder Full Path:ファイルを検索するフォルダパス(絶対パスを指定)

 Ext:ファイルの検索条件。指定が無い場合は全てのファイルを取得する。

        *.*のように指定。

戻値

 Files:取得したファイル名。

 Return Value:true=取得に成功。

フォルダまでの絶対パスと検索するキーワードを指定して、一致したファイル全ての名前を取得します。

ファイル読み込み関連では、サブフォルダまで検索を行うものや、全てのセーブデータファイル名を取得する。といったノードが用意されています。

GetAllWidgetsOfClass

f:id:usui3153m:20151215174104p:plain

引数

 Widget Class:取得したいWidgetClass

 Top Level Only:true = ビューポート上に設定されているものの中から取得する。

戻値

 Found Widgets:見つかったウィジェットオブジェクト

プロジェクト上に設定されている指定したWidget Classのオブジェクトを全て取得します。

UMG関連では、ビューポート上に存在する指定WidgetClassを全て削除するものや、指定WidgetClassが存在しているかどうかを調べるといったノードが用意されています。

RealWorldTime__GetDifferenceBetweenTimes

f:id:usui3153m:20151215174059p:plain

引数

 Previous Time 1:差分をとりたい時間1

 Previous Time 2:差分をとりたい時間2

 ※フォーマットはFDataTime.ToString()に則ったもの。

戻値

 Milliseconds:ミリ秒

 Seconds:秒

 Minutes:分

 Hours:時間

時間を指定して、それらの差分を取得します。

時間処理関連では、現在時刻(OSに設定されている時間)を取得するものや、現在時間と比較したい時間を設定し、その差分を取得するようなノードも用意されています。

Physics__EnterRagDoll

f:id:usui3153m:20151215174107p:plain

引数

 The Character:ラグドール状態にしたいキャラクターオブジェクト

戻値

 Return Value:true=ラグドール状態にすることに成功した。

指定したキャラクターをラグドール状態にします。

ラグドール関連では、指定キャラクターがラグドール状態か判定するものや、ラグドール状態になった場所の座標を取得するもの、ラグドール状態から復帰させるといったノードも用意されています。

Conversion__FloatToRoundedInteger

f:id:usui3153m:20151215174103p:plain

引数

 IN Float :変換したいfloat値

戻値

 Return Value:変換されたint値

float値の小数第一位を四捨五入して、int値を返します。

数学処理関連では、+=, -=の演算子を使用可能とするもの、int, float配列をソートするもの、最大値、最小値を取得するものなど、数多くノードが用意されています。

また、TKMathFunctionLibraryという、数学処理メインのBlueprintFunctionLibraryもVictoryPluginの中に付属しています。

HasSubstring

f:id:usui3153m:20151215174105p:plain

引数

 Search In :検索対象となる文字列

 Substring:検索したい文字列

 Search Case :大文字、小文字で分けて判定するか否か。

 Search Dir:文字列の先頭から検索するか、末尾から検索するか。

戻値

 Return Value:true=文字列が見つかった。

検索対象となる文字列の中に、指定した文字列があるかどうかを調べます。

文字列処理関連では、文字列を結合するもの、各文字列に接頭語をつけて結合するといったノードがあります。

 VictorySoundVolumeChange

f:id:usui3153m:20151215174102p:plain

引数

 SoundClassObject:音量を調整したいサウンドクラスオブジェクト

 NewVolume:設定したい音量

戻値

 ReturnValue:true=音量設定成功

指定したサウンドクラスオブジェクトの音量を変更します。

サウンド関連では、サウンドクラスオブジェクトから現在の音量を取得するノードもあります。

 VictoryGetCustomConfigVar_Bool

f:id:usui3153m:20151217003509p:plain

引数

 SectionName:指定変数が設定されているセクション名

 VariableName:取得したい変数名

戻値

 Return Value:VariableNameに設定されていた値

プロジェクトフォルダ/Saved/Config/WIndows/Game.iniファイルから指定のデータを取得します。

同様のものが以下の変数の型分用意されています。

 

 変数の型:int32,float,FVector,FRotator,FLinearColor,FString

 VictorySetCustomConfigVar_Bool
f:id:usui3153m:20151217004132p:plain

引数

 SectionName:指定変数を保存したいセクション名

 VariableName:保存したい値の変数名

 Value:VariableNameとして保存したい値

プロジェクトフォルダ/Saved/Config/WIndows/Game.iniファイルに指定のデータを設定します。

同様のものが以下の変数の型分用意されています。

 変数の型:int32,float,FVector,FRotator,FLinearColor,FString

 

まとめ

VictoryPluginの導入から機能の紹介までというテーマで今回ざっくりと書かせていただきましたが、いかがでしたでしょうか?

他にどんな機能があるのか気になる!という方は、冒頭で紹介したスレッドで1つ1つ機能が解説されていますので、そちらを見てみることをオススメします。

ソースコードを読むことに抵抗が無いのであれば、プラグインをダウンロードして、ソースを読んだほうが早いかもしれません。

普段ブループリントのみで開発をされている方々にとっても、またプラグイン開発、ブループリント関数ライブラリの開発に興味がある方にとっても、非常に有用なプラグインだと思いますので、興味がわいた方は、ぜひダウンロードして使ってみてください!

 

告知

ただ、正直英語ばっかり(APIリファレンスも英語しかないし)の中で、Google翻訳に頼ったり、辞書引いたりして調べるのは面倒だと、仰る貴方に朗報です。

VictoryPluginの各ブループリントノードの機能を日本語でまとめた上で公開します!

現在、絶賛中身の解析・コメントの翻訳等々を行っているところです。

…この記事を公開する時点では、7割くらい調べられていたらいいなーと考えています。(笑)

Googleスプレッドシートで公開するのか、エクセルファイルを配布するのか、ホームページやwikiページを作成するのか、そのあたりはまだ決めていませんので、欲しいという方がいらっしゃいましたら、ご意見いただけると助かります。

また、既に利用されている方がいらっしゃいましたら、このブループリントはこんな機能だったよ。とか教えていただけると幸いです。

 

 明日のUE4 Advent Calendar

 明日は@s_ssk13さんこと、我らが佐々木さんです!

「何かやります!」とのことですが、一体どんな内容になるのでしょうか…?

非常に楽しみです。佐々木さん、よろしくお願いします!

 

最後まで目を通してくださり、ありがとうございました!