00:02
ソルラジ、ゲーム開発の挫折共有トーク。この番組は、素人ゲーム開発者たちが、プログラミングにおける挫折を、つれづれなるままに共有していく番組です。
ゲーム開発に興味のある方や、開発者の方の参考になることを目指した番組です。
ということで、第7回目。はい、よろしくお願いします。よろしくお願いします。
じゃあ、また簡単に自己紹介しようか。はい、ソルベンター代表のパギジョウと申します。
はい、ゲーム開発担当ヤブです。はい、音声映像担当のソーマです。お願いします。お願いします。
こんな感じだっけ?毎回試行錯誤でちょっとね、おかしくなってくるからね、毎回。なんかハマんないですよね。
これだっていうのにちょっとなかなか出なくて。まあまあまあ。今回は第7回目。7回目。
もう1回チェックするよ、回目は。7回目で、ゲーム開発についてお話ししたいなと思っています。
そうね、開発設計の流れとかみたいなのをちょっと一般的なね。
開発を多分したことない人でも、どんなゲーム開発って言ってるけど、どんなことを全体の流れとしていて、それぞれどういうことをやっているのかっていうところをイメージできるような説明ができたらいいなと思っています。
なるほど。一般的なあれですよね、ソフトウェアの開発とかでよく使われるような流れっていうことですか?
そうですね。ただゲーム開発のプロとかではないので、会社で働いているようとかでもなくて、ただソフトウェア開発っていうところもしているので、
一般的なソフトウェアの開発の流れっていうところを紹介したり、実際こちらでチームとしてゲーム開発をしている中でどういう分担をやって、どういう工程を挟んで開発しているかっていうところの説明ができたらいいなと思っています。
はい。ぜひぜひ。ちょっと流れ、一般的にどうやって開発しているか普通に分からないんで、ちょっと知っていきたいですね。
最初に、ゲームってソフトウェアじゃないですか。ハード設計とかではなくて、ソフトウェアの設計として見たときに、今回も図を添付しましょう。添付というかリンク。
リンク?概要欄に?
うん。まず最初に話したいのはV字モデルです。
V字モデル。
ソフトウェアの設計の基本的なところになるんですけど、まずアプリケーションあたりソフトウェアっていうところの設計を最初にスタートするにあたって、これちょっと図は送るんですけど、大きくステップとして要求分析とか要件定義っていうところが最初入ってくるんですよ。
これ何かっていうと、要はソフトウェアの使用をどうしますかっていうところを決めていく工程になるんですよね。
はいはいはい。
要求分析とかっていうお客さんからこういうの作りたいんだよねっていう要求があったりとか、市場的にこういう企画とかこういうものを作りましょうっていう仕様として決めていく、大事なところを決めていくっていうところが要件定義とかに入ってくるんですよ。
03:04
で、その後に基本設計っていう段階があって、大まかな概要の設計ですね。大枠としてどんな設計の環境でどういうツールを使って設計しようかっていうところも入るんですけど、とかデータの構造というかそういう土台となるところの骨組みの設計をしていく。
で、その後に詳細設計っていうのがあって、具体的に関数だったりプログラムをどう書いていくかっていうところの設計をしていって、実際にコーディングっていうところでプログラミングをしていくっていうのがまずやることなんですよね。
で、VGって言ってるところ大事なのが、それぞれのステップ、今言った要求分析からコーディングに対してそれぞれ対応したステップを逆戻りしていくよっていうような流れになっているんですよ。これ図を見るとわかると思うんですが、コーディングした後に今度はコードレビューっていうのをしていくんですよ。これ上から下に向かうにつれてだんだん細かい話をしていくんですよ。
その後にコーディングした後、コードレビューから何するかというと、今度テストをしてちゃんとうまく実装できてるよねって、それ通り実装できてるよねっていうチェックとかテストをするっていうのがVGの二画目というか上がっていく。でそのテストするときは詳細のテストをしてからだんだん大きいテストしていくんですよ。
っていうのがあってVGって言ってるんですよね。なんでコーディングをしたらそのコーディングに対応するのがコードレビューってやつなんですよね。これ何かっていうと有識者も含めてデザインレビューって言ったりもしたりするんですけど問題ないよねっていうところの確認をみんなでしたりするんですよ。
その後に単体テストっていうのはこの詳細設計に対応したテストなんですよね。ざっくり言うと関数とかそういうのを設計したりするんですよ。詳細設計の中で。でその関数の中身がうまく動いてるよねとかそういったところをテストするのが単体テストってやつなんですよね。
でその後結合テストっていうのはその関数の組み合わせとかその処理の全体とかが問題ないよねっていうのを確認するのが結合テスト。でその後最初の要件っていうところとか仕様っていうところをちゃんと満たしてるよねっていう風でシステムテストとか受け入れテストっていうのをやったりするんですけど何かというと最初はこのソフトウェアの設計において大事なのって手戻りしないことなんですよ。
手戻りっていうのは作ってみたけどやっぱこうじゃなかったよね欲しいものっていうのがあるんでまず最初に仕様とかを固めるっていうのが何よりも大事なんですよね。
何が必要なのかとか。そうそうそうそう。大きな方針というかそういうのが設計する方向わかるじゃないですか。そういう大枠なところから大事なところから決めていって最終的に詳細の設計をしていくっていうのが大事。でその後に今度大事なのは詳細なところからテストしていくのが大事でその理由っていうのがいきなり例えばコードレビとか単体テストしずにいきなり全体のテストすると問題があった時にどこが問題あるのかわかんないんですよね。
06:01
わかんないね確かに。バグの原因っていうところそれは詳細からやっていった方がわかるんですよね。だから詳細のところからテストやっていくっていうのをこのVGモデルっていうところは大事だよねっていうところの考え方。
なるほど。だいたいザクッと再現したい機能とか必要なものを洗い出した上でそれをどんどん細かく細かく落とし込んでいったので後でその細かく作ったものをさらに細かくからどんどん洗い方向にテストしていく。そうそう大きい方向に。下に下がっていって突合する細かいところからだんだん上がっていくって感じですね。
そう。そんな感じ。例えばゲームの設計で言うと最初に機能としてRPGゲーム作ろうかなとかアクションゲーム作ろうかなとかって結構全然変わるじゃないですかゲーム設計って。そういうところが要件定義だったり基本設計ってところに入ってくるやつですよ。
あとは2Dで作る3Dで作るとかゲーム。3Dで作るんだったらそれぞれオブジェクトが必要だったりとか2Dでもしも作るんだったら絵とかが必要だったりとかそういうふうになってくるじゃないですか。それを決めずにいきなりドット絵を描いても3Dゲーム作りたいよねってなった時に困るじゃないですか。だから最初に要件定義とか仕様っていうのは決めないといけないよねってこと。
なるほど。なんか大きいところからちっちゃいところを動いてってちっちゃいところからまた大きいところに戻っていくみたいななんだろうな。抽象的ですけど。なんとなく言わんとしたことは分かるかも。なんかこうU字型。
U字型でもいいかもしれない。大事なのはそれぞれ対応してることなんですよね。図で横に矢印ついてるじゃないですか。例えばこれ何かっていうと、例えば基本設計のところで戦闘のRPGゲームで戦闘をしますと。
で、それは基本設計の段階で戦闘に入る時の時間とか戦闘のバトルの時間とかは大体10分ぐらいで倒す敵ですみたいな。そういうようなゲームの設計するじゃないですか。その後詳細設計として具体的にこのモンスターが出現して味方はこういうキャラクターが出現してみたいなことを設計するんですよ。
そしたら、例えば詳細設計でちゃんと定義したボスが出てくるかとかをチェックするのが単体テストみたいな。
なるほど。そのシーンだけでとかね。そうそうそうそう。で、その基本設計ってところは、そもそも戦闘のシステムとしてスピード感だったりとかゲーム。そういったものを定義したもの通りになってるよねっていうことをチェックしていくみたいな感じ。
全体通してね。そうそう。そしたら、今度最初の企画とかは、例えばテンポのいい戦闘システムみたいな企画に書いてあるんですよ。それ通りになってるかっていうのをシステムテストとかそういうところでやっとできるってこと。
なるほど。プレイした全体の感想みたいなのが戻ってくる。そうそうそうそう。おもろくなってる。そういうこと。なるほどね。
っていうところがあって、今回ちょっとまあそれソフトウェアの設計という観点でもあるんだけど、一般的なゲーム開発っていうところの手順というか開発の流れ、製作の工程っていうところの話もしたいなと思っていて。
09:04
それもちょっと図を貼ろう。ゲームの製作工程ね。そう。これもね結構似ているところがあったりするんだけど、よくあるのは最初企画をして、その時に企画をした時にゲームってちゃんと作れそうかっていう技術検証とかがしたりするんですよ。
今の技術じゃ到底できないよこのゲームみたいなことがないよねっていうのを確認するために最初企画してプロトタイプ設計したりする。試しみたいな感じで。すっごい簡単に作れる感じね。でその後できそうってなったら基本設計っていうのをするんですよね。基本設計もさっきV字モデル出てきたところ。
概要な設計構想設計って言ったりするかな。でその後に実装とかテストをするって意味でアルファ版を作って、それも詳細設計とかコーディングですね。それを膨らませたステージを増やしたりとか。それのベータのベータ版を制作したり、最終的にリリースするものとマスター版を作ったりっていうような形で進めることが多いですね。
まあちょっと結構ずーっとフワッとした説明になってるんですけど、今回お話したいのはソルブエンターとして僕らどういうゲームを作っているときに具体例としてそれぞれのステップどういう風に設計しているかっていうちょっとお話をしたいなと思っています。
ゲームの流れで言うと、設計の流れで言うと最初に企画をしますと。その企画が俺らで言うとエグゼアクトっていう名前でプログラミングが学べるゲームっていうのを作るっていうのは最初企画にやったんですよ。でその後にそもそもコンセプトっていうのもあって、それがテキストプログラミングを実際にする。
C言語とかPythonとかCシャープとかJavaScriptとかそういうプログラミングをできる環境、ゲームの上でそれができて、それを実行する機能もあって、それを実行したらキャラクターがそれ通りに動いて、それが戦闘できて、それで戦闘で敵を倒す、そういうゲーム楽しそうだよねっていうところが企画としてあったんですよね。
でそもそも次のステップとしては基本設計とかやっていくんですけど技術検証ですね。技術検証としてそもそも俺らも素人だったんで、ゲーム開発としてUnityも使ったことないけどUnityでプログラミングができるゲームってそもそも作れんっていうところがあったんですね。でそれを調べてみてもなかなかない。
ただいわゆるコンパイラっていうものを作らないといけないんですけど、プログラミングを解読する機能みたいなことですね。そのコンパイラは独学で一応学んで、それで実装を試しにしたらそれ通りに動いたねっていうところがあって、じゃあこれは作ることができそうだ、実現できそうだっていうところをチェックした上で改めて設計をしたんですよ。基本設計。
基本設計何かっていうとステージ1からステージ10まで敵はどんな敵が出てきて、プログラムはどういうプログラムを書くと倒せるかみたいな設計をして。戦闘もだいたい何ターン、RPGで考えたんですけど、だいたいどれぐらいのターンでどういうことをしてどういう工夫があったりして倒せるかみたいなのを考えたりして。
12:13
で、同時にこのステージではどんなプログラミングとしての学習項目があるかみたいなところを基本設計の中で検討しました。で、その次に試しに3ステージぐらいを作ってみたっていうのがアルファ版設計ですね。
で、今アップしたりして発信とかしていろんな人にテストプレイをしてもらったりしてるんですけど、それが今アルファ版っていうのを作ってて。で、今ちょうどやってるのがベータ版設計っていうところで、その作った5ステージぐらい作ったんですけど、それを10ステージ20ステージっていうところを作り上げて、そこでベータ版としてテストもしていって。
いろいろこういうふうに変えたらバグったよとか。今もう絶賛バグ出し中で。
バグ中なの?
そうそう。出まくってます、バグが。
でもそういうもんなんですよ。作り立てっていうのはバグすごい出るんですよ。ただテストプレイと修正っていうのをやっていくことでだんだんバグが落ち着くというか、だんだん出なくなって。で、それがマスター版としてこれから作っていきたい。ベータ版マスター版っていうのを作っていきたいなっていうところも、今現状開発状態ですね。
そうですね。
そういう段階なんですね。なんか聞いてるだけの人分かるかな。左上から要求分析、要件定義、基本設計、詳細設計、コーディングで下まで降りてきて、ここまでで1回形ができてるっていう状態ね。で、そこから隣に行ってコーディングに対してコードレビューっていうものをしてチェックする。詳細設計に対して単体テストっていうのをやってチェックする。
基本設計に対して結合テストっていうのをチェックしていく。要件定義に対してシステムテスト。要求分析に対して受け入れテスト。受け入れテストまでいくともう大体できてるねっていう完全完成みたいな。
そうそう。ソフトウェア開発としてのV字モデルっていう紹介と、ゲームの制作工程の2つを紹介したんですけど、これちょっと別々なのも理由はあってですね。このV字モデルっていうのは1つの、例えば機能というかソフトウェアを作るときに便利な考え方で。
なるほど。1つのフレームワーク。
そうそうそうそう。これ、ウォーターフローっていう開発の考え方なんですよ。これ何かというと一個一個フェーズをきちんとやっていって、やっていった結果V字モデルのそのフェーズを全部終わらせたときに完成するっていうソフトウェアなんですよ。
ただゲーム設計ってちょこちょこバージョンアップするじゃないですか。
これもう作るものが決まってる場合は。
そう、それに近い。もう作るもの。
こういう形で作るけど。
作るものが決まってないもんね。ゲームとか途中で。
そう、あの決まってたり決めるべきなんだけど、バージョンアップとかしていくっていうのが常じゃないですか。ちょこちょこ。
15:03
要は一昔前だとディスクに収めるゲームを作るときにさっきのV字モデルが活躍するけど、今はアップデートをし続けたりするっていうのをアジャイル開発っていったりする。そういうもっとより早く開発を進めたいねっていう考え方なんですけど、簡単に言うとね。
そのアジャイル開発的な考え方で、さっき言ったゲームのアルファ版施策とかベータ版施策っていうような工程を挟んでいくっていうような感じなんだよね。結構そこらへんを片方に偏らずに、今自分らが意識してるのは両方とも考え方っていうのをある程度知りん考え方っていうのがあるなっていうのを意識しつつ進めるっていうようなことはしている。
ざっくり言うと、ゲームの制作工程でやってるけど、実は基本的な設計を最初に優先的にしたりとか、テストはちっちゃいところからやっていくっていうところは細かいところではやってるっていうような感じ。V字モデルを何回も回してるに近い。
アジャイルのほうね。高速で回すのか、1回回して綺麗にやっていくのか。
そう。機能追加も基本的に要件定義から入るべきだから、機能追加をするっていう。
なるほどね。もう一回Vから、左上から降りて上がっていく。
難しいのは、ゲーム開発って結構あれじゃないですか、すごい優秀な人がチーム組んで作るだけじゃない開発っていっぱいあるわけじゃないですか。
もう僕らみたいに素人で、何なら一人でやる人もいるし、環境的に。3人とかの小人数とかでもやったりするから、そこら辺は真面目すぎずに、だけどこの考え方も大事に進めたらバランス感覚で設計するのがいいのかなって思います。
バランスだね。
一概に答えとは言えない。
そうだね。必ず左上から行くんじゃなくて、もしかしたら飛ばしてもいいのかもしれないし。
そうそう、すごい難しいところ。理想的な進め方っていうのはいくらでも言えるけど、その理想的な進め方をしようとして挫折するくらいだったら、っていうところもあるなぁと思ってるので。
なるほどね。それぞれ関わる人とかも変わってくるわけだよね、各段階で。
そうそう。最初のプロトタイプとかのタイミングでは、簡単にゲームを最低限実装するっていう感じなんで、イラストレーターさんとかCGとか、そこら辺を無理して組み込まなくても全然いいので、そういうのはもうちょっとゲーム、アルファ版作るとかベータ版作るとか、もうちょっと形として成り立たせたいときにそういうところが入ってくるようなイメージですね。
確かに。この流れはちょっと抑えておいた方が良さそうですね。何がどこでどう関わるかとか。
で、その中でも今回ちょっと紹介したいの一個あって、ソルベンタのやり方でもあるんですけど、僕らって作れる人少ない2,3人とかなんですよね。
はい。
そうなったときに、CGやる、イラストやる、モデリングとか、あとはプログラミングでゲーム実装もする、ユニキュアも使うとか、いろいろ一人でやる。けど、ゲーム開発ってそういう環境にいる人って結構いると思うんですよね。趣味でやるとかでも。そうなったときに、なんか挫折すごいしやすいんですよね。わからないものいっぱいだらけじゃないですか。
18:21
あるね。
ゲーム詳しいですって人でも全然挫折するじゃないですか。ゲーム開発って。だからそういったときに紹介したいのは、その知識がなくても専門家じゃなくても簡単に実現できるツールとかを使うのが何よりもおすすめなんですよね。
なるほど。
例えばなんですけど、最初企画とかは、企画とかは結構考えてて楽しいところでもあるんで、こういうゲーム考えました?みたいな紹介するのも楽しいしね。企画っていうところはソルベンタで言うと、みんなでキャンプ行ったじゃないですか。キャンプ行ってこういうゲーム楽しそうじゃね?みたいな。飲みながらでもいいから考えるのは結構おすすめ。
はいはい。
一人で開発する、考えるのもいいんですけど、何かしら友達とかで共有した方が企画っていうのは個人的には良いものになりやすいかなって思ったりする。
結構企画って、企画したときって思いついたときめっちゃ楽しそうって思うんですよ。
はいはい。
でも1週間か2週間経つとめっちゃつまらんそう。
謎だよね。それあるよね。
あるよね。
あるある。あれ?みたいな。気づいちゃったり。
これ面白いんかなって。
あるね。
そうそうそうそう。あるじゃないですか。っていうのも、一人で何回も回すよりもみんなでそういうのやった方が短時間っていうか。
そういうところでは。
それはね、もう避けれない気がすんだよな。どうしてもテンション上がるしよ。
上がるよね。
でもそれって意外とね、調べてみたら既存でそういう似たようなゲームいっぱいありましたとか企画もね。
そうそうそう。意外とね。
まあでも、そういうところもプロセスとしてあると僕はもう思ってます。
もうそれがあって、この時期きたなみたいな感じで、そういうふうに思ってやってて。
ただそこも企画っていうところも他人数でやる楽しく話すっていうのが多分やり方として意識していることなのかなと思ってて。
次にプロトタイプ施策っていうのは結構気をつけているところで、素人だからこそ技術的にネックとなっているところがないかっていうところはよく調べたんですよ。
ユニティ知らないです。ユニティがどんなことできるかっていうのも知らないところが始まってるんで。
ただRPGのゲーム作りますってなった時に比較的それは難易度低いんですよ。
なんでかっていうと今までの人たちやってるから、基本的なRPGゲームとか基本的なアクションゲームっていうのはユニティを使っていろいろ作ってたりするし、参考サイトもいっぱいあるんですよ。
ただ技術ネックになったのは、プログラミングができる機能っていうところがとてもネックだったんですよね。
21:01
だからプログラミングができるためにはどういう機能追加しないといけないかっていうところの検討はプロトタイプの時点で結構したんですよね。
オリジナルな機能っていうところはよく機能分解して、これらを全部機能入れるとやりたいことできる、作りたいものができるっていうようなことはプロトタイプの時点で考えるのはとても大事だと思ってます。
それをするともう一個何がいいかっていうと、計画立てやすいんですよね。それぞれの機能実装をするっていうのが必要になってくるから、目的になるんですよね。
ちっちゃい目標になるから、それをそれぞれこの期間でやれたら全体として3ヶ月ぐらいできそうだなとか。
そういったところで、俺らは2ヶ月ぐらいで何かができたっていうか、アルファ版っていうのは。
コアに外せないっていう機能についてプロトタイプで必ず確かめておく。
だって大事なものができなくなったら、そもそも企画通りのゲームはできませんってなるからね。
アクションしないアクションRPG。
そうそうそうっていうのがあるから、技術検証って言うんですよね、自分は。
っていうのを外せないですね、確かに。
っていうのが、そこもできたら、あとは基本設計とかは結構プロトタイプがそれなりにできたらできるのかな。
基本設計とかっていうと、ここもね、いいのか悪いのかわかんないんだけど、そんなしっかりやってなかった。
しっかりやってなかったから、プロトタイプの試作の段階で、プログラミングできるゲームはできそうだなってなったんですよね。
その後、基本設計というところで、RPGの機能としての基本設計を考えたんですよね。
最初はタイトル画面から始まって、ボタン始まるとメニュー画面があって、それを押すとステージ1があって。
で、その時のステージ1としては、キャラクターがいて敵がいて、マス目はどういう風になってるのかとか、コマンドどういうのが打てるのかとか、そういったところは簡単に考えたぐらいかな。
その辺ができてればまあいいかなっていうところですね。
で、それをやって、その後、アルファ版制作ってなったんだけど、その時にCGとかもできる人いない。
イラストレーターは、友人とかで絵上手そうな人、もう知ってる中の絵上手そうな人に、ただただお願いした。
あとはそのCGは、ブロイドをゴリゴリ。
ブロイドっていうCGを作る?
3Dのキャラクターモデルを作るツール。
めちゃくちゃお世話になった。
確かに、すごいちゃんと作れるよね。CGモデリングツール。
で、そのキャラクター作って、それをユニティに入れるっていうところも、やり方は調べれば出てくるんで、それをして入れて、ざっくりはそんな感じかな。
あとは、アルファ版設計の中で、基本設計の中で、最初知らなかったのもあって、あんま意識してなかったんだけど、キャラクターをどういう風に動かすのか。
24:02
キャラクターのアクション、魔法を使うときのアクションとか、剣で斬る、そういったところのアクションっていうのは、基本的にユニティのアセットを使ってます。
そのアセットっていうのは、ユニティっていうのはゲームを作るためのツールなんですけど、それで機能がいっぱい、ストアみたいなところで売ってたりするんですよね。
無料で手に入るもあるんですけど、それを使って購入したりして、それをキャラクターに適応して魔法の動きをさせるとか、基本的にそういうのをモーションって言ったりするんですけど、そこら辺は基本的にゼロから作ってない。
いろいろ買ったりとか、落として組み合わせてる。
やってます。っていうところでアルファ版を作って、ベータマスターも基本的には今はそれでやっていこうかなと思ってます。
とりあえずマスターまではそれでいこうかなって感じで。
本当にそういったところ、根本としてオリジナルとしての面白さっていうのは、そういったものをゼロから作らなくても出せるので、そこでマスターまで作り切ると。
その次のステップとして、オリジナル感だったりとかを見直す、手直しをしたいと思ってるんで、その段階では曲だったりも含めて、いろいろゼロから作っていきたいなっていうのは思いとしてある。
最終的な位置から。
そうそうそうそう。すべてをゼロから作ろうとすると、結局つまずいちゃうっていうところはあると思っているので、だからあえて楽できるところはしとくというか、っていうのは自分の設計している中の意識していることかなっていうのは。
とりあえず一本丸々作れるところで作ってみるって。
楽しみ方としては、ゲーム検証もあるんですけど即時フィードバックみたいなのがあるんですけど、やっぱゲームがどんどん出来上がっててやれること増えるっていうのがやっぱ楽しいので。
モチベーション。
モチベーション。
モチベーションなるね。
そうそうそう。だからどんどん取り入れるものは取り入れちゃってやるっていうのが、やっぱゲーム開発で進めるっていうのも含めて大事なポイントかなっていうのは思ってます。
あとは出来ないとかも頼っちゃうみたいなのもあるよね。
そうそうそうそう。ほんとそれ。だからすべてを大事にしようとしないこと。
大枠でとりあえず最後までポンポンポンとやれる範囲のものでやっちゃう。
できることとできないことはもう切り分けちゃって、スッと諦めていい。
諦めて次に行く。
そうそうそうそう。そっちからCGの勉強とかしてるとね。
もう間に合わないね。
それまで経っても多分ゲームができない。
確かに確かに。
ただ既存にあるゲームと同じものを作っても意味ないんで、オリジナルのところはどこかっていうのも企画プロトタイプの段階でしっかり意識。
確かにそこの企画がオリジナリティあれば、後で組み合わせ方は何でもいいもんね。
っていうところがあります。
なるほど。プログラミングがゲームの中でできるっていうのは一つ面白いですよね。
Exactの企画としては。
そういう感じでどんどん形はとりあえず後で整えるけど、できるところで作っちゃう。
27:03
あとは設計書とかね。設計書っていうのはよく問題になってるんですよ。
設計書が残ってないから次の人作れませんとか改善できませんとか。
これどう作ってたのかわからへんよね。
結局それぞれの設計のV字モデルとか特にそうなんですけど、基本設計書っていうのがあったり詳細設計書っていうのがあったりするんですよ。
要はできたプログラムが見ればわかるよねじゃないんですよ。
いろいろ設計者っていうのは同じことだったけど、思い、自分の企画とかそういったところから要件っていうところからどういうふうに仕様に落とし込むか。
どういう考え方で仕様に落とし込んでるか。
どういう考え方で構想設計、基本設計をしたり詳細設計してコーディングしてどういう工夫で処理時間が短くなってるのかとか。
コードもいろんな書き方あるわけじゃないですか。
その考え方っていうのだったり設計者の思いっていうのも残すのが本当に大事なんですよ。
じゃないと次の人作れない。
だけど今少人数とかそういったところで設計書を作ってる暇あったらゲームの形にしたいっていうのもあるから。
ずっとそれのジレンマと戦ってるというか。
開発規模によってちょっとその辺変わりそうですね。
そうなんですよ。おっしゃる通り。開発規模で全然変わってくるし。
そういうのを仕事としてやるとかそういったところとかも含めてどれだけの品質が求められているのかっていうところでもまた変わってくるところなのかなと思ってるんですよね。
ただ一個それ知っておくとちょっと納得がわからないですけど、
それは参考サイトの出来上がったプログラミングを流用しようとすると自分でアレンジしづらいっていうのはそれでまさに設計書とか残ってないんですよ。
そういうのがないものを取り入れようとしてもどういう考えでこのプログラムになったのかがわかんないんですよね。
わかんないね。
わかんないでしょ。
だから俺はゲーム作りの中ではどんどんそういう設計の中身も含めて公開していきたいなと思ってるんですよね。
絶対そっちの考え方としてからそういうのを共有していきたいなと思ってるんですよね。
じゃないとなんでこうできたのかっていうのがわかんない。
確かに。
わかんない。
なんか体でいくとそのAさんっていう体があるのに無理やり腕だけ別の人の中に移植されてわかんないみたいな。
そうそうそうそう。
それは合わないよねみたいな。
そうそうそうそう。
とかあるんですよね。
これからゲーム作り始めようと思っている人とか今でもちょっと頑張っている人とかの参考になれればいいなって感じですかね。
そうですね。
そういうのを見てもらって。
とかこれから僕らのやるその過程とかを見てもらいながらこんな感じかみたいな。
そうそうそうそう。
って見てもらうといいですかね。
そうですね。
はい。
よろしくお願いします。
よろしくお願いします?
我々ソルベンタをよろしくお願いします。
ヤブさんが無理やりお晴らしにかかっております。
お腹を下しているようなので。
時間をちゃんと見て。
ちゃんと見て。
今36分くらいだからちょうどいい感じでね。
はい。
30:00
じゃあ今日は。
そうそうそう。
これからはゲーム開発7回目ということで。
それぞれの詳細のまた今回はステップとかゲームの制作工程だったりそれぞれを全体の概要っていうのを話したんですけど。
次はそれぞれのね詳細のところステップの詳細とかもお話しできたらいいなと。
基本設計。
詳細設計の違いとか。
オモプロタイプ施策とかね。
そうそうそうそう。
そんな感じのところもちょっと共有していきたいなと思っていると思いますね。
そうですね。
でそういったものを日々X、旧Twitterでつぶやいてますっていうところで日々の開発挫折やゲーム開発プロジェクトの過程を。
こちらでsolventerでアカウントを検索してフォローしていただけば概要欄にも貼ってますのでこちら遊んでいただいて僕らの活動に参加していただけると嬉しいなと思っております。
よろしくお願いします。
よろしくお願いします。
じゃあ本日はこれでありがとうございました。
ありがとうございました。
バイバイ。
