Time MachineからUnityのプロジェクトをエラーなく復元する方法
私は過去のプロジェクトに戻りたくなったら、MacのTime Machineで過去のプロジェクトを復元します。
アニメーションが複雑なので、「あの時点のボーンの入り方じゃないとダメ」とか「あの時のアニメーションじゃないと…」とか、そういうことがあります。
今までは、Time Machineの復元でうまくいってました。
ところが…
Unityを6にバージョンアップし、MacOSもMontereyからSequoiaになった最近、Time Machineからプロジェクトを復元したら、エラーだらけになってしまいました。
症状
復元したのは、たった1週間前のデータです。
私のPCの環境は何も変わっていません。
なのに、UnityHubに表示された、そのプロジェクトのエディターバージョンは「不明」です。
もう嫌な予感しかしません。
作成していたエディターのバージョンはわかりきっているので、そのバージョンのエディターで無理やり開くと、案の定エラー祭りです。
しかし、エラーを吐いているのは主にインストール済みのアセット類です。
パッケージマネージャーから、アセットのバージョンアップを試みたところ、エラーが解消するものもありましたが、頑なにエラーを吐き続けるものもあります。
その代表格はodinです。
私は早速、chatGPTに相談しました。
解決方法
ぶっちゃけ、私がした紆余曲折など、どうでもいいと思いますので、結論を書きます。
- 問題なく開く直近のプロジェクトを用意します。
- そこに、過去のAssetsフォルダを上書きします。
以上です。
これで過去の状態のプロジェクトが問題なく開きます。
エラーの原因
chatGPTの受け売りですが、
- Unityが過去一キャッシュ依存になり
- macOSが過去一セキュリティが厳しくなった世代
なのだそうで、Time Machineの相性が最悪なのだそうです。
そんな人いないと思いますが、「過去のプロジェクトに戻そう!」と思ったからといって、そのプロジェクトを即座に削除するのはやめておきましょう…。
【webGL】スマホかタブレットかを判別する(JavaScriptからunityにデータ送信する)【htmlテンプレート】
概要
unityのwebGL用htmlテンプレートの頒布です。
「Default」のテンプレートを改造しています。
webGLを再生している端末が、スマホ/タブレット/PCのいずれかを判別して、unityに送信してくれます。
※webGLではScreen.dpiが使えないため、JavaScriptで端末の判別をしています。
※端末の判別は、画面のインチ数を算出して振り分けています。
ダウンロード
※unity2019以降で使えると思いますが、2022.3.40f1で作成・動作確認しています。
使い方
↑からzipをダウンロードして解凍すると、以下の2つが入っています。
- Default_DTRフォルダ
- DeviceTypeReceiver.cs
(1)は、htmlテンプレートです。
(2)は、JavaScriptからのデータを受信するためのスクリプトです。
1. Default_DTRフォルダ
ビルド時のhtmlテンプレートに「Default_DTR」を設定します。
- プロジェクトのAssetsの「WebGLTemplates」の中に「Default_DTR」をフォルダごと入れます。
- メニューから、編集>プロジェクト設定… で、Project Settingsを開き、「プレイヤー」の「WebGLの設定」で「WebGLテンプレート」から、「Default_DTR」を選択します。

2. DeviceTypeReceiver.cs
Unityのシーンに「DeviceTypeReceiver.cs」を設置します。
- スクリプトの設置は、プロジェクト再生時、一番最初に再生されるシーンに設置します。
- シーンのルートに、スクリプトと同名(DeviceTypeReceiver)のオブジェクトを作り、そこに「DeviceTypeReceiver.cs」をアタッチします。
- 「DeviceTypeReceiver.cs」の中のSendDisplayType(string device)関数の中身をお好みに書き換えてください。
JavaScriptからは、SendDisplayType(string device)が呼ばれます。
「string device」が、JavaScriptから送信される文字列になります。
デフォルトでは、それぞれ以下のstringが送られてきます。
・スマホだった時→"Smartphone"
・タブレットだった時→"Tablet"
・PCだった時→"PC" - 「DeviceTypeReceiver.cs」がデフォルトのままの場合、インスペクターの「Tmp」に、TextMeshProのテキストボックスを設定することで、実行時、JavaScriptからの文字列が、そのテキストボックスに表示されるようになります。
カスタマイズする
unityに設置するオブジェクト名や、JavaScriptから送信される文字列を変更したい場合、「Default_DTR」フォルダ内の「index.html」を編集します。
167〜172行目を編集します。
● JavaScriptから送信される文字列を変更したい
167〜169行目を編集してください。
※JavaScriptからの送信データは、unityでの受け取り時、すべてstringになるらしいです。
var smartphone = "Smartphone"; //スマホ時、unityに送信する文字列
var tablet = "Tablet"; //タブレット時、unityに送信する文字列
var pc = "PC"; //パソコン時、unityに送信する文字列
● unityに設置するオブジェクト名を変更したい
171行目を編集してください。
ここで設定したオブジェクト名に、JavaScriptからデータ送信するらしいのですが、多分、データ受信用のスクリプト名も同じ名前にした方がいいと思います。(オブジェクト名とスクリプト名が違う場合、どうなるのかは未検証)
ここを編集した場合は、unityに設置するデータ受信用のオブジェクト名・スクリプト名も変更してください。
var objectName = 'DeviceTypeReceiver'; //unityでデータを受信するオブジェクト(スクリプト)の名前
● データ受信用の関数名を変更したい
172行目を編集してください。
ここで設定した関数名に、JavaScriptからデータ送信されます。
ここを編集した場合は、unityのデータ受信用の関数名も変更してください。
var functionName = 'SendDisplayType'; //unityでデータ受信する関数名
補足:JavaScriptからunityにデータ送信するには?
JavaScriptからunityにデータ送信する場合「『unityInstance.SendMessage』で送信できる」と、大方の説明には書かれてると思います。
これは正しいのですが、それだけでは、データ送信できません。
index.hmlに書かれているJavaScriptに、いくつかの加筆修正が必要です。
このことがどこにも書かれておらず、JavaScriptに詳しくない私は本当に苦労しました!
ここで頒布している「Default_DTR」には、その修正が反映されていますので、「データ送信なぜかうまくいかん…」と悩まれてる方は、ご利用になってみてください。
スクリプトを加筆修正した箇所には、「// 修正箇所」と記入してあります。(3箇所あります。)
URP対応のモザイク・ぼかしシェーダー(2D / Sprite Renderer)
※ このシェーダーは、Unity6では使えないです。
Unity6で使えるモザイクシェーダーをお探しの方は、
目次から「Unity6で使いたい方へ」をクリックしてください。
pya1234さんのモザイクシェーダーをChatGPTを使って、URP対応のシェーダーに修正しました。「経緯とかどうでもいい」という方は、目次でダウンロードをクリックしてください。
ことの経緯
私は今まで、冒頭でリンクさせていただいたpya1234さんのモザイクシェーダーを重宝させていただいてたのですが、URP対応のプロジェクトで利用しようとしたところ、エラーが出て使えなくなってしまいました。
これは困った…。
旧来のシェーダーで使えたGrabPassが、URPでは使えないことが原因なようです。
「URPに切り替えたことだし、前々から気になってたシェーダーグラフでモザイクシェーダー作っちゃう?(ウキウキ)」と思ったのですが、これがまた、話はそう簡単にはいかず…。
超ベーシックなモザイクシェーダーであれば、すぐに作れるのですが、pya1234さんのシェーダーのように、オブジェクト越しに見えるものすべてにモザイクをかけることができません。
そこからネット探索の旅に出た末、UI用のモザイクシェーダーの作り方を発見できたのですが、このシェーダーをSpriteRendererに使ってみたところ、うまく作動せず…(当たり前ですが)
ちなみに、Imageで使用すると、ちゃんと作動します。
その他、3D用モザイクシェーダーの作り方はたくさん発見できたのですが、3Dと2Dはまた少々異なるらしく、「そんな設定2Dにないんですけど?」という箇所が現れて頓挫。
そもそも、シェーダーの知識がそんなにない私がネットを探索したところで、探索範囲は限られており、「やはり素人の私には無理か…」と諦めかけたのですが、一縷の望みをかけてChatGPTにお願いすることにしてみました。
実は、pya1234さんのモザイクシェーダーがエラーを吐きまくった際、一番最初にChatGPTに修正依頼したのですが、何度やってもうまくいきませんでした。
なぜなら…私に知識が皆無だったからです。
今思えば、すごい漠然とした、ChatGPT頼みの修正依頼をしていました。
しかし、今の私は違う。
URPモザイクシェーダーを作り出すために色々調べたせいで、初めより知識が備わり、的確な修正依頼をChatGPTに出すことができるようになっていたのです。
そして…
無事!pya1234さんのモザイクシェーダーをURP対応シェーダーに修正することができました!
ChatGPT凄い!!!
いや〜、「もう諦めて旧来のシェーダーに戻すか?」と思ってたので、本当に嬉しいです。
シェーダーのダウンロード
※ Unity6では使えないです。
修正したURP対応のシェーダーは、↓からダウンロードできます。
※大元はpya1234さんのモザイクシェーダーです。(著作権などで)問題がありましたら、取り下げますので、コメントにてご一報ください。
※素人の私がChatGPTで修正したものですので、自己責任でご利用ください。
※このシェーダーに関する質問をされても、素人ですので、何も答えられないです。
※Unity2021.3.28では無事動いてます。
ちなみに、モザイクシェーダーあるあるの「モザイクのセルが長方形になる現象」にも対応してみました。モザイクのセルを正方形にできます。
使い方
- ダウンロードした「mosaicURP.shader」をプロジェクトのAssetにドラッグ&ドロップする。
- Assetの「mosaicURP.shader」上で、右クリック > 作成 > マテリアルで、マテリアルを作成する。

- 「Pya_mosaicURP」というマテリアルが作成されるので、モザイクフィルター化したい2Dオブジェクトのマテリアルに設定する。
下の図の場合、オブジェクトAとオブジェクトBの手前に、オブジェクトCが配置されているのですが、オブジェクトCのマテリアルに「Pya_mosaicURP」が設定されていて、オブジェクトA・Bそれぞれと重なる部分がモザイクになっています。

ちなみに、「Pya_mosaicURP」を適用したオブジェクトのZ座標がカメラより手前になってしまうと、ゲーム実行時にモザイクが映らなくなるので、注意してください。(手取り早くモザイクオブジェクトを手前にしたくて、Z座標に大きめのマイナス値を入れるとそうなりがちです。) - 「Pya_mosaicURP」のインスペクターで、モザイクのセルサイズ等を設定します。
pya1234さんのDLページにも書かれていますが、こちらにもあらためて書いておきます。

【Cull】
詳しくないですが、2DだとOffでいいと思います。
【Type】
モザイクかブラー(ぼかし)かを選びます。4タイプから選べます。
以下、pya1234さんのページから転記。
・モザイク1(mosaic1_normal)
普通のモザイク
・モザイク2(mosaic2_average)
色を平均化してモザイクを作る。1より色の再現度が高い。
・ぼかし1(blur1_normal)
周辺ピクセルの色を平均化する。
・ぼかし2(blur2_gauss)
ガウス関数での重み付け。1より画像が平滑化される。
【AspectRatio】
モザイクのセルの正方形化に使います。
作成しているゲームのアスペクト比を入れてください。
(比率でなくても、そのまま入れても大丈夫です。例えば960×540で作っている場合、そのままX(横)に960、Y(縦)に540と入れて大丈夫です。)
自動取得させたかったのですが、シェーダーでは本来取得できないらしいのと、代替手段について細々調べるのが面倒くさかったので、手入力にしました。
長方形のままでいい方は、両方1を入れてください。作ってるゲームの画面比率のモザイクセルになります。(16:9で作っていれば、モザイクセルも16:9の長方形になります。)
【Mosaic】
「Type」でモザイクを選択した場合、ここでモザイクの大小を調節できます。
【Blur】
「Type」でブラー(ぼかし)を選んだ際、ブラーのかかり具合をここで調節します。
あらためて、モザイクシェーダーを作ってくださったpya1234さんに感謝です!
(あと、ChatGPTも!)
Unity6で使いたい方へ
有料になりますが、 Yu-Rin-Chiのゲ制工房さんのシェーダーがおすすめです。
ゲームでよく使われそうなシェーダー120種類以上をセットで販売されています。
●booth
●Unity Asset Store(URP用)
●Unity Asset Store(Built-In用)
ちなみに、モザイクシェーダーは、ネット上の情報を集めれば、シェーダーグラフで作成できますが、断片的に散らばっている情報を検索してまとめ上げて作成するのは、かなり骨が折れます。(自分のケースに100%合致してる記事がないので、スラッといかず、かなり紆余曲折します)
その面倒をすべてやってくれてるのが、Yu-Rin-Chiのゲ制工房さんのシェーダーです。
しかも、他にも120種以上のお役立ちシェーダーが入っているので、コスパ的にもタイパ的にもかなりオススメです。
Yu-Rin-Chiさんのモザイクシェーダーは2種類ありますが、「OverlayPixelize」が、ここで取り上げているモザイクシェーダーと同じ効果のシェーダーです。
シェーダーの使い方は、↓のページでチェックできます。(該当部分にリンクしてます)
私は自力でモザイクシェーダーを作ろうとして途中まで作ったのですが、「あれ?これって結局、Yu-Rin-Chiさんのシェーダーと同じだな…」って気づいて、作るのをやめました。
(Yu-Rin-Chiさんのアセットには、シェーダーグラフの生データが同梱されているのですが、それと全く同じ構成のものを作り上げようとしていました)
自力で作ると本当に時間がかかるので、サクッと購入してしまうのをオススメします。
モザイクをかけたオブジェクト同士を重ねる方法
現状、一番おすすめなYu-Rin-Chiさんのモザイクシェーダーですが、弱点が1つあります。
モザイクをかけたオブジェクト同士を重ね合わせることができません。
これは、Unityの仕組みが原因なので、シェーダーにかなり詳しい人でもない限り、誰が作っても、この弱点を持つシェーダーになると思います。
ここでは、その弱点をカバーする方法を書いてみようと思います。
あまりスマートなやり方ではないですが、現状、私が思いついたのはこの方法だけです。
(※未検証ですが、カメラを複数使うことで、モザイクをかけたオブジェクト同士を重ね合わせることができるかもしれません。私は、webGL用にもビルドしたかったので、カメラを複数使う方法は採用しませんでした。)
弱点の説明
大方の人は、このシェーダーで事足りると思いますが、私の場合は、かなり入り組んだ構成のオブジェクトに適用したかったので、本当に頭を悩ませられました。
例えば、下図のような感じで、2人の人物がすれ違ったとしましょう。モザイク部分は、わかりやすいようにピンクで囲いました。

すると、モザイクのレイヤーは、モザイクをかけたいオブジェクトより手前にないといけないために、以下のような状態になってしまいます。(茶服女性用のモザイクが、緑服女性に適用されてしまう)

言わずもがな、私としては、下図のようになってほしいです。

ちなみに、レイヤーの構成はこうなっています。

「緑服の女性を、茶服女性のモザイクより手前のレイヤーにすれば解決では?」と思われたと思います。ところがそれはできません。
モザイク処理を施したいオブジェクトは、「先頭ソーティングレイヤーテクスチャ」に設定したレイヤーよりも手前側でなければなりません。
考えられるのは、以下の2パターンですが、いずれもうまくいきません。
……………………………………………………………………………………………………………………………………
● パターンA


……………………………………………………………………………………………………………………………………
● パターンB


解決方法
このシェーダーを使う際、「Renderer 2D」の「カメラソーティングレイヤーテクスチャ」の「先頭ソーティングレイヤーテクスチャ」に、レイヤーを設定します。
ここで設定したレイヤー以奥のものをカメラに映した結果を取得し、そこにモザイク処理を施してから、モザイク用オブジェクトに描画するのが、このシェーダーの大まかな流れです。
ですので、「先頭ソーティングレイヤーテクスチャ」より奥に配置したオブジェクトは、モザイクの素材用と割り切ります。
具体的な流れは以下です。
- モザイク処理を施したいオブジェクトを「先頭ソーティングレイヤーテクスチャ」以奥に配置する。ボーンを入れるなど、アニメーションをつける場合は、この時点で完璧な状態に仕上げる。
- それを複製し、「先頭ソーティングレイヤーテクスチャ」より手前のテクスチャに配置する。(1)で作ったオブジェクトと、このオブジェクトは、完全にシンクロさせる。(複製してるので、特に気をつけなくてもシンクロするとは思います。実際は2つあるが、完璧にシンクロするので、1つしかないように見える状態です)
- モザイクシェーダーを適用したオブジェクトは、この複製したオブジェクトに対して、手前にしたり奥にしたりして、好きな位置に調整する。 ソートレイヤーで階層分けしても良いし、同一レイヤー内で、「レイヤーの順序」を調整しても良い。
「先頭ソーティングレイヤーテクスチャ」より奥のオブジェクトは、モザイクを作成するためだけに存在させている感じです。「いらないだろう」と思って非表示にすると、モザイクもブランクになります。負荷軽減の目的で部分的に非表示にするなら、複製した方のオブジェクトを非表示にします。裏にモザイク用のオブジェクトがあるので、重なり順的に非表示にしてもおかしくないパートは非表示にできます。
同じオブジェクトを2つ存在させるので、非常に無駄ですが、現状、私が思いついたのは、この方法だけです。
もっといい方法や、もっと良いシェーダーがありましたら、教えていただけると嬉しいです。
※以下の例では、Layer2のオブジェクトは必要ないと思いますが、例えば、茶服女性の胸だけにモザイクをかけたかった場合、腕がモザイクより手前にくる時もあります。
こういった場合、茶服女性の複製は必要になってくると思います。

ゲームのローカライズ、何語がオススメか?
この記事の要約
- スペイン語がおすすめ!
- 理由は、21カ国で使われてるから。
- 最盛期で、中国+台湾からのアクセス数を上回ったことがある。
平常時でも、中国単体並みのアクセスがある。
本編
最初に断っておくと、私は趣味でゲームを作ってるだけの素人なので、確固たるエビデンスがあるわけではないことをご了承ください。
私の経験からいうと、「このへん狙い目だな〜」と思った…ってだけの話です。
(しかも、そんな目新しい話でもないと思います。)
私は、趣味でゲームを作ってweb上で無料公開しているのですが、私のサイトはどう言ったわけか日本人の来訪者が少ない(少なかった)です。最小で10%しか日本人がいなかったこともあります。
じゃあ、どこの国が一番多いのか?というと、言わずと知れた、中国です。
40%くらいは中国からの来訪者で、次が台湾。台湾は20%くらいのことが多く、その次に僅差で日本…ということが多かったです。
その他は、アメリカ、ロシア、EUが少量ずつ、あとはいろんな国から1〜3名…といった感じです。
(ちなみに、私は日本語で日本人向けにしか宣伝活動したことがないですが、なぜかこのようになってしまいました。多分、中国人の口コミ力がすごいのだと思います。)
そんなある日、来訪者の構成に激変が起きました。
スペイン語圏からのアクセスがうなぎ上りになったのです。
どうやら、メキシコのYouTuberが私のゲームをチャンネル内で取り上げたようで、あの絶対不動だった中国語圏(中国+台湾)からのアクセス数をあっという間に凌駕しました。
話題になったのは素直に嬉しかったのですが、「これもそのうち、すぐ下火になるんだろうな…」と思っていました。(バズりは、沈下も早いので。)
しかし、私の予想に反してスペイン語圏からのアクセスは、3年経った今もそこそこあり、中国(単体)並のアクセスを保っています。
なぜそうなるのか?というと、スペイン語を話す国が、思った以上に多いことに要因があります。
調べたところ、スペイン語を公用語とする国は、21カ国あるようですね。
スペイン語話者も、中国語に次いで多く、世界2位なのだとか。
21カ国のうち、どこか1つの国に刺されば、残り20カ国に広まる可能性が高いわけです。
これは中々魅力的です。
現在の私のサイトでは、4〜10位までスペイン語の国です。
もちろん、10位以下にも、様々な国に混ざってスペイン語の国が多数エントリーしています。
しかも、アメリカや(スペイン以外の)EUからのアクセスも増えました。
(スペインは10位以内に入っているので、「スペイン以外のEU」の話です。)
これは、言わずもがな、アメリカやEUにスペイン語の話者が多いからです。
アメリカは一時、スペイン語話者が増えたことが問題となった時期がありましたし、EUは、EU内でいろんな国の人が移動しているため、スペイン語話者がEU内に散らばっているのだと思います。(ただの推測ですが)
それまで私は、「ローカライズするなら、英・中くらいかな…」と漠然と考えていたのですが、この出来事にあってからは「ひょっとしたらスペイン語って、英語より影響力があるのでは?」と思うようになりました。
また、中国は確かに人口は多いですが、広まっても中国1カ国でしかありません。
「いろんな国の人に知ってほしい」と思うなら、スペイン語の方が断然有利です。
話は少しそれますが、有料ゲームを作られている方もいらっしゃると思いますので、思い出した話を少し。
↓のページで、DMMの開発者の方が面白いことを書かれていました。
DMMのログイン・会員登録周りの多言語化対応 - DMM inside
中華圏のユーザーは英語圏・日本国内のユーザーに比べて課金率とARPPUが低い状態であることをデータ上で確認できていました。
そんなわけで、より高い精度の英語表記と、新たに中国語(繁体字)の対応をすることになりました。
どうやら、爆買いのイメージとは正反対に、中国人はあまりお金を落とさないようです。
実は、近所の焼き鳥屋(飲み屋)の店主が、「中国人は何も注文しない。4人で来て焼き鳥1本頼んで、あとはこっちが焼き鳥焼いてるのを見てるだけ」(中国人に限らず、外国人にとって、レストランの調理風景を見られるのは珍しいようです)と言っていて信じられなかったのですが、DMMの記事と照らし合わせると「然もありなん…」といった感じなのでしょうか。
(とはいえ、スペイン語の国が多い南米も、そこまで裕福ではないでしょうから、似たり寄ったりの状況かもしれませんが。)
ちなみに、今の私のサイトのアクセス構成ですが、無事に日本人が戻ってきて、日本人のアクセス数が50%にまで増えました…!
理由は、ゲームをパソコンだけでなく、スマホでもプレイできるようにしたからです。
噂には聞いていましたが、「パソコンなし、スマホのみ」という層がこんなにもいるのか…!と本当に驚きました。
増える直前は、日本人のアクセスは10%にまで落ち込んでいたので、アクセスが一気に5倍に増えたことになります。
時代はスマホなんですね。
周回遅れですが、いろいろ勉強になりました。
sprite swapを使ったアニメーションがうまくいかない時の対処法まとめ
何かとうまくいかないことが多いsprite swapアニメーション。
うまくいかないときの症状別に、対処法をご紹介します。
【A】アニメーションが微動だにしない
[対処方法]
(1)アニメーションのタイムラインから、Sprite Resolver プロパティの全てのキーフレームをマウスカーソルで囲って選択します。
(2)キーフレーム上を右クリックして出てきたメニューから、「両側の接線 > 一定」を選びます。

[原因]
Unityのマニュアルによると、「両側の接線 > 一定」にした時のみ、キーフレームに割り当てられたスプライトを探しにいく仕様のようです。(それ以外だと、プロパティの数値を計算してフレーム間補完をするみたいです)
【B】アニメーション がコマ落ちする。
Unityでは、レイヤーを使うことでアニメーションの部分置換ができます。
sprite swapを使ったアニメーションでは、レイヤーのブレンドの設定が「Additive」だとコマ落ちするようです。
[対処方法]
レイヤーのブレンドの設定を「オーバーライド」にする。
(ちなみに、アニメーション の置換が反映されない方は、ウェイトが0になってると思いますので、1にしてください。)

【C】sprite swapを使用したアニメーションクリップの再生と、通常のアニメーションクリップの再生がずれる。
[対処方法]
(1)通常のアニメーションクリップのサンプルレートを、sprite swapアニメーションのサンプルレートに合わせる。

(2)通常のアニメーションの、キーフレームすべてを選択し、キーフレーム上で右クリック。「両側の接線 > 一定」に設定する。

[原因]
アニメーションがズレる方は、おそらくsprite swapアニメーションのサンプルレートを少なくしていると思います。通常のアニメーションは、updateに合わせて1秒間に60回、アニメーションを更新しています。これは、サンプルレートをいくつに設定しても、60回更新し、滑らかなアニメーションを実現しています。
しかし、sprite swapアニメーションは、例えばサンプルレートを20にしたなら、1秒間に20回しか絵が切り替わりません。
これは、通常のアニメーションが2回更新されるのを待ってから、sprite swapアニメーションを1回更新することになり、このために、常に2フレーム分、アニメーションが遅れるように見えます。
これを解消するために、あえて通常のアニメーションのフレームレートを少なくし、フレーム間補完をなくす「両側の接線 > 一定」に設定します。
【D】sprite swapを使用したアニメーションが小刻みに揺れる。
下記の記事をご参照ください。
sprite swapを使ったアニメーションが小刻みに揺れる(位置がずれる)時の対処法
対処法
swapさせる画像を、縦横ともに【偶数ピクセル × 偶数ピクセル】にする。
例)
口パクさせるために、口の連番画像があるとする。
これは、「人物.psd」の中にレイヤーで入っている。
【偶数ピクセル × 偶数ピクセル】にするのは、「人物.psd」ではなく、口の画像そのもののサイズを【偶数ピクセル × 偶数ピクセル】にする。
おそらく、口レイヤーにおいては、口以外を透過させている人がほとんどと思うが、透過部分を無視した口の実画像部分のサイズが【偶数ピクセル × 偶数ピクセル】になっている必要がある。
(私は、全く同サイズの【偶数ピクセル × 偶数ピクセル】の肌色の下地を、全口画像の背景に合成して解決しました。)
なぜ、ずれるのか?
多分ですが、奇数ピクセルだと2で割り切れないために、上下左右どこか1ピクセルずらして配置される。このせいでアニメーションがガタガタと小刻みに揺れてしまう。
これで1日潰れた…
Unityホント疲れる…
本来の画像サイズのまま、画像を配置する方法
私は2Dのゲームを作成していますので、Unityのプロジェクトを新規作成する際、「2D」を選んでいます。また、PC用ゲームをメインに考えていますので、ゲームの画面サイズも固定しています。
Unityを始める際に参考にしたサイトでは960×540をオススメされていたので、私も960×540で作成することにしました。
さて、私は、960×540の画面の中に、100×100の画像を、100×100のサイズで配置する必要が出てきました。
「普通に配置すれば、できるんじゃないの?2Dなんだし」
そう思う人は多いと思います。私もそう思いました。
しかし…Unityはそれを許してはくれません。
普通に読み込んでゲームオブジェクトにすると、なんだかすごく小さい…。
「え…ちっさ!何コレ?」
適当に拡大しようにも、現在のサイズがわからないため、何倍に拡大していいのかわかりません。
私は思いました。
「そうだ!2DのくせにZ軸(奥行き)の概念があるからに違いない!
きっと、めっちゃ遠くに配置されてしまったんだ!」
しかし、これは答えではありませんでした。
いくらZ軸を触ったところで直りません。
さて、100×100の画像を配置したのに、なぜUnityは100×100で表示してくれないのでしょうか?
答えは…
Unity(2D)は、「ユニット」という単位で画面を構成していたからです。
いや〜ビックリ。
そう言われたら、そんな説明を最初の方にチラッと読んだ気もするけど、それがここで活きてくるとはね…!
つまり、1ユニットの設定が10×10ピクセルなのか、50×50ピクセルなのかで、配置された画像の大きさが変わってしまうという仕組みだったのです。
ユニットって何?と思われた方は、Unityの「シーン」を見てみてください。
そこに、うっすらマス目が引かれていると思います。
この1マスが1ユニットです。
対処方法
(1)ヒエラルキーから「Main Camera」を選択し、インスペクターの「Camera」の「サイズ」を確認します。このとき、サイズにこだわりがない場合は、あとの計算が楽なので「5」に変えてしまってもいいと思います。

(2)(1)を元に、1ユニットが何×何ピクセルになっているのか算出します。
「Camera」の「サイズ」は、「シーン」上のマス目の数を設定するものになります。
「5」の場合は、画面の中心から上方向に5マス、下方向に5マスの、合計10マス、マス目を設定することを意味しています。(ちなみに、横方向は成り行きとなります。)
この数で、設定したゲーム画面の縦サイズを割れば、1ユニットが何×何ピクセルなのかがわかります。
(私の場合は、ゲーム画面の縦のサイズが540ピクセルなので、540px ÷(5マス×2)で、1ユニットが54×54ピクセルであることがわかります。)
(3)アセットから、あらかじめ読み込んでおいた画像を選択し、インスペクターの「インポート設定」の「ユニット毎のピクセル数」を、(2)で算出した数に書き換えます。(画像は複数選択して一気に変えることもできます。)あとは、「適用する」を押して完了です。

これで、100×100ピクセルの画像を、100×100ピクセルで配置できるようになりました。