こんにちは！コンじゃぶろーです！
ハロウィンまっただなかの更新です。
ご無沙汰してました！前回から１カ月くらいあいてしまいましたね。
どういう順番で説明したらいいかなぁなんて思ったり、色々とブログ作成や文章作成に関する本を読んだり、ゴロゴロゲームしているうちに、１カ月以上も記事の更新を休んでしまっていました。
時の流れるスピードが・・・速すぎる。
タイムリープできれば・・・。
時をかける、もぐお・・・。
これからは、もっと小さなテーマでたくさん更新していこうと思います。
さぁ、前回はゲームストーリーに関して投稿しました。
今回は、ゲーム作りに便利なフローチャートの解説をしていきたいと思います。
ストーリの基本は前回やったけれど、次は何をしたらいいの？
ゲームは、正直どこからでも作れてしまうので、何からはじめようか・・・、
かなり悩んだけれど・・・。
フローチャートからはじめていこうかなと思います。
フローチャート！？
何それっ！おいしいのっ！？
冷たくて甘いやつ？
・・・フローチャートは、プログラムの流れを図にしたものの事だよ。
えぇ・・・！？
なんだかめんどくさそう・・・。
きくのやめておこうかな・・・。
めんどくさい・・・と思うかもしれないけれど、プログラムが楽になる魔法のツールだから、覚えておいて損はしないよ。
で、でも、知らなくても、ゲームは作れるんでしょ？
作れるよ。
でも、これを知っているだけで、プログラムの開発効率はとてもアップするんだ。
う、ううん・・・便利なんだ・・・でも今回はちょっと眠いから・・・パス。
がびーん！・・・おねがい、寝るのはまって！
色々、かいつまんで・・・大事な所だけにするから！
そこまで言うなら、・・・聞いてあげてもいいけど・・・。
つまらなかったら即寝るからなっ！
世の中には、たくさんのプログラム言語があるけれど、このフローチャートは、どのプログラムを勉強していても、役に立つから覚えておいて損はないよ！
フローチャートを学べば、スーパープログラマーって事だね！
はじめてゲームプログラミング『メタルボーラー！RPG！』連載 第4回 ゲームの設計図作り「フローチャートってなんだ？」の巻
フローチャートって何？
まず、フローチャートという言葉を聞いた事もない人もいると思います。
プログラミングをし始めると、触れ合う機会もあるので覚えておいて損はありません。
フローチャートとは
フローチャートとは、四角形やひし形といった図形や矢印を使って、ゲームの流れを図にしたものです。
プログラムを作る前に、流れや考えを整理したりするのに便利なツール。
まずは、どんなモノが見てみよう。
これが、フローチャートだ！
これが、フローチャート！？
不思議と、意味が分かる。
シンプルなので、『フローチャート』を見た事が無くてもカンの鋭い人であれば、これでだいたい何をあらわしているのか分かると思います。
宝箱をゲットしたら、ゲームクリア画面が表示されるゲームを表現しています。
こんな簡単な流れのものでも、プログラミングしてしまうと、内容がわかりづらくなってしまいます。
フローチャートを見るだけで、プログラムをしていない人にも全体のボリュームが、分かりやすくなるんです。
言葉だけで説明するのも大変だよね。そんな時は、図にすれば簡単に説明できる！
プログラムが分からない人でも、理解できるって素晴らしいですよね。これが作れると、プログラム言語が分からなくても、ゲームの仕様書が書けるようになります。
フローチャートは、ゲームに限らずエンジニア界を中心に幅広く使われている便利な道具です。
＜フローチャートの便利な部分＞
- 処理の流れを整理できる。
- 足りないところを、プログラミングする前に見つける事ができる（想定漏れがわかる）。
- プログラムを作る前に、プログラムを作った後と同等のディスカッション（作る前に議論）ができる。
- 作る前に、全体のボリュームがわかる。
こういったメリットがあげられるでしょうか。（後で詳しく解説を入れていきますね。）
ゲームを作る前に「フローチャート」を作れば、事前に構造の問題が洗い出せるので、作り直しが減って時短になります。
作りなおしが、一番もったいないですから。
ゲーム開発は、絵を描いたり、音楽を作ったり、プログラミングしたりと、１つずつがかなり時間がかかります。
数時間から数日間かかるような作業になるので、絵を描いたあとに「あ、これいらなかった！！」ってなると、数日間の作業が無駄になったりすんですよね。
人が作ってるので、作ったのに使われなかったらかなりのストレスになります。
行き当たりばったりの開発を進めると、人間関係にヒビが入ってもおかしくないです。
色々問題を解決するのに便利なので、時短の為や品質を上げる為に使われています。
フローチャートの例
お買い物ロボットをフローチャートで書いてみた
これは、自動でお買い物をしてきてくれるロボットのフローチャートだ！
何か、気になる点はありませんか？
な、なんだコレは・・・。
色々、つっこみたくなる。
うずうず・・・。
うずうずする・・・。実は、そこが一番重要な事なんだよ。
声に出してみて。
捨て台詞「てやんでぃ！」じゃなくて
「すみません、お金足りません」じゃない？
それに、今のままじゃ・・・、他のお客さんとぶつかった時や、レジに人がならんでいた時に、他のお客さんと喧嘩になりそう・・・。最初の立ち位置が変わったら、変な動きしそう。
そうだね！色々おかしいよね！
もし、プログラム組んでからだと、パっと見で分かりづらいから
そういった意見がでづらいんだよね。
なるほど、プログラムしてから
「ほかのお客とぶつかった時どうするの？」なんて言われたら
「そんなの想定してないよっ！」って、エンジニアと喧嘩になっちゃう。
無用な争いが無くなる・・・なんてすばらしいツールなんだ！
ゲームの仕組みをフローチャートで書いてみた
あとは、イメージしづらいものもフローチャートで考えると分かりやすくなるよ。
意外とイメージしづらい、ゲームの基本構造を、フローチャートにしてみるね。
ゲームの構造は、めっちゃ複雑なので色々と複雑な部分をはしょって、ぶっとばして最低限の部分だけを書いてみるとこんな感じ
シンプルだけど・・・
なんだかおかしくない？普段ゲームしていて、ボタンを押した時と、移動と、画面表示ってほとんど同時な気がする。
これじゃあボタン入力している最中に、動きがとまっちゃうんじゃ・・・。
そうだね、そうおもっちゃうけれど、この動きが１秒間に３０回から６０回のスピードで動いているから、ほぼ同時に処理されているように見えるんだよ。
い、１秒間に６０回！？
凄い・・・！！
ろー
そう、めっちゃ速い！
色々、例外もあるけれど、プログラムは１度に１つずつしか処理できない。
だけど、すごく速く処理できるから、フローチャートを使って、シンプルな処理を順序良くフローにしてあげれば、凄く便利なサービスが実現できるんだね。
ろー
NintendoSwitchソフト「ナビつきはじめてゲームプログラミング」では、このあたりの処理をあまり意識しなくても作れてしまいます。興味がある人は調べてみてね。
（補足：タイマーを作ったりする時には意識してみるとおもしろいですよ）
それでは、ここで終わると中途半端なのでもう少し詳しく解説しておきますね。
どうしてフローチャートを使うの？
フローチャートを使うと、作る前に問題を見つける事が出来る。
フローチャートは、品質を上げるツール
複雑な流れが、整理できる
ろー
シンプルにする！必要最小限の労力で作る！
それには、整理整頓が重要です。
文字だけのプログラムを１万行眺めていて、中身が全て把握できるのは本人だけ。
場合によっては、本人でも理解できていないかもしれない。
そんな時に、フローチャートを書けば自分でも間違いに気づきやすいし、後から追加する時にも問題なく追加出来るようになります。
また、本人が気づかなくても、他の人がフローチャートをみれば気づける問題もあります。
不足している要素を見つける事が出来る
ろー
あれもない！これもない！
あとからどんどんつけ足す・・・！何でも後からつけ足せてしまうのがゲーム作りの罠
想定外の要素を後で追加すると、バグが生まれやすい。
フローチャートを書いてみると、想定していない処理が見えるようになります。
ゲームでは、フローチャートに出来ないものは実現できません。
逆にフローチャートとして図に出来れば、何でも作る事ができます。
＜応用テクニック＞
フローチャートを書いたあと、ゲーム画面や入力方法を１ステップずつイメージすると、足りないモノがどんどん見えてきます。それらを全て作れば、ゲームを作る前に必要な素材が全部わかっちゃいます。（最初に工数が出るってすばらしい）
作る前に、問題を見つける事が出来る
ろー
プログラムを組む前に、熟練プログラマーにフローチャートを見てもらうだけで
かなり品質が向上します。
見てもらう人の負担を軽減するのも、かけだしプログラマーのつとめ！
プログラミングをする上で、プログラムする前に問題を見つけれるのは、非常に優位です。
作る前から構造上の問題があったら、いつか必ず崩壊します。
いきあたりばったりでプログラムすると、あとからあとから想定外の処理を盛り込む事になり、最悪の場合（というより、絶対に）作り直しになってしまいます。（作り直せないケースもあり・・・途中で開発中止になる場合もあります。）
そうなる前に、フローチャートをほかの人に見せて、問題を減らしてから挑みましょう。
ろー
最初に想定して作るのと、後から追加するのとでは、品質にかなりの差がでます。
家を建てる時にたとえると分かりやすい。（建てたあとから増築しまくって、壊れそうな家見た事ありませんか？）
フローチャートの作り方
簡単なゲームでフローチャートを作ってみよう
世の中のあらゆる事は、フローチャートに出来ます。
試しに、自分の身の回りの行動やサービスをフローチャートにしてみましょう。
一回作ってみると非常に理解しやすくなります。
最低限のルール
フローチャートを書く際に、ちょっとだけルールを決めておきましょう。
極めると、ものすごく深いのですが、ゲームの仕様書を書くだけであれば、覚えるものは５種類くらいでいいでしょう。
フローチャートを作る無料ツールは山ほどありますが、最初は紙と鉛筆で十分です。
①スタート：端子（開始）
ろー
すべてのはじまり。例外もありますが基本的には、１つだけにしましょう。
複数あったらバグりやすい。くらいに考えておきましょう。
②ゴール：端子（終了）
ろー
ゲームの終了。複数作っても問題ありません。
③処理
ろー
四角形の中に、処理の内容を書きましょう。こまかく書くときりがないので、シンプルで分かりやすいものにしましょう。なれないうちは、ゲーム画面で分けるのがいいです。
できるかぎりこまかく書いて、慣れたら減らしていくのもいいでしょう。
④分岐：判断 条件分岐
ろー
条件分岐は、ゲームやプログラミングのだいご味です。これがあるから、小説や映画とは違うゲームの魅力が表現できる部分だったりします。
ひし形の中に「判断する要素」を書いて、「はい」「いいえ」の矢印をひっぱりましょう。
今は、あまりみかけませんが、「ゲームブック」なんかがイメージしやすいと思います。
⑤矢印：結合子（けつごうし）
ろー
最後は、矢印です。一番よく使うやつです。
矢印の上に、何をしたら進むか書いておくと分かりやすくなります。
以上です。とてもシンプルな作りなので、覚えてしまいましょう。
他にも、色んな記号がありますので、興味のおもむくままどんどん調べていくと良いです。
これらは、世界共通の言語だったりするので、違う国の人にも理解してもらえたりします。
フローチャート例題
フローチャートにするといい練習になりそうなものをピックアップします。
身の回りのモノを、どんどんフローチャートにして自分の武器にしましょう。
フローチャートに出来るものは、プログラミングできる。
フローチャートに出来ないものは、プログラミングできない。
●初級例題
- サイコロをふって、出た目を叫ぶ
- 自動足し算機、２つの数字を入力すると合計した数字を叫ぶ
- ひよこのオスメス判断、ひよこがセンサーを通過した時に「オス」「メス」叫ぶ。１万匹に対応。
●中級例題
- 自動販売機 お金を入れて、5種類のジュースから選んで買うと、ジュースが出てくる。そして叫ぶ。払い戻し機能あり。
- 自動扉のセンサー 自動扉に近づくと、扉がひらく。しばらくセンサーに反応がないと、扉がしまる。はさまれたら叫ぶ。センサーが反応しないとちょっとすねる。
- コンビニにおいてある自動コーヒーマシン 注文して紙コップを置いてから、抽出して取り出すまで。コーヒーが出来上がったら叫ぶ。コーヒー豆やミルクの残量を判断して、補充エラー機能つき。
●上級例題
- 地雷原での爆弾探索 キャラクターの目の前のマスに地雷がうまっているか調べる。調べた時の地雷の距離で、音の強さを変える。地雷の上に移動すると爆発。そして叫ぶ。
- 塗り絵ツールのドットぬりつぶし 指定したマスの色を変える。隣のマスも同じ色だった場合は塗りつぶす。隣接マス全てチェックしたら、塗りつぶし処理を完了する。そしてやっぱり叫ぶ。
- 自動返答ツール（自動解答・自動返信） きたメールに対して、自動的に文言を返す。メールの種類は、「問い合わせ」「クレーム」「送り間違い」「いたずら」「ウィルス」の５種類を想定する。メールを送る時は、3回に１回叫ぶ。
フローチャート 最後の注意点
ろー
はい、おつかれさまでした。
ここまで、読めたあなたはすばらしい！
ふー、
盛りだくさんだったけれど・・・
メタボールRPGの話は全然できなかったね。
ろー
しまった・・・！
フローチャートのボリュームが多すぎて、全然書けなかった！
おなかいっぱいだから、今から話されても
正直きついけれど・・・。
ろー
１歩ずつ進んでいきましょう。
こつこつやるのが大切。
フローチャートに関して解説してきましたが、あまり細かく作らないというのも大切だったりしますので、フローチャートを作るのに１週間や２週間かけたりはしないようにしましょう。
１時間程、手書きで書いてスタートするくらいでもいいと思います。
プログラムしている最中に問題が発生したら、フローチャートに戻って考えましょう。どうしようもなければ、つくりなおせばいいんです。
絶対に問題が無い状態にする必要もありません。僕の場合は、ゲーム開発の予算が決まっていたので、それを超える事がどうしてもできなかった。だから、１日で全体のフローを書いて１日かけて担当プログラマーとつめて、３日目にはもう作り始めていました。
フローチャート主義でいく場合のデメリットも覚えておいてください。
●フローチャート主義のデメリット
- フローチャートを完璧にすると、遊び部分がなくなりやすい。大きく変更しづらい。
- フローチャート以上のものが生まれにくい。固くなりやすい。
- 決められた処理を作るだけになり、エンジニアのモチベーションがあがりづらい。
あるていど大雑把に作って、エンジニアに託す。
こういう考えもあっていいと思います。
それでは、長々とご清聴ありがとうございました。
良いゲーム作りライフを！
コメント