わがままアリスと百日戦争 制作手記 グラフィック編 ~その3

この記事はフリーゲーム「わがままアリスと百日戦争」の制作秘話をだらだらと書いたものです。
・ネタバレ上等
・ゲーム遊んだよ!
という方向けの内容なので、その点をご承知ください。

はじめに

わがままアリスと百日戦争 制作手記 グラフィック編
第三回の今回は、背景について取り上げようと思います。

戦闘背景

背景をかけるイラストレーターは探してもなかなか見つからないものです。
特に同人ゲームなんかでやっていると、身の回りに背景をかけるなんて人は皆無でした。

しかし、背景はゲームの世界観を語る重要な要素です。
背景だけ他と比べてクオリティを下げるわけには行きませんでした。

幸いチームには、3Dアーティストがいたので、
今回は背景を3Dでやることにしました。

戦闘背景の作業工程

ディレクターがイメージボードを描く

f:id:chicchi0531:20171019000555j:plain
こんなかんじのスケッチを3Dアーティストに渡して、これをもとに作ってもらいます。
戦闘領域を考えるのと、奥行きが感じられるとか、ポリゴン数を考慮したデザインにするとか、
色々考えながらやります。

3Dアーティストがモデリングとテクスチャリングを行う

f:id:chicchi0531:20171019000929p:plain
渡したスケッチをもとに、mayaでアーティストがモデルとテクスチャを作ってくれます。
基本的にmaya上でステージごと作ってしまいます。
ただし、場合によっては、Unityに移してからTerrainを追加してもらったりすることもあります。

上がってきたモデルをライティングする

上がってきたアセットをディレクターが受け取り、unity上でライティングを行います。
この時に、パーティクルなどの動的演出や、テクスチャスクロールによる水面の演出など、エンジニア的な部分も一緒にやってしまいます。

f:id:chicchi0531:20171019001413p:plain
ライトを置いただけの状態(GIはONにしてあります)

f:id:chicchi0531:20171019001452p:plain
ReflectionProbeを配置して、室内のGIを補完

f:id:chicchi0531:20171019001559p:plain
最後にポストエフェクトをかけて完成

戦闘画面の負荷もこの時に測定し、推奨スペックで30fpsが保てるようにします。

背景指定と、完成背景コレクション

オリヴィアの家

毒の沼

2D背景

3D背景では雰囲気に合わない場面があります。
UIメニューで出てくる背景や、タイトル画面に使われる背景です。

そういったものは2Dで用意しました。
2D背景は描くのに時間がかかるので、要所要所にしか用意しませんでした。

タイトル画面

f:id:chicchi0531:20171019004406p:plain

町背景

f:id:chicchi0531:20171019004512p:plain

フィールドマップ

そういえばフィールドマップも2Dでした。
今思えばフィールドは3Dの方が広くできるし、見栄え良かったかもわかりません。
f:id:chicchi0531:20171019010504p:plain

おわりに

今回は背景の制作過程を紹介しました。
背景は世界を形作る、ある意味キャラクターよりも大切なものです。
もっともっと高品質な背景の制作を目指したいものです。

次回は戦闘のドットとエフェクトについて取り上げたいと思います。
見ていただいてありがとうございました。

わがままアリスと百日戦争 制作手記 グラフィック編 ~その2

この記事はフリーゲーム「わがままアリスと百日戦争」の制作秘話をだらだらと書いたものです。
・ネタバレ上等
・ゲーム遊んだよ!
という方向けの内容なので、その点をご承知ください。

はじめに

わがままアリスと百日戦争 制作手記 グラフィック編
第二回の今回は、キャラクタービジュアルについて取り上げようと思います。

※キャラデの勉強とかで見るのはお勧めしません。
プロの方のを見ましょう。

キャラクターデザイン

キャラクターデザインは、シナリオチームでキャラ設定をごりごり固めてから始めました。
ただし、主人公のアリスだけは最初からイメージがあったので、ほとんど変わらずでした。
(絵柄が変わりすぎで……)

・アリスの一番最初のデザイン

f:id:chicchi0531:20171016181236j:plain

チームメンバーの顔合わせ時に持って行った、アリスのイメージ画像です。
この段階でほぼ今のアリスと変わりません。

・最終デザイン

f:id:chicchi0531:20171016183413p:plain

アリスはともかくとして、他のキャラクターのキャラデで気を付けたことは、

・キャラクターのイメージカラーを、学園物のギャルゲーとか、漫画とかよりも強く出すこと

・デフォルメしてもわかりやすいシルエットや、特徴的なアイテムを持たせること

です。割と普通ですか、そうですか……。
ただ、このポイントはゲームの仕様も影響しています。

わが百では、バトルシーンで、キャラクターのドット絵が演出スペースに出てくるので、
ドット絵にしてもつぶれてしまわないデザインをする必要がありました。

幸い、ファンタジーという世界観だったので、髪の色変え放題、ヘンテコなファッションし放題、でやることができました。
学園物だったらネタ切れしてそうです。
プロの方はすごい……。

シナリオメンバーの方で、キャラクターの称号や、領地の特徴、季節を決めていたので、キャラではそれに雰囲気を合わせるようにデザインしました。
例えば、アリス領は童話のキャラから命名したので、王道ファンタジーな服。
シャルロッテ領は、没落貴族のイメージと、黄金の魔女という称号から、黄色系統で、装飾多めなデザイン。
トリアイナ・オリヴィア領は、冬と春、という季節イメージだったので、
もったりした王道ファンタジーから少しずれた、ちょいモダンっぽいデザインになっています。

立ち絵の制作

立ち絵を描いたキャラクターは、結局36体(パンプキングミニ合わせれば39体)になりました。
最終的な数を見るとすごい多いですね……。
しかし、実際はこれと同じくらいの量を没にしています。
絵柄をリニューアルしたり、顔が気に入らなくて微修正したキャラもいます。
アリスなんかは3回くらい描きなおしてます。

環境に悪い開発だ……。

最終的には期日が迫ってきたので、1日1枚ペースでひいひい描いていました。つかれた。

以下、修正前キャラ特集

・初期アリス、2代目アリス、3代目アリス、4代目アリス、最終デザインアリス

f:id:chicchi0531:20171016224909p:plain

描きなおしすぎ! アリスは立ち絵の指標で描いたキャラだったので、没枚数も多いです。
同時にキャラでもだんだん変更されてますね。

・初期デザインのニアちゃん

f:id:chicchi0531:20171016183901p:plain

結構気に入ってたけど、動かすスペースがなくて、泣く泣く膝から上の立ち絵を描きなおすことに……。
なんか髪留めが君〇名はっぽい。ちょうど公開直後だったんだ、仕方ないんだ。

・初期マスター

f:id:chicchi0531:20171016223549p:plain

老けすぎ! ってことで没に

・初期クロ

f:id:chicchi0531:20171016223707p:plain

こっちの方が渋くてかっこいい……? やはり立ち絵のフォーマット変更で没に

・初期ライザ

f:id:chicchi0531:20171016223803p:plain

おっぱいがえっちすぎ。 立ち絵のフォーマット変更で没に

・初期ベガと二代目ベガ

f:id:chicchi0531:20171016224100p:plain

ほぼ全裸。痴女やんけ……。 フォーマット変更と同時に全年齢OKデザインになりました。

はい、没キャラ集でした。

どのキャラが人気になるんだろうなー、とか考えながら描いていました。
押しキャラとかできましたか?
気に入ったキャラクターができてもらえたら幸いです。

最後に、声なし出番なしの不遇だけど、結構気に入っているキャラ、ホーリーベルちゃんを乗せて終わりにしましょう

f:id:chicchi0531:20171016225453p:plain

ありがとうございました!

わがままアリスと百日戦争 制作手記 グラフィック編 ~その1

この記事はフリーゲーム「わがままアリスと百日戦争」の制作秘話をだらだらと書いたものです。
・ネタバレ上等
・ゲーム遊んだよ!
という方向けの内容なので、その点をご承知ください。

はじめに

本記事のグラフィック編では、この5つの項目について、制作手法などを書いていこうと思います。
第一回の今回はUIデザインについてです。

・UIデザイン
・背景
・立ち絵&イベント絵(キャラクタービジュアル)
・戦闘用のドット絵
・戦闘用のエフェクト

UIデザイン

アリ百におけるUIの役割はとても重要でした。
戦略シミュレーションというゲーム性のため、
ゲーム中のほとんどの操作が、ボタンやスクロールビューといった、
UIオブジェクトの操作で完結するのです。

そのため、UIは完成までに最も修正を入れた部分になりました。

フィールド画面

初期デザイン

f:id:chicchi0531:20171013021816p:plain

プロジェクト開始時に、まずはフィールド画面の試作に取り掛かりました。
まず作った初期案は上の画像です。ラフ状態のマップイラストはともかくとして、
UIのパーツも配置も製品版とは大違いです。
このようなテスト画面を、仕様がしっかり固まるまでにまず仮配置としておいていました。

そして、しっかり仕様が固まり始めたころ、f:id:chicchi0531:20171013023923p:plain
このような現在に近いデザインになりました。

このときのデザインは体験版のものです。
体験版から得られたフィードバック、

・メニューの開き方がわからない、というかメニューの存在にすら気付かない
(左下に操作が書いてあるがユーザーはそんなもの見ないのだ!)
・どれが味方の領地で、どれが敵の領地なのかわからない
・どこに攻め込めるのかわからない

を反映し、最終的に完成したUIがこちら。

最終デザイン

f:id:chicchi0531:20171013024610p:plain

・メニューを開きやすくするため、上にメニューバーを設置、おまけで全体表示などの機能も追加
・どれが味方領地、敵領地かわかりづらい問題には、ポップアップアイコンを付けることで対処
・このポップアップアイコン追加で、フィールドの探索要素を明示化できることに気付いたため、本来メニューバーに合った町へ行く機能を、フィールド上に点在する町エリアへ分散。ゲームが進むごとに、より強い武器や防具が手に入る店へ遭遇するという、RPG的要素が誕生、侵略がより楽しくなる一因になった
・このポップアップアイコンの問題として、ノートPCなどではアイコンが小さく文字が見えないという問題があったため、マウスホイールで拡縮できるようなおまけ操作も実装した
・拡縮機能は結果的にポップアップの見やすさだけではなく、マップ全体の広さをユーザーに印象付ける役割も果たしてくれた

このようにフィードバックを受け、体験版からさらにあそびやすく、わかりやすいUIを実現できました。

戦闘編成画面

初期デザイン

f:id:chicchi0531:20171013022953p:plain

初期案ではこんな感じでした。
操作も現在とは違い、ユニットリストからドラッグアンドドロップで、出撃リストへ入れるような方式でした。

ドラッグアンドドロップ自体はあまり悪くなく、むしろ直感的でいいアイディアのように思えますが、
このUIの問題点は、まず第一に配置でした。
出撃ボタンが右側にあるにもかかわらず、出撃リストは左にあるのです。
ユーザーは右にあるユニットリストから、左にある出撃リストへ、
「右から左」への操作を要求された後、再び右の出撃ボタンへ動かなければなりません。

ユーザーの操作の導線を考えたときに、このUIはとても不親切でした。
さらに、画像のD&Dは戦略シミュレーションというゲーム性には適さないことがわかりました。
戦略シミュレーションは、RPGやアクションゲームに比べて、意識すべきパラメータが多いのです。
そのため、多くのパラメータを表示させる必要があり、ユニットのイラストをD&Dするような形状のUIでは情報が収まり切りませんでした。

そこで完成した最終デザインがこちらです。

最終デザイン

f:id:chicchi0531:20171013030343p:plain

ユーザーの導線を考え、ユニット→カード→出撃ボタン
と自然にクリックできるよう、左から右への配置へ変更しました。
さらに、リスト形式にすることでより多くの情報を表示できるようになり、
見た目がさみしいのを防ぐため、上半分にはユニットのドットとステータスが表示されるディスプレイスペースを設けました。

操作においても小さな工夫があります。
本ゲームでは、出撃時にユニットとカード、両方を同時にセットする必要があります。
そのため、ユニットとカードを間違えて配置し、外したくなった時の操作を工夫しなければなりませんでした。

はず初めに考えた、右クリックで「外す」という操作はとても直観的でした。
ただ、その外す順は、ユニット優先、カード優先、ごちゃまぜで後にセットしたもの優先、と、いろいろ考えられました。
試行錯誤の結果、ユニットもカードも平等に、後にセットしたものから外していく、という処理になりました。

しかし、これだけでは、例えば最後から2番目にセットしたものを変えたいときに、直近にセットしたものを外さなければならなくなります。
これは1つの操作のために2クリックが必要となり、とてもストレスです。

そこで、右上に特定のユニット、もしくはカードを外すことができるUIを用意しました。
これにより、右クリック連打で大雑把に外すこともできるし、右上のアイコンから、選んで外すこともできる、
柔軟なUIとなりました。

メニュー画面

最後にメニュー画面の改善を紹介します。

初期デザイン

f:id:chicchi0531:20171013022818p:plain

メニューのUIは実装が遅かったのもあり、体験版のものが初稿となりました。
体験版では、プレイできる範囲が狭く、ユニット数も少なかったため、
このUIでも何とかなっていたのですが、
製品版ではそうはいきませんでした。
大きく問題となったのが

・ユニットの増加によるレベルアップ、兵数回復のめんどくささ
・ユニットが増えすぎて、使わないユニットがどんどんたまっていく

ということでした。

その後も細かい点で、プレイ中にストレスを感じることがあり、
手を入れまくって最終的に完成したのがこちら。

最終デザイン

f:id:chicchi0531:20171013032340p:plain

改善点として、以下のようなものが挙げられます。

・レベルアップ等のめんどくささをなくすため、リスト上部に「まとめてボタン」を設置。全ユニットに対して、一括でレベルアップ、兵数回復などが行えるように
・種族が漢字一文字でダサかったのでアイコンに変更
・強さの指標となるレベルが表示されていなかったので、表示にレベルを追加
・ユニットがどんどんたまっていく問題を解決するため、解雇ボタンを設置。解雇すると換金アイテムがもらえるというユーザーへの誘惑も用意し、積極的な解雇を狙う設計に
・リスト上部に並び替えボタンを設置。これにより、レベル順や、種族別といった並びに変更することができるようになった
・装備ボタンを追加(これは体験版に装備機能がなかっただけ)
・レベルアップなどのウィンドウをキャラのステータスウィンドウに被らないよう、右に移動(見た目にバランスが悪かった)

非常に細かい改善が多いです。
メニューが結果的に最も手を入れた場所になりました。

おわりに

今回取り上げた問題は、戦略シミュレーションだけではなく、
多くのゲームのUI設計でも起こりうる問題だと感じます。

いわゆるUXを考慮したUIの設計は、ゲーム制作においての永遠の課題です。

ユーザーのフィードバックと真摯に向き合い、
ユーザビリティを追求したUI設計を行いたいと日々思うばかりです。

次回は背景やイメージボードなどについて書こうと思います。
見ていただいてありがとうございました。

わがままアリスと百日戦争 制作手記 シナリオ編

この記事はフリーゲーム「わがままアリスと百日戦争」の制作秘話をだらだらと書いたものです。
・ネタバレ上等
・ゲーム遊んだよ!
という方向けの内容なので、その点をご承知ください。

開発始まる

2016年5月初旬、わがままアリスと百日戦争(以降わが百)の開発が始まる。
今回は、

戦略シミュレーションゲーム
・7つくらいの国に分かれていて、各国ごとにシナリオがある

ということが企画段階で決まっていたので、
各国ごとのキャラクターをざっくり決めてから、そのキャラを動かすかたちでプロットを決めていくことになった。

プロット会議

プロットを固めるためにメンバーを集めてサイゼリアへ……。
お酒を入れつつプロットを固めた。
会議は4回。プロットを各々が考えてきて、ディレクターがまとめ、ディレクターが脚本を書くという形。

議事録

議事録を見返して見つけた没設定など…

シャルロッテルート

f:id:chicchi0531:20171012210829p:plain

シャルロッテルートのキャラは、最初はもっとアクが強かったらしい
シャルロッテのお金大好き設定はスキルとかに影響が残っているけど……

パンプキングルート

f:id:chicchi0531:20171012211324p:plain

キワモノといえばパンプキング。当初は各キャラごとのエンディング構想があったので、
こんなトンデモプロットが誕生。
今でも作ってみたいルートである。

オリヴィアトリアイナルート

キャラクターが多めに割り振られたルートだったので、
人間ドラマや恋愛模様とかできたらいいねー、なんて話していたら、
なぜかレイプシナリオへ……。

メインシナリオを超えるシリアス展開へ変貌を遂げる。
これ全年齢で大丈夫か(汗)なんて開発後期までいってたけど、
フリーゲームだしCERO関係ないしいっか!! ってことでそのままに……。

あとイケメン嫌いだからオリヴィアとラブラブにさせたくなかった!(←オイ)

ディレクターの趣味の犠牲になったオリヴィアさん、なむなむ……。

脚本制作

さて、プロットも決まり、6月ごろには脚本制作に移った。
今回はゲームの仕様として

・演出付きのノベルシーン

・画面効果などもある程度何とかなる

ということが決まっていたので、
脚本制作で気を付けなければならないことは、極力地の文を避けることだった。

演出付きなので、キャラクターの立ち絵が画面内で動くのだが、
地の文をつらつら並べていても、キャラクターが動く余地がないし、
そもそも動いているのだから説明不要じゃないか!
ということがあるのだ。

また、テキストウィンドウにも、横23文字、縦4行という制約があったので、
表示を考えながら書かなければならなかった。
幸いディレクターは女の子といちゃいちゃするゲームを作った黒歴史経験があったので、その点は問題なかった。

ボイスを入れることになった

プロット会議をしているときに、ボイスを入れようかというノリになった。
よく考えればいいものを、その場のノリでやってみようということになってしまった。
言い出しっぺは仕事をさぼって首になったため、今チームにいない。
おのれ。

愚痴を言っても仕方ないのだが、ともかく脚本に締め切りができてしまった。
8月29日に初回収録と決めてしまったため、
ディレクター兼脚本の私は、わずか2か月でほかの仕事をやりつつ膨大な量のシナリオを仕上げる羽目になった。

結果、ボイスを入れる部分である、12万文字程度のメインシナリオが何とか完成し、29日当日、慌てて台本を刷って収録に持って行ったのを覚えている。

慌てて仕上げたものだから、エンディングが薄いとか、ボイスを入れてしまったもんだから、後からシナリオの変更がきかないとか、あとで見返して、設定の矛盾を発見してしまっただとか、そもそもボイスの組み込みに1年近くかかったとか、いろいろと地獄を見る羽目になった。

ボイスを入れるなら、シナリオをきっちり時間をかけてあげた後にスケジュールを組もう、というのが、今回得られた教訓である。
思い付きでボイス入れるとかいうもんじゃないよ。ホント。

終わりに

いろいろあって苦労して仕上げたシナリオだったけれど、
そこそこいい感じに仕上がっていると思う……たぶん。

矛盾とか疑問点とか結構ある気がするけど、
そこはそこで優しい目で見て、楽しんでくれたら幸いです。

Unityで作る、画面遷移のあるメニュー

UnityのMecanimを使って、画面遷移のあるメニューを実装してみたいと思います。


ソースコードはこちら 
github.com


今回作るメニューの構造

今回作るメニューの構造は、JRPGによくあるタイプの
トップメニュ→キャラステ、アイテム、システムなどに分岐するような構造。

 

トップメニューがあって…

f:id:chicchi0531:20171010001900p:plain

キャラクターステータス画面や、

f:id:chicchi0531:20171010002007p:plain

他のメニューに遷移するようなメニューを作る

f:id:chicchi0531:20171010002110p:plain


 

デモの画面遷移はざっくりこんな感じ

f:id:chicchi0531:20171010011231p:plain

画面遷移の実装パターン

 細かくは色々ありますが、次の2パターンに大別されると思います。

 

・パターン1:マルチシーンエディティングを活用する
・パターン2:オブジェクトの表示非表示で切り替える

 

パターン1

パターン1は、各メニューをSceneとして保存しておき、遷移する際に

SceneManager.LoadScene("シーン名",LoadSceneMode.Additive);

上記のコードで、シーンを追加読み込みして、画面を重ねていく方法。


この方法だと、

・各メニューの独立性が高くなり、他の場面で再利用しやすくなる

というメリットがありますが、

・メニューの数だけSceneファイルを用意しなければならない

というデメリットもあります。
メニューの各項目を、単体で再利用する場面というのはなかなかないと思うので、Sceneを使わないパターン2の方法で実装するか、再利用する部分だけ、パターン1で、しない部分はパターン2という実装をすることになると思います。

パターン2

パターン2は、オブジェクトの表示、非表示を切り替えて実装する方法です。

表示非表示は、SetActiveメソッドを使う方法もありますが、
ここではCanvasコンポーネントのenabledフラグを切り替える方法で行きます。

f:id:chicchi0531:20171010021849p:plain

SetActiveメソッドを使ってしまうと、そのオブジェクトにくっついているコンポーネントが動作しないというデメリットがあるため、
単純に表示非表示を切り替えるだけならCanvasのenableフラグを切り替えた方が、シンプルな実装になると思います。

データドリブンな実装

テスト段階ならスクリプトで素直に

GetComponent<Canvas>().enabled = false;

とかしておけばよいのですが、実際のアプリケーションでは、UIの遷移にアニメーションを付けることが多いです。
そこで、次のようなMecanimを作り、表示と非表示をアニメーションから切り替えられるようにします。

f:id:chicchi0531:20171010022843p:plain

スクリプト

GetComponent<Animator>().SetBool("IsShow",true);

と書いてやることで、表示され、
falseを入れると非表示になるよう組まれています。

実装

実際のトップメニューからの遷移部分のコードです。

Assets/Resources/Scripts/Menu/Top/TopMenu.cs

    public class TopMenu : MonoBehaviour
    {

        [SerializeField]
        private MenuController mMenuController = null;

        [Header("各メニューのキャンバス")]
        [SerializeField]
        private BaseMenu mArmy = null;
        [SerializeField]
        private BaseMenu mItem = null;
        [SerializeField]
        private BaseMenu mTips = null;
        [SerializeField]
        private BaseMenu mSystem = null;

        //内部変数
        private Animator mcAnim = null;

        // Use this for initialization
        void Start()
        {
            mcAnim = GetComponent<Animator>();
        }

        // Update is called once per frame
        void Update()
        {
            if (mcAnim.GetBool("IsShow") && mMenuController.InputEnable)
            {
                if (Input.GetButtonDown("Cancel"))
                {
                    mMenuController.Close();
                }
            }
        }

        //軍拡をクリック
        public void OnClickArmy()
        {
            mArmy.Open();
            Close();
        }

        //アイテムをクリック
        public void OnClickItem()
        {
            mItem.Open();
            Close();
        }

        //Tipsをクリック
        public void OnClickTips()
        {
            mTips.Open();
            Close();
        }

        //システムをクリック
        public void OnClickSystem()
        {
            mSystem.Open();
            Close();
        }

        public void Open()
        {
            mcAnim.SetBool("IsShow", true);
        }

        public void Close()
        {
            mcAnim.SetBool("IsShow", false);
        }
    }

この、Click_XXXというメソッドをボタンをクリックしたときに呼ぶことで、
各メニューを表示し、トップメニューを非表示にしています。

今回は、右クリックを押すとトップメニューへ戻る、といった実装になっているので、トップメニューと、各メニューでは画面遷移の実装が若干違います。
各メニューの実装は以下。

Assets/Resources/Scripts/Menu/BaseMenu.cs

    public class BaseMenu:MonoBehaviour
    {
        //コントローラへの参照
        [SerializeField]
        protected MenuController mController = null;

        //トップメニューへの参照
        [SerializeField]
        protected TopMenu mTopMenu = null;

        //component 
        protected Animator mcAnim = null;

        //閉じれるかどうか
        public bool Closable { get; set; }

        // Use this for initialization
        protected virtual void Awake()
        {
            mcAnim = GetComponent<Animator>();
            Closable = true;
        }

        protected virtual void Start()
        {
            
        }

        // Update is called once per frame
        protected virtual void Update()
        {
            if (mcAnim.GetBool("IsShow") && Closable)
            {
                if (Input.GetButtonDown("Cancel"))
                {
                    Close();
                }
            }
        }

        public virtual void Open()
        {
            mcAnim.SetBool("IsShow", true);
        }

        public virtual void Close()
        {
            mcAnim.SetBool("IsShow", false);
            mTopMenu.Open();

        }
    }

Closableプロパティは、メニューが右クリックで閉じられる状態かどうかを表すプロパティです。
例えば、キャラクターの編成画面で、装備品を選択するポップアップウィンドウを出しているときに右クリックでトップメニューへ戻ってもらっては困るので、ポップアップウィンドウが表示されている間はClosableをtrueにして、トップメニューへ戻ってしまうのを防いだり、ということに使います。



画面遷移に関して、ざっくり説明してきました。
基本的な内容ですが、何も見ずに実装しようとすると意外と躓くところでもあると思うので、
参考の一つにでもしていただければ幸いです。