2025 年 5 月 4 日 | カテゴリー: Near The Sun, 製作について

15期のドッグウッドと申します。

制作記第6回、今回は「Near The Sun」の体力ゲージについて話します。

「Near The Sun」は2Dステルスアクションです。
敵の視界に入るとステルスモードに入り、敵から姿が見えなくなります。
しかし、ステルスモードはエネルギーを消費します。
エネルギーが全てなくなってしまうとステルスモードが維持できなくなり、敵に見つかってしまいます。

つまり、「残りエネルギー」はHPです。
また、エネルギーを消費して回避兼攻撃のダッシュを行うため、エネルギー残量の管理はとても重要です。

さて、この重要なエネルギー残量、どのようなUIで表現するかとても迷いました。工夫したことをいくつかあげます。

1.主人公に重ねて表示されるUI
アクションゲームを遊んでいて、「キャラを動かすのに必死で、左上の体力ゲージを確認できない!」となったことはありませんか?
このゲームでは主人公があちこちに飛び回ります。左上のHPゲージを確認している暇などありません。
そこで、エネルギーゲージは主人公に重ねて表示することにしました。
また、エネルギーの残量割合は満タンの時に確認する必要はありません。そのため、エネルギーが満タンの時はUIを表示しないようにしました。UIが表示されていると、せっかくの主人公のアニメーションも見えなくなってしまいますしね。

2.円形のゲージ
HPゲージは直線系のUIが多い印象があります。しかし今回は主人公に重ねて表現するため、直線のUIだと左右に大きくはみ出してしまう可能性がありました。
そのため、円形のUIを採用しました。
円形のUIのデメリットは、エネルギー最大値の上昇を表現しにくいことです。
UIを重ねて2周分表示させるとか、横に並べるなどをしなければ最大値の増加が表現できませんが、直感性が失われます。
今回は主人公のレベルアップが段階的であって線形でないこと、最大値の細かい上昇を表現する価値が薄いため、デメリットがそこまで致命的でないことから円形のゲージを採用しました。

3.非線形なゲージの減少
実は残りエネルギーが30%になっても円形ゲージの表示は残り30%のようには表示されません。残り100%→90%の時の方が10%→0%よりも減るゲージの面積が大きいです。
これにより、ゲージの表示がギリギリになりやすくなり、プレイヤーに緊張感、敵に見つかった時の失敗感、ギリギリ視界から抜けることができた時の安心感を強く与えることができます。
本当に細かい数値が大きな意味を持つカードゲームなどではこの表現は許されないと思いますが、このゲームのUIは大雑把な円形UIで瞬間的にゲージが減少するため、最適な表現となっています。

また、残りダッシュ可能回数を右側に分離したことも工夫した点です。これによりある程度自由なUIデザインをすることが可能になりました。

ちなみに、形はシェーダーグラフで作成、imageではなくspriteでUIのレイヤーに表示しています。そのため、imageのfillAmountは使っていません。
offsetをアニメーションさせてタイトルの背景にも使っています。

polar coordinateを利用している
タイトルの背景に使用

さて、ここまでUIについて話してきました。
プレイヤーに重ねる円形UI、たまたま本作ではハマりましたが、かなりデメリットが大きいため、改めて考えると他の作品であまり使われてない理由がよくわかりますね。

次回は簡単そうに見えて奥が深い、壁ジャンプの実装について話そうと思います。
ではこの辺で。

2025 年 4 月 27 日 | カテゴリー: Near The Sun, 製作について

15期のドッグウッドと申します。


制作記第5回、今回はシェーダーグラフの勉強について、初期にやったことをまとめます。
僕自身、完全にシェーダーグラフを理解しているわけではないのですが……これからシェーダーグラフについて勉強を始めたいと思っている人には役立つのではないでしょうか。

まず、シェーダーグラフとはUnityの機能の一つで、シェーダーをノードで作成することができます。

ノードベース!

シェーダーはゲームの物体がどのように描画されるかを決める計算方式です。
例えば、あるテクスチャの不透明度をn倍して描画する!みたいな感じですね。

通常、シェーダーを書くにはhlslなどの言語を学ぶ必要があります。
しかし、シェーダーグラフを使えばコードが書けなくてもシェーダーを作ることができます!
僕はプログラマーなので、コードが書けないわけではないのです。しかし、シェーダーのコードは書くための「約束事」が多いので、たまにしかシェーダーを書かない僕は毎回書き方を一から調べることになります。その手間を短縮してくれるシェーダーグラフは本当にありがたいです。

シェーダーを作ることができると、いろいろなエフェクトや光に対するシーンの構成が簡単にできるようになります!

さて、前置きが長くなりました。シェーダーグラフを学ぶためにやったこと、まず最初は「発光するオブジェクト」の作り方を調べたことでした。
これは調べればいくらでも記事が出てきます。
シェーダーグラフは「技術を向上させる」、というよりは「何ができて、何ができないかを知る」というタイプの勉強です。高速化とかを考え始めるとまた変わってくるのでしょうが……。
なのでおすすめなのは、とりあえず使えそうなシェーダーを5個ほど作ってみることです。
おすすめは
・ディゾルブ UIや消滅表現に汎用的に使えて、ノードの構成が簡単
・アウトライン UVの概念を学ぶのに適している
・汎用シェーダー エミッションマップ、加算、乗算、透明度について自由に値を設定できるシェーダーです。めちゃくちゃ便利。
・炎 外部に露出させる設定項目の割り切り方が学べます。
・ぼかし シェーダーグラフが苦手な「隣り合ったピクセルの値の取得」ができるようになります。

シェーダーグラフを学ぶと思った通りのエフェクトが出せるようになるのが一番大きいです。シェーダーグラフについて、いつくかシェーダーを作成した後次の本でエフェクトとシェーダーについて学びました。

Unity ゲームエフェクトマスターガイド

少し前のバージョンでの解説ですが、問題なく学習することができます。
また、次のサイトも参考になります。

https://zenn.dev/r_ngtm/books/shadergraph-cookbook

ありがたいですね。
あとは、UnityJapan公式が出している次の動画がとてもわかりやすいです。

https://www.youtube.com/watch?v=3TXHMS8xFJ0

このあたりを一通り終わらせたらシェーダーグラフ中級者なんじゃないでしょうか。売られているシェーダーの本を見て、「この本に載ってるエフェクト、全部作れるな……」とほくそ笑むことができるようになります。

ぜひシェーダーグラフを勉強してエフェクトもりもりなゲームを作りましょう!

エフェクトもりもり

次回は残り体力ゲージについて話そうと思います。
ではこの辺で。

2025 年 4 月 20 日 | カテゴリー: Near The Sun, 製作について

15期のドッグウッドと申します。

制作記第4回、今回は視界の実装方法についてです。

「Near The Sun」は2Dステルスアクションです。
ロボットの視界に入ると、主人公はステルスモードに入ります。
ステルスモードに入っている間は敵に見つからないのですが、ステルスモードの間はエネルギーを継続的に消費します。
エネルギーが0になるとステルスモードが切れてしまい、敵に見つかってしまいます。
敵に見つかるとチェックポイントから再スタートになります。

敵の視界が通常のアクションでいう「敵の攻撃」に当たるため、敵の視界はゲーム内で明示する必要があります。

さて、ここで「視界が地形に遮られるにはどうしたらよいか?」という課題がでてきます。

「敵の視界が地形に遮られる形」を明示する必要がなければ、扇形の画像を張り付けて動かすだけで済みます。
プレイヤーが敵から見えているかどうかは、敵の目の位置からプレイヤーへRay(当たり判定を判別するレーザーのようなもの)を飛ばして、地形に遮られているかを判断すればよいです。
この処理の場合、ざっくりと敵の視界の範囲に当たり判定をつけておいて、プレイヤーが当たり判定の中にいるときにRayを飛ばせばいいので、計算負荷は大したことがありません。


しかし、今回は視界の範囲を表示する必要があります。
視界の範囲を表示するためには、地形と視点の位置を把握し、扇形の形状を毎フレーム計算する必要があります。
また、プレイヤーが敵の視界の中にいない時も計算をする必要があるため、なるべく計算負荷を抑える必要があります。

まず、最初に言っておきます。この問題の綺麗な解法を思いつくことはできませんでした。
思いついたのは3つ。一つは、地形を完全にグリッド状に配置することで、Rayなどを使用せずに、視点と地形から扇形の形を計算する方法。もう一つは、視点にLight2Dを置いて、地形にShadowCasterを配置し、光の強さを透明度に変換する方法。最後に、視点から扇状にRayを複数飛ばし、Rayがヒットした場所を繋いで扇形を作る方法。

光の強さを透明度に変換
Rayをたくさん飛ばす


結論から言うと、3つ目のRayを飛ばしまくる方法を採用しました。
一つ目の案では、地形を作る方法に制限を持たせることになります。細くて降りることができる足場などに対応ができなくなります。二つ目の案では、単純に当時その技術がなく、また、地形にShadowCasterを配置するのが手間です。

そのため、計算負荷を許容して3つ目のRayを飛ばす方法を採用しました。
こちらの動画を参考に実装をしました。

https://www.youtube.com/watch?v=73Dc5JTCmKI


プレイヤーが近くにいないときは視界の計算をしない、地形と干渉しない視界は扇形の画像にする、近くに複数の遮られる視界を複数置かないなどの対策で計算処理の頻度そのものを減らしています。

もっと軽い処理で実現できる方法はないものか……。
もしご存じでしたら教えて欲しいです。

今回の実装は2023年2月ごろに行いました。

扇形の視界の表示方法についてもちょっと工夫していることがあるので、いつか記事にしたいですね。

次回はシェーダーの学び始め方(初期にやったこと)をまとめようかと思います。

2025 年 4 月 13 日 | カテゴリー: Near The Sun, 製作について

15期のドッグウッドと申します。

制作記第3回、今回はgitでやらかした話とエディタ拡張についてです。

gitというプロジェクトの管理方式をご存じでしょうか。
ファイルそのものだけでなく、その差分履歴を保存する管理方式です。
サーバーにプロジェクトデータをあげてgitで管理することで、複数人での作業を簡単に行うことができます。
このgitという方式、僕はゲームを作り始めるまで知りませんでした。

「Near The Sun」ではgitでunityのプロジェクトを管理しています。
unityのプロジェクトフォルダには最上階層に「Assets」「Library」「Logs」「obj」「Packages」「ProjectSettings」「Temp」「UserSettings」という8つのフォルダが存在します。
この中で共有するべきフォルダは「Assets」「ProjectSettings」「Packages」の3つで、それ以外のフォルダは個々人のPCで内容が変わるため、共有すべきではありません。

が、ゲームを作り始めた当時そんなことは全く知りませんでした。
単なるクラウドと同じに思っていたため、プロジェクト内のすべてのファイルをサーバーにアップロードしていました。
その結果、毎度毎度Libraryフォルダ内のファイルが大量にアップロードされることに……。

これが間違いと気づいたのが2022年の12月。
やっと指定したフォルダをgit管理しない「.gitignore」ファイルの存在を知り、プロジェクトに追加。しかしうまくgit管理を外せず、以下のサイトを参考にキャッシュを消すことで、どうにか希望のフォルダのみをgit管理できました。
https://qiita.com/kohei_wd/items/f1d224c9257d1e242b58

ゲーム開発の落とし穴をすべて踏み抜いていますね。
2023年の8月にプログラマが一人プロジェクトに参加してくれることになるのですが、それより前に気づいて本当に良かった……。(実は今もUserSettingsのフォルダは管理対象から外れていません。どうにかしないといけないんだけどね……)

次はエディタ拡張について。
超基本システムの実装が終わった12月、「ステップアップUnity」という本を読んでエディタ拡張に興味を持ちます。

「ステップアップUnity」

学んだことはとりあえず実践で生かす方針なので、ストーリー管理用のウインドウを作成することにしました。

完成形

「Near The Sun」のストーリー部分の管理方式は以下のようにになっています。
1.テキスト本体、話者、画像、背景のトランジションなどはcsvファイルで管理
2.何行目で音を鳴らすか、話者以外の画像を出すか、暗転させるかはスクリプタブルオブジェクトで管理
3.csvファイルとスクリプタブルオブジェクトからダイアログ管理用のオブジェクトに情報を流し込む
4. ダイアログ管理用のオブジェクトが文字を一文字ずつ出して入力待ち、話者画像の入れ替え

このウインドウでは2と3の部分を担当しています。なんと、csvファイルのパスを入れ、何行目にどんなアクションを起こすかを設定して「GenerateStoryManager」ボタンを押せば、スクリプタブルオブジェクトに情報が保存され、ダイアログ管理用のオブジェクトに情報を流し込むスクリプトが生成されます!
ゲームを作り始めて1年未満でこの仕組みを作ったのはえらい!

……はい、今はもうあまり使ってないです。
この方式で一部のストーリーができてしまっているため、形式的に使ってはいます。しかし、何行目に何を起こすかはインスペクター上でのコールバックチェーンにより実現してます。だってその方が楽だから。
それに、スクリプトの自動生成は間違っていた時に直すのが面倒くさすぎて……。もっと単純なレベルでの自動生成をすべきでしたね。めちゃくちゃなコードが1000行以上続いているのでもう見たくもないし、新しい機能を追加したくもありません。
まあ、コールバックチェーンもあまり複雑なことをするのは向いてなさそうですが……みなさんこの辺りどうやってるんですか!!!???

力技

まあ、そもそもどんなイベントを実装するかわからない状態でイベントの管理プログラムなんて組めるわけないので、割とよくやったんじゃないでしょうか。
手順が面倒くさいだけで、少なくともどんなイベントでも対応可能なシステムではありますし。

最近はずんずんイベントを作っているので、だんだんとイベントシーンを作るペースが上がってきました。エディタ拡張は楽しいので、次回作はさらに最適化されたシステムを作りたいですね。できればあと一生使える財産になるものを……。

ではまた。次は

2025 年 4 月 8 日 | カテゴリー: ニュース

今年も新歓の季節がやってきました!

4/8(火) 20時~ 第1回新歓説明会

@オンライン(Zoom)

オンラインでサークルの話を聞けます。カメラもマイクも必要ないので、気軽に参加してください!

4/12(土) 20時~ 第2回新歓説明会

@オンライン(Zoom)

1回目と同様に、サークルについて説明します。

4/18頃(日程調整中) ゲーム制作体験会

@場所調整中

ゲーム制作の体験活動ができます。初心者でも楽しんで取り組めます!

4/25(金) 19時~  新入生プロジェクト発足、ミーティング

@場所調整中

入部手続きの後、新入生のみなさんで新しくゲーム開発プロジェクトを結成します。

今後も随時、新歓情報を掲載予定です!
活動や入部、その他について質問があれば
新歓用メールアドレス:nonlinearshinkan2025@gmail.comまでどうぞ!

2025 年 4 月 6 日 | カテゴリー: Near The Sun, 製作について

15期のドッグウッドと申します。
今回は基本システム実装の話です。

基本システム実装は、ゲーム製作、特に初心者にとって最も難しい段階だと思います。
自分ができることも、これからできるようになることも曖昧なまま、それでも拡張性の高いコードを書かないといけないのですから……。
下手なコードを書けば将来どうしようもなくなる、スパゲッティコードになるぞと脅されますが、それでも作り始めなければモノは完成しません。

主人公の動作制御については割とまともなものが書けた……気がします。開発から2年半経ちましたが、一応まだ動いているので。
ステートの遷移と実際の移動を別ファイルに分ける、や主人公の動作をステートとアクションに分けて考える……などの設計はうまくいったのですが、今でも正解がわかりません。誰か答えを教えてほしい。

うまくいかなかったこととしては、主人公を1フレームごとに定数値で動かしていたとか、RigidbodyのAddForceでキャラを移動させていて動作が安定しないとか……初心者あるあるのミスはほとんど踏み抜いた気がします。
UIをステージ作成機能で組んでしまったせいで、解像度の変更に対応できなくなるという問題もありましたね。

当時のステージの様子

そんなこんなで試行錯誤を繰り返しながらも、2022年12月には、主人公の挙動、敵からのダメージ処理、会話システム、アイテムによるレベルアップなどが形になってきました。

そして、2022年の大晦日。除夜の鐘を聞きながらバックログと格闘していると、ふと気づきました。
制作開始からすでに4か月が経過しているのに、ストーリーはほぼ未着手。考えているのはトゥルーエンドの結末だけ。
敵の動きもほとんど実装できていない。グラフィックは仮素材のまま、音は一切入っていない……。



あれ、これっていつ完成するんだろう……。

2025 年 4 月 5 日 | カテゴリー: 中の人の戯言

ノンリニア16期のu.s.です。

ここには、私がUnity/C#のシェーダーを扱っている中で起きた問題と、それに対する自分なりの解決策を、備忘録としてまとめておきます。

状況1
「シェーダーのプロパティを Material.SetInteger や Material.SetFloat から変更したけど、変更が見た目に反映されてない!」

もしかしてそのプロパティ、Toggleとして扱ってる?

Toggleの場合、大抵プリプロセッサを用いた描画の条件分岐を行う。
例えば、”_AlphaSquare” というToggleプロパティを定義した場合、ToggleがONのときに “_ALPHASQUARE_ON” というキーワードが定義される:

Properties {
	[Toggle] _AlphaSquare ("Alpha Square", Float) = 0
}

として

#pragma shader_feature _ALPHASQUARE_ON

fixed4 frag(v2f IN) : SV_Target
{
	fixed4 c = SampleSpriteTexture(IN.texcoord) * IN.color;

	#ifdef _ALPHASQUARE_ON
	c.rgb *= (c.a * c.a);
	#else
	c.rgb *= c.a;
	#endif
	
	return c;
}

という感じで書くと、シェーダーのインスペクターにおける “Alpha Square” という名のToggleのON/OFFに応じて処理を分岐させることができる。

ところで、このプリプロセッサによる分岐は、動的ではなく静的なものである。

#ifdef … #else … #endif による分岐を仕組むと、コンパイル時に各分岐に対応するシェーダーが作成され、キーワードの有無に応じて分岐がなされるようになる。

つまり、キーワードによる分岐のパターン数だけシェーダーを出力し、ランタイムではそれらをキーワードの定義状況によって切り替える、というのを行っているっぽい。

インスペクターにおけるToggleのON/OFFは、キーワードの有効/無効が伴うみたいだが、Material.SetXxxx からToggleプロパティの値そのものを変更しても、ランタイムにおける対応するキーワードの有無には関わらない。

この場合に、ToggleのON/OFF切り替えと同じ効果をスクリプトから得たい場合は、Material.EnableKeyword / Material.DisableKeyword を用いて直接キーワードをいじることになる。

さっきの例だとこんな感じ。

[SerializeField]
private Renderer _renderer;

public void AlphaSquare(bool b)
{
    if (b)
    {
        _renderer.material.EnableKeyword("_ALPHASQUARE_ON");
    }
    else
    {
        _renderer.material.DisableKeyword("_ALPHASQUARE_ON");
    }
}

これだと何をしてるのかよく分からない!という場合は、そもそもプリプロセッサを使わずに動的なif文でシェーダーを記述すれば、従来の Material.SetXxxx を用いた描画処理の分岐もできそう。 (動的な分岐はパフォーマンスの観点から避けるべきと聞くが…実際どうなのでしょう?)

参考文献:
@up-hash. “「Shaderでif文を使ったら遅い」は正しくない🧐”. 2023-12-20.
https://qiita.com/up-hash/items/e932ccae110d687e225f

状況2
「エディターでは問題なく動いてたのに、ビルドしたら、シェーダーの効果がなくなってしまった!」

Unityでは、使われていない(と思われる)シェーダーはビルドから省かれるようになっているらしい。

このため、そのタイプのマテリアルを少なくとも一つ、アセットに用意して、 Unity にそのシェーダーバリアントを使う事を明示する必要があります。そのマテリアルは シーンで使われていなくてはなりません 。もしくは、 ランタイム時にリソースを読み込んで おくという方法もあります。そうしないと Unity からは、まだ使っていないように見えるため、ビルドから除外されてしまいます。

Unity Technologies. ” マテリアルパラメーターへのスクリプトを使ったアクセスと変更 – Unity マニュアル “. 2024-02-10. https://docs.unity3d.com/ja/2018.4/Manual/MaterialsAccessingViaScript.html

そのシェーダーをアタッチしたマテリアルがシーン上に1つでも存在すれば、それをビルドでも使うということを明示したことになるので、問題なく動作する。

しかし、例えばシーンロード後にInstantiateするプレハブのマテリアルに使っているものなど、最初からシーン上に存在しないようなシェーダーは、ビルド時に「使わない」と判断されてしまうらしい…

これを防ぐために、次のようなことを考えた。

私が使っている UnityEditor のバージョン 2022.3.23f1 には、Project Settings > Graphics に “Always Included Shaders” という項目がある。

早い話が、ビルド時に省略されたくないシェーダーをここにセットすれば、それらを全てビルド時に必ず含めてくれるようになる。

他にも対処法はあるかもしれないが、おそらくこれが一番手っ取り早くて分かりやすい方法なんじゃないかな?と思う。

ということで、もしビルド時のシェーダーの挙動がおかしいぞ?となった場合は、それがビルドから除外される対象になってないか確認し、上記の設定などを介して、除外を免れられるようにしてあげると解決するかも。

2025 年 3 月 30 日 | カテゴリー: Near The Sun, 製作について

初めまして。15期のドッグウッドです。

現在、僕は「Near The Sun」というゲームを開発しています。
タイトルの開発を始めてから、すでに2年半が経過しました。

時間が経つにつれ、記憶は薄れていきます。
悲しいので、制作記という形で記録に残しておこうと思いました。
いささか手遅れ感がありますが、忘れたことが多ければ残っているものも多いです。
書く内容を貯めていたのだ、と考えることにします。

この製作記では「Near The Sun」 の開発に関する出来事を時系列順に書いていく予定です。
過去の回想から始まり、徐々に現在の状況へと追いついていきます。
僕はゲームプランニング、シナリオ、グラフィック、プログラム、SEを担当しているため、技術的なこと、考えたこと、学習したことについて幅広く書き残していけたらと思っています。
ただし、どの分野に関してもほぼ一からの学習をしている上、今も勉強中です。そのため、間違ったことを書くかもしれません。裏取りをきちんとして書くぞ!という記事でもありませんので……。

あくまでも、「ゲーム開発初心者が2年半にわたって格闘してきた記録」、そして「これからも格闘し続ける様子」を書いたものとしてお楽しみいただければ幸いです。

2025 年 3 月 30 日 | カテゴリー: Near The Sun, 製作について

初めまして。15期のドッグウッドです。
まずは「Near The Sun」のプロジェクト承認までの話をしたいと思います。

「Near The Sun」は2022年の8月25日にプロジェクトが承認され、Unityで開発が開始されました。

私がUnityに初めて触ったのは2022年の1月頃で、「作って学べるUnity本格入門」という本で2か月ほどかけて学習をしました。その後ノンリニアに入部し、新入生プロジェクトというものに参加して3か月でゲームを一本完成させました。チームは5人、私はグラフィッカー兼プロジェクトリーダーとしての参加でした。

そう、「Near The Sun」を企画したときはまだUnityを触って半年、プログラミングに関してもクラスや構造体などの用語も全然わからない初心者でした。
イラストに関しても同様です。

そんな状況でしたが、当時の私は怖いもの知らずだったので企画を立てました。
足りない技術は学習すればいいだけ、できないことなどなにもないですからね。
企画時のタイトルは「CrackedSky」でした。

企画書に載せたコンセプトアート
今のスクリーンショット

「コンセプトアート」なんて言葉も知らない時期に描いたコンセプトアートです。キャラと世界観は今も残っていますね。

コンセプトアートは割とまとも……でしたが、企画書はひどいものでした。
28ページあって、アクションに関するスライドは次の一枚のみ!!


……こんなひどい企画書書いたっけ……?
防衛機制が働いて忘れていました。

残りのページはほとんどが世界観・ストーリー説明でした。
しかも開発期間は半年。
100人の開発者に見せたら100人が「途中でポシャる企画」と言うでしょうね。

しかし、弊サークルはゆるいのでプロジェクトは承認されました。
当時から既に有能だった同期からツッコミを入れてもらいましたが、余り深く考えずに「まあなんとかなるだろ」の精神でUnityのプロジェクトを作成しました。
ちょうどサークルに復帰した音屋の先輩と2人で開発を始めることになります。

う~ん、既に雲行きが怪しい……。
一体どうなってしまうのでしょうか。#2に続きます。

2024 年 4 月 15 日 | カテゴリー: イベント参加情報

皆さんこんにちは。ドッグウッドと申します。

タイトルにもある通り、この度ノンリニアとして東京ゲームダンジョン5に出展することが決まりました。

東京ゲームダンジョン5

展示される作品は2Dアクションノベル「Near The Sun」です。

前に開発記事を書きました

当日参加するメンバーは展示会参加が初なので、緊張中……

試遊ができますので、ぜひ足を運んでください。