開発ノキオク21 ～ありがとうチャート表～

やっとこさアイテム表示のメドが見えてきました。

いやほんと、脳汁が足りなくなるんじゃないかってくらい
脳みそをこねくり回していました（要するに慣れない頭を回転させたという事）

おかげで↓こんな感じで夜眠るのも一苦労でしたよ。


具体的にはシステムの骨組みは出来上がったので、
後はバグ取りという段階です。

ここからはアドレナリンの続く限りモチベーションが保てます。

バグ取りっていうのは、（不完全な）システムを「否定」する工程だと思います。
ほら、人同士でも論議をする際に「否定」する方が簡単じゃないですか。

この場合は、システムを組んだのが自分なので、
自分の揚げ足を取って、システムを正していくという事になります。
その結果、自分が組んだシステムが完璧に近づいていくわけですから、
楽しくないはずがありません。
（人のプログラムのバグとりは違うだろうけど）



さて、そこに行くまでに最近気づいた事をメモ。

システムを組んでいてバグ取りの一歩手前で起こる
「致命的な欠陥」を知らず知らずの内に生み出している事があります。

バグ以前に、とりあえずソースは書いたけどまったく動かない状態。
そして、そのソースのどこが悪いのかわからない状態。

で、結果論ですが簡単なミスだったりするんですよ。

そこで、
今まではプログラムを頭の中で組み立てて直接ソースを打ち込むという
スタイルでやってきたんですが、
ここに来て初めてチャート表を書いたりしました。


（といっても、その場しのぎの落書きですが）

チャート表っていうのはプログラムの設計書の事で、
それをあらかじめ作っておくことで、
ぱっと見で変数とか分岐とか全体の処理がわかるので、
複雑なプログラムほど必要になってきます。

というよりプログラム組む前にチャート表を作るのが常識ですorz
（どんなプログラム書籍でも最初に書いてますね）

というわけで、
書かざるを得ない状態まで自分を窮地に追い込み、
結果、チャート表の偉大さを知ることとなりました。

ありがとう、チャート表。

そして、戦闘プログラムの時には
先にチャート表を作ってから打ち込もう･･･と思う我輩であったとさ。

開発ノキオク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

なんですね。


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



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






たような。