OpenVPN 動作検証メモ
ゲーム関係ない、結構本気にただのメモ。そのうちちゃんとしたもの書く。
触った環境
VirtualBoxを使用してローカルの仮想環境上で検証
ホストPCスペック
CPU:Ryzen 7 3700X
メモリ:32GB
サーバー:Ubuntu 20.04 LTS(2コア、4GB RAM)
クライアント:Windows 10 Enterprise(1コア、4GB RAM)、VyOS 1.3(1コア、512MB RAM) x 9、
基本的にクライアントは1台だけWindowsにしておいて、あとは数を稼げるようにVyOSを複数使用。
触ってみた所感
- シングルスレッドで動作するというが、I/Oも入るし、システム的にCPUの処理を他にも使われるので、マルチコアの方がパフォーマンスは出そう。
- サーバーは接続しているクライアント数が増えてもメモリの使用量が増えていくだけで、CPUの負荷は上がらない。1000台で140MBほど。
- コネクションを張るときも、I/O側の時間の方が遥かに長いので、一度に大量のリクエストが来ても結構さばける。(1000台から一斉に来てもCPU使用率が一瞬50%になるくらい)
- データ圧縮は通信速度とCPU負荷を見ても、ほとんど違いを感じられない。微妙にデータの送信量が減って、ほんの少し通信速度が上がる気がする。
第14回UE4ぷちコン振り返り 実装編
時系列で書くの無理そう…
ということで、作った内容毎で勘弁して。
そのほうがきっと誰かの役に立つはず…
Level
ベースはFirstPersonテンプレート。
まあ、ライティング関係以外ほぼ元のもの使ってないけど。
部屋はHQ Residential Houseのアセットを使用。
www.unrealengine.com
そこからライト消したりできないアセットをひたすら削除。
窓から外を見れるように邪魔なものも削除。
使わない部屋も削除。
全体はこんな感じ。
この時点で見えてるのはゲームの説明用の足+Shinbiちゃんの顔だけど、Level上にはVisibleを切って見えないようにしてクリア後の綺麗な足+Shinbiちゃんの顔も配置済み。
それぞれFullSunegeとRemoveSunegeの名前になってる。
Shinbiちゃんどこいった。
カメラは左から
- タイトル用
- ゲーム中用
- ゲーム開始前の説明とクリア後用
最初は部屋を複製して各シーン毎に自由にできるようにしようと思ったけど、どうにもライティングがおかしくなる原因がなかなか分からなくて、一緒の部屋にまとめる。
後で床が抜けてて光がちゃんと反射してないのが原因だったのが発覚。
みんな、薄い床とか壁はやめようね。
部屋だけ複製するために元の外壁消したせいかもしれないけど。
家の内壁の法線が内側向いてて、外からの光が透過するから?なのか、外壁を新たに作っていくことに。
部屋の中でも夏の空気感が出るように、LightSourceのIntensityを少し高めの75くらいに設定。
今見るともう少し高めでも良かったかも。
脛毛を何度もスポーンさせるのは効率が悪いので、予めLevel上に配置しておき再利用できるように、部屋の裏側に脛毛を植える。
ゲームモード
Levelが遷移しないので、全て同じゲームモード内で処理する。
汚すぎて参考にならなそう。
ただ、グラフを分けたのでシーンごとに見れるようにはした。
この馬鹿みたいなコメントつけたの誰だよ。
自分か…
各シーンの遷移はほぼWidgetからのイベント任せ。
レベル上にシーケンサー配置して使おうとした跡があるけど、一切使ってない。
ゲーム説明用のキャラクターとゲームクリア時のキャラクター(足のあれ)
足の部分は板メッシュに写真のマテリアルを貼り付けただけ。
足が短い感じするけど長いほうだと自負している。
ただ足のサイズがでかい。
Shinbiちゃんは首だけのメッシュにするとか、そんな残酷なことはできないのでポーズを作った。
ただ、体がそのままだと足からはみ出すので、ひねったりなんやりしてみたけど、手足小さくしてもまとまらず、全体を小さくする手に出た。
それでも収まらなかったので、最終的に頭大きくして首をキュって曲げる方法になった。
ちょっと下から見るとこんな感じ。
横からだとこう。
これ大丈夫…?エピックの人に怒られない…?
クリア後の綺麗な感じを出すためのエフェクトはNiagara。
パーティクルのテクスチャは用意せずにマテリアルで計算して作ってる。
以前、キラキラエフェクトを作りたくなって作ったものの使いまわし。
結構無茶な計算をして作ってる。
毛抜き
グレイマンですね。
FirstPersonテンプレートを使ってしまったので、ThirdPersonテンプレートから召喚。
初期位置を見えるようにArrowを置いている。
左側の脛毛は掴む位置を見えるようにするためのダミー。
脛毛掴むアニメーションはUE4エディター上だけで作った。
結構しんどかった。
多分作るのに一番時間がかかったところ。
アニメーションBPも作って、内容は簡単だけどアニメーション制御をするようにした。
グレイマンが移動する部分はスプライン使って別で動かしたけど、アニメーションに組み込んだほうが良かったかも。
一通り作った後、風呂に入りながら、操作方法が見えないことに気がついて、各方向の矢印は急遽Blenderで作って投入。
時間もギリギリだし、アニメーションもTickで動くように作ってしまった。
BPは許されるレベルのスパゲティと思いつつ、関数作ったほうが良さそうな部分が見える。
総括
ギリギリに作るな。
第14回UE4ぷちコン振り返り 企画&準備編
非常に今更感はあるけども、なんとか年が明ける前に↑を振り返りたいと思います。
まずは企画編。
書くのもなかなか大変なので、さっくり行きましょう。
7月末
とりあえず、テーマの「なつやすみ」に関連したワードを出していく。
そのメモが以下。
なつやすみ 夏デビュー 毛抜き 脛毛を抜く
既にアレな感じが出てきている。
8月頭 企画初期
脛毛抜くとか絵面やばいから色々考えていった結果、孫がおじいちゃんの元に向かって階段を上っていき、おじいちゃんは孫が来ないように邪魔をしてくるゲームを考える。
お前が来るのはまだ早い、みたいな。
スーパーマリオUSAの仮面みたいな感じで顔だけのおじいちゃんが邪魔をしてくるのを考える。
親父の顔使おうとした。
まあ、ネットで検索すれば出てくる顔だしいいっしょ。
タイトルは「Knockin' on Heaven's Door」とか「Stairway to Heaven」を考えてた。
8月中旬
世はお盆。多くの人が先祖をお迎えする時期。
流石に悪ノリがすぎると、おじいちゃんの元に向かうのは却下。
そこで夏休みデビュー案が浮上。
親父の顔を使おうとか考えてたのもあって、絵面を気にしなくなる。
むしろ、やるとこまでやったれとすら考える。
実際に脛毛を抜く時のこと考えて、痛くないように抜いていくゲームを考える。
操作はシンプルに。
アーケードのビシバシチャンプシリーズのような感じ。
8月下旬
足だけで夏休みデビューもどうなのかなと思い、思い切ってShinbiちゃんが夏休みデビューしていくことにする。
とりあえず自分の脛毛の写真撮ったりする。
でも脛毛が細くて、なかなかリソースとして使いにくい。
てか、Shinbiちゃんよく見たら全然足出てないじゃん!
仕方ないので、自分の足にShinbiちゃんの顔くっつける。
ゲームクリアして夏休みデビューしたら水着着せて、海でキャッキャッさせるんだ。
そんなことを思っていたけど、水着着せるのが苦労するので時間があったらやることにする。
まあ、自分の足に水着がくっついてる状態になるんだけど。
下どういう風にするつもりだったんだ。
キャラクター用写真
脛全体を写真撮って切り抜いて…足だけで見ると太いな、おい。
体は太くないんだけど、足は太い家系なのを思い知る。
脛毛のモデリング
自分の脛毛が細いので、脛毛だけはBlenderでモデリングすることにした。
写真撮るために少し抜いた脛毛は無駄になった。
ごめんね、脛毛君たち。
スケルタルメッシュにして、ポーズを付けて各パターンを作ろうと考えて作り始める。
だけど、動くわけじゃないし、ポーズ付けるのいい感じにするの大変だし、そもそもBlenderでボーン分割したのそのままエクスポートしても分割されない。
ボーンを分割するの大変そうなので、全部Blenderでパターン分作ってスタティックメッシュにすることにする。
脛毛を抜いた時のSE
脛毛を抜いた時の声を最初は自分の声にしようとか考えてたけど、Shinbiちゃんの顔でそれはなくない…?
ということで、Shinbiちゃんのアクションのボイスから選定していく。
一部を切り取ったりして使えそうなのを探すためにひたすら聞く。
とりあえず目星だけはつけて、できそうな目処を付ける。
8/28
仕事から帰って寝る。
準備はしたし、明日の自分がなんとかしてくれる…
8/29~
実装編に続く
akisenri.hatenablog.com
C++のユースケース毎のLevel、BPへの変数公開のUPROPERTY設定
毎度調べるのも面倒だし、ほぼ個人的なメモ。
気が向いたら内容が増えていくかも。
初期値の設定
Level上での設定や、BPエディタ上での設定に関するUPROPERTYの設定。
EditAnywhere
EditDefaultsOnly
EditInstanceOnly
VisibleDefaultsOnly
VisibleInstanceOnly
Level上に配置後に値を調整したりしたい
Level上で表示を確認しながら調整したい場合に。
UPROPERTY(EditAnywhere)
クラスの設定値を変えないので見れるようにだけしたい
あまり見れるだけというのはLevelエディタやBPの利点を活かせてないように思うけど、C++で設定している値を見たい場合などに。
UPROPERTY(VisibleDefaultsOnly)
インスタンス毎の設定値を変えないので見れるようにだけしたい
UPROPERTY(VisibleInstanceOnly)
全部
UPROPERTY(EditAnywhere)
BP上での編集、取得
BPでGet、Setの使用可否の設定。
BlueprintReadWrite
BlueprintReadOnly
BP上で書き換えを行いたい
イベント等で書き換えたい場合に。
UPROPERTYにVisibleInstanceOnlyやVisibleDefaultsOnlyを設定していても書き換え可能。マジか。
UPROPERTY(BlueprintReadWrite)
BP上で取得のみ行いたい
The 設定値
UPROPERTY(BlueprintReadOnly)
コンストラクションスクリプトの使い所 その1 照明
コンストラクションスクリプトをどう使うか探しても、あんまり実用的な使い方が無い印象なので、適当に思いついたこと、実際に使っていることを書いていこうかと。
長いこと書いても仕方ないので、超簡単に。
プロパティに照明のスイッチのON/OFFを追加して、ポイントライトの表示/非表示を切り替えることで、照明を点けたり消したりする場合にコンストラクションスクリプトが役に立つ。
BeginPlayイベントで照明のスイッチのプロパティを見て、ポイントライトの制御をするようにしてしまうと、プロパティを変更してもエディタ上では何も変化しない。
その制御をコンストラクションスクリプトに持ってくると、プロパティを変更することでエディタ上にも反映されるようになる。
以下はチームで作ってるゲームから。
照明のスイッチON
照明のスイッチOFF
コンストラクションスクリプトはこんな感じ。
真ん中のちょっと右から、Set VisibilityでPoint Lightの表示/非表示をSwitchのプロパティから設定するようにしているので、Switchのプロパティを切り替えるとエディタ上で照明が点いたり消えたりするようになる。
照明の傘が光を透過しているように見えるように、傘のマテリアルインスタンスを作って、エミッシブライトで光ってるようにする処理も入ってるが、これもエディタ上で動く。
その1はここまで。
その2の予定は未定…
widget部品化のすゝめ
色々書こうと思ったけど百聞は一見にしかず、ということで。
UserWidgetを利用することで複数のWidgetを組み合わせたWidgetを作成することができ、同じデザインのwidgetを使い回すことができる。
何かあった時の修正も一つのwidgetの変更で済むようになる。
特にそれぞれのサイズを一定にしたい場合等に全部のUIサイズをいじるのは非効率極まりない。
ただサイズだけの問題なら、まあ解決は難しくない。
そこにボタンを配置して、それぞれの位置を調整して、ボタン全てにイベントを設定してなんて日には、ストレスで胃に穴が開く前に指示した奴の胃に穴を開けかねない。
問題
User Widgetを配置するとボタンのクリック等、個別のイベントの処理を作成できなくなる。
そうなると、デザインは同じだけどボタンをクリックした時の動作は別のものにしたくても変更ができない。
そこで、デリゲートを利用する。
デリゲートはUser Widgetを配置後に個別に関数をバインドできるため、User Widget側でイベントとデリゲートの呼び出しを繋ぐことで、後からデリゲートにバインドされた処理をイベントから呼び出されるように設定ができる。
まずはイベントグラフからイベントディスパッチャーを作成する。
次にUserWidgetを利用するWidgetから動作を変更したいイベントからイベントディスパッチャーを呼び出す。
以下はOn Clickedからイベントディスパッチャーの呼び出しを行うように設定。
ここまで出来たらあとはUserWidgetを呼び出す側で設定を行うだけ。
UserWidgetを使用している側のデザイナの詳細タブにイベントディスパッチャーのイベントが追加される。
これをクリックするとイベントディスパッチャーが呼び出された際のBPの設定が行えるので、あとは好きに動作を設定すればOK。
On Clicked → イベントディスパッチャーの呼び出し → イベントディスパッチャーに設定した動作の実行
の順に動作するので、UserWidgetを利用する側から好きに動作を変更できるようになる。
ディープラーニング失敗例
失敗例その1
予測の期待値を設定して、その結果にならないと入力の修正を行い、期待値通りの出力をするが予測はできないものを作り、役に立たないと言い出す。
お前の期待値が予測として正しいなら、てめえでやれ。
失敗例その2
予測結果が100%にならなければ信用しないと言い出す。
それを人は予知と言う。
失敗例その3
なぜその結果になったのか、理由を説明できなければ結果を採用しないと、何も分かってない上の人が言い出す。
お前、自分が何考えてるのか理由を全部説明できんの?