結論：　重すぎる･･････

以下手順とハマりポイント

◆RubyのインストールにはRubyInstallerを使う
◆コマンドプロンプトはnyaosを使う
※nyaosにpik関係の問題あり

◆Windows/Ruby環境を作るにあたってあきらめなければならないこと

・Unicornは依存パッケージの関係上はいらないっぽい(kgioはunix only)
→http://locomotive.cl0.vanillaforums.com/discussion/3/windows-installation/p1

◆Ruby環境の整備にpikを使うケース

gem install pik
pik_install C:\RubyPik #パスを通しておくこと
pik config install_dir=C:\RubyPik #pikのインストールパスに半角スペースとか入れないように。
※pik_installの場所とinstall_dirは場所同じにしたけど、違う場所がいいかも。
pik install Ruby 1.9.3
pik use 193

○rvmと違うところで致命的に嫌だった所
・gemsetは使えない(ただし、環境ごとに名前を変えれば似たことは出来る)
・–defaultが設定できないので毎回useする

○知っておくといいこと
・Windows特有のパスディレクトリを含めない。RubyインストールパスはC直下あたりが望ましい。(半角スペースや全角文字のない場所)
・pik useを適切に行うためには、pikのパスにあるbatを読む必要がある。pik listとかは動いちゃうので注意！
・すでに環境がある場合はaddするほうが絶対いい
(gem install pikの時点でもうRuby環境あるじゃん！ って話なので)

○nyaosでpik useを有効にする
_nyaに↓追加

### Pikの設定を追加する
pik{
pik_runner.exe pik.bat %*
if exist “%USERPROFILE%\.pik\pik.bat” then
source “%USERPROFILE%\.pik\pik.bat” 2> nul
endif
}
※pik.batの場所は%USERPROFILE%\.pik\pik.batになるもよう。

○nyaosでpik useのデフォルトを指定して弱点をカバー
_nyaに↑のあとに
pik use 193
環境の可視性を持たせるために
ruby -v
rails -v
を記述。
この_nyaファイルはカレントディレクトリにおき、nyaosをカレントディレクトリで起動するショートカットないしbatを用意する。

◆DevKitのインストール

(レガシーなやり方)
1. http://rubyinstaller.org/downloads/
ここから最新版のDevKit落とす

2. DevKit解凍(半角スペースや全角文字のない場所にすること)
(自己解凍書庫だがディレクトリを作らないので、ディレクトリを作ってその中に入れる)

3. DevKitのパスにもぐり、以下実行
ruby dk.rb init
#この際に最初にインストールしたRubyパスを読むので、別にpikでインストールした場合はそのパスに変える
ruby dk.rb install

◆mysql関係の落とし穴

libmysql.dllがないといわれる
http://exposed.egoism.jp/wordpress/?p=295

Rubyインストールパスに、
Mysqlインストールディレクトリのbinの中にあるlibmysql.dllをコピーする。
→ただし、私の環境ではこれでも駄目だった。

駄目だった場合は、MySQLのページ→Download→Connector→Connector/Cで落としてきたzipの中にあるdllファイルを突っ込む。
MySQLコネクタのバージョン＞gemが使うコネクタのバージョン にすること！

◆guard(自動でRSpec実行してくれるやつ)の問題

○Cucumber関係のWARNINGを消す

・.rspecのカラー付けが出来ない
(You must gem install win32console to use colour on Windows)
gem install win32consoleをする。
(Pikではなく、Windows環境デフォルトのRubyに入れる？)

・WARNING: You must use ANSICON 1.31 or higher を消す
http://qastuffs.blogspot.jp/2011/02/how-to-install-ansicon-for-cucumber-to.html

○awkが無い
→Windows Services for UNIX を入れる。
http://www.microsoft.com/downloads/ja-jp/details.aspx?familyid=896C9688-601B-44F1-81A4-02878FF11778&displaylang=ja
gawkをごまかして使うことも考えたけどやめた。

A. その一つはルール、もう一つは達成感。

-Expression-

Step. ルールとは。

ルールとは、ゲームを構成する最低源の要素。

「ルールを構造化する」
・ルールを複雑にすることと、シンプルにすることは相反しない。

トレードオフ
「構造化された複雑さ」 　⬅ 　Which?　➡　「単調化されたシステム」

スーツの理論では複雑性の土俵の上に「ゲームが成り立つ」とあるが、
これはハイソサエティな考え方にすぎない。

Case. 構造化された複雑さについての説明

例題)
「操作はボタン１つだけである」というルールでゲームを作るとする。
ここからは色々なルールが完成する余地がある。
が、しかし、完成したゲームそれらの何割をユーザーは受け入れることが出来るだろうか？

基本的に、ユーザーは無料の利益というものになれてはいない。
ボタンを押すと何かを失い何かを得ると判断しうる。
システム上「ただボタンを押すこと」で人と話し、冒険を行い、アイテムを入手し、町で買い物をし、仲間を集めるような仕組みを作ることは可能である。

しかし、ユーザはそれらの行動に対し、「対価」を無意識に考えるものだ。
仲間を雇うには交渉が必要、モンスターを倒すには十分な準備が必要、町で 買い物をするには金が必要……

それらを無意識のうちで使用するような「ワンボタン、ミステイク」は、
ユーザビリティとしては考えづらいし、やり過ぎといえるだろう。

トレードオフ
どこまで操作を併合すればいい？　⬅　Which?　➡　どこまで操作に自由度を与えればいい？

成功例)
ミスタードリラーは、成功例の一つといえる。

複雑なブロックのルールを「掘る」というアクションでシンプルにし、
操作をほぼ「ワンボタン」(正確には、ユーザーの移動をしなくてはならないが)で行うことが出来る。

これは、シンプルにルールを融合した例の一つといえる。

Case. 単調化されたゲームについての説明

近年のソーシャルゲームの台頭。

めんどくさいと思える行動(様式美)を単調化することで、
ユーザビリティをあげるというもの。

基本的に、だれる行動をシンプルに纏めてしまうのはよい。
が、根底がパズルゲームだとした場合に、そのパズルの部分を最適化するのはどうだろうという課題がある。

単調化されたゲームに求められるのは、ユーザへのルールへの介入度だ。

例題)
「冒険をする」ことを基軸としたゲームを作れ。
とした場合に、まずは冒険の要素を洗いだすだろう。

1. 準備をする
1-1. 装備強化
1-2. ちょっと遊んでみたり……？

2. 徒歩/船/飛行船/車で目的地に行く
2-1. 道中でのイベント
……
2-2. 怪しい場所を発見
2-2-1. 探索
2-2-2. もしかしたらボスとかいるかも
……

3. 宝を探す
3-1. 原生動物との戦闘
3-1-1. 攻撃！
3-1-2. スキル！
3-1-3. くびをはねられた！
……
3-2. 目的地での休息
3-2-1. 寝床の作成
……

4. 宝の分配、持ち帰り
4-1. 宝は全部私のものだ！
4-1-1. 持ち運ぶには船が必要だな……
4-2. 仲良く分けようか……
4-2-1. わけまえを均等に配分するかどうかは問題だ
……

さて、要素を深く掘り下げ、そこにルールを定義し遊びを生み出すことは可能だが、
はたしてどこまでが必要だろうか？

ユーザは宝を持ち帰るのが目的であるなら、
道中の「めんどくさい工程」はある程度どうでもいいのかもしれない。

あるいは、ユーザはその工程の全部、ないし一部を楽しみたいのかもしれない。
(おそらく、冒険の都度全部の要素を楽しもうとするユーザーはマイノリティとなるだろう！)

成功例)

ドラゴンコレクションや探検ドリランドなど。

基本的にユーザーが行うアクションの様式を全て取り外し、生活にとけ込むまでにゲームを圧縮することに成功している。
ゲームが生活にとけ込めない「悪しき点」の一つは、様式をプレイすることに集中しなければならないために、ユーザーからある程度まとまった時間を奪ってしまうということだ。

JRPGは「戦闘が面白い」とよくいわれてはいるが、ブラウザベースのソーシャルゲームで「戦闘が面白い」と感じたものは一つもない。
多数派のユーザは「戦闘の細部に関する様式」よりも、「戦闘をしたことに対する結果」を重視するのだ。

トレードオフ
どのくらい様式を省けばいい？　⬅　Which?　➡　どのくらい様式を盛り込めばいい？

Step. 達成感とは？

ゲームをやっていて、結果として何も残らない/何も起きない、
その時間を無為に感じることはないだろうか。
また、行動的には無為なものをやっていると自覚していても、
自分の中で「ある一定の目標」を作成し、それを達成しようとしてないだろうか。

それを自然に行うことの出来る要素が、達成感である。
これは、ゲームの演出や難易度をどのように調整するかで表現できる要素だろう。

Case. 何を残すか

「ゲームとは無為なものだ」とほざいたのはホイジンガだったか。

ユーザになにがしかの形で残り、なおそれがうれしいものとなる要素は、
なにも社会的にプラスになるものばかりではない。
ゲームを遊んだ記憶そのものや、友人とともに行動した環境、
そういった、ゲームのシステムとは完全に隔離された関係ない……関係ないと思っている要素！
それが「後に残るもの」である。

これは、言い換えると「昔」を楽しむことになり、
未来の自分へ楽しさをシェアすることに繋がる要素となり得る。

しかし、何も残らないゲームもある。
音楽に合わせてリズムを刻むなどして、「おもしろかった！」と一言残すことが出来るゲームは
それそのものを遊んだ時間を「有為的なもの」にする。

これは、言い換えると「今」を楽しむことになり、
それ以外の社会的要素に何も影響しない、気楽なものとして遊ぶことが出来るだろう。

トレードオフ
「今」を楽しめ！　⬅　Which?　➡　「昔」を楽しめ！

Case. 何を起こすか

ひきがねをひけば弾が出る。それは銃にとって当たり前のことだろうか。
いいや、弾が込められていなければ、その撃鉄はただ音を鳴らすだけだ。

ふつう、マニアックに時間をつぶす意外の用途では、
弾の込められていない銃を撃ちたくはないものだ。

ましてや、それがゾンビや野生動物がうろついているような環境では、
ユーザは無為に「カチカチ音を鳴らすだけの行動」をやるはずがない。

プレイヤーとユーザーは弾が切れたら自主的に弾をリロードし、次に備える行動をすると
心の中で同期している。していたいと思うのだ。
ゾンビが視界にいる状態では「銃の引き金を引いたら、弾が出てあいつが倒れる！」といった
心の同期が必要だと思う心があるはずなのだ。
(もっとも、現実で次に備える行動を実際に行うか、というのは別の問題)

別の例を出そう。RPGだ。次にいく場所が分からない。迷ってしまった。
が、町の人はスクリプトで打ち込まれた文章を返すだけで何も教えてはくれない。
「何かヒントを教えろよ！」と思うことは良くあるだろう。
無意味に昔の町に戻ったりしなかっただろうか。

しかし、次の町へたどり着くことがひとつの「推理的パズル」なのだとすれば

それをぺらぺら喋るNPCというのは野暮ったいとは思わないか？
「自分の知りたい要素」をなかなか教えてはくれないパズルゲームなどでは
回答にたどり着いたときの「やった！」という快感を味わうことがあると思う。

これは心の同期をしていてはたどり着けない領域にあるもので、
かつ、ユーザの「ここにちがいない！」という同期心を完全に無視した想定をしなくてはならない。

ユーザーの心を無視する(ある程度のストレスを与える)必要があるのだ。

トレードオフ
心を同期する　⬅　Which?　➡　心を無視する

Case. 何がしたいのか

目標というものがなければ、物事などただの苦痛にしか感じない。
しかし、現実でもゲームでも、時に苦痛を強いられるときがあるだろう。

・RPGで、完全にルーチン化した戦闘を繰り返しているとき
・何度も繰り返されるストーリーを、スキップできずにみているとき
・広すぎるフィールドにただ１人、いきなり放り出されたとき

人間は目標を立てて、それに添って動く生き物だと思っている。
であれば、まずはプレイする上で「目標」が必要なのだ。
しかし、目標というものは自分で考えるものであって、
人に決めてもらうものではないはずだ。

しかし、最初から最後まで自分で目標を決めてまでゲームという「苦行」をやる人はそういない。
「これはゲームなのだから」と

ある程度は、与えられた目標通りに動くことがほとんどであるだろう。
このゲームで何をすれば、自分は面白いと感じるだろうか。

ゲームで何がしたいのか。ゲームで何を表現したいのか。

トレードオフ
自主的な目標　⬅　Which?　➡　与えられた目標

-summary-

Point. 全てはトレードオフの関係にある。

何が正解で、何が間違っているかなんてわからない。わかりっこない。
この記事が正解かさえもわからない。

しかし、全てにおいて、自分が納得のいくバランスを見つけたなら
すくなくとも、自分と同じ天秤を持つ人には、それが理解されうるのではないだろうか。

ふと、このままCPUが分散化のみに注力され
GPUの恩恵が十二分に得られる時代が訪れたとき
それを、単純演算資源としてではなく
汎用的演算資源として活用できる時代が来るとしたら。
そのような未来を想像してみた。

そんな、すぐにでも訪れそうな未来。
オブジェクト指向なんてぬるい理想のままでは生きて行けないだろう。
それを切り開く活路、「十億関数時代」というものを夢想した。

十億関数とは、一秒に投げられる関数の数の指標のこと
つまり、一秒間に10億個の関数が処理されなければならない時代だ。
仮として、CPU/GPUの資源をGF114の384コアの約３倍、1000を基準に試算すると
百万関数/1コアまで拡張が可能であると試算できるので
平均して1マイクロ秒で1関数の処理が完結していればいい。

このベストパフォーマンスを得るには
データの衝突やI/O限界の解消とは別に
「すべてのオブジェクトが関数として機能していること」がまず前提となる。

1. ラムダクラスタリング
クロージャの集合を、データスレッドごとに分散して、同じパターンのスレッドにチェインしていくもの。
この際、並列化が可能であれば並列化すること。
関数は共有メモリ上にある程度ハッシュ化されているはず。

この構造は
・分子コンピュータの領域では比較的親和性が高いと思われる。
・量子コンピュータの領域では親和性は低いように思われる。

2. クリティカル・パスの並列走行
クリティカルセクション(ロック機構)はボトルネックをつくる。
これは前時代からのマルチスレッドコンピューティングの基本であり最大の難関であった。
しかしデータグラムを分散、ラベリングすることでは
「クリティカルが競合しないもの」は多々存在すると言える。
それらを並列走行させること
あるいは仮にそれが全体で単一に走るべきオブジェクトだとしても
競合するオブジェクト自体は離別できるので

//データコンバイザ的なほげ関数
//ついき:くそながい
function void hoge(Element elm)
{
elm.critical_str += “これ競合してる”;
elm.value….
うんたらかんたら
elm.critical_str += “これ競合(ry”;
return elm;
}
↓これをこうする↓
//データコンバイザ的なほげ関数
//ついき:分割した。ってか昔懐かしい？
function void hoge1(Element elm)
{
elm.critical_str += “これ他と競合してる”;
chain hoge2;
return elm;
}
function void hoge2(Element elm)
{
elm.value….
うんたらかんたら
chain hoge3;
return elm;
}
function hoge3(Element elm)
{
elm.critical_str += “これ競合(ry”;
return elm;
}

概念的には、ステートメントを保持するという感覚分コルーチンに近い。
しかし、当然ながらこの間elmにアクセスされたくない場合は有るはず。

3. フェイジング・マージ
elmの内容自体(Cでいえばそのポインタの中身に該当する部分)を書き換えられたくない場合。
その場合には、これをFadingオブジェクトとして宣言して使う。
このオブジェクトは、確定可能な計算時(コミットメント)に実存として表現されるオブジェクト・キャッシュで
関数によって割り当てられた割り当てられた優先度順にチェインされたもの計算を1スレッドを使用して行い、基礎範囲外の演算結果(それが許容範囲外アクセスであるとかの処理を含めて)、適切に演算する。
これはマージの概念に近く、演算は適切な優先度を持ち得ることでコンフリクトしない。
優先度を用いて適切とする場合は、掛け算や割り算など順番の変わるものに関して気をつけること。特に掛け算と割り算は執り行う前後が逆転しただけでも演算が狂うことがあるので。

ex. いくつかの実例的コード
統合的概念は関数型言語そのものである。

単純な処理例として、functionAで5*8+3、functionBでA*0.8、functionCでB/2という計算を行うとして
慣れやすい感じで視覚化するとこうなる。
ret = functionC(Int functionB(Int functionA(){ return (5*8+3); } As A){ return (A*0.8); } As B){ return (B/2); };

Haskellのような何かと、LISPレベルの型付け。
http://ja.wikipedia.org/wiki/LISP
http://ja.wikipedia.org/wiki/Haskell
ただ両者ともやはり(慣れなければ)分かりづらいので、JavaないしCの関数レベルで分解し引数の場所にプロトタイプ宣言が書けるような形で取り繕えれば。

4. I/Oアクセス
I/Oに関連するものだけに関しては、その際SSDをフルに活用するという言い訳を置いておいて割愛。

i. 問題点そのいち
どの段階で「関数」を「分別」するの？
・問題として、動的でなければならないもの(順番が変動するもの、数が流動的な物、存在が不確かな物が該当)と、静的なものがあり、上記の例のような関数式は静的コンパイルが可能で、動的式(Zオーダーされたポリゴンの座標変換式や、人間の操作系による影響)は、コンパイルがJITとなる。
・その分別に対するツリーボットやクローラーはいつ動く？ あるいはそういったものはそもそも必要なのか？ ツリーボットやクローラーはGCと同じようにタイミングを見なければ非効率的になるものでは。

とりあえず後日追記

◇Amadeus
・完成できるか？

◇Kleio
・時間はなさそう。

◇Harware
・時間はなさそう。

◇Working
・分岐点にいる。
TA的要素をもっと磨かなければ？

◇Private
・今年はもっと遊びたいな。
遊び方を覚える年でありたい。

◇Total
今年も早く終わりそうなので、早いうちから手を打つこと。
昨年度は手遅れになりがちだった。
気をつけよう。

ODP: Original Design Pattern

ルーリングによる管理メソッド。このルーリングパタンの概要は以下。
・共通化されたルーチンと外部ルールによるFactoryパターン
・ルールはハッシュ化された辞書。

これはIMEなどの言語処理、またスクリプティブな/仕様がよく変更される場合においてのデータ処理に役に立つ。

外部設計

・ルーリングは、主にKey-Valueの関係で動作する。

実装のモデルは以下のようになる。

ルーリング辞書シングルトン
↑↓  ルールのやりとり
ルーリングコンパイルクラス
↑データ　　　　　　　解答↓
実装クラス 

(※後で図にでもしよう)

内部設計

◇ルーリング辞書クラス
・シングルトンで動作する。ルールは単一化されるべきである。
・ルールデータを管理し、シリアライズ/デシリアライズするなどして可視状態にする。

ルーリングデータはDictionary<String,Dictionary<String,Token>>などで作成される。
最初のDictionaryはルールのヘッダ
二番目のDictionaryは各トークンに対する「キー」ヘッダである。

◇Token
・Tokenは、各ルールを解釈するために扱う単位クラスであり、コンパイルはこのTokenを用いて情報を解釈する。

Tokenは「単一の処理に対する」コンパイラ・クラスであり、ルール情報を持つ。
このクラスの変数設計はシリアライズされるため過度に変えるべきではない。
また、目的に応じて動的に処理を作成する必要がある。

以下はスクリプトコンパイラにおける処理の一例。
public class EventToken
{
        public String header; //処理のヘッダ名
        public String initParam; //デフォルトとなる初期値
        public String data; //データ
        public String Type; //データのタイプ
        public Boolean key = false; //この情報がスクリプトに必要なキーであるかどうか
        public List<String> SetParam = new List<string>(); //
}
public class EventDef
{
        public String header;
        public String tag;
        public List<Token> token = new List<Token>();
        //外部からTokenを設定
        public void SetTagData(String _tname, String data)
        {
            foreach( Token _a in token )
            {
                if( _a.name.Equals(_tname) )
                {
                    _a.data = data;
                }
            }
        }
        //トークン情報をカウントする
        public int TagDefCount()
        {
            return this.token.Count;
        }
        //トークンのキーの数をカウントする
        public int KeyDefNums()
        {
            int c = 0;
            foreach ( Token _a in token )
            {
                if (_a.key)
                {
                    ++c;
                }
            }
            return c;
        }
        //トークンを使って展開する
        public String ExpendTagDef()
        {
            String str=”[“;
            str += tag;
            foreach( Token _a in token )
            {
                str += ” “;
                str += _a.name;
                str += “=\””;
                str += _a.data;
                str += “\””;
            }
            str += “]”;//\n”;
            return str;
        }
    }
}
ルーリングコンパイルクラス
(コンパイラの実装部分のみ)
ScriptCode = “”;
EventDef t = new EventDef();
if ((t = GetTagData(tag)) != null)
{
  foreach (Token tk in t.token)
  {
    try
    {
      if (tk.key)
      {
        if (this.token[tk.name] != null && this.token[tk.name] != “”)
        {
          t.SetTagData(tk.name, this.token[tk.name]);
        }
        else
        {
          if (tk.key)
          {
            //このパラメタはキーであった。
            //スクリプトコードの出力をクリアして中止する。
            ScriptCode = “”;
             //エラーメッセージ
             Logger.Log(“キープロパティが設定されていませんでした”);
             return -1;
           }
         }
       }
     }
     catch
     {
        //エラーメッセージ
        Logger.Log(“不正なキープロパティが設定されています”);
      }
    }
    ScriptCode = t.ExpendTagDef();
}

ルールに使う「tag」ヘッダを用いて、コンパイラから処理の区分けを受け取り
コンパイラのトークンに「data」値を流し込み、展開を行う。

このコンパイラは上位の処理でコンパイルデータ・クラスを作っていたため
汎用性のある部分のみを抜粋した。
→あとで追記する。

[設計上の注意]

・汎用設計上好ましいのは、「すべてのデータタイプに対応する」であるが、やりすぎると可読性と処理速度の低下を招くので、分けたほうがわかりやすいのであれば、データの種別ごとにルール化するのが望ましい。
・よくわからん場合、「辞書を引いて翻訳する」という表現をすると理解しやすい。このコードって何？って聞かれたらそう説明するといい。
・Tokenにデータを流し込まず、Token自体にCompileメソッドを作るのもいい。

[あとがき]
・ざっくり書いたのでソース部分を後でまとめなおす。
・Wordpress初投稿。正直Liveのほうが好きかも。