横浜通い
昨日、今日と、横浜通いしてます。1時間かかるのですが、普段は通勤時間が15分なのでついついその感覚で起きてしまい、昨日も今日も遅れてしまいました。さらに、今日は忘れものをして、横浜についてからトンボ返り。旅行に行ったわけでもないのに1日で4時間も電車に乗りました。。。
仕事でも何でもないので興味持ったものをテキトーに見て回ってます。興味のあるのはスクリプトと開発効率まわり。ついでにAI。以下、見た順に感想。
1日目の1つ目はスクリプトを使ったよって話。企画の人にかなりスクリプトを任せていたのがおどろき。いや、うちもほぼ全て企画の人がデータを打っているわけですが、そのほとんどで(?)汎用のスクリプトを使っているのが驚き。パフォーマンス的に問題なかったのかな。同時に動いているのが20個とかって話だから、そんなに複雑にならないような仕組みになっているのかも。キャラが20体出たら20個なんてあっという間に消費してしまうし。
それにしても、企画の人がスクリプトを書いていくという流れはよいのだろうかが気になるところ。確かに慣れれば企画の人もスクリプトは書けるし、複雑なこともこなせる。しかし、そうなるとバグのほとんどは企画の人が書くスクリプトが原因となる。プログラマの仕事を企画担当者の仕事に移したのだから当然のこと。いや、企画の人の作るスクリプトは品質が高くないことが多いので、バグは増える。結果、プログラマは楽になるけれど企画の人は辛くなる。ゲームのバグも増える。利点は、企画の人が作りこめるというところ。プログラマはシステムを作る人、企画の人はゲームの面白い部分を作る人、と、役割分担ができるということだ。…これが理想的だと言う人もいるけれど、僕はちょっと違うと思ってる。少なくとも、一定規模以上のものを作る場合、プログラマと企画担当者の仕事の境目はぼやけていたほうが良いと思う。環境を整えたからあとは面白いのを作るのは企画の責任です、とか、環境が整っていないから面白くできない、とか、そんなのは嫌だ。う〜ん、結局のところ、チームの状況に合わせて適切なものを選択するしかなさそう。どんなものを作るのか、それが新規なのか続編なのか、チームの各人の認識はどうなのか。で、その選択の候補とする以上、スクリプト周りはしっかり整備しておこう。
1日目の2つ目は、効率化のためにシステム整えようぜって話。規模的に以前のうちよりちょっと大きい程度なのに、既にいろいろとシステム化されているのは素晴らしいと思う。他との比較ができるだけでもいろいろと得るものは大きいので、発表することに意義がありますね、ホント。で、今後の展望としてシステムをより整えるために専用の部署を作るって話だったけど、そこにはちょっと懸念を持ちました。人数が少ないうちはうまくいくと思うけど、規模が大きくなってくると、即役に立つものが必要なタイトル開発部署と、将来的に役に立つはずのものを作らなくてはいけない技術部署との連携が難しくなるのではないかと。そのあたりうまくやって欲しい。うまくいったら是非続きが聞きたい。
1日目の3つ目、AI設計について。技術的な話ではないけど、こうやって作ってますよっていうのは聞いていて面白いし、いつか役に立ちそう。特に研究や、やってみました的な発表とは違い、実際に動いているものを作った人の発表は貴重。実際に作り上げるためには、知識、技術力以上に、経験というものが役に立つと感じているので余計に。とはいえ経験談を聞いただけで自分のレベルが上がるわけではないので、これをどうにか自分に反映させなくちゃ。
1日目の4つ目、毎年ゲーム出してるよって話。すごいの一言。一つ一つは別に目新しいものではなく、どれもやればできると思うというものばかり。しかし、そういったものを一通り導入し、実際に活用しているのがすごい。例えば、リンク速度向上のためにPCを64bitのOSにしてメモリをたくさん積むと言う話。開発者としては手間がかからず環境を向上させられる素晴らしい手段。発表でもさらりと流されていた。しかし、これって普通はなかなか難しいと思う。効率上げるために高いPCが欲しいですと申請しても、上の人に渋い顔をされる。そうなると、開発初期はリンク時間なんてたかがしれているので、「もしかしたら今回は大丈夫かも…」なんて思ってしまい、申請を取り下げてしまう。あるいは、そこで引かずに強く申請したとしても、トップに届く前に途中で似たようなやり取りが行われて却下されてしまう。つまるところ、チーム全体、もしかしたら会社全体で、トータルコスト削減のためには開発環境の充実にコストをかけるべきことを認識していなくては、こんなことはできない。そのあたりはさすがセガってことなのかな。よくミドルウェアやツールの利用者として紹介されている。会社全体で常にそういう認識のもとに動いているんだろう。うん、このセッションで紹介されたものは是非取り入れたい。ちょっと動いてみよう。
1日目の5つ目は、アジャイルの話。最近、スクラムって言葉をよく耳にするし、前回のプロジェクトの作り方が非常にまずいなと感じたので興味があります。セッションの中味はパネルディスカッションみたいな形で、スクラムの説明も短く簡単なもの。でも、なんとなくわかった気がします。全然わかってないのかもしれないけど。チームのモチベーションを下げずに開発していくのにいいかも。今は、なんというか各人が作業者になってしまっていて、これだったら外注でいいじゃんと感じてるので。これが良いか悪いかわからないのでとりあえず導入してみたいけど、現在の自分の立ち位置がわからないし、上の人の賛同を得るのが難しそうなので、とりあえずこれを意識して動いてみよう。僕が飽きずに、そして周りものってきたら導入できるといいなぁ。
2日目の1つ目は、処理負荷軽減とかマルチスレッド化の話。処理負荷対策は、判断の材料を用意しておこう、原因や対策のパターンを考えておこうという話。うんうん、まったくです。処理負荷はみんな意識しないといけないと思う。結構、「最後に誰かがなんとかしてくれる」と思ってる人が多い。確かに、最後になるまで手をつけにくいので最後になんとかするものなのだけれど、そのための準備なり意識なりすることでもっと楽になると思う。マルチスレッド化は、ごく当然の、依存関係の整理や、SPUで走らせるための工夫についての話。とは言え、頭では分かっていても実際にマルチスレッド対応のコードを書いたことがないので参考になりました。欲を言えば実際にコードを見たかったけど、コードの解説を始めたらとても時間内には収まらないか。マルチスレッド化によって相当処理が軽くなったみたい。う〜ん、次のプロジェクトでは対応必須か。設計にかかわってくるのでこれは早めに勉強しておかなくちゃ。
2日目の2つ目は、ギャラクシー。なんというか、このシリーズを作っている人の話を聞けるというだけでもとをとれます。昔話、自慢話、なんでもいいです。おもしろいもの、売れるもの、すごいものを作っている人の話はそれだけで価値がある。で、中身は、作る際にこういうことを意識しましたよと言う話。いろいろ参考になりました。特別なところなので、うちとは違う特別な作り方をしているのかと思ったら、全然そんなことはありませんでした。作り方の方針は同じ。それで出来上がるものに差があるのは、丁寧さとか手間の掛け方の違いなんだと思う。能力の違いっていうのはきっと言い訳。ただ、それに敬意をはらっても、まるっきり習う必要はないと思う。いっぺんの隙のない丁寧で安心して遊べるゲームも、いろいろと穴だらけだけど魅力的な尖った部分のあるゲームも、どちらも良いゲーム。自分達の得手不得手を認識して作ってけばいいんだと思う。…それにしても、ずいぶん少ない人数で作っているのだなと思いました。作り方がうまいからなのか、SDだったからなのか。
2日目の3つ目は、AIのだらだら話。あの人数であの時間では、ラウンドテーブルは無理だと思う。まして、一人1分とか言われてしまうとよっぽどの喋りたがりじゃないと発言できない。僕は喋りたがりだった。。。一部の人しか話さないことを前提にがっつり話をさせるか、ラウンドテーブルは諦めて、1つ2つの項目の発表の方がいいんじゃないかな。発表者が毎回固定されていて準備が負担なのであれば、準備無しに最近の動向の雑感を話して、あとはMLやブログの紹介にとどめるだけで十分だと思う。受身の人は発表を聞くために来ているし、そうでない人は別の場を紹介してもらえればあとはそっちで暴れるだろうし。魅力的な内容だけに、ちょっと残念でした。
ひとまず以上。明日で横浜通いも終了。帰りに崎陽軒の餃子を買ってこよう。
