現在使っている書籍 Archive

 

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

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

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

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

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

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

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

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

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

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

ただの買い物画面を

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

見てなかったりします。

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

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

把握していないので、

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

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

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

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

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

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

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

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

暴走していまいました。

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

発売後。

今でもトラウマです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ラスターって何ですか？

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

何を言っているんだ？

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

もっともな意見で

打破してくれました。

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

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

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

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

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

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

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

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

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

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

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

本当にわかりません。

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

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

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

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

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

大間違いですから。

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

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




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

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

今回とあるメニュー画面を作っていて、
ほぼ今の状態（開発中期）で確定だと思い、

プログラムをガチガチに作っていたら、

開発末期に修正がかかりました。

修正が本当に大変だった・・・・・・・。

ガチガチに作るのは楽なんですけどね～。

初めてメニュー画面を作っていた時に、
完成したのでデザイナーさんの方に持っていきました。

今は作った後、本人が見るまで放置していますが、
当時は画面を構成した人に完成すると見せていたんです。

いま考えると、いちいち面倒な奴ですね。

ですが、そういう画面は基本的にはプログラマの意思よりも、
デザイナーの意思の方が優先されると思っているので、

後で作り直して面倒になるよりも、
そのプログラムを組んでいる流れで作った方が、

記憶に新しいので楽です。

しばらく後で作り直したら、忘れてますから。

そこで２０行３列で表示する組むプログラムがあって、
１画面に収まるように作っていました。

その上をカーソルが動くのですが、ミナミ的には

右端まで行ったらカーソルはその段の左端に戻る

のがスタンダートだと思っていたんですよね。

しかし、それを画面構成したデザイナーさんに見せた所、

右端まで行ったら、カーソルは一段下の左端に行く

という物に変更して欲しいと言われました。

なんか不思議・・・・・・・。

右端まで行ったらカーソルと止めてならわかるのですが、
下に行くとは思わなかったです。

順番に並んでいるので、言われている事はわかるのですが、

「下に行くんですか？」

と何回も聞きなおしてしまいましたね。

何か気持ち悪い。

じゃあ、２０行目の３列目まで行ったら、
上に戻るのか？と思いきや・・・・・・

そこは止めるようです。

やっぱり何か気持ち悪い。

しかし、そこはデザイナーさんの意見を尊重し、
その動きにしてみました。

でも、やっぱり気持ち悪い。

そこから、他のメニュー画面を作る事もありましたが
そのデザイナーさんの画面では、

ほぼ、その動きをして欲しいようで、

今は作る時は何も言わずにその動きにしています。

カーソルを動かす共通関数がニ個あって気持ち悪いです。

どこかでプログラマーのクセの話をしましたが、
デザイナーさんにもそういうのがあるのです。

関数増えるのは管理が面倒・・・・・・。

そういうわけで、担当してもらっているデザイナーさんの

小さな主張にも対応するのがプログラマの役目なのです。

ええ、気持ち悪い動きでも、作ってくれた人の考えがあるのです。

ちなみに、いつの間にか慣れてくるので、

今は何とも思いませんけどね。

そういって、デザイナーさんの考えも覚えつつ、
仕事を進めていっていた当時のミナミ。

デザイナーさんの凄さを、さらに感じる出来事がありました。

さて、それは何か？

「うん・・・・・・ナニソレ？」って感じのお話です。

 
今年はわりと大人しかったです。

大変になる事はわかっていたので、
なんとかスムーズに開発を進める為にも

余計な事には反論しない

という事を心掛けました。

本当はダメなんですけどね・・・・・いいゲームを作る為には。

修行時代も含めると二年目ですが、
その作品が１作目にあたるわけで、

言ってみれば新入社員１年目と変わらないミナミでした。

契約はアルバイトですよ。もちろん。

なので、わりと自分の事で精一杯で、
今のように周りの分担を減らそうとか、
来年はあっちをもらおうとか、

そんな考えはまったくなく、

とりあえず目の前の物を終わらせるが一番の目的でした。

なので、まわりとの人間関係がうまくいってなかったとしても、
その時は問題なかったんですね。

まあ、周りと絡む部分が少なかったからなのですが。

今もできるならば個人で終わる部分で、
何とかできれば気分的には楽だなと思っているのですが、
やはりそうはいかず、担当する部分が増えれば増える程、
他人との関わりが多くなっていくので、

人間関係は大事になってきます。

特にゲーム開発がスムーズに行くかどうかは、
自身の腕とかよりも、

それの方が大事になってくるんじゃないでしょうか。

わからない部分を聞けたり、融通をきかせてもらったり、
人間関係が悪いと、そんな事はできませんから。

そういうわけで、一人だけ自分の世界に入って
プログラムを組んでいたミナミには、外の世界の事は

ちっとも関係がなく、

仕事が遅いデザイナーさんが、周りからのプレッシャーで

押し潰されそうになっていたり、

プログラムの師匠のチームが、デザイナーとプログラマで、

内部分裂していたとしても、

ミナミには影響がありませんでした。

席も一人だけ孤島でしたしね。

こういう時の新人は楽です。
わりと先輩や上司がなんとかしてくれます。
新人だから気せんでいいと言ってくれます。

自分がその本人でなければですが。

それが年々、周りの事も気にしながら仕事していかなくなり、
そして、その仲裁に入るようになり、

人間関係が面倒になってきます。

仕事関係ないじゃんとか思ってしまいますが、

開発をスムーズに進行させる為にも大事になってくるんです。

自分で精一杯だったミナミは、

「なんとか頑張ります」

というセリフを連発しながら、人間関係の問題から、

なんとか逃げようと必死で、

ひたすら目の前のプログラムを戦ってました。

会社って大変ですね。

まあ、完全に逃れるわけもなく、
新人という事で何にもしらないと思われていた為、

いろんな愚痴を聞かされてはいたのですが。

中立はこれがあるから大変だったりします。

とりあえず、この時期に学んだ事は

「敵は作らないようにしよう」です。

自分の為にチームの為にも。

次回は本当に久しぶりのプログラム＆ゲームの話。
とあるメニュー画面を作ったお話です。

操作方法って、けっこう自分は特殊だったりしますよ。

こっちの方が楽なのにと思っても、

みんながみんなそうではないという事ですね。

成長期を復活するにあたって問題は

「1ヵ月空いたので何も覚えてない」

という事ですかね。

厳密に言うと、２ヶ月以上書いてなかったので、
前に何を書いていたのかなんて覚えてなかったりします。

というわけで、自分で思い出すためにも、
現状をまとめておきたいと思うのですが、

現在（成長期で）は開発チームとして入ったばかりです。

解析で過ごした１年間の修行を終え、
これから世にゲームを送り出していくわけですが、

アルバイトです。

あれから今は数年経ち、社員にもなりましたが、
扱いはあまり変わってないのは

ミナミのプログラミング力がないからでしょうか。

もっと扱いが変わるように頑張りたいと思います。

それで前作を担当していた人からの引継ぎを受けて、
ミーティングにも参加し、何にも意見を言えなくて、

ソースの解析で躓き、

立ち止まっている状態のようです。

この時は担当している部分が少なかったので、
立ち止まれる時間もある程度ありましたが、

今はこんなにも立ち止まっていたら、

間違いなくミナミのせいで延期確定です。

立ち止まって１週間が限度かと・・・・・それでも長過ぎですが。

次にデザイナーさんに必要な絵を聞かれ、

無駄に一喜一憂している頃のようで、

今はよっぽどの事ではない限り、
デザイナーさんに任せていますが、
この頃は聞かれた事を嬉しがっているようですね。

そんな余裕もないクセに。

初めての制作が始まったばかりのようで、

ここからしんどい日々になるわけですね。

人間関係とかも面倒でしたし。

というわけで、ここまでの話
を簡単にまとめてみました。

次回は当時の人間関係について書きましょう。

面倒な事ばかりで、基本的に仕事とは関係ない部分で、

気をつかいたくないなあ・・・・とか思ったり。

会社に属するという事は大変なのです。