投稿記事

応援が出来るプランの記事 (12)

kotaro / 俺時空 2024/02/03 16:30

SlashRash #4 / タイトルとか作った

進捗どうですか?

まあタイトル通りなんだけど、一旦区切りがいいとこまでできたと思うので進捗報告。
最初の方に不定期更新とか言ってた気がするけど、なんだかんだ続いてるね。えらいぞ♡

どこまでできたの?

タイトルと、ステージ選択。ここのシステムはほとんど完成してる。
え、それだけ?と思われるかもしれないけど、結構大変なんですよ。
DXライブラリとかやったことないクラス設計とか、初めて触る要素が多いので割と手探り状態だし。
まあそれなりに頑張って、ちょっとずつではあるけど進んでるよって状態です。

次に作るもの

ようやくゲームのメイン部分に触れられそうです。一番楽しそうなところ。そして一番大変そうなところでもあります。
具体的にはプレイヤーの実装、並行してステージ制作になりますかね。
旧SlashRushからコードの流用ができる可能性があるとはいえ、リメイクということで多少手を加えると思うのでね。
僕のやる気次第で原型をとどめていないレベルになるかも。コードが。
後のことを考えながらコードを書いていると、「こうした方が効率的だな」とか「こういう機能あったら便利だな」とか延々と出てくるんですね。
んでそのたびに必要な技術や知識を調べる。これがまあ時間かかるんですね。
特にゲームのプレイ中周りの処理はそういうのが多い。いろいろやりたくなっちゃう。
まあだからと言って妥協するのは性に合わないのでね。ぼちぼち頑張っていきます。

コードの勉強、いる?

これは余談ですが、なんでわざわざ知らない方法使ってプログラミングしてるんだと。ゲームが作れるくらいプログラムが出来るなら勉強とかいらなくないかと。

旧SlashRushが完成している時点で、全く同じものなら難なく作れるんですよ。
じゃあなんで難しそうな技術を勉強してたり調べたりしてるんだ。
わざわざそんな面倒なことしなければ、リメイクなんてすぐにできたんじゃないか。
答えは、「俺がやりたいから」
プログラミング的には、クッソ見づらいコードを書いていた自覚があるので直したい。ついでにもっと良いコードを書きたい。
ゲーム的には、結構気に入ってるゲームなのでさらにブラッシュアップしたり新要素の追加をしたい。あと世に出したい。
ということで、勉強というのはやりたいことをやるために必要なんです。
正直なところ、世に出すだけだったら一週間くらいでできたと思います。でもそうしないのは、単純に自己満足のため。
僕の行動原理なんてそんなものです。

おわり

という感じでした。どうせ作るならクオリティの高いものにしたいよね。
あと、次のSlashRushに関する記事はマジでいつになるかわかりません。
やりたいことを実装するのにだいぶ時間がかかる見込みです。まあ不定期更新なのでね。気長にお待ちいただければと。
なんか「不定期更新」が逃げの言葉になってしまいそうでやだな…

それじゃ、またね。

kotaro / 俺時空 2024/02/01 14:09

俺のゲームのつくりかた

ゲームづくり、どうやってるの?

ゲームを作る、と言っても何から始めたらいいのかわからない。
そもそもどんなゲームを作るのか。どういうゲームを作りたいのか。
一番最初に出すアイデアはどうやって生まれてくるのか。
そんな根本的な部分を僕がどうやって決めているか、またその考え方などをメモっておこうというお話。話ですらなく独り言ですが。
もしかしたら誰かの参考になるかも?

ゲームの根本的な部分

ゲームにおいて最も重要な部分とは。
人によって答えが違うと思います。ゲーム性、ストーリー、世界観、キャラクター。
当然不正解はありません。どれもその人にとって重要な要素なのです。
では僕はどうかと言われると、そのゲームが生み出されたきっかけとなる部分。
アイデア、コンセプト、テーマ。ゲームの根本的な部分こそ、最も重要だと考えます。

では「根本的な部分」とは何か。
ゲームを作るとき、アイデアも何もない無の状態から作るなんてことは到底できない。必ず何かしらのアイデアやコンセプトがあり、そこからゲームへと発展していくものです。
これはゲームに限らず創作物であれば何にでも言えることです。
絵を描き始めた後に「よし決めた、これを描こう」とはなりませんし、何か書類を書き始めた後に「この書類にはこれを書いていこう」とはなりません。
必ず、それを創るためのアイデアやテーマが存在します。絵であれば「描きたいもの」、書類であれば「書きたいもの、書くべきもの」
それを創るべき理由や、それを創るための発想。これこそが「根本的な部分」 です。

「根本的な部分」の重要さ

ではそのアイデアはどのように生み出されるのか。アイデアを出す方法は五万とあります。検索しても出てくる。
既存の要素の組み合わせで新しいものを生み出したり、いままで誰も見たことがないような突飛なものだったり。日常生活などから着想を得るのもいいですね。
ことゲーム制作において、このアイデア部分は非常に重要な要素です。ここがそのままゲームの面白さに直結していると言っても過言ではありません。
秀逸なコンセプトやテーマがあれば、それは必ず面白いと思えるものになります。逆に言うと、ここが中途半端なものはだいたい中途半端なものになってしまいます。
この感覚は一度でもゲーム制作に触れたことがある人はなんとなくわかるんじゃないでしょうか。

…いろいろと思想強めなことを言い切っていますが、あくまで個人的な意見だということをご留意ください。変な言いがかり付けられても困りますし。

「面白いゲームを作る」は罠?

さて、そんな大事な部分(だと思っている)ですが、これはゲーム制作者が陥りやすい罠になりえるものでもあります。
一体どういうことかというと、ゲームにおいて重要な部分、もしくは根幹に深く関わる部分ともあれば、誰もがよく考える部分になるはずです。
ましてやそれがゲームの面白さに直結するかもしれないということは、より面白いものであるべきと考えるのです。
その結果、自分の出したアイデアが他のゲームやコンテンツと重複していないか、いかに独自性やオリジナリティを持たせられるかなど、ゲームの面白さについて非常にセンシティブな状態になりやすいのです。
要は他のゲームより面白いゲームを作ろうとしてしまうのです。

もちろんこれが悪いことだとは言いません。面白いゲームを作ろうと頑張ることには価値があります。それは否定できません。
しかし、面白いゲームに固執するあまりアイデアを生み出すことに難が生じては本末転倒です。このまま無理に考え続けるのは効率がいいとは言えません。
どうにかして客観的な視点から見てみたり、自身の価値観を疑ってみることができれば良いのですが、この罠にハマってしまうとどうにも抜け出すのは難しいんですよね。

自分の「やりたい」をゲームにする

面白いゲームを作りたい。これはゲームを作る人たちの共通認識だと思います。
どうせ遊んでもらうなら、遊んでくれた人が「面白い」と思ってくれた方がいいですよね。中には苦しませる目的のゲームもありますが。
ここに共感できた人は、既に罠にハマっています。
というか、この罠にハマらない人はいません。

ゲームを作るにあたって、必ず「面白さ」を考える時間があります。では、その面白さはいったい誰に感じてほしいのでしょうか。
もちろん遊ぶ人には面白いと思ってほしいでしょう。ただ、何も遊ぶ人だけに面白さを感じてほしいわけではないはずです。
僕が言いたいのは、一番最初に「面白い」「遊びたい」と思わせるべき人物は誰かを考えてほしいのです。

それは紛れもなく、自分自身のはずです。

自分が作るゲームというのは、まず自分自身が面白いと思わなければそもそも作る気にすらならないと思います。
自分が「つまらない」と思うゲームなんてわざわざ作りたくないですし、作ったとしても「つまらない」で終わりです。
まず自分が「面白い」と思ってこそ、「遊びたい」「やりたい」という気持ちも生まれますし、作るモチベーションにもなります。

こうした自分が感じる「面白い」を「他の人も面白いと思ってくれるだろうか」と考えたり、自分が「やりたい」と思ったことを「でも他のゲームが既にやってることだし」と考えてしまう。
これこそが「罠」の正体です。
自分の「面白い」という気持ち、自分が「やりたい」と思ったこと。これらに素直に従うことこそ、面白いゲームを作るために必要なことなのです。

…何度でも言いますが、あくまで個人的な意見です。当然人によって考えも違うと思うので、僕の言うことをあんまり信じすぎないようにしてくださいね。

自分が先、他人は後

実際、僕が作っていたゲームは「自分のやりたいこと」をそのまま形にしたものが多いです。というか全部そうです。
どれも「全部斬りてえ~」とか「機関銃撃ちてえ~」とかから生まれています。
こんなのでいいんですよ。ゲーム制作なんて。(おい)
自分が「やりたい」と思ったものを作っているときが一番楽しいんです。
ただ、人間という生き物は賢いので、どうしても「声」が聞こえてきます。
今話題になっているゲームだとか、注目を浴びている表現だとか。そうしたものがあれば取り入れたくなってしまうものです。
もっと言うと、作ったものに「ここがダメ」とか「こうした方がいい」とか言われることもあります。
改善案やシステムの問題点などを提示してくれる「参考になる意見」はありがたいものですが、ただの批評の場合もあります。
そんな時は、この言葉を思い出してください。

「うるせえ黙れ!」

無理に流行に合わせる必要はありません。無理に他人の意見を聞く必要はありません。
最優先は自分の「やりたい」という気持ちです。これを形にすることが何よりも大事なことです。
「ちょっと自分のやりたいことからはズレたけど、流行を取り入れました!」「自分のやりたい表現ではないですが、話題の表現を使いました!」
これで満足できるのであれば問題ないと思いますが、それは本当に自分の「やりたいこと」だとは思えません。
やはりゲームは自分のやりたいことを形にしてこそ、と僕は考えます。

…あくまで個人的な(以下略

おわり

まとめると、

  • ゲームはアイデアやコンセプト、テーマが大事
  • 自分の「面白い」を基準に考える
  • 他のものに影響されがちなので気を付けよう

ということ。やりたいことをやろう。
もちろんこれが正解というものはないので、大いに悩んでください。自分の「やりたいこと」を理解するのは、実は難しいことなのです。
まあそもそもこれらの考えは「個人」での考えだと思うので、必ずしも当てはまるわけではないんですよね。何度でも言いますがあくまで個人的な意見です。

それじゃ、またね。

kotaro / 俺時空 2024/01/30 23:19

SlashRush #3 / シーンの実装

タイトル通り!

タイトルの通り、シーンの仕組みが実装出来たという報告です。
有言実行えらいぞ♡
正直もう記事終わっていいんだけど。

くわしく

今回実装出来たのはシーンの仕組み部分。
どういうことかというと、複数のシーンを用意することが出来て、シーンの切り替えもできるようになりました。
逆に各シーンの内容は未着手の状態です。
タイトルにもゲーム部分にも「Now Loading」と書いてあります。草。

「仕組みだけ?」と思われるかもしれませんが、今後のプログラミングにおける作業効率が段違いになっているはずです。
このためにめっちゃ勉強した。知らない言葉10個くらい覚えた。
まあ、プログラムを触らない人には伝わらない部分で頑張ってたというお話です。

苦労したんですよ

いやあ、実は「シーンの実装」だけなら何度もやったことあるんですよ。
ただ今回はちょっと違う方法での実装を試みたんですね。
その結果5日くらいかかっちゃった。てへ。

今までやっていたシーンの実装方法は不正解ではないんですが、他の方法に比べて効率が悪いというものでした。
だから旧SlashRushは7,000行とかあったんですね。
なので色々調べて、なるべく効率のいい方法で実装したいと思っていました。しました。
プログラミングってね。楽をするために苦労をするものなの。掃除するために掃除道具から手作りするようなものなの。

おわり

短めですが、今回はここまで。
次回からやっとゲームの内容部分に触れられそうです。
といっても、まずはタイトルやステージ選択周りのシステムを作るところからになりそうですが。プレイ画面を作り始めるのはもう少し先かも。
まだまだDXライブラリも使いこなせているわけではないので、結構期間が開いてしまうかもしれませんね。頑張ります。

それじゃ、またね。

kotaro / 俺時空 2024/01/24 17:02

SlashRush #2 / まずやるべきこと

プログラムを書く前に

僕はいまDXライブラリに慣れていく段階にいる。
ではある程度慣れたあと、何から始めよう。
いきなり見切り発車でプログラムを書き始めても、全体の見通しが立っていなければ効率がいい方法とは言えません。
ということで整理していきます。前回も整理してなかった?

決めておくべきもの

適当にプログラムを書き始めて完成まで持っていくのは至難の業。
例えるならば、下書きをせずいきなり絵を描き始めたり、起承転結や全体の構成を考えないままいきなり小説を書き始めるようなものです。
プログラミングも同様に、下書きのようなものがあります。
下書きと言っても、ある程度大まかに「このゲームには何が必要か」「どんな機能が必要か」などを決めていくものです。
「攻撃の挙動」とか「敵の配置」などの細かい部分は省略して考えます。
今回はそれを考えていこうというお話。

  • ゲームの仕様
    仕様と言ってもプレイヤーの挙動や使用するボタンなどではなく、ゲーム全体を通したものを考えます。
    タイトル画面→プレイ画面→クリア画面orゲームオーバー画面
    のように、シーンの遷移やその順番などを整理していきます。
    最初にゲームの流れを決めてしまおうというわけですね。
    ここが決まると、どの場面で何が必要かを考えやすくなります。
  • 必要な要素
    ここでいう必要な要素とは、「その場面で必ず必要になるもの」のこと。
    ゲームが始まった場面では、必ず「ステージ」と「プレイヤー」が必要になります。
    いらないゲームもあるかもしれないけど。
    とにかく、「これがなきゃゲームが成り立たない」というものを挙げていきます。
  • 場面と要素の関係性
    これは少し難しいのですが、上で考えた要素が「どこで必要になるか」を考えます。
    例えばプレイヤーの場合、ステージが開始した場面では必ず必要ですが、タイトル画面やステージ選択画面では必要ありません。
    いや必要なゲームもあるけど。
    とにかく、「どこでこれが必要になるのか」という、要素と場面の「関係性」を整理していきます。

このあたりのことを決めることが出来れば、既にゲームの枠組みはできたと言っていいでしょう。
ここからそれぞれの要素を細かく掘り下げていったり、途中で必要なものが増えたりしたら適宜対応していく形になります。

もっとわかりやすく

ゲームに必要なものはだいたいわかりました。
しかし、小規模な物であればあまり問題はないのですが、規模が大きくなってくると複雑な関係性を構築していたりして非常にわかりづらくなります。
ということで、もっと整理していきましょう。
僕のように完全に一人で作っている場合、ちゃんと全体の流れが頭に入っているのならばわざわざここまで整理しなくとも大丈夫だったりしますが。
でも僕は頭がそんなに良くないので整理していきます。というか忘れる。

もっとわかりやすくとは言いましたが、具体的にどうするか。
今回は視覚的にわかりやすく整理する方法をとります。
それぞれの要素や関係性を図にしてみましょう。


ということで作りました。手書きでゴメンネ。
この図ではシーンの流れとプレイ中に必要な要素をまとめています。
現状、構造自体はシンプルな物ですね。
ステージ選択画面で選んだステージをプレイできる。プレイ結果によってリザルト画面へ。そしてまたステージ選択に戻るの繰り返し。
プレイ中では、プレイヤーと敵が存在します。プレイヤーと敵はお互いにダメージを与えあう存在です。
そして敵には「ザコ」と「ボス」が存在します。さらにザコとボスの中で種類がある、という感じですね。
プレイヤーと敵にはそれぞれパラメータや行動が設定されていて、それに基づいた動作を行います。移動だったり弾を飛ばしてきたりなどですね。
端の方にある「シーン」は、こういうシーンがあるよという情報を持っています。特に何かとつながりがあるわけではないんですね。

とりあえず最低限ではありますが、これでゲームの流れと要素を把握しやすくなりました。
何にでも言えることだと思いますが、やっぱり整理整頓は大事です。
僕が分かんなくなるから。

で、どうするの

ここまで整理してきましたが、忘れてはいけないのは整理することが目的ではないということ。ここで終わってはいけません。
ある程度全体の見通しを立てたということで、プログラミングではどんなメリットがあるか。
一番は、「最初に手を付けるべき場所」が考えやすくなることだと思います。
言い換えると「一番重要な部分」を考えやすくなる。
今回の場合、最初に手を付けるべきは「シーン」だと思います。
そもそも「シーン」が存在していなけば、プレイはおろかタイトル画面すら存在することが出来ません。
ということで、まずは必要なシーンを作り、それから各シーンに必要な要素を作っていく、という形でプログラミングは進んでいきます。
最初にやるべきことが分かるだけでも、プログラミングの効率が上がりますし、なにより気持ち的にもとても楽です。
みんなも整理整頓、しよう!

おわり

ということで、DXライブラリをある程度扱えるようになったらこんな感じで進めていきたいと思います。
いやーとっても気が楽。やることわかってるとすごい気が楽。
とまあ、進捗報告というよりは備忘録みたいになってしまいましたがまあいいでしょう。
実際全体の見通しを先に立てておく、というのはだいたいのものに言える大事なことですし。
次回からはちゃんとした「進捗」の報告が出来るよう努めてまいります。

それじゃ、またね。

kotaro / 俺時空 2024/01/23 17:01

SlashRush #1 / 制作開始

制作開始!

ということで、本格的にリメイク版SlashRushの制作を開始していきます。
がんばるぞー。
と言っても、本当にゲーム部分の制作が始まるのはもう少しかかりそうですが。

制作環境の構築

今回はDXライブラリを使用し、C++で制作を進めていくことにしました。
上手くいけば元のソースコードをある程度流用できるってのが大きいですね。
とりあえずパパッと「もうゲーム作り始められるで」ってとこまで構築できたので、あとはもう作っていくだけなんですよね。
今のところ順調。まあ環境作っただけなんでそりゃ順調じゃなきゃ困るんですが。

DXライブラリ?

実は僕も今回初めて触るので、そこまで深くは理解してなかったりします。大丈夫か?
超ざっくりいうと「描画関連はだいたいやってくれるツール」みたいなものです。間違ってたらごめん。
そう、初めて触るんですよ。一応リファレンスはざっと目を通しましたが、恐らく慣れるのには時間がかかると思います。
まあ描画関連も全部一から自分でやるってよりは相当楽なはずなのでね。まあなんとかなるでしょ。

制作の予定

とにかく初めて触るので、いろいろと慣れておかないといけませんね。
ある程度扱えるようになったらゲーム部分の制作に手を出し始めると思います。

最初に作るのはやっぱり操作キャラですかね。ゲームのメイン部分なので。
同時にチュートリアル用のステージも作る形になると思います。
動作確認も兼ねて、まずは主人公がステージ上を動けるようにする。
第一目標はここですね。

ちょっとした問題

リメイク版の制作にあたって、旧版SlashRushからソースコードを流用しようと思っていました。だって楽だし。
専門学校の用意したエンジンを使って制作していましたが、基本的にエンジンは描画関連を担っていたので、DXライブラリでも少し手を加えれば流用はできると思います。
問題なのは、僕が書いたコード。

main.cppに7,000行あります。

わかる人なら「うわあ」ってなると思います。僕もなりました。
旧SlashRushは、main.cppに約7,000行のコードが記述されていて、そのmain.cppだけでゲームのすべてが動いています。
例えると、数学のノートとかで絶対ノートの幅が足りないような式を無理やり詰めて書いてる感じです。見にくいしわかりにくい。
まあこれは気合いで何とかするしかないですね。7,000行とはいっても大部分は流用できそうなので、整理しながらやっていきましょう。

余談

旧SlashRushではプログラムはもちろん、グラフィック、BGMも全て自作でした。
まあそんなに出来がいいとは言えないと思いますが、なんか全部自分でやろうとしてたんですよね。
僕がこのゲームを気に入っているのは、全部自分で作ったからかもしれないですね。手間暇かけただけ愛着が沸いているのかも。
ちなみにBGMは僕のYoutubeで公開されているのですが、そもそも僕のチャンネルを見つけることが難しいというね。リメイク終わったらチャンネルの方も大々的に宣伝するかもしれないです。

おわり

そんな大した報告でもなかったんですが、とりあえず作り始めたよという報告でした。
ちなみに記事のサムネイルは旧SlashRushのタイトル画面です。CERO Zの作品だと間違えられたことがありました。草。

それじゃ、またね。

1 2 3

限定特典から探す

記事のタグから探す

月別アーカイブ

記事を検索