ゲーム開発メモ・日記
6/23
(`・ω・´)
あとチョット細かい調整をしたら、新キャラモデル版を公開できそうなカンジです。
ただ、前言ったように公開する場合でも当初はサーバは不定期に稼働させるコトになる予定です。
現公開バージョンからの変更点は↓のようになる予定。
・プレイキャラクターのモデルが新しくなります。
・男性を選択できるようになります。また、体型を変えられるようになります。
・装備も変更され、インナーの装備が追加されます。
・モデルが変わるのでモーションも変更されます。走るのも少し速くなります。
・視点の動きがわりと変わります。
とりあえずこんくらい変更してから、新機能を追加してく予定です。
新キャラモデルになって、重くなるのを心配する人もいると思うのですが、 キャラクターのポリゴン数自体は少なくなります。 また、装備を着て隠れるポリゴンをなるべく描画しないようにチューンしています。
反面、プレイキャラクター/装備のほぼすべてにテクスチャを貼るようになるので、そのぶん重くなります。
実際の描画速度の変化は環境によって異なるのですが、自分の環境でちょっとだけ比べてみたトコロ、 裸状態だと新モデルの方が重いけど、装備をいっぱいつけるとそんなに変わらない、ってカンジでした。
あとチョット細かい調整をしたら、新キャラモデル版を公開できそうなカンジです。
ただ、前言ったように公開する場合でも当初はサーバは不定期に稼働させるコトになる予定です。
現公開バージョンからの変更点は↓のようになる予定。
・プレイキャラクターのモデルが新しくなります。
・男性を選択できるようになります。また、体型を変えられるようになります。
・装備も変更され、インナーの装備が追加されます。
・モデルが変わるのでモーションも変更されます。走るのも少し速くなります。
・視点の動きがわりと変わります。
とりあえずこんくらい変更してから、新機能を追加してく予定です。
新キャラモデルになって、重くなるのを心配する人もいると思うのですが、 キャラクターのポリゴン数自体は少なくなります。 また、装備を着て隠れるポリゴンをなるべく描画しないようにチューンしています。
反面、プレイキャラクター/装備のほぼすべてにテクスチャを貼るようになるので、そのぶん重くなります。
実際の描画速度の変化は環境によって異なるのですが、自分の環境でちょっとだけ比べてみたトコロ、 裸状態だと新モデルの方が重いけど、装備をいっぱいつけるとそんなに変わらない、ってカンジでした。
6/9
(´・ω・)
忙しくて開発がゼンゼン進まないス(´・ω・`)
一応新キャラモデルでキャラ作成してサーバに接続して遊べるようにはなったのですが、 細かい調整をしなきゃなんないトコがいっぱいあるス。
とりあえずSS貼っとくス。
忙しくて開発がゼンゼン進まないス(´・ω・`)
一応新キャラモデルでキャラ作成してサーバに接続して遊べるようにはなったのですが、 細かい調整をしなきゃなんないトコがいっぱいあるス。
とりあえずSS貼っとくス。
5/4
予定
今後の予定なのですが、キャラの新モデル導入の他にもイロイロ変更したし、基礎部分にも手を加えたいので、 今後の方針としては次のようにしようカナーと思っています。
・現在公開しているバージョンの更新は、バグ修正などに留め機能の追加は基本的に行わない。
・新バージョンについては当初はイロイロなテストを行いたいのと、 不安定だったりバランス調節がテキトーだったりすると思うので、サーバは不定期に稼働させる。 こちらのキャラデータは頻繁にワイプされる可能性が高いです。
・新バージョンに主要に機能が追加し終えた時点で、新バージョンのサーバを本格稼働・旧サーバ終了。
ってなカンジにする予定。
移行時に旧サーバのデータを引き継ぐかどうかは未定ですが、装備等のアイテムも変更されるため、 引き継ぐにしても完全な移行はできないと思います。 ゲームを面白くするコトとデータの引き継ぎ、二者択一の場合は前者を優先させます。
新バージョンはボチボチ作ってるのですが公開時期はまだわかんないです。
今後の予定なのですが、キャラの新モデル導入の他にもイロイロ変更したし、基礎部分にも手を加えたいので、 今後の方針としては次のようにしようカナーと思っています。
・現在公開しているバージョンの更新は、バグ修正などに留め機能の追加は基本的に行わない。
・新バージョンについては当初はイロイロなテストを行いたいのと、 不安定だったりバランス調節がテキトーだったりすると思うので、サーバは不定期に稼働させる。 こちらのキャラデータは頻繁にワイプされる可能性が高いです。
・新バージョンに主要に機能が追加し終えた時点で、新バージョンのサーバを本格稼働・旧サーバ終了。
ってなカンジにする予定。
移行時に旧サーバのデータを引き継ぐかどうかは未定ですが、装備等のアイテムも変更されるため、 引き継ぐにしても完全な移行はできないと思います。 ゲームを面白くするコトとデータの引き継ぎ、二者択一の場合は前者を優先させます。
新バージョンはボチボチ作ってるのですが公開時期はまだわかんないです。
4/21
( ´∀`)
しばらく開発をサボってたのですが、再開しました。
作らなきゃなんない部分はイロイロあるのですが、とりあえず絵がキレイになってきたのでSS貼っときます。
しばらく開発をサボってたのですが、再開しました。
作らなきゃなんない部分はイロイロあるのですが、とりあえず絵がキレイになってきたのでSS貼っときます。
小太りなジジィ鍛冶屋風味 | 女戦士風味 |
10/20
(´Д`)y─┛~~~
ココントコはネットワーク関係とか暗号化とか基礎部分の見直しを主にやってました。
もっとゲーム的な部分を拡張してほしいと思う方が多いと思います。 ほんでプレイヤーが面白いと感じる部分は開発するのも楽しいモノなんですが、 今後必要な部分なのでメンドクサイけど作んなきゃなんないんす。
新しいキャラのモデルのデータはあらかた揃ったのですが、 新モデル導入と同時に内部的にも大幅に変更する予定なので、基礎部分がしっかりしてないとボロボロになりそうだし。
暗号については鍵共有にDiffie-Hellman、ストリーム暗号にArcfour(RC4)、ハッシュにSHA1を使ってみました。 暗号は理論は結構面白いのですが、実装はメンドクサイっすね。
暗号強度を確保しようとするとどうしても鍵長を長くする必要があるのですが、 そーなると実装で手を抜こうとするとアホみたいに処理に時間がかかっちゃって使い物にならなくなっちゃう...。 一部の計算はアセンブラで組んでみたのですがイマイチ納得のいく速度が出なかったっす。 なので特に重要なトコ以外は鍵長を短くしてしまいました。楕円曲線暗号とか使うと高速化できるカナー?
気づいたらアカウント数が5万を超えてました。( ´▽`)
ココントコはネットワーク関係とか暗号化とか基礎部分の見直しを主にやってました。
もっとゲーム的な部分を拡張してほしいと思う方が多いと思います。 ほんでプレイヤーが面白いと感じる部分は開発するのも楽しいモノなんですが、 今後必要な部分なのでメンドクサイけど作んなきゃなんないんす。
新しいキャラのモデルのデータはあらかた揃ったのですが、 新モデル導入と同時に内部的にも大幅に変更する予定なので、基礎部分がしっかりしてないとボロボロになりそうだし。
暗号については鍵共有にDiffie-Hellman、ストリーム暗号にArcfour(RC4)、ハッシュにSHA1を使ってみました。 暗号は理論は結構面白いのですが、実装はメンドクサイっすね。
暗号強度を確保しようとするとどうしても鍵長を長くする必要があるのですが、 そーなると実装で手を抜こうとするとアホみたいに処理に時間がかかっちゃって使い物にならなくなっちゃう...。 一部の計算はアセンブラで組んでみたのですがイマイチ納得のいく速度が出なかったっす。 なので特に重要なトコ以外は鍵長を短くしてしまいました。楕円曲線暗号とか使うと高速化できるカナー?
気づいたらアカウント数が5万を超えてました。( ´▽`)
10/3
10/2
新しいパソコン買いました...ウソです買いませんでした
現在ウチには3台のデスクトップPCとサブノートPCが稼働しているのです。 デスクトップPCの1台はmmo!のサーバであとはメイン・サブとして使ってます。
サブPCは例のmmo!のサーバが逝ってしまった後に買ったのですが、 グラボのテストとかしようと思ったら問題発生してしまいました。 わりと最近買ったPCなんでAGPx2とかの古いグラボに対応してないんすよ。
しょーがないので、すごく昔のPC(ファミコンのカートリッジみたなCPUが刺さってる。P!!!600MHzカナ?) の電源をひさしぶりに入れてみたら起動しないし...(´Д`;)
かといってメインPCは環境汚れるのがイヤなのでグラボ差し替えとかしたくないし、どーしよう... と思って、「もー一台パソコン買っちゃおうかなー」とか思ったんすよ。
んで、最近の自作PC事情に疎かったのでちょっとイロイロ調べたんすけど、なーんかコレってのが決まらない。 組むんなら、今持ってるPCよりカナリ性能の高い物にするか、もしくは激安にするか、どっちかにしようと思ったんすけど、
安くしようとしてもシステム全体だとそれなりにかかっちゃうので、もうちょいCPUとかにお金かけた方がおトクな気がする →そうすると今のPCと同じような物ができあがる→なんだかなぁ...
高性能にしようとすると、Intelは高性能化に苦労してるかんじだし、AMDの64bitCPUは興味はあるけど 万が一ソレが原因で問題とか起こったりしたらメンドクサイ(開発に使用するから通常の利用より危険だし)。 あと、CPUの他にもPCI Expressとか規格の変わり目なのでソレもちょっとヤなかんじ。CPUソケットの規格も乱立してるし...
んで、悩んでたんですが、ふと思いついたんすよ。「メインPCとサブPCの役目を取っ替えればイイじゃん!」 ...こんなことに気がつかないなんて、アホですかオレは?
で、結局新しいPCは買わなかったのですが、先週秋葉原まで行く用事があったので、代わりといってはなんですが、 ハードディスクとテスト用に古ーいグラボ2枚を買ってみました。
グラボはGeForce2MXとRAGE Mobility-Mです。忙しくてまだ開封すらしてないんですが、ココらへんのグラボでも 「快適とはいえないけど一応ゲームはできる」くらいにしたいなあ...。 あ、グラボ買おうと思ってる人はまちがっても同じヤツ買っちゃダメです。5~6千円くらいで買えるRadeon9200SEとか FeForceFX5200とかでもコイツらの10倍以上の性能だと思うし。
ちなみに現在のオイラのパソコンたち
メインPC : Pentium4 2.8C GHz + Radeon9600 + メモリ1G + HDD80G+80G
サブPC : AthlonXP 2600+ + Radeon9200ナド + メモリ512M + HDD60G(+新しく買った80G)
ゲームサーバ : AthlonXP 2200+ + SIS740内蔵 + メモリ512M + HDD120G(ファイル置き場化してる)
グラボにRadeonが多いのは安くてファンレスだから。重い最新ゲームとかやんないし。
そして死亡して転がっているPCやCPUの刺さったマサーボードたち。
Celeron1.4GHz (昔のmmo!のサーバ。最低動作環境の目安だったi815なので壊れたのがイタイ...)
Pentium!!! 600MHz (もっと昔のmmo!のサーバ)
Pentium!!! 800MHz (アレ、もっと昔のmmo!のサーバはこっちだったっけか?)
AthlonXP 1800+
壊れすぎ...
現在ウチには3台のデスクトップPCとサブノートPCが稼働しているのです。 デスクトップPCの1台はmmo!のサーバであとはメイン・サブとして使ってます。
サブPCは例のmmo!のサーバが逝ってしまった後に買ったのですが、 グラボのテストとかしようと思ったら問題発生してしまいました。 わりと最近買ったPCなんでAGPx2とかの古いグラボに対応してないんすよ。
しょーがないので、すごく昔のPC(ファミコンのカートリッジみたなCPUが刺さってる。P!!!600MHzカナ?) の電源をひさしぶりに入れてみたら起動しないし...(´Д`;)
かといってメインPCは環境汚れるのがイヤなのでグラボ差し替えとかしたくないし、どーしよう... と思って、「もー一台パソコン買っちゃおうかなー」とか思ったんすよ。
んで、最近の自作PC事情に疎かったのでちょっとイロイロ調べたんすけど、なーんかコレってのが決まらない。 組むんなら、今持ってるPCよりカナリ性能の高い物にするか、もしくは激安にするか、どっちかにしようと思ったんすけど、
安くしようとしてもシステム全体だとそれなりにかかっちゃうので、もうちょいCPUとかにお金かけた方がおトクな気がする →そうすると今のPCと同じような物ができあがる→なんだかなぁ...
高性能にしようとすると、Intelは高性能化に苦労してるかんじだし、AMDの64bitCPUは興味はあるけど 万が一ソレが原因で問題とか起こったりしたらメンドクサイ(開発に使用するから通常の利用より危険だし)。 あと、CPUの他にもPCI Expressとか規格の変わり目なのでソレもちょっとヤなかんじ。CPUソケットの規格も乱立してるし...
んで、悩んでたんですが、ふと思いついたんすよ。「メインPCとサブPCの役目を取っ替えればイイじゃん!」 ...こんなことに気がつかないなんて、アホですかオレは?
で、結局新しいPCは買わなかったのですが、先週秋葉原まで行く用事があったので、代わりといってはなんですが、 ハードディスクとテスト用に古ーいグラボ2枚を買ってみました。
グラボはGeForce2MXとRAGE Mobility-Mです。忙しくてまだ開封すらしてないんですが、ココらへんのグラボでも 「快適とはいえないけど一応ゲームはできる」くらいにしたいなあ...。 あ、グラボ買おうと思ってる人はまちがっても同じヤツ買っちゃダメです。5~6千円くらいで買えるRadeon9200SEとか FeForceFX5200とかでもコイツらの10倍以上の性能だと思うし。
ちなみに現在のオイラのパソコンたち
メインPC : Pentium4 2.8C GHz + Radeon9600 + メモリ1G + HDD80G+80G
サブPC : AthlonXP 2600+ + Radeon9200ナド + メモリ512M + HDD60G(+新しく買った80G)
ゲームサーバ : AthlonXP 2200+ + SIS740内蔵 + メモリ512M + HDD120G(ファイル置き場化してる)
グラボにRadeonが多いのは安くてファンレスだから。重い最新ゲームとかやんないし。
そして死亡して転がっているPCやCPUの刺さったマサーボードたち。
Celeron1.4GHz (昔のmmo!のサーバ。最低動作環境の目安だったi815なので壊れたのがイタイ...)
Pentium!!! 600MHz (もっと昔のmmo!のサーバ)
Pentium!!! 800MHz (アレ、もっと昔のmmo!のサーバはこっちだったっけか?)
AthlonXP 1800+
壊れすぎ...
9/21
サーバ最適化
ちょっと前にサーバ負荷がヤバイことになったんすよ。PvP大会とか大勢が一カ所に集まって激しく戦うとヤバイっす。 なもんで、ちょっくらサーバの負荷を減少させてみました。
去年の6/19日のトコの日記に書いてあるように、 キャラクターやモンスター間で線形リストで視界にいるかどうかを保持しているのですが、まずはコレをSTLにしてみました。
STLだとメモリの確保・解放を1回ごとにやらないでまとめてやるとどっかで見たような気がするので、負荷が低くなるカナー、 と思ったのですが、ほとんど変わらなかったっす。むしろ微妙に遅くなったかも...?(´Д`;)
しょーがないので、次に上記リスト内に距離を保持させて、 攻撃とかの当たり判定である程度距離で足きりして高速化を図ってみました。
それから、負荷が高いのが飛んでくタイプの魔法です。ちょっと進むごとに当たり判定してたので負荷がとても高かったです。 なので、ある程度間隔を置いて当たり判定をさせるようにしました。
でもそれだけだと、魔法が敵をすり抜けちゃったりするので、この場合には、 当たり判定を点と点の距離で行うのでなく線分と点の距離で行うようにしました。
さらに魔法発射時に当たる可能性のある敵のリストを作って以降はそのリストの敵のみと当たり判定をするようにしました。
実際のトコ、他のMMORPGだと負荷が高くなんないように発射した時点で当たり判定とかダメージ計算をしちゃったりするのですが、 やっぱ軌道を見て避けることができたほうがイイなー。と思うのです。
さらに、ネットワークでエラーが起きた時のためにデータの再送信用のバッファを持っていたのですが、 ここらへんの処理の効率が悪かったので、コノ処理は行わないことにしました。
まー、エラーの訂正とかはTCP/IPのプロトコルでやってくれるので必要なかったのですが、 実際ちんとできてるかチェックのために残っていたのです。
実際接続が多いトキに負荷軽減の効果がどんくらいでるかはやってみないとわかんないトコがあるので、 コノ文章を書いている時点ではよくわかんないのですが、いっぱい効果があるとイイナー...
まー、最終手段としてはサーバを何台か用意して負荷分散させることになると思うのですが、 現在の接続人数くらいは1台のサーバで処理できないとマズイと思うのです。 そのうち戦争とか実装したいので「100人くらいが1カ所に集まって激しく戦闘」くらいは1台のサーバで処理できないと困るのです。
あと、もう一個サーバ負荷を大幅に減らすことができる秘策があるのですが、一部スキルに影響が出るので後回し中。
ちょっと前にサーバ負荷がヤバイことになったんすよ。PvP大会とか大勢が一カ所に集まって激しく戦うとヤバイっす。 なもんで、ちょっくらサーバの負荷を減少させてみました。
去年の6/19日のトコの日記に書いてあるように、 キャラクターやモンスター間で線形リストで視界にいるかどうかを保持しているのですが、まずはコレをSTLにしてみました。
STLだとメモリの確保・解放を1回ごとにやらないでまとめてやるとどっかで見たような気がするので、負荷が低くなるカナー、 と思ったのですが、ほとんど変わらなかったっす。むしろ微妙に遅くなったかも...?(´Д`;)
しょーがないので、次に上記リスト内に距離を保持させて、 攻撃とかの当たり判定である程度距離で足きりして高速化を図ってみました。
それから、負荷が高いのが飛んでくタイプの魔法です。ちょっと進むごとに当たり判定してたので負荷がとても高かったです。 なので、ある程度間隔を置いて当たり判定をさせるようにしました。
でもそれだけだと、魔法が敵をすり抜けちゃったりするので、この場合には、 当たり判定を点と点の距離で行うのでなく線分と点の距離で行うようにしました。
さらに魔法発射時に当たる可能性のある敵のリストを作って以降はそのリストの敵のみと当たり判定をするようにしました。
実際のトコ、他のMMORPGだと負荷が高くなんないように発射した時点で当たり判定とかダメージ計算をしちゃったりするのですが、 やっぱ軌道を見て避けることができたほうがイイなー。と思うのです。
さらに、ネットワークでエラーが起きた時のためにデータの再送信用のバッファを持っていたのですが、 ここらへんの処理の効率が悪かったので、コノ処理は行わないことにしました。
まー、エラーの訂正とかはTCP/IPのプロトコルでやってくれるので必要なかったのですが、 実際ちんとできてるかチェックのために残っていたのです。
実際接続が多いトキに負荷軽減の効果がどんくらいでるかはやってみないとわかんないトコがあるので、 コノ文章を書いている時点ではよくわかんないのですが、いっぱい効果があるとイイナー...
まー、最終手段としてはサーバを何台か用意して負荷分散させることになると思うのですが、 現在の接続人数くらいは1台のサーバで処理できないとマズイと思うのです。 そのうち戦争とか実装したいので「100人くらいが1カ所に集まって激しく戦闘」くらいは1台のサーバで処理できないと困るのです。
あと、もう一個サーバ負荷を大幅に減らすことができる秘策があるのですが、一部スキルに影響が出るので後回し中。
8/13
モンスター思考ルーチン改良中
少し前に敵にぶつかるようになったのですが、敵の方はかまわず突進してきて、重なって動けなくなったりとかするわけなんです。 コレは納得いかないと思うので、敵の方もぶつかるように変更中です。
コレができるようになれば、戦士が敵をブロックして魔法使いや僧侶を守るとか、今後そーいった方向で戦略性を持たせたりできるようになると思います。
ただ、そんなふうにブロックされたら迂回してターゲットに向かっていったりとかしなきゃなんないので、 そこらへんの思考ルーチンがナカナカめんどくさいトコです。まあソコはもうほとんど作っちゃったんですが。
ほんで、せっかくなので、今まで大部分ハードコードしていたモンスターの思考ルーチンを、 パターン化してスクリプトっぽく設定ファイルに記述できるように変更中です。 現在このゲームはモンスターの種類は多くないのですが、結構イロイロなパターンで動くので、纏めるのがタイヘンです。
でもココで纏めておけば、今後モンスターをもっと頭良くしたりとか思考パターンを変更する時に楽になるので、がんがって改良中です。
少し前に敵にぶつかるようになったのですが、敵の方はかまわず突進してきて、重なって動けなくなったりとかするわけなんです。 コレは納得いかないと思うので、敵の方もぶつかるように変更中です。
コレができるようになれば、戦士が敵をブロックして魔法使いや僧侶を守るとか、今後そーいった方向で戦略性を持たせたりできるようになると思います。
ただ、そんなふうにブロックされたら迂回してターゲットに向かっていったりとかしなきゃなんないので、 そこらへんの思考ルーチンがナカナカめんどくさいトコです。まあソコはもうほとんど作っちゃったんですが。
ほんで、せっかくなので、今まで大部分ハードコードしていたモンスターの思考ルーチンを、 パターン化してスクリプトっぽく設定ファイルに記述できるように変更中です。 現在このゲームはモンスターの種類は多くないのですが、結構イロイロなパターンで動くので、纏めるのがタイヘンです。
でもココで纏めておけば、今後モンスターをもっと頭良くしたりとか思考パターンを変更する時に楽になるので、がんがって改良中です。
8/3
合成系の生産システム追加
合成システムを作りました。
なんかメンドクサイシステムなのですが、気温や湿度など周りの状況に応じて火加減を調節したりとか そういう「職人技」を表現できるシステムにしたいのです。(現在は周りの気温とか影響しません。) 攻略サイトで材料等の情報を集めてきて、ポチッと合成ボタン押す、後は運、みたいのはイマイチだと思うので。
今後、生産でしか手に入らない装備とか追加していってメンドクサイのが報われるようにしたいなぁ。 料理についても今は食べることすらできないのですが、そのうち深い意味を持つようにする予定...
合成状況はホントはグラフでなくビジュアルや音で表現したいのですが作るのがタイヘンなので保留です。
合成システムを作りました。
なんかメンドクサイシステムなのですが、気温や湿度など周りの状況に応じて火加減を調節したりとか そういう「職人技」を表現できるシステムにしたいのです。(現在は周りの気温とか影響しません。) 攻略サイトで材料等の情報を集めてきて、ポチッと合成ボタン押す、後は運、みたいのはイマイチだと思うので。
今後、生産でしか手に入らない装備とか追加していってメンドクサイのが報われるようにしたいなぁ。 料理についても今は食べることすらできないのですが、そのうち深い意味を持つようにする予定...
合成状況はホントはグラフでなくビジュアルや音で表現したいのですが作るのがタイヘンなので保留です。
7/29
鯖移動しますた
日記4ヶ月も更新してなかったっす。スマソ。イマイチ書くネタがないんすよコレが。
んで、サイトの鯖を移動してみました。ついでにドメインも取ってみました。
開発ネタとしては、近いうちに生産系で新しい要素を導入予定です。
そんなカンジです。
日記4ヶ月も更新してなかったっす。スマソ。イマイチ書くネタがないんすよコレが。
んで、サイトの鯖を移動してみました。ついでにドメインも取ってみました。
開発ネタとしては、近いうちに生産系で新しい要素を導入予定です。
そんなカンジです。
3/29
男キャラについて
☆ チン マチクタビレタ~
マチクタビレタ~
☆ チン 〃 ∧_∧ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
ヽ ___\(\・∀・) < 男キャラまだー--??
\_/⊂ ⊂_ ) \___________
/ ̄ ̄ ̄ ̄ ̄ ̄ /|
| ̄ ̄ ̄ ̄ ̄ ̄ ̄| |
| 青森りんご |/
っていう意見が多いのですが、まだっす。
今後の拡張も考えてつくらなかなんないし、モーションも多いし、装備も作り直しだし、タイヘンです。
あと女性キャラのモデルも作り直しになります。
進捗はだいたい。
・男性 … モデル(・∀・) モーション(・∀・) 装備(´・ω・`)
・女性 … モデル(`・ω・´) モーション(´・ω・`) 装備(´Д`;)
こんなカンジかな?
あと、制作はオイラが指示しつつ開発チームのモデラーさんに作っていただいてるので、 関係ない新機能が先に搭載されたからとしても、その分男性キャラの導入が遅れるというわけではないです。
それから男性キャラと同時にワイプがあるかどうかというのはまだ未定です。 ワイプは必要最小限にしたいですが、見た目だけでなくて装備とかも刷新されるので、 うまい引き継ぎ方法が無い場合にはワイプもあるかもしれないです。
☆ チン マチクタビレタ~
マチクタビレタ~
☆ チン 〃 ∧_∧ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
ヽ ___\(\・∀・) < 男キャラまだー--??
\_/⊂ ⊂_ ) \___________
/ ̄ ̄ ̄ ̄ ̄ ̄ /|
| ̄ ̄ ̄ ̄ ̄ ̄ ̄| |
| 青森りんご |/
っていう意見が多いのですが、まだっす。
今後の拡張も考えてつくらなかなんないし、モーションも多いし、装備も作り直しだし、タイヘンです。
あと女性キャラのモデルも作り直しになります。
進捗はだいたい。
・男性 … モデル(・∀・) モーション(・∀・) 装備(´・ω・`)
・女性 … モデル(`・ω・´) モーション(´・ω・`) 装備(´Д`;)
こんなカンジかな?
あと、制作はオイラが指示しつつ開発チームのモデラーさんに作っていただいてるので、 関係ない新機能が先に搭載されたからとしても、その分男性キャラの導入が遅れるというわけではないです。
それから男性キャラと同時にワイプがあるかどうかというのはまだ未定です。 ワイプは必要最小限にしたいですが、見た目だけでなくて装備とかも刷新されるので、 うまい引き継ぎ方法が無い場合にはワイプもあるかもしれないです。
こんなかんじ | マッチョとかにしたりとか |
3/15
光回線導入することにしました。3/24に開通予定です。
TEPCOひかり待ってたんだけど微妙にエリア外でいつんなるかワカンナイのでBフレッツにしました。
ってか一端契約したら半年とか一年とか使い続けないと「キャンペーンで無料にした分返せー」とか言われのかと思ってたんだけど、 プロバイダさえ変更しなければスグ他の回線に切り替えてもヘーキだったのでした。 もっと早く導入すればよかったナー。
ここんとこずっと夜は満員だったのですがもっと受け入れ可能になるハズ。 あと、通信量が増えるのを恐れて導入を先延ばししてた機能の追加もできるべさ。
ってか一端契約したら半年とか一年とか使い続けないと「キャンペーンで無料にした分返せー」とか言われのかと思ってたんだけど、 プロバイダさえ変更しなければスグ他の回線に切り替えてもヘーキだったのでした。 もっと早く導入すればよかったナー。
ここんとこずっと夜は満員だったのですがもっと受け入れ可能になるハズ。 あと、通信量が増えるのを恐れて導入を先延ばししてた機能の追加もできるべさ。
1/14
ヽ(´▽`*)ノ
1/12
今年もよろしくですよ
2ヶ月も日記更新してなかった。スマン。そして遅くなりましたがあけおめ。ことよろ。
そうそう、開発のお手伝いしてくれる方が2人増えました。わーい。 うち一人は音楽作ってくれてるので、そのうち公式BGMを公開できるかなー。
せっかくなのでいまさらながら開発メンバーの紹介をするですよ。(加入順)
新プレイヤーキャラはモデル自体はカナリ完成してきたのですが、モーションも作らなくちゃイケナイし 装備も作り直しで、さらにイロイロ調整が必要なのでまだ時間かかりそう...。
ほんで先日「釣り」のベースシステムを導入したので、PKナドの犯罪関係も一応導入可能になりましたね。 そのうち犯罪関係の導入するかもしんないです。
なんで犯罪と釣りが関係するかワカンナイ人もいるかもしれないので説明しときます。
PKなどの犯罪をすると犯罪者になります。そーすっと時効になるまでガードに追われます。 犯罪者は殺しても犯罪にならないので(名声が得られるカモ)他のプレイヤーからも追われたりします。 犯罪者が倒された場合、刑務所として隔離された場所で強制労働させられます。
つまり釣りを強制労働として使えるよーになったので犯罪も導入可能になったワケ。 詳しくは構想/妄想のページを見てください。
ユーザーによって法律を決めるのは戦争の導入までできないですが、戦争の導入はまだ先になりそーですね。 現在のサーバ回線で戦争導入したらラグラグでえらいことになりそうだし。
釣りやクエストについては、種類が少なかったりして奥が浅いのですが、とりあえずはベースになるシステムの 拡充を優先させて奥の深さや豊富さなどの追求は後回しになってしまうかもです。
あと、釣り以外の生産系や職業・スキルなどの追加についてはモーションが必要だったり装備に影響したりする部分があるため 新しいキャラモデルができてからになるのが多いと思います。
2ヶ月も日記更新してなかった。スマン。そして遅くなりましたがあけおめ。ことよろ。
そうそう、開発のお手伝いしてくれる方が2人増えました。わーい。 うち一人は音楽作ってくれてるので、そのうち公式BGMを公開できるかなー。
せっかくなのでいまさらながら開発メンバーの紹介をするですよ。(加入順)
diecon氏 | 3Dモデル担当。デーモンとかのモデルリングはこの方による物。新PCも作ってもらってます。 |
sn50氏 | 2D画(+3Dも)担当。カコイイ絵を描いてくれる。3Dもできて、始まりの村の家とかも作ってもらった。イソガシイらしくこのところ手伝ってもらえないのがツライ。 |
takahashi氏 | 3Dモデル担当。モンスターなどをイパーイ作ってくれてる。ロブロブの怠惰によりゲームにまだ導入してないモデルが貯まってきた。スマソ。 |
qyuser氏 | 音楽担当。新加入。BGMを作ってもらってます。まだお聞かせできないのが残念ですがナカナカイイですよー。 |
未黒氏 | 2D画担当。新加入。sn50氏がイソガシくて2D描ける人材不足になっていたので期待ですよ。 |
新プレイヤーキャラはモデル自体はカナリ完成してきたのですが、モーションも作らなくちゃイケナイし 装備も作り直しで、さらにイロイロ調整が必要なのでまだ時間かかりそう...。
ほんで先日「釣り」のベースシステムを導入したので、PKナドの犯罪関係も一応導入可能になりましたね。 そのうち犯罪関係の導入するかもしんないです。
なんで犯罪と釣りが関係するかワカンナイ人もいるかもしれないので説明しときます。
PKなどの犯罪をすると犯罪者になります。そーすっと時効になるまでガードに追われます。 犯罪者は殺しても犯罪にならないので(名声が得られるカモ)他のプレイヤーからも追われたりします。 犯罪者が倒された場合、刑務所として隔離された場所で強制労働させられます。
つまり釣りを強制労働として使えるよーになったので犯罪も導入可能になったワケ。 詳しくは構想/妄想のページを見てください。
ユーザーによって法律を決めるのは戦争の導入までできないですが、戦争の導入はまだ先になりそーですね。 現在のサーバ回線で戦争導入したらラグラグでえらいことになりそうだし。
釣りやクエストについては、種類が少なかったりして奥が浅いのですが、とりあえずはベースになるシステムの 拡充を優先させて奥の深さや豊富さなどの追求は後回しになってしまうかもです。
あと、釣り以外の生産系や職業・スキルなどの追加についてはモーションが必要だったり装備に影響したりする部分があるため 新しいキャラモデルができてからになるのが多いと思います。
11/5
プレイヤーキャラ用新モデル作ってますよ
要望でヒジョーに多いのが「男キャラ使えるよーにしてくれ」っつーのなんですが、男キャラも作って(もらって)ます。
でも、ただ男キャラのモデルを作るだけでなくて、同時に新しいフィーチャーを盛り込む予定なので、まだだいぶ時間がかかります。 体型が変えたりできるよーにしたりとか、装備まわりの仕様も一新させる予定です。
現在こっち方面の開発を中心にやっていて時間がかかるので、ゲームの新機能追加もマターリペースになりそーです。
新PCを作る予定があったため、装備やスキルの追加を止めてたとゆーのがありまして、 ココらへんができてから装備や職業やスキルの追加とかもする予定です。
まだテクスチャとかあんまりできてないのでシルエット&ハゲで公開します。シルエットだと体型変化がわかりにくいかも...
女性キャラもモデルを作り直します。
キモイキモイいわれてたのでカワイクしたいなぁ...女性の方はまだあんまりできてないのですが...
女性キャラで体型変化っつーと「オパーイの大きさは変えられますか」って質問が必ず来ると思うので答えておきます。 変えられるよーになります。多分ね。
要望でヒジョーに多いのが「男キャラ使えるよーにしてくれ」っつーのなんですが、男キャラも作って(もらって)ます。
でも、ただ男キャラのモデルを作るだけでなくて、同時に新しいフィーチャーを盛り込む予定なので、まだだいぶ時間がかかります。 体型が変えたりできるよーにしたりとか、装備まわりの仕様も一新させる予定です。
現在こっち方面の開発を中心にやっていて時間がかかるので、ゲームの新機能追加もマターリペースになりそーです。
新PCを作る予定があったため、装備やスキルの追加を止めてたとゆーのがありまして、 ココらへんができてから装備や職業やスキルの追加とかもする予定です。
まだテクスチャとかあんまりできてないのでシルエット&ハゲで公開します。シルエットだと体型変化がわかりにくいかも...
女性キャラもモデルを作り直します。
キモイキモイいわれてたのでカワイクしたいなぁ...女性の方はまだあんまりできてないのですが...
女性キャラで体型変化っつーと「オパーイの大きさは変えられますか」って質問が必ず来ると思うので答えておきます。 変えられるよーになります。多分ね。
9/12
フォントの描画
開発日記ぜんぜん書いてなかったスマソ。
今回は技術的なコトとして、ちょっと前に実装した新しいフォント描画ルーチンについて書きます。
全角文字も描画できるフォント描画ルーチンはなかなか悩む人が多いようです。
なので、私が実装した方法と、その他の考えられる方法についてイロイロ書きます。
DirectXに含まれるユーティリティライブラリ(Direct3DX)には「ID3DXFont」っていうフォント描画インターフェースがあります。
以前はコレを使ってました。簡単に使えて良いのですがちょっと問題があります。
まず描画が遅いです。そして環境によって表示されなかったり、文字化けするようです。
単純な実装方法として、全部の文字をテクスチャで用意する方法もあります。
この方法は実装が簡単だし、かなり高速な描画ができるのですが、テクスチャでビデオメモリを大量に消費してしまうトコが欠点です。
テクスチャ圧縮を行うと結構小さくなるそうなのですが、テクスチャ圧縮がサポートされていない環境もあります。
そのような環境の場合はビデオメモリもあまり余裕がない可能性が高い気がして、その場合悲惨なコトになりそーなので採用はやめました。
半角文字だけで良い場合には最も一般的な方法のような気がします。
さらに他の方法としては、オフスクリーンサーフェースを用意し、一端そこに書き込んでから
それをバックバッファに転送する方法があります。
オフスクリーンサーフェースに文字を書き込むのは文章が更新されたときだけでよく、
それ以外の場合は単純な矩形領域の貼り付けで済み、高速です。
この方法は文章が更新されることがそれほど頻繁ではなく、文字表示領域がある程度決まっているような場合には有効だと思います。
例えばビジュアルノベルとか。
ウチのMMOの場合はいろんなトコに文字が表示されて更新チェックとかつらそーだし、コレまた不採用になりました。
ウチのヤツはユーザーインターフェースはWindowsっぽいので、応用して各ウィンドウごとにオフスクリーンサーフェースを作り、
ボタンとかの構成要素も厳密に規定して更新チェックを行い、WindowsAPIのようなシステムを作れば
ウィンドウ描画全般が速くなると思います。でも自由度下がるしメモリ喰いそうだし...正直に言うとそんなの作るのメンドクサイです。
イロイロ引っ張ってきましたが、今回使った方法を書きます。
まず半角文字は普通にぜんぶの文字が書かれたテクスチャを用意して普通に描画します。
mmoでは半角文字は6*12pixelなので、128*128のテクスチャに余裕で収まります。(空きがあるので外字とかに使う予定)
そんで全角文字ですが、まず文字データを用意してメインメモリに読み込みます。2値データなのでメモリはほとんど使わないです。
そして、オフスクリーンサーフェースを用意します。今回は256*256のサイズにしました。
全角文字を描画する時には2値データを元にオフスクリーンサーフェースに1文字ごとに描画、それをバックバッファに転送します。
ただし、オフスクリーンサーフェースには文字ごとに別の領域に書くため、以前描いた文字は新しく描く必要が無いです。
描く領域が無くなってしまったらしょうがないので、最も古く、使ってない領域にある文字を破棄して上書きします。
256*256のサイズなので12ドットフォントが441種類(21*21)バッファリングできます。
なので画面内に全角文字が441種類以下の場合には最初しかオフスクリーンサーフェースのロックが必要無いので高速です。
全角文字出現率はひらがななどに集中するので441種以上同時に表示されることはまず無いと思います。
文字がバッファにあるかどうかのチェックとか、バッファがいっぱいになった時にどの文字を消すべきかの判定などを
高速に行うコーディングがちょっとめんどくさそうな感じがしましたが、実際に作ってみるとそんなにタイヘンでもなかったです。
まだ最適化できる部分が残っているのですがそれでも結構速いです。どんくらい速いかは環境によるんで表現しにくいのですが、
ID3DXFontと比べるて、全角文字が411種以下の場合には、「カナリ速い」~「超速い」くらい。
411種以上の時でも「少し速い」~「カナリ速い」くらいでした。わかりにくいか。
AthlonXP2600+、GF4 4200Tiという私のメインマシンでは、全角が411種以下の場合は10倍程度の速度が出ているようです。
ゲームでは文字描画以外の部分が重いので速くなったようには感じないと思いますが...(´Д`;)
読み返してみたらめっさ長文になってる...図もないしわかりにくいな...スマソ
開発日記ぜんぜん書いてなかったスマソ。
今回は技術的なコトとして、ちょっと前に実装した新しいフォント描画ルーチンについて書きます。
全角文字も描画できるフォント描画ルーチンはなかなか悩む人が多いようです。
なので、私が実装した方法と、その他の考えられる方法についてイロイロ書きます。
DirectXに含まれるユーティリティライブラリ(Direct3DX)には「ID3DXFont」っていうフォント描画インターフェースがあります。
以前はコレを使ってました。簡単に使えて良いのですがちょっと問題があります。
まず描画が遅いです。そして環境によって表示されなかったり、文字化けするようです。
単純な実装方法として、全部の文字をテクスチャで用意する方法もあります。
この方法は実装が簡単だし、かなり高速な描画ができるのですが、テクスチャでビデオメモリを大量に消費してしまうトコが欠点です。
テクスチャ圧縮を行うと結構小さくなるそうなのですが、テクスチャ圧縮がサポートされていない環境もあります。
そのような環境の場合はビデオメモリもあまり余裕がない可能性が高い気がして、その場合悲惨なコトになりそーなので採用はやめました。
半角文字だけで良い場合には最も一般的な方法のような気がします。
さらに他の方法としては、オフスクリーンサーフェースを用意し、一端そこに書き込んでから
それをバックバッファに転送する方法があります。
オフスクリーンサーフェースに文字を書き込むのは文章が更新されたときだけでよく、
それ以外の場合は単純な矩形領域の貼り付けで済み、高速です。
この方法は文章が更新されることがそれほど頻繁ではなく、文字表示領域がある程度決まっているような場合には有効だと思います。
例えばビジュアルノベルとか。
ウチのMMOの場合はいろんなトコに文字が表示されて更新チェックとかつらそーだし、コレまた不採用になりました。
ウチのヤツはユーザーインターフェースはWindowsっぽいので、応用して各ウィンドウごとにオフスクリーンサーフェースを作り、
ボタンとかの構成要素も厳密に規定して更新チェックを行い、WindowsAPIのようなシステムを作れば
ウィンドウ描画全般が速くなると思います。でも自由度下がるしメモリ喰いそうだし...正直に言うとそんなの作るのメンドクサイです。
イロイロ引っ張ってきましたが、今回使った方法を書きます。
まず半角文字は普通にぜんぶの文字が書かれたテクスチャを用意して普通に描画します。
mmoでは半角文字は6*12pixelなので、128*128のテクスチャに余裕で収まります。(空きがあるので外字とかに使う予定)
そんで全角文字ですが、まず文字データを用意してメインメモリに読み込みます。2値データなのでメモリはほとんど使わないです。
そして、オフスクリーンサーフェースを用意します。今回は256*256のサイズにしました。
全角文字を描画する時には2値データを元にオフスクリーンサーフェースに1文字ごとに描画、それをバックバッファに転送します。
ただし、オフスクリーンサーフェースには文字ごとに別の領域に書くため、以前描いた文字は新しく描く必要が無いです。
描く領域が無くなってしまったらしょうがないので、最も古く、使ってない領域にある文字を破棄して上書きします。
256*256のサイズなので12ドットフォントが441種類(21*21)バッファリングできます。
なので画面内に全角文字が441種類以下の場合には最初しかオフスクリーンサーフェースのロックが必要無いので高速です。
全角文字出現率はひらがななどに集中するので441種以上同時に表示されることはまず無いと思います。
文字がバッファにあるかどうかのチェックとか、バッファがいっぱいになった時にどの文字を消すべきかの判定などを
高速に行うコーディングがちょっとめんどくさそうな感じがしましたが、実際に作ってみるとそんなにタイヘンでもなかったです。
まだ最適化できる部分が残っているのですがそれでも結構速いです。どんくらい速いかは環境によるんで表現しにくいのですが、
ID3DXFontと比べるて、全角文字が411種以下の場合には、「カナリ速い」~「超速い」くらい。
411種以上の時でも「少し速い」~「カナリ速い」くらいでした。わかりにくいか。
AthlonXP2600+、GF4 4200Tiという私のメインマシンでは、全角が411種以下の場合は10倍程度の速度が出ているようです。
ゲームでは文字描画以外の部分が重いので速くなったようには感じないと思いますが...(´Д`;)
読み返してみたらめっさ長文になってる...図もないしわかりにくいな...スマソ
7/15
負荷がぁー( ´Д⊂ヽ
先日マップ拡張を行ったのですが、サーバ負荷が発生してエライコトになってました。
原因がなかなかわかんなかったし...。マップの拡張はしたわけなんですが、ソースコード自体はほとんど手を加えてなかったので、
なぜそんなにも負荷が上昇したのかわからんかったのですよ。
サーバプログラムではおおざっぱに、どの部分でどの程度のCPUリソースを使っているか表示されるようになっているのですが、
基本的にモンスターが増えたぶんの負荷上昇だけのはずだったのに、なぜかプレイヤー関係の負荷が異常に上昇している...
バージョンアップで変更した部分をもとにもどしてみたりとかしてみたのですが、一向に変化ナシ...(´Д`;)
よくわかんねーから、とりあえず高速なマシンで鯖稼働させて時間を稼ごうとしたら、そのマシンのパフォーマンスがぜんぜん出ない...
泣きそーになりながら、各処理にかかっている時間を詳細に調べて負荷部分の特定をしました。
結局負荷の原因は、プレイヤーとドアが近くにあるかどうかを判定するルーチン内部にマップの面積に比例するコードが
含まれていたことによるものでした。
バージョンアップ前のソースにも含まれていたのですが、マップがそれほど広くなかったから問題になってなかったのでした。
修正を加えたトコロびっくりするほどに軽くなりました。バージョンアップ前よりもだいぶ軽くなってしまいました。
こんだけ軽くなったら、イロイロ複雑な処理を追加してもヘーキだなー。どっちにしろ帯域の上限が先にくるし。
やっと機能の追加ができるかな。
ちなみに時間稼ぎに用意したPCのパフォーマンスが出ないのは、負荷位置特定のためにインストールしてみたソフト(体験版)が
悪さしてたっぽいです。アンインストールしてからSuperπで測定してみたら、現在の鯖マシンの2倍ちょっとの速度がでました。速い!!
先日マップ拡張を行ったのですが、サーバ負荷が発生してエライコトになってました。
原因がなかなかわかんなかったし...。マップの拡張はしたわけなんですが、ソースコード自体はほとんど手を加えてなかったので、
なぜそんなにも負荷が上昇したのかわからんかったのですよ。
サーバプログラムではおおざっぱに、どの部分でどの程度のCPUリソースを使っているか表示されるようになっているのですが、
基本的にモンスターが増えたぶんの負荷上昇だけのはずだったのに、なぜかプレイヤー関係の負荷が異常に上昇している...
バージョンアップで変更した部分をもとにもどしてみたりとかしてみたのですが、一向に変化ナシ...(´Д`;)
よくわかんねーから、とりあえず高速なマシンで鯖稼働させて時間を稼ごうとしたら、そのマシンのパフォーマンスがぜんぜん出ない...
泣きそーになりながら、各処理にかかっている時間を詳細に調べて負荷部分の特定をしました。
結局負荷の原因は、プレイヤーとドアが近くにあるかどうかを判定するルーチン内部にマップの面積に比例するコードが
含まれていたことによるものでした。
バージョンアップ前のソースにも含まれていたのですが、マップがそれほど広くなかったから問題になってなかったのでした。
修正を加えたトコロびっくりするほどに軽くなりました。バージョンアップ前よりもだいぶ軽くなってしまいました。
こんだけ軽くなったら、イロイロ複雑な処理を追加してもヘーキだなー。どっちにしろ帯域の上限が先にくるし。
やっと機能の追加ができるかな。
ちなみに時間稼ぎに用意したPCのパフォーマンスが出ないのは、負荷位置特定のためにインストールしてみたソフト(体験版)が
悪さしてたっぽいです。アンインストールしてからSuperπで測定してみたら、現在の鯖マシンの2倍ちょっとの速度がでました。速い!!
7/8
マップだいたいでけた!
マップの新規拡張部分がほぼできました。あとは細かい調整とテストというトコ。
マップ拡張でモンスターの数が増えて最大接続数も少し増やそうと思っているので、今の鯖PCで耐えられるかビミョー。
他のPCに鯖移そうかどうか悩み中。ちょうどWin2KSP4が出たトコなのでOSの再インスコには良いタイミングではあるのだが...
マップの拡張しても新しい機能が追加されるわけじゃないしあんま面白くないので、
早くケリつけて面白い機能をイロイロ追加したいなぁ...
マップの新規拡張部分がほぼできました。あとは細かい調整とテストというトコ。
マップ拡張でモンスターの数が増えて最大接続数も少し増やそうと思っているので、今の鯖PCで耐えられるかビミョー。
他のPCに鯖移そうかどうか悩み中。ちょうどWin2KSP4が出たトコなのでOSの再インスコには良いタイミングではあるのだが...
マップの拡張しても新しい機能が追加されるわけじゃないしあんま面白くないので、
早くケリつけて面白い機能をイロイロ追加したいなぁ...
7/5
マップ作成中
マップ作成中です。あとは少し整地して、町を作って、モンスターの発生エリアの指定ってトコかなー。
混雑緩和のために早くリリースしたい気分なので、とりあえず町とか超テキトーになってしまう可能性大(´Д`;)
マップ作成中です。あとは少し整地して、町を作って、モンスターの発生エリアの指定ってトコかなー。
混雑緩和のために早くリリースしたい気分なので、とりあえず町とか超テキトーになってしまう可能性大(´Д`;)
6/25
引き続き改良中ー。
6/24
マップエディター改良
マップエディターででっかいマップを扱えるよーな仕組みを作りました。
クライアントでは必要な部分を逐次読み込むような仕組みになってるので、それをマップエディター用に修正したら
思ったより手間がかからなかったです。
まだちょっと不足している機能があるので、ソレをマップエディタに組み込んだら、
せこせこマップ作成に勤しみたいと思います。
とりあえずマップを2倍くらいにして、モンスターも2倍くらいにして、最大接続人数を1.5倍にしたら
人大杉状態もちょっとは緩和されるカナーと思ってます。
現在の回線だと150人くらいが限度カナーとゆーところ。200人だと負荷が高い時にそーとーラグが激しくなりそー。
CPU負荷の方は、メインマシンの他にCeleron1.4Gマシンもあるし、AthlonXP1800+がころがってたりするので
なんとかしよーと思えばなんとかなると思うんだけど...。
んでも光回線の導入は、もーしばらく様子を見たいんす。TEPCOひかりとか速そーだからエリアに入んないかなー...
マップエディターででっかいマップを扱えるよーな仕組みを作りました。
クライアントでは必要な部分を逐次読み込むような仕組みになってるので、それをマップエディター用に修正したら
思ったより手間がかからなかったです。
まだちょっと不足している機能があるので、ソレをマップエディタに組み込んだら、
せこせこマップ作成に勤しみたいと思います。
とりあえずマップを2倍くらいにして、モンスターも2倍くらいにして、最大接続人数を1.5倍にしたら
人大杉状態もちょっとは緩和されるカナーと思ってます。
現在の回線だと150人くらいが限度カナーとゆーところ。200人だと負荷が高い時にそーとーラグが激しくなりそー。
CPU負荷の方は、メインマシンの他にCeleron1.4Gマシンもあるし、AthlonXP1800+がころがってたりするので
なんとかしよーと思えばなんとかなると思うんだけど...。
んでも光回線の導入は、もーしばらく様子を見たいんす。TEPCOひかりとか速そーだからエリアに入んないかなー...
6/23
メモリ使い杉
えーと、今マップの拡張作業を行っているんです。5/26の日記にも書きましたけど。
今の島はマップ全体がだいたい1km四方なんですけど、約8km四方になる予定です。
ほんで島の起伏はペイントソフトでテキトーに自動生成した画像を元に手を加える、というよーに作ってるんですが、
マップエディタに元の画像を読み込んで変換させてみたら、メモリが足んねー。
メモリ1ギガもあるのにみるみる減っていってブルースクリーンになりますた(´Д`;)
クライアントとサーバ用にはちょっとづつマップを追加する予定で、
さらにクライアントでは自分の近くのマップのみをロードするのが既に実装されていて、
サーバはテクスチャとかの情報が必要無いんでデータ量が少ないんですが、問題はマップエディタなんす。
広い範囲を見ながら編集したいし、テクスチャ等のクライアント用の部分も同時に編集するようになってるし...
必要な部分を必要に時にロードするよーにマップエディターを改良しなければー。というトコロ。
ここんとこ混雑していて申し訳ないっす。「ゲームの完成度が低いから1週間くらいしたら落ち着くかなー」とか
思ってたんですけど、なんかじわじわ増えてるような...
マップ拡張を含めて多くの人に遊んでもらえるような対策も進めていこうと思います。
ただ、対応するにはやっぱり時間が必要なのでしばらく待ってください。おながいします。
えーと、今マップの拡張作業を行っているんです。5/26の日記にも書きましたけど。
今の島はマップ全体がだいたい1km四方なんですけど、約8km四方になる予定です。
ほんで島の起伏はペイントソフトでテキトーに自動生成した画像を元に手を加える、というよーに作ってるんですが、
マップエディタに元の画像を読み込んで変換させてみたら、メモリが足んねー。
メモリ1ギガもあるのにみるみる減っていってブルースクリーンになりますた(´Д`;)
クライアントとサーバ用にはちょっとづつマップを追加する予定で、
さらにクライアントでは自分の近くのマップのみをロードするのが既に実装されていて、
サーバはテクスチャとかの情報が必要無いんでデータ量が少ないんですが、問題はマップエディタなんす。
広い範囲を見ながら編集したいし、テクスチャ等のクライアント用の部分も同時に編集するようになってるし...
必要な部分を必要に時にロードするよーにマップエディターを改良しなければー。というトコロ。
ここんとこ混雑していて申し訳ないっす。「ゲームの完成度が低いから1週間くらいしたら落ち着くかなー」とか
思ってたんですけど、なんかじわじわ増えてるような...
マップ拡張を含めて多くの人に遊んでもらえるような対策も進めていこうと思います。
ただ、対応するにはやっぱり時間が必要なのでしばらく待ってください。おながいします。
6/19
線形リストまみれ
今後マップの拡張とかするし、将来的には光回線を導入したいのですが、そーしたら帯域20倍くらいになって
帯域的には10倍くらいの1000人規模もいけるんじゃねーの?とか夢が広がるわけですよ。
ほんで現在鯖マシンはP!!!600MhzというクソPC上でさらにデバッグモードで稼働させているんで、
最新のCPUでリリースモードで稼働させたら数倍の処理能力を得ることができると思うのですが、
数倍の処理能力だから数倍の人数に対応できるとは限らないわけなんす。
処理によっては規模に比例するのではなく規模の2乗に比例してしまったりするんです。
典型的な例としては当たり判定ですね。100個の物どーしの当たり判定は100*100の計算が必要になるわけです。
「敵足りないんじゃボケ」って言われてる現状でも敵は500匹くらいいるんで、
さらに規模が大きくなったらえらいことになるわけです。
もちろん現状でもここらへんの処理は最適化していて、数の2乗に比例してしまうようなことが無いように
設計しているのです。具体的にはどうなっているかというと、互いに影響を与える可能性があるかどうかという
フラグを保持していて、影響を与える可能性がない場合には処理をすっとばすようにしているのです。
なのですが、この方法にも問題があるのです。まず、メモリの使用効率が悪いということです。
m個の物とn個の物の影響フラグはm*n個になってしまいます。また、影響フラグのチェックは高速ですが
全ての組み合わせで行う必要があるので、全体に対して影響を与える物の割合が非常に低い場合には
速度的にも効率が悪くなる恐れがあります。
6/15の日記で書いたように動的なオブジェクト全てを一元的に管理するように設計を変更しつつあるので、
影響フラグも全ての動的オブジェクト同士で保持したいトコです。が、数が増えてしまうと、
上記の非効率性が増大することが予想されます。
なもんで、影響を与えるオブジェクトを線形リストで保持するように処理を変更してみました。
さらに、効率化のためにオブジェクト同士のみでなく、マップ上の細かいゾーンごとにも関連オブジェクトの
線形リストを保持するようにしました。さらにその他の処理でも、動的な部分は配列を使用しないで
線形リストを使用するようにして最大保持数等の制限が出ないようにしてみました。
線形リストまみれです。
またしても根本的な部分にかなり多くの手を加えたので、この前の変更と合わせると
サーバ側プログラムの基礎部分はほとんど全ての箇所に変更が加えられたような感じになってしまいました。
バグがいっぱい潜んでそうでコワイです。
っていうか線形リストはデバグしにくいトコがあるもんで、さっき出たバグでちょっと泣きそうになりました。
まあ、無事修正できてヨカッタわけなんですが。
あまりにも変更を加えすぎてしまったので、バグとか心配だし、負荷なんかも予想できなくなってしまったので
近いうちにリリースする次バージョンでは、機能の追加はナシで、チェックをしようと思ってます。
申し訳ない。ココを通過できればいろんな機能追加に向けて弾みがつくんでカンベンしてけろ。
今後マップの拡張とかするし、将来的には光回線を導入したいのですが、そーしたら帯域20倍くらいになって
帯域的には10倍くらいの1000人規模もいけるんじゃねーの?とか夢が広がるわけですよ。
ほんで現在鯖マシンはP!!!600MhzというクソPC上でさらにデバッグモードで稼働させているんで、
最新のCPUでリリースモードで稼働させたら数倍の処理能力を得ることができると思うのですが、
数倍の処理能力だから数倍の人数に対応できるとは限らないわけなんす。
処理によっては規模に比例するのではなく規模の2乗に比例してしまったりするんです。
典型的な例としては当たり判定ですね。100個の物どーしの当たり判定は100*100の計算が必要になるわけです。
「敵足りないんじゃボケ」って言われてる現状でも敵は500匹くらいいるんで、
さらに規模が大きくなったらえらいことになるわけです。
もちろん現状でもここらへんの処理は最適化していて、数の2乗に比例してしまうようなことが無いように
設計しているのです。具体的にはどうなっているかというと、互いに影響を与える可能性があるかどうかという
フラグを保持していて、影響を与える可能性がない場合には処理をすっとばすようにしているのです。
なのですが、この方法にも問題があるのです。まず、メモリの使用効率が悪いということです。
m個の物とn個の物の影響フラグはm*n個になってしまいます。また、影響フラグのチェックは高速ですが
全ての組み合わせで行う必要があるので、全体に対して影響を与える物の割合が非常に低い場合には
速度的にも効率が悪くなる恐れがあります。
6/15の日記で書いたように動的なオブジェクト全てを一元的に管理するように設計を変更しつつあるので、
影響フラグも全ての動的オブジェクト同士で保持したいトコです。が、数が増えてしまうと、
上記の非効率性が増大することが予想されます。
なもんで、影響を与えるオブジェクトを線形リストで保持するように処理を変更してみました。
さらに、効率化のためにオブジェクト同士のみでなく、マップ上の細かいゾーンごとにも関連オブジェクトの
線形リストを保持するようにしました。さらにその他の処理でも、動的な部分は配列を使用しないで
線形リストを使用するようにして最大保持数等の制限が出ないようにしてみました。
線形リストまみれです。
またしても根本的な部分にかなり多くの手を加えたので、この前の変更と合わせると
サーバ側プログラムの基礎部分はほとんど全ての箇所に変更が加えられたような感じになってしまいました。
バグがいっぱい潜んでそうでコワイです。
っていうか線形リストはデバグしにくいトコがあるもんで、さっき出たバグでちょっと泣きそうになりました。
まあ、無事修正できてヨカッタわけなんですが。
あまりにも変更を加えすぎてしまったので、バグとか心配だし、負荷なんかも予想できなくなってしまったので
近いうちにリリースする次バージョンでは、機能の追加はナシで、チェックをしようと思ってます。
申し訳ない。ココを通過できればいろんな機能追加に向けて弾みがつくんでカンベンしてけろ。
6/15
クラスってステキ
前回(ver0.00152)のバージョンにはマップが拡張された場合でも(クライアントでは)メモリ使用量が
増えないような管理方法を導入したのですが、今はプレイヤーやモンスターの管理部分に手を加えてみてます。
当初は最小限の変更でマップ拡張にのみ対応するようにしようと思ったのですが、
いい機会なので、プレイヤーやモンスターなど動的なオブジェクトを共通に扱える
抽象度の高いクラスを複数のレイヤで管理できるようにすることにしました。
とりあえずは、マップ拡張のための管理に使うので手間の割に恩恵が少ないように思われてしまうかも
なのですが、将来的には「NPCが動いたり攻撃したりする」「モンスターの行動パターンを増やす」
「モンスターをテイムする」「ペットを飼う」「地面に物を置けるようにする」「資源を収集する」...
など非常に広範囲の機能を、ぐっとラク実装できるようになるので、導入することにしました。
こういうのを作る時にはクラスは便利なものだなぁ、と改めて思いました。
かなり根本的な部分にも大幅に手をいれたので、メタメタになって動作しなくなるのが心配だったのですが、
とりあえず、いままで実装した機能が一通り動作する程度に再構築できたかんじです。
まだ実装が甘い部分がいろいろ残ってるので、さらに手をいれなくちゃなんないのですが...
ここ何日かで人が増えたので、狩り場が足りない状態のトキが多いと思うのですが
いま言ったあたりの実装が完了したら、心おきなくマップの拡張を行えるので、もーちょっと待ってください。
それはそーと、なんとなく現在のソースコードの行数を数えてみました。
クライアントが59ファイルで約4万7千行、サーバが34ファイルで約2万7千行でした。
(cppファイルのみ、一部共通部分アリ)
うーん、比べる物が無いので多いのか少ないのかよくわかりません...
とりあえず1年けっこうがんばった気がするので、結構がんばったコトにしといてください。
前回(ver0.00152)のバージョンにはマップが拡張された場合でも(クライアントでは)メモリ使用量が
増えないような管理方法を導入したのですが、今はプレイヤーやモンスターの管理部分に手を加えてみてます。
当初は最小限の変更でマップ拡張にのみ対応するようにしようと思ったのですが、
いい機会なので、プレイヤーやモンスターなど動的なオブジェクトを共通に扱える
抽象度の高いクラスを複数のレイヤで管理できるようにすることにしました。
とりあえずは、マップ拡張のための管理に使うので手間の割に恩恵が少ないように思われてしまうかも
なのですが、将来的には「NPCが動いたり攻撃したりする」「モンスターの行動パターンを増やす」
「モンスターをテイムする」「ペットを飼う」「地面に物を置けるようにする」「資源を収集する」...
など非常に広範囲の機能を、ぐっとラク実装できるようになるので、導入することにしました。
こういうのを作る時にはクラスは便利なものだなぁ、と改めて思いました。
かなり根本的な部分にも大幅に手をいれたので、メタメタになって動作しなくなるのが心配だったのですが、
とりあえず、いままで実装した機能が一通り動作する程度に再構築できたかんじです。
まだ実装が甘い部分がいろいろ残ってるので、さらに手をいれなくちゃなんないのですが...
ここ何日かで人が増えたので、狩り場が足りない状態のトキが多いと思うのですが
いま言ったあたりの実装が完了したら、心おきなくマップの拡張を行えるので、もーちょっと待ってください。
それはそーと、なんとなく現在のソースコードの行数を数えてみました。
クライアントが59ファイルで約4万7千行、サーバが34ファイルで約2万7千行でした。
(cppファイルのみ、一部共通部分アリ)
うーん、比べる物が無いので多いのか少ないのかよくわかりません...
とりあえず1年けっこうがんばった気がするので、結構がんばったコトにしといてください。
6/1
PC制作準備中
よくいただく要望として「装備もっと増やせ」とか「スキルもっと増やせ」ってのがあるのですが、
とりあえずこれらはしばらく追加されないと思います。
理由の一つは前から言っているのですが、システムのベース部分を先に進めておきたいということ。
んで実はもう一つ理由があって、プレイキャラクターのモデルの刷新をしようと思っているのです。
今、装備・スキルを追加すると、後から装備のモデル・スキルのモーションを
作り直すことになってしまい、無駄が出てしまうので、後まわしにしているのです。
現在はデザインを描いてもらったり、仕様を詰めてるという初期段階なので
ゲームに実装されるにはまだまだ時間がかかると思うのですが、
カッコイイ/カワイイキャラになりそうな予感!
それから、今のモデルは無駄にポリゴンを使いすぎているので、
ポリゴン削減・描画の最適化で軽くしたいです。
んで、ここ何日かは、マップの部分読み込みができるように、マップデータ構造の変更などを
やってました。データ構造の変更はだいたい終わったので、クライアントが必要に応じて動的に
マップを読み込む部分を作ればこのへんはひとまず一段落というカンジです。
よくいただく要望として「装備もっと増やせ」とか「スキルもっと増やせ」ってのがあるのですが、
とりあえずこれらはしばらく追加されないと思います。
理由の一つは前から言っているのですが、システムのベース部分を先に進めておきたいということ。
んで実はもう一つ理由があって、プレイキャラクターのモデルの刷新をしようと思っているのです。
今、装備・スキルを追加すると、後から装備のモデル・スキルのモーションを
作り直すことになってしまい、無駄が出てしまうので、後まわしにしているのです。
現在はデザインを描いてもらったり、仕様を詰めてるという初期段階なので
ゲームに実装されるにはまだまだ時間がかかると思うのですが、
カッコイイ/カワイイキャラになりそうな予感!
それから、今のモデルは無駄にポリゴンを使いすぎているので、
ポリゴン削減・描画の最適化で軽くしたいです。
んで、ここ何日かは、マップの部分読み込みができるように、マップデータ構造の変更などを
やってました。データ構造の変更はだいたい終わったので、クライアントが必要に応じて動的に
マップを読み込む部分を作ればこのへんはひとまず一段落というカンジです。
5/26
マップ
今後マップを広くしていかなきゃならんと思うわけですよ。
とりあえず今のマップは配置するスペースがなくなりつつあるし
ほんでテキトーにマップのアウトラインを作ってみたわけなんす。(青いトコが今の島)
物流で経済が発生するにはこれくらい広くないと...と思うわけです。
しかしコレだと計算してみると、マップデータの容量が200Mくらいになってしまうのである。Σ(゚ロ゚ノ)ノ
とりあえず少しずつ追加していくとして、レン鯖のことも考えないといけないなー。
今後マップを広くしていかなきゃならんと思うわけですよ。
とりあえず今のマップは配置するスペースがなくなりつつあるし
ほんでテキトーにマップのアウトラインを作ってみたわけなんす。(青いトコが今の島)
物流で経済が発生するにはこれくらい広くないと...と思うわけです。
しかしコレだと計算してみると、マップデータの容量が200Mくらいになってしまうのである。Σ(゚ロ゚ノ)ノ
とりあえず少しずつ追加していくとして、レン鯖のことも考えないといけないなー。