transformでの移動方法が間違っていると思われます。
C#
1void Update () {
2 transform.position += new Vector3(1f, 0f, 0f);
3}
例えば上記のコード、ゲームによってはカクカクします。
Update関数は「1フレームに1回」呼ばれます。
そしてフレームレート(=1秒間に何回Updateが呼ばれるか)は負荷によって都度都度変わります。
例えば(極端な例ですが)上記のコードを使って、フレームレートが以下のように推移した場合。
0フレーム目:ゲーム開始後0秒目
1フレーム目:0.01秒目
2フレーム目:0.03秒目
3フレーム目:0.035秒目
各フレーム間の時間が0.01→0.02→0.005秒とバラバラなのに移動量は同じなのでガタついて見えます。
(カメラの移動だと描画に直結する為分かりやすいかと)
なので「Time.deltaTime
=各フレーム間に掛かった時間」を掛け算することで、各フレームにおける移動距離を同じにすることが出来ます。
C#
1void Update () {
2 transform.position += new Vector3(1f, 0f, 0f) * Time.deltaTime;
3}
これだけでも大分滑らかになるはずですが、必要と好みに応じてlerp等を使うと良いかと。
ちなみに何故rigitbodyだと元から滑らかなのかというと、
物理演算の場合Unityが内部で上手いこと調整してくれているのと、
「フレームレート依存」ではなく「現実世界の"時間"依存」で動いている為です。
Update
の代わりにFixedUpdate
を使うと、フレームレートに依存せず常に同じ間隔(デフォ値だと0.02秒。Edit > Player Settings > Time から変更可)で移動するようになると思います。
「物理的な操作はUpdateではなくFixedUpdateで行え」というのはこれが理由です。
(Updateを使うとFixedUpdateの合間にUnityが意図しない操作が入ってしまい、物理演算が破綻する可能性がある)
逆に何故常にFixedUpdateを使わないかというと、負荷を最小限にする為にわざわざフレームレート落としてる(=Updateの回数を減らしている=計算回数を減らしている)のに、それを無視して一定間隔で計算し続けてたら無駄だよね、ということかと。
ちなみにちなみに、画面の描画自体はフレームレート単位なので、
フレームレートがガタ落ちしている場合(10fpsとか)の場合はtransformだろうがrigidbodyだろうがカクついて見えます。
この場合は全体の負荷を下げる等して、まずフレームレートを上げることを目標にしてください。
(今回はrigidbodyは滑らかとのことなので候補から外しましたが)
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。