あまり成功していないf2pソーシャルから何を学んだか

約2年半前、私は非ゲーム開発会社に雇われ、パイロットプロジェクトに参加しました。これは、プロダクトプレースメントを使用したf2pソーシャルメディアの開発です。 これ以前は、ゲーム開発での私の経験はすべて、1.5ダースの小さなフラッシュカジュアルと気取らないiOSアプリケーションに限定されていました。



チームは可能な限りコンパクトに選ばれました:サーバー、クライアント、デザイナー、アニメーター。 投資家はスタッフ自身を膨らませたくありませんでした。彼自身がこの企業の便宜性について確信を持っていなかったからです。 さらに、誰もが(おそらく、私を除いて)彼の仕事をよく知っていて、本当に上手でした。 すべてうまくいくはずです!



圧倒的な成功はありませんでしたが、保持と支払いの指標は非常に控えめでした(プロモーションにお金を投資しませんでした-ゲームが「新しい」セクションにぶら下がっている間にVkontakteカタログから最初の週にゲームに来た最初の20万人のプレイヤーに基づいて評価されました) ) 収益化とゲームの設計に関しては、まだ多くの経験を積んでいませんでしたが、自分自身でいくつかの結論を出し、それらを共有したいと考えています。誰かが役に立つかもしれません。 さらに、大規模なゲーム会社で働いている今、特に「子供時代」の間違いを賢く経験豊富な人々が避けていることを特にはっきりと見ています。



ちなみに、同じトピックで、「 1つのソーシャルゲームを開発して14のミスを犯すにはどうすればよいか 」および「 ソーシャルネットワーク用ゲームの開発におけるレーキの意図的な収集と分析 」という素晴らしい記事をお勧めできます



以下、繰り返します-これは、私自身の観察と(多くの場合)間違いに基づいた、純粋に個人的な結論(主にキャプテンのもの)です。 だから...



画像



自分を過大評価しないでください



プロジェクトを始めたとき、このサイズと規模のゲームを開発した経験はありませんでした。「まあ、以前のゲームの5倍の機能とコンテンツがあるゲームを作るには5倍になります」と大幅に誤解されました。 その結果、非常に多くのニュアンスと落とし穴が出てきましたが、それについても知りませんでした。 「ゲームデザイナーは必要ありません。記事を読んで、同様のゲームを見て、自分で判断します」、「アルファ版は9月までに準備が整います。これで十分だと思われるので」 「官僚主義、肥大化したスタッフ、あまりに形式化されたプロセスのために、そして今、私たちは本当のインド人のように、すべてを襲い、やるでしょう。」



可能な解決策:すでにこれを行って犬を食べた人々の詳細な相談を求めます。 たとえあなたがそれのためにお金を払わなければならないとしても、それはそれ自身のために支払います。



タイミングをできるだけ悲観的に計算します-負けません



かなり一般的な推奨事項。 1週間でタスクを解決できると思われる場合は、2週間を計画することをお勧めします。 そして3つです。 自分で熟練した職人であることを証明し、エンドツーエンドの時間を取り、疲れ果てたクランチに取り組みながら、まだ遅れないようにするよりも、より多くの時間を取り、スケジュールより前にそれを行うことをお勧めします。あなたの言葉は以前のように聞かれなくなります)。



ゲームの設計と計画は非常に重要です



dzdokと計画の欠如により、2〜3回の開発が遅れました。 レベルでは、ゲームがどのようなものになるかについての一般的な考えしかありませんでした。「あれやこれのシミュレーターになります。あれなどあれこれできるようになります...まあ、それもやりたいです」。 機能、バランス、インターフェイス、グラフィックスタイルなど、他のすべてが外出先で発明されました。 新しいアイデアが生まれたとき、私たちはしばしば古いアイデアを捨て、既製の機能の一部を切り取り、プロジェクトを元のビジョンとリモート機能のこだわりのある作品に近づけるようにしました。 コミックのように、 1つのプロジェクトの枠組み内でのみ判明することもありました。



ゲームプレイに関係のないことに関与しないでください



ゲームにはオブジェクトがありました-バスルームとキッチンのシンク、自分用の普通の洗面台。 私たちはそれをクリックできるようにすることを決め、そこから少しの水が流れ始めました。 アーティストはアニメーションを描き、アクションと2つの状態を主題に追加しました:オープンとクローズ。 それから彼は、あなたが地図に行って、そして再び家に帰るならば、水が流れ続けるようにする方法に困惑しました。 それから、タップを閉じずにゲームに再び入ったとしても水が流れるように、オブジェクトの状態を維持するのが良いと考えられました。



そして、それだけで、すべての後に、実現が来ました:地獄にこれはすべて必要ですか? これは、ゲームプロセスにも収益化にもまったく価値を追加しません。時間は無駄になります。



多くの悪いことをしようとしないでください。



これは、ここですでに別の形式で表明されています。 一番下の行は、最大のコンテンツを追いかけてはいけないということです-既存のものがうまく機能することを確認することをお勧めします。 テトリスとビジュエルドは美しいですが、RPG要素、一人称視点、DirectX 11サポート、異常、盗品はありません。 それ以外の場合は、「ゲーム内でオブジェクトXXXとZZZを使用する理由」などの質問のみを作成します-「まあ、それらに関連付けられた機能YYYを追加することを考えましたが、適切に操作できませんでした」。



ゲームデザインの人々にゲームデザインの決定をさせない



ゲーム開発に関与していない多くの人々は、ゲームのプロセスに関するアドバイスや推奨事項を提供したいと思うでしょうが、これはこれらの人々が耳を傾けるべきだという意味ではありません。 投資家であってもプロデューサーになるべきではありません-製品所有者として、彼は資金調達、プロジェクトの一般的な主題、許容される期限、およびその他の要件について決定できますが、バランス、アート、機能セットについてはできません。



無関心な人をできるだけ早くテストする



私たちは良いゲームプレイをしましたが、それは理解可能で非常に便利でした。 まあ、それはすべてがそこに単純であることは明らかです-それは時期尚早に人々に準備のできていないゲームを見せています。



しかし、警鐘を鳴らすのは、後の段階で誰かがコンピューターでゲームを突くようにすると、「いや、いや、ここにはない」、「見て、カードに行くために-あなたがする必要があるボタンを押してください、それは明確ではありません”、”いいえ、ここではうまくいきません。別の方法で押す必要があります”。 それは私たちの仲間であり、定期的にコンピューターゲームをプレイしていました。 そして、私たちはソーシャルネットワークに行き、一般的にさまざまな年齢のさまざまなバックグラウンドを持つ人々を狙うことを計画しました!



私が読んだもう1つのことは、非常に一般的です:テスターへの批判は感謝と攻撃なしで、自分を守るために取られるべきです(「ここでは、彼らは言う、ゲームは良い、彼らは何も理解していない」)。



事前にリファクタリングしないでください(コードの美しさではなく、製品が重要です)



議論の潜在的な根拠ですが、私の個人的な意見と経験から得られた結論:コードが機能し、バグがほとんどない場合は、少なくともリリースまでは触れないでください。 プロジェクトには投資家がいて、開発には毎日費用がかかり、競合他社はこの期間中に3つの類似製品をリリースします。 リファクタリングはコードの美しさのために採算の取れないマスターベーションになり、最適化の結果、「今ではこの構成は0.3ではなく、0.1秒で解析され、3倍高速になります!」という精神が生まれます。 未完成のプロジェクトでこの最適化に3日間を費やしたという事実にもかかわらず。 私は完全に美しいコードが欲しいです-夕方にはgithubでオープンソースエンジンを書いてください。



商業プロジェクトでは、各アクションに時間がかかり、リリースが遅れることに注意する必要があります。したがって、費用がかかります。 非常に単純化:1週間の作業に1,000ドルの費用がかかり、リファクタリングに費やすとします。 この場合、これを行う必要があります。将来未反応のコードの保守とデバッグに合計で1週間以上かかるか、バグの可能性があるために1,000ドル以上の損失が発生する可能性があります。



ストレステストおよび弱い接続でのテストの実施



ここではすべてが単純です。サーバーがどれほど信頼性が高く高速であっても、最初の数日間は負荷に耐えられない可能性が高いです。 同様に、クライアントとサーバー間のやり取りがどれほど信頼性が高く効率的であっても、おそらく接続が遅いか破れているように見えますが、クライアントの何かが正常に機能しないか、まったく機能しません。



助けを求めることを恐れないでください



私は他のチームメンバーには言いませんが、私は常に「プロジェクトの一部をアウトソーシング業者に引き渡します。これに十分なお金を与えます。彼らはあなたと並行してコードの一部を書いてください」という申し出を断りました。 自分のコードがわからなかったからといって。 ここに、他の人がおそらくそれを使いたくない、あるいは批判するような嫌なコード構造があると思った。 そして一般に、ここにあるものはすべて私と密接に結びついているので、コード全体を書き換えずに1つのものを編集することは不可能です。したがって、一般に複数の人がそれを扱うのは不便です。 はい、少し残っています。ここでは、2、3週間でささいなことを追加します。その後、すべてが簡単になり、アウトソーシング業者について考えることができるようになります。 一言で言えば、彼は私が誰かの助けを必要としない理由を言い訳したという事実にのみ従事していました。 しかし、実際には-私は助けを求めるのを恐れていました。



ゲームでは、プレイヤーに影響を与えることができるものに関する情報を提供する必要があります



これは非常に一般的なヒントであり、記事やゲームで何度も表明されています。 プレイヤーは、何らかの形で、自分が何に影響を与え、何に依存するかについての情報を提供する必要があります。 ゲームがそのアクションに直接応答する場合、プレイヤーはその方法と理由を明確に把握している必要があります。 たとえば、体力や弾薬のインジケータがないカウンターストライクや、次のレベルのヒーローまでのMobレベルや経験値が表示されないWorld Of Warcarftを想像するだけで十分です。 仕組みは変わりませんが、プレイヤーはゲームが不快であり、すべての重要な情報を提供していないことに不満を感じます。



遅かれ早かれ、あなたはまだリリースする必要があります



シドマイヤーはこれを言ったが、男は問題を知っている!



ゲームは常に未完成で、空で、リリースの準備が完全に整っていないように思われました。 私は何年もそれに取り組むことができたようで、この感覚はどこにも行きません。 この理由は、主に計画の欠如と明確なdzdokの欠如であり、最初にリリースに必要な機能のリストと、更新で追加される機能のリストを記述します。 ただし、dizdokが存在する場合でも、期限が切れている場合はフィッシュカットが必要になる場合があります。これは完全に正常で、多くの場合便利であり、オプションの殻を削除できます。



すべてのプレイヤーに同じことを言う



ゲームのVKontakteグループを作成した後、管理者セクションに自分のプロファイルへのリンクを残しました。 その後、プレイヤーは私に個人的なメッセージを絶えず書きました(それらのほとんどは私たちのターゲットオーディエンスです:14歳未満の女の子です)。 できるだけ簡単に答えようとしても、私はレベルでの広範囲に及ぶ計画にただぶらぶらしている何かについて話しました:「たぶん手が届くなら、機能XXXXXXとYYYYYを追加します。」 悲しいかな、VKontakteグループの次の日には、同じプレイヤーからのメッセージが既にありました。「開発者は、ゲームにはXXXXXがあると言っていました」、そして今、「いつXXXXXをしますか?」 あなたは約束しました!」プレイヤーからは定期的になりました。



ところで、Sergey Galenkinはマーケティングに関する優れた本で、プレイヤーとのコミュニケーションについて非常にクールな話をしており、とりわけ次のように述べています。「ソーシャルネットワークで代表オフィスを開設する場合は、質問に答えてテクニカルサポートを提供する準備をしてください。 プレイヤーはあなたにとって便利なツールを使用しません-彼らは常に彼らにとって便利なものを選択します。 私は世間で「ゲームの技術的問題」というトピックを作成したと単純に信じていました-私はそれらだけを見るでしょう。 種類はありません! 質問、コメント、レビュー、苦情はどこにでもありました:個人メッセージ、グループ内のニュース(質問のトピックとはまったく関係ありません)、そして私のプロフィールの個人写真の下のコメントです。 書くことへの欲求を感じて、ユーザーは投稿の形式があるところならどこでも書きます。



All Articles