http://www.plunk.org/%7Ehatch/MagicCube4dApplet/

クリックする場所はいくつかしか無い癖に
これだけの複雑怪奇な動きをしてくれる物って

動作とそれに対応する状態遷移の画面表示として
面白いな。

何か物理的なインターフェースとしてこんな様な物の
動作を取得するインターフェースがあったら面白いな

モチロンモニタと接触センサの組み合わせみたいには
なるだろうけれど

でもコーユー変なインターフェースを考え始めると
単純な真四角の立方体でうまい事中心付近に3Dチックに図形を表示させて
それを動かしたりすると内部の傾きセンサとかが値を受け取って
それを非接触のブルートュースか何かで通信してPCが受け取ったりすると

非常に面白いんだけれどなぁ
動的な処理を行うWebSiteを勉強していて思った事は
思ったよりも簡単な事なのだけれど、記述様式的には
如何考えても面倒な事が多い。

結局行いたい事は

ユーザーから値を受け取る。
ユーザー単位で識別および情報を付与し管理する。
ユーザーの状態に応じた画面を表示する。

って事だけっぽい。

何かそう考えるとアドベンチャーゲームみたいだ。
ユーザーの現在位置
ユーザーのアクション
そういった事に対してのリアクション。

ルーム方式チャットルームをこういった考えでフロー化すると

IDとパスワードによりログインする
ユーザーコンポーネントにユーザーIDを付与する。
ユーザーIDよりDBからステータスを取得し、ユーザーコンポーネントに付与する

現在のステータスが入室中で有ればルーム発言画面を表示
現在のステータスが入室中で無ければルーム一覧を表示
現在のステータスがルーム一覧選択であれば入室時発言画面を表示

と言った形でステータスを付与し、またステータスによって画面遷移する形を
取れば画面遷移コントローラは単純化されるだろうな。っと。

ステータス状態に応じてテンプレートを取得し
テンプレートは必要なデータを取得しにいく
取得しにいく際にデータは一部表示系を動的に変移させる為の
表示フラグ、表示内容データ、ユーザー等固有のデータ等

また取りにいけるデータが無い場合は、対応する部位の表示を行わなかったり
エラーデータを取得しにいったりな感じ

つーか、何かのフレームワークだコレ。

んでもって取得するテンプレートが余りにも高機能だと
テンプレートとしての画面と言った機能は失われてしまうから
テンプレートを画面テンプレートと画面変移テンプレートの二つに分離し
二つのテンプレートをマージし、テンプレートを作成する形を取れないかなぁ
広告的な読者登録の申請が増えたなと。
読書と筆者の関係は、読者から筆者が何らかを得られる事によって
のみ発生する関係だろうけれどな。

っと。まぁこんだけの文章だと、ちとズイブンと浅はかだが
まぁ、今忙しいし。

コレに関してはまた書こうっと。
我々は全ての犠牲の下に生きている。
我々は犠牲の下に生かされている。
我々は精一杯に生きていた者の下で生きている
我々は全ての下で生きて言る。
我々は積み重なり生きている。

我々は所詮一次元の下に縛られている
我々は繰り返そうとも生きていて死んでいる
そして、殺されていて殺している。

我々は、我々と個と認識している。

カリスマはカリスマを生み、我々がカリスマで有り
我々がカリスマを殺す。
現在、遊びと勉強を兼ねてJAVAを用いたWebApplicationを作ってる。
Struts、iBatis、Log4Jって言うソコソコ標準的っぽい組み合わせだ
(iBatisがどの程度流行っているのかは不明だが

んでもって、内容としては汝は人狼なりやと言うドイツ製のテーブルゲームのCGI版の
一つのJAVA版に作り直した物だ。

といっても特別既存ソースを元にしている訳では無いので
全部自分で作っているのでは有るが

今の所、大体のフロントの画面遷移は完成して(HTML的なミテクレはテキトウだけれど
GMの代わりのバッチ処理系が半分くらいって所かな。

作ってみて思ったのが、案外テーブルゲームはCGI形式のゲームに向いていると言う事だ。
画面遷移数は少なく作れるし、GM的な処理はバッチ処理として行えば簡単に管理出切る

これは多分に
基本テーブルゲームは何らかの一連の動作に対して役割をふり、簡潔化して、
システムを起こし、動作させる。

これは、プログラミングでは無いだろうかと。
システムを動作させる為に人間を用いていると言う事だけで

そもそもRogue等のゲームがテーブルゲームを人を使わずに
コンピューターを使用してゲーム化した物で有るのだから

今の時代に、WebApplicationといった形態をとれば
今までコンピューターで制御しなければゲームにならなかった物を
逆に人間の手にゆだねる事によって、コンピューター制御する部分を
あまり作らずともゲームになるだろうから

作成する部分が少なく、最大の効果を与えられないのだろうか
世の中は広く、知らない事が沢山で有るけれど
知る事は簡単に多くできて

実感する事は難しい。

何でだろうとやってみたら

何でダロウなのかなんて判らなくなって
何でだろうと思える一時の安心ぐらいは得られるだろうか
最大の傍観者を見つけられる事がストーリーに
最大の魅力を与える為のファクターでは無いだろうか?

否。

ストーリーとは語り継いでこそのストーリー

つまりは、最大の傍観者が居なければ
最大のストーリーは見いだせられない

評価されない為にそのストーリーは脆弱で有ると言えるのだ。

否。

脆弱であるからこそ、ストーリーはストーリー足りえる。
つまり不確定要素による揺らぎこそがストーリーで有り
その揺らぐ瞬きをつむぎ取る事でストーリーに魅力の与えるのだ。

それは、不確定で有りながら、確定する事の
一瞬の瞬き
JAVAでのDBを扱うのにiBatisを使っていてSQLがXMLファイルに分けられるので、
結構便利に使えているのだけれども、取り扱うSQLが多くなるとDaoを分けたくな
るのだけれども必要とするDAOが複数になってしまうとDAOの取得だけでイッパイ
になってしまう。それはナンダか汚く思える。

幾つかのDAOを一つのオブジェクトで一括で取得して、複数のDAOのメソッドその
オブジェクトから扱えると作るうえでもDAOを切り分けれるし、使う分には一個
のDAOを呼び出す感じで便利ぃけれど、どうやってヤルんかなぁ。

一つのオブジェクトのコンストラクタで、複数のDAOを取得して、複数のDAOのメ
ソッドを全部書くとかバカっぽい方法で何とかなるけれど、メソッドを書かない
で、複数のDAOのメソッド名と、出力と入力を取得して、入力した物をDAOを使用
して処理して、DAOから出力された物を、其の侭自身のメソッドの出力として出
力する様な感じで行えれば、DAOはイッパイ書いても一個のDAOから呼び出せる感
じにならんかなぁ。うーむ。

リフレクションを行ってやんのかなぁ。うーむ勉強が足らんな。ソモソモ、そん
な複数のDAOを纏めるとか言う事を考え出している時点が間違っているのかも知
れないし、一つのDAOに複数のメソッドが増えていくとメソッドが増えすぎて意
味不明になってくるから分けたいだけだしなー
ぶっ壊れているエレキベースとアンプを3000円で買ってきて
電装系を直して動かしてみた。まーまー面白い。
プログラミングってのは手段で有って目的では無い。
それを判らないでプログラミングを覚えた所で何の役にも
たつ訳無いだろう

と、言うか覚えられないだろうね。