資料館/ネトゲ製作/001

Last-modified: 2008-10-02 (木) 00:39:11

計画を立てよう

用意するもの

さて、実際にゲームを作るぞ。その前に色々必要なものがあるので用意しよう。

  • WindowsPC
    • HSP3はWindowsじゃ無いと動かないしね
    • 俺はXPpro
  • HSP
    • 3.x系を利用する。どうしても2.xを使いたい天邪鬼は各自脳内補完するように
  • PCBnet2

大まかな手順

ゲームを作るうえで大まかな手順を考えよう。

  1. ゲームの計画を立てる
    • どんなゲームを作るか
  2. 必要なネットワークの計画を立てる
    • 通信をどのようにゲームに組み込むか
    • 通信頻度、速度、プロトコルなど
  3. ゲーム部分を作る
  4. 通信機能を実装する
    • 自分のパソコンで2個起動し、テストしながら作成
    • ローカルネットワークが構築できれば2PC以上でテスト
  5. 友達に配布するなりして、ネットワークテスト
    • ローカルで動かないものはまず友達のPCでも動かん
  6. おしまい

ゲームの計画を立てる

どんなゲームを作るか考えよう。自分の実力と理想の掛け算で決めてくれ。
この講座では、以下のふたつで行こうかと思ってる。あくまで予定。

  • ターン制のパズルゲーム
  • リアルタイム通信を行うアクションゲーム





理由は、実際PCBnet2を理解するにあたって俺は上記二つを作ったから、それだけ。*1
まずターン制という、比較的通信頻度や難易度が簡単なものをつくり、その後発展系ということでアクションゲームを作成する。大多数のチルドレン達はリアルタイム通信のアクションゲームをいきなり作りたいようだが、まずは簡単なものからステップアップしていくべきだ。いうなればターン制ゲームはネット対戦のバイエルといえよう。




なお、ちるどれん達の中にはMMORPGをHSPで作るお!!という大いなる無謀な野望を抱えている勇者が居るかもしれない。が、本講座を読めば読むほどその野望は粉々に打ち砕かれていくであろうことを先に述べておく。クライアントはHSPでも何でもいいと思うが、サーバーをHSPで組むのはかなり蛮勇といわざるを得ない。モノホンのプロフェッショナルも居るが、他の言語を選択することが殆どだろう。

ネットワークの計画を立てる

大まかにゲームの内容を決めたら如何にしてネットワーク通信を行うか決めよう。今の段階で最低限決める事は

  • 何人と通信するか
  • 接続と処理形態はどうするか
  • どのくらいの頻度で通信するか
  • TCP or UDPどっちを使うか

くらいだと思う。ゲームの概要も頭に入っているなら

  • どのようなデータを送るのか
  • どのくらいのサイズのデータを一度に送るのか
  • 確立する経路の本数

等も決めておくと、後々メロディースッキリするのではないだろうか。

何人と通信するのか

何人と対戦するのか?という問題と完全にイコールでは無い点に注意。
例えば1vs1のパズルゲームでも、観戦者を許可する場合もあるだろう。この場合は対戦相手と観戦者で送るデータを変える必要もあるはずだ。
ちなみにWORZは最大6人でプレイできるので、自分を除いた5人と通信している事になる。

接続の処理形態はどうするのか

これは、どの程度処理を依存しあうのか、という問題である。大きく二通りの形態がある。

  • ピアツーピア方式
    • 相手と自分がやれるところはやり、結果を送信しあう。
  • クライアントサーバー方式
    • 誰か一人が処理を行い、結果を全員に送信する。

それぞれに利点と欠点がある。
ピアツーピアの場合、全体の処理をお互いが分割して行う感じになるので、基本的に一人一人の負担が軽い。また、接続部分など細かい違いはあれど基本的にお互いの処理部分は共通であるので、比較的作業量が少ない。ただし欠点として、全員と通信経路を確立しなければならない。お互いの作業結果をお互いに送信しあうためだ。そのため通信の管理は複雑になるかもしれない。
クライアントサーバーの場合、送られてきたデータを元にサーバー役が全ての処理を行い、結果を全員に送信する。個々のクライアントはお互いに通信する必要はないので、クライアントから見れば常にサーバーとだけ通信を行っているため、クライアント側の管理は単純だと思う。また、サーバーと経路を確立する分には自分のポート解放は必須でない場合が多く、クライアントはポート解放しなくても良い(事がある)というのも、ルーターに敗北したチルドレン達には心強い。反面、サーバー役に処理が集中してしまう、処理を行うサーバー、結果を元に表示するクライアント、というまったく別のプログラムを書く必要がある、といった欠点を持つ。


どちらを選ぶのかはある程度ゲームの種類にも拠る。

どのくらいの頻度で通信するのか

極めて重要、マストといってもいいくらい外せない事柄。例え僅かなデータ量であっても300回/秒というようなフザけた通信頻度では意味が無い。これもある程度ゲーム性に影響される場合が多いが、実装如何によってはかなり下げる事が可能。兎に角可能な限り低く、しかしゲーム性を損なわぬよう配慮しなければならない。


まあ・・・困ったらとりあえず毎フレーム送信しちゃってもいいと思う。

TCPとUDPどっちにするか

ごちゃごちゃレイヤーの話を出すつもりは無い。知りたい人は脚注でも見てくれ。*2


適当にかいつまんで説明すると、俺達がゲームを作るうえでデータの送信方式が2種類あって

  • TCP
    • データが壊れてないかチェックし、相手に届いたかどうか確認するため正確*3
    • 遅い
  • UDP
    • 送ったら終了
    • 早い

という相反する性能を持ってるってコト。
TCP通信はデータを送る際、あらかじめ通信経路を確立する。相手までの道程を確認し、ファイルを確実に送信するわけだ。さらに、相手がデータを受け取った事を確認する。実際TCP通信には、「おい、届いた?連絡くらいよこせよ。」「忙しくて忘れてた。届いたよ。」という、下宿している学生なら経験した事があるであろうやり取りがなされている。この確認等に余計な処理を行うため、比較的遅いといわれている。

一方UDP通信は、送ったら終了。それも、自分の手から離れたら終了。相手にデータが届いたかどうかなんてまるで確認しやしない。兎に角手数で勝負である。兎に角速さが要求される場面で利用される。




どっちを使うか迷う程度ならTCPを使っておくべき。UDP通信なんて下手にやるもんじゃない。ホント。泣きを見るって。俺は泣いたよ。

総評

それじゃあ次回から実際に通信を行ってみるが、コンテストが近くなってきたし、ネットの調整がなんかうまくいってきたので暫く休むぜ。アデュー。


*1 といっても後者はWORZ。前者はあまりに恥ずかしい出来なのでうpできない^^;この講座中に作り直したい
*2 OSI参照モデル。此処を読んだだけで10を知るような天才は今すぐネットワーク技術者になれ
*3 根幹にあるIPが適当であるため、このIPでどうにか正確な通信を行うために作られたという話がある