ホームページ >バックエンド開発 >PHPチュートリアル >Web ゲーム用のプライベートチャットとメガホンを作成するというアイデアについて話し合いましょう。

Web ゲーム用のプライベートチャットとメガホンを作成するというアイデアについて話し合いましょう。

WBOY
WBOYオリジナル
2016-06-23 14:39:141276ブラウズ

この投稿は huoshi5151 によって最終編集されました: 2013-06-06 23:36:57



URL を入力してください: 入力する必要があるゲームのアドレスを入力してください。
通話設定: プライベートコンテンツを入力します。
プライベート チャット ターゲット リスト: 番号、プレイヤー ID、プレイヤー ニックネーム、ソース (近隣または世界)、メッセージ ステータス (送信完了、送信待ち) を含むすべてのプレイヤーをリストします。
プライベート チャット ターゲットは、近くの地図上で見つけることができます。キャラクター(ソースは近くにあります)、そしてワールドチャンネルの叫び声(ソースは世界です)でキャプチャすることもできます。
ランダムな文字: プライベート メッセージの内容の後には、同じ内容が複数回繰り返されるメッセージとしてシステムが判断するのを防ぐために、ランダムに数文字が続きます。
ブロックされたユーザーを追加: プライベートメッセージを送信しないプレイヤー。
リストをクリアした後、プライベートチャットパートナーを再度取得できます。

これらの機能を実装するためにどのような点から始める必要があるかを議論しましょう

議論への回答(解決策)

完了後、統合された各サイトからのさまざまなデータを分析するクライアント ソフトウェアです。送信されたデータはフラッシュなので解析が容易です

問題を考えるときは、基本的に 5 つの W と 1 つの H が必要です。 H (どのように)
何を: チャット (本質的には、接続してテキストを送信することです)
誰: プレイヤー ID (方法によっては、サーバー自体も含まれる場合があります)
場所: マップまたはより広いエリア内
なぜ:言うまでもなく、モチベーション
いつ: リアルタイム

接続であると確認された内容、長い接続であることを確認したとき、接続の両端を誰が確認するか、誰の範囲をどこで縮小するか
最後の 1 つは、どのように、接続なので、接続方法に従わなければなりません
以下は個人的な一般的なアイデアであり、実際の操作には多くの詳細があり、さらにはまったく異なるアイデアやアプローチがあります

ゼロから始めるか、ゼロから始めるか既存のコンポーネント
前者は、基本的な通信から開始し、通信プロトコルを理解し、ソケット通信の構築方法を理解する必要があります
後者は、前者の完成した通信コンポーネントをベースにし、そのコンポーネントから開始します インターフェイスの使用を開始します使用ルールをマスターしてください
会話の分割などの問題については、基本的なコミュニケーションの方法を理解していれば、何をすべきかがわかります

ゲームは一般に「マップ」と切り離せないものです マップがあれば、座標や座標が存在します。同様の位置データ (これは通常、同時にプレイヤー ID と 1 対 1 の関係があります)
位置データを使用すると、誰が誰をフォローしているかを自然に判断できます。A が開始者であると仮定します。チャット

A はサーバー (ゲーム インターフェイスとして表示) から全体的なデータを取得し、B を見つけてチャットを開始し、サーバーにリクエストを送信します。 サーバーには 2 つの方法があります:
1) サーバーはチャットに介入します。次に、サーバーはそれぞれ A/B への接続を生成します (実際、これはゲーム開始時にすでに行われています)。次に A に接続します。B との両方が「チャット」状態に入ることに同意することを確認し、サーバーはメッセージを送信します。特定の順序 (もちろん会話/時間の順序) で A/B に送信します
2) サーバーはチャットには介入しませんが、B の IP とポート情報を返し、同時に B に通知を送信します。 A があなたからのチャットをリクエストしたい場合、A は B の IP とポートに接続リクエストを送信し、B はサーバーを経由せずに受け入れて「チャット」状態に入ります

一般的に、1) の方法で、サーバーが関連性を維持できるようにします。情報(会話内容含む)や各種詳細データはデータ量が多いですが、ゲーム演出からの対応やゲーム外のインシデント回避などに対応可能です
2) 仕組みはP2Pと同様で、サーバートラフィック負荷が大きくなります。しかし、A/B 接続で起こることを介入したり制御したりする方法はなく、これにより (オンラインまたはオフラインで) さまざまな予期せぬ問題が発生し、「チャット」がいつ終了したかを知ることさえ困難になります。ゲームのインターフェースでは、画面上に 2 人のキャラクターが固定されている可能性が最も高いです

それに追加: 方法 1) は、ゲーム自体によっては、短い接続を使用して実装することもできます

余談: Tencent が QQ Liantian に介入したと思いますか? ? ?自分で想像してみてください



URL を入力してください: 入力する必要があるゲームのアドレスを入力してください。
通話設定: プライベートコンテンツを入力します。
プライベート チャット ターゲット リスト: 番号、プレイヤー ID、プレイヤー ニックネーム、ソース (近隣または世界)、メッセージ ステータス (送信完了、送信待ち) を含むすべてのプレイヤーをリストします。
プライベート チャット ターゲットは、近くの地図上で見つけることができます。キャラクター(ソースは近くにあります)、そしてワールドチャンネルの叫び声(ソースは世界です)でキャプチャすることもできます。
ランダムな文字: プライベート メッセージの内容の後には、同じ内容が複数回繰り返されるメッセージとしてシステムが判断するのを防ぐために、ランダムに数文字が続きます。
ブロックされたユーザーを追加: プライベートメッセージを送信しないプレイヤー。
リストをクリアした後、プライベートチャットパートナーを再度取得できます。

これらの機能を実装するにはどのような側面から始める必要があるかについて議論しましょう

なんというか、Apache 自体がこれに利点があるとは思いません。現在、国内のオンラインゲームの一部ではデータ送信用のサーバーとしてnodejsを利用しています。

これは、各サイトのさまざまなデータを分析した後、統合的にログインし、送信されたデータパケットを分析するためのクライアントソフトウェアです。フラッシュの方が分析しやすいため、フォーマットに従って対応する場所にデータを送信するだけです。プライベート チャットするには、まずアカウントを登録し、プライベート チャットを通じて登録したアカウントでゲームにログインする必要があります

問題を考えるとき、基本的には 5 つの W と 1 つの H がなければできません。 Hについて(どのように)

何を: チャット(本質的には接続してテキストを送信することです)
誰が: プレイヤーID(方法によってはサーバー自体も含まれる場合もあります)
どこで: マップ内またはより広いエリア内
なぜ: 言うまでもなく、モチベーション
いつ: リアルタイム

接続であると確認された内容、長い接続であることを確認したとき、誰が接続の両端を確認するか、どこで誰の範囲を縮小するか
最後はどのように、接続なので、接続方法に従わなければなりません
以下は個人的な一般的なアイデアであり、実際の操作には多くの詳細があり、まったく異なるアイデアやアプローチもあります

ゼロから始めるか、ゼロから始めるか既存のコンポーネント
前者は、基本的な通信から開始し、通信プロトコルを理解し、ソケット通信の構築方法を理解する必要があります
後者は、前者の完成した通信コンポーネントをベースにし、そのコンポーネントから開始します インターフェイスの使用を開始します使用ルールをマスターしてください
会話の中断などの問題については、基本的なコミュニケーションの方法を理解していれば、どうすればよいかわかります

ゲームは一般に「マップ」と切り離せないものです マップがあれば、座標が存在します。または同様の位置データ (これは通常、同時にプレイヤー ID と 1 対 1 の関係があります)
位置データを使用すると、誰が誰をフォローしているかを自然に判断できます。A が開始者であると仮定します。チャット

A はサーバー (ゲーム インターフェイスとして表示) から全体的なデータを取得し、B を見つけてチャットを開始し、サーバーにリクエストを送信します。 サーバーには 2 つの方法があります:
1) サーバーはチャットに介入します。次に、サーバーはそれぞれ A/B への接続を生成します (実際、これはゲーム開始時にすでに行われています)。次に A に接続します。B との両方が「チャット」状態に入ることに同意することを確認し、サーバーはメッセージを送信します。特定の順序 (もちろん会話/時間の順序) で A/B に送信します
2) サーバーはチャットには介入しませんが、B の IP とポート情報を返し、同時に B に通知を送信します。 A があなたからのチャットをリクエストしたい場合、A は B の IP とポートに接続リクエストを送信し、B はサーバーを経由せずに受け入れて「チャット」状態に入ります

一般的に、1) の方法で、サーバーが関連性を維持できるようにします。情報(会話内容含む)や各種詳細データはデータ量が多くなりますが、ゲーム表示からの対応やゲーム外のインシデントを回避することが可能です
2) 仕組みはP2Pと同様で、サーバートラフィック負荷が大きくなります。しかし、A/B 接続で何が起こるかを介入したり制御したりする方法はなく、これにより (オンラインまたはオフラインで) さまざまな予期せぬ問題が発生し、「チャット」がいつ終了したかを知ることさえ困難になります。ゲームのインターフェイスは、おそらく画面上に固定された 2 人のキャラクターだけです

追加: 方法 1) は、ゲーム自体によっては、短い接続を使用して実装することもできます

余談: Tencent が QQ Liantian に介入したと思いますか?自分で想像してみてください

本当にたくさんの利益を得ました、ありがとうございます

ああ、面倒です、わかりません

huoshi5151] こんにちは、ご都合がよろしければ、+QQ: 519173276

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。