成長期 Archive

さて、スクロールアクションで
最初にはまるプログラムの二発目です。

ちなみにこれはミナミが勝手にはまっただけで、

通常の方はまったく問題にならないかもしれません。

よく躓きますから。

専門学校時代に作ったゲームと同じように、
スクロールアクションでも問題になったのは

死んだ時に復活する位置。

マリオみたいに、死んだ場合、
画面を切り替えて固定の場所からスタート等など、

かなり簡単ですが、

今回やろうとしていたのは、
死んだ画面から切り替えずの復活だったので、

復活→即死亡がありえました。

普通はいろいろ対処方法があります。

レースの時に作ったのは

・無敵時間を入れる
・落ちた場所から少し画面をズラす

この二つで誤魔化しましたが、
無敵時間を入れるのはいいとして、

画面をズラすのは子供騙しです。

自分は許しても、周りが許してくれません。

これ対策としては簡単で、
当りを持っているのですから、
死亡する当り以外の部分を検索し、

復活した自機を安全な位置におけばいいだけなのです。

なのに、なぜそれをしなかったのか？

面倒臭そうだったから！

二年目の新人が何か言ってます。

言い訳しますと、その安全な位置が果たして、

本当に安全かどうかを判別するのが難しい。

プレイヤーとしてはそんな所に置いて欲しくない場所もありますし、
敵がいた場合はハマる可能性があります。

敵がいた場合は、どんな状況でもハマる可能性がありますが。

なので、それらを全部考えると

プログラムが大変になる。

限界に挑戦しようとしない新人って、どうなんでしょうね。

そういうわけで、ミナミ出した結論は、

死んだその場から復活！
無敵時間を長めに！

プレイヤーの意思を尊重します！

そんなゲームもあるからいいよね。

ちなみに落とし穴系は

全てカット！！

落とし穴は罠等に全て作り直し、

自機が画面から消えない仕様に！

罠で死んでも無敵時間の間に抜けてもらえれば大丈夫です。

チームの人への言い訳は

アクションゲームが苦手な人でも、
無敵時間を使えばクリアできる仕様にしましたとさ。

いつか作り直す機会があれば、頑張りたいと思います。

こんな感じでミナミ的、スクロールアクション問題の２個目を

誤魔化し・・・・解決しました。

基本、専門学校から進歩してません。

しかし、意外と好評でして、

そんな裏話があった事は今でもバレてません。

まあ、バレても問題ないですが。

次回はミナミ的スクロールアクション問題の３個目を。

まだ、あるのかよ！

ゲームを崩壊させるバグを仕込み、
その事に気付かず、終わったと喜んでいたミナミ。

前回の話のバグはバランスブレイカーとなり、
後々、大問題となるわけです。

とはいえ、二年目のバグよりマシですが。

基本的にデザイナーさんに絵を描いてもらわないと、
深い仕事はできないわけで、

デザイナーさんが持ってきた絵の順番に仕事をしていきます。

もちろんシステムなど、絵が関係ない部分などは、
先に作っていきますが、基本は上記の通りです。

なので、終わったと思いきや、次の仕事がやってきました。

本来（現在）なら、１日で終わる仕事。

１週間近くかかったら、次の仕事もやってきますよ。

今度はアクションゲームの絵達。

ミナミはそれまで学校で、
レースゲームやシューティングゲームは作ってましたが、

この時、初めて、ステージアクションゲームを作る事になります。

MAPの持ち方とかよくわからない・・・・・。

アクションゲームを作る時に置いて、ぶち当る壁。
プログラムがわからないのは勉強すればいいとして、

まず、上記に書いたMAPの持ち方。

MAPの表示はなんとかできますが、

MAPの当りの持ち方がわからない。

ずっと平面なら、問題もありませんが、

今回は上下左右のMAPの当りが必要。

さて・・・・どうするか？

今ならツールで、もらった画像から、
当りをテーブルにして吐き出して、
それを読み込むだけですが、

当時のミナミにそんな芸当は不可能。

なので、やった事といえば、
敵がいなくて、プレイヤーが自由に動くMAPで

地味に細かくドットを調べてました。

５ステージぐらいあったので、

かなり時間が・・・・・・・。

しかも、途中までスクロール無視で、
画面に映っているドットの当りを調べていたので、

やりなおしのハメに。

何をやってんでしょうねコイツ。

ステージアクションゲームを作る時は絶対に、

グローバルなMAPの変数がいります。

画面表示の変数とは別で、全体を通した変数がいるのですが、

それを忘れて作っていたというわけです。

こうやって人は成長していくわけですね。

無駄な時間を使って。

ちなみに、この方法は

人間なので当然ミスをします。

ツールで吐き出した物は、やはりプログラムなので、

完璧な当りをとれていますが、

自分で調べると

当り抜けが当然のように発生し、

調べなおしをしなければならなくなります。

無駄な時間を使って。

こうして、ミナミの初めての

ステージアクションゲーム作りが始まりました。

次回は２個目の壁について書きたいと思います。

本当に遠回りな事をしているなあ。

２００９年度の成長期を始める前に、
ちょっとしたまとめを。

久しぶりなので、前回までどうなっていたかというと・・・・

２年目の初めての開発で、

どえらいバグを仕込んだ。

この一言でまとめ終了です。

実際にこのバグでゲームはバランスブレイクし、

ミナミの社員計画もブレイク寸前になります。

という話でした。

まあ、ブレイクせずに何とかここに居るわけですが。

成長期という事ですが、今も（2009年も）それは継続中でして

今はデーターのバイナリ化＆読み込みで四苦八苦してます。

普通のデーターを読み込んだり、エクセルファイルを読み込んだりなどの
最低限のことはできるのですが、
ゲームプログラマでもシステム側の人間ではないので、

圧縮とかバイナリ化とか解凍してからの読み込みとかは

ほぼ無知でした。

ええ・・・・参考書との格闘の日々。

Perlがやりやすいのか、それともJavaがやりやすいのか、
やっぱりCで作った方が速いのか、作っては失敗し、
解凍したデーターを組み込む為にソースを改造し、

取り出してみるとデーターが間違っていたり、

それを修正し作り直すと、

連鎖バグで違う所がバグったりと、

進んでいるようで進んでいない日々です。

成長してませんね。

そして今回思った事は言うと、

「システム担当の人間に全てを任せていると痛い目を見るぞ」と。

自分の担当じゃないとか言っていると、
こうやって突然仕事を振られたりして、

逃げたくなるので注意です。

でも、何とかもう終わりそうですが・・・・・無知は大変。

こんな、まだまだ成長中のミナミからのご忠告です。

エキスパートになるのもいいですが、

少しはオールラウンダーになっておきましょう。

何があるかわかりません。

実はこのあたりって、

個人的には関係ないので勉強とかしてなかったりしてたんですが、

今回、いろいろと勉強するハメになりました。

こんな事に時間をとられない為にも、
やり方ぐらいは頭に入れといた方がいいと思われます。

いや、本当に。

そんなわけで、今も成長期まっただ中のミナミでした。

 

 

軽く前回の続きからです。

なんとかよくわからないシステムから逃れたものの、
デザイナーさんとしては、その画面を一新したい。

新人に何を期待しているのやら。

それまでの画面はカーソルを合わせてボタンを押すだけの、
単純なお買い物画面でして、データ整理さえできれば、
そこまで問題なくできます。

当時のミナミは、前担当者のソースをいじっているだけだったので、
まだセーブ・ロード関連を自分で作ってはいなく、

データーの整理なんてほぼしてません。

そんなミナミも今はデーター管理の責任者になっています。

そんな単純な画面だったので、新人のミナミでも、
変更可能だろうと担当を割り振られたのですが、

そんな大幅に変更するなんて！

話が違うぜ・・・・・デザイナーさん。

ただの買い物画面を

スロット風にするなんて！

考えが飛びぬけてるぜ・・・・・デザイナーさん。

というか意味がわからない。

買い物 = スロット　の意味がわからない。

飛びぬけたセンスがあるから、デザイナーになれるのですね。

そんなわけで一から作り直す程、

プログラム力があるわけでもなく、

前の担当者のソースを全部把握できる程、

プログラム読解能力があるわけでもないので、

前のソースを流用しつつ、なんとなくで作ってました。

もともと単純なプログラムな事もあり、
変更はしやすかったのですが、
それでもなんとかデザイナーさんの注文通りの物を作り、
OKをもらいました。

たぶん今なら１から作り直して１日で終わらせるプログラムを

１週間もかかりましたけどね。

しかし、本人は何とかなったのでホッとしていて、

完全なチェックをしなかったのです。


だいたいソースをしっかり把握しないで作ったプログラム。
どんな変数を使っているかなんて、

細かい部分は見ていません。

その変数に数字を入れているのはわかりますが、

どのように宣言されているかなんて、

見てなかったりします。

実際にプログラムを把握していると、

細かい部分まで目が行きますが、

把握していないので、

面倒になって、解析をやめてしまうんですよ。

だから大変な事になったりします。

符号なし整数型にマイナスを入れたり・・・・・・。

プログラマの皆さんはわかりますよね？

これがどれだけ大変な事か。
これがどれだけ初心者ミスか。

前の担当者がunsignedで宣言していまして、
マイナスにならないように組んでいたのですが、

ミナミはそれを知らずにマイナス判定を下にズラした。

だから、とんでもない値になり、

暴走していまいました。

このどえらいバグが発見されたのは

発売後。

今でもトラウマです。

これ以来、ミナミはunsigned型を

一生使わない事を心に決め、

そのような宣言を見つけたら、

すべて符号ありに変えています。

だいたい今のゲームの容量なら、

unsigned型にしなくも問題はありません。

そんなわけで今回はトラウマになったお話でした。

皆さんも気をつけましょう。

今は逆にオーバーフローしてる時がありますけどね。

 
先日、ＳＥの方とお話をしていて、

やっぱり違う職業だなと再確認。

プログラムが全然違うなあと感じました。

ただ、しんどさは置いといて、
どっちも楽しそうと感じたのは。

やっぱりプログラムが面白いからですかね。

ＳＥのプログラムもやってみたいかもしれません。

「ミナミ君。ここはこれで作ってくれへん？」

と、ある突然言われたミナミ。

とりあえずポカーンとしていました。

何を言われたかというと、「ラスター」を切ってくれと。

ラスターって何ですか？

フルネームはラスタースクロールというらしく、
今なら聞いても何となくわかりますが（というか今でも）、
当時は初めて聞いた言葉に、

何を言っているんだ？

という表情で固まっていました。

細かい説明はよくわかりませんが、
この「ラスター」を簡単に言えば、

横のラインの制御で、いろいろなアクションをする

みたいな感じだったと思います（本当に適当です）。

間違っていても、合っていても特に覚える必要はありません。


なぜなら、この機能、ハードウェア依存の為、

そのハードにはもうない事が多く、

すでに絶滅しそうな勢いだからです。

なんか、そんな感じという程度で覚えていればいいでしょう。

例にもれず、その時のハードにそんな物はなく、
（あったのかもしれませんが）
そのうえ、それが何かもわからないミナミ。

何をしていいか、さっぱり状態。

何かデザイナー同士で話をしているのを横で、

ポカーンと聞いてました。

知らないのに意見が言えるわけがありません。

向こうは向こうで、「こういう使い方をした方がいい」とか
ラスターの使い方を相談していたようですが、

それ自体何かを教えて欲しかったです。

そんな状態を意外な人物が、

もっともな意見で

打破してくれました。

それは当時のプログラムチーフ。

「それは、こっちの方が楽で簡単ですけど」

何が簡単で何の話をしているかわかりませんでしたが、

ＯＢＪの優先度で処理するという方法で何とかできるらしく

むしろ、それで何とかできる物を

さっきまで何で話し合っていたんだ？

とか思ってしまう、必殺の言葉でした。

というか、本当に何だったんだでしょうか？

新人はこうやって聞いたこともない仕様を

突然、聞かされる時があります。

特に上のようなシステム側の話なんて、
システム側のプログラムをやってないと

本当にわかりません。

なので、いつでも話ができるように、
いろいろと知っておく方がいいのかもしれませんね。

今回もプログラムチーフの言葉がなかったら、
本当に大変な作業になっていたかもしれませんし、

というか終わってなかったかと思います。

たぶん次年度はクビだったんじゃないでしょうか。

まあ、プログラマが全員なんでも知っていると思ったら、

大間違いですから。

どっちが間違っているかというと、

知らないダメプログラマのミナミが悪いんですけどね。




ちなみに、この話は今でもよく起きています。

知らないシステムなんて、まだまだ大量にありますよ。