徹夜しました。
久しぶりにプログラムをがりがり書いてました。
ゲームロジックの1/3位書いた。

この感覚なら言える。
プログラムのコード量を減らすには結構整った前提条件を与えること。
これに尽きると思う。
なんていうか、数学の証明みたいなもんだと思う。
その代わり条件突っ込みすぎるとプログラムの引継ぎに支障が出そうな感じ。

ま、不慮の事故でスクラップって事も有るけども。
斜め上行かれると簡単に崩れるもんかもしれんし。

今さっき、精神科の先生から電話があった。
内容は診察の曜日を変えてほしいという内容だった。

こんな些細なことで揺らぎを感じてしまう。
はっきり言うと、どの方法を使っていけば自信を養って、うまくいくのか。それがわからなくなってる。
メソッドの最適化の方法を迷っている。

多分自分の知らない何かに依存している自分がいる。
その何かが揺らいだときに自分も揺らいでいる。
平時それを考えることは無い。
けれど、些細な出来事で揺らぐことが多い。

ああ、そうか。自分は依存体質なのだと思った。
依存することで、不安を消していたんだなぁ。
この依存を消すことはわかってしまえばそんなに難しくない。
けれど、消すことによって自分が変人になることはわかっている。
それでも普通になろうとしていた、楽な自分とのトレードオフかもしれない。
ま、変人の自分の方が自分的には標準なのだけど、
今ある安定を壊すのが少し怖い。
根っこにある些細な事を支える些細なトゲ。これを抜けば俺は変わる。

価値観を誰にも渡さず、自分の感覚を信じることでしか生きていけないのか。
大衆を無視して、倫理感を無視して、一番最初に教えられた教えを信じるしかないみたいだ。
結局、病気ってなんだったんだろうか。。。
戻るのなら、その間は無駄にならないだろうか。
前振りは十分だから、後は複線回収するだけかな。
あ〜、めんどくさ！！

昔から、リアルタイムストラテジーの簡略版を考えている。
もう5年目位かもしれん。あいだに常に考えてるわけではないけども。言語はC++。

で、今日発想したのは、WarObjectって言うクラスを作って、それを実運用するようにして、
それを継承したテンプレート的なたとえば騎馬とか弓とかをWarObjectにコピーする。
だから、ひつようなパラメータはWarObjectにもっておかないといけない。
だから、WarObjetctは万能でないといけない。
ずーっと、インターフェースで操作できないか考えていたけど、メモリ確保して管理しないといけないのが面倒すぎるので妥協した。っていうか、すげー、良いアイディアだと思った。自分的には。
で、この際だから、コピーのコストは払ってやることにした。
ついでにFPUも使ってやることにした。基本intしか使わないのだけど。

名前の話。
自分のモデルの中で、はじめは基本クラスはソルジャーで最弱で低コストっておもっていたのだけど、それだとたとえば鳥にしたいときに鳥の存在をどう捕らえるかという思考のロジックにはまるので、人であることをやめて無味にWarObjectにした。
WarObjectは歩けるし空飛べるし、秒速3万キロで走行もできます。
攻撃力も自由自在で、攻撃ユニットはいかなる隙間を通り越してターゲットを狙うことができる。
防御力も自由自在で、平温の豆腐の角で死んだり、凍ったバナナをモリモリ食べたりできます。
え？なにそれ。つまり、それがWarObjectです。
で職業を与えると徐々に輪郭が定まっていって、弱体化するわけです。
この辺がゲーム。
つけたい職業は。
飛行ユニット。射手。騎士。歩兵。レーザー。壁。神。ジョーカー。
あー良いね、ジョーカー。神様はジョーカーにぬっころされる。でもそれ以外はジョーカー最弱。
騎士->弓->歩兵->騎士。という三すくみを入れたい。AOM式ですな。
レーザーは場所食うけど一掃できるけど、壁は貫通できないとか。
あー考えると収集付かなくなるから打ち切り。

っとまぁ、思いついたときにこんなこと考えてる。
今日はWarObjectを実装しようと思ってIDE立ち上げたのは良かったけど、途中で忘れちゃって、やる気なくしたのだった。

オカルトですよ。妄想１００％ですよ。

ちょっと思いついたことをメモ。

火が燃える。
そんな単純で原始的なものを分解してみた。

pc.watch.impress.co.jp/docs/2008/0219/nanotech1.htm
これを見ていてなるほどと思ったのは、炭素の記述。
炭素は熱伝導率が良いそうだ。

火とは、何かの物体が気化するときに発する色なんだと思う。
発するということは、そこに目に見えるほどの気体が密集している事だと思う。
それが拡散して見えなくなる。目では捕らえられなくなる。
俺が確信しているのは青は酸素の色。オゾン層がそうだから。そう。
褐色は二酸化炭素かな？こっちは不明。

で、世の中永久機関はできないようになっている。
小さいモデルで永久機関を構築できないか少し考えた。

箱の中に、素材を突っ込む。
スイッチを入れたら後はとまらない。
増長しても良いし、しなくても良い。減るのはまずい、止まるから。

火が燃えるとき、何がおきているか。
結合と分解だと見る。
結合時に熱を発していわゆる炭ができる。炭が気化したら、固体は残らない。
分解は熱によって特性の変わった原子が分離して気化するのだと思う。
そうやって、火が燃えるロジックは実行されて、素材が無くなったら止まる。
で、箱に突っ込んである状態の場合。燃えるための素材はどの状態でも箱の中にある。
熱になって消える可能性もあるにはあるが、箱の周りを真空にすれば伝導物質がなくなる。
そんなわけで、これが言いたかった。物質の循環をうまくひねり出せば永久機関ができるんではないかということ。屁理屈万歳。
箱の中にすべての材料がそろっているわけだから、それをくっつける素材と分解する素材を突っ込んでおけば閉じた循環が可能かもしれない。

熱について、熱とは、分子の運動速度だと自分では思っている。速度が速いと熱い。
あと、熱を与えると燃えるように、物質の束縛を失うような気がする。
あー。なんかワケわからなくなってきた。

書いてて一つ思いついたのは、原子レベルで見れば、平時に原子が突然消失することは無い。ということ。これを前提にすれば、色々身近なことを説明できるような気がする。
太陽とかになると前提条件かわってくるのかなぁ。。。

原子と分子はだいたい一体って事は、安定する分子量と速度が割りと統計的に出てるということなんかな？
って、良く考えたら、そんなポンポン温度が爆熱になるようなものを生活に入れるわけ無いよなぁ。
研究者レベルではどのレイヤーかで、永久機関ができてるのかな。

はー、オカルトでした。

今日、ちょっとした発見をした。

プログラムにおいて、ViewとModelを分離するのは一応一つの能力的な指標になっている。
ビューとは見た目そのものであり、モデルとはロジックである。（強気に言うならローカルな法だ。）
それが現実にも存在したのだ。つまり、モデルとは数学や物理であり、いまだに視覚化されないロジックが存在するのだ。
すごい広がりだと思う。
精神とはまた違う目に見えない何か。
万物の根元たるエネルギーを創造するロジックがまだ眠っているのかもしれない。
すごい発見だと思った。他の人にすれば些細なことかもしれないけど。

久しぶりに感動した。XD

暇なので、書いてみる。俺自身はソフト側なのでそうのように書く。

コンピュータがなぜ動くかというと。マシン語を運用しているから動く。
マシン語自体は単なる数字の羅列であり意味はマニュアルに載っている。
数字やモノにに意味を付与することをマップするという。これはコンピュータ用語だと思う。
CPUはマップされた数字の意味を独自解釈することで動作する。
マップされた方言をしゃべりまくるのである。
その方言のことをインストラクションセットと読んだりする。
世界で一番売れてるのはx86ではなくてArmだそうだ。どっちも相互運用性はまったく無い。
マシン語を覚えることに辟易したらアセンブラを覚える。
アセンブラはマシン語の数字に名前をつけて、多少覚えやすいようにできている。
大体は1対1でマップされているのでアセンブラの書いたとおりに動く。
オプティマイザがあるか知らないけど、同じ意味で効率を上げることを最適化という。その自動化されたツールをオプティマイザと言うことがあるらしい。
アセンブラの命令はニーモニックという。
大体は意味を表した英文の単語の頭文字の羅列だったり結構大雑把にできている。
自分でアセンブラを設計する気になったらもっとマシな命名規則を適応するのも良いかもしれない。
でも、プログラマは怠け者だから、結局端折った命名になりがちである。
アセンブラでアセンブリをアセンブルするのに辟易したら、C言語を覚える。
高級アセンブラといわれるほどのもので小物を書くには悪くない選択だ。
コンパイラさえ用意できれば多少の相互運用性を確保できる。
さらにポインタなどの概念はアセンブラの概念がそのまま使える。
基本アドレス[相対アドレス];
の書き方で表せるこの方法は配列という構造を作ることを可能にした。アセンブラでも可能だが、言語仕様であるわけではない。
基本的にメモリはミクロに見ればBITの配列だが、プログラミング的にはByte（8BIT）単位の連なりつまり配列である。
C言語で一アプリに突っ込める構造は基本的に1個だけである。
2個とか3個突っ込と途端にスパゲッティといわれるぐちゃぐちゃなコードを生成してしまいがちになる。
だから、1プロジェクト1アプリが基本であろう。C言語の基本構築方法を手続き型と呼ぶみたい。
C言語に慣れてきたらC++を覚える。ただし、CがC99といわれる規格で別流をたどったみたいだ。
クラスが強力でクラス1個に1アプリを独立した形で突っ込める。手続きも自分の意思で公開できる。
でもメモリ管理がその分複雑になる。基本的にクラスで使ったメモリはそのクラスで開放しないとリークしやすい構造になる。iostreamは必要なら覚える。
C++の見所はやはりTemplateである。
BOOSTっていうサードパーティライブラリが有るのだが、変態級の発想でTemplateを駆使している。あれにはついていけない。
C++の次期標準ではBOOSTをたたき台にしている。
C++に辟易したら、ここで2本の流れがある。
1本はDMのD言語。
1本はニシキヘビや宝石系のスクリプトである。
D言語は執筆時点でまだマイナーである。でもC++で色々と疲れたら、これを手にする価値はあると思う。趣味でもいいので。
なんせガベージコレクタというメモリの掃除やが言語仕様にある。
これが便利で偉い人が考え出したメモリ回収機構が勝手にメモリを掃除するのである。
これによって例外を除いてメモリをリークさせることは無くなった。
プロパティを生成する構造も良い。構文はほとんどC/C++系列だ。
スクリプト系の話。
スクリプトはある種のトレードオフによって実現されている。
それは、処理速度を求めない代わりに簡単お手軽を実現するのだ。
GCはあるし、変態構文糖はあるし、作者の思惑に乗りまくりですよ。一番面倒なのは学習コストかもしれない。慣れれば都だと思われる。
ただ、実行環境事態は処理速度を追求して作られるので思ったほど遅くも無いみたい。
で、俺はDを選んだ。

さらに、最近はDのマイナーさにちょっとびびりつつ、C++をいじっている。
やっぱVCは快適だなー。Orz

最後に、プログラミング言語と言うのは道具です。
道具をつかってゴールを目指すのが正道なわけで、凝った使い方にはまったりするのは学習の面では悪くないが、それではアプリは完成しない。
あくまで道具です。

最近、昔はよかった。昔はよかった。って言ってる。
実際に戻ると意外と地獄だったりするんだろうか。

美化されてることを良く忘れる。
終わってしまえば何とやら。そういう感じかもしれない。
甘いひと時をもう一度と、思ってしまう。

自分が何をしたいのか良くわからなくなる。
自分は生きるのに向いてないのはわかってるんだが、寝ても朝が来るし。

今日はちょっと精神が荒れ模様だった。