この画面は、簡易表示です
４ゲーのPSNの正田氏の記事を読んでて、氏から見たオンラインゲームとは、
「インターネットで遊べるゲーム＝オンラインゲーム 」のような印象だった。
だから、PSNとしてはカジュアルゲーもMMORPGも手広く範囲を広げると云うこと
なんのだろう。それはそれで良い事である。
ただ、不特定多数の赤の他人と同じルームやフィールドで長く遊ぶオンラインゲーム
の人間関係やらBOT蔓延とかの問題点には全く触れる様子もなく手広く商売されても、
かなわんなぁ・・・と思った。
そうなると、野外Say禁止とかマイルールなFF調で運営するしかないんだろう。
また、どこのポータルでも全体の人気維持のために、新作投入は必要になる時期があるだろう。
面白そうならちょっと覗く程度ならいいがｍ本腰で移行となると、キャラデリ同様の現状では腰が重い。
月額課金ならなおさらだろう。
そう思うと、案外MOEもマイペースで気軽に遊べる数少ないゲームに思えてくるから不思議なものである。
※半年休むとキャラ消えますけどね（笑
多分できそう・・・。（薄笑
AOpenのXC Cube LE201である。
PCI Express x1の拡張スロットがナゼが付いているが、PCI Express2.0 x16のビデオカードでも動作するものがあるようだ。カードスロットの大半の端子が宙に浮くのでグラボの端を支えるパーツも付属しているようだ。
最悪、推奨のビデオカード以外は全滅かもしれないが、セットで買えばソコソコ遊べるかもしれない。
勿論、ケースサイズの都合上、使えるグラボはロープロファイルのみである。
とりあえず、今日見た感じでは、
「XC Cube LE201」の予想実勢価格は1万4900円。
「Aeolus F95GTD2-DCLP512X」が最安価格（税込）: ¥8,670。
なので、HDD＋メモリ＋DVD＋WindowsVista（？）でドレくらいになるのかな？
なお、ケースの前面アクセスはDVDと電源スイッチのみ、USBや音源等の端子は全部裏面でチョット使いにくそうです。前面下の3.5インチのオープンベイは、マザボにFDDコネクタが無いので使い道は定かではない。2台目のHDDを付けてもいいだろうが、HDD2段重ねの発熱を考えると、マザボの内部USB端子を前面に引き出して使った方がよさそうです。
また、ケースが同じXC Cube LE211は、CPUがAtom330プロセッサーと強化されているが、写真を見る限りグラボを支えるパーツが無く、仮にPCI Express2.0 x16のビデオカードが使えてもグラつきそうである。
クロックが２GHｚを越えたあたりから、更に高速なCPUが欲しいかと云えば欲しい。（笑
しかし、HDDが３Gbps程度のS-ATAに繋がっていることを考えると、これ以上速くても使い道がほとんど無い。１GｂｐｓのLANカードで５０Mバイト/秒の性能もCPUが速ければ多少あがりそうだが、HDDの実質最大転送速度が５０Mバイト/秒なのでこれ以上あがりようがない。そう二次記憶装置の性能の底上げが無いとCPUは今でも十分なのである。
３Dゲームのテクスチャーをグラボに押し込むには高速なCPUは欲しいものの、やっぱりテクスチャーファイルが入っているHDDの転送速度が足を引っ張るのである。
まず、RAIDを組み無駄にHDDを並列化して転送速度を底上げしてこそ、２GHｚ越えのCPUの意味があるのである。
と云う訳で、RAIDカードが高値なので、RAID０くらいは付いている高めのマザーボードが必須である。
いくらベンチマークで高速でもソフトの起動時間が長いのでは興ざめだ。
やったことは無いが、この期にやってみるのもいいかもしれない。
るるる とか戻っていたりするんだろうか・・・。
今思えば、リネⅡで一人でスペルハウラーをやっていたのは何だったのかな？
話せる島が重過ぎLDしすぎで、マップが軽かったダークエルフの村から始まり、
オラクルにする予定が、知り合いがさっさとオラクルになって、地すべり的にスペルハウラーに
なっただけなんですよね。だって、オラクル・ペアで何ができるんだぁ～って設定でしたからね。
他に知合いと云えば、藍雨、メルツ、るるる とか長く居た血盟の人ばっかり。
気が付けば、屑の掃き溜めと云われてたり、血盟のHPがRMTサイトのサブドメインだったり、
世の中甘くみてた面々が揃っていたようでした。
ただ、ゲームの外のそんな世間体も肝心のゲームの中身が狩り中心のスッカラカンでしたので、
実感が湧きませんでした。どっちかというとプレイ終了後に今日のリネⅡのプレイ日記のネタを
考えてる時間の方が長かった気がする。
※それはMOEも同じだったかもしれない・・・。
イプス峡谷にいってみたら、運悪く３匹ペットでやってる人がいた。
元ダメで『カオス石くださーーい。』と云ってみたら、OK貰えました。モノもすぐ出ました。
んじゃ、もう一個取ろうと自分でやってみたが出ませんでした。
カオス石でない暦一週間。
なぜだぁーーーーーーーーーーーー
などど書いた後は、ここに行くと綺麗さっぱり忘れられる。
この方の超プロ級のネタ度には毎回脱帽です。
使えば使うほど課金しますという請求方式。
ただし、金額を測る単位によって、かなり感触が違うので要注意。
１０円／分（接続時間）なら、一時間何もせずとも繋いでるだけで６００円請求される。
１００円／ゲームダウンロードなら、ダウンロード（但し書きが無ければ失敗も含む）の度に１００円請求される。
つまり、従量課金制という文字だけではどんな課金がされるか全くわからないので、
契約したら解除するまでは放置しても刻々と課金されていると思った方がいいくらいである。
安そうで結局高くつくものが大半である。
例）MOE スーパープレミアム【３０日】
※開けたら遊ばなくても３０日後には消滅します。
※この手のチケットは【７日】だって持て余すのに・・・orz
※どっちも、持ってますけどね（笑
火竜神殿でサッパリLVが上がらないエイシスイクシオンを
ビスク近くのイプス峡谷 の城の橋の下にいるウォータ ウンディーネで育成してみた。
一度、クライシス コールの３連続スカ（発動するものの戻ってこない）で
死なせてしまったが、なんとかLV96.9(袋表示)。
鱗も少し貯まったので、ミスリルと混ぜてビサイド ユア ハートでも
作って売ろうかな？一個錆びたのもあるがコレは枠拡張に使った方がよさそうだ。
しかし、カオス ストーンは一回も出ていないレアなものになってしまったようだ。
これではカオスエイジで落とす訳にもいかないな～。
原因は設定が甘かったみたいです。
Ｗｉｋｉによると、
Model View Controller（モデル・ビュー・コントローラ; MVC）は、コンピュータ内部のデータをユーザに提示し、それに対してユーザが何らかの指示を出すタイプの、独自のユーザーインタフェースをもつアプリケーションソフトウェアを、以下に述べるようなmodel・view・controllerの3つの部分に分割して設計・実装するという技法、又はそのような構造をいう。
となっている。
やってみれば判るが、model・view・controllerは互いに従属し、遷移あるいは結合が増えるたびに従属関係は複雑怪奇になっていく。
早い話が【伝言ゲーム】なのである。
ツリー状に枝葉が伸びていく分には余り支障は無いが、後になって、一本串を刺す様に伝言の内容（名前は１０文字から２０文字に変更になりました。等）が変ると一大事である。
このため、現在のＭＶＣは、伝言の内容をＦＯＲＭと称して仕様書上の隠蔽化を図っているが、ＰＨＰやＪＳＰなど画面にバッチリを書き込まなければいけない部分は全部書き換えである。
※もしくはヒデュン（非表示）エリアにＦＯＲＭを全部転記するかセッションで保持し、画面情報を一づつ吟味して転記するしかない。どっちみち面倒である。
つまり、後の保守は他人に任せてのが最適であり、アプリケーションのＵＩ設計をＭＶＣで行うということは、『開発完了』までしか念頭に無いと思われる。
何のことは無い、前世期のホスト・ターミナルからある『電文』という業界用語をMVCと云ってるだけなのだ。唯一違う点は、【送信ボタン】が『キーボード』から『ディスプレイ』の中に移動しただけである。
更にWikiの文面を続けると、
各モジュールが比較的截然と分かれ、プログラムの見通しがよくなるとともに、ユーザインタフェース (UI) 部分を別のモジュールに取り替えることが容易となるのが利点である。自動プログラミングなどにも適している。
となっている。
僕とは反対の感想をお持ちの方が書かれたらしい。だが、どちらもＭＶＣの一側面であり、
使い方次第では、
本当に【プログラムの見通しがよくなる】が、普通ただの【伝言ゲーム】に成り下がるしろものである。
要は設計次第で、各モジュールが比較的截然と分かれとなっているか、なっている様に見せかけているかである。
この辺は仕様書では綺麗に誤魔化しているので、ソースを読んでみてみるまで全く判らないのである。
という訳で、本当は『自動プログラミング』にこそ適したＵＩ設計手法なのであろうが、
『自動プログラミング』でまともなモノはまだ見たこともないので、当分無理そうである。
というのも、web.xmlにしろ、validateにしろ、一から作成するなんてことはまず考えに入っていないとしか思えないんだがら・・・（笑
もっとも、httpd.confやsendmailやphp.iniも、同類ですけどね・・・。
そんなシロモノばかりを集めて出来上がったのが今のインターネットだから・・・。
実際は、コンピュータより手間や保守の方が高く付くのは仕方が無いし、Linuxをインストしたら、ぶっ飛んだりしても仕方がないんだろうね。
ネットワークだけに仕様なんか無視して増設しまくるから、物凄い蛸足配線になっていても別に不思議ではないと思う。（大笑
現行バージョンのＣＯＢＯＬは、レアものなので、論ずる事自体意味を持たない。
ここでは、１９７０頃のＣＯＢＯＬ全盛期のものを前提にしている。
こう書くとＮ８８－ＢＡＳＩＣそのもののように思えるが、まぁ大して差は無い。
強いて言えば、実行手順に差がある。
ＵＮＩＸで ps -elf | grep java | grep jboss ＞ /tmp/jboss.log
とパイプで繋いでいくようにプログラムを束にして実行するのがＣＯＢＯＬ風である。
N88-BASICでは、
ＬＯＡＤ ｘｘｘｘ
ＲＵＮ
となるので、続けて別のプログラムを実行するのは何かと面倒であった。
つまり、ＣＯＢＯＬでは、１個のプログラムをいくつかのパート分けするのが普通で、
急ぐ仕事程、細かなパートに分けられていった。
※パート分けという仕事は、設計というより、分担であった。
しかし、この方法によって、大きな方法論上の収穫があった。
なんでも、一本のプログラムにしてしまうと、ちょっと変ったものが必要になっても、
一から作り直した方がマシなのはVisual-Studioを使っている人なら理解して
もらえるだろう。
プログラムをある程度の大きさに分類するという基本的な考え方はＣＯＢＯＬで成立した。
しかし、物事が複雑になると、ある程度の大きさに分類しても大まかすぎで訳がわからない。
例） 月旅行 ＝ 月に行く ＋ 地球に帰る
もっと、人を動員して、
「月に行く」チーム＋「地球に帰る」チーム
更に細かく・・・と、普通のプロジェクトが人海戦術で組みあがっていくように、
ＣＯＢＯＬ社会でも上級ＳＥ，中級ＳＥ，下級ＳＥ、ＰＧ（プログラマ）、ＣＤ（コーダー）と
階層社会が出来上がっていったのである。
つまり、上級ＳＥとは予算や人材確保などプロデューサ役のことであった。
しかし、今では、下級ＳＥ～ＣＤまでは、ＰＧ＋テキストエディタ＋階層構造を持ったコンピュータ言語で十分。
人件費削減というわけではなく、ＳＥ階層化社会が生み出す延々数百（あるいは数千）ページの【仕様（あるいは願望）定義書】よりも、
図式化した【アルゴリズム】や【フローチャート】の方が、まだ理解しやすいし、今でもある【ワークフロー】の方がマシである。
※個人的には【ＵＭＬ】は、【仕様（あるいは願望）定義書】の子孫だと思っている。だって、意味不明でしょ？？？
この辺の事情から、ＳＥの階層を増やす続けるよりもプログラミング言語の方に階層構造を持った方がマシと
思う人が少しづつ増えていった。
※エドガー・ダイクストラ etc
そうは云っても現実社会を支え活躍中のＣＯＢＯＬとＦＯＲＴＲＡＮに変革（言語仕様変更）は混乱の元でしかなかった。
そして、今やＣＯＢＯＬとＦＯＲＴＲＡＮは取り残された化石言語になったのである。
しかし、
目で肌でしっかり感じることが可能だった時代にはＳＥ多重階層化社会が一番向いていたのかもしれない。
合掌。