emotionサイトトップ >Unity

emotionサイトトップ > Unity >某インディーゲームをSwitchに移植する為にオブジェクトを減らしたら炎上

PC版で売れた某インディーゲーム、Switch版へ移植する際にフレームレートを優先する為に配置しているオブジェクトを減らしたら炎上。
発端はSwitch版のストアにXbox Series X版の画像を掲載して、実際はオブジェクトの数が大幅に減らされていた事だったのですが・・・

まともに移植出来ない無能

これ酷くないですか？
1人で開発したインディーゲームですよ？
もしかして移植作業は任天堂の社員がやっていると思っているのかな？
任天堂は「Switchでリリースしたいなら開発者登録して開発機を購入して下さい。あとはマニュアル読んで上手くやっといてね～」
ですよ？
任天堂はサードパーティの移植には当然関与しませんよ？

技術力が足りないだけだろ。
普通に技術力なさ過ぎ。

酷い・・・企業が作ったゲームなら分かりますけど、
何度も言いますけど開発者1人の個人開発ゲームですよ？

技術的問題でPSには出せないソフトだっけｗ

酷い言われよう・・・企業が作ったゲームなら分かりますけど、
何度も言いますけど開発者1人の個人開発ゲームですよ？
PS4への移植はPS4の開発機を購入する必要がある上に、ソニーの呪縛があって色々大変なんですよ？
PS4への移植は実際行われていてリリース予定はされています。
企業で開発メンバーが大勢いるなら同時リリースは出来るでしょうけど、開発者1人ではどうしてもリソース不足で複数のコンソールへ同時移植は難しいんですよ。
まぁ複数のプラットフォームで同時リリースしてしまうツワモノの個人開発者もいますけど・・・

WRC10と比べてもローポリなんだからもっと上手く最適化して欲しい・・・という消費者の気持ちは理解できますけど、それで無能扱いをするのは酷いよね。
処理の重さは単純にポリゴン数やテクスチャだけが原因じゃないんですよ？
まぁでもだいたい知らない人が大言壮語しますからいくら説明しても理解されないでしょうけど・・・

引用：https://krsw.5ch.net/test/read.cgi/ghard/1628898084/l50

emotionサイトトップ >Unity

emotionサイトトップ > Unity >【Unite 2017 Tokyo】スマホゲーム開発者なら知っておくべきチートのリスク＆対策

色々対策しても結局逆コンパイルされたらチート可能なのでいたちごっこ。
中間言語のDLLでは無く、IL2CPPを使ってネイティブファイルで出力すると逆コンパイルによる解析のハードルが上がる
(IL2CPPでビルドされたapkの逆アセンブラも存在する)。
でもメモリの解析・改ざんに対する対策ではない。

以前、R6シージのチーターがUBIはメモリのセキュリティがガバガバでチートが楽勝みたいな事を言っていたので、
チーター側からするとメモリ解析・改ざん出来ない対策をされるとハードルが上がる。
あくまでハードルが上がるだけで、ハードルを超えられるチーターに対しては時間稼ぎでしかない。


いたちごっこでもチーター対策を止めると、恒久的に使えるチートツールが沢山出回って、PS3のGTAオンラインみたいにチーターだらけのカオスになる。

CrackProofが進められていましたけど、CrackProofをググってみたら検索上位にCrackProof回避に関する記事が出ていましたw
まぁいたちごっこでも何もしないとやっぱりカオスになる。

オンラインゲームは遊び半分で、チーターがいてもプレイヤーが笑って済ませられる程度のカジュアルゲームした方が無難ですね。
チーターがいて不公平を感じるのは、散々課金させられたり対戦ゲームだったりするので、そもそもカジュアルゲームだったらチーターがいてもブチギレるプレイヤーは少ない筈。

それにしてもDBDでiniファイルを変更しただけで簡単に壁やロッカーが透視出来るのが放置されているのは酷いですよねw
プログラムの改ざんやメモリの改ざんでは無く、ゲームエンジンのスクリプトで簡単にチートが出来ていましたからねw
あれってもう対策されたのかなぁ？4年間くらい放置されていましたけどw
DBD引退したのはWHキラーやWHサバイバーだらけだったのも理由の一つですけど、単純にゲームバランスが悪く運営がサバイバー側に媚びへつらっているのが気持ち悪くて辞めたんですけどね。

チーター対策とは真逆でMODの話はこちら

emotionサイトトップ >Unity

emotionサイトトップ > Unity >InputSystemがバグだらけで使えな・・・

UnityのInputSystemがバグだらけで使えな・・・
大人しく古いInputManagerを使ったほうが無難かもしれません。

まずバグじゃないけど仕様っぽいけどインプットアクションの個別バインドのProcessorsをスクリプトで変更する事が出来ない。
インプットアクションならスクリプトでオーバーライドでProcessrosを可能(変更は出来ないのでオーバーライドするしかない)。
インプットアクションごとProcessrosを変更するとマウスとゲームパッドのスティックのスケール(感度)を個別で設定出来るゲームだと使えない。

次にバグ。
PlayerInputのControlsChangedEventが発生しないので、キーボードとゲームパッドの入力切り替えを検出する事が出来ない。
Ver2019.4.13f1ではイベント発生するがVer2020.3.6f1ではイベントが発生しない。

イベントが発生しないのでFixedUpdate（）イベントでPlayerInput.currentControlSchemeの変化を監視しようとしたら、
PlayerInput.currentControlSchemeが取得できない。常時Nullを返す為どうしようも無い。

散々調べて2日時間を潰した結果、バグだらけで使えないという結論になりました。
InputSystemに関する情報も少なく、調べたり調査したり海外サイトを調べたりして時間をかなり浪費しました。
しかもこのバグはかなりの期間放置されているみたいです。
使っている人が少なくて、バグ報告する人が少なくてバグに気がついていないだけかもしれません。

Unityは大人しく古いInputManagerを使った方が無難です。
一応キーボードどゲームパッドの入力は出来ますが、ある程度ちゃんとしたゲームシステムを作る時になったら後悔する事になります。

---

イベントが発生しなかったのとPlayerInput.currentControlSchemeが取得できない理由が分かりました。

InputoSystemエディターでスキームを追加する必要があります。
ただそれだけです。
・・・マニュアルやチュートリアルにあった？この説明？

あとゲームプレイ起動短縮の為にプロジェクト設定でEnterPlayModeOptionsを使用していると、InputoSystem関連のイベントが発生しなくなるので、要注意。


あのUnityはスクリプト変更時とゲームプレイ時の地味な待ち時間が、地味にイライラするので改善して欲しいです。
UE4と比べてしまうとイライラしてしまいますが、Unityしか使っていない人はUE4使用者よりはイライラしないでしょうね。

emotionサイトトップ >Unity

emotionサイトトップ > Unity >UnityのベイクにGPUが使えない(OpenCL 1.2が必要)

UnityでCPUでベイクするとめちゃめちゃ時間がかかるのでGPUでベイク使用としたら

OpenCLデバイスが見つかりませんというエラーが・・・

Unityのハードウェア要件をみたら

Windows オペレーティングシステム
OpenCL 1.2 をサポートする少なくとも 1 つの GPU
少なくとも 2GB の専用 GPU メモリ
SSE4.1 命令をサポートする CPU

今使用しているGTX750TiはOpenCL 1.1

orz

GTX750Tiを購入したのは失敗したなぁ～。
GTX950ならHDMIが4K 60Hzにも対応しているし、OpenCL 1.2だし。
単純にゲームをプレイするだけだったらGTX750Tiでも十分だったんですけど、
一世代違うだけで微妙に色んな事に対応していなくて困る。
主に仕事面に関する部分が・・・

半導体不足で、GTX950の中古がアホみたいに高いしorz
速くRTX3050出してぇぇぇぇ～～～～！！！
4世代前の中古グラボに1万円出すくらいなら、超高性能化したRTX3050に2万円(発売直後は代理店ギャランティで3万円くらいすると思うけど)出した方がコスパがいいからマジで買います！！
というかUnityじゃなくてやっぱりUE4かなぁ。