新しいゲームを開発する際に考慮すべき最大の落とし穴は何ですか？

実際、数週間前にFacebook用の新しいWebベースのゲームをトレースし始めました（命名法の修正についてはDavid Youngに感謝します）。私はターンベース（ヴァンパイア戦争）スタイルのRPGに似たものに取り組んでいます。ゲームをコーディングするスキルはありますが、デザインパターンを正しくし、製品を自分の目に見えるものに一致させようと努力しています。

通常、ウェブサイトを構築するとき、「コードを考える」のが好きで、コード/ HTMLを変更して調整する方が速いと思います。これはおそらく、私がやることに非常に満足しており、何を期待しているのかを知っているからです私は何度も何度もやってきた。ゲーム開発のこの時点で、私は自分が再びウェブサイトで始めたように（ウェブサイトで使っていたように）自分がゲームロジックに焦点を当てず、直観に欠けているだけなのか、それとも考えを広げるのに適切な方法なのかと思いますコーディングの進歩。

この問題を正しく攻撃し、仕事を続ける方法についてのアドバイスをいただければ幸いです。ゲームエンジンが標準のビジネスWebサイトとどれほど違うかをすぐに学んでいます！私が何かを手に入れるたびに、それはただムーシーで不完全であると感じ、それはあきれた欲求不満になりつつあります。

延長

例として、私に非常に多くの問題を与えてきた戦闘エンジンは、最近単純な攻撃スキルを取り、-50％から+ 50％の間でランダムにロールし、元の攻撃スキルにそのパーセントを掛けます。同じことは防衛でも行われ、それからそれらをメッシュ化して、敵の健康に対してダメージが与えられているかどうかを判断します。それが正しい方法なのか、それとも「正しい」方法があるのか​​を自問し始めたとき、頭の上にいることに気付くべきだと思います。私がこれで見つけた1つの大きな欠点は、同じレベルの2人のキャラクターが複数の「ロール」を持つことができ、攻撃が-50％、防御が+ 50％であるため、誰も何もしない非常に長いバトルシーケンスになります。失敗します

たぶん、私の投稿は、単純なゲームロジックを説明する推奨リンクを求めていたはずです。

エンドエクステンション

よろしくお願いします！

追加する機能が多すぎます。ゲームのコアに焦点を合わせてビルドし、すべてがうまく機能したら機能を追加します。人々はクールなものを追加することに集中しすぎて、何も成し遂げることはありません。

これは、ゲームのプロトタイプの作成方法に関する素晴らしい記事です。あなたの質問から、あなたはプロトタイプがどうあるべきかの考えを逃しているように思えます。

プロトタイピング：あなたは（おそらく）間違っている

かすみ：

間違いその4：ゲームではなくシステムを構築する
プロトタイプを作成しているときに、直接前進しないものに取り組んでいることがわかった場合は、すぐに停止してください。プログラマーとして、私たちはコードを一般化し、エレガントにし、あらゆる状況に対処できるようにする傾向があります。かゆみはひっかき傷ではなく非常に難しいことがわかりましたが、その方法を学ぶ必要があります。コードではなく、最終的に出荷するゲームであることに気付くまでに何年もかかりました。

エレガントなゲームコンポーネントシステムを記述せず、エディターを完全にスキップしてコード内の状態を固定し、データ駆動型の自己解析的なXMLの狂気を避け、気の毒なことをコーディングするだけです。

編集：

PrototypeとTracer Codeの違いを明確にするために、これを追加しています。

常に覚えておいてください：プロトタイプは捨てられるように設計されています！トレーサーコードはそうではありません。

プロトタイプの落とし穴

...トレーサコードアプローチは、別の問題に対処します。アプリケーション全体がどのように連携するかを知る必要があります。インタラクションが実際にどのように機能するかをユーザーに示し、開発者にコードを掛けるアーキテクチャのスケルトンを提供する必要があります。この場合、コンテナパッキングアルゴリズムの簡単な実装（先着、先着のようなもの）とシンプルだが機能するユーザーインターフェイスで構成されるトレーサーを構築できます。アプリケーション内のすべてのコンポーネントをまとめたら、ユーザーと開発者を表示するフレームワークができました。時間が経つにつれて、新しい機能でこのフレームワークに追加し、スタブルーチンを完成させます。しかし、フレームワークはそのまま残り、システムは最初のトレーサーコードが完了したときと同じように動作し続けることがわかります。

この区別は、繰り返しが必要なほど重要です。プロトタイピングにより、使い捨てコードが生成されます。トレーサーコードは無駄がありませんが、完全であり、最終システムのスケルトンの一部を形成します。プロトタイピングは、1つのトレーサー弾丸が発射される前に行われる偵察および情報収集と考えてください。

The Pragmatic Programmerのトレーサーコード設計に関する詳細情報

トレーサーの箇条書きとプロトタイプ

落とし穴：ロジックをデータから分離しないこと。データが目的の結果を生成することをテストしません。

Joeの投稿に対するコメント：

モンスターとの遭遇のために戦闘エンジンをコーディングしてほしい、BOOM！今週少なくとも3回エンジンを書き直しましたが、気分が悪くなることはありません。つまり、数学は機能しますが、実際に試してみると奇妙に感じます。それは理にかなっていますか？

ここでエンジンとデータを混同しているようです。モンスターエンカウンターエンジンはデータによって駆動される必要があります。ゲームのバランス/ファンに影響するデータが間違っている場合、エンジンを完全に書き換える必要はありません。バランス変数を適切に調整するだけです。

ただし、バランス変数は相互依存している場合があるため、1つの変数をより良い1つのシナリオに変更すると、他のシナリオに大きな（負の）影響を与える可能性があります。

新しく調整したデータが他の多くのケースを破壊しないことをテストするために、いくつかのテストケースを保持し、調整後に破損しないことを確認すると便利です。これは、これをどのようにテストするかについて、明らかに不自然な例です。

TestResult TestPlayerKillsMonsterDuringAttack(PlayerStats, MonsterStats, seed)
{
   Player player(PlayerStats);
   Monster monster(MonsterStats);


EncounterEngine.SeedRNG(seed);

   while(1)
   {
     result = EncounterEngine.Attack(player, monster);
     if (result == PLAYER_DEAD)
       return TEST_FAIL;
     if (result == MONSTER_DEAD)
       return TEST_PASS;
     // result == MONSTER_DAMAGED, PLAYER_DAMAGED is expected. 
   }
}

例えば。PlayerStats.Level == 5およびMonsterStats.Level == 3でこれを呼び出すと、プレイヤーは最終的には常にこのモンスターを倒すことになるでしょう。

私が見る限り、ここでの落とし穴は、プログラミングとゲームデザインが実際には別々のタスクであるのに、同じタスクとして扱っているということです。ご提案のとおり、これはプログラミングやアルゴリズムの問​​題ではなく（バトルシステムは任意の方法でコーディングできます）、プレイヤーにとって面白くて面白いものです。

答えは、ゲームデザインとゲームバランスに関するリソースを調べることです。実際、あなたが提起しているトピックに4年間の学習プログラム全体を費やしている大学があります。そのため、あなたに迅速で汚い答えを与えることは不可能です（誰かが「ええ、私はゲームのためにこのアイデアを持っていますが、それをプログラムする方法がわかりません、私は何に気をつけるべきですか？」ゲームデザインについての本、コース、オンラインライティングがあります。それらを探します。

ゲームを作成する際の最大の落とし穴は、気分が良いコードを書くだけでなく、正しいデザインパターンを使用しているかどうかを心配することです。

時間管理と自発性に関するSteve Pavlinaの記事をお勧めします。http： //stevepavlina.narod.ru/

彼もプログラマーです。彼のライフスタイルの実験は、いくつかの主流メディアの関心を生み出しました。