原カバンは鞄のお店ではありません。

Unityを使ったゲーム制作のあれこれを綴っていきます。

【Unity】オープニングシーン作成

寒風吹きすさぶ

「Dull Things No Life」の製作も大詰めということで、この三連休は気合を入れてゲーム作りに励んでいたわけですが、そんな中、近くのコンビニまで夕飯を買いに出かけた帰り道、そういえば部屋の電気をつけっぱなしだったなぁ、なんてことを思いながら自宅のマンションを眺めていたら、7階建てのマンションの中で自分の部屋しか灯りが点いないことに気づいて、そして思い出したんです、ああ、今日はクリスマスイブか・・・って。大丈夫です。別に泣いてません、今日も元気に心も体も寒風吹きすさぶ日々を過ごしています。

 

そんな中・・・

そんな感じで血の涙を流しながら何を作っていたのかといえば、「Dull Things No Life」の初回起動時に流すオープニングのシーンをTimeLineとCinemachineの勉強をしながら作っていました。

 

TimeLineとはオブジェクトやCamera,AudioClipなどを時系列に並べて動かすことの出来るエディタで、Cinemachineとはカメラの動きをいい感じにコントロールしてくれるアセットです。

 

TimeLineはUnityに標準で搭載されています。CinemachineはAssetStoreからダウンロードする必要がありますが、無償なので気兼ねなくダウンロードして使うことができます。

 

どちらもゲームのカットシーンや、映像シーケンスを作るのに非常に有用で、テラシュールブログにもその使用法が度々取り上げられています。私は以下の記事を参考にしながらオープニングのシーンを作っていきました。

 

tsubakit1.hateblo.jp

出来上がり

で、こんな感じのシーンが出来ました。
CinemachineとTimeLineで細かいカット割りが以外と簡単に作れました(とはいえ、3日掛かったけど)

 

youtu.be

BGMにはD’elfさんの「Re_cybernetic」を使用しています。

www.d-elf.com

普段はPCのUnityエディタ上の画面をキャプチャして動画を作成しているのですが、PCの性能がショボイ所為なのか速い動きのある場面をキャプチャするとガタガタになってしまうので、実機(Android端末)で動かした画面をキャプチャして動画を作成しています。

なので画面中にキャプチャソフト(DU Recorder)のアイコンが映りこんでますがご容赦ください。

 

年内リリースは無理だったので、来年1月中にはなんとか・・・

(じゃないと次の予定が立たないし・・・)

【Unity】DoTweenで360度回転したかった。。。

需要が読めない

最近ブームの話題作だ、ということで寒風吹きすさぶ中、わざわざ映画館まで足を運んで「ボヘミアン・ラプソディ」を観て来たました。まぁ、Queenに思い入れも何もない人間なので「感動!」「泣いた!」みたいな絶賛をする気もないし、「クイーンってはさぁ、こんな美談で語るようなバンドじゃないんだよ・・・」みたいなうざい薀蓄を語る気もないのですが、映画ラスト20分のライブシーンは必見だと思います。映画を観た後、実際のライブ映像も観たくなるし。

 


ただ、昼間の回ということもあってか観客が爺さん婆さんばかりでビックリ。あれだよ、ブームってのは若い女性の間とかで流行っているからブームって言うんじゃないですか?シルバー世代とか演歌しか聴かない、とか固定観念に染まっていたので、まさか洋楽ロックが主題の映画を観に行って敬老会の中に混じるような状態なるとは夢にも思いませんでした。学生はおろか同世代の人間も見当たらなかったし。

 

メニュー画面作り

そんな感じで需要もターゲットも読めないような人間が今日もゲーム作りに励んでいるわけですが、「Dull Things No Life」の製作も本編の主要な部分はだいぶ作り終えたので、枝葉となるメニュー画面等々の作りこみ作業へ移ってきています。

 

こんな感じ(前回の記事でも紹介したけど)

f:id:Karvan:20181211195710p:plain

 

そのメニュー画面も上の画像にあるように大体は完成したのですが、左上に見える掲示板みたいな部分、ユーザにいろいろな情報を表示する部分の作りこみで問題が発生しました。

 

表示情報を切り替える

掲示板みたいな部分には、現在の状態やスコア情報等を一定間隔で切り替えて表示しています。(全てテキスト情報)
これは各情報を表示するTextMeshを四角柱型に配置して、それを90度づつ回転することでユーザ側に見える情報を変えています。

 

f:id:Karvan:20181218233821p:plain

この90度づつ回転させる、という機能にはDoTweenのDoRotateメソッドのRelativeオプションをtrueにすることで実装しています。
このRelativeオプションは非常に有用でこれを設定した場合、移動角度を相対的に計算するようになります。


つまり、現在角度からZ軸方向に90度回転させたい場合、

 

// 回転処理
 MessageBoardObj.transform.DOLocalRotate(new Vector3(90.0f, 0.0f, 0.0f), 0.3f)
                                        .SetRelative(true);

 

としてコールすると、オブジェクトの角度は順に0度⇒90度⇒180度⇒270度⇒360度へと回転してくる、はずです。ですが、実際に実行してみる・・・

 

0度⇒90度の場合

f:id:Karvan:20181218234430g:plain

うん、大丈夫

 

90度⇒180度の場合

f:id:Karvan:20181218234501g:plain

OK、OK

 

180度⇒270度の場合

f:id:Karvan:20181218234535g:plain

コレまでとは逆方向に回転、なんでやねん。

 

調べてみるとDORotateは動作として回転方向は指定した角度の近い方へ回転する仕様らしい、例えば270度に回転する場合は、0度から回転して0->1...269->270となるのではなく、360度から回転して360->359...271->270で回転するみたい。

 

つまり、0度⇒360度を90度づつ回転させる場合、全て同じ指定で回転させるのではなく、180度⇒270度の場合は逆方向に回転させないと上手くいかないようです。
なので、コードとしては

 

/// <summary>
/// メッセージ表示処理(順次回転表示)
/// </summary>
private void RotDisp_MessageBoard()
{
    // Indexの設定
    nextIndex++;
    if (nextIndex >= 4) nextIndex = 0;

    if (nextIndex != 3)
    {
        // 回転処理
        MessageBoardObj.transform.DOLocalRotate(new Vector3(90.0f, 0.0f, 0.0f), 0.3f)
                                    .SetRelative(true);
    }
    else
    {
        // 回転処理
        MessageBoardObj.transform.DOLocalRotate(new Vector3(-90.0f, 0.0f, 0.0f), 0.3f)
                                    .SetRelative(true);
    }

}

 

 

と、超ダサいコードに。うーん。。。


ちなみに結果としては

f:id:Karvan:20181218235128g:plain

こんな感じで、上手く一回転してくれるようになりましたが、なんだかなぁ・・・・
 




 

進捗報告

喉痛い

出来るだけ起伏のない平坦な人生を選んできたつもりでしたが自然現象だけはこちらから選ぶことは出来ないので、ここ最近の急激な寒暖差に体がついていけずに風邪をひいて喉がとても痛いです。のど飴を舐め過ぎて舌も痛いし。

 

つまり全然本調子じゃないということで、本来ならDiscont@XR landscape design氏が紹介されていた窓シェーダーについて

 

styly.cc

 

実際に実装してみたアレやコレやを書くつもりでしたが、頭が働かないので今回は進捗報告のみです、ごめんなさい。

 

メニュー画面を作った

そんなこんなで先週から今日に掛けてはずっとタイトル&メニュー画面の作成に従事していました。
出来上がりとしてはこんな感じですが、どうでしょうか?

 

f:id:Karvan:20181211195710p:plain

 

サイバー系ゲームのあるあるで文字やら床やらがやたら発光しております。
「Run」ボタンをクリックするとさらに発光します。こんな感じで

 

f:id:Karvan:20181211195744g:plain

 

年内には完成したいなぁ・・・

 

ブログ開設一周年

早いものでこのブログを開設してから一年がたちました。パチパチ、おめでとう、おめでとう自分。

 

開設当初の予定では1年の間にアプリを2,3本リリースしてアプリの売り上げでウハウハな生活を営んでいるはずでしたが、実際のところはリリースできたのはたったの1本で、アプリの売り上げはほぼ0という惨憺たる結果となりました。

 

次の1年こそはアプリを2,3本リリースして、高級ホテルで両脇に売れないグラビアアイドルを抱えながら夜景を見つつワインを傾けるみたいな豪遊できるぐらいの収入を得たいと思います。ワイン苦手だけど。

 

 

 

 

【Unity】カメラワークによる演出を考える

ふと思い出す

12月に入ったのに気温が高くて全然冬になった気分にはなりませんが、確か昔、このぐらいの時期にひょんなことから足を骨折したことがあって、病院でギブスを巻き、なれない松葉杖をなんとか使いながら自宅に戻る途中で上司に本日は休みを取る旨の電話をしたら、「はぁ?おまえなぁ、有給ってのは病気したとか大怪我したとか、そういう時に使うものだぞ!」ってな感じで延々と説教された出来事を、バカリズムに似た芥川賞作家センセの「いい加減、国に与えてもらった休日に、みんなで一斉に休むとか止めればいいのに」といった高等遊民的なTweetを目にして思い出した今日この頃、私もいつの日か「ゴールデンウィーク?ww、みんな好きなときに好きなだけ休めばいいのにー(鼻ほじー)」みたいなことを言える立場になってみたいものです。

 

減衰・FoV・手振れ

そんな感じで私もナチュラルに上から目線で物を言えるような地位を確立すべくゲーム製作を頑張っている訳ですけれども、アレやコレや試行錯誤していく中で、つい最近では@yoship1639氏の書かれた記事が非常に有用で参考になりました。

 

qiita.com

ゲーム中のカメラワークについての手法に関する記事なんですが、記事の中で紹介されている「Lerp減衰・FoV変動・PerlinNoise手ブレ」を取り入れると、かなりダイナミックが表現が可能となります。

 

それぞれの手法については上記の記事で詳しく書かれているのですが、掻い摘んで説明すると

 

  • Lerp減衰:カメラとカメラの被写体の動きをピッタリ同時にするのではなく、カメラ側が少し遅れて被写体を追随するような動きをさせる手法。これにより被写体の動きが俊敏かつ大きく見える

 

  • FoV変動:カメラの画角(FieldOfView)を変化させて画面をダイナミックに変化させる手法。カメラのProjection(投影方法)がPerspective(透視投影)の場合は特に効果が大きい

 

  • PerlinNoise手ブレ:文字通り「手ブレ」を表現する。カメラを揺らすことで被写体が激しく動いているように見える。アクションゲームとかRPGなどではダメージを受けた時の表現にも使われる。

 

となっています。

 

FoV変動を取りれよう

一般的なレースゲームではマシンにブースとが掛かったり急加速したりするときに、一瞬大きな引きの画になったりしますが、それはカメラの画角(FieldOfView以下、FoV)をあげている為です。

 

FoVを上げるとはカメラに写る範囲を広げる、という意味で、一般的に大きく引いた画を撮るときにこのFoV値を上げて画面に表示される範囲を広く取ります。

 

もちろん、カメラ自体を奥行き方向に移動させて画角を広く取るという手法もありますが、カメラの投影方法がPerspective(透視投影)の場合、このFoV値が大きくなると画面の端に行くほど歪みが大きな画像になり、被写体は引き伸ばされて映し出されます。

逆に中央に行くほど歪みは小さいものになるので、結果、奥行きが強調された画面になります。

 

通常時の画面

f:id:Karvan:20181204223558p:plain

 

カメラを奥行き方向に移動させて画角を広く取った場合(FoV値は変えない)

f:id:Karvan:20181204223630p:plain

 

FoV値を大きくして画角を広く取った場合(カメラの位置は移動しない)

f:id:Karvan:20181204223710p:plain

 

どちらも引いた画になりますが印象はずいぶん違ってきます。

 

実装してみた

FoV変動の実装は簡単でCamera.fieldOfViewの値をスクリプトで徐々に変えるだけです。今回はLerpを使って変化させてみます。

 

Camera.fieldOfView = Mathf.Lerp(Camera.fieldOfView, fov, Time.deltaTime * 2.0f);

 

第二引数のfovが最終的に変化させたいFoVの値です。
Lerpの第3引数にフレーム間の差分時間であるTime.deltaTimeを使い、目標値へ滑らかに変化するようにしています

 

上記の処理後に同じようにLerpを使って徐々に変化させながら元のFoV値へ戻します。
これで、一瞬大きく引いた画になったかと思うと、一気に元の画に戻る、という演出が行えます。

 

public class CameraController : MonoBehaviour 
{
    public float FoVTarget = 145;
    public float DefaultFoV;
    
    void Start () {
        m_Camera = GetComponentInChildren<Camera>();
        DefaultFoV = m_Camera.fieldOfView;
    }
    
    void LateUpdate()
    {
        ZoomControl();
    }

    /// <summary>
    /// ズーム処理
    /// </summary>
    void ZoomControl()
    {
        if (inZoom)
        {
            m_Camera.fieldOfView = Mathf.Lerp(m_Camera.fieldOfView, FoVTarget, Time.deltaTime * 2);
        }
        else
        {
            m_Camera.fieldOfView = Mathf.Lerp(m_Camera.fieldOfView, DefaultFoV, Time.deltaTime * 4);
        }
    }
    
    /// <summary>
    /// FoC変更
    /// </summary>
    void OnFoVChange()
    {
        StartCoroutine(DoZoomEffect(1.2f));
    }


    /// <summary>
    /// ズームエフェクト
    /// </summary>
    /// <returns></returns>
    IEnumerator DoZoomEffect(float duration)
    {
        inZoom = true;
        yield return new WaitForSeconds(duration);
        inZoom = false;
    }
}

  

で、ゲーム中の実際の動作はこんな感じになります。

 

 f:id:Karvan:20181204224653g:plain

 

実はFoVを元に戻すときに「PerlinNoise手ブレ」も動作しているのですが、サンプリングの関係なのか手ブレの効果については上のGIFでは良く分かりませんね。カメラが急にワープしたかのように見えるし。

 

「PerlinNoise手ブレ」については次回のブログで記事にしようと思います。

 

 

【Unity】複数のオブジェクトの色を一気に変える

三連休だった

スパイダーマンになってNYの平和を守ったと思ったら、次は核戦争後の荒野を彷徨う事になってオンラインゲームなのに他のプレイヤーと滅多に出会わないという斬新な世界を旅する三連休を過ごしたのですが、あまりに休日ニートが過ぎたのか、車の定期点検にディーラに持ち込んだら担当者に「走行距離が全然伸びていないので、ほとんど新車同然ですね(ニヤニヤ)」みたいな感じで、褒められているんだか貶されているんだか分からない言葉を浴びたりしたので少しは外に出ようと誓った秋の夜。

 

一気に色が変わる

さて、製作中の「Dull Things No Life」ですが、ゲーム自体は典型的なエンドレスランゲームなので、迫ってくる障害物を右に左に上に下に避けて進んでいくだけ、という単純な内容となっています。

 

なので他の類似アプリと違いをだす為にアレコレと演出を考えているわけですが、最近思いついた演出が「周りの背景や障害物の色が一気に変わる」というやつ、シューティングゲームなどで偶に見かける演出です。

 

周りの背景の色を変える、とはスカイボックスやプレイヤー機を囲んでいる壁のMaterialをスクリプトで変えるだけなので特に問題ないのですが、悩んだのは「障害物の色を変える」こと。
つまり、大量に動いているオブジェクトの色を一気に変えないといけない

 

オブジェクトの色を変える

「Dull Things No Life」では障害物として動いているオブジェクトのMaterialは全て同じものを使用するように作っています。
これは性能対策としてBatch数を減らすためです。

 

ただ、Unityではオブジェクトに対して

GetComponent<Renderer>().material.color = 色;

を行うことでオブジェクトの色を変更する事が出来ますが、これを行うと内部処理でオブジェクト毎にMaterialが一つ追加されます。つまりBatch数が増えるという意味で、これでは性能対策をした意味がなくなります。

 

Materialのcolorを変更したいけどBatch数は増やしたくない。

 

そんなことで悩んでいたのですが、毎度お世話になっているテラシュールブログに解決方法が記載されていました。

 

tsubakit1.hateblo.jp

SharedMaterialを使う

テラシュールブログによればRendererのsharedMaterialで共通Materialにアクセスすることができるようです。


つまり、同一Materialを参照しているオブジェクト全てに対して変更内容を適用できるということで、共通Materialを変更するので内部処理で新たにMaterialを追加することもありません

 

使い方はmaterialと同じように

GetComponent<Renderer>().sharedMaterial.color = 色;
とするだけです。めっちゃ楽。

 

早速、取り込んでみたらこんな感じなりました。
(sharedMaterialの変更と同時に、スカイボックスと壁のMatrialを変更しています)

 

f:id:Karvan:20181127235051g:plain

 

まぁ、ソコソコ面白い演出になっているのではないでしょうか。

 

【Unity】Animator付きのGameObjectの非アクティブ化について

強炭酸ブームらしい

どちらかといえば微炭酸な人生を歩んできた人間なので気づかなかったのですが、巷では強炭酸がブームらしいです。バカリズム似の作家センセイがそんなTweetをしていて知りました。調べてみると昨今のハイボール人気から炭酸の需要が拡大し、強炭酸水のブームにつながったようです。なんでもウィルキンソンは前年比22・1%増の販売量だとか。

 

そういえば最近は居酒屋には必ずハイボールやサワーのメニューはあるし、乾杯の一杯目でもビールではなくハイボールを頼む人が多いですしね、あ、でもビールも炭酸か、なんだ、根っから炭酸好きじゃん日本人。

 

新しい発見

そんな感じで新しい発見に出会えたり出会えなかったりする日常を過ごしているわけですが、Unity関連で最近発見したことといえば、前回のブログで取り上げた性能対策を行っていたときに直面した問題だったりします。

 

www.karvan1230.com

前回のブログではBatch数を削減すために『使用しないUIはCanvasごと非アクティブにする』対策を行ったのですが、この非アクティブにする前後でUIのアニメーションが変わってしまう不具合を発見

 

非アクティブ状態にする前のUIアニメーション

f:id:Karvan:20181120235302g:plain

 

非アクティブ状態からアクティブ状態に戻した後のUIアニメーション

f:id:Karvan:20181120235353g:plain

 

見て分かるようにアクティブ状態に戻した後だと、右側の四角が半分切れた状態で表示され、途中で表示される白線も上に移動しています。

 

UIアニメーションはUnity標準のAnimationを使用しているのですが、アクティブ状態の切り替えでこんな影響がでるとは想定外でした。

 

原因?

まったく原因がわからないので、エディタウィンドウに表示される右の四角の設定を通常時とおかしくなった後で比較して確認。
すると、PivotのY位置が通常時は0.5になっているのに、おかしくなった後では0になっていることを発見、
つまりアクティブ状態の切り替えによってこの設定が0になるらしい、んー。

 

f:id:Karvan:20181120235502p:plain

 

次にAnimationエディターで右の四角の動作を確認。
AnimationではPivotのX位置についての設定はあるものの、Y位置について設定は特に行っていません。

 

f:id:Karvan:20181121000631p:plain

 

つまりAnimationではPivotのY位置は動かしていない。

 

f:id:Karvan:20181120235919p:plain

PivotのY位置が変わっているのにAnimationにはY位置の設定はない・・・

 

f:id:Karvan:20181120235938p:plain

だけどAnimationを動作させるとPivotのY位置が0になる・・・
それもアクティブ状態を切り替えた後にだけ・・・

 

f:id:Karvan:20181120235957p:plainわからん!!

 

当初はまったくお手上げでした。

 

たぶん、たぶん、きっと

で、改めてAnimationエディターで設定を確認。

 

f:id:Karvan:20181121000042p:plain

 

PivotのY位置について『DefaultValue』の記述があります。

『Default』ってことは初期位置(=0.5)だと思ったのですが、もしかするとアクティブ状態の切り替えによって『Default』値が変わっているのかもしれない・・・

 

そう思って、PivotのY位置について0.5となるように設定を追加すると・・・

 

f:id:Karvan:20181120235302g:plain

 

ちゃんと動いたー

こんな簡単なことで一日潰れたりする・・・

 

類似記事の紹介

ここら辺の話をよくよく調べてみると毎度お世話になっているテラシュールブログにて似たような記事がありました。

 

tsubakit1.hateblo.jp

つまり、Animatorを含むGameObjectの非アクティブ化はできるだけ避けたほうが良い、という事みたいです。

 

ん~、とは言ってもなぁ・・・

 

 

 

【Unity】使われないuGUIはCanvasごと非アクティブにした方が良い?

腰痛い

基本的に休日ニートな人間なので、休みの日は部屋に閉じこもることが多いのですが、先日は地元でADAM atのライブがあったので重たい腰を上げて参戦してきました。

 

www.jvcmusic.co.jp

ADAM atはピアノ・インストゥルメンタル・ユニットでCDショップなどではジャズ系に分類されることが多いのですが、ジャズスウィングの横ノリというよりはロックな縦ノリ曲が中心で、ライブではヘドバンするような曲も演奏されます。その所為かMCでは『ジャズなのにジャズ系のフェスに呼ばれない』とぼやいてました(笑)

 

実は、現在製作中の「Dull Things No Life」はADAM atの「共鳴ディストラクション」という曲を聴いた時のイメージがベースになっています。ゲーム画面のデザイン中はずっと聴いてたし。

 

なので、早々にチケット取りウキウキしながら参戦してきたのですが、結果腰が痛い。

なにせ前述のように激しい曲が中心で、ライブ中はほぼずっと飛び跳ねていたので、そりゃ腰を痛めるわ、って感じ。座っても立っても腰が痛い。

 

まぁ、ライブが楽しかったからいいけど

 

性能対策に頭が痛い

そんな感じで痛めた体を庇いながらもゲーム製作は進んでいくのですが、前々回の記事で報告したメニューウィンドウを実際のゲームSceneに取り込んでみたら、実機での動作がまたモッタリするような感じに何度目だ。

 

スマホ向けゲームを作るうえでは避けて通れない性能対策に頭を痛めながらStatisticsを確認すると、確かにBatch数が常時130オーバーな状態になっている。んー、これはいかん。

 

f:id:Karvan:20181113211319p:plain

 

メニューウィンドウを追加する前だとBatch数は100を切っていたので、これは明らかに追加したメニューウィンドウの所為だと分かります。


まぁ確かに、実行前のゲーム画面はこんな感じでゴチャゴチャしているし、起動後はマスクによって非表示状態になっているだけなので、いくら見えないとはいってもBatch数は軽減されないのかもしれない。

 

f:id:Karvan:20181113211421p:plain

(テキスト部分は分かりやすいように文字を入れています)

 

uGUIに関する性能対策

uGUI周りの性能対策について広く知られているのは

  • SpriteをAtras化する
  • 動くUIと動かないUIでCanvasを分ける

等があります。詳しくは下記リンクを参照してください

 

siguma-sig.hatenablog.com

「Dull Things No Life」でも同様の対策を行っていて、Canvasも通常(動かない)UI、メニュー系UI、メッセージ系UI、トランジッション系UIで別々のCanvasに分けています。

Canvasが増える分、SetPassが増える=Batch数が増える、ことは覚悟していたのですがここまで増えるとは予想外でした。

 

とはいえ、今更同じCanvasに纏めるのは馬鹿らしいし、違うところで負荷が増えることになるので対策にはならない。
なので試しに、マスクによって非表示状態になっている時はCanvasごと非アクティブにしてみようと思ったわけです。

 

で、結果として・・・

f:id:Karvan:20181113211833p:plain

おお、見事にBatch数が減っている!

 

んー・・・使われないGUIはCanvasごと非アクティブにしたほうが性能的にはいいのかな?

 

 

 

 

 

 

 

・・・とか思ったのですが、ここでまた別の問題が発生、はぁー、頭痛い・・・詳細は次回の記事で

 

 

◇プライバシーポリシー

●個人情報の利用目的

当ブログでは、メールでのお問い合わせ、メールマガジンへの登録などの際に、名前(ハンドルネーム)、メールアドレス等の個人情報をご登録いただく場合がございます。

これらの個人情報は質問に対する回答や必要な情報を電子メールなどをでご連絡する場合に利用させていただくものであり、個人情報をご提供いただく際の目的以外では利用いたしません。

●個人情報の第三者への開示

当サイトでは、個人情報は適切に管理し、以下に該当する場合を除いて第三者に開示することはありません。

・本人のご了解がある場合
・法令等への協力のため、開示が必要となる場合

個人情報の開示、訂正、追加、削除、利用停止
ご本人からの個人データの開示、訂正、追加、削除、利用停止のご希望の場合には、ご本人であることを確認させていただいた上、速やかに対応させていただきます。

アクセス解析ツールについて

当サイトでは、Googleによるアクセス解析ツール「Googleアナリティクス」を利用しています。

このGoogleアナリティクスはトラフィックデータの収集のためにCookieを使用しています。このトラフィックデータは匿名で収集されており、個人を特定するものではありません。
この機能はCookieを無効にすることで収集を拒否することが出来ますので、お使いのブラウザの設定をご確認ください。

●免責事項

当サイトからリンクやバナーなどによって他のサイトに移動された場合、移動先サイトで提供される情報、サービス等について一切の責任を負いません。

当サイトのコンテンツ・情報につきまして、可能な限り正確な情報を掲載するよう努めておりますが、誤情報が入り込んだり、情報が古くなっていることもございます。

当サイトに掲載された内容によって生じた損害等の一切の責任を負いかねますのでご了承ください。

●プライバシーポリシーの変更について

当サイトは、個人情報に関して適用される日本の法令を遵守するとともに、本ポリシーの内容を適宜見直しその改善に努めます。

修正された最新のプライバシーポリシーは常に本ページにて開示されます。