イスファハン
 ボードゲーム

　すばらしいといっていいのじゃないか。ダイスを振ることの楽しさもある。戦略開発の楽しさもある。それにテンポがいい。おもしろいです。
　プレイヤーは商人。商店を開いたり、首都イスファハンに向かうキャラバンに商品を届けたり建物を建てたりして、得点を稼ぐ。
　ルールブックを読みなおしてはじめて気づいたけど、このボードはイスファハンではなく、周辺の街らしい。繁栄を謳歌してるイスファハンと取引して自分たちも稼ごうという近郊の街のお話だったらしい。

　とりあえずラウンドのスタートプレイヤーは、ダイスを９個振る。
　そしてこれを出た目で分け「タワーボード」に置く(→なんか写真は12個あるけど、普通は９個)。
　一番高い目は一番上の段だけど、他は下から順。
　プレイヤーのターンでは、このダイスのグループを一つ選び、とる。ダイスが置かれているエリアにはそれぞれ固有のアクションが設定されている。ここで、このターンにおこなうアクションを選ぶわけだ。
　ちなみに、上から

• 最上段：ダイスの数だけ(目じゃなく)金貨を獲得
  
• ２〜５段目：ダイスの数だけ商店に商品を配置
  
• 最下段：ダイスの数だけラクダを獲得
  

　となっている。
　あと、選んだエリアに関係なく、下の二つの行動が選択できる。

• ダイスの目の数だけ行政官を移動
  
• カードを１枚引く
  

　行政官というのはイスファハンからきた人で、この人がふらふら歩いてきて商店の前でとまると、そこにある商品がキャラバンに送られる。
　あと手番のあとに建物を建てられる。これはもう見慣れた感じの、それぞれのアクションを強化する、プエルトリコ風の建物だ。
　こんなことを７ラウンド(１週間)やると得点計算。盤面に置かれた商品とキャラバンに送られた商品から得点が入る。盤面の商品はリセットされるけど、キャラバンはリセットされない。
　３週間でゲーム終了である。

　なんといってもテンポがいい。けっこういろんなことをやっている気がするわりに、さくさく進む。
　でもだからといって考えないわけではないし、得点戦略を選択する意思が必要なゲームになってもいる。

　得点戦略にはおもに２種類。盤面の商店に商品を置くか、キャラバンに送るかだ。
　この２つがまた、ロジックがまるで違う。盤面に置くならダイスの数だけど、商品をキャラバンに送るためのアクションである行政官の移動の場合は、数ではなく目。そもそもここから違うわけで、特化した作戦を選ぶと違うゲームになってしまう。
　いつどちらを選ぶのか、よく考えなければならない。
　ところがこれが、よく考えなければならないんだけど、けっきょくダイス目次第だったりもする。なにしろダイスを９個振るのだ。しかも、目ごとにグループ分けするこの使いかたは、だいぶ変動が激しい。
　運ゲーといえばまちがいなく運ゲーなのだ。しかもけっこう運が強い。
　しかし、そのわりに、不条理感はそれほどないとも感じる。
　たぶんこれは 「乱数はあっても結果を決める乱数ではないから」 ではないかと思う。
　このゲームでは、乱数で決まるのは行動の結果ではなく、そのラウンドの環境だ。いわば「席決め」と似たようなもの。プレイヤーは、乱数の結果を見てから自分の行動を選択できるのである。
　次のラウンドの環境がわからないため「今後の展開」を予想しきることはできないが「この選択の結果」はわかっている。自分の行動に責任をもつことができる。
　もちろん、乱数をどこにもってこようが、数学的には大差ないかもしれない。だがプレーヤーの感じ方が違うんじゃないか。「ソロプレイ感」と同じようなもので、おそらく「運ゲー感」というものがあり、これに関連する要素に「ダイスを振るタイミング」があるのかもしれない。
　などということを思ったり。

　このあたりは、よく考えてみると、カタンと同じなのじゃないかと思う。
　やっぱり、ゲームに乱数はあったほうがいい。単純にダイスを振るのは楽しいし。しかし「運ゲー感」が強すぎてはいけない。
　難しい問題だ。
　そのあたりの解決法として、イスファハンではカタンと同じものが採用されているのではないか。デザイナーの意図はともかくとして。
　カタンはもはや神話だ。個人的に、ここ十数年のボードゲームというのはすべて「カタンはなぜおもしろいのか」という問題を解き明かすためにあったのではないかという気がしている。極論だし暴論だけど。
　そんな数ある「カタン問題」のうち、少なくとも「乱数性」の部分について、イスファハンは解き明かしているのではないかという感じがある。

　余談だけど、書いてて思うのだが、カタンと比較できるゲームというのはそれだけですごいような。

ネームファーストプログラミング
 日記

　小説でもなんでもそうだが、わたしの経験上、タイトルを先に思いついたときというのはいい文章が書ける。そして、わたしがシステム製造業に身を投じて最初に実感したことというのは、文章を書く脳とプログラムを書く脳は同じだということである。
「WEBサイトを新設するときはまず名前を考えろ」なんてこともよくいわれるらしい。
　ということは。
　プログラムも、名前から先に考えるようにしたらどうだろうか。
　機能で関数やクラスを分けろとか、そんなことはよくいわれるが、しかし世間を見てくれ。スパゲティコードが氾濫してる。そのやりかたじゃダメなのだ。

　つまり、かっこいい関数名や変数名を思いついたら必ずそれを作れと。どんなにくだらない機能でもかまわない。ただし、逆に思いつかなかったら作ってはいけない。
「機能的にはこんなクラスがほしいんだけど名前が思いつかない」
　なんてときは、作らない。だって、自分でも一言で説明できないようなクラスは、他人が見たらわけがわからないに決まってる。そういうところから荒れていくのだたぶん。
　もちろんこの場合、名前のかっこよさを制限するコーディング規約はジャマだ。Rails系のフレームワークとかBeansとか、名前に制限を与えるものも厳しい。でも名前空間を分けることができるオブジェクト指向は推奨されるべき。

$Kimball = $lens->clearEther();
if($Kimball == QX){
$bergenhorm->on()
……

　……うーん楽しそうだが、ちょっと待て。ノシャブケミングってどうつづるんだろう。そんなの調べてたら時間かかってしかたないなあ。やはり日本人は日本語プログラミング言語を使うべきだろうか（ぉ

明治ミルクチョコレートパズル
 ボードゲーム

　こんな箱に入ったパズルである。
『ご注意！　食べられません』
　と書いてあったりもする。
　正方形を5個並べてできる12種類のブロックを並べて、10×6のマスを埋めてみろという、実にシンプルなパズルだ。
　まあわりと昔からよくある、ペントミノパズルというらしいのだが。子供のころやって、ぜんぜん解けなかった記憶がある。
　それがチョコレートのかたちに……。たしかにビジュアルとしておもしろいけど、これ継ぎ目がまったく見えないんですよ。どこになにがはまっているのか、ぜんぜんわからん。ユーザインタフェースは低下してます(笑)。

　難易度：ピュア（甘め）

　とか書いてあるが、そんなことはない。というか、これを解く人は尊敬すべきだと思う。
　手がかりや戦略がまったくなく、どうしたらいいのか考えようがない。惜しいところまでいったーと感じても、最後の１ピースのかたちが違っていたらもうダメなのだ。全部とはいわないが、半分くらいは入れなおさなければならないと思う。
　これを解ける人というのは、天才か、すごい根気のある人か、強運の持ち主か、あるいはプログラマだろう。
　要するに、パズルというより数学の問題だ。一度箱から出してしまったら、元に戻すのはかなり難しい。
　まあいまどきは、ペントミノでぐぐるとけっこう出てくるからなんとかなるけど。

　ちなみに、ペントミノじゃなくてヘクソミノ（正方形６個）版のブラックチョコレートパズルとかホワイトチョコレートパズルとかも出てます。

［2007.04.16 21:02］masamasa :
まずコーディング方法考えて
時間かかりそうだから効率的なアルゴリズム考えて
んで「難易度：ピュア」っつーんだから正当の場合の数が1じゃないんだろーな→いくつだろう？って思いました。

プログラム以外の納得できるやりかた(つまりはトライアンドエラーの効率的施行法)がきになります。

［2007.04.16 22:59］てらしま :
　2339とおりらしい。ブラックは1とおりしかないそうな。
　パターンを捜すという意味では、購入時の状態からちょっとずつ変えていくのがいいだろうなと思うけど。
　人間らしいやり方としてはたぶん、試行錯誤して使えるパターンをいくつか見つけだすとかそんな感じはあるのかなあ。

学校の階段映画
 日記

• http://kaidan.gyao.jp/
  

　つまりアイドル映画のダシになったのかー……。
　キャラクターもだいぶ違うみたいだし。まあネタはいいし青春だし、それもいいのかもなー。

ABDいいじゃん
 日記

はぶにっき
　↑とか（有名なブログらしい）関連のいろいろとかをいろいろ調べてみたりした。まるでマジメなエンジニアのようだ。
　いや、DB設計する機会が頻繁にあるような身分ではぜんぜんないんだけど、しかしWEBの仕事というのはスパンが恐ろしく短いので、テーブル変更もしょっちゅうやってるし、だからわたしのような新人にもそういう仕事が回ってくることがないではない。というかある。
　で、このはぶにっきさんで紹介してるABDという設計手法である。「これだ」と思ったんである。これだよ。こうやるべきだよ。

「とにかくIDをふれ」というのは実際、実感として感じていたんだけど、さらに、いわゆる外部キー列を作るんじゃなくて「とにかく交差エンティティにしろ」というのがすばらしいじゃないか。すばらしいと思ったんである。
　SQL書くのが大変だったりするとは思うけど、それもちゃんとしたデータアクセスオブジェクトを作っとけばいいだろう（もっとも、そんなの見たことないが）。

　まあ実際のところ、テーブル定義の修正とかはたまにあっても設計からやることはないので、勉強しといても使う機会はなさげなんだけど。でもいいなあ……。