みんなでMMORPGを作りましょう

**喪装中** · 04/08/13 20:08

俺が監督をやります

随時スタッフ募集

**名前は開発中のものです。** · 04/09/01 10:59

まぁｶﾞﾝｶﾞﾚ

**名前は開発中のものです。** · 04/09/01 11:14

>>752
接続中のクライアント数と同じ数だけacceptでソケットハンドルを得てるわけで、
クライアントのソケットハンドルを持つ通信用クラスとプレイヤーキャラのクラスを
関連付けすればいい。

誰かというのがプレイヤーキャラのことならば、
ソケットハンドルを得たときに、クライアントに対しログインIDの送信を要求し、
ログインIDと一致するプレイヤーキャラをロードすればいいんじゃないか？

**名前は開発中のものです。** · 04/09/01 11:54

>>753
>>754
ありがとうございます。
＞関連付けすればいい
これができてなかったみたいです。
キャラクターのクラスを作ってそのメンバ変数にソケットハンドルを持たせてみます。

**名前は開発中のものです。** · 04/09/01 12:17

この板みてたら１が激怒したよ

**名前は開発中のものです。** · 04/09/01 16:13

1さんのお知り合いでつか

**名前は開発中のものです。** · 04/09/02 02:56

よーし、パパもサーバー書いちゃうぞ～

ところで、
>>448 ってどうなったん？

**名前は開発中のものです。** · 04/09/02 02:57

>>488 ですた

**名前は開発中のものです。** · 04/09/02 06:24

いつみてもやる気なさそうなページだなぁ
みんなで作ろうぜ！作ってるぜ！なんて意気込みが微塵も感じられない。

**191** · 04/09/02 06:48

>>488はこのスレの前半戦(1-616)のネタをまとめたサイトだな。
>>617以降はｽﾚの趣旨が微妙に変わったので>>488のサイトに期待するのは可哀想だろ。
>>756自称ﾁｰﾀｰによって乗っ取られたようなもんだから>1も怒るかもな。

>>758
ｻｰﾊﾞｰに期待する。
ﾌﾟﾛﾄｺﾙも決めちゃって、他のﾔﾂにｸﾗｲｱﾝﾄ書かせてみたら面白そうだな。

**名前は開発中のものです。** · 04/09/02 07:08

ここで先にアプリケーションプロトコル決めてみたら？

**名前は開発中のものです。** · 04/09/02 10:56

おまいら何本ぐらい接続してる？
今まで1本でやってたけどチャットとゲーム用ぐらいは別にしたほうがいい気がしてきた

**663** · 04/09/02 11:10

とりあえず最低限、サーバと複数クライアント間で会話をすることは
できるようになった気がする。
しかしプログラムは楽しいな。一個ずつできる事が実感をもって増えていく。
もちろん一言でできると言っても次元の高い低いの違いはあるけど。

今までグラフィックばかりやってたけど凄く時間がかかる作業で
キャラなりオブジェクトなり作って一つ一つ完成していくのはそれはそれで楽しいが、
振り返ってみると延々頂点を一センチ二センチ動かす作業を繰り返してただけで
新しく得るものなんてほとんどなくて「この期間俺は何をやってたんだろう…」と
虚しい気分になるだけだったからな。

**名前は開発中のものです。** · 04/09/02 11:12

これ使えばwin機でもUNIX向けの開発できるんじゃね？
今は鯖もwin向けに書く流れだから関係ないかもしれんが

http://www.forest.impress.co.jp/article/2004/01/16/servicesforunix35.html
http://www.microsoft.com/japan/windows/sfu/

**663** · 04/09/02 12:10

今回のチャットはVCのダイアログエディタつかってダイアログベースで作ったけど、
ゲーム内で表示するウィンドウのためのウィンドウシステムみたいのをつくりたい。
ウィンドウオブジェクトの下にボタンとかタブとかテキストフィールドとか自由に配置して
そのテキストフィールドの下にはさらにスクロールバーを配置してとか
そういうのを柔軟にデザインできる仕組みを作りたい。
けど激しくむずそう。なので
とりあえず最初の手がかりとしてなんか課題をくれるとうれしいのであります。

**名前は開発中のものです。** · 04/09/02 12:27

>>762
とりあえずちょっと妄想してみた
このまま拡張していっていいのか評価が欲しい
191氏もヨロシク

・目標
勉強用ということでデバッグの簡単さを優先させたい
マップを歩き回ってチャットするのがとりあえずの目標
ある程度の拡張性は欲しい
特定の開発環境にあまり依存しない

・仕様
通信はテキストによっておこなう
n*4バイトで構成される命令の送受信をおこなう

・・命令の仕様
1語は4byteとする
先頭に1語の命令部とそれに続く0語以上のデータ部で構成される。
****++++++++
*命令部
+データ部
例)
mvtorigt
attk7743
quit

**767** · 04/09/02 12:28

・・命令表
カッコ内はバイト数

戻り値
retn[コード(1)]
なんらかの命令に対する返事である
成功もしくは失敗を示すコードが含まれる

ログイン
lgin[id(8):password(8)]
この命令に成功するとキャラクター操作系の
命令が使用可能になる
戻り値
成功 okok
IDが存在しない noid
パスワードが違う nopw

終了
quit
ログイン以前の状態になる
切断やログインが可能な状態になる
戻り値
成功 okok

**767** · 04/09/02 12:29

mvto[方向(1)]
方向=upup,rigt,down,left
[方向(1)]で指定した方向へ移動する
戻り値
成功 okok
失敗 ngng

chat[チャンネル(1):メッセージ(10)]
戻り値
チャット
成功 okok
そのチャンネルでの発言は許されていない chng
失敗 ngng

**名前は開発中のものです。** · 04/09/02 12:48

チャットはもうちょっと文字数欲しいな…

**名前は開発中のものです。** · 04/09/02 12:49

4bytes*10=40bytesなのかorz

**名前は開発中のものです。** · 04/09/02 13:07

ｽﾏｿ、カッコの中の数字が1語なのか1byteなのか自分が一番混乱してたorz
1語(=4byte)に統一した修正版

retn[コード(1)] (合計8byte)
lgin[id(2):password(2)] (合計20byte)
mvto[方向(1)] (合計8byte)
chat[チャンネル(1):メッセージ(10)] (合計48byte)

**767** · 04/09/02 13:22

>>772に名前入れ忘れてたｽﾏﾇ

ゲームによって移動方法が変わるから目的地を指定して後は鯖まかせで道が選ばれるタイプか
上下左右をダイレクトに指定するタイプなのかで修正が必要な予感
個人的には後者タイプでアクション性が強いものが好みだけど通信量が増えそう

mmoゼルダやりたい(;´Д｀)ﾊｧﾊｧ

**名前は開発中のものです。** · 04/09/02 14:56

コインでお絵かきしたいよ

**191** · 04/09/02 15:14

>>767
ﾁｬｯﾄの部分がちょっと気になるよな。
一文字発言でも48byteってやな感じ。
発言文字列のｻｲｽﾞも送ったほうが良いだろう。
あと、通信料気にするなら文字列で送っちゃ駄目だよな。

で、俺の場合
[送信ｻｲｽﾞ(2byte)] [ﾒｯｾｰｼﾞの種類(1byte)] [ﾃﾞｰﾀ(可変ｻｲｽﾞ)]
受信時に2bye読み込んで受信サイズ取得
受信ｻｲｽﾞ全部受信し終わったら、ﾒｯｾｰｼﾞの種類に応じた処理
ﾁｬｯﾄ文字列送信ならﾃﾞｰﾀ部分が発言文字列って感じだな。

>mmoゼルダやりたい(;´Д｀)ﾊｧﾊｧ
隣接ｷｬﾗのPC強制ｼｬｯﾄﾀﾞｳﾝｺﾏﾝﾄﾞを実装するだけで御手軽に殺伐としたﾁｬｯﾄが出来ると思うｾﾞ

**名前は開発中のものです。** · 04/09/02 15:23

>>775
文字列で動くようになったらバイナリ化する予定なんじゃないか？
文字列バージョンならターミナルソフトでも確認できるし。
しかし可変長ぐらいは扱ってほしいな。

**488** · 04/09/02 17:17

>>761
ちゃんと、見に来てるよ＾＾；；
でも、なんか話が変わってるからついていけてないだけです＾＾；；
なんか、問題あったらスマソ

**名前は開発中のものです。** · 04/09/02 21:05

MMORPGに向いてるライブラリってどれ？

■参考
各種ライブラリ紹介スレ
http://pc5.2ch.net/test/read.cgi/gamedev/1008220559/
http://gamdev.org/w/?%5B%5B%A5%E9%A5%A4%A5%D6%A5%E9%A5%EA%5D%5D

**488** · 04/09/02 21:15

質問！！

C++って奴は、ゲーム作るのにむいてますか？

**191** · 04/09/02 21:20

>766
某ROみたいにｳｨﾝﾄﾞｳをﾕｰｻﾞｰが自由に配置するやつってことかな。
だとしたら、メﾒｲﾝｳｨﾝﾄﾞｳを親にしていしてCreateWindowして
ﾀｲﾄﾙﾊﾞｰﾄﾞﾗｯｸﾞでｳｨﾝﾄﾞｳ移動とかしてやればできそうだな。

そうじゃなくて、プログラムでその場に応じたボタンとか出したいなら
CreateWindowしまくるか、ダイアログなら適当に貼り付けておいてGetDlgItem()で
ﾊﾝﾄﾞﾙ取得すれば、たいていのことはできる。

なんか良い課題が思い浮かばないが、
ウィンドウの中にウィンドウを表示するクラスでも作ってみたら？
ｳｨﾝﾄﾞｳﾌﾟﾛｼｰｼﾞｬはｸﾗｽのﾒﾝﾊﾞ関数で

>>777
監督はもういない。
ｼﾅﾘｵも協力者もいなくなった。
自分でﾌﾟﾛｸﾞﾗﾑ書いて壁にぶつかったらこのｽﾚにこい。
きっと誰かが助言をくれるだろう。

**191** · 04/09/02 21:35

>>778
あんまそういうの使わないからわからん。
自分で自分用ﾗｲﾌﾞﾗﾘつくるのが一番勉強になるし、
そのつくったものが資産にもなるから時間があるならおすすめ

>>779
多態性ｳﾏｰなのでC++(というかｵﾌﾞｼﾞｪｸﾄ指向)はｹﾞｰﾑに向いていると思ってる。
C++はCの強化版みたいなもんなので、C++が出来るってことはCも出来るってことだしな。
今からやるならC++おすすめ。

**名前は開発中のものです。** · 04/09/02 21:44

>>766
DirectX 2004 SummerUpdate に新しく追加された CustomUI みたいなことがやりたいのなら、
既存のウィンドウシステムの仕組みを調べるとある程度どんな感じで作ればいいかはつかめると思う。

**名前は開発中のものです。** · 04/09/02 22:20

>>780
>>766じゃないけど、ウィンドウプロシージャってメンバ関数にできる？
漏れはそれやろうとしたら

error C2440: '=' : 'long (__stdcall Window::*)(struct HWND__ *,unsigned int,unsigned int,long)' から 'long (__stdcall *)(struct HWND__ *,unsigned int,unsigned int,long)' に変換することはできません。(新しい動作 ; ﾍﾙﾌﾟを参照)

って怒られたYO！

**191** · 04/09/02 22:29

>>783
ちょっとしたｺﾂがあってな、ｳｨﾝﾄﾞｳﾌﾟﾛｼｰｼﾞｬにstatic つけるのさ

**名前は開発中のものです。** · 04/09/02 22:33

>>783
staticつけれ。
けどstaticつけたら名前空間に入っただけの
ただの関数になる(=メンバ変数、メンバ関数にアクセス出来ない)から
ウィンドウプロシージャはただの関数にしておいて、その中でメンバ関数を呼べばいい。

**783** · 04/09/02 22:39

>>784
わ～い！即レスありが㌧

確かにstaticにすれば行けるけど、インスタンス独自の処理をさせたい時に困らない？
漏れがやりたかったのは

class Windos
{
public:
Window(...); // CreateWindowやらなにやら

//かなり割愛
protected:
virtual LRESULT WindowProc(...); //ここでこのインスタンス独自の処理をさせたい
}

って感じなんだけど・・・
staticにするとどのインスタンスのメッセージなのかわからないYO！
インスタンスのリストでも持っててプロシージャの中で渡って来たウィンドウハンドルに対応するインスタンス探さなきゃいけないのかな。
それともこういう考え方自体間違ってる？？？？

**766** · 04/09/02 22:45

>>780
どうもです。一応標準のウィンドウシステムを使わないで
生意気にも全部自作したいと思っているのであります。
見た目とか好きにデザインしたいので、、、、

、、、と思ってたらこんなのがあったのか！>>782（教えてくれてありがとう）
IMEクラスとかがんばって作ってしまったのはなんだったんだろう。。。
でも悩むなぁ。自分で作んなきゃ力になんなそうだし、
かといってあくまでやりたいのはコーディングじゃなくてゲーム作りだし。
便利なものは使うべきか…

**名前は開発中のものです。** · 04/09/02 22:45

>>786
HWNDにクラスをもたせて置けばいい。
GetWindowLong/SetWindowLong参照。

**783** · 04/09/02 22:45

書いてる間にレスついてた！
>>785もありが㌧！
うんうん。アクセスできないっていうか、誰のメンバ関数を呼べばいいか判断できなくて困ってるYO

**766** · 04/09/02 22:49

あれ、なんだか標準(?)のウィンドウを使ってる人が多いっぽいんですが、
そういう場合は見た目はカスタマイズしたりして使ってるんですかね。
猫でも～とか見てるとある程度カスタマイズできるみたいですけど
結構いろいろ手続きが面倒くさそうで…

**名前は開発中のものです。** · 04/09/02 23:14

>>787
がんばって最後まで作って。

**783** · 04/09/02 23:21

みんなスゲーーーー！
>>788
ありが㌧！！
そんな便利な関数があったんだね～～
それ使ってユーザーデータにポインタを持たせてやったら呼び出せた！
MSDN検索したらGetWindowLongPtrなんてのもあったけど、漏れの環境じゃ使えなかった。
SDKをアップデートしないとダメなのかな～

とにかくレスくれたみなさんありが㌧！！！

**名前は開発中のものです。** · 04/09/03 00:34

ＺＯＮＥ分けどうするかなぁ

**191** · 04/09/03 04:57

>>792
俺はGetPropとSetPropを使ってる。
まぁ、参考までにってことで

>>790
DirectXで普通のｳｨﾝﾄﾞｳを使いたいってことなのか、
それとも。ただ単にｺﾝﾄﾛｰﾙを自分で描画したいのか？
ボタンとかならオーナー描画にして、自分で描画すれば簡単にできるな。

**790** · 04/09/03 09:58

>>790
例えばチャット窓用のテキストフィールドについて考えれば、
winAPIの標準コントロールを貼り付けるんじゃなくて、
文字の折り返しからスクロールバーから日本語変換から自分で実装したいということです。
で、そんな感じに「ボタン」とか「タブ」とか「スライダー」みたいな部品も全部作って、それらを更に
「自作のゲーム内ウィンドウ」に、
（↑これも「タイトルバー」がある、とか「縮小ボタン」がある、とか定義できる）」
「部品として」位置や個数など柔軟に配置し、制御したいです。

DirectX9.0Cで見た目もカスタマイズできるUIコントローラーというのができたらしいですが、
なんかやっぱり自分で全部作りたくなってきました。
クラスの勉強の範疇だと思うんですが、どうしてよいやらという感じです。
それぞれ部品の一個一個単独なら作れそうなんですけど。

↓標準コントロール貼り付けて作ってるっぽい例
ttp://eternal.s19.xrea.com/ss.html

↓自前ウィンドウシステムを作ってるっぽい例
ttp://www.nubarou.mydns.jp/wiki/pukiwiki.php
（スクリーンショットのところ参照）

**名前は開発中のものです。** · 04/09/03 16:33

日本語変換て…何参照するつもりなんだ

**790** · 04/09/03 17:00

漢字変換って言うか、FEPの制御のことだけどなんか変かいな？

**名前は開発中のものです。** · 04/09/03 17:00

>>796
チャットウィンドウのIME処理もAPIからやりたいってことじゃね？

**191** · 04/09/03 19:36

>>795
DirectXで日本語入力は確かに手強いな。
ｴﾃﾞｨｯﾄﾎﾞｯｸｽをDirectXで使いたいと思って対処したときは大変だった。
CreateWindowでｴﾃﾞｨｯﾄﾎﾞｯｸｽ作成して画面外の遙か彼方へ移動して隠蔽。
ｳｨﾝﾄﾞｳに対するｸﾘｯｸとかｷｰ入力でｴﾃﾞｨｯﾄﾎﾞｯｸｽに渡したいものだけを
座標変換とかしてSendMessageでｴﾃﾞｨｯﾄﾎﾞｯｸｽに再送信。描画は全部自分で。
なんかｽﾏｰﾄじゃないな。

>それぞれ部品の一個一個単独なら作れそうなんですけど。
単独で作れそうならいけるんじゃないか？
ｳｨﾝﾄﾞｳ管理ｸﾗｽを作って、ｽｸﾛｰﾙﾊﾞｰとかのｺﾝﾄﾛｰﾙ系ｸﾗｽを追加していく
javaのAppletｸﾗｽみたいな感じで実装したら良いんじゃないかなぁ

**795** · 04/09/03 22:25

>>799
FEP制御はある程度できてて、
入力した文字とか変換候補をベタに表示したりするのはできてるんで、
あとはウィンドウ幅に合わせて改行したりスクロールバーとかつけられたら
エディットボックスとして単体部品としては完成できそうです。
けどやっぱり全体をまとめたクラスの設計をどうすればいいのか分からないし
どこがどう分からないというのも複雑で説明できない。。。
もうすこしクラスの勉強をする必要がありそうです。

**名前は開発中のものです。** · 04/09/04 01:37

VC++4.2からはコンポーネントギャラリでサクッと雛形を入れたれたような？
それ参考にすれば余裕かと。

**191** · 04/09/04 01:50

>>800
ｸﾗｽの設計とかは経験値が重要かもしれん。
いくつもﾌﾟﾛｸﾞﾗﾑ書いてみることだな。ｶﾞﾝﾊﾞﾚ

子ｳｨﾝﾄﾞｳを考えないなら俺ならこうすると思う。
clas Iｳｨﾝﾄﾞｳ{
　RECT* GetRect();
　ﾌﾟﾛｼｰｼﾞｬｰ(...);
　(略)
}
class ｳｨﾝﾄﾞｳﾏﾈｰｼﾞｬｰ{
　ｳｨﾝﾄﾞｳ追加(Iｳｨﾝﾄﾞｳ *pWindow);
　ｳｨﾝﾄﾞｳ抹殺(Iｳｨﾝﾄﾞｳ *pWindow);
　ﾌﾟﾛｼｰｼﾞｬｰ(...)
　(略)
}
実際のｺﾝﾄﾛｰﾙはIｳｨﾝﾄﾞｳを継承させる。
そしたら、ﾎﾞﾀﾝでもｴﾃﾞｨｯﾄﾎﾞｯｸｽでもｳｨﾝﾄﾞｳﾏﾈｰｼﾞｬｰにぶち込める。
本来のｳｨﾝﾄﾞｳをｻﾌﾞｸﾗｽ化とかして、ｳｨﾝﾄﾞｳﾏﾈｰｼﾞｬｰのﾌﾟﾛｼｰｼﾞｬｰに渡す。
ｳｨﾝﾄﾞｳﾏﾈｰｼﾞｬｰでｱｸﾃｨﾌﾞなｺﾝﾄﾛｰﾙを判断(ｸﾘｯｸならﾋｯﾄﾃｽﾄして)、そしてｺﾝﾄﾛｰﾙのﾌﾟﾛｼｰｼﾞｬｰを実行。

ｳｨﾝﾄﾞｳﾏﾈｰｼﾞｬｰ::ﾌﾟﾛｼｰｼﾞｬｰ(...){
　Iｳｨﾝﾄﾞｳ *pWin = ｳｨﾝﾄﾞｳﾏﾈｰｼﾞｬｰ::ｱｸﾃｨﾌﾞｳｨﾝﾄﾞｳ検索(posClick) ;
　pWin.ﾌﾟﾛｼｰｼﾞｬｰ(...) ;}

こんな感じかな。
Iｳｨﾝﾄﾞｳでｺﾝﾄﾛｰﾙの場所と矩形領域を管理。
ｳｨﾝﾄﾞｳﾏﾈｰｼﾞｬｰでｳｨﾝﾄﾞｳの重なり(順番)を管理。
参考にならなかったらすまぬ。
俺が助言できるのはココまでだ。

**名前は開発中のものです。** · 04/09/04 05:32

どこかにライセンスフリーで一貫性があって魅力的な「ＲＰＧの世界設定」無いかね

**名前は開発中のものです。** · 04/09/04 05:56

>>803
妄想だらけの設定厨はいくらでもいるんだけどな。皮肉だなｗ
なんとか妄想厨を寄せ集めて、一つのものはできないものかｗ

**名前は開発中のものです。** · 04/09/04 08:41

>>803
言われてみれば無いよな、ほんと。
前出てきてた農民ﾍﾞｰｽのMMOなんか面白そうだったがｗ

**名前は開発中のものです。** · 04/09/04 11:17

通信ウィンドウのサブクラス化
結論
WSAAsyncSelect()で任意のウィンドウに直接msgを
送るのはやめる。
だめだ、ネットのサンプルソースじゃ
見つけたのは全てMainProcに直接書いてる
ましなのは、MainProcで明示的に通信用Proc呼んでるし
・・・帰りに図書館行ってきます

**名前は開発中のものです。** · 04/09/04 13:38

サブクラス化のメリットって何？
少なくとも現時点での設計で

**名前は開発中のものです。** · 04/09/04 13:42

SwingとかGTK2とか、それのWindowツールキットと似たような設計で何が不満なんだ。
人間にとっての使いやすさ考えると、おのずとああいう設計になると思し、
それで慣れてる人多いからそういう設計でいいんでないか。

**名前は開発中のものです。** · 04/09/04 14:19

>>807
１、可読性。
２、ウィンドウ機能としてクラスにまとめられる。
３、デフォルトの処理をしなくて良い。

**名前は開発中のものです。** · 04/09/04 14:31

プロトコルは
>>767で決定なの？

**191** · 04/09/04 16:02

>>806
ｻﾌﾞｸﾗｽ化できてんでしょ？
例えばhMainWin(MainProc)があるとして
hMainWinをｻﾌﾞｸﾗｽ化してSubProcを関連付ける。
SubProcで通信ﾒｯｾｰｼﾞだけを拾って処理。
WSAAsyncSelect()でﾒｯｾｰｼﾞをhMainWinに送れば実現できそうじゃない？

>>807
通常のﾌﾟﾛｼｰｼﾞｬｰで通信について配慮する必要がない。
ｳｨﾝﾄﾞｳのあるｱﾌﾟﾘｹｰｼｮﾝなら簡単に導入可能。

>>808(>>803)
>「ＲＰＧの世界設定」無いかね
現実
>SwingとかGTK2とか、それのWindowツールキットと似たような設計で何が不満なんだ。
誰か不満もらしたか？

>>810
>>767が作る>>767のためのｱﾌﾟﾘｹｰｼｮﾝはあのﾌﾟﾛﾄｺﾙをﾍﾞｰｽに修正したもので決定だろ。

このｽﾚで何か一つのものを作ってる訳じゃないぞ！

**名前は開発中のものです。** · 04/09/04 17:06

MMORPG って何の略？

**名前は開発中のものです。** · 04/09/04 17:58

>>811
正直マ板いけば？って感じ

**名前は開発中のものです。** · 04/09/04 18:04

ムだった

**名前は開発中のものです。** · 04/09/04 18:59

>>488も音沙汰がないようなので、
他にプロジェクトの概要や製作状況をまとめた
Webページがないのであればスレッドの削除依頼を出します。

**名前は開発中のものです。** · 04/09/04 19:17

>815
おいおいどこに目をつけてるんだ
ここにまとめてあるだろうが
http://gamdev.org/w/?%5B%5BMMORPG%A4%F2%BA%EE%A4%C3%A4%C6%A4%DF%A4%BF%A4%A4%5D%5D

**名前は開発中のものです。** · 04/09/04 19:23

>>815
ナイズギャグ

**名前は開発中のものです。** · 04/09/04 19:34

もう800超えてるし埋まるまで好きにやればいいと思うよ・・・

**795** · 04/09/04 19:39

>>802
どもです。なんか難しくて現状での理解の範疇を超えているので
とりあえずメモ帳に保存しときました。

**名前は開発中のものです。** · 04/09/04 19:47

>>816
ていうかひとんちのスレだろ、それは・・・

**795** · 04/09/04 21:56

マウスで矩形をドラグするという実験ですが、
マウスボタンの押下状態の取得を
WMのスイッチを使わないでGetAsyncKeyStateで逐一行っている為か、
ボタンを押した状態で外から接するとそのまま掴めてしまいます。
ウィンドウメッセージ使う以外にどうにか方法はないでしょうか…
（こんな感じで自前ウィンドウ処理をベタに作っていくのって無理臭いですかね？）
ttp://gamdev.org/up/img/1162.zip

**795** · 04/09/04 21:58

書き忘れましたが821はVC6++プロジェクト入りです。

**191** · 04/09/04 22:47

>>821
なんか小難しいこと書いてすまんな。
で、1162.zipだが
ボタンが押されるってのはボタンがＯＦＦの状態からＯＮになることを言うんだぜ。
mywindowで以前のカーソル位置とマウスボタン押し状態も保存。
毎回マウスボタン状態もチェックして以前がOFF、現在がONになっていたらドラッグ開始とすればいい。
勿論以前の状態か現状でマウス座標が範囲外なら無視だ。

**名前は開発中のものです。** · 04/09/04 23:16

チャットソフトから先に進まない、に96円賭ける

**795** · 04/09/05 00:35

>>823
できたーーーーーーーーーー！
ボタンの過去の状態と、ドラグ中かどうかのフラグも追加して
組み合わせたらできました。
サンクスコ！

**名前は開発中のものです。** · 04/09/05 01:09

>>815
今はMMORPGの基礎技術スレになってるので、
プロジェクトとは関係ないですよ。

**作りたい人** · 04/09/05 15:34

お初です。

本気でＭＭＯを作ろうと思ってるだけど。

アクション系ＭＭＯ（リネ２よりアルタイム度を上げたい）にしたいんですが、
データベースって汎用ＤＢ（オラクルとか）を使うものなの？

アクション性の高いＭＭＯとか、情報がかわったら毎回更新しているわけないよね。
サーバープログラム内部で、データを保持していて、定期的に更新にいってるのかなあ？（それともログアウトするまで、そのまま？）
できれば、サーバを複数台立ち上げても、データベースを更新せずに、相互にデータの補完しあえるようにしたい。

そういう高速簡易ＤＢを自分で設計したほうがいいのかなあ？
汎用ですでに実績があるのもがあるのであれば、あえて、ＤＢから作ることは避けたいんだけど。

クライアントの挙動なんてどうにでもなると思ってます。

駄文ですが、聞きたいことは。
　・現在のアクション系大規模ＭＭＯでは、どういうタイムミングで、更新するのが普通なのか？
　　汎用ＤＢでも耐えれるか？ＤＢサーバースペックはどのくらいもので、運用しているのか？
　・何か参考になるサイトないですか？

なお、ゲームデザイン論や新しい世界観に関しては他人から得るものは何もないで、
興味ないです。

**名前は開発中のものです。** · 04/09/05 15:56

あなたから得るものは何もないんで、興味ないです。

**名前は開発中のものです。** · 04/09/05 16:23

>>827
「レイテンシ」って知ってる？
ついでにオラクルの値段も

**191** · 04/09/05 16:23

>>827
データベース未経験だし、MMO作ったこともないのでパス

以下は個人的想像
>現在のアクション系大規模ＭＭＯでは、どういうタイムミングで、更新するのが普通なのか？
よくｻｰﾊﾞｰﾒﾝﾃとかでログオフしてくれって言われるじゃん。
そこから察するにログオフ時にデータベースに保存してるんじゃないかな。
巻き戻しとかもデータベースの内容＋サーバー稼働ログがあれば出来るし。
>汎用ＤＢでも耐えれるか？
耐えられない規模まで個人制作MMOを盛り上げるのが困難だと思う…

**名前は開発中のものです。** · 04/09/05 16:48

良くあるMMOの更新のタイミングは、
・ログオフのとき
・別のマップに移動したとき
・交換などユーザ間でアイテム等の移動が行われたとき
って感だと思う。

重要なのは、サーバが落ちたときやユーザの回線が不意に切れたときに
・データの矛盾
・ユーザにストレスを与えるほどの撒き戻り
等の問題が起こらないことだと思う。

上の問題が起こらない範囲でなるべく更新を少なくすれば、一番効率がいいんでない。

**名前は開発中のものです。** · 04/09/05 16:53

ここで、単語を打つ事を勧める
tp://cgi.www5f.biglobe.ne.jp/~fortune7/ccnp/daken/type.cgi

**名前は開発中のものです。** · 04/09/05 17:00

逐時更新しないと他プレイヤーに反映されないとおもうんだが。位置情報とか。
そんなことないのか？

**名前は開発中のものです。** · 04/09/05 17:33

メモリ内のプレイヤー情報を、いつストレージに書き出すかってことを言ってるんだと思いますが

**名前は開発中のものです。** · 04/09/05 17:33

>>827
>アクション系ＭＭＯ（リネ２よりアルタイム度を上げたい）にしたいんですが、

なぜリネ２がもっとリアルタイム性を上げないか考えたことある？

**795** · 04/09/05 17:57

できるだけ人を入れて金儲けしたかったからじゃないでしょうか。

**名前は開発中のものです。** · 04/09/05 18:02

>827は多分素人の意見を聞きたくは無いと思うので、独り言として喋ります。
まず重要なデータ、アイテムとかそうそう頻繁に書き換えが必要でないもの
と、そうでないデータ、位置情報とか。MMORPGで一番多いデータの種類が移動データである、って多分聞いたことあると思うけど。
この２つの更新タイミングを分けるべきだね。
前者は逐次書き換え、後者は、10分毎くらいか、ログアウト時。
こんな感じでいいんじゃないのかな。

**名前は開発中のものです。** · 04/09/05 18:05

>>836
そう。数千人規模にもなるとあれぐらいが限界です。

蛇足になるが”金儲けしたかったから”これはいらない。
企業が利益を求めるのは当然です。
むしろ836のお金に対するコンプレックスが見えて笑えますよ。

**名前は開発中のものです。** · 04/09/05 18:12

リネ２ってアクション系だったのかよ

**名前は開発中のものです。** · 04/09/05 18:51

>>838
その点でリネ2を語るなら、セキュリティ面が抜けてるよ

**名前は開発中のものです。** · 04/09/05 18:59

>>840
抜けてると思うなら補足してくれよ。
なにから何まで説明する気はないよ。

**191** · 04/09/05 18:59

なんかMMOについて語りたいだけって感じのレス増えたな。
DB得意なヤツはいないのか？

>>838
>そう。数千人規模にもなるとあれぐらいが限界です。
何が限界なんだ？通信量か？それともDB負荷？
>>827で問題としてるのはDBだぞ。
汎用DBって数千人規模で限界になるようじゃ使えないと思うんだが…。

**名前は開発中のものです。** · 04/09/05 19:05

>>842
わりい。俺が勝手に通信量の話してたね。
ただ、ＤＢ以前の問題だなと思ったのさ。

**783** · 04/09/05 22:52

話の流れをぶった切ってしまうけど・・・

ウィンドウメッセージごとに受け取る関数を書いたインターフェイス(MessageListener)を作って、
メッセージを受け取ったウィンドウは登録されているMessageListenerに処理は任せちゃおう！
と思って全てのメッセージを受け取るインターフェイスを作ってたさ。

できたら便利だよYO！最強だYO！！！
シコシコシコーーー・・・

ttp://gamdev.org/up/img/1176.zip
＿|￣|○ 既に使う気になれねぇーーーーーーーーーーーーーーーーーー！！！

こんなアホな漏れを誰か叱ってください。おながいします・・・

これでもまだ半分にも届いてな～い。
何か種類ごとにインターフェイス分けるとかしないとダメポ・・・

**191** · 04/09/05 23:18

>>844
ｵｲｵｲ、ﾔﾘｽｷﾞ
ってかMFC使いなさいYO

**名前は開発中のものです。** · 04/09/06 09:53

>>844
笑った。
っていうか純粋仮想関数にするから使えなくなるのでは。
本当に必須の所だけにしとき。

**795** · 04/09/07 00:49

チャット窓用に、文字列つっこむと勝手に改行とかしてくれる
窓というか部品を製作中。
自分の実力では予想以上に難しいのでそのうち助けを求める確立高し…

**795** · 04/09/07 00:50

あげてしまった。

**622** · 04/09/07 12:00

>>744
WSAAsyncSelectが信じられなくなってしまったので、
（メッセージを送信してほしいhWnd渡しても送ってくれない）
サンプル見ないと、私が理解出来そうに無いっぽいですorz

>>745
サブクラスは、あっちのほうに置いておくことに・・・
分割受信に対応しました。（欠損して届くと大変なことに）
ttp://gamdev.org/up/img/1193.zip

自分がだらけてきたので、充電開始～。

>>847
>>637ここの・・・って
製作環境違うんでしたっけ、アドバイスできない
orz

**191** · 04/09/07 17:24

>>847
AddLog(文字列) って感じで文字列渡すと改行して文字列追加してくれるって事か？
それとも、<br>とか\nを自動で改行に変換ってことか？
駄目なときはもう少し明確に教えてｸﾚよ。

>>849
>WSAAsyncSelectが信じられなくなってしまったので、
たぶん、渡すHWNDが間違っているかｻﾌﾞｸﾗｽ化でのﾌﾟﾛｼｰｼﾞｬの実行順序の勘違いじゃないか？
>分割受信に対応しました。（欠損して届くと大変なことに）
TCPなら欠損ｼﾈｰだろ。分割受信はｱﾚでよさげ。良くやった。
今後の方針もｱﾚで良し。

ttp://gamdev.org/up/img/1195.zip
ｻﾌﾞｸﾗｽ化+Winsockの合わせ技のｻﾝﾌﾟﾙを書いてみた。
ﾒｲﾝｳｨﾝﾄﾞｳのﾌﾟﾛｼｰｼﾞｬで通信処理を書いてないのがﾎﾟｲﾝﾄ

ｽﾏﾝ、むしゃくしゃして書いた。
自分が面白ければ何でも良かった。
まさかこんなに長く複雑でｻﾝﾌﾟﾙとして不適切になるとは思わなかった。
今は反省している。
ｻﾝﾌﾟﾙで解らなかったら聞け

**795** · 04/09/07 17:58

>>849
ヘタレのくせに無謀にも標準コントロールを使わずに
自前で処理をしようと考えているのです。
普通の人なら簡単な事なのかもしれないですけど難航してます…

>>850
＞AddLog(文字列) って感じで文字列渡すと改行して文字列追加してくれるって事か？
こんな感じになるように作ってます。
ウィンドウ幅を自由に変えられたりスクロールバーも
つけることを考えてるのでその辺が難しいです。
今の所なんとか思いつく事があるのでそれを試してます。
でもなんか汎用性の無いものになりそうな予感。
何も思いつかなくなったら助けを求めに来るのでよろしくです。

**名前は開発中のものです。** · 04/09/07 19:10

どうでもいいけどサーバー側が
UnixかLinuxで動く事を考慮して作らないと意味がない。
サーバーをWinOSに限定するならDirectPlay使ったほうがいい。