仕事納め

なんだかんだで2010年の業務も一通り終了しました。あとは家で出来る仕事をやるのみ。あ、あと確定申告の準備もそろそろ始めなきゃ……

今年の後半は、ブログを日課として復活させることを目標にしていたのですが、てんで達成できてません。やはり一旦ペースを崩すと復活するのが難しいみたいです。Twitterでのツイートさえもままならなくなるというのは、自分でも驚きでした。

そろそろ夏辺りから進めてきた仕事がいくつか形になり始めています。それと同時に、新しい仕事も何件か動き始めています。おかげさまで、また来年も当面は忙しいことになりそうです。

iPhoneゲームを20分間で作る【メダルプッシャー編】

こんな動画を作ってみました。Unityを使って20分間でメダルプッシャーゲームを制作するというものです。Unityのイントロダクションとしてどうぞ。

当初は10分を目指していたのですが、やっぱり10分は無理でした。20分に延ばしたうえで、iPhone上での動作確認までを含めるようにしてみました。

10分ゲームプログラミング（構想）

「Unityを使って10分間でゲームを制作する」というネタを、ちょっと考えてみている。台本付きで作るなら、実はそれほど難しくないかもな、と思う。

上は試しに、おやつを食べながら30分間ぐらいで作ってみたメダルプッシャーゲーム。間を空けずに詰め込んで作業すれば10分に収まるのではないかな……

Unityでunsafe codeは使えるか？

UnityのC#でのヒープvsスタックの話を書いてから、「unsafe codeが使えればもう少し簡単に高速化できる」というような話をいくつかいただきました。そこで問題となるのは、Unity環境でunsafe codeが使えるかどうか、ということです。

ちょこっと調べてみた限りでは、「Unity環境ではunsafe codeは使えない」というのが結論のようです。マニュアルに明記されてはいないのですが、「まあ使えないでしょ」みたいな書き込みがいくつか見つかります。

以前のバージョンではビルドスクリプトを書き換える事で対応が可能だったとか、そんな情報もありましたが、それもweb playerでは使えないとか、色々と制約があったようです。

C#におけるヒープVSスタック問題、あるいはUnityにおけるスクリプト高速化。

個人的にC#はグルー言語であるという認識が強くて、パフォーマンスを意識したプログラミングの経験が無い。しかしUnityのスクリプトをC#で書いていると、そこを意識しなくてはならないケースに出くわすことがある。

最近あったのは、テンポラリな配列のアロケーションが大きなオーバーヘッドを生み出しているという状況だった。これは結局、配列の使用をやめてstructのメンバー変数にパックするよう変更したところ、パフォーマンスは著しく改善された。言い換えれば、テンポラリオブジェクトの所在をヒープ上からスタック上へと移すことによってオーバーヘッドが解消された、という格好だ。

問題となっていたのは、まあざっくりとこんな感じの、ゲームステートを保持するクラスだった。

public class State {
  byte[] cells = new byte[16];
  public State() {}
  public State(State src) {
    src.cells.CopyTo(cells, 0);
  }
  public byte this[int i] {
    get { return cells[i]; }
    set { cells[i] = value; }
  }
}

これをAIで処理する際に、大量のオブジェクトコピーと、比較的少量の書き換えアクセスが発生していた。ここでは似たような負荷を発生させるために、こんな感じのテストコードを使うことにする。

int pos = 0;
State state = new State();
for (int i = 0; i < 1000 * 1000 * 10; ++i) {
  State temp = new State(state);
  int pos2 = (pos * 11 + 1627) % 1637;
  temp[pos & 0xf] = (byte)(temp[pos2 & 0xf] + 1);
  pos = pos2;
  state = new State(temp);
}

このコードを手元のUnity環境で実行すると、終了までに約１９秒かかる。

このコードが重いのは、メモリロケーションとオブジェクトコピーに問題があるのだろう。それは書いている最中から想像できたし、プロファイリングの結果もそれを示唆していた。それならばと、Stateクラスをこんな感じのstructで置き換えてみた。

public struct State {
  private uint cells0, cells1, cells2, cells3;
  public byte this[int i] {
    get {
      int sh = (i & 3) * 8;
      switch (i >> 2) {
        case 0:  return (byte)((cells0 >> sh) & 0xff);
        case 1:  return (byte)((cells1 >> sh) & 0xff);
        case 2:  return (byte)((cells2 >> sh) & 0xff);
        default: return (byte)((cells3 >> sh) & 0xff);
      }
    }
    set {
      int sh = (i & 3) * 8;
      uint mask = ~(0xffU << sh);
      uint add = (uint)(value & 0xff) << sh;
      switch (i >> 2) {
        case 0: cells0 = (cells0 & mask) | add; break;
        case 1: cells1 = (cells1 & mask) | add; break;
        case 2: cells2 = (cells2 & mask) | add; break;
        case 3: cells3 = (cells3 & mask) | add; break;
      }
    }
  }
}

大きな違いは、classではなくstructを使っていることと、配列ではなくメンバー変数を用意し、そこに値をパックしていること。これで、ヒープ上に確保されていたオブジェクトはすべてスタック上へと移ってくれるはずだ。

変更後のコードは0.6秒で終了した。30倍以上の高速化だ。これは極端な例だけれど、シンプルな処理を反復することの多いAIの内部ループでは、同様の対処によって高速化の望めるケースがあると思う。

まあでも

C#やCLRには詳しくないので、どうするのが正しい対処なのかはよく分かっていないです。そもそも今回の対処も合っていたのやら。恐らくC#やXNAのコミュニティを探れば、その手のノウハウを見つけることができると思うのですが、そこまでするのは面倒だなと思い、まだ手を出していない次第。いつかはやんなきゃなんないかもしれないけども。

MacBookの据え置き運用

導入前はスペックに不安を感じていたMacBook Air 11″も、現在はすっかりメインマシンとして活躍している。動画編集以外の作業はほぼすべて、このMBAの方で行っている。ここまで実用になるとは、正直なところ思ってもいなかった。

それで、今まで使っていたMacBook 13″の方は、常時クラムシェルモードで据え置きマシンとして使っていくことにした。

クラムシェルモードとは、MacBookを閉じたまま使うモードのことだ。この辺りの記事の解説が分かりやすい。

AdobeのツールやVirtualBoxなど、容量を食うソフトはこちらに入れて立ち上げている。iTunesのライブラリもこっちに入れてある。MBAはXcodeとUnityとLiveとiWorkだけ。普段の作業のほとんどはそれらのツールで完結しているから、それで済んでしまうというわけだ。

Tumblrを使いこなす人たち

Tumblrは色々な使い方のあるサービスだ。もっぱらreblog用のサービスという印象があるけれど、中には普通のブログとして使いこなしている人たちもいる。 Minecraftの作者のブログThe Word of NotchはTumblrを利用している。これは本当に普通のブログとして使っている例。ちゃんと使いこなしている感があってかっこいい。 他に僕が知っている例としては、ＵＩデザイナーのMax Steenergen氏のブログが、やはりTumblrを利用している。こちらは半ブログ、半リブログといった感じの中間的な雰囲気になっていて、これはこれで面白い。 現在、はてなダイアリーの使い勝手には少し不満があって、他のサービスへの移行をうっすらと考えている。WordPress.comが最も無難だろうと思っているのだけれど、Tumblrを使うというのも、ちょっと面白そうだ。