開発ノキオク20 ～オラに芸術センスをわけてくれ～

諸事情で開発に手つけてませんでした。

僕の場合、ゲーム作りに勤しんでいるあまり、
ブログがおろそかになる事はありません。
ブログも開発モチベーションの一環なんで、
こっちが停滞している場合はゲーム作りも停滞しとります。


その間、他のツクラーのブログとかを参考にしたりしてたんですが、
ゲーム作りで一番大変なのはシステム作りと言う人が多い事に気づきました。

かくいう僕も現在システム構築の真っ最中ですが、
頭が爆発しそうになりそうな時は5分に1回はありますΣ（゜∀゜）

ゲームを作る上では物語やデザイン、システム等と沢山の要素があり、
どの工程が一番大変なのかを考えるのはナンセンスです。

ただ、システムを組むというのと他の要素とが違う所は、
手を抜く事が出来ないという事だと思います。
精神論じゃなくて現実的な話、
適当にシステム組んでもPCがエラーを吐くだけですから。

システム構築とは課題を物理的にクリアしなければならないポジションなんですね。

理系か文系かの差に似てると思います。


じゃあそれ以外の物語とかデザインはどうなってるかと言うと、
現時点ではシステム構築プログラミングがメインなんで、
グラフィックの表示なんかはダミーを用意して仮組みしてます。

で、思ったのが、僕はデザインのセンスは無いなと。



上では「システム組みは大変ですぞ」的な事言ってますが、
物語考えたりデザインしたり音楽作ったりとかっていうのは
一種の芸術的能力が必要で、ほいそれと身につくモノでは無いと思います。

それは才能であったり日々の積み重ねの中で育まれるモノですから。
僕がそうだったようにある程度のゲームプログラムだったら
小学生でも作れますから、やっぱり芸術センスのある人は尊敬します。


という一週間でした。←無理やりなオチ

開発ノキオク19 ～視覚聴覚効果～

アイテム表示ですが、画面上に一度に表示できる数は限りがあります。
例えば、アイテムを10個持っていて一度に表示できるのが6個までとすると、
7個目以降のアイテムの表示方法も考える必要があります。

表示方法は大きく別けてこの２種類だと思います。

・キーを押しつづけるとアイテム欄がスクロールするタイプ
・ページを切り替えて7個目から表示しなおすタイプ

世の中の大半のゲームは前者のスクロールタイプが採用されていると思いますし、
見た目や直感的な操作感でもこちらの方が優れているように思います。
そのかわりページタイプに比べてプログラムの量が大きくなり複雑さも増します。

複雑といっても、チャートや変数管理がしっかりできていれば
そんなに悩まされるほどでも無いと思ったので
当ゲームではスクロールタイプを採用する事にしました。


でまぁ、早々と結論を言いますと、
やっぱりページ切り替えタイプにしました（早っ）

プログラム的にはもちろんエラーも無くデータの受け渡し等も間違いないんですが、
どうしても操作時のレスポンスが想像通りにならないんですよ。
CとかBASICのプログラム言語なら難なく作れるんですが、
こういう細かいところで制約が出てくるのがスクリプト言語の弱点です＞＜

完全に言い訳です。

敗北。

とにかく前へ進む。


たかがレスポンス、操作感覚と言うかもしれませんが、
ゲームにおいて操作感覚こそがゲームの良し悪しを決める
大きな要因であると僕は考えています。
アクションゲームだけでなくRPGでも
構成やシステムは完璧なのに操作性が悪くて惜しいゲームは結構あります。

というわけで、ページ切り替えタイプに切り替えるのは難なく終了。



次にアイテムの大分類の項目、
【素材】【だいじなもの】等のルートメニューを作成。

メニュー画面→アイテム→【素材】→ミミズ

これもアイテム表示プログラムに比べたら楽ちんなので
すぐに終わるかと思っていたら、

すぐには終わったんですが、
レスポンスの人がまた邪魔をしてきました。
ソースをいじったり削ったりしてもモッサリ感がぬぐえないんです。

最悪、アイテム表示欄のデザインごと変更する事も考えるくらい
煮詰まるところまで煮詰まりました。
そして、もうろうとした意識の中、ソースを適当にいじる事少々。


ほんっとーうに、偶然なんですが、
アイテム表示時にともなう効果音やウェイトの位置を
プログラム中で変更しただけでモッサリ感が無くなりました。
（正確には無くなっているように感じる）

具体的に説明するのは難しいのですが、
例えばカーソルが右から左へうごくプログラムがあったとして、
どうしてもカーソルが左へ行く時に処理落ちするとします。
その時に効果音をわざと遅らせて鳴らすとか、
左へ到達した瞬間ではなく少しずらして鳴らすとかだけの事です。


ちょっと長くなったので、
以前から考えていた、効果音がもたらす「気持ちいい効果」と合わせて
考えがまとまればまた続きを書きたいと思います。

まとまれば。

開発ノキオク18 ～美しいプログラムと腱鞘炎～

アイテム表示第一段階完了。･･･？

データ入力900回やりとげました。
海内ドラマヒーローズのセリフの「やったー！！」の気持ちが今ならわかります。


おかげで、
450回目あたりで腱鞘炎（けんしょうえん）になりそうでした。
さらに、526回目あたりで小学2年生の頃の記憶を失いかけました。
さらにさらに、727回目あたりで猫に好かれる体質になりました。

(|||ﾟДﾟ|)＜ゴフッ

無事やり遂げたと言いつつも、
やはりいつものようにデータが膨れ上がることになりまして･･･


たとえば、通し番号でアイテムを管理しているのですが、
そこには後々アイテムが追加される事を考えてデータ間に余裕を与えています。
すなわちその余白にはアイテムデータ（アイテムグラフィック）はまだ存在しないのですが、
アイテム表示システムを完成させた後にデータを追加するならば、
その余白にもダミーデータを入れておく必要があるんですね。

なぜダミーを先に入れるかと言うと、
そうしておく事で後からデータを追加（変更）する際に
ダミーだけいじればアイテム表示システム全体に適用できるからです。

そんなわけでダミーデータの作成（適当だったけど）をしてるうちに
少しだけデータ量の最大値も変更したくなったりと手を加えました。


次に、前回まで組んでいた仮の表示プログラムの軽量化。
これはプログラム的に美しくないというか、精神衛生上の問題ですかね；；

結果的には半分近くまでソースを削ったので、
理論上は物凄く軽くなった（と信じたい）はず。

低スペックPCで動作速度を計測したわけではないので、
軽量化する必要があるのかもわからないのですが（なんじゃそりゃ）
無駄があるのならば削ろうという脅迫概念が昔からあるんです。
その辺の考え方はMSX-BASICで嫌というほど叩き込まれました。
うっうっうっ（←泣いてる音。ウマウマでは無い）


美しくないプログラムというのは、
・無駄に長く、
・不必要な命令や変数が存在し、
・ゆえにハードウェアの処理能力に頼りきっている。
こんなところでしょうか。


しかし、2つめの【不必要】なっていうのは、
プログラムを軽量化する際の結果論でもあって、
プログラマーやデバッガー側に立って、
作業効率の向上やプログラムのわかりやすさの事を考えると
必ずしも不必要とは言えないのです。

要するに、
ハードウェアの処理能力の限界を見極めて、
その上で、プログラムを軽量化し、
全体の構成を把握した上でどれだけ作業効率を良くできるか。
これがプロデューサーやSEに必要な能力なのかなと考えます。


ほら、中国拳法だって習い始めたばかりの技でも、
最初は長く打ち、段々と距離を縮めていく事によって、
命中率と打撃力を養っていくじゃないですか。


それに似ていますな～（遠い目）

開発ノキオク17 ～プロジェクトS～

眠れない夜はゲーム作りですよ。
いやもう、むしろ深夜の方が作業効率が良いのです。
お目目ぱっちり。(*ﾟ◇ﾟ*)


さて、進行状況はというと、

アイテム名の取り込み完了と、
各アイテム数の表示完了。

なんか前回からあまり進んでないなorz、
とか思ってたらプロジェクト間の移植もやってました。


具体的には、
【フィールド】と【妖精育成】と【ステータス（アイテム表示を含む）】です。

といっても、この3つを同一のプロジェクトに移行しただけ過ぎないので、
RPGシステムの中枢【戦闘】がここに加わるまでは、
本格的なプロジェクト間のリンク作業は行えないんで大した事ないんですが。


また、今後の開発は一つのプロジェクト内で行う事になるので、
変数等の大まかな領域確保（プログラム言語でいう宣言？）も同時に行いました。


というわけで、気兼ねなく現在のプロジェクトを進行できるという事で、
再びアイテム表示の続きをやっております。

とりあえず、表示させるシステムは出来上がったので、
テスト用に取り込んだアイテム（10個くらい）を含め、
残りの全アイテム150個分の表示をこれから作ります。

まぁ150回似たような作業したらいいだけなんですが･･･
一度に表示されるアイテムの種類が6個なんで、

150*6＝900

なんですね。


んで、それが終わったらアイテム欄のスクロール機能ですね。



「諦めなければ願いは叶う」って、どこかの偉い人が言って






たような。

開発ノキオク16 ～ミミズから変数へ～

アイテム表示の骨組みは好調です。
アイテムの有無を調べる変数と、
画面に表示した回数を格納する変数が、
頭でごっちゃになり若干手間取りましたがすぐに解決。

といっても、アイテム表示画面に
4種類のアイテムの名前が出なければならないところが･･･


ミミズ
ミミズ
ミミズ
ミミズ

2時間、ミミズだらけの画面とにらめっこしてました∞(|||ﾟДﾟ|)


次はそのアイテムの横に個数の表示を作りますが、
これはステータスの表示なんかで何度もやってきた事なので
すぐに終わると思います。

んが。

ここで（というか今さら）
そろそろゲーム全体で使う変数を
まとめたほうがいいんじゃないかと思えてきました。

いやですね、
今の段階では各システムを独立したプロジェクトで構築してるんですが、
後々、一つのプロジャクトに移植する際に変数がかぶる事は明白なんですね。

今やってるプロジェクトの、アイテム所持の変数。
そして前回作った、妖精成長システムの変数。
この2つのプロジェクトで扱う変数が一番多いんです。

だから、前回の妖精成長システムを移植する事を考えたら
おそろしいほどの同じ作業を繰り返さないといけない事に気づいたわけですよ。


とりあえず変数とデータがまとめられれば、
今後の戦闘やフィールド、会話システム等が
一つのプロジェクトで開発できて時間が簡略できるので、
アイテム表示システム完了までにはまとめたい所存。