emotionサイトトップ >UE(ｱﾝﾘｱﾙｴﾝｼﾞﾝ)備忘録

emotionサイトトップ > UE(ｱﾝﾘｱﾙｴﾝｼﾞﾝ)備忘録 >Unity料金改定が極悪過ぎてUnrealEngine一人勝ちに？

Unity料金改定が極悪過ぎてUnrealEngine一人勝ちに？
Unityでゲームを作ったら1ダウンロードあたりに料金が発生する事になり、ゲーム開発者がUnityに見切りをつけてUnrealEngineへ移行する流れになる？

アンリアルエンジンを使い続けて来た私は高みの見物ｗ

日本の増税よりも極悪なUnity料金改定に対抗して、EpicGamesは当てつけのように
「うちは突然ぼったくるような事はしませんよ、もし仮に価格改定したとしてもユーザー自身で料金選択出来ますよ」とツイート（ポスト）。

基本的に #UnrealEngine は無料で利用可能です。ロイヤリティが発生するのは、エンジンコードを組み込んだ市販向け製品（ゲームなど）の売上が100万米ドルを超えたときです

仮に本契約が変更された場合、ユーザはその変更に同意するか否かを選択できます。詳細はこちら (1/2)https://t.co/2eVlJ35n5e pic.twitter.com/73vZBI7Kht

— アンリアルエンジン (@UnrealEngineJP) September 15, 2023

emotionサイトトップ >UE(ｱﾝﾘｱﾙｴﾝｼﾞﾝ)備忘録

emotionサイトトップ > UE(ｱﾝﾘｱﾙｴﾝｼﾞﾝ)備忘録 >やっぱり自前実装は不可欠

ある程度本格的な詳細部分の機能を追加しようとすると、テンプレートやプラグインだけでは流石に無理があって、最初から用意されているのはある程度それっぽく動く基本部分だけなので、細かい部分は自前で実装し直さなければならない。
決まったジャンル専用のゲームエンジンじゃないので当然と言えば当然ですが、本格的な機能を実装するにはベース部分のソースコードを解析して、どこを拡張しなければならないかを調査するのに時間がかかりそう。

逆に元々ある機能を丸ごとオーバーライドして、インターフェース部分だけを流用して、部分的に新規で使った方がマザー２のように早く仕上がる可能性もあるけど、コンソールデバッグとの関連も考えるとやっぱり拡張した方が良いのかも？
いや、ある程度ガチで開発するなら、自前で作った方が後半の作業効率が指数関数的に上がるから悩みどころ。

どちらにしてもとりあえずベースのソースコード解析して、解析結果の資料作成しないと。
年末までにドキュメントは全て準備完了させるつもりでしたけど、遅延が発生しそう・・・
睡眠時間を削るか？いや、年齢的に若くないから睡眠時間を削るとまた入院する事になるから、徹夜は寝れない時だけにしよう。

---

何故かバネレートを動的に変えられない仕様で、まだ正式リリース版じゃないからかな？
と思っていたけど、ソースコードをみたらそもそも動的に変えられるような作りになっていなかったOrz
これを動的に変えられるようにするにはベースのソースコードにかなり手を加えないと・・・
継承させて部分的に追加しようにも、privateの部分が多いからまずここから変更しないと。

それからソースコードを眺めていたら、ダンパーの縮み側の設定も作成途中なのも判明。
正式版がリリースされてからの方が余計な工数をかけなくて済むかも？
でもいつ正式版がリリースされるか不明だから悠長に待っているわけにもいかないからベースコード改造しようか？

---

ソースコードをよく眺めてみたら、サスペンション設定でまとめて動的に変更できる関数が用意されていました。
めちゃくちゃ分かり難いし、初期値で全部0が設定されているので、全ての設定値を設定しなければならないという面倒臭さｗ
でもそういう関数が用意されているだけでも助かります。
しかも、散々ソースコードを弄くり回した後にその関数の存在に気がついたというｗ

emotionサイトトップ >UE(ｱﾝﾘｱﾙｴﾝｼﾞﾝ)備忘録

emotionサイトトップ > UE(ｱﾝﾘｱﾙｴﾝｼﾞﾝ)備忘録 >C++ソースコードを変更した時に発生する謎エラー[E0077 this declaration has no storage class or type specifier]

アンリアルエンジンのC++ソースコードを変更した時に発生する謎エラー[E0077 this declaration has no storage class or type specifier]。


なんかUCLASSの上行を変更すると、GENERATED_XXXX（）マクロの所でエラーが発生するみたいです。

こんなもん分かるか！
ヘッダーファイルにメソッドを追加して、そこから自動生成してcppファイルにソースコードが追加された時にエラーが出て、追加したコードを削除してもエラーが消えなくてビルドが通らなくて「やっちまった！」感でキレそうになりましたけど。
アンドゥで前戻ししたらビルドが通ったので、手動でソースコードを消した時とアンドゥで前戻ししたソースコードの差分検証したら、この空白行でした。

あとは
#include "XXX.generated.h"
の下にインクルードを追加すると発生するみたい。

いや、このマクロの扱い難さを修正するべきなのでは？

emotionサイトトップ >UE(ｱﾝﾘｱﾙｴﾝｼﾞﾝ)備忘録

emotionサイトトップ > UE(ｱﾝﾘｱﾙｴﾝｼﾞﾝ)備忘録 >リプレイシステムがクッソ面倒

想像はしていたけどリプレイシステムがクッソ面倒。
レコーディングシステムというのが一応用意されていて、各アクターの情報を記録して、リプレイモードを作ってその記録されたデータを使って再現するというもの。
データ記録にはDemoNetDriverやシーケンサーレコーダーを使用する。

昔グランツーリスモ1をBleem!というエミュレーターでプレイして、リプレイをすると動作がバグる事がありました。
単純にユーザー入力情報を記録して、リプレイモードではその入力情報を使って再現させていたのですが、PC上で動作させる事でフレームレートが異なっていたりでタイミングがズレてまともにリプレイが再現出来ないという現象が発生していました。
それを見てリプレイというシステムの仕組みをなんとなく理解はしていましたけど、これが結構大変。

市販のゲームでリプレイを早戻しした場合に、逆再生中にエフェクトが発生したなったり、順再生中に発生したエフェクトが残ったままになる事を確認出来ますが、リプレイシステムの仕組み上色々と難しいのでそういう所は妥協するしか無いんでしょうね。

それから膨大なデータを記録しているので、メモリにも気を使う必要があります。
だからレースゲームでもリプレイ記録が出来る上限が10分とか制限されているんですよね。

マジで最適なリプレイシステムを考えるのにもう3日ぐらい考えていて全然進んでいませんｗ
ゲーム制作ってマジで難しいですよね。

---

DemoNetDriverを使用したら簡単に実装出来ましたｗ
ただ、公式リファレンスが分かり難くて初見刹し過ぎます。
一度実装して動作するレベルまで持っていけてから、リファレンスの内容がちょっと分かるようになります。

ただ 疑似ローカルサーバーみたいな感じでリプレイしているので、基本的にマルチプレイゲームを作成するような調整が必要。
動的にスポーンするアクターはレプリケートしなければならないし、Owner No Seeはレプリケートされないのでリプレイ中に切り替えるにはどうすればいいのやら・・・とにかく資料が無さ過ぎて手探りで調べる事が多い。

---

結論。
自前で入力情報を記録して、リプレイ時に記録した入力情報で再現させる方が痒いところに手が届く。
面倒だけど現状ではそうするしか無い・・・というかDemoNetDriverの情報もドキュメントのあまりにも無さ過ぎて、「あれをしたい」と思った時に何も出来なくてお手上げになります。
自前で作成したシステムなら、やりたい事を実現する際に確実に作成出来ますからね。

emotionサイトトップ >UE(ｱﾝﾘｱﾙｴﾝｼﾞﾝ)備忘録

emotionサイトトップ > UE(ｱﾝﾘｱﾙｴﾝｼﾞﾝ)備忘録 >UE5のChaosVehicleにクラッチが無い

UE5のChaosVehicleMovementにクラッチが無い。
UE4のVehicleMovementにはあったのに・・・UE4のソースコードから移植するか。
ChaosVehicleは未だ実験段階のプラグインなので、正式リリースされたらもしかしたらクラッチシステムが導入されるかもしれないけど、最近実車でも3ペダルは無いしNFSなんてマニュアルすら無いから導入されるのは期待薄ですけど。