教育工学ででてくるＧＢＳ理論をオブジェクト指向で考えるとゲーム開発で面白いかも

　教育工学に、ゴールベースシナリオ理論（ＧＢＳ理論）というのがあるそうだ。
　で、ＧＢＳ理論は、（事例ベース推論）に基づいてシミュレーション型教材を構成する7要素（ゴール、ミッション、カバーストーリー、役割、シナリオ操作、情報源、フィードバック）を提案。

　しているそーな(上記斜体は、ここのＧＢＳ（Goal-Based Scenario）モデルから引用）

　つーことは、だよ。。
　もし、
・事例ベースが作れれば、つーか、作り方がわかり、
・ＧＢＳ理論をシステム開発理論、たとえばＵＭＬにマッピングできれば、

　ＧＢＳ理論を元に、シュミレーションゲームが（って、教材じゃないのかって、いいのいいの）ばんばんつくれるっていうことだよねえ。。

　たとえば、東洋英和女学院の女子高生にウケル事例ベースができれば
　　　　ときめきメモリアル東洋英和女学院編
　で、そのしくみで、フェリス女学院、神戸学院女学院版は、簡単に作れそうだし、

　東大生をあつめて、勉強方法の事例ベースを作れば
　　　　実録、ドラゴン桜

　お医者さんをあつめて、事例ベースをつくると　
　　　　ブラックジャック。。つーか、それって、医者の教材っていう気もしなくはないが

　あとは、対象を変えて、事例ベースを作れば、ばーんばんシュミレーションゲームができると。。。

---

　で、どーも、この理論、ＵＭＬにマッピングできそーよ。

　っていうことで、ＧＢＳ理論経由で、事例ベースからＵＭＬ（オブジェクト指向）でシュミレーションゲームを作る方法を考えてみたい。

　まず、ＧＢＳをＵＭＬに落とし込んでみる。

---

■ＧＢＳの７要素をＵＭＬへ

　まず、ＧＢＳとは？なんだが、７つの要素があるそーな
ゴール・・これは、ゴールっす。つまり、事後条件みたいなもんやな
　　　　　→これは、直接示さない。ゴールがわかってしまったら、ゲームにならない
　　　　　　この女の子を口説くには、ＡしてＢしてＣして。。。とやることがわかって
　　　　　　しまったら、ゲームは成立しない
ミッション・・最終的な課題のようだ
カバーストーリー・・・ミッションをおこなうための初めの状態、事前条件にからんでくる
役割・・アクターとして、クラスになるもんだと思う
シナリオ操作・・・役割が取りえる操作なので、アクタークラスのメソッドとなる
情報源（リソース）・・アクター以外のクラス、アクターはこいつをアクセスする
フィードバック・・・メソッドが行った結果に対する評価、＝メソッドの結果

ってかんじかなあ。。よくしらべてないからわかんないけど。。。

---

■なんで、こんなかんじで置き換えられる

ミッションを課題とし、
カバーストーリを事前条件として
リソースと役割のクラスを生成し、役割クラスにシナリオ操作に該当するメソッドをおく
シナリオ操作に対応するフィードバックを結果として定義し、
ゴール達成が事後条件になる

と思う。

じゃあ、それらの７条件を、どーやって、事例ベースを作るか？だよね

もちょっとまってくれ、これから勉強するから（＾＾；）

IHTMLVIEWERの具体的な使い方（２）ＨＴＭＬ文（かな漢の制御指定とか）

　このブログのつづきで、IHtmlViewerの話。
　ここでは、IHtmlViewerに読み込ませる、つまりIHTMLVIEWER_ParseBuffer
の引数として、受け取るＨＴＭＬデータについて。
　これ、テキストデータとして渡せばいいだけなので、ソースに直接形手もいいんですけど、今回はＨＴＭＬファイルとして、別個にしておきました。このファイルをIFileMgr,IFileを使って読み込み、それをIHTMLVIEWER_ParseBufferに渡すってことっす。

---

　で、ここにソースがあります。
　ＨＴＭＬファイルなので、そのまま開くと、当然表示しちゃいますので、書いてある内容を以下に書いておきます。

＜html＞
＜body＞
＜form method=post action=brewdic:showevent＞
早うちの練習＜P＞
以下の文を打とう！　　＜input type=submit name=do value=挑戦する＞＜P＞＜P＞
これは、練習文です。＜BR＞
＜input type=text name=nyuryoku istyle=1 mode=hiragana maxlength=20 size=20＞＜P＞
＜input type=submit name=do value=打ち終わった！＞＜P＞
正解率＜input type=text size=3 name=seikai＞％　時間＜input type=text  size=3 name=zikan＞＜P＞
＜input type=submit name=do value=終了＞
＜/form＞
＜/body＞
＜/html＞

上記＜　＞　￥　は実際には、半角です。

で、ごらんのように普通のＨＴＭＬなので、説明は要らない。。。とおもうので、ＢＲＥＷにおける注意点だけ、書いておきます。

---

■formについて
　Ｆｏｒｍのアクションはbrewdic:showeventにしておいて、このformタグから／formのタグのなかに、入出力するタグを書きます。Ａ（アンカー）タグも、この中に書いてください。

　対象となるのは、A,input(typeはsubmit,text,checkbox),select,textboxですが、これが、全部、思ったとおりににつかえるかどうかは（＾＾）ｖ
　安全なのは、inputのtextとsubmitです。これで、構成する限り、問題ありません。

---

■長さの指定
　inputのsizeは、実際の幅、maxsizeは入力長の最大長をしめします。
　したがって、size=9 maxsize=20のように、sizeのほうが短い場合があります。
　この場合は、フォーカスがないと、初めの部分だけ表示され、フォーカスがくると、マーキー（文字がかいてんかいてんかいてんかいてん、あ、この会社あったっけ？になる）になります。

---

■かな漢の初期設定、字種指定
　かな漢の初期値指定は、inputタグの属性istyleで、入力内容指定はmodeで行います。
　どのような、属性値があるかは、ボーダフォンの技術資料のHTML編を参考にしてくださいって、なんじゃそりゃ（＾＾；）

　で、当然ながら、その値が有効かどうかは実機で確認してみてください。

---

■複数行指定

　入力エリアで複数行指定したい場合、普通はtextareaにしますが、（これは機密の文書にかいてあることなので、詳しいことはかけませんが）この場合は。。。textareaをつくって、実機で試してみてください（って、書くってことは、で、実際に上でやってないってことは。。想像にお任せします）

　ということで、複数行指定の場合、IHtmlViewerに。。ここから先はかけません（しないほうがいいです、ITextCtlで複数行にしますとかかいたら、まるで「できない」って書いているようなものなので、かけません。。うん？）

---

■selectに関して
　selectを一度やると、結構ＩＤが後ろに行きます。なぜか。
　なお、selectのselectedについて、どのような状況でもうまくいくかは、実機で確認したほうが、身のためです。
　おなじように、確認したほうがいいのが、inputのcheckboxだったりします。

---

■Aタグについて
　このシリーズで、IDを取得して、いまフォーカスがある位置を取得する方法によって、Aタグが押されたかどうかを取得することができます。ただし、Aタグの場合、IDとして取得する値は、IHTMLVIEWER_FindElemで取得できる値に、HREF=ＵＲＬ先のなさがを足した値、それもHREF=の５文字を含めてです。たとえば、＜A HREF=ab＞とび先１＜/A＞と書いた場合、IHTMLVIEWER_FindElemで取得した値＋STRLEN("HREF=ab")つまり、７足すことになります。
　

---

ぱっとおもいつくのは、これくらい。

また、思いついたら書き足しておきます。

このあとは、（１）カーソル移動方法についての１回目、ソースのヘッダ部分と関数概要の説明になると思います。といっても、次回、いつやるか（やるのか？）分かりませんが。。

銀行とキャリアが提携したなら、ケータイからカタログ通販の場合、そこから引き出したい。その時

　さっきの話のつづき。

　で、カタログ、これは、商品の通販カタログでも、旅行のカタログでも、なんでもいいんだけど、そーいうデータを、ＤＢに入れて、ＣＧＩで出す。

　これは別にいいんだけど、そのあと、決済まで、いっしょにやろうとしたとき、カードとかを使うんであれば、今までどおり、その決済会社のサイトに飛べばいい。
　これは、ＰＣでも、ケータイでも（今ＳＳＬきくので）、それはそれでいいんだけど、

　もし、おサイフケータイの中から決済したいとか、銀行と提携して、それから決済したいとなった場合、どーするか。

　まあ、iアプリの場合、銀行と提携しているなら、そこから、ブラウザ起動して、いままでのケータイの決済と同じようにすればいい。

　で、おサイフケータイの場合、アプリからアクセスできる、クラスを用意すればよさそう。
　決済時、アプリを呼び出し、そいつで決済したら、またブラウザに戻る（あるいはブラウザを起動する？）。
　もちろん、ブラウザのタグでおサイフケータイにたいして、読み書き可能なら、それはそれで結構結構。

---

　で、問題は、ＢＲＥＷの場合。たしか、auと銀行と提携してたけど、その場合、銀行預金から引き出すとき、そーいう関数を作るのか、アプリを用意してくれるのか？

　とはいっても、仮にそんなの用意してくれたとしても、これを企画出して、審査とおってそれから。。。っていうのは大変そう。

　ってなると、やっぱり、今のケータイの決済の方法を使うか、ってことになる。
　（銀行が決済サイトを用意する場合、方法的には今までとあんまり変わらない。決済サイト先がかわるだけ）

　おサイフケータイのような、ケータイにアクセスしないとわかんないものは、企画出して、審査とおってそれから仕様がわかる。。。だったら、ちょっと企画練るのにリスク大きいよね。

---

　ってことで、銀行とキャリアが提携しても、ドコモならともかく、auの場合は、あんまり、恩恵ないような気がするなあ。。中小企業の場合は。。大手はメリットあるんだよね。きっと。

求人誌やカタログは、ケータイアプリやWeb2.0になると、いろいろ使い倒せるかも

前のブログの最後のほうに書いた、


iアプリで、スケジュール帳と連動したりとか。。
まあ、これは別にかくことにするけど。。


ってことについて。

　現実的に、求人誌や商品カタログなど、いわゆるDTP編集しているものは、XML化してデータを持つと、たしかに、DTPでも、Webでも（iモード、EZWeb含めて）共通になるので、便利っていうことはある。ただ、この場合、CGIやPHPで、DBを検索して表示しても、大して変わらない。
　なので、XML化して、大きなメリットがあるかといわれると、。。（＾＾；）

　ただ、Web２．０になってくると、サーバー側にXMLを置いて、クライアント側で検索とかをかけて、必要なXMLを呼びだし、表示できるので、サーバーの負荷がへる（ページ作成のレイアウトの作成をしなくてよい）＆自分の好きなフォーマットでみれる（クライアント側に好きなCSSを置いておいて、切り替える）っていうメリットがある。

---

　ここまでは、たいしたこと無いんだけど、ケータイのアプリにしちゃえば、確かに、マイクロソフトが実現したと前の記事に書いてあるように、

・必要なデータを保存したり
・それをスケジュール表にいれたり
・メモしたり、
・すぐに電話したりできるよね。

データ保存は、iアプリならスクラッチパッド、BREWならそのままファイル保存すればいいし、

スケジュール表はiアプリの場合、com.nttdocomo.system.ScheduleDataクラスをつかうの？
（iアプリコンテンツ開発ガイド for DoJa-4.X/4.XLE 詳細編　第3.00版 P162)
BREWだと・・・あったっけ？無かったら、スケジュールのアプリをつくって、そのアプリのフォルダあるいはshareに、IFileMgrで書けばいいし（規約注意：すくなくともshareへの書き出しは、技術的以外にやることあり）、

メモって、スクラッチパッド、ファイルに書けばいい話だし、

電話は、iアプリでは、com.nttdocomo.util.Phoneクラス、
ＢＲＥＷでは、ITAPI_MakeVoiceCall()なの？？よくわかんないけど・・

---

　てなわけで、求人誌が、ケータイアプリになれば、

・サーバーにXMLなり、RDBなりを置いて、まあ、ケータイアプリから条件を送ってもらうと、
　それに適合するデータを送り、
・そのデータを自分の好きなように見れて
・それをチェック・書き込みしたり、ブックマークしたり、できて
・気に入ったら即電話
・スケジュール表に面接日などを書き込める

っていうことになるかもしんない。

　つまり、アプリ連携することで、一連の動作がケータイでできるという、メリットがある。

---

　さらにすすんでくると、

・ケータイアプリ側に条件を入れておいて、
・定期的に検索を自動的にかけさせ、
・データがあったら、ケータイがなる

　といったように、今までは、雑誌を見て探すという行為を自分がしないといけなかったが、それをケータイ側でやってくれるということになるかもしんない。

---

　で、さらにそれが進むと、

・ケータイの検索条件を、あらかじめ、会社のほうに登録する
　（かりにリクルートとしましょうか）と、
・その条件に合ったデータを配信する

　という方法になるかもしんない。え、なら、iアプリでなく、メールでいいじゃんとか、そーいうオチもあるのだが、それはこっちにおいておいて、そーすると、リクルート側に、検索条件があつまることになるよねえ。

　そーういと、どういう条件で検索している人が多いか？ということが、わかるわけ。

　これを、求人会社側に提示すれば、求人会社も、「あ、２０代で募集したかったんだけど、３０歳代の人で検索している人が多いから、３０歳までひろげよう」とか、判断できる。

　つまり、求人会社側が、どういう人が見ているか分かるので、それも考慮に入れて、求人側が広告を出せるようになるってこと。

　ただ、これは、個人ページを持てば、ケータイに限らずできるけどね。CGIの世界でも、上に書いたようにメール配信でもできる。

---

　で、こんなことは、どーでもいいのだよ、実は、カタログだ、もっとおもしろいんだよ。

　それは、別の機会に。