成長期 Archive

 

すでに昔のソースが読めません。

年々、自分なりにソースを簡略化しているので、

昔の長いソースが読みにくい。

自分の書いたソースとはいえ、

癖が変わっているんですね。

成長しているかどうかわかりませんが、

自分のソースの解析に時間を取られます。

なんか無駄な時間を過ごしている気になりますよ。

メインの部分のプログラムを進める事は
もちろん当然なのですが、
チームに完全に入りこんだ今回は、

他の部分のソースの解析が必要に。

前作までのチーフプログラマーが抜けた部分を、
ある程度、引き継いだわけですが、

思い通りにいじれない。

これまで作ってきた部分は、
実はプログラムの繋がりとしては

一人ぐらいしか繋がっていませんでして、

そのうえに自分のソースの中で完結しているので、

自由に作れていたんですね。

しかし、今回の引継ぎは、
残していただいたソースの中に、

周り全員が汎用して使っていた関数やら、
グローバルできられていた変数やら、

自分の部分なのに変更できません。

この状態はとてつもなくややこしいです。

なので簡単に触れないですし、
新しくなる部分の絵などが来たら、
できるだけ前のソースを使いまわしつつ、
作っていかなければなりません。

間違いなく新しく作った方が早いです。

ですが、そうもいかない為、
必死でソース解析をするわけですね。

バグが出ないわけがありません。

見落としとか作り方を少し換えるだけで、

Ａバグがでます。

初期化の箇所を変えるなどが、
これ系のもっともバグが出やすいパターンです。

unsignedの中にマイナスを入れてしまって、
反転してから初期化したり。

よくあるミスです。

まあ、今の世の中、ほとんど整数型を使っていると思いますが、
古いプログラマーの方などはu16やu8などを使っている方が多いので
（容量を減らす為）

危険です。

せめてs16とかs8にしてくれるといいのに・・・・・・。

ちなみに、今のシステムはu16やu8などのunsigned系を
いったん整数に直す処理をするので、

実は処理が重たくなったりするので注意です。

まあ、ゲーム機の容量も大きくなったので、
基本的にはintなどの整数型を使った方がいいですね。

でもfloatやdoubleなどの少数型は重いから使いたくない。

同様に簡単な掛け算や割り算もシフト演算ですから、

自分も古いプログラマーになってきたのでしょうか？

軽いって教えられて、育てられたので・・・・・。

これに近いプログラムで、一つの型を細かくビットに
分けて使っていらっしゃる方もいられると思います。

これが見つけにくい。

普通に値を入れると、オーバーしたりするので、

簡単にバグが発生します。

昔は容量を削るのが大変だったんだなと感じながら

修正する事になります。

自由に使えるって良い事です。

こんな感じで、ソースを引き継ぐというのは

大変だったりします。

歳が近いと、ソースの書き方や使い方が似ているので、
まだ、歳が離れている方に比べれば読みやすいとは思いますが、

ミナミのソースは、すでに読みにくいです。

読みやすくなる日が来るのか・・・・・・。

掛け算や割り算のシフト演算も、

過去の遺産になってしまうんでしょうね。

なんで、こんな無駄な事をしているんだろうと
言われる日が来るんでしょうか？

その時は世代交代です。




こんな事をやってます。
関西在住で募集中。

 

最近、お会いする方と話をしていて、
参考書の話になる事が多いので、

少しだけ番外編です。

まあ、「現在使っている参考書」のカテゴリー方にも
書いてますが、とりあえずまとめておこうかと。

自分なりに便利な本を見つけるのが一番なのですが、
学生さん達の参考になればいいかなと思います。

とりあえずメインで使っている本はこれです。

「Ｃ言語によるプログラミング　基礎編」

これは今でも、調べ物等の時に使っていまして、
初心者向けでいて、本当に教科書です。

ダメプログラマーでも何とかなった１冊で、
これを買った以降は、

他にＣ言語の参考書は買わなくなりました。

本当に基礎なので、技術がある人は買わなくてもいいと思いますし、
逆に心配な方は１冊ぐらい持っていてもいいんじゃないかと、
個人的には思っている１冊です。

本当に１冊が太いので、他の参考書に比べて読みやすく、
細かい部分もわかりやすく書かれているので、

使いやすいですよ。

次に上記の本の発展編となりますが、

「Ｃ言語によるプログラミング　応用編」

基礎編は本当に基礎なので、
ビットシフトやポインタ等などは書かれていません。

使えなくても何とかなりそうですから。

しかし、それらを使わないとダメな事も間違いありません。

それらをわかりやすく、そして基礎から応用への

橋渡し的な役割になるのがこっちの本ですね。

こちらも、メインとして使っています。

これは基礎編とセットで持っておくのがいいと思います。

個人的にはＣ言語はこの二冊と、アルゴリズム辞典があれば、

何とかなると思っています。

この上に、もう一冊ありますが、
個人的にはこの二冊で何とかなると思うので、
特に必要はないかなと思います。

次にややこしいポインタ関連ですが、
これはこの本を使っていました。

「Ｃ言語　ポインタ完全制覇」

参考書というよりも、使い方が詳しく載っている本で、
入門書には使いにくいので、Ｃ言語の力がある程度はいりますが、
ある程度の知識を持っていて、ポインタがわからなければ、

読んでみてもいいと思います。

もちろん、自分でポインタ使うのも大事ですが、
これを見ながら作っていくとわかりやすいと思います。

最近の主流であるＣ++に関しては、

「C++クラスと継承完全制覇」という本を使って基礎を固めて、

「C++プログラミングスタイル 」で、普段は確かめています。

とりあえずはこんな物でしょか。

ミナミのようなダメプログラマーでも、何とかなる本で、
技術と知識がある方は逆に使いにくい本かもしれません。

参考になればと思って、今回は書きました。

いや、まあ、実際に聞かれた時に、

本人が名前を忘れているから、書いておこうと思っただけなのですが。

全体集会がある時は、
だいたい後ろの席に座ってます。

特にメモもしていませんし、
全ての事は後で、議事録を見ればいいので、
目立たない場所にいるのが一番です。

なんだか学生みたいですね。

まあ、学生時代はサボれましたが、
今はそんな事ができないので、

面倒臭そうに行ってます。

ちなみに開発末期は忙しいので、

かなり行きたくなかったりします。

テレビ会議とかで、何とかなりませんかね。

二回目のミーティングは、
まず席の順番から考えました。

前回座った位置はマズイ・・・・・。

学生時代、教室では、授業中に先生に
当てられやすい席と当てられにくい席がありました。

先生の視界から向かって左。

人の目は右から左に行き、再び右に行くので、
とりあえず二列しか無い席で、
司会者であるプロデューサーの左側に。

しかも、後ろから二番目。

両端に挟まっている方が、
目立ちにくいという理由です。

あきらかに必死になる部分を間違えてます。

まあ、いつだって方向を間違えているんですが。

そんなわけで、前回は自分の想像と離れていたので、
なかなか自分らしさを発揮できませんでしたが、

今回は前回の教訓を生かし、
目立たないように、しかし、ポイントポイントで、
意見できるようなスタンスを取ろうと思っていました。

やっぱり、必死になる方向を間違えてます。

相変わらず、おおまかな進行はプロデューサーと、
ゲームのメインを担う方で進んでおります。

だいたい、どのチームにも、そういった方おり、
その方の案に味付けをしていくのが、
その周りの人いった感じです。

その方がいられない時は、
ミーティングをしない事もあり、

本当に重要な方であります。

なので、意見に乗っかりながら、
自分のしたい事を言うのが、

うちのチームのポイントです。

皆さん、漁夫の利を奪うのが得意ですよ（自分を含めて）。

しかし、今はそんな感じですが、
当時は第一回目のトラウマもあり、

おとなしくしているのが、ミーティングのコツでした。

どこのチームでも、そんな方は面談で、

もっと意見を言おう

とか言われます。

普段の性格が明るかったらなおさらです。

というわけで、ミーティングで目立たないようにする為には、
普段から目立たないようにしておくといいですよ。

それが将来的に良いのかどうかは・・・・・・・。

ミーティングは次回は何をするかが、
今回のメインの議題になりました。

これはしたい事を言い合うだけの、
ブーレンストーミング形式でして、

本当に言いたい放題です。

なかには「うわ～」と思う意見もありますが、
この場合は、意見を言わない方がダメなので、

黙っている方が悪者です。

目立たないようにしたい人間にとっては、

とてつもなく迷惑な会議形式です。

でも話の脱線率が高いので、

違う部分で楽しかったりします。

ブーレンストーミングは基本的には、
時間があっという間に過ぎてしまいます。

まあ、言いたい放題言って、
その度に脱線していますからね。

メイン２、脱線８ぐらいです。
２時間中、１.５時間ぐらい雑談です。

こうやってゲームは作られます。

なんだそれ？と思うかもしれませんが、
明るい雰囲気じゃないと良い案は生まれません。

本人達が楽しくないと、いいゲームにはなりません。

なので、進まなくてもこれで良いのです。

後々、ミーティングの時間がなくなって、
切羽詰るのも、いつも通りです。

仕様が細かい部分でまとまらないのは、そのせいですね。

毎年、後悔してます・・・・楽しいですが。

二回目以降はこんな感じで、
ミーティングは進みました。

初めての作品のミーティングは、
こんな感じで全体的には大人しめでしたね。

今もスタンスは変わりませんが、

言いたい事は言ってます。

やっぱり経験が必要な世界。
いろいろやる事が次に繋がります。

というわけで、次回からは、
再びプログラミングの話に戻ります。


こんな事をやってます。
関西在住で募集中。