どれぐらいの人がやってるのかが気になって。 私はやりません。 (面倒臭いなんて言えない) やっぱり大事なんですかねぇ。 (風呂で茶を飲んで投稿してます)

マリオメーカー協力にだれもこない！！

風呂で茶飲んでとかww

俺氏はノートに使用をまとめますね。 その後は実機でぼちぼちと… 少し書き換えたら 名前変えてセーブ (例 PETITRPG_01 PETITRPG_02 など) っていうのは俺的なやり方。 フローは基本書かないっす。 ジップロックに3DS入れて 風呂で書くことはあるけど(実話

仕様だったw

別スレの話持ち出す人はお帰りください！ 待つのも大事ですよ。 前にスレ立てて2週間たってようやく1コメですから。 このコミュの流れは遅いので、気長に待ちましょう。

miiverseのサーバ落ち着いてないな… 投稿ずれちゃったみたいです すいません

フローチャート 風呂ー茶ート 公式のネタなんて言えない………

「お風呂でお茶は飲まねぇぞ？」 ですね

投稿についてはすいません。

フローチャートは複雑なら大まかに分けた後細かくやっていくので結構便利だったり。 フローチャートはバトル関係の場合にのみ使用しています。

複雑さによりますねー 頭の中でまとめられるものはそのまま組むし 少しややこしいものは紙で適当に考える… マジで複雑で頭の中ではどうにもならないものは フローチャートを書きますが、 厳密なフローチャートじゃなくて、 適当な囲い+擬似コードってかんじになります

厳密にフローチャートっていうのは書かない。 流れを表した図見たいのを書くのもまれ。脳内でどうにかすることが多い。

フローチャートは全く書きません。 僕のプログラムの流れが複雑でないから かもしれませんが。

今作ってる作品は、基本的には前作と大まかな流れは一緒ですので フローチャートは書いていませんね。 それよか変数や配列、関数の仕様、ファイル構成、データ仕様 スプライト仕様、イベントフラグの管理とか・・ そっちのほうが重要になってます。 （エクセルで管理してます）

風呂はお茶の後で→風呂お茶後→フローチャート というのは置いといて、「フローチャートがどんなものかを知っておく」ということは良いですがフローチャートは少なくともある程度プログラミングができないとまともに書くことができないので今まで全くプログラミング経験がなくプチコン3号が初めてという人はその存在自体を知っておけば十分です。 入力、表示、判断、繰り返しというのがどのようなものかを実際にプログラムを入力しながら確かめていくのが一番です。 フローチャートは複数人で共同開発する場合には共通認識の確認のためあった方が良いですが、すべて個人開発であるならば「必要」と感じている人（あとで自分用の資料にしたい等）のみ書けば良いと思います。 ちなみに私は必要性を感じてないため書いていません。書くとしてもフローチャートの厳格なフォーマットではなくオリジナルフォーマットにすると思います。

フローチャートなんて書いたことないです( ´ ω ` ) 頭で考えれば何とかなるなるー。データ的に頭のキャパ超えそうなときはコメントで逐一メモするか、るかかさんみたいにエクセルがめんど味少なくて良いと思いますー。 この手の「○○ってやった方が良いかなぁ」っていう疑問は、「必要性を感じないうちはやんなくて大丈夫！」で良いと思いますよー(・u・) なんでやるのかわからないうちにやっても大した効果は出ないと思いますしー。

長方形書いたり、菱形書いたり、矢印書いたり、いちいち書く必要はないと思ってるので書きません。 そのかわり、コメントを多めに書きます。変数が何を意味してるのか？ ここでは大まかにどのような処理をしてるのか？はたくさん書いたほうがわかりやすくなります。 関数名やラベルをもっと目立つようにコメントで囲ったりすると探しやすくなるので長いプログラムも読みやすくなります。

フローチャートは書いたことないし、書こうとも思わないし、書いてあるのを見てありがたいと思ったこともありません。 時間軸で変数の変化を図示する「タイミングチャート」というのはそこそこ使います。 データ構造(木構造や連結リストなど)は結構書きますね。 もしフローチャートが制御構造を明らかにするのが主目的なのであれば、制御構造って ・連接(上から下へ) ・条件分岐(if) ・繰り返し(while) の三種類しかないので、わざわざ明らかにしなくてもいいかな。

私の場合初心者故に、プログラムの勉強をする時やプログラムを実際に打ち込む時、プログラムの順番や何が起きているのかがごちゃごちゃになるので、フローチャートみたいに本格的ではありませんが、プログラムのだいたいの流れをノートなどに書いています。 私もぷちぷちさんの様にプログラムの方にもコメントアウトで何が起きているか、何の変数なのか、などをメモする事もあります。

フローチャート自体、図示することで分かりやすくする目的のためにあるものなので、重要性は制作者個人のスタンスや周りの環境に影響するものと思います。 まあ、プロジェクトリーダーという立場にある私みたいな人は、こと細かなプログラムの書き方は別にして、ゲーム自体がどう進んでいくか、というぐらいの物は作ったほうがいいです。 実際に、粗雑な計画のせいで何度も泣きを見た私が言うんですから間違いはない(筈)です。

なるほど、コメありがとうございます。 意外にやらない人が多いんですね。 自分は コメントあまり入れない空白入れない改行入れない でやってたから見辛いと言われて…(当たり前) 見やすくなるのかと思って、必要なのかなと感じました。(スパゲティソース)

フローチャート？　書きませんよ？ ソコまでしっかりとした計画でプログラムを組み始めていないので、「書け」と言われても書けませんがね。 どうしてもフローチャートを添付して提出する必要がある時に書いたことがありますが、プログラムを書いてから、最後にプログラムを元にフローチャートを書きました。かなり面倒な作業でした。

マルノウチ・スゴイタカイビルでフローチャート詳細設計書いたことが・・・・処理の理解よりも図形の整列に時間をとられた・・・・プチコン案件ではないです。殆どの場合インデント付き箇条書き、よくてExcelでした

自分の頭のなかを整理するために図形で整理する、あるいは他人に伝えるために図示することは多々あります。 自分の理解のためなら、とにかくシンプルにして、将来の僕が理解できる様に備える。(僕ならサボりたいと思うはずなので。) そんなやり方が好みです。

「サボりたい」は、自分でもやった方が良いと思っている事なら自分で納得できるくらいにはきちんとやり、自分で納得できるくらいにはサボりたいと言う意味です。

ちゃんとしたフローチャートは書いてないですね ゲームではなくツール開発が主で画面毎に作っていくから流れが複雑になりにくいという事もあるかもしれません それでも処理の流れを確認しないといけないと感じた時は具体的に値が変化していく様子を紙に書きながら頭の中を整理します

おや? ベテランの方々、意外と書かないようで。 さすがと言うべきか。 僕もそんなに書かないですけど、これからはバトルのプログラム組んでいかなきゃなので、多分そのときに書きます。 その点ルデさんに近い。

コメ感謝。 あまり書いたりしないんですね。 Excelを使っている人は尊敬する。 (Excelごときに弱い人) (弟の方です。兄弟で同垢使っているので。)

ツララさんへ 私がフローチャートを書かないのは必要性を感じないからですが、まともにフローチャートを書くならばその間にコーディングが終わってしまいます。 時間は有限であるためフローチャートを書かなくても作れるのにわざわざ時間を割いて書くのは時間が勿体ない気がします。

書かない人が多いとは思ってたけど有名な方のほとんどの人が書いてないとは… 大作の複雑なバトル形式の場合、AIの動きをフローチャートみたいな感じで書いてたりしてました。 かなり昔にフリーゲームの方をパソコンの方で配信してたんですが、その時は飽き性で断続的にやってたのでフローチャートはかなり重宝しました。

私の知る限りフローチャートを書かない人は2種類いる。 既にデバッグ済みのフローが頭の中に叩き込まれていて、後はそれを部品のように組み合わせてコーディングする人。 要求仕様から勢いでコーディングを始めて、後で動かしながらデバッグしつつ足りないものを付け足していく人。

後者です。 勢いなので。

私は書く派です、というより推奨派ですね。 大雑把な処理の流れを書いて、そこからまだ細かくあれもこれも追加したり 面倒だと思う流れを整理する為に書いたり プログラムに取り掛かる前の「下準備」として書いたりします。 あと仕事で他の方に引き継いだりする時にフローチャートを渡すと解析も速かったりしますよ。

勢いでコード書いていき、どうしてもバグが消えなかったり、思ったような処理が出来ない時に必要に駆られてフローチャートらしいものをノートに書いて、それを基にコーディングする事があります。趣味で作るゲームなので、自分のやりやすいようにするのが一番だと思います。

私は自分だけで作るプログラムにフローチャートはかきません。 でも暇なときには仕様書を簡単に作ったりしますよ。完成品をイメージするにしても記憶力とかに限界があるので、ちょっと脳内で形にしやすくします。仕様書を作るとモチベーションも上がります(個人の感想)。 フローチャートも仕様書も、必要なら使う、それで良いかと思います。

前のコメントで書き忘れたけど、ステートマシンを作る時は「状態遷移図」というのを書きます。 字句解析/構文解析を書く時には、文法を表す「構文図式」というのがあると便利です。 フローチャートの進化形に UML というのがあります。 フローチャートと違って、書いた UML から実際のプログラムを生成できます。 使ったことはないでけど

そういうのもあるんですね。 奥が深い………！？

UMLでコーディング しっかり細部まで使いこなして余分なコードを埋め込んだりしなければ楽なんでしょうが 実際はなかなかそうも言ってられない感じになる事が多いようです UMLで表現出来ない仕様をプログラマが自分で書き込み互換性が崩れて結局二度手間とか 昔経験しました(^^;)

皆さんコメント本当にありがとうございます！！ フローチャートのことについてよくわかりました。 これで閉めようと思います。 本当にありがとうございました！！