- Polygonic
  Layer
  Project -

  → 不定期連載:「転職&引越」(4/23)

  → RokMill 1.1c (説明)

  → 一行掲示板(引き継ぎ)

  → 過去ログ (spaceports)

  うーん。とりあえず、ここに定住しちゃおうかなあ・・・。






2002/03/14

・・・半年ぶりの更新です(爆

最近はもう、ラグナロク一辺倒なのです。他のことをやってる時間などありません。 仕事すらもおろそかになって、自分で自分が怖くなる今日この頃。

そんなおり、アスキーからメールがあり、テックなんとかにRokMillを載せますと 言うじゃありませんか。RokMillのサポートページは私の所には既に無く、結果的に ここのページのURLが載ってしまうわけですが・・・こんな状況です。いやはや。

RokMillは、六角大王で作ったデータを表示するためのjavaアプレットです。 自分で作った六角大王作品を手軽にページに貼り付ける事ができるので、わりと 面白いかなあ、と。最近のバージョンではHumanMDLで作ったp3dデータを読み込んで 動作させることも出来るようになっております。

・・・驚くべき事に、2年近く更新しておりません(爆

現在このページでは、六角大王+HumanMDLで作られたモデルデータを使った ネット対戦格ゲーを作っております・・・が、こちらも1年ぐらい放置。 最近の最大の関心事はラグナロクなんだよッ!しょうがないだろッ!!(逆ギレ

ネトゲーにハマったのはdiablo以来だなー。diabloもそうだけど、どうにもネトゲーは キャラが可愛くない!最近は3Dのが増えていたりしますが、これまた可愛くない!! そんな中で出会ったラグナロクキャラのなんと可愛いことか。ドット絵の品質は 一級品なので、どこかで見てみることをオススメします。特に、動いてるところを。 全体的に、男キャラは女キャラと比べて力が入っていないのですが(爆

ドット絵が廃れたのは、純粋に開発に職人技と手間暇が必要だからです。別に ポリゴンキャラの方が可愛いからではありません。この状況を全国のポリゴナーは いかがお考えか。・・・と、中途半端に問題提起っぽいことをしておきつつ また半年ぐらい放置するわけですが(マテ


2001/08/23

とりあえず、再開しようと思い立つ。で、まずは自分が何をやっていたか思い出すために 自分の書いたソースを読み返す・・・ま、まぬけや・・・。

そういえばこんなことやってたなあー。試験用のサーバーとか作ったけど、いまいち プロトコルとか気に入らないよなー。特に、GETしまくってデータを取り寄せるところが(^^; いや、この方が作るの楽かなと思ったんですが、よく考えたらどうせ、受信と送信って別のところで 処理するだろうし。あんまり意味無かったなあ。もう一度いろいろ考え直そう・・・。

と、ここまでは良かったんですが。届いちゃったんです、友人から「PARTY'S BREAKER」が。 えーと、これは同人の格闘ゲームで、一言で言って「面白い」です。・・・はい、そうです、 最近、仕事と寝る以外の時間はこれしかやってないです!うわー。プログラムなんか書いてる 暇があったら詠美ちゃん様のコンボ練習してるっちゅうねん!!

てことで、夏休みはあけましたが、PB休みに入ります(爆 いや、これもきっと、 Polygonic Layer に生かされ・・・るかどうかはさておき、私の精神状態を活性化するのに 役立つような気がしないでもないような・・・むにゃむにゃ。人生、楽しいこと、悲しいこと、 いろいろあったほうが創作に厚みが出るというものです。楽しめるときは思いっきり楽しもう、 そうしよう。ていうか、詠美ちゃん様サイコー!うはー!(壊


2001/06/02

 → VIRTUAL ANGEL FAN

リアルタイム3D、ネットワーク、java と気になる要素がてんこ盛り・・・ というか、とりあえず、この馬鹿っぽさは体験に値するかと。


2001/05/30

 → Polygonic Layer Server(テスト版)
 → Polygonic Layer プロトコル仕様(テスト版)

サーバーの方は JDK1.2 以降が入っている環境で

 javac plsv.java

とすればコンパイル出来ます。JDK1.2 または JRE1.2 以降が入っている環境で

 java plsv

とすれば動くはずです。port9000 を乗っ取って、サーバーになります。これでテストして クライアントを作ってもらえたりすると儲けモノというかなんというか。当たり判定とか ないですが、まあ、テスト版なので(適当な・・・)。通信の実験をするだけなら、 これで充分でしょう。プロトコルも若干かわってたりします。

チャットのサーバーを作ったときは、極力サーバーの側から勝手にデータを送るように していたのですが、今回はとにかく、クライアントから要求を出さない限り全くデータを 送ってきません。こっちのほうが「いつ何が送られてくるかわからない」よりも 作りやすいかなあ?と思ってのことなのですが、まあ、テスト版なので、今後 どうなるかはわかりません(^^;

あと、今回のこのサーバーですがー。まだ、クライアントを作っていないので、 正常に動いているのかどうか、私にも分かりかねます(爆 ・・・ええんかこんなんで(^^;


2001/05/27

最近割と、p3d周辺の動きが活発に成っている様子。よきかな。

で、こちらはどうかと言えば、あいかわらず、クライアントをどうしたものかなぁ〜と 思いながらコメットさんを見て萌え転がってるわけです。コメットさん、目の中の描き込みが 怖い時があるのが問題あるなあ・・・って、いや、全然関係ないですが。あと、 今更ながらにブレイブサーガやったり。これも関係ないですが。

こんな調子では出来るものも出来ないので、とりあえずプロトコルだけでも放置しておく テスト。いや、ひょっとしたら、誰かがこれをみてクライアントとか作ってくれるかも しれないじゃん(淡い期待)?そしたら、私はもう、安心してコメットげふんげふん、 サーバーの製作に走れるわけでー。

 → Polygonic Layer プロトコル仕様(テスト版)

本当ならテスト版のサーバープログラムも公開したかったんですけど、プロトコルを 大幅に変えちゃったので、今回は間に合いませんでした。作っても、クライアントが無いから TeraTermとかでテストしてる状態だしさー。

まあ、こんなものだけ置いていても、反応ないでしょうね〜。あっはっは(笑うな)。


2001/05/20

覚え書き更新。

当面の課題:
現在、変形後の間接位置をそのままサーバーからクライアントに送信することで クライアント側に表示していますが、サーバーから間接のクオータニオンとモデル位置を 受け取って、そこからサーバー内の状況をクライアント上に再現出来るようにしないと いけない。当然、それに伴ってプロトコルも固めないといけない。

攻撃判定をはじめとする物理法則を実装しないといけない。あと、攻撃とかが出てくると、 いろんな状態になりうる(ダウンとか)から、状態のやりとりをするプロトコルも 追加しないといけない。

それぐらい出来たら、とっとと公開したいなあ。

攻撃判定とか:
技の一つ一つに威力とか硬直時間をパラメータ設定するような形にはしたくありません。 「どうモーションを組むか」で威力や硬直時間が決まる、また、その決まり方が 傍目に見て妥当であり、かつ、美しくあるようにしたい。そのためにはうまい具合に 格ゲーの技をモデル化して物理法則として実装してやらないと・・・。出来るのかなあ。 ちゃんとしてやろうと思ったら、その時の拳の速度だけじゃなくて、過去の速度とか 体の他の部分の速度とか加味してやる事になるのかな・・・とか漠然と考えていたり。 この辺は、やってみないとわからないなあ。その為にも、上の課題をとっととなんとか しないといけないんですがー。

クライアント:
delphiで作り始めたばっかりに(TCPのコンポーネントが便利なんだもんー)非常に 難航しているわけですが(^^; プロトコルの方は馬鹿みたいにシンプルなプロトコルに なりますし、HumanMDLの方はすでにオープンソースになっていますから、TCPで通信する プログラムを作れる人なら簡単に作れるんじゃないかなあと思ってます。ていうか、 作って欲しいです、誰かに(^^; サーバー、クライアントがはっきり別れているので、 自動操縦プログラムとか色々作れると思うんですよー、とか言ってみたり。

モデルデータとP3D:
P3Dの方は、直にサーバーとクライアントでやりとりする事にしよう・・・と 思ってます、最近は。他人のP3Dに関しては、動きデータ以外の部分を最初に 受け取って、後はその時々のポーズを受け取る事になります。直にモーションデータ 自体を受け取る事はありません。ゲームとして、その方が面白かろうということで (技を出される前から手持ちの技がばれてはツマランかな、と言う事で)。 公開したければ公開すれば良いだけのことですし。

モデルデータの方はサーバー側には必要ないので、どこかに置いてもらってそこの URLだけをやりとりすればいいかなーと思っています。クライアントがそれを見て 自動でダウンロードするなりすれば良いという事で。

プロトコル:
上にいろいろ書いたような事を決めていけば、勝手に決まってくるはずです。 やりとりはテキストベースで行います。バイナリでやりとりした方がデータ量は 少なくて済みますが、テキストの方が分かりやすいから。とにかく他の人にも 作ってもらいたいのでー。あと、最初から完璧なものは作れないと思うので、 適当なタイミングでがらっと変える事になるだろうと思います。ここが決まらないと 何も始まらないので、不完全なものでも動かすのに支障無くなれば公開した方が 良いと思いますのでー。

ちなみに、以前作ったチャットのプロトコルはこんな感じ。 これだけ簡単なら文句は無いでしょう(^^;


2001/04/15

ネットワーク:
すっかり忘れている人も居るかもしれませんが、当プロジェクトの目的は「自分で作った モデルで戦えるネットワーク対戦型ポリゴン格ゲー」なのです。そうなんです。 現在、以前作ったRokMillと、以前作ったチャットサーバー、チャットクライアントを ごちゃまぜにして、ソレっぽいものを生成中・・・。うーん、こんなことならちゃんと Class化とかしておくんだった・・・。

今まで、C のようにしか使ってなかったので、実のところクラスとか良くわかって なかったんです(java使っといてそれかよ俺!)。ちまちまとesep3d やら quaternion やら、謎なクラスを作っておりますがー。うまくクラス化が出来てくると、一気に 読みやすくなったりするんですが、下手なクラス化をしてしまうと、スパゲッティ以上に おぞましい事になりますなー。怖い怖い。

そんなこんなで、一応、クライアントからの指示でサーバー上に動きデータを読み込ませたり 動きを指定したりができるようになりまちた。あと少しで(ワイヤーフレームですが) 実用レベルになる、かなあ・・・。現時点では10人まで同時につなげるように設計してますが、 3D の計算だけなら100人とかでも特に問題はありません。多分。接続した全員が一度に データを取りにくる・・・となったときに、どの程度の人数まで耐えられるか、については 動かしてみないとわからないですね。

なんか、他の部分の方が気になってしまいますが(litestep のスクリーンショットを 流用してるので(^^;)、サーバーを立ち上げて、2人が接続して、2体分の P3Dデータを 読み込んで動かしているところです。クライアントは急造品なのでアレですが、 サーバーの側は「ネットワーク周りに関しては」ほぼ完成品と言っていいところまで 出来ています。もっとも、当たり判定とかのゲーム周りはサッパリですけど。

「87% まだいけます」などと言っておりますがー。うーん。余裕があと13%というのは、 ちょっと不安が残りますな・・・。まあ、今回の場合はクライアントを同じマシンの上で 動かしていますし、うちのマシンはよそ様の環境と比べると随分見劣りする K6-2 366MHz だったりとかするので、クライアントが別マシン、CPUがもうちょい速い、とかならば 当たり判定をつけてもそれなりにいけるんじゃないかなーと思ったりしております。 まだわからないですが。

今回のはちょっと、β版どころかα版って感じなのでスクリーンショットのみなのですが、 わりと早くに試せるようになるかもしれません。うぅ、7月までは手をつけないつもり だったのになあ・・・。なんちゅーか、今、自分の目から見て、非常に魅力的なんです このプロジェクト。自分内の旬を逃すとやる気なくなっちゃうので、やっぱ今やるしかないよなー。

今後やらないといけないのがサーバー側での当たり判定。当たり判定がついたら、それだけで かなり遊べると思うんですけども。どつき漫才とか。攻撃判定は前に考えた通りに、一定の 速度を超えれば発生ということで作るとして・・・あーもー。考えたら考えただけ作りたくなるー。 今はまずいってー。まあいいかー(どっちやねん)。

あと、クライアント側の六角データ読込・表示部分。これは、野田さんのDLLを使えば すぐなんだと思うのですが・・・DLLって、どうやって呼び出すのか、わかりません(爆)。 使ったことないんじゃよー。でも大丈夫!ついに HumanMDL やら DLL やらがオープンソース化を 果たしたんです、そうなんです!凄いぜ!気になる人はとりあえず行っとけ!

 → 野田さんの「野田篤司のホームページ」

これでソースを読めば私にも簡単に DLL の呼び出しが・・・って!ウチ、delphiじゃん!(爆

今日のBGM:コッペリアの柩

今後、コッペリアの柩をP.L.P.のテーマソングとします(嘘

------------------------------------------------

2001/03/18 その2

緊急更新:
思い立ったが吉日。作りたいものは作りたい時に作ってしまわないと気が済まない
タチなのです。あと、今回はHumanMDLer専用の内容っぽいです(^^;

 → sample ※javaが有効でないと動きません

 → dir ※覗いてくれて可

今回のは随分ソレっぽく(ソレってドレさー?!)なっているかと思います。あと、
自分内で固まりつつある「今後の方針」みたいなものが色濃く反映されています。
・・・っていうほど、大層なもんでもないですが。

正直、P3Dデータをそのまま使うのは無理があると思っていました。で、まあ、変換して
使えるようにしようかな・・・とか、色々考えていたわけですが、今回プログラムを
作っていて、「P3Dのままでもいけるじゃん!」と結論づけられました。自分内で。
そのかわり、P3Dデータを作るときに、各人に簡単なルールを守ってモーションを組んで
もらわないといけません。まあ、「P3Dデータがそのまま使える」という事がもたらす
利点に比べれば些細な事でしょう。

なお、このルールは必ずしも守る必要はありません。ただ、このルールを守っていない
モーションの場合、突拍子もない動作をして驚くかもしれない、といった程度の事です。

動作上の特徴:
pltest は通常の P3Dデータの再生とは異なる再生の仕方をします。
・モーションは1回しか再生されない
 全てのモーションは最後のポーズで静止します。
・モーション切り換え時に補完がなされる
 前のモーションの最後のポーズから次のモーションの最初のポーズまでが補完されます。
 なお、動作途中で次のモーションに移る場合も同様です。
・地面に水平な方向への移動
 接地している点を支点にして体全体の位置が動きます。
・地面に垂直な方向への移動
 重力がかかっています(落ちます)。地面をちゃんと蹴ってやれば、飛び上がれます。
・旋回
 モーション終了時に向いていた方向が後のモーションに引き継がれます。
 なお、例えばモーション2が右方向に90度回転するモーションであった場合、
 45度回った時点で別のモーションに切り換えれば45度だけ回る事も出来ます。

ほとんどのルールは、動作上の特徴に起因するものです。

ルール:
・1番目のモーションの1番目のポーズが、全ての動作の起点ポーズとなる
 また、1番目のモーションは何もしていない時の動作(格闘ゲームだと、肩を上下に
 揺らしていたりする奴)になります。
・将来的には変更可能になりますが、現時点では
  2番目のモーション:前に移動
  3番目のモーション:右を向く
  4番目のモーション:左を向く
 に固定されています。といっても、画面上「^」「<」「>」と表示されるかどうか
 だけの話なので、わりとどうでもいいんですが(^^;
・全ての(1番目以外の)モーションについて、
  1番目のポーズ=起点ポーズの次のポーズ
  最後のポーズ=起点ポーズ
 である事が望ましいです。これもまあ、絶対ってほどでも。
・位置データは全て無視されます
 なんらかの動作で全て実現可能なはずなので、頑張ってモーションを組んで下さい。

動作上の特徴を理解した上でルールを破るのはアリです。

現時点では ayatai.p3d がいいサンプルになるかと思います・・・と言いたいところ
だったんですが、時間がなくて「とりあえず動く」ぐらいのデータです(^^;
#なんかに似てると思ったら、そうか、ホンダのロボットだ(爆

以上。

------------------------------------------------

2001/03/18

思いついた事:
突然思いついてしまったので、忘れないように覚え書きなど。

以前書いたかと思いますが、

「サーバーに電子妖精のデータ(ROK(形状)&P3D(動き))を事前に登録しておく」
「クライアントは ROK(形状)データをサーバーから事前にダウンロードする」

という感じの運用を想定していました。
この場合、サーバーにはそのフィールドに出現しうる全ての電子妖精の六角データが
置いていなければならないし、クライアントからの要求が有ればいつでもそれらを
ダウンロードさせてやらないといけません。

すげー無駄。しかも、なんか中央集権的。

そもそも、P.L.鯖は六角データを必要としません。必要なのはクライアントの側だけ。
クライアントが六角データをダウンロードする最も有効な方法は?

URL。

早い話が、サーバーはURLだけ管理しておけばいい。これなら、1000体の電子妖精を
登録してもまるで問題ないでしょう。六角データは世界のどこにあってもかまわない。

なんでこんな簡単な事に気づかなかったんだ・・・。鬱だ子嚢。

選手登録〜対戦まで:
あなたが自分の妖精をサーバー上で動かせるように登録する手順は、以下のようになります。

・六角データとP3DデータをどこかのWebサーバーにアップする。
・2つのデータのURLをP.L.サーバーに登録する。

選手登録を済ませたあなたは、早速、適当なフィールドで自分の電子妖精を動かしてみる
事にします。仮にフィールドAとでも言っておきましょう。

・P.L.サーバーは、フィールドA上にあなたの電子妖精を構築します。
 具体的には、登録されているURLを見てP3Dデータをダウンロードします。
・あなたのクライアントは、あなたの電子妖精のデータの形状データを読み込みます。

後は、クライアントからサーバーにコマンドが、サーバーからクライアントに
動きデータが、リアルタイムにやりとりされて、あなたのクライアント画面上で
あなたの電子妖精が動きだす事になります。

さて、ここで。選手登録されている別の人が、フィールドA上で電子妖精Xを
動かしに来たと思いねぇ。

・P.L.サーバーは、フィールドA上に電子妖精Xを構築します。
 具体的には、登録されているURLを見てP3Dデータをダウンロードします。

そして、

・P.L.サーバーは、あなたに電子妖精XのURLを渡します。
・あなたのクライアントは、URLを見て電子妖精Xのデータの形状データをダウンロードします。
 もし過去にダウンロードしているデータなら、ダウンロードしません。
・あなたのクライアントは、電子妖精Xのデータの形状データを読み込みます。

同様の処理が、その別の人の側でも実行されます。
これで、2人は同じフィールドAの上で電子妖精を戦わせる事が出来ます。

・・・なんか、長々と書いたわりに、しょうもない内容だったね(爆

------------------------------------------------

2001/02/25

サンプル:
「プログラムには手を着けるまい」と思っていたのですが、サンプルプログラムが無いと
つまらなくてやってられない(私自身が)ので、簡単なサンプルプログラムなどを。

 → sample ※javaが有効でないと動きません

※このサンプルは、あくまでも、いろんな動作の試験の為のものであって、実際に製作予定の
 サーバー・クライアントとはほとんど関係ありません・・・いや、要するに、「『遅い!』
 とか言われても知ったこっちゃないよ〜」ということです(^^;

※旧バージョンなので削除。3月18日版でお試し下さい。

今回試してみたのは、接地点を支点とした移動、ジャンプ(重力)っぽいもの
・・・ぐらいです。ダウンロードしてお手持ちのデータで試してみると、いろいろと
変な挙動をして面白いかもしれません。今回のプログラムではHumanMDLにおけるモデルの
位置データは完全に無視していますが、わりと、それっぽく動いているかなあという感じ。
歩きモーションとかを読み込ませると、どこまでも遠いところまで歩いていってくれます。
ジャンプは、よほどうまく(これ向きに)作られたモーションでないと飛ばないんじゃ
ないかなあ・・・。

このサンプルの場合、2番の歩きモーションで足を前に出して接地した時に、少し後ろに
戻っちゃってますね。高いところから落ちてきてもピタっと止まるだけだし・・・。
前に進んでるときに足が地面についたら勢いに流されるように足を後ろに送るべきだし、
ジャンプから着地するときには膝を曲げるべきなんでしょうなあ。そういう外からの力に
従う事をするのは・・・面倒だなあ(弱音)。

あ、あと、実験用に1/100秒毎のコマを全部表示させてますので、環境によっては
遅くてしょうがないかもしれません(^^; 耐えられない人はP3Dデータの周期を
縮めるとかしてだましだまし使って下さい(^^;;;

------------------------------------------------

2001/01/24

よもやま話(思いついたことを適当に):
サーバーからクライアントに送られてくるのは、P3Dにおける「ポーズ」と
そのポーズになる時刻、になるかと思います。クライアント側は、そのポーズと
時刻を元に、現在時刻のポーズを連続して生成し、モーションとします。
あ、ポリゴンの形状データは事前にDLしてる訳ですよ、もちろん。
#指とかはデータが無駄に増えるので、グーとかパーとか、いくつかのパターンを
#事前に用意しておいて・・・となりそうな予感。

データ遅延を解消する為、サーバーからは未来のポーズをとってくることも
できるようにしようかと思っています。もっとも、未来は変化しうる
(キャンセルとかいろいろ)ので、騙されるケースもあるかと思いますが。
観客用クライアントには少し遅れたデータ(そのかわり確定したデータ)を
渡しておけばいいですかね。

おまけ: