Twitter でちょっと流行っているこのTシャツの件。
こういうコードが書かれているらしい。
Unity いじりをしている人なら「ぱっと見」で、このコードがおかしいことが分かります。
そういうネタなのです。ジョークグッズ。
・
・
・
でも、「はたして全部指摘できているだろうか」って不安になりませんか?
・
・
・
・
・
・
間違えているかもしれないからドキドキする。自信がない。
【訂正】実はこの箇所では f を付けなくても特に問題は起こらないです。ただし、var hoge = 100; のようにすると当然 int 型と解釈されてしまいますし、たまに double も float も受け付けるメソッドもあったりするので、float 型には f を付けるのがやはり基本なんじゃないかなと。。。
参考
このような場合は、Awake や Start 内で MainGame スクリプトのコンポーネントをキャッシュしておくのがよさそうです。
また、GameObject.Find メソッドは処理負荷が高く処理に時間がかかるので、GameObject.FindWithTag などを使うとさらにいいのかも?
参考
Unityエディターの規定値(Project Settings > Input)では、Vertical にはキーボードの W と ↑ キーが positive に、S と ↓ キー が negative に設定されています。また、ゲームパッドの左スティックの入力も受け取れるようになっています。
Tシャツのコードの場合は、上記のどのキーでも、押されている間は true が返るので、if 文の中の処理が行われます。つまり、上記のどのキーが押されても、押されている間はこのスクリプトがアタッチされているオブジェクトが前方に移動します。
これはこれで意図どおりなら正しい挙動なのでしょう。
仮に、本来の意図が以下のようなものであったなら、適切に修正が必要です。
参考
何か問題があるのでしょうか。
このままでも、入力があれば前方に移動する という処理になっているように見えます。
強いて言えば、右辺に Time.deltaTime を掛け算するのが推奨、ということでしょうか。
Time.deltaTime を掛けないと、プログラムを実行するハードウェアの能力によって移動量がバラついてしまいます。
また、このコードでは speed の初期値が 100 なので、ボタンが押されている間、毎フレーム100単位ずつオブジェクトが移動することになります。これも常識的なスケール感でいえばおかしいので、やはり Time.deltaTime を掛けるくらいでちょうどいい進み具合になるような気がします。
この行についての指摘が、なんかモヤっとするのですよね。
参考
はたして、これで合っているのでしょうか。指摘は足りていますかね???(冷や汗)
【追記】
ほかにもこのネタについて記事を書かれている方がいらっしゃったのでご紹介。
transform.position += での移動について詳しく突っ込んでいます。普通に勉強になりますね。
今回は以上です。
[ この記事の使用環境: Unity 2018.1.0b13 Personal (.NET 4.x Equivalent), Visual Studio Community 2017, Windows10 ]
こういうコードが書かれているらしい。
Unity いじりをしている人なら「ぱっと見」で、このコードがおかしいことが分かります。
そういうネタなのです。ジョークグッズ。
・
・
・
でも、「はたして全部指摘できているだろうか」って不安になりませんか?
・
・
・
・
・
・
ひとつずつ指摘してみよう
と、いうことで、ひとつずつ指摘してみましょう。間違えているかもしれないからドキドキする。自信がない。
1. float型 なのに数値に f が付いていない
まずは1行目。float 型であることを明示するために、100f のように、末尾に f を付けてやる必要があります。【訂正】実はこの箇所では f を付けなくても特に問題は起こらないです。ただし、var hoge = 100; のようにすると当然 int 型と解釈されてしまいますし、たまに double も float も受け付けるメソッドもあったりするので、float 型には f を付けるのがやはり基本なんじゃないかなと。。。
参考
2. Update の中で毎フレーム GameObject.Find を呼ぶのは重い
次。Update は毎フレーム呼び出されますが、その中で毎回 GameObject.Find メソッドと、GetComponent メソッドが呼ばれています。これでは処理負荷が高くなってしまいます。このような場合は、Awake や Start 内で MainGame スクリプトのコンポーネントをキャッシュしておくのがよさそうです。
また、GameObject.Find メソッドは処理負荷が高く処理に時間がかかるので、GameObject.FindWithTag などを使うとさらにいいのかも?
参考
3. if ( Input.GetButton("Vertical") ) は意図どおり?
さて、ここ。誤りとは言い切れないが、かなり怪しい。怪しいけれども、もしかしたら意図どおりなのかもしれない。Unityエディターの規定値(Project Settings > Input)では、Vertical にはキーボードの W と ↑ キーが positive に、S と ↓ キー が negative に設定されています。また、ゲームパッドの左スティックの入力も受け取れるようになっています。
Tシャツのコードの場合は、上記のどのキーでも、押されている間は true が返るので、if 文の中の処理が行われます。つまり、上記のどのキーが押されても、押されている間はこのスクリプトがアタッチされているオブジェクトが前方に移動します。
これはこれで意図どおりなら正しい挙動なのでしょう。
仮に、本来の意図が以下のようなものであったなら、適切に修正が必要です。
- ↑ キーなら前方に、↓ キーなら後方に動かしたい
- ゲームパッドで、スティックの倒し具合によって移動量を変えたい
参考
4. transform.position += transform.forward * speed は何か問題があるか?
ここで自分は真顔になってしまいました (´・ω・`)何か問題があるのでしょうか。
このままでも、入力があれば前方に移動する という処理になっているように見えます。
強いて言えば、右辺に Time.deltaTime を掛け算するのが推奨、ということでしょうか。
Time.deltaTime を掛けないと、プログラムを実行するハードウェアの能力によって移動量がバラついてしまいます。
また、このコードでは speed の初期値が 100 なので、ボタンが押されている間、毎フレーム100単位ずつオブジェクトが移動することになります。これも常識的なスケール感でいえばおかしいので、やはり Time.deltaTime を掛けるくらいでちょうどいい進み具合になるような気がします。
この行についての指摘が、なんかモヤっとするのですよね。
参考
はたして、これで合っているのでしょうか。指摘は足りていますかね???(冷や汗)
【追記】
ほかにもこのネタについて記事を書かれている方がいらっしゃったのでご紹介。
transform.position += での移動について詳しく突っ込んでいます。普通に勉強になりますね。
今回は以上です。
[ この記事の使用環境: Unity 2018.1.0b13 Personal (.NET 4.x Equivalent), Visual Studio Community 2017, Windows10 ]
コメント
コメント一覧 (2)
transformでもtranslate、推奨はRigidbody.positionがいいと思います。
たしかに transform.Translate のほうが素直かなとも思ったのですが、はたして「そのほうがいい」とまで言えるのかどうかと思い、書けませんでした。
また、Rigidbody推奨というのも分かります。自分でプレイヤーなどのオブジェクトを動かすときはそうしています。でも、カメラを移動させるスクリプトなどではRigidbodyを使っている例も見かけないし、それもなかなか言い切れないかな、なんて。。。