みんちゃのサーバ向けポート設定とか

　ふと思ったのですが。

　みんちゃはポート設定が結構めんどーです。クライアントとしてつなぐ分には他のアプリケーションと大差ないのですが、サーバにしようとした場合、やはり、NATやらルータやらにいろろ設定しないといけない。
　しかも、１ポートだけならともかく、基本11ポート(defultだと3530～3540?)と、Windowsの場合は追加で参加人数分のポート(13000～13099?)を、外部に解放する必要があります。

　ところで。MicrosoftのMessagerが利用している技術に、UPnPというのがあります。これは、近距離での機器間の通信やら制御を行うためのプロトコルなんですが、このなかに、NATの静的な変換テーブルの制御もあり、MS-Messagerではそれを利用していたりするわけです。

　そこで、JavaなりLazarusなりREALBasicなりで、UPnPをたたくだけのアプリケーションを作成すると、サーバを立てようとしている人も結構簡単に利用できてよいかもしれない　と思うところです。

# なお、WindowsXPにはUPnPのライブラリが載っているため、VBScriptで簡単に制御できます。

自力で作ってみようと思ったんですが・・・・以下の取得方法がわからずに断念しました・・・

・NAT Traversalに応答した、UPnPデバイスにつながっているNICのIPアドレスの取得。
　要は、登録する転送先のIPアドレスを取得する方法がわかりませんでした・・・最近のＰＣだと２ポート３ポート(ノートPCだと、有線+無線で２ポートとか)が当たり前なんで、NICを列挙して１件目　とかではだめなような気がする。

telnet型チャットシステム

　何か足りないなぁ　と思っていたら、掲載用ページを作成していなかったので作りました。こまかく書いているというわけでも無いですが、無いよりは良い・・・・はず。

掲載ページ
・Telnet型マルチプラットフォームチャットシステム(WeykChatLite)

　このチャット環境を使う利点のうち、大部分は、オンラインダイス(NA2 for Onichat)が使えるという点なんですが・・・あっちはまだページはありません。本体を掲載するなら、いくつか定義ファイル(DEFファイルか、NADファイル)を載せたいところですが、公開許可をどーしたものか・・・・元作品の著作者側は公開指針を出しているところのを選べば良いとして、じつは、定義ファイル自体が複数の人の手で作成されているものが多くて、しかも、連絡が付くんだろうか　みたいな。有名どころでSwrodWorld（の簡易版DEF）あたりか、手札が管理できるとゆー点をアピールするために東京NOVAあたりがよさそうなところ。
# 手札と言うと、深淵、TORGもあるけど、著作者側許可がびみょー。

REALBasicで生成したアプリケーションのIntelMac対応とか

　WeykChatLiteをIntelMacで試してもらったところ、動かないとゆー話をうけ、調べてみました・・・・

結果、以下のことがわかりました。
・MacOS Xでは、OS 8/9のころに使われていた、リソースまで全部含めて１つのファイルにまとめた形の実行と、Mac OS Xでの、ファイルを個々に分けて管理する方式の２つの両方をサポートしている。
・ただし、IntelMacのPowerPC互換環境では、１つにまとめた形式（旧形式）は、サポートしていない。
・よって、REALBasicで生成するとき、Mac OS X専用を選んで生成すると良い。

んで、早速試してみると・・・実行ファイルの変わりに実行フォルダが生成されてる・・・・
どーやって配布したものだか悩んでいろいろ調べたところ、Mac OS Xでは、このフォルダこそがアプリケーションであることが判明。特定の形式で作成したフォルダにたいして、拡張子を「.app」にすることで、それを１つのアプリケーションとして扱う　とのこと。うーむ、おくがふかい・・・・
なお、Mac上でフォルダを作成し、おもむろに拡張子をappにすると、簡単には中を見られなくなるので注意（笑）

telnet型チャットシステム

　以前に作成していた、NIFTY-RTをベースにしたチャット環境に、メタサーバ（サーバを管理するサーバ）を利用した形の変更してみました。
　どのくらいの環境からメタサーバが機能するか、試したいところ。
Win用、Mac9用、MacX用、Linux用

なお、データ形式がびみょーに更新されているため、以前に起動したことがある場合には、設定ファイル(*.rdb)を削除しておく必要があります。

DiceMan更新(みんちゃ用特定システムダイスツール）

　ひさびさに更新・・・というか、以前はSWRateとゆー名前だったものです。その名の通り、ソードワールドＲＰＧのレーティングによる判定(?)を支援するためだけのツールだったもの。
　新たに、ウィッチクエストのチャレンジ/魔法と、アースドーンの判定(ステップを参照するあれ)を加えて、１つにしました。
　とはいっても、普通の数式やダイス式を指定する場合で演算子は加減算のみ。各システムの固有の判定を行う場合には基本的に演算子を使用できない（あらかじめ頭で計算して指定する）んで、他のツールに比べて不便なわけですが・・・じゃぁ、なんで作ってあるのかというと、

　これらの判定は、一般的なダイス式がふれるだけの環境では面倒（ふり足しとか）だから

という理由。なので、ピンポイント的に特定の判定のみ組み込んであります。ウィッチクエストの魔法は本当はどーでもよいんですが、チャレンジを実装したついで。チャレンジもふりたしがあるわけでもないんですが、たとえば、「チャレンジ６」を、12d6とかで代用して、それを２個づつみながら同じ値だったら・・・というのは見誤りやすいしぱっと見て判りずらいので実装しました。

サイトURL
・みんなのチャット♪用TRPG判定支援ツール

もろもろ更新

　とはいっても、チャット用のツールではなく。
以下のツールを修正しました。

・フロアタイル（http://www.weyk.com/floortile/）
　２ファイル構成を１ファイルに（ファイル名で動作が変化していただけで、中身は一緒だった）
　ユニットの欄にあまりがあるまま表示モードに移行するとエラーとなっていたのを修正。

・ＷＱキャラメ（http://www.weyk.com/create/wq/）
　魔女の猫の表示の際に色柄が表示されないのを、表示欄追加。
　SHIFT_JISからEUC-JPに変更。

fumbleのネットワーク周りを考える

　なぜか、fumble-minchaをつなぐ部分を作成したわけですが、いまのところ、fumbleとみんちゃAPIが結構強く結合をしています。それにともない、fumble側の動作自体も、みんちゃのAPIにひきづられてます。それは、まぁ、悪いことではないんですが、そこにさらに「汎用ツール目指しているんだから、おーにちゃっとやＩＲＣとかにもつなぎたい」とかの話をする人もいるわけです。
# 「いきあたりばったり」で作るのか、「最終形を念頭において」作っているのか、いまいちはっきりしない。なんか、また全改定するっぽいし。どっちかとゆーと、あまりに機能をはしょりすぎて、みなで使うツール目指して　というよりも、開発者のおもちゃと化しているだけな気がする。

　とりあえず、fumbleからみたネットワーク機能と、みんちゃが提供している（みんちゃ固有の仕様）を、独立して考えるために、「fumble側に」汎用的な、「fumble側が期待する」interfaceを１つ作成した上で、そのinterfaceと、実際のみんちゃ接続クラスを橋渡しするクラスをはさみたいところ。このinterfaceを考えるのは、本体側を待ちます。どうしたいんだか判らないし、先にいじっても、なんか、全改定する気みたいだし。そもそも、今後どうしたいのか見えないし。

　その際にどーしても避けて通れないのは、「fumble側で機能の有無を取得して処理を変更する」という機能。たとえば、みんちゃには、SEND(PRIVMSG)がない。正確には外部アプリに送信・取得するAPIを提供していない。そのため、いまのところ、fumbleの本体全体に受信モード/送信モードという概念が無い。そのとき、どう動作するかは、adapterクラスの実装によるわけです（送受信モードといった概念自体は導入しておく必要がある）
# 送信モードは、%2 とか書くと、SENDで結果が飛んでいったアレです。手札表示とかでも、内部で使ってます。
# 受信モードは、SENDで受信したコマンドや、通常発言のコマンドにたいして、とくに送信モードを指定しない場合に、同じ方法で返信するための記憶してます。
# あとは、動的にコマンド入力者を変えるのもよくつかってました。「＞ほげほげ」という書式のアレです。これも受信モード・・・？「＞」とすると、元に戻ります。

fumble-更新中

　ちまちまと更新中。主な目的は以下の通り。
・文字列の表記である"や、括弧の対応をもって、コマンドとして扱う。
　→途中に半角スペースがあったり、文字列中に括弧があっても誤動作しないように。

・COMMANDのform部分の処理の変更
　関数の形式で制御構造を扱うのは無理があるため。

今週末ぐらいに出来るとよいなぁ　と思わなくもない。
※_ifや_whileを使っているformの定義ががらっと変る・・・かも。とりあえず、制御構文は、if-elseとwhileのみ。

telnetベースのチャットシステム

　いろいろ考えて、とりあえず、telnetベースのチャットを完成させようかということに。
理由は以下の通り。
・おーにちゃっとさーば互換に出来る
・プロトコルが規定済み
・NA2が使える
・現状のfrpgs.clientに限れば、ユーザがコマンド体系になれている。

ただし、現状では同じtelnetベースであるおーにちゃっとサーバは、１部のセッションを除いて使用されていない。以下の理由が考えられる。
・サイトとして推奨はしていないこと（いちおー、推奨ツールはみんちゃ）
・サーバの導入の大変さを、利用する上（クライアント）での大変さと誤解されている（説明ページの不備）
・フリーで良いクライアントが無い
・新規ユーザを呼ぶ場合、コマンド体系に慣れてない
・クライアントユーザが、接続するのが大変（ＩＰやらなんやら）

なので、以下のようなものを想定
・サーバ兼クライアントで１つのプログラムにする
・ユーザ一覧リストを表示し、SENDはそこからGUIベースに行えるようにする
　※ただし、実際のユーザ一覧とずれる可能性があるのはあきらめる。
・メタサーバ（みんちゃのリンカー）相当を導入する
・接続に必要な情報・手続きを簡単にする（接続先ごとの管理を必要ないようにする）

とりえあず、サーバ兼クライアントで通信可能なものを、ここにのせてみたり。
メタサーバの実装と、情報の簡略化は、まだ。
# いまが、おーにちゃっとと同じぐらいの設定の複雑さ。

fumble-12/12更新

以下を項目を更。

以下のタイミングでPCデータの読み込み・保存を行うようにします。
・プログラム起動時に、default.defの読み込み後にdefault.defに指定されているPC.TXTを読み込む。
・プログラム終了時に、現在のdefに指定されているファイルに保存する。
・system=コマンドによりdefの切り替えに成功する際、
　１．新しいdefの読み込み前に現在のdefに指定されているファイルに保存する。
　２．新しいdefの読み込み後に新しいdefに指定されているファイルを読み込む。
・PC保存ボタンを押した際、現在のdefに指定されているファイルに保存する。
・saveコマンドをパラメータなしで呼び出した場合、現在のdefに指定されているファイルに保存する。

上記保存/読み込み動作で正常に処理するためには、各defに異なるPC.TXTの名称を指定する必要がある。基本的に、defを作成する人が、PC[defの名前].txtとするとよい・・・かもしれない。
# たとえば、wq.defなら、pcwq.txt。

実行に必要なファイルは以下。
・fumble_weyk_051212.lzh

fumble-通常のコマンド(12/07更新)

　通常に入力したコマンドがどう扱われるかを記載。

最後に「==」が指定されている場合。
　単なる数式として計算し、計算結果のみを表示する。
　例）1+1= → 2

最後に「=」が指定されている場合。
　単なる数式として計算し、計算結果を演算経過と=の右に付加して表示する。
　例）1+1= → 1+1=2

置換されて最初から再評価になるケース
　まず、Aliasについては、置換後に再度、最初から評価される。
　つぎに、能力値の指定でその能力値に判定式が付いている場合、置換後に再度、最初から評価される。

システムコマンド。
　パラメータの扱いは各システムコマンドに依存。出力される内容も各システムコマンドに依存。

「@」で始まるdef内定義のコマンドの形式になっている場合
　ユーザ定義コマンドとして処理され、ユーザ定義の書式に従って出力されるケース。

そのほかのケース。
　状況によって、以下のいずれかになる。
　１．なにも表示されないケース。
　２．単なる数式として計算し、演算経過部分に=と計算結果が付加されて表示されるケース。
　３．計算の演算経過部分のみ表示されるケース。
　４．標準判定（COMMANDの@defaultに定義されているコマンド）として処理され、@defaultに定義されている書式に従って出力するケース（「@default,」の後ろに入力した文字が付加されて実行されるのと同様）

１．のケース
　最初の項目が代入である場合（hp=hp+2など）
　計算式の途中に代入がある場合は含まれない（1+(hp=2)+2など）
２．のケース
　１に当てはまらない場合で下記の場合。
　　ダイス（nDmの形式）を含む。
３．のケース
　１及び２に当てはまらない場合で下記の場合。
　　式の先頭が関数の呼び出し（「_hoge(」の形式）となっている。
４．
　１〜３のいずれにも当てはまらない場合。

なお、上記のどのケースにおいても、代入式の形で能力値を変更（0の加算のように実質的には変化しないケースも含む）したばあい、全ての処理の終了後に、１行にまとめて更新後の能力値が表示される。この場合、同じ能力値が何度更新されても、１度のみの出力となる（３種類の能力値が更新されていれば、３つとも表示されるが、１種類を３階更新しても、最終的な値で１回のみ表示される）

fumble-起動

　みんなのチャットから使用できるようにするための手順を簡単に。

１．自分だけ使用する場合。
　みんなのちゃっとを起動しておく。
　接続ボタンを押して、接続を行う。
　「Solo」「Msg」を選択する。
　以降、自分で先頭に「#」をつけた発言をすると、その発言に反応して結果を送信するようになる。

２．一人が起動して、全員が利用する場合。
　みんなのちゃっとを起動しておく。
　接続ボタンを押して、接続を行う。
　「All」「Msg」を選択する。
　以降、だれかが先頭に「#」をつけた発言をすると、その発言に反応して結果を送信するようになる。
　※だれの発言に反応したかも合わせて送信します。

fumble-画面

　自分で起動したとき場合の、画面の操作やら意味について。

コマンド欄。
　ここにコマンドを入力して「ＧＯ」ボタンを押すことで、結果をシステムメッセージ欄に表示可能。
　実行した結果は、接続状態と処理モードに従う。

接続ボタン（状態により変化）
　みんなのチャットと接続して無い時に表示。
　みんなのチャットを起動したうえで、このボタンを押すことで、みんなのチャットと接続した状態（接続済み）になる。

接続中/切断中ボタン（状態により変化）
　みんなのチャットと接続/切断の内部動作中に表示。
　状態を表示しているだけで押すことは出来ない。

切断ボタン（状態により変化）
　みんなのチャットと接続済みであるときに表示。
　このボタンを押すことで、みんなのチャットとの接続を解除（未接続）する。

ＧＯボタン。
　コマンド欄に入力した内容を実行するさいに押す。
　何も入力せずに押すとエラーが表示されるので注意。
　実行した結果は、接続状態と処理モードに従う。

終了ボタン。
　本ソフトを終了する。
　終了時、「ＰＣ保存」にて明示的に保存していない登録データは消えるので注意。

応答モード。
　「None」「Solo」「All」の３種類があり、これにより、みんなのチャットから受信した内容をどう扱うかを指定する。
　None
　　何もしない。だれの発言に対しても何も反応しない。
　Solo
　　自分で発言した内容にのみ反応する。
　All
　　全ての発言に反応する。

処理モード。
　「None」「Msg」「Msg/Cmd」の３種類があり、これにより、どこの内容を処理した結果を送信するか指定する。
　None
　　どこで処理した内容も送信しない。
　Msg
　　みんなのチャットから受信した内容にのみ送信する。
　Msg/Cmd
　　みんなのチャットから受信した内容とコマンド欄に入力してGOボタンにて実行した内容を送信する。

テスト用UID欄、登録PC欄。
　どちらかというと開発者の動作確認用。設定・変更せずそのまま使ってください。

ＰＣ保存ボタン
　現在保持しているＰＣの登録情報をファイルに出力する。
　デフォルトでは、「pc.txt」。defファイル内で、PC.TXTの項目で変更可能。
　個別に指定されていない場合、全てのシステムで共通されて同じな名前に出力されるので注意。
　明示的に保存せずに終了すると、保存されて無い情報は捨てられる。

システムメッセージ欄
　コマンド欄を使用してコマンドを実行した際に結果を出力する。

fumble-通常のコマンド

　通常に入力したコマンドがどう扱われるかを記載。

最後に「=」が指定されている場合。
　単なる数式として計算し、計算結果を=の右に付加して表示する。

置換されて最初から再評価になるケース
　まず、Aliasについては、置換後に再度、最初から評価される。
　つぎに、能力値の指定でその能力値に判定式が付いている場合、置換後に再度、最初から評価される。

システムコマンド。
　パラメータの扱いは各システムコマンドに依存。出力される内容も各システムコマンドに依存。

「@」で始まるdef内定義のコマンドの形式になっている場合
　ユーザ定義コマンドとして処理され、ユーザ定義の書式に従って出力されるケース。

そのほかのケース。
　状況によって、以下のいずれかになる。
　１．単なる数式として計算し、=と計算結果が付加されて表示されるケース。
　２．標準判定（COMMANDの@defaultに定義されているコマンド）として処理され、@defaultに定義されている書式に従って出力するケース（「@default,」の後ろに入力した文字が付加されて実行されるのと同様）

１．のケース
　以下のいずれかの場合となる。
　　ダイス（nDmの形式）を含む。
　　式の先頭が関数の呼び出し（「_hoge(」の形式）となっている。
２．のケース
　１に当てはまらない場合。

fumble-ちょっと拡張

　掲示板のほうにも書いてますが、以下の点が拡張されてます。
・command区のformに、通常の数式が記述可能（式の演算をDM氏のものに更新したため）
・数式上での演算子が結構増えた（理由は同上）
単項の+,-,!
２項の+,-,*,/,%
論理の||,&&
比較の==,!=,<,>,<=,>=
代入の=,+=,-=,*=,/=,%=
　おまけで「,」。２項演算子で、右側の値そのものを返します。
・演算途中の値に型情報をもつ（Boolean,Integer,Double,String）
　0,0x00の形式で整数の指定が可能。
　0.0や0x00.00で浮動小数の指定が可能（誤差対策は未実装。まだ使い物になりません・・・）
　"hogehoge"で文字列の指定が可能。
・式の途中に代入式の記述が可能（あまり意味は無い・・1+(hp=2)*3=とかできる。）
・「#」の数で、非表示・改行無しの制御に対応。あわせて、改行なしで出力したままたまってしまったものを強制的に出力するコマンドを追加
　　#---表示する/改行する
　　##--表示する/改行を抑止
　　###-表示しない
　　flush 改行の抑止により内部バッファに残っているものを強制出力する。

これでほぼ、普通にさいころとして使う分にはだいたいたりるよーな気がします。

fumble-Attribute区

　frpgsにて開発・利用されている(?)みんなのちゃっと用オンライン多機能(予定)ダイス、「fumble」のAttribute区の記述について簡単に。

１行＝１能力値で定義を行う。
各行は、
　能力値名<TAB>初期値<TAB>判定式<TAB>別名
の順に定義する。余分な<TAB>を記述すると、解析がずれるので、見易すくするために<TAB>２つ・・とかは出来ない。

　能力値名は、表示される際に利用される。また、参照する際には能力値名と完全に一致する名前が最優先される（「Strength」という能力値がある場合、「Strength」で参照することで、他の能力値の別名に影響されずに参照することが可能。能力値名による参照では全角-半角・大文字-小文字も区別するので注意）
　初期値は登録した際に自動的に設定される値。いまのところ、ちゃんと動いてないっぽい？。
　判定式は、以下のいずれか。
・「-」を指定すると、判定式の無い能力値となる。この場合、能力値から始まる代入ではない式を記述しても、何も行われない。Lunacy/NA2にあったような更新も出来ないので注意（判定式がない能力値に限り、HP+3やMP-3などでで更新を可能としていた）
・置換先コマンドを記述することで、Aliasのように置換/コマンドの再評価が可能。ただし、{n}の意味がAliasのものとは異なる（※）ので注意。
　別名は、Aliasのものと同じ。ここで一致すれば、能力値名を一字一句正しく記述しなくても参照・設定可能。

※Attributeの判定式は、{n}の扱いがAliasの置換と異なる。
　・{0}はもともと入力したコマンド全体を置換する（能力値に一致した部分も含む）
　・{1}はパラメータ全体を置換する。
　・{2}は能力値として一致した部分を置換する（別名に一致する文字列か、能力値名のいずれか）
　{0}は、{1}{2}と等しい。個々のパラメータは分割されない。
　なお、判定式に「,{0}」と記述することで、@defaultにそのまままわすことが可能。
　（単に{0}と記述してしまうと、無限にループしてしまう）

fumble-Alias区

　frpgsにて開発・利用されている(?)みんなのちゃっと用オンライン多機能(予定)ダイス、「fumble」のAlias区の記述について簡単に。

　各々の定義は、行単位になります。構造は、「コマンド文字<TAB>置換後コマンド文字」の形式。
まずは、コマンド文字。
・全角-半角、英大文字-英小文字を区別しません。
・パラメータとの兼ね合いから、算用数字は使えません（パラメータとして扱われます）
・同様に算術に使う演算子も使えません。それもパラメータとして扱われます。
・特殊な表記として「*」「?」「[...]」というのを利用できます。
　「*」は、任意の文字の、任意の文字数と一致します。つまり、何でも良い　と（０文字とも一致します）
　「?」は、任意の文字の１文字と一致します。
　「[...]」は、[]に記述したいずれか１文字と一致します。
・特殊な表記以外の文字はその文字そのものと一致します。
・入力してきた文字に、コマンド文字が全て一致した場合、置換が行われます。

たとえば。
「判定」は「判定」とのみ一致します。
「判定*」は、「判定」（０文字とも一致）「判定する」「判定式」のいずれとも一致します。
「判定?」は、「判定」（？と一致する文字が無い）「判定する」（文字が多い）とは一致せず、「判定式」（？と「式」が一致）とは一致します。
「と[おう]りみち」は、「とおりみち」「とうりみち」と一致します。[]の使い方としては、主に、送り仮名の間違いに対応するためが多いです。「と*りみち」でも可能ですが、この場合は「となりみち」や「とんでもないまわりみち」とも一致してしまいます。

次に置換後コマンド文字。
・基本的に、全て置き換わります。もともと入力された文字は残りません。
・特殊な表記として、{n}（nは整数)、{n-}が利用できます。
・{0}は、元の入力文字のパラメータ部分全体に置換されます。
・{n}は、n番目のパラメータに置換されます。
・{n-}は、n番目のパラメータ以降の全体に置換されます。
※もともと入力されたコマンド部分の文字を置換後に残すことは出来ません。

例として、コマンドの単なる別名をつける場合には、
sys<TAB>system{0}
のようになります。
置換後もパラメータの部分を明示的に分けて起きたい場合は、
判定<TAB>@test,{1-}
のように利用します。
# {0}と{1-}の違いは最初のパラメータの前に予め付いていた区切り文字の扱いです。{0}では、区切り文字もそのままついてきますが、{1-}の場合、最初のパラメータ以降となるので、区切り文字は削除されます。

　置換されたコマンドは、再度、評価されなおされます。「 」によって、複数のコマンドを記述しておいたり、システムコマンド（登録とかsys=hogehogeとか）を利用したりが可能です。
※∞ループに注意。現時点では、回数や時間によるエラー終了は実装していません。

　なお、_for,_if,_whileは、式の１部の関数として演算中に呼び出されるため、コマンドとしての再評価が行われない（システムコマンドや、Aliasに定義したコマンドを呼び出せない）ことに注意してください。

ちゃっと環境またまた

　今時点で、既存の環境ではできず、また、代用が効かないものというと、トランプなどの手札のあるものの管理。
　また、CUIベースで実装すると、操作（カードを引いたり渡したり捨てたり）が、直感的ではないというのもある。

　そこで、その部分のみを扱うFlash(CGIとの連携形式）があると良いのかも。通信量の削減やサーバでの処理の軽減として、cgiと連携して動作するFlashをフロントエンドにするのは良い案かもしれない。
# cgiを単機能ごとに個別に作成することで、多機能化による負荷の増大を抑えたり、チャットとダイスと手札をまったく別のcgiにすることで、記述を単純化したり。

　やはり、カードやらトークンやらは、GUIで直接的に操作できるようにしたいところ・・（コマンドを説明せずとも数回試せば操作がわかる程度に）

ちゃっと環境ふらしゅ

いろいろ調査を継続すると、どーやら、フリーの環境ではUIComponentsを利用できなさそう。
# 通常、Flashで設置ちされているよーなことはできます。同が書いたり、画像やらであにめーしょんしたり。

そーすると、FlashをみすえてXMLによるSocket通信を利用した上で、JavaAppletもしくは、JavaApplication(Java Web Start)で組むのがよさそうかも。
なお、ツールを購入すると仮定すると、機能的には、Basicのほうでできそーなので、３万ぐらいでしょーか。遊び倒すには、Proのほうがよいので、そーすると、８万・・・
# いろいろ調査したり、本を読んだおかげで、Flash自体はなんとなく覚えた・・あとは、実際の環境がないと無理だな・・・

ちゃっと環境つらつら

コメント＆チャットで話した内容から、いろいろ。いろいろ。

追記その１

参加する際には、ハンドル名のみ入力。ユーザ管理は行わない。
必要に応じて、サーバパスワードを設定する。サーバパスワードのあるサーバへ接続するには、そのパスワードを入力する必要がある。
（ようは、みんちゃ♪とおなじつくり）

JavaAppletを用いたチャットでの問題点（@nifty interway時の経験）
１．ログをローカルに保存できない（プラットフォームによる仕様）
２．バックログが増えるとハングアップする（実装の問題？）
３．Mac OS8/9では動作しない（secure socketを使用しなければ、努力すれば可能っぽい）

それぞれに対策案
１．ログをローカルに保存できない（プラットフォームによる仕様）
　これはどーにもならないので、ログはサーバに保持しているものを、サーバ(http)経由でダウンロードする。
　参加にID/PASSによる認証を考えてないため、参加者に限定するのは不可能。結果として、PRIVMSGを含むログを送信者・受信者に限定して表示することも不可能。
　ただし、サーバパスワードによる制限はかける（ログを取得した時点のサーバパスワードに依存させるべき？）
　というか、後日にログを求めるなら、サーバを起動していた人から、メールでもらってください・・・・
　※Java Web Startとゆー技術もあるらしい。Java1.4以降の機能で、WebからJavaApplicationを起動する技術。「３．」の問題をおいておくとすれば、利用する価値があるかもしれない。

２．バックログが増えるとハングアップする（実装の問題？）
　interwayのRTでは、でっかいスクロールバー付きテキストボックスに、テキストをどんどん放り込んでいただけのようなので、「受信済みログ」と「表示（カレント部）」「表示（バックログ部）」を分けて管理するようにすれば、ＯＫ？
　また、セッションになると連続して巨大なログになるのは避けられないので、一定サイズを超える分の過去ログは、サーバから再取得？

３．Mac OS8/9では動作しない（secure socketを使用しなければ、努力すれば可能っぽい）
　JREのバージョンが違うため。1.1.8相当で、swingも無い（別途インストールすれば利用可能）。
　また、jarファイルの実行もできないっぽい（classならＯＫ）
　基本的には動作したほうがよいが、1.2以前と以降でかなり機能に差があるため、利用者数しだい？
　※もちろん、同一プロトコルを話す両バージョンを作るのが１番よい。

開発環境のコスト及び技術者の数の都合でJavaAppletのみを考慮していたものの、FlashのActionScriptにフリーなコンパイラがあるっぽい。
利用者側の利点を考えると、Flashのほうがよいような（pluginのインストールの案内が簡単。JREよりもインストール済みであることを期待できる。PDFのよーに、Viewerが多々あったりしない（バージョンは多数考慮する必要があるものの））

サーバ−クライアント間はただのSocket通信だから、複数用意してしまうのも手かもしれない。

以下、Flashの環境関連URL。上から、コンパイラ、統合開発環境、画像処理。
http://www.mtasc.org/
http://www.sephiroth.it/python/sepy.php
http://www.osflash.org/doku.php?id=swfmill

補足。Flashでの常時接続型通信は、XMLのみで、knownポートは不可らしい。

チャット環境案つれずれ

　チャットに関して、ユーザ(※)の導入・利用が簡単な方法を模索中。
今利用している方法は、ユーザの導入という点では、以下のような問題があり。

１．導入
　IRC
　・専用クライアントが必要。ただし、資料も多く敷居は低い。

　みんなのチャット♪
　・専用クライアントが必要。エラーメッセージがちょっと不親切。

　おーにちゃっとサーバ
　・対応したクライアントを探してきて導入する必要あり。標準として推奨できるようなフリーのものは無い。

　WEBチャット
　・なし。ＷＥＢブラウザがあればＯＫ。

２．利用
　IRC
　・名前に日本語が使えない。
　・繋がっているサーバ群内で、同名が利用できない。

　みんなのチャット♪
　・PRIVMSG系がログに残らないぐらい？

　おーにちゃっとサーバ
　・コマンド形態が基本的にCUI。
　・文字に装飾不可。
　・接続再起に関する情報をIP+Portでやり取りする必要あり。

　WEBチャット
　・cgiによる。一般的に、更新サイクルが長い。

余禄．サーバ導入
　IRC
　・必要なし。

　みんなのチャット♪
　・利用ポートが多く、ルータ/Firewallの設定はネットワークの知識が必要。
　・参加者のいずれかがサーバになる必要あり。

　おーにちゃっとサーバ
　・デフォルトが通常公開されないknownportのためプロバイダによっては不可（portをずらせばOK）
　・ルータ/firewallの設定が必要。
　・誰かの設置したものを、みんなで利用することは可能（自宅内サーバにする必要あり）

　WEBチャット
　・一般的なCGIと同様。プロバイダによっては、禁止している可能性あり。
　・誰かの設置したものを、みんなで利用することは可能。

このほか、今のところ使用していない方法としてWEBとJavaApplet/Flashを組み合わせて接続を維持したシステムがある。上記の項目に当てはめると以下のような感じ。
１．導入
　Flashは導入済みであることが多い。
　JavaAppletも実行環境が導入済みである可能性がある。

２．利用
　WEBチャット同様、サーバ次第。

余禄．サーバ導入
　自宅内サーバにhttpdと専用プロセスを起動する必要あり。

上記を総合して、以下のようなチャット環境を考える。
・サーバはサーバ用アプリケーションを使用する。
・クライアントはWEBブラウザ＋JavaAppletを使用する。
・使用ポートは、http用80と、チャットの常時接続で＋１（どちらも変更可能）
・リンカーとなる共通CGIを提供する（自サイト内に固定URL。デフォルト値）
・サーバアプリケーションからリンカーへの接続はhttpを使用する。
・クライアントはJavaAppletによりサーバに持続接続する。

そうすると、必要となるのは、
１−０．サーバとなるプログラム（共通部）
　リンカーへの登録。
１−１．サーバとなるプログラム（http部）
　ブラウザからの要求に対し、Appletの定義を含んだhtml及びApplet本体を返す。
１−２．サーバとなるプログラム（ソケット接続部）
　JavaAppletからの接続を受け入れ、チャットを行う。
　　リンカーへの情報更新。
　リンカーからのpingにpongを返す。
２．クライアントとなるプログラム
　サーバに接続にチャットを行う。
　JavaApplet？
３．リンカーとなるプログラム
　一般的なプロバイダ用CGI。perlもしくはphp。
　可能であれば、pingを各登録サーバに送信することも行いたい。

うーむ、どうしたもんだか。

オンラインセッション環境としてのみんちゃ

　frpgsではオンラインでセッションする際に使用する環境として、対応ＯＳ及び拡張モジュールのためのインターフェースから、みんなのチャット♪（以下、みんちゃ）を推奨しているわけですが・・・セッションで利用する上で、どーしても必要なのに無いものが１つあります。それは、
特定のユーザのみにメッセージを送信（以下、個別メッセージと記載）して、それを送信者と受信者のログに残すこと
です。個別メッセージの送信はできるものの、専用のウィンドウが開いて内容を確認し、また、送信の際も専用のウィンドウが開いてしまうために、通常の会話のログとは切り離されてしまいます。また、個別メッセージの送受信は、拡張モジュールからは一切関与できないため、手札のようにほかのＰＬへの非公開情報の管理にも利用できません。

　この辺が解決すれば、後のところは「不便なところもある」とか「ユーザに親切ではない」で済ませられるんですが・・・独自の個別メッセージ送受信機能と、ログの保存機能を含めた拡張モジュールつくんなくちゃダメなんですかね？
# 結果として、チャット画面や発現用の入力欄も一緒に持たないといけなくなるため、独自にチャットシステムを開発するのと変らなくなっちゃうんですが。

なお、みんちゃの開発環境だと思われるREALBasicは、今度REALBasic2005になって、また結構変るようです。これらで新たに導入されたよりよい機能もできれば積極的に利用してほしいところです。
# とりあえずは、5.5から導入された「サーバーソケットの同一ポートでの複数受付」とか。サーバ立てる際にルータ/firewallに必要な設定（ポートの穴あけ）が多すぎ。

オンラインセッション環境

　オンラインでセッションを使用と思うと、やはり、オンラインダイスツールもあったほうがよい。が、プレーヤー全員が難解な設定が必要となると話は別。

　そこで、私の考えるオンラインセッション環境に必要なもの。

・誰でも使える
　・インストールが簡単
　・セットアップ（初期設定）が簡単
　・起動/接続が簡単
　　・ユーザにネットワーク知識を要求しない
　　　・サーバが常設もしくはメタサーバが存在すること
　・多数の環境で利用できる
　　・ブラウザで動作もしくは最低限Win/Macで動作
・日本語サポート
　・メニューやらボタンやらが日本語（やりすぎに注意）
　・発言に日本語が使える
　・発言以外の部分（ハンドルやＩＤ）に日本語が使える
・マニュアル関連
　・オンラインヘルプが日本語で存在する（チャット中にコマンドで呼び出せるようなもの）
　・マニュアルが日本語で存在する
　・チュートリアルが日本語で存在する
　・詳細な解説サイトが日本語で存在する

全てを満たす環境はなかなか無いわけですが・・・・１番有効っぽいのは、ＷＥＢチャットですかね・・・
また、これらのことに多少目をつぶって、セッション支援機能の多いツールを使用するという選択肢もあります。こっちの方向が、OpenRPG（英語圏の人にとっては、ほぼ全部クリアなんですが。）

OpenRPG/日本語 Windows用簡単パック掲載

OpenRPG1.6.1/Japaneseの、Windows用簡単パックをサイトに掲載しました。95/98系の場合、追加作業が必要になるのでまだちょっと説明文が足りないんですが・・・XPやら2Kを使用している人は、試してもらえるとうれしいところです。

関連ページ
・OpenRPG日本語化計画
・

August 12, 2005 in オンラインツール | Permalink | Comments (1) | TrackBack (0)

　反応があったのに気をよくして、OpenRPGを、Py2EXEというツールを使用してWindows実行形式への変換にチャレンジ。
　単独EXEにはならないのと、サイズが巨大になるというデメリットはあるものの、PythonやらwxPythonをあらかじめインストールしなくとも動作させられるというのが強み。というわけで試してみると・・・

・変換中にエラーとなる(attrに無いとか言うエラー）
　→Py2EXEだかDistUtlsの変数の初期化漏れの既バグらしい。no_compile=Noneという初期化を追加。
・変換後実行すると、string.xmlが見えないというエラー
　→モジュール外ファイルを含むよう定義(data_files)に追加（data、images）
・文字コードの変換ができないというエラー
　→-p encodings にて、encodingsパッケージを強制追加。
・再度文字コードの変換ができないというエラー
　→-p encodingsに加えて、japaneseも強制追加。
・デフォルトキャラクターセットを利用しているところでASCIIと取得している？
　→py2exeではsite.pyは流れないそうな。プログラムの開始部分でsys.setdefaultencodingを実施。
・動的生成されるモジュールハンドラでエラー。
　→-iにて、モジュールを追記。明示的にimportされてないから、取り込まれないのね・・・

で、一通り動作するようになったっぽいので、あとで、説明文の変更とあわせて乗せときます・・・

現在、手をだしつつちまちまと作成しているものを一覧に。
・人狼CGI改造(Perl)
・FRPGS推奨みんちゃ用ダイス「fubmle」改造(Java)
・CMN用Extension(C++)
・おーにちゃっと互換のサーバ内蔵クライアント(REALBasic)
・fumble用Extension(def/WitchQuest)
・OpenRPG日本語化(Python+wxPython)
・みんちゃ用碁盤(REALBasic/番手制御なし)
・みんちゃ用だいす(REALBasic/まだぜんぜん)
・NA2のみんちゃ対応(C/気持ちだけ)
・みんちゃ用マップシート(REALBasic/まずはホワイトボード？)
・過多機能TRPG用WEBCHAT(Perl)
・WEB版floortile(PHP/作ったの忘れてた・・・)
・WEB版WitchQuestTRPG用きゃらめ(PHP)

現時点で、本人の興味がある順。ただし、「openRPGつかえば、ほかのものなんていらないなぁ」という考えは変らず。Unicode(UTF8)ベースへの変更希望とか、だれか出さないかね。

　みんなのチャット♪用の碁盤ソフトを作成。いまのところ、特定のルールとかのサポートは無く、たんに碁盤が表示できて、石を置いたりどかしたりできるだけ。いちおー、REALBasicで作成したみんちゃ用初めてのソフトということで。
# １つできれば、他のも簡単に作れる・・・といいなぁ・・・

関連サイト
・みんチャワールド
・うぇいくのプログラム置き場（これは自サイト）

　WEBチャット以外が利用されないのは、やはり、さーばを立てる困難さにあるのではないかということで、なんとか、NATの裏側でも（大多数の人が）簡単に立てられるチャットサーバをつくれないかなぁ　というところ。
# MicrosoftのUPnPのドキュメントを見ると判りますが、NATの内側にサーバを立てるために静的なマッピングを定義するのは「専門的でかつ複雑な作業」とかかれています。「インターネットでIPアドレスがどう使われているのか、NATはどんなことをしているのか」がわかってないと、設定は難しい。

そこで、NAT越えの方法をちまちま調べてみました。
１．UPnPを利用する
　これはMicrosoftがMSN Messangerに組み込んでいるのでそこそこ有名？ただし、NAT装置自体に機能が実装されている必要がある。
２．STUNを利用する
　NATの種類がsymmetric NATでは無い場合は、これが有力。
３．symmetric NATでもSTUNを利用する
　えらく複雑。簡単に言うと、STUNサーバに何度か連続でマッピングを確認し、次回以降にマッピングされるポートを予測したうえで、実際に接続したいサーバへ接続を試みる。

どの方法でもほぼ共通してる欠点は（UPnPは該当しないものも多い）・・・
１．UDP通信。TCPではない。
２．接続前に、お互いに相手のIPとPORTを知っている必要がある。
３．「２．」と絡んで、サーバ側もアクションを起こす必要がある。
４．KeepAliveには、一定時間ごとに通信が必要。
５．別途、グローバルなアドレス上にSTUNサーバが（できれば複数台）必要。
（６．UPnPは、NAT装置が対応してないとアウト。対応してない機種も少なくはないっぽい）

結局のところ、外部に「STUNサーバ」と「ネゴシエーション用CGI」がどーしても必要になるっぽい。口だけ開けっ放しで待っていれば、クライアントが勝手に接続できるのにくらべると、各クライアントごとに招き入れないといけないというのは、結構大変。やっぱり、P2Pならともかく、サーバには向いてないのかも。

追記。
　一般家庭であれば、UPnPへの対応で結構な範囲がカバーできそうです・・・・が、プロトコル仕様がわからない・・・ターゲットをWindowsXPにしぼれば、APIから利用できるんですけどね・・・（あと、Linuxもオープンソースなライブラリがあります）

　ＷＥＢチャットの調査をしているうちに、ＷＥＢチャットで利用するさいころ機能の高機能化に凝ってみたり。欠点は、凝れば凝るほど重くなることでしょうか・・・・
　今のところ、チャットに内蔵しない形で設置してあります。サンプルは、FRPGS プレイングフォーラムの管理サイトからどうぞ。

　おーにさーばや、みんちゃのよーに、自ＰＣにサーバを立てる前提で、ユーザがとっつきやすい環境という点では、高機能化のＷＥＢチャットもよいのかもしれません。

　REALBasic第２弾。おーにチャットサーバ用クライアント。Windows,MacOS8/9(PowerPC),Mac OSX,Linux/x86(GTK+ 2.x)の環境で利用可能・・・・の予定。

　なお、ログは勝手に取られます。ファイル名はタイトルにつけた名前＋日付.log。

　ファイルは、ここ。

「なんとなく」のほうに記載したとおり、RealBasicを発注したわけですが・・・いまいち、どんなものを作ろうかというところが決まってなかったり。いちおー、ターゲットとなるチャット環境はみんちゃを想定。
※旧Macを除けば、別プロジェクトでダイス作ってるんですけどね。

１．旧ダイスはツール本体というか定義ファイルが多機能すぎ。
　→公に配布できないほど高機能なのは、ちょっとあれです。ツール本体のせいではないんですが・・・
２．みんちゃで考えると、SEND/PAGEに相当する機能が外部アプリから使えない。
　→全員が同じ外部アプリを使用する前提がないと、手札のような非公開情報を扱えません。
　→なお、あ外部アプリから使えても、個別メッセージごとに別窓が開いちゃうので使い勝手が悪いかも。
３．「２．」と絡んで。全員で同じ外部アプリを使う前提でいくのかどうか。
３−１．旧オンラインダイスと同様に１人で起動して参加者が全員利用できる。
　→インターフェースは送受信発言に限定されます。
３−２．全員で同じ外部アプリを必ず起動して利用する。
　→ＧＵＩとかも使えるようになります。ただし、起動できない人がひとりでもいるとアウト。
　　マップとか使うならこれが必須。
３−３．１人以上で任意の人数で起動して利用する。
　→「３−１」「３−２」の中間。実装する機能は送受信で利用できる機能に限定する。ＧＵＩは在れば便利程度に。持っていない人の文のデータはいずれか１つで一括管理。実装は１番大変そう。
３−２−派生．データ処理は１つで行いユーザインターフェースのみを実装したアプリを全員で利用する。全員で使わないといけないのは一緒だけど、「３−２」よりも作るのが簡単・・・・かもしれない。

なにかこう、「これがなくては意味がないっ」とゆー機能があったら、コメントもしくはTackBackください。

　べつのとこの掲示板で出た話ですが。
　既存のオンラインダイスでは、ＤＤ３Ｅの攻撃判定を扱うのが面倒らしい・・・そーいわれてＮＷＮ(Neverwinter Night/PC版DD3E)で遊んでいるときを考えてみると、
・基本攻撃力が＋６以上だと攻撃回数が増える。たとえば、+12/+7/+2と、３回、違う攻撃力での判定が必要。
・さらに、逆手に武器を持つと、基本攻撃力から導かれる攻撃回数＋１される、これの攻撃力は持っている武器のサイズとFeatにより変化する（６パターンぐらい。ハーフリングだとまた別（笑））
・さらにさらに、「武器の妙技」を持つと、特定の種類の近接武器の命中判定が、筋力修正の変わりに敏捷修正になる。右手と左手で適用が違うと愚かかもしれない・・・
・さらにさらにさらに、攻撃オプションでも変化。ゲーム内でよく使うのは「強打」「速射」。これはそのつど修正でもよいか・・・ただし、ターンの途中でオプションはかわんない。
いちお、最初の１つめの項目以外、持つ武器が変化しない限り変わらないわけですが・・・うーむ、回数と共に修正が変わるのは、実装したことないな・・・・

　「１ターンに使われる攻撃力を順番に登録して、ターンごとにその順番で自動的に使用する。ターンが変わったら使いきって無くても最初にリセット」あたりが現実的か・・・

関連記事
・FRPG RPGプレイングフォーラムの、雑談bbs内発言

　ＴＲＰＧに関するツール系もこっちであつかうことに。これからは、この手の情報が増えていくと思います。

　日本でオンラインでＴＲＰＧを行おうとすると、大半がＷＥＢチャットであり、次点がＩＲＣではないかと思います（逆・・・ということは無いと思ってます）その他、誰かがサーバを立ててのチャットツール（みんなのチャット♪とかMagicalChatとか）を使っている人も少数いるのかな　と。

　そのなかで、チャット自体ではなく、ＴＲＰＧを行うための支援機能がどうなっているかを見てみると、まったくないか、大体がさいころがふれるか、それに加えて遊んでいるシステムの判定が行える（ふり足しとか１度に大量に振る必要があるシステムではないと不便）ぐらいかと思います。

　それでみな満足しているようなのでわざわざだれも使ってないわけですが、海外でそこそこ使われている（のかは不明）な、OpenRPGという、ＴＲＰＧ用チャットツールがあります。これは、みんなのチャットやMagicalChatと同じようにだれかがサーバを立ててそこ繋げて使うタイプで、ＴＲＰＧをオンラインで行う際に必要な機能がほとんど入っています。だいたい以下の感じ。
・チャットできます。
・HexSheet/SquareSheetが利用できます。
・情報をツリー構造に入れて管理できます（ＰＣのデータとかモンスターのデータとかシナリオプロットとか）。
ただし、海外ではあまり見かけないからなのか、「カードを管理する機能」はありません。トランプやらオリジナルのカード（Torgとか深淵のように）は、現状では対応していません。

　そこで、「日本語で利用できるものでは、ここまで便利なものが無いのもさびしい」ということで、ちまちまと日本語化対応と日本語化をはじめました。「興味はあったけど、言語が怪しかったのでほっといた」とか「じつはＭＡＰを使いたかった」とかあれば、コメント（いや、トラックバックも出よいですが）をもらえると、作業が進んだりするかもしれません。

関連リンク
・OpenRPG: Online Virtual Tabletop (英語)
・

September 02, 2004 in オンラインツール | Permalink | Comments (0) | TrackBack (1)

OpenRPGのインストールの簡略化

　反応があったのに気をよくして、OpenRPGを、Py2EXEというツールを使用してWindows実行形式への変換にチャレンジ。
　単独EXEにはならないのと、サイズが巨大になるというデメリットはあるものの、PythonやらwxPythonをあらかじめインストールしなくとも動作させられるというのが強み。というわけで試してみると・・・

・変換中にエラーとなる(attrに無いとか言うエラー）
　→Py2EXEだかDistUtlsの変数の初期化漏れの既バグらしい。no_compile=Noneという初期化を追加。
・変換後実行すると、string.xmlが見えないというエラー
　→モジュール外ファイルを含むよう定義(data_files)に追加（data、images）
・文字コードの変換ができないというエラー
　→-p encodings にて、encodingsパッケージを強制追加。
・再度文字コードの変換ができないというエラー
　→-p encodingsに加えて、japaneseも強制追加。
・デフォルトキャラクターセットを利用しているところでASCIIと取得している？
　→py2exeではsite.pyは流れないそうな。プログラムの開始部分でsys.setdefaultencodingを実施。
・動的生成されるモジュールハンドラでエラー。
　→-iにて、モジュールを追記。明示的にimportされてないから、取り込まれないのね・・・

で、一通り動作するようになったっぽいので、あとで、説明文の変更とあわせて乗せときます・・・

さくせいぶつあれこれ

現在、手をだしつつちまちまと作成しているものを一覧に。
・人狼CGI改造(Perl)
・FRPGS推奨みんちゃ用ダイス「fubmle」改造(Java)
・CMN用Extension(C++)
・おーにちゃっと互換のサーバ内蔵クライアント(REALBasic)
・fumble用Extension(def/WitchQuest)
・OpenRPG日本語化(Python+wxPython)
・みんちゃ用碁盤(REALBasic/番手制御なし)
・みんちゃ用だいす(REALBasic/まだぜんぜん)
・NA2のみんちゃ対応(C/気持ちだけ)
・みんちゃ用マップシート(REALBasic/まずはホワイトボード？)
・過多機能TRPG用WEBCHAT(Perl)
・WEB版floortile(PHP/作ったの忘れてた・・・)
・WEB版WitchQuestTRPG用きゃらめ(PHP)

現時点で、本人の興味がある順。ただし、「openRPGつかえば、ほかのものなんていらないなぁ」という考えは変らず。Unicode(UTF8)ベースへの変更希望とか、だれか出さないかね。

みんちゃ用碁盤

　みんなのチャット♪用の碁盤ソフトを作成。いまのところ、特定のルールとかのサポートは無く、たんに碁盤が表示できて、石を置いたりどかしたりできるだけ。いちおー、REALBasicで作成したみんちゃ用初めてのソフトということで。
# １つできれば、他のも簡単に作れる・・・といいなぁ・・・

関連サイト
・みんチャワールド
・うぇいくのプログラム置き場（これは自サイト）

NATを超えるには？

　WEBチャット以外が利用されないのは、やはり、さーばを立てる困難さにあるのではないかということで、なんとか、NATの裏側でも（大多数の人が）簡単に立てられるチャットサーバをつくれないかなぁ　というところ。
# MicrosoftのUPnPのドキュメントを見ると判りますが、NATの内側にサーバを立てるために静的なマッピングを定義するのは「専門的でかつ複雑な作業」とかかれています。「インターネットでIPアドレスがどう使われているのか、NATはどんなことをしているのか」がわかってないと、設定は難しい。

そこで、NAT越えの方法をちまちま調べてみました。
１．UPnPを利用する
　これはMicrosoftがMSN Messangerに組み込んでいるのでそこそこ有名？ただし、NAT装置自体に機能が実装されている必要がある。
２．STUNを利用する
　NATの種類がsymmetric NATでは無い場合は、これが有力。
３．symmetric NATでもSTUNを利用する
　えらく複雑。簡単に言うと、STUNサーバに何度か連続でマッピングを確認し、次回以降にマッピングされるポートを予測したうえで、実際に接続したいサーバへ接続を試みる。

どの方法でもほぼ共通してる欠点は（UPnPは該当しないものも多い）・・・
１．UDP通信。TCPではない。
２．接続前に、お互いに相手のIPとPORTを知っている必要がある。
３．「２．」と絡んで、サーバ側もアクションを起こす必要がある。
４．KeepAliveには、一定時間ごとに通信が必要。
５．別途、グローバルなアドレス上にSTUNサーバが（できれば複数台）必要。
（６．UPnPは、NAT装置が対応してないとアウト。対応してない機種も少なくはないっぽい）

結局のところ、外部に「STUNサーバ」と「ネゴシエーション用CGI」がどーしても必要になるっぽい。口だけ開けっ放しで待っていれば、クライアントが勝手に接続できるのにくらべると、各クライアントごとに招き入れないといけないというのは、結構大変。やっぱり、P2Pならともかく、サーバには向いてないのかも。

追記。
　一般家庭であれば、UPnPへの対応で結構な範囲がカバーできそうです・・・・が、プロトコル仕様がわからない・・・ターゲットをWindowsXPにしぼれば、APIから利用できるんですけどね・・・（あと、Linuxもオープンソースなライブラリがあります）

こんどはＷＥＢチャット関連

　ＷＥＢチャットの調査をしているうちに、ＷＥＢチャットで利用するさいころ機能の高機能化に凝ってみたり。欠点は、凝れば凝るほど重くなることでしょうか・・・・
　今のところ、チャットに内蔵しない形で設置してあります。サンプルは、FRPGS プレイングフォーラムの管理サイトからどうぞ。

　おーにさーばや、みんちゃのよーに、自ＰＣにサーバを立てる前提で、ユーザがとっつきやすい環境という点では、高機能化のＷＥＢチャットもよいのかもしれません。

オンラインダイスじゃないものも作成

　REALBasic第２弾。おーにチャットサーバ用クライアント。Windows,MacOS8/9(PowerPC),Mac OSX,Linux/x86(GTK+ 2.x)の環境で利用可能・・・・の予定。

　なお、ログは勝手に取られます。ファイル名はタイトルにつけた名前＋日付.log。

　ファイルは、ここ。

オンラインダイスの作成・・？

「なんとなく」のほうに記載したとおり、RealBasicを発注したわけですが・・・いまいち、どんなものを作ろうかというところが決まってなかったり。いちおー、ターゲットとなるチャット環境はみんちゃを想定。
※旧Macを除けば、別プロジェクトでダイス作ってるんですけどね。

１．旧ダイスはツール本体というか定義ファイルが多機能すぎ。
　→公に配布できないほど高機能なのは、ちょっとあれです。ツール本体のせいではないんですが・・・
２．みんちゃで考えると、SEND/PAGEに相当する機能が外部アプリから使えない。
　→全員が同じ外部アプリを使用する前提がないと、手札のような非公開情報を扱えません。
　→なお、あ外部アプリから使えても、個別メッセージごとに別窓が開いちゃうので使い勝手が悪いかも。
３．「２．」と絡んで。全員で同じ外部アプリを使う前提でいくのかどうか。
３−１．旧オンラインダイスと同様に１人で起動して参加者が全員利用できる。
　→インターフェースは送受信発言に限定されます。
３−２．全員で同じ外部アプリを必ず起動して利用する。
　→ＧＵＩとかも使えるようになります。ただし、起動できない人がひとりでもいるとアウト。
　　マップとか使うならこれが必須。
３−３．１人以上で任意の人数で起動して利用する。
　→「３−１」「３−２」の中間。実装する機能は送受信で利用できる機能に限定する。ＧＵＩは在れば便利程度に。持っていない人の文のデータはいずれか１つで一括管理。実装は１番大変そう。
３−２−派生．データ処理は１つで行いユーザインターフェースのみを実装したアプリを全員で利用する。全員で使わないといけないのは一緒だけど、「３−２」よりも作るのが簡単・・・・かもしれない。

なにかこう、「これがなくては意味がないっ」とゆー機能があったら、コメントもしくはTackBackください。

オンラインダイスでのＤＤ３Ｅ

　べつのとこの掲示板で出た話ですが。
　既存のオンラインダイスでは、ＤＤ３Ｅの攻撃判定を扱うのが面倒らしい・・・そーいわれてＮＷＮ(Neverwinter Night/PC版DD3E)で遊んでいるときを考えてみると、
・基本攻撃力が＋６以上だと攻撃回数が増える。たとえば、+12/+7/+2と、３回、違う攻撃力での判定が必要。
・さらに、逆手に武器を持つと、基本攻撃力から導かれる攻撃回数＋１される、これの攻撃力は持っている武器のサイズとFeatにより変化する（６パターンぐらい。ハーフリングだとまた別（笑））
・さらにさらに、「武器の妙技」を持つと、特定の種類の近接武器の命中判定が、筋力修正の変わりに敏捷修正になる。右手と左手で適用が違うと愚かかもしれない・・・
・さらにさらにさらに、攻撃オプションでも変化。ゲーム内でよく使うのは「強打」「速射」。これはそのつど修正でもよいか・・・ただし、ターンの途中でオプションはかわんない。
いちお、最初の１つめの項目以外、持つ武器が変化しない限り変わらないわけですが・・・うーむ、回数と共に修正が変わるのは、実装したことないな・・・・

　「１ターンに使われる攻撃力を順番に登録して、ターンごとにその順番で自動的に使用する。ターンが変わったら使いきって無くても最初にリセット」あたりが現実的か・・・

関連記事
・FRPG RPGプレイングフォーラムの、雑談bbs内発言

OpenRPGの日本語化

　ＴＲＰＧに関するツール系もこっちであつかうことに。これからは、この手の情報が増えていくと思います。

　日本でオンラインでＴＲＰＧを行おうとすると、大半がＷＥＢチャットであり、次点がＩＲＣではないかと思います（逆・・・ということは無いと思ってます）その他、誰かがサーバを立ててのチャットツール（みんなのチャット♪とかMagicalChatとか）を使っている人も少数いるのかな　と。

　そのなかで、チャット自体ではなく、ＴＲＰＧを行うための支援機能がどうなっているかを見てみると、まったくないか、大体がさいころがふれるか、それに加えて遊んでいるシステムの判定が行える（ふり足しとか１度に大量に振る必要があるシステムではないと不便）ぐらいかと思います。

　それでみな満足しているようなのでわざわざだれも使ってないわけですが、海外でそこそこ使われている（のかは不明）な、OpenRPGという、ＴＲＰＧ用チャットツールがあります。これは、みんなのチャットやMagicalChatと同じようにだれかがサーバを立ててそこ繋げて使うタイプで、ＴＲＰＧをオンラインで行う際に必要な機能がほとんど入っています。だいたい以下の感じ。
・チャットできます。
・HexSheet/SquareSheetが利用できます。
・情報をツリー構造に入れて管理できます（ＰＣのデータとかモンスターのデータとかシナリオプロットとか）。
ただし、海外ではあまり見かけないからなのか、「カードを管理する機能」はありません。トランプやらオリジナルのカード（Torgとか深淵のように）は、現状では対応していません。

　そこで、「日本語で利用できるものでは、ここまで便利なものが無いのもさびしい」ということで、ちまちまと日本語化対応と日本語化をはじめました。「興味はあったけど、言語が怪しかったのでほっといた」とか「じつはＭＡＰを使いたかった」とかあれば、コメント（いや、トラックバックも出よいですが）をもらえると、作業が進んだりするかもしれません。

関連リンク
・OpenRPG: Online Virtual Tabletop (英語)
・

September 02, 2004 in オンラインツール | Permalink | Comments (0) | TrackBack (1)