Web開発からゲーム開発への移行方法

こんにちは、Habr！ ほぼ10年半の間、Webサービスを作成および開発してきました。 あなたはそれらのいくつかを知っているか、使用の経験を持っているか、情熱的に愛している、または複雑な感情を持っているかもしれませんが、これは今ではありません。

そのため、2つのWebサイトビルダーが市場で知られています。uCozとuKit、 90 ％ 以上の登録が独自のサイトの作成に変換されなかった、少なくとも5 ％のオーディエンスを節約したいという意欲、そしてゲーム開発の経験はありません。 Web業界に関するゲームのリリースに必要なものではなかったわけではありませんが...そうですね。

曲がりくねった道の始まり

バックエンドおよび65675フロントエンドの59845行のコード。 2年以上の開発、失敗とデッドロック、7つのインターフェースオプション。 夢の中でチームメンバーの一人に会うのに長い時間がかかるかもしれませんが、これはすべて私たちの背後にあります。

主にサイトビルダーを扱っている人や会社が突然、 オンラインマルチプレイヤー戦略を採用しました（そして実際に採用しました！）。 テーマであっても：サイトとウェブマスターについて？

ある時点で、製品としてのuCozが時代遅れになり始めたことに気付きました。これがuKitを作成する動機の1つでした。 すべてはうまくいきますが、問題はより深く、その根源はどこにも行かず、人間の心理学にあることが判明しました。 どのサイトビルダーについて話すかは重要ではありません-uKit、uCoz、Wix、Tilda、Jimdo、LPmotor（名前を付けなかった同僚をすべて許してください。数百人です、みんな覚えています、みんな大好きです）。 大多数の登録ユーザーは決してサイトを作成しません 。 これは簡単に確認できる事実であり、登録数（ボットなしのカウント）と実際にサービスを受けているドメイン/アクティブクライアントの数を比較するだけで十分です。

なぜそう ユーザーだけでなく、私たちが電話した答えを探して、良い質問です。 明日だから 。 または来週。 すべてが明確で、すべてが便利ですが、まだ時間がありません。 ジムに行くようなものです。

そのとき、簡単な考えが浮かびました-私たちはすでにこれらの人々にお金を払って、彼らを引き付けました。

「インターネットプロジェクトの作成に何らかの形で関係している人は誰でも、この経済戦略の一環としてサイト管理を確実に行うべきだと思います。 ゲームが何かを教えることができると言うのも不思議ではありません...これは、サイトチームの管理の原則と多くのサイトで作業する機能のいくつかを本当に理解できる数少ないケースの1つです。 そして、この業界に突入しようとしている人たちにとって、ゲームで提示されるメカニズムを研究することは必須です！」



Dimry G.別名Dimok （Runetウェブマスター、ブロガーの狭いサークルで悪名高い）

誰もが自分でゲームを作りたいと思っています。

誰も私を完全に信じてはいけませんが、これは本当に一番の前提条件ではありませんでした。 歴史は世界と同じくらい古いですが。 「私はミュージシャンです。ミュージシャン向けのゲームを作ろう！」、「ゲーム開発者、ゲーム開発者タイクーンを作ろう！」-特にインディーのジャンルでは、こうしたおもちゃの例がたくさんあります。

ところで、Game Dev Tycoonは明らかな成功です。 これは、多数のクローン、暴徒の開発によって証明されています。 プラットフォーム。 私たちのゲームは根本的に異なります（他のメカニズム、異なる設定）が、Web Tycoonはほとんどの場合それらと比較されます。

最初の痛み

決定が下され、ゲームを作ります。 彼は導入部でチームの経験について書きました。さらに、彼らは進行中のプロジェクトですでに忙しく、彼らから引き離すのは不合理です。 それで何？ そのため、仕事を専門家に任せる必要があります。 これが私たちの最初の本当の痛みでした。

何よりもまず、開発のためによく開発されたゲーム開発スタジオを雇うために、正直な試みがなされました。 幸いなことに、ワークショップで同僚や友人から推薦することができました。 アイデアレベルでは、誰もがプロジェクトを気に入っており、スタジオはそのような仕事を引き受ける準備ができていました。

後で出会ったいくつかのシナリオを以下に示します。

• はい、認めます、私たちのゲームデスはそうしませんでした。 プロジェクトで頑張ってください！
• ブラウザゲームが必要ですか？ 質問ではなく、Unityでやってみましょう。 そして、ユーザーがプラグインをブラウザーにインストールする必要があるという事実（当時はそれだけだった）は問題ではなく、ほとんどすべての人に費用がかかります！

2つのスタジオが最も安いdizの代金を支払った。 ドック。 非常に膨大な結果を受けました。 多くの作業が行われましたが、質問はありません。 しかし、それは他のゲームについてのすべてでした。 いいかもしれませんが、違います。 説明のために、最高は人気があります：「ロシア人が何をするにしても、すべてがカラシニコフ突撃ライフルであることがわかります。」 人々はそれに慣れており、よく知られ、よく発達したメカニックで、彼らに知られているジャンルでそれをやりたいと思っていたのは明らかだったので、彼らはdizで比ur的でした。 doc

ただし、シルバーの裏地はありません。 スタジオからスタジオへと繰り広げられるこの段階から、私たちは1つ、しかし非常に貴重な名前を引き出しました。 最初のコードはuWebmasterでした（ゲームはWebマスターに関するもので、すべてをUという文字で呼び出すことに慣れています）。 より明らかに関連性の高いオプションが提案されました-Internet Tycoonは、その後Web Tycoonに変換されました。

第二の痛み、自分でやる

スタジオと一緒に（または一緒に）何もうまくいかないことを認めなければならなかったとき、私たちは家を作ることにしました。 プロセスの基本的な人物であるゲームデザイナーの長い選択が始まります。 最初に類似のジャンルに興味を持ち、必要な能力などを持っていた人は、アイデアをキャッチします

これらのゲームデザイナーである非常に難しいトピックについて、長い間お話ししたくありません。 必要であり、dizを書く必要があるかどうか。 ドック。 ゲームデザイナーが自分のゲームをプレイし、視聴者とコミュニケーションを取り、マネージャーになる必要があります。 これは非常に独立した全体的な会話です。 私は一つのことを言います：今日、全く異なる理由で、プロジェクトとチームは4人のゲームデザイナー（1人の後輩を含む）を生き残りました。

募集はすべての面で簡単ではありませんでした。 長い間、唯一の代表者は孤独なゲームディッシュでした（上記の4つのうちの1つ）。 この主な理由は、かなり高い要件を備えた「残留原理」です。 つまり、まず第一に、開発者はメインプロジェクトを必要とし、そこで彼らは非常にうまく採用されました。 そして、ゲームのtechdirは結晶化しませんでした。 もちろん、これはできません。 やることを決めた-それを行う。 しかし、私たちはこのレーキに長い間行きました。

techdirがついに登場したときでさえ、彼は長い間、彼自身のチームリーダーであり、アーキテクトであり、完全なセットではパフォーマーでした。 スタッフのナンセンスハード修正。 本格的なチームを結成するには、約6か月かかりました。 奇妙なことに、奇妙なことに、彼らはイラストレーターを探していました。 そして突然、私たちのオフィスマネージャーが彼らになりました。

ストーリーのこの部分に一定の結果を要約すると、2年前にゲームチームが本当に機能したと言えます。 誰がインターフェイスを描画し、誰がコードを書くか、そしてスクラムさえも少し後に紹介されました。これはすでに会社全体で確立された慣行でした。

設計とインターフェース

次のようになります。

ゲームとしては珍しく、退屈で面白くないとさえ言えます。 しかし、これは意味のある選択です。 一見、ゲームというよりはWebポータルのように見えます。

好きな人：

知り合いにスクリーンショットを見せて、「だからこれは管理パネルだ」、「ゲームではなく、誰かの統計だと思った」というようなことをよく耳にしました。 私たちの聴衆である人々はすぐに大騒ぎしました。 彼らは漫画ではなく、本当に本物の何かを望んでいました。 おそらく、選択したスタイルのために数人のカジュアルなプレイヤーを失うことになるでしょうが、その簡潔さを信じています。

彼はついに、このゲームは典型的なゲーム、フットボールマネージャーのように見える必要はないと確信しました。 シミュレーターはあまり遊び心がないように見えるかもしれませんが、成功しています。 これがジャンルです。

選択したスタイル内には、ビジュアルのオプションがいくつかありました。 以下は、さまざまなデザイナーのさまざまなソリューションです。

AIを追加するとすべてが改善されます

プレイヤーは化粧品が大好きです。 まだ実装していませんが、写真からプレイヤーのアバターを生成する方法を既に学習しています。 最も興味深いことに、これは、データセットなしの機械学習とモデルトレーニングに対する非常に革新的な特定のアプローチで発生します。

これは、アバターデザイナーの要素から生成されたもので、プリズマの写真からは定型化されていません。 そして、品質の面で機械は人を打ち負かしませんでしたが、結果によって彼に追いつきました。

技術自体には開発の計画があります。 このストーリーは、別の投稿に値するものであるか、1つではありません。間違いなくHabréに掲載されます。 誰かが非常にせっかちな場合は、PMをノックして、私たちはこれを個人的にプレイする機会を与えます。

イングリッシュファースト、モバイルファースト

リリースに近付くほど、ゲームがモバイルデバイスに完全に適合していることに気付きました。 デスクトップよりもさらに良い場所。 同時に、テスト期間中、ブラウザプレーヤーは視聴者に非常に喜んでくれました。 彼らはゲームのチャットルームでアクティブなIT会話を行い、ゲームを自動化するボットを作成し、ドキュメント化されていないAPIを選びました。

当初、ゲームは現在ブラウザを使用しているという考えで開発されました。そこで、メカニズムをテストし、バランスをとってから、組み込みAPIのおかげでネイティブアプリケーションを収集します。 現実は調整を行いました。

この素晴らしい計画には時間も予算もありませんでした。 同時に、私たちが話したほとんどすべての出版社は、主にモバイルに興味があり、モバイルがあればすぐに来てくれると申し出ました。

私たちは妥協しなければなりませんでした。なぜなら、Cordovaで数か月間iOSとAndroidのアプリケーションを組み合わせたからです。 標準ではないことは明らかですが（非常にまともですが）、非常に快適にプレイできます。 そして、仮説を「どのように進むか」を完全に正確にテストすることができます。

App Storeの問題

AppleとApp Storeでの節度により、少し苦労しました。 最初は、動機付けの起草がありました。「あなたはWebアプリケーションです。 「AppleデバイスにはSafariがあり、Safariに住んでいます。気にしないでください。」 しかし、私たちはそれに勝ちました。

その後、残念ながら、Appleの要件により、人目を引くゲーム通貨Bitcoinの名前をWebcoinに変更する必要がありました。 公平に言えば、彼らは正しいです、間違いは確かに可能です。 私たちにとって感覚は同じではありませんが。

ローカリゼーションについては、英語を話すオーディエンスで始める準備ができています。 ただし、ロシア語を母国語とする市場で磨きをかけてテストする方が簡単で安価です。 したがって、これまでのところ私たちはロシアでのみ開始しましたが、1、2週間以内に、イングリッシュファーストに戻る予定です。

技術的なポイント

ReactおよびReduxからVueおよびVuexへの移行

私たちは今、可能性のあるホリバーの薄い氷の上を歩いていることを理解しているので、私は私たちが何かを課したり主張したりしないことをすぐに予約します。 これは私たちの道、選択の理由と経験の単なる説明です。

ゲームを作成するプロセスの最初の革命は、非常にソフトではありますが、ReactとReduxからVueとVuexへの移行でした。

当社では、ほぼ同じ技術スタックですべての製品を開発しようとしています。 これは主に蓄積された専門知識の問題であり、その場合、開発チーム間での簡単な移動です。 今日の基本：NodeJS、React、MongoDB。

大量のデータと接続を使用してゲームを作成することは、最初はNoSQLでは馬鹿げていました。 その結果、私たち全員が移行したのは1週間流血でしたが、最初に最初にしたことです。

途中でReactからVueに変わったのはなぜですか？

新しいゲームデザイナーの登場により、ゲームの中心的な仕組みが変わり、ゲーム内のほとんどのインターフェイスが大幅に変更されました。 新しいメカニズムはVueで迅速にプロトタイプ化されました。この選択の基準は、技術を導入するための低しきい値でした。 同じ時期に、トラフィックの成長、利益、エネルギーのベクターシステムを思いついて導入し始めました。 それ以前は、データを時間内に書き込むだけでしたが、変化の速度には影響しませんでした。

最初は、ReactとともにReduxを使用しました。 スプレッドは非常に急速に成長しました。ゲーム内のWebサイトでのユーザーアクションごとに新しいエントリが作成されました。 したがって、ストーリー全体が変異し、ゲッターが再集計され、結果としてトラフィックと利益の複雑な計算が行われました。これはすべて非常に遅くなりました。 もちろん、MobXを使用して計算のロジックをやり直すこともできますが、この瞬間はセンターメカニクスの重大な変更と一致しました。 または星が一致しました。 彼らが複数の関係者をつないでReduxの問題を解決しようとしたところ、Vuexではすべてが箱から出して機能し、不必要なジェスチャーなしで任意の数のサブモジュールに分割されました。

Vueの構文シュガーと柔軟性は、本当に「ヒット」します。 たとえば、現在、コンポーネントの値を定期的に更新するために、計算されたプロパティの代わりに

foo() { return bar + baz; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

書きます

 foo() { return (this.oneTick, bar + baz); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プロパティthis.oneTickには小さな魔法が隠されています。これはリアクティブで、1秒間に1回更新され、式bar + bazの結果が変わるとコンポーネントがレンダリングされます。

データベースの移行

バックエンドから、1つの小さな移行と1つの大きな移行がありました。 最初は、プロジェクトはMySQLで行われました。 それは迅速だったので、単純にリレーやその他の喜びが必要だと考えました。 少し成熟した後、かなり簡単にPostgreSQLに切り替えました。

より広範で複雑なのは、MongoDBへの移行です。 この決定は、容易なスケーラビリティと比較的高いパフォーマンスによるものでした。 ORMの存在にも関わらず、2番目の移動ではさらに多くの問題がありました。 しかし、標準のReplicaSetとAutoFailOverのセットアップには1時間しかかかりませんでした。

出版社について一言

そもそも、彼らを待っています。 これまでのところ、Mail.Ruだけが自信を持って私たちを信じています。 同僚に感謝します。 ブラウザーのバージョンがどのようにオーディエンスに届くのか、すぐにわかります。

スマートブックやポッドキャストでは、出版社はリリース段階ではなく、途中に来る必要があると言っています。 11月にDevGammに行くなど、事前に話し始めました。

私たちは何を期待していました：

「はい、わかりました、これをやり直してください。ここに私たちと専門知識があります！」

私たちが得たもの：

「それはクールで、新鮮で標準的ではない、興味深い設定ですが、どのように始めれば収益化のテクニックがありますか？」

一般的に、理論は私たちを失敗させました。 これがなぜ起こったのかを理解しようとすると、答えは次のようになりました。

私の意見では、非標準はそれほど多くありませんが、よく知っていると言います。

全体として、ゲーム開発者は私たちに前向きに反応しています。 市場は、次の「ドラゴンを殺す」と「城を征服する」にうんざりしていることがわかります。 これは、内部からの人々の歪んだ認識かもしれませんが。

ファイナル

そのようなとげのある曲がった道で、私たちは柔らかい昼食に来ました。 これは、勝者が判断されない場合ではなく、まだ勝利とは言えません。 そのため、フィードバックや質問に対するコメントをお待ちしています。 すべてに迅速に対応します！

あなたが協力を提供する準備ができているなら、私たちはそれを検討する準備ができています。