ブラウザ開発-コンセプトレベル

ブラウザーゲームの開発に参加することに同意したその日、誰かが私にプロジェクトを公開するために生きるということを教えてくれたなら、私は神経質に笑い、信じられませんでした。 そして、プロジェクトの実際の立ち上げに先行するイベントのシーケンスを既にお伝えした場合、この間に実際に完了した作業量については何も言いませんでした。



ストーリーを続けて、私の部分の技術的な部分と他のチームメンバーからのプロジェクトの重要なポイントの両方を含む、隠れた開発の問題のいくつかを強調したいと思います。 考えを記録した結果、私は多くの資料を入手しました-前回よりもはるかに多いので、いくつかの段階でそれを公開します。 幸いなことに、論理的に簡単に破ることができました。



そして、最初の部分では、プロジェクトの基礎を築くことについて説明します。世界を創造し、ゲームの仕組みを考え、バランスを完璧にし、システムの秩序を維持します。 最初の部分全体は、プロジェクトコーディネーターの責任に完全に依存しています。 各イベントはそれを直接通過し、各アクションはその一部で正確にコミットされました。したがって、以下で説明するすべてはプロジェクトのコーディネーターの仕事です。

コーディネーターの仕事

私たちのチームのプロジェクトコーディネーターは、リンクの役割を果たし、役割を果たします。特定の変更が導入されるのは、彼の指揮と世界の構造の理解に基づいています。



たとえば、プロジェクトの最初から、チーム全体に対して、まず第一に、ゲームは実際のお金でゲーム通貨を購入するプレーヤーに完全な利点を与えないことが示されました-ゲームの各（またはほぼすべての）要素に対して、代替の生産ソースが提供され、使用する可能性がありますこのアイテムは到達可能です。 これまで、プロジェクトの「有料」通貨に固有の瞬間は2つしかありませんが、これでも、ゲームの「マーケット」でゲームアイテムを販売することで、直接支払いなしでCookieを取得できます。



プロジェクトが一般的に始まり、今日まで続いているのはこの人のおかげです。

世界の創造

すべてのプロジェクトはアイデアから始まりますが、一部のプロジェクトは基本的なアイデアだけでなく、詳細な説明、継続的な開発、内部「物理」による強化、および整合性を維持するためにあらゆるニュアンスの完全な考慮も必要とします。 私たちの目標は、そのような世界を作ることでした。 徐々に発展するが、最初から強固な基盤を持つ世界。



前の記事で、私たちのチームは旅の初めにアイデアの生成者としての希望を持った2人のコンセプトエンジニアがいることを既に述べましたが、プロジェクトの開発における彼らの仕事の説明にはほとんど注意を払いませんでした。 彼らは主に、そのようなプロジェクトのプレイヤーとしてすでに膨大な経験があり、言葉と行動でコーディネーターに彼のアイデアを「正しいか間違った方向に」伝えることができるという事実のために招待されました。 もちろん主観的ですが、初期段階では、意見や議論が多ければ多いほど、コンセプトは良くなります。



合計で、「ブラウザ」の内部構造を理解している3人の人がいました。



コンセプト形成の始めに、私たちは集団ブレーンストーミングのための共通のSkypeチャットを作成しました。そこでは、ゲームの世界を構成する可能性のあるアイデアが議論のために提出されました。 それはすべて、ゲームに誰を投入するかを決めることから始まりました-他のゲームの既存のアナログと重複しないいくつかのタイプのゲームキャラクターのセットが必要でした。 同時に、見つかったキャラクターのおかげで、プロジェクトのほぼ準備ができた名前が形成された可能性があり、さまざまな種類の鳥の使用に関する一般的な合意の時点で、プロジェクトはコード名「birdz」を受け取り、数か月後に「Pernatsk」に名前が変更されました 一意の単語、無料ドメイン。



通貨は同じ態度で発明されました-おそらくコインを除く通貨全体は、その時点で私たちが使用する組み合わせで他のプロジェクトで使用されるべきではありませんでした。 そして原則として、ゲームのほとんどすべての要素は、市場の既存の競合他社から遠く離れている必要があります。



通常のプロジェクトの立ち上げでは、アイデアが散在していても、実際には互いにつながりがなく、世界でバランスが取れていない場合でも、非常に多くのアイデアを獲得する必要があります。 モザイクのこれらの断片は、プロジェクトの一般的なマップに後で追加できます。途中で、多少不快な形で結合されているため、各断片のコーナーをファイリングします。



アイデアを書き留めるために、メッセージに「idea」という単語が表示されたときにメッセージの全体をwikiにコピーし、結果として生じるブロックをさらに分析することを期待して、Skypeボットを作成しました。 そしてそれは働いた。

意図的な専門用語

プレイヤーの集団が成長し、ゲームの特定のコミュニティが形成されると、プロジェクトの特定の側面を特徴付ける特定の略語または英語のセットがプロジェクト全体に広まり始めます。 さらに、この問題について事前に考えておくと、特定の名前がプロジェクトにのみ関連付けられ、他の名前には関連付けられないように、プレイヤーが予測し、当社に受け入れられる単語または組み合わせを使用するように指示できます。



ゲームのほとんどの要素について（意図的に体系的なリストの形式である場合、単純に思考の形式である場合）、特定の関連性と記述のバリエーションのセットが作成されました。 たとえば、ゲーム内で「ランダム検出」によってマイニングする必要のあるまれなアイテムの場合、最終的には「relic」という造語を公式名と間違えました。 。



評価のプレイヤーの「かっこよさ」を特徴付ける「フェザリング」は、アイコンの外部の類似性のために、一部のプレイヤーによって「卵」と呼ばれます。これは一般に、画像を無視すると、何らかの真の意味さえ持つ可能性があります。



ゲームの主な「ボット」-敵であり、攻撃者の特性に基づいてサーバーが計算した特性でいつでも攻撃可能-は「鉄の鳥」と呼ばれ、プレイヤーはそれを「鉄片」または「鉄片」と呼びます。



私は繰り返します-ゲームのこれらの瞬間を事前に考え、プレイヤーにオプションを提供し、ゲームの特徴として受け入れて、世界に小さな興味、必要なタッチとアクセントを与えることができます。

データの倉庫

すでにアイデアを書き留めるためにウィキを開いたと言いましたが、考えを整理して体系化することは、プロジェクトを直接作成することよりも重要です。



プロジェクトコーディネーターが自分でサイトを開発した経験があるため、ウィキには開発者向けの特別なセクション、アーティスト向けの特別なセクション、全員向けのセクションがありました。 管理パネルをすばやく作成するために、目の前に膨大なキャラクタープロパティのリストがありました。データベースに押し込み、途中で正規化して適切なアーキテクチャを構成しなければなりませんでしたが、私は常に楽しい仕事の基礎を持っています。



Wikiの記事は、2、3段階に分けられました：コンセプトデザイナーによる主なアイデアのスケッチ、読みやすい外観（文への分解から機能の追加作業条件の導入まで）、実装の技術的要件。 プロジェクトコーディネーターは、人とサイボーグとのつながりである一種のC3POとして私たちのために働き、コンセプトデザイナーからの作業のコードへの感情の流れを翻訳するのを助けました。



ゲームには、Biblioセクションがあります-ウィキのイデオロギーの後継者：各場所、各アクション、インターフェイス要素の説明。 wikiの開発の最初の組織は始まりとして機能し、原則として、ゲーム内に知識ベースを作成するというアイデアを導入しました。



6か月間の開発の後、アルファ版とベータ版を起動する準備ができているはずの機能セットを特定しました。

少し秘密をお伝えします。現時点で計画されているすべての機能（パブリックベータ版）のうち、約70％が実装されています。 なぜそう 答えは簡単です。最終的に、力や理由を失うことなく、考えていたすべてを実行することはできないという結論に達しました。 要件の一部が削減され、他の部分は「開始後」に移動しました。 ただし、その時点で作業の過程で利用可能なリストに、失われた機能のボリュームをカバーする追加の重要なモジュールが追加されました。

システムハート

ゲーム内で少なくともいくつかのアクションを作成する前に、主なパラメーターを決定する必要があります。これから、ほとんどすべてが将来計算されます。 まず最初に、キャラクターの特性のリストを作成し、このパラメーターまたはそのパラメーターが持つセマンティックロードを決定する必要があります。 この場合、5つの特性が特定され、さらに2つの特性が追加されて、さらに複雑な要因が導入されました。



実際、システムのソースコードの一部をデモンストレーションするように依頼された場合は、1つだけを除いて、問題のない人を表示します-数式を含むクラスです。 1つのファイルがゲームの作業ロジック全体とバランス全体を形成します。この特定のファイルは、バランスをデバッグするプロセスで絶えず変更および補足されています。 そして、一般的にそのようなファイルまたは任意の1つの計算式を作成するには、プレーヤーの望ましい動作を決定する必要があります。



以下に、概念と可能な実装の例を示します。 この例は実際のものではありません。



「新しく登録された」プレーヤーを最初のレベルで、これに興味を持ってちょうど1つの「仕事」の日を維持したいとします。 これを行うには、「科学的な突っ込み」の方法により、プレイヤーが1日に50バトルを行い、各バトルで正確に1ユニットの経験が必要であると判断します。したがって、第2レベルを達成するには、プレイヤーは50の経験値を獲得する必要があります。 1日にさらに多くの戦いを行うことを不可能にするために、戦いの間の時間遅延を決定します-10分のリアルタイムに同意します。 タイマーを常時監視しながら、1日合計8時間、プレーヤーは48経験値を獲得します。



次に、どのような種類の戦いが見たいのか、そしてどのような戦いがその中に存在すべきかを決定する必要があります。 戦闘で敵にヒットしたり、重大なダメージを与えたり、ミスしたり、一撃をブロックしたりできるとしましょう-この「イベント」のセットは、レベルを上げずにプレイヤーの特性を変更することでイベントの数を調整できる頻度で戦闘に組み合わせる必要がありますそのようなイベントの制御されない数。 「イベント」のそれぞれについて、どのプレイヤーパラメーターがその開始に直接影響するかを暫定的に推定する必要があります。



重大な損害を引き起こすという事実のために、攻撃者の「精度」の値と防御者の「直感」の値が必要であると仮定できます。イベントの結果は、これら2つのパラメーターの組み合わせに依存する必要があります。 打撃の強さは、同じ名前の攻撃者の特性の値と、防御者の「防御」特性の値に依存します。 そして、再び、私たちは、10ラウンドの1回の戦闘で、そのような攻撃を1-2回見たいと思っています。



同様の作成パスが、他のすべての必要なイベントを通過します。



その結果、多数のそのような「仮定」から、戦闘におけるキャラクターの行動の最初の絵が形成され、その後、私たちが正確に得たいものに応じて調整されます。



今日、プレイヤー間の決闘のための多数の数式計算モデルがあります。 しかし、独自の何かを作成すると、実際に指を空に突っ込みます-調整、分析、実験します。



キャラクター自体の特性を向上させるには、通貨を使用します。通貨も何らかの方法で抽出する必要があります。 そして、プレイヤーが特定のレベルで改善できる特性の数を制限したい場合、特定の期間の生産に必要かつ十分な通貨の量を見積もることができます。



たとえば、最初のレベルでは、特性の値をすべての点で（使用した金額で）1から10の制限に制限できます。 2番目のレベル-10〜25、3番目のレベル-25〜40など。したがって、高レベルでは、データベースフィールドのインターフェイスと一般的な制限に必要なインジケータが含まれます。







次に、各レベルでキャラクターの動作をシミュレートする必要があります。これには、プレーヤーから時間がかかるすべての作業要素が含まれます。 同時に、活動レベルの可能な「不均衡」を事前に予測することは非常に重要です。 理想を達成することは不可能ですが。 さらに、ゲームの式にランダムな値を入力して、戦いの計算、リソースの抽出、および他の式の依存関係が線形ではなく、期待によって制御されるようにすることができます。



多くのことを考え、想定する必要があります。実際に仕様が存在しない場合、あらゆる種類の相互接続の巨大な画像が得られます。システムの一部を調整するために、それを覚えておく必要があります。



散在する情報の断片、基本的なパラメーター間の豊富な関係、多くの時間の議論、主要なプレイヤーのモデルの編集の後、式を自分で書き、それを実践する時です。



私たちの場合、プロジェクトコーディネーターは個人的に式の要約分析を作成しました。パラメーターを入力するための数十のフィールドを持つ巨大なページで、1つのボタンを押すことで、特定の特性値で数百の戦闘を計算し、リソース抽出モデルを作成しました。 計算の最後の「排気」が分析され、係数が修正され、計算が再開されました。 このような係数の選択と式の種類は、管理パネルの主要なモジュールが開発され、イラストの一般的な概念が作成されている間、ほぼ2か月かかりました。



解決され、現在も解決されている主なタスクは、レベルの成長とともに開くミニゲームと追加の機能を考慮してキャラクターが均等に開発されたときに、リソース抽出、経験の獲得、ごちそう、戦闘の特性と構造の増加のバランスをとることです。



パブリックベータテスト中に、残高が不快で誤って実行されたという事実に関して、いくつかの否定的なレビューを受けました。 プレイヤーの議論は、彼のキャラクターは、現在の「ビルドアップ」中の決闘のすべてのケースで、敵の打撃をかわす義務を負っているだけだということでした。 ちなみに、プレーヤーは獲得したすべてのお金を1つの特徴的な「器用さ」に完全に投資し、彼のアプローチが唯一の真の方法であることを証明しました。 私たちのバランスの理解は他の原則で構成されており、公式はキャラクターの成長の一般的な理解に適応し、本質的に不均衡である完全な勝利状況を得るための率直な「歪み」ではありません。



そのような式の多くの「ランダム」による憎しみは最小限に抑えられましたが、完全には消えませんでした。 特性は、ランダム変数のリミッターと乗数であり、唯一の計算要因ではありませんが、2つのキャラクター間の1つの特性の巨大なバイアスは、ランダム変数の範囲にうまく入る可能性にのみ影響を与えるため、実際の勝利を保証するものではありません。 フォーミュラの定式化に対するこのアプローチにより、同じキャラクター間の2回の戦いが毎回異なる方法で行われ、より強力な敵に勝つチャンスが残ります。



これまで、プロジェクトコーディネーターの主な責任は、意図された目標から離れたわずかな変動とプレーヤーの望ましい行動を特定するために行われる戦いを常に監視することです。 ベータテストを通して、式に適切な調整が行われ、バランスが調整されます。 ベータが開始される前にシステムに導入された最後の機能の1つは、ある程度の周期で集約された300を超えるインジケータの大きなレイヤーの収集であったことに注意する価値があります。 さらに、ゲーム内での資金やインジケーターの支出または受領に関連する各アクションに対して、個別のログエントリが作成されます。 これらの2つの大きな追跡ツールにより、ユーザーアクションの理解を調整し、それに応じてバランスを正しい方向に変更できます。



ブラウザゲームの無料の特性評価を行おうとすると、これは「一種の大きな工学計算機」であり、グラフィックスが少し「味付け」され、プレイヤーは膨大な数の未知数を含む方程式の大規模なシステムを解こうとします。 これらは、「突っ込む」方法を解決し、パラメータの変化による環境の動作の一般的な変化を分析します。 同時に、政権は、方程式に対する既成の仮の解決策を使用して、方程式系の形で数学モデルを作成しようとしています。 一般に、これは思考であり、数学者を何らかの形で作業に関与させる必要があるでしょう。

チームスター

プロジェクトコーディネーターは、世界を創造するための基本的な責任に加えて、チーム内で適切なつながりを築くという全責任を負っていることを忘れないでください。 同時に、すべてのチームメンバーが何らかの形で互いに連絡することは絶対に必要ではありません。さらに、私はグループ内での一般的な会話を避けて個人的に意図的に踏み出しました。これは私のキャラクターの特徴であり、コーディネーターは私の行動を通常どおりに受け入れ、許容できる。 これにより、プロジェクトの私の部分で冷静に作業することができ、現在の社会の深byに入らないようになりました。



コーディネーターと彼の魔法の能力のおかげで、人々を有利に配置することができたので、私たちはチームとして組織し、バラバラにならずに将来働くことができました。 はい、一部は私たちを去りましたが、これらの損失はコーディネーターによって排除され、プロジェクトはその場で止まりませんでした。



私たちのプロジェクトは当初から長期的なものとして計画されていたため、完全なガイドラインの欠如でそれを行うことはできませんでした。 どんな計画であっても、不可能な計画であっても、一定の自信と目標を与えて努力することができます。 そのため、世界を作成するアイデアを考えて整理した後、プロジェクトの各段階（プレアルファ、アルファ、クローズドベータ、オープンベータテスト、発売）のおよその発売日を承認し、準備が必要なモジュールの詳細なリストを作成しました。

地獄と肉挽き器

サーバーとシステム全体が負荷を増やすことでどのように動作するのかわからなかったため、どのユーザーのしきい値を重要と見なす必要があるのか​​、ベータテスト中に、ゲームに登録するための必須の招待状の存在を入力することにより、雪崩の可能性から身を守りました。



実際、実際の具体的な「ハブラー効果」は、言葉の直接的な意味では発生しませんでしたが、状況は予想よりもはるかに良かったです。 私は謙虚にレプリカを待っていました。「もう1つのブラウザ」-プロジェクトにほとんど関心がありませんが、わずか数日で登録者の数は発行前の状況に比べて10倍近く増加し、180〜1600人になりました。 現在、サーバーは1秒あたり4〜12リクエストの「負荷」の下にあり、実際にはこれに気付かないため、平均CPU負荷は約4％です。



しかし、それは私たちが自分自身を守ると仮定した「ハブラー効果」ではありませんでした。 プロジェクトの主な爆発は、議論、推奨事項、タイプミスに関する報告書、そして私たちが加速したペースで最初の週に解決しようとしたエラーでした。 ユーザーとプロジェクトの間の6つのコミュニケーションチャネルがあります-内部サポートサービス、外部サポートサービス（メールボックスの着信レターを含む）、「pvitter」、フォーラム、ニュースに関するコメント、プライベートメッセージ。 これらの各通信チャネルには、ユーザーを不明瞭にしないために迅速に処理する必要のあるデータが完全にロードされています。



初期の頃、プロジェクトコーディネーターは実質的に睡眠をとっていませんでした-就寝しようとしていると言っても、最終的にユーザーの質問に答え続けました。 私の性格上、「高速モード」で簡単かつ簡単に人々とコミュニケーションを取ることはできません。 そして、自分のスタイルを無視してメッセージを書くことはできません。それは、誰もが軽視やeveryone慢さを見ずに適切に理解できるわけではありません（ただし、これは当時の現実と私の本当の考えに対応しません）。 したがって、この状況でできることは、「バグ」を修正し、インターフェイスに改善を加え、ユーザーと実際に連絡することなくユーザーの希望を満たすことだけでした。



しかし、コーディネーターは一人ではありませんでした-アルファテストの開始以来、私たちのチームに加わった「閉塞」の分析で二人が彼を助けに来ました。 そして、ベータテストの開始以来、チームは再び拡大し、現在8人のスタッフがいます。ゲームの管理者とモデレーターを獲得しています。



間違いなく、ベータテストはプロジェクトに大きな利益をもたらしました。 「バグ」を捕まえることと、プレイヤーと通信することの両方。

遠心分離機でリス

プロジェクトに導入された新しい更新プログラムのたびに、コーディネーターの頭に置くべき情報と知識の量が増えます。 プロジェクトで何をしているのかを知る必要があるという事実に加えて、ユーザーと管理者が行うすべてを確認し、繰り返し質問に答え、予想外のあらゆるアクションを監視し、「バグ」または改善のリストを作成する必要があります-これは毎日ですプロジェクトコーディネーターが実施する最小限の監視。



そして、このトピックについてはすでに多くの資料が書かれているので、リーダーは常に24時間働いています。この場合、これは現実を完全に反映しているだけでなく、実際に私たちの状況から削除されています。 理論的には、この問題を解決するために必要なことは、プロジェクトの資金源を見つけ、本格的な従業員に基づいてタスクを完了することができる多くの人々を引き付けることです。 ただし、資金調達の検索には、まず、一時的なリソースの大規模な投資（「スタートアップパーティー」、プレゼンテーション、投資家への祈りなど）が伴います。オッズ。



奇跡やチームの他の人々を完全に期待し、その責任を誰かに移すことは不可能です。 プロジェクトモジュールの記述をコーディネーターに渡すことができないのと同じように（開発の経験があるにもかかわらず）、コーディネーターはシステムコンセプトを作成する責任を私に委任することはできません。 加えて、私の仕事とその品質には平凡なjeがあります-私は私たちを助けるためにプログラマーを探し続けるかどうかを何度も疑問に思いましたが、私を止める主な疑問は残ります： 「彼は汚いトリックをしますか、彼はモジュールを間違って書くでしょうか、それとも何か他のものですか？」



仕事のすべての量について、あなたは何らかの形で家族、個人的なリラクゼーション、および主な仕事のための時間を見つけなければなりません。 目の下の袋が現れ、朝のアラームの数が2桁の数字に近づき、夢の中で、覚醒中に生じた問題の解決策が求められています。



最も興味深いのは、文字通りHabréの最後の記事の数日前に、この状況は観察されなかったが、新しい登録ユーザーごとに、プロジェクトの作業量と責任が予想外に増加したことです。そして、これはすべて、見知らぬ人から「誰かとの会話でのプロジェクトについての言及」を聞くことを望み、そしてもちろん、この事業全体がすでに獲得した経験の巨大な荷物に加えて、さらなる利益をもたらすことを期待して行われます。

そして、私も刺繍することができます...そしてタイプライターにも

ベータテストの最初の1か月で個人的には期待していなかったのは、見返りに何も要求せず、開発チームの場所を要求せずに、「プロジェクトのために驚くべきことを突然行う」準備ができている人々の姿です。



プロジェクトのフォーラムに参加したプレイヤーは、理由もなくゲームやコンテストの一種の「リーダー」になりました。定型化されたテキストを書き、獲得した「富」そのものを配り、「文化イベント」のためにプレイヤーを組織しました。同時に、プロジェクトの管理者は誰もそのようなプレーヤーを見たことも聞いたこともありません。その理由と理由を誰も理解しておらず、彼の努力を助けられないことを恥ずかしく思います。



以下は、コンテストの開催時に「Mad Owl」のコンテストのトピックを表示しているユーザーのリストの例です。







将来、同じプレイヤーがソーシャルイベントの優れたコンセプトを作成しました。プロジェクトコーディネーターとのこのアプローチに慣れていませんでした。私たちを去ったコンセプトエンジニアを思い出して、彼らの仕事は質的に行われたマッドフクロウの仕事と比較することはできませんでした。



さらに、新年の更新の前夜、サポートサービスは別のプレイヤーから予期しないオファーを受けました-ゲームの冬のデザインのレンダリングを支援するために、既に準備されたアウトラインとビジョンがゲームのスタイルに応じて正確にターゲットに到達しました。



完全に見知らぬ人のこうした行動は、プレイヤーのコミュニティが私たちのプロジェクトに興味を持ち、プロジェクトを必要としているという「少し」多くの希望と自信があるため、働く意欲の新たな部分を与えることがあります。

世論

このプロジェクトは開発者向けではなく、プレイヤー向けであるため、ユーザーの意見が問題解決に大きな役割を果たすことがあります。もちろん、すべてのユーザーが耳を傾ける必要があるわけではありませんが、すべてのユーザーを無視できるわけではありません-論証、問題文の正しさ、現象の質量の性質、およびプレゼンテーションの妥当性は、特定のレビューを綿密に調べるための主要な指標です。



プレーヤー向けのオープンフォームでのプロジェクトのわずか1か月で、多くの変更が行われました（修正、インターフェイスの改善、論理的および定式的なコンポーネントの改善）。レベルを取得するために必要な経験の量が変更され、ほぼすべてのページのインターフェースが改善され、他のプレーヤーを攻撃する条件が変更され（弱いプレーヤーの「ビート」が制限されました）、「パック」に参加する可能性が低いレベルにシフトされました。



プレイヤーによる開発プロセスへの影響の可能性の事実は、プレイヤーからプロジェクトへ、そしてプロジェクトからプレイヤーへの二国間の忠誠心として認識されています。ベータテストプロセスでは、ミニゲームから大規模なアクションを備えた本格的なゲームロケーションまで、世界のさらなる発展のためにプレイヤーに多くのオプションが提供されました。提案されたアイデアのいくつかは既に計画されていましたが、別の部分は開発可能な追加のアイデアとして受け入れられます。



競合するプロジェクトの管理者も私たちを放置しませんでした-私たちが知っているメールアドレスで登録がありました。競合状況は発生しませんでしたが、競合他社からの関心のある事実は喜ばしいことです。



実際のレビューに加えて、間接的なフィードバックもありました。まさに「新年」について、プロジェクトの販売を申し出ました。提案された金額は、投資された労働力に比べて不釣り合いに少なかったため、取引を拒否しましたが、このプロジェクトにも一定の誇りを感じました。

試験期間

一般に、ベータテストの主な目的はコードエラーの検出ではなく（多くの修正もありました）、それにもかかわらず、有能なゲームベースの作成です。この開発段階では、バトルフォーミュラの不正確さ、報酬の計算、特性のコスト、「フェザード」を獲得するための条件など、他のプレイヤーに対するアドバンテージの容易な達成に直接影響するゲームの瞬間を特定することになっています。



クローズド開発の過程で作成された各理論は、プレイヤーの望ましい行動に応じて検証および修正する必要があります。プロジェクト全体がこのような仮定と未定の定理に基づいているため、実際の起動は事実上不可能です。



たとえば、年末年始には、すべてのプレイヤーに「フェザード」の再計算の大きな段階があり、計算式の予備調整が暗示されました。届きにくい統計ユニットの要件は、届きにくいものについては増加および減少し、難易度はユーザーの完全なゲームの1か月の結果として特定されました。同時に、実際の複雑さはプロジェクト全体の統計レポートに基づいて推定できます。たとえば、すべてのユーザーの特定のインジケーターの平均値のアイデアを提供できます（インジケーターの予想される複雑さを確認または反論することができます）。



プロジェクトの数式の調整に加えて、プロジェクトのロジックに関連するエラーが特定されます。これは、プレーヤーの目標の達成に直接影響します。たとえば、「ローカル」通貨のミニゲーム（「スケールラック」と呼ばれる）があり、通貨単位がライン上に置かれ、プレーヤーは提示された5つのクローズドオプションの中から「重い」アイテムを推測しようとします。 。このミニゲームは、一定数の勝ちに対する追加のグローバル報酬を意味し、各グローバル報酬には、「購入」スキルに費やすことができる追加のプレーヤーポイントが含まれます。したがって、プレイヤーが繰り返しミニゲームで勝利した場合、スキルを向上させるための追加の機会を得ることが保証されます。時間が長い場合（またはゲームボットを作成する可能性がある場合）、報酬を得るのは難しくありません。この場合、ユーザーが1日で利用できるミニゲームの数を制限し、ユーザーが目的のプラスポイントをすばやく簡単に取得できるようにすることが正しい判断でした。



明らかな理由により、ベータ版のテストでその「成果」のセットを使用してゲームを続行することはできません。一部のプレイヤーはパイの一部をつかんで、システムの不完全性に気づきましたが、他のプレイヤーはそうしませんでした。悲しいことではありませんが、3月までにゲームの進行全体が完全にキャンセルされます。例外として、私たちと過ごした3か月のインセンティブとして残されたいくつかの指標は例外です（もちろん、基本原則を理解している人々自身の蓄積された実際の経験レベリング「キャラクター」。プロジェクトの現在の段階の運命については、登録時の手紙を通じて誰もが警告されましたが、これがプレイヤーがプロジェクトを離れる理由として役立たないことを願っています。

2年間の人生はどこに行きましたか？

, , – , , , . – . , , .



– – , , – .



- , . - , , , – , , . , - – , , , .