経験もお金もなしにWebglでマルチプレイヤー3Dシューティングゲームを作成する

これは、Web開発者の小さなチームがgamedev、大金、スタッフの経験なしにマルチプレイヤー3Dシューティングゲームを開発した方法についての話の最初の部分です。



免責事項：この記事に記載されているソリューションの一部は、facespalmを引き起こす可能性があります。

2011年。 すべての始まり

2011年、私たちは4人の小さなサンクトペテルブルクのWebスタジオでした。 Timlid / Seoshnik、プログラマー（または自分自身をプログラマーと見なした）、デザイナー、セールスマネージャー。 当時、チームリーダーとプログラマーは3年間ウェブサイトに携わっていましたが、この分野ではあまり成功しませんでした。 すでに昇進とサービスの常連客が何人かいましたが、収入の大部分は税金、オフィス賃料、およびその他の費用によって食われていました。 4人の残りのセントは明らかに十分ではありませんでした。 慢性的な資金不足と見通しの欠如が落ち込んだ。 デザイナーはすでにスキーをスピードアップしており、チームの残りのメンバーはかろうじて持ちこたえました。 このような雰囲気の中で、驚くほど素朴なアイデアが思い浮かびました：「なぜすべての叔父たちのためにプロジェクトをやっているのでしょうか。たとえば、ブラウザゲームなど、私たち自身で何かをやろうと思います。それをVKontakteで焼きます」。 デザイナー以外の誰もがこのアイデアに熱心でした。



ほとんどの「初心者」のゲーム開発者と同様に、彼らはMMORPGを行うことにしました。 私は誰もgamedevで経験がなかったと言わなければなりません。 小さなlineage2フリーチャードは別として、プログラマーはそこで自家製の記録を保存して完成させました。 ドーピングは、主にサーバーゲームデータに限定されていました。それ以上のことは十分ではありませんでした。 何らかの形で、これはサーバー側のデバイスに関するいくつかのアイデアを与えました。 プレイヤーの部隊との管理およびコミュニケーションの経験は、クライアントが信頼できないこと-サーバー上で実行できることはすべてサーバー上で実行する必要があること-を確信していました。



プロジェクトに戻りましょう。

責任は次のとおりです。

Timlid-ゲームデザイナーになりました。

マネージャー-サウンドを引き受けました。

プログラマー-プログラマーのまま。



当初は、フォールアウトと略奪者（7.62エンジン）の混合物で、アイソメではありましたが、リアルタイムでした。

シーンはポスト黙示録的なサンクトペテルブルクであることになっていた。

最初のステップ

技術的な実装は次のように提示されました。

ゲームの場所は、imgタグとdivタグで構成されます。

オーバーラップは、y軸に沿ったオブジェクトの位置に基づいて計算されたz-indexによって設定されました。

性格はなく、彼の職務は白い四角によって行われました。

コメット接続を介したサーバーとの通信。

マウスクリックによる管理。



彗星の接続はすぐに放棄され、Webソケットが採用されました。 それから、それらはまだ完全に未加工であり、フラッシュ松葉杖が立ち往生しているブラウザの半分ではサポートされていませんでした（その後、6か月または1年でベータリリースが可能になり、ブラウザ間の互換性が今必要であると私たちは単純に信じていました）。

障害物

これがすべて実現し、四角いキャラクターが画面を動き回ることを学んだとき、新しいタスクが浮上しました-その動きの自由を何らかの形で制限する必要がありました。 停止セグメントを使用してオブジェクトの境界をマークすることが決定されました。また、将来的には、射撃と視界をブロックする別個のタイプのセグメントが提供されました。







マウスでクリックすると、キャラクターの現在の座標からクリック点まで線が引かれました。 さらに、すべての停止セグメントがルートセグメントとの交差についてチェックされました。 交差点が見つからなかった場合、クライアントは目的地の座標を受け取り、移動を開始し、同じプロセスがサーバー上で行われました。 しかし、交差点の場合、キャラクターは動かないままでした。 これから、次のタスクが発生しました-回避策を見つけます。

障害物回避

解決策を見つけるのに多くの日と夜を要しました。 最初はリアルタイム検索を行う試みがありましたが、許容可能な計算速度は達成されませんでした。 次に、グーグルで、事前に計算された方法を使用することにしました。 これを行うには、オブジェクトの角にポイントポイントを配置し、各ポイントから各ポイントまでのすべての可能なルートを検索するジェネレーターを作成し、そこから最短ルートを選択して記録しました。



サーバーは、直線で移動できない場合、出発点と目的点から利用可能なすべてのポイントを取得し、それらを接続するすべてのルートを選択し、それらからすでに最短ルートを選択して移動を開始しました。 現在、この広場はすべての障害物の間を巧妙に移動し、最も重要なことには、計算に一瞬かかりました。





オブジェクトの中には立ち入ることが不可能な閉じた領域がありましたが、それほど気にしませんでした

Webgl

ターンはキャラクターを視覚化するようになりました。 難易度は次のとおりでした。キャラクターは3つのポジションを持つことができると想定されました-立ち、座り、横になり、これらすべてに空間で8方向が掛けられました。

さまざまな種類の武器が想定されていました：ピストル、ライフル、機関銃、さまざまな鎧。

最初の考えはスプライトですべてを行うことですが、新しい変形css3変換を使用しても、スプライトの数は膨大に見え、カスタマイズの可能性は非常に限られています。 他のソリューションを探し始めました。 その場でキャラクターを描くには何かが必要でした。

そのようなソリューションが見つかりました-WebGL 。



最初の経験は、ゲームCopperCubeのデザイナーでした。 アニメートされたキャラクターを含む空のシーンをエクスポートし、白い正方形ではなく全体を貼り付けました。 実行すると、対応するアニメーションがオンになり、キャラクターが好きなように空間で回転しました。 悪くはありませんが、シーン全体をWebGLで構築できますか？



決定が下され、ツールを選択することが残った。 CopperCubeは既成のデザイナーエンジンでしたが、閉鎖され、支払いが行われ、その中にネットワークゲームを作成する方法は、サーバーサイドのメカニズムを使用しても、まったく理解できませんでした。



独自のゲームメカニックを作成できる低レベルのものが必要でしたが、同時にWebGLを直接操作する必要がありません（3Dプログラミングのチームでは誰も理解していませんでした）。



多くのライブラリをテストした後、three.jsで停止しました。 文書は何もないよりもわずかに優れていたという事実にもかかわらず、ネットワークには特定の処理がどのように行われているかを見ることができる膨大な数のデモがありました。 実際、これが選択を決定しました。



残りの年は、クライアントを3Dで転送するために費やされました。







オブジェクトとマップのエディターも移植されました。

2012年。 バーを下げる

開発の開始からほぼ1年が経過しましたが、結果はまだ印象的ではありません。 Gamediseはアイデアを出し、インターフェイスの概要を説明し、キャラクターと将来の位置を説明しましたが、それは具体化に達しませんでした。 最初はわかりやすいプロットもありませんでした。 一般的なアイデアがありました-黙示録の結果、または突然の未知の攻撃の結果として、澄んだ水は金の重さに見合うようになりました。 そして、彼らはこれに基づいてゲームをWasteWater（下水）と呼ぶことにしました。



音を引き継いだマネージャーは仕事を始めず、現場での仕事もやめました。その結果、私たちの道は分岐しました。 だから私たちのうちの2人は最初の構図から残った。



しかし、最も重要なことは、ゲームコンテンツがなかったことです。さらに、それをどこで入手できるかも考えられませんでした。

明らかなことが明らかになりました-MMORPGは私たちの力では決してできません。

それから、彼らはすべてをチーム射撃に単純化することに決めました。 一般的に、ゲームは次のようになります。



プレイヤーが次のような問題に対処できるロビー：機器の購入、キャラクターの装備、スキルの向上。



バトルモード。赤いボタン「バトルへ」を押すとプレイヤーがヒットします。



彼らはトップビューを離れ、WASDで管理をやり直すことにしました。 今後、WASDは「他の人とは違う」ことが判明したと言います。 通常、このフォームでは、Wが常にアップで、Sが常にダウンの場合、キャラクターが見ている場所に関するすべてがあります。 このような制御は異常ですが、それはより戦術的な機会を与え、あなたは数回の戦いの後にそれに慣れます。

ゲームプレイはよりダイナミックになると想定されていたため、キャラクターの横たわる姿勢と座る姿勢は捨てられました。



重要な機能のみが同じままでした-すべての場所は、サンクトペテルブルクに実際に存在する場所に基づいている必要があります。



これはコンテンツの不足の問題を解決しませんでしたが、起動に必要な最小量を大幅に削減しました。



クライアントの書き直しを始めました。 夏までに、作業用具を備えたロビーのプロトタイプが完成しました。 キャラクターは、これまでにアクション地震（q2のmod、祖父cs）から取られました。







夏はすべて戦闘システムに費やされました。 WASDコントロールは、古いマウスポインティングコントロールシステムの上にねじ込まれました。キャラクターのパスファインディングは無効になり、クリックポイントはキャラクターの前の特定の距離でエミュレートされました。 プレイヤーがマウスを動かした場合、またはキャラクターが計算された座標に達した場合、ポイントが再度計算されました。 パスファインディングはMobに役立ちます。 それらのモデルは、いくつかのq2モードからも取得されました。 プレイヤーを追いかけてプリミティブAIが作成されましたが、目標を達成するための主な作業はすべてパスフェーディングシステムによって行われました。 すべての原始性にもか​​かわらず、この人工生命の観察は魅惑的でした。







銃撃は行われたが、静かで炎のない状態だったが、暴徒はすでに一斉に刈り取られ、彼らはそれに応じて痛々しく噛むことを学んだ。

攻撃/ショットアルゴリズムは、セグメントと抑制のチェックにも基づいていました-条件付きセグメントがシューターから現在の武器の最大範囲まで取得され、衝突がチェックされました。 「生きている」オブジェクトも交差セグメントとして指定されていました。



一般的に、プロトタイプの崩壊までに、多かれ少なかれ準備が整いました。

内容

一方、ゲームデザインは無駄な時間を無駄にせず、私たちに適したコンテンツを求めて既製の3Dモデルが販売されていたサイトを整理しました。 彼は何かを集めることができたが、これは十分ではなかった。

コストが削減されたため、無料の資金を得て、フリーランサーを雇うことにしました。

最初の注文は、アニメーションを持つ新しいキャラクターでした。 そして、いつものように、最初のパンケーキはゴツゴツ出てきました-事前に契約業者は合意された日付までにわかりやすいものを見せませんでした。 どんなおとぎ話のキャラクターと一緒に仕事をしなければならないかを知っていたら...



年末までに、キャラクターを作成してアニメーション化したアーティストを見つけましたが、新しい問題が表面化しました。 事実、作業が行われた3DsMaxからは、アニメーションをthree.jsに直接エクスポートできなかったため、中間コンバーターとしてmd2を使用する必要がありました。これは、オンラインコンバーターを介してネイティブjsonに既に蒸留されていました。



フレーム単位のアニメーションに共通する欠点（重量とメモリ消費）に加えて、md2にはもう1つありました。頂点座標が丸められ、モデル全体がフローティングになりました。 これは、低ポリのQuakeキャラクターではそれほど目立ちませんでしたが、私たちのものでは、より詳細に見ると、うんざりしていました。







どういうわけか別の方法でエクスポートに失敗したことは、ブラウザが単に対処できず、「たわごと」を与えることができないとてつもない量であることが判明しました。 その後、私たちはすべてをもう一度やり直す精神的な準備ができていなかったので、実際にやり直す方法がまだ明確にわからなかったので、今のところそのままにしておくことにしました。

2013年。 最初の結果

環境の3Dモデラーにも不運でした。 最初に彼らは新しいロビーを取り上げて、なんとか二人のフリーランサーからしか悲しみをなくした。

最初の場所

最初のマップで作業を開始しました。 当初、彼らは地下鉄のオゼルキ駅とその周辺地域を使いたいと考えていましたが、設計段階でこのベンチャーを放棄しました。 実際、この領域には大きな高低差があり、クライアントは3次元になっていますが、サーバーロジックは2Dのままです。 つまり、キャラクターが山の上に立って、足元に立っているキャラクターを撃ち、弾丸が落下せずに、ターゲットの頭の上まで飛んでいる状況はいように見えました。



より平坦な場所が必要であり、ランスコエショッセとオムスカヤ通りの交差点は、通過する高圧送電線を除いて注目に値するが、そのような場所として選ばれた。



Yandex.Mapsのロケーションプランをマークし、実装に切り替えました。 私たちは未来の地形のスケッチから始め、新しいウェブデザイナーがこの仕事を引き受けました。 実際の領域の領域は1ヘクタール程度でしたが、4 GBのメモリを搭載した古い2コアではデータ量に対応できなかったため、設計者はすぐにコンピューターを改善する必要がありました。



これは、もちろん、品質が洗濯石鹸の状態に絞られていない限り、単一のテクスチャを平面に引っ張るだけでは機能しないことをすでに示唆しています。 すべてを小さな断片にカットし、モザイクのように組み立て、可能な限りセグメントを繰り返すことにしました。 タイル、デカール？ いいえ、そのような言葉は知りませんでした。



カードアセンブリは主にゲームデスによって処理され、組み合わせてレベルデザイナーにもなりました。 結局のところ、この方法でカードを収集することは非常に困難でした。 わずかなミスが原因で、カードの半分を再度組み立てる必要がありました。 開発ツールというよりも拷問のツールであった自作のエディターは、苦しみを強めました。







それにもかかわらず、巨人の努力により、地図は収集されました。

音

マップ上での作業と並行して、音で作業が進行中でした。 ロビーと戦闘モード用に1組のトラックが購入されました。

これらのトラックの作成者は、他のゲームサウンド、ショット、ステップなどを注文しました。



バックグラウンドミュージックは、単にオーディオタグに掛けられ、ゲームサウンドは、当時まだ未加工で、クロムとその親族でのみサポートされていた最新のWebオーディオAPIを通じて実装されましたが、すでに豊富な機会を提供しており、特に、サウンドを空間に合わせて配置できました3Dシーンでのソースの位置。

プレアルファ

2013年5月8日、私たちは生きている人々に対してプレアルファテストを開始しました。 実験的なものはほとんどありませんでしたが、彼らはまだいくつかのフィードバックを収集し、自分でプレイすることができました。

プレアルファの結果に基づいて、次の結論が出されました

1.アニメーションシステムを変更する必要があります。

2.停止セグメント上に構築された障害物システムはうまく機能しません。プレーヤーは微妙な障害物にしがみつきます。

3.手動ストローク自体は労働集約型であり、複雑な形状の場合には完全に対応しません。

4.スケーラビリティはありません。マップ上で利用可能なすべてのストップセグメントをソートする必要があります。

5.平面の地形モザイクはFPSを描画し、ジョイントはどこにでも表示されます。

6.実際のインターネット上のキャラクターの完全なサーバー側の動きは、私たちが望むほどうまく機能しません-ボタンのクリックとゲームの反応の間の遅延は視覚的に見えます。

7.グラフォンは全体として「ニオヘン」です。

まとめ

ほとんどすべてをやり直す必要があることが明らかになりました。 しかし、否定的な結果は結果でもあります。 ほとんどすべてのことは、少なくともそれを行う方法のいくつかの経験と理解を与えました。



次の1年半で、ゲームを作り直しましたが、次の記事で詳しく説明します。



ゲームの作業は継続され、計画のメインのみが実装されます。



2015年のロビーのスクリーンショット：







マップ「Spit of Vasilyevsky Island」2015年のスクリーンショット：







ご清聴ありがとうございました。