だまされる必要はありません。1日でゲームを書くのは現実です。 さて、多分あなたはそれからキャンディーを作らないでしょう、多分それの中にたくさんのバグがあるでしょう...しかし、もし明日プロジェクトのプロトタイプを見せる必要があるなら、手に握って-そして行ってください！
当初、計画は次のようなものでした（すべてはC＃、WindowsForms、グラフィックス-GDI +、サーバー-WCFで記述されています）。
- ラビリンス生成アルゴリズムに対処する（または、より正確には、前述のフラッシュドライブを逆コンパイルし、そこからコードをバタンと鳴らす）。
- 全部+ 1（今のところ-あなたの）戦車を描きます。
- タンクを動かします（元のゲームと同じです）。
- 迷路をクライアントに配布するWCFサービスを接続します。
- 2番目のタンクをサービスに追加し、プレイヤー間の動きを同期します。
- 発射物の飛行を追加します。
- データベースを固定し、スケジュールを完了し、WindowsフォームからWPFにプロジェクトを転送します。
ご覧のとおり、計画は非常に詳細ですが、これが行動への明確なガイドであると言うにはまだ十分ではありません。 あなたは生きることができますが。 将来を考えると、結局のところ、それは不可能です。 私たちはそれから始めませんでした...
私たちには十分な時間-3週間がありましたが、変更が行われる4日前に座ったので（そう、そう、そう、ここでは必要ありません...） 投稿が「1日でゲームを書く方法」と呼ばれるのはなぜですか？ 実際、ある日それを書いたからです。
ラビリンス
困難はほとんどすぐに始まりました-しかし、迷路を生成する方法は？ ラビリンスは簡単ではありません。Ellerのアルゴリズムはここでは適切ではありません。 これは「理想的な」迷路ではなく、1つの障害物の周りに多くの経路があり、閉じた領域を含むことができます。
元のゲームを逆コンパイルしても何も得られませんでした。 コードは読めませんでした。 むしろ、それは読みやすいですが、作成者が私たちのような職人がいると推測したか、逆コンパイラが曲がったコードを取得したかのどちらかです...時間が不足していました。 私は自分で考えなければなりませんでした。
数時間の思考とたくさんのお茶の後、「再帰」という言葉が私の頭の中にきらめき、アルゴリズムが発明されました。 コードでは、迷路はMazeCell構造体の2次元配列で表されています。この配列には、セルの下側境界線と上側境界線の2つのフィールドがあります（両方のフィールドは単純ブールで、最初はtrueに設定されています）。 あとでコードを投稿するかもしれませんが、今のところその本質を説明します。迷路を構築する必要はありませんが、それを壊します。 つまり 最初に、迷路内のセル（部屋）の数を決定し、それらのすべての障害を設定します（両方のフィールドがtrue）。 次に、タンクがある2つのセルを決定します。 前提条件は、あるタンクから別のタンクへの直接アクセスです。 マップ上に囲まれたエリアが存在する場合がありますが、戦車はエリアの外側、またはその両方がエリア内にある必要があります。 したがって、再帰が作用します。次のセルをパラメーターとして渡し、右のタンクのセルを左に移動します。 タンクに着くと、同じルートに戻りますが、通過するセル内の必要な壁はすでに破壊されています。
そして最後に、最終段階-迷路を通り抜けて（これは通常の2次元配列であることに注意してください）、ランダムなセルのランダムな壁を破ります。 すべて、迷宮は準備ができています、あなたはそれを描く必要があります、全く些細なこと！ アルゴリズムは数日後に実装されました。 それが私たちが1日間ゲームを書いた理由です。
ムーブメント
描画には特別な困難はなかったので、書くことは何もありません。 それが問題です-動き...戦車を斜めに動かすことはそれほど簡単ではありませんでした。 率直に言って、これを行う時間はありませんでした。 むしろ、彼は斜めに動きますが、彼がこれを行う方法は見ないほうが良いです。 さらに、方向を変えると、タンクは所定の位置で0.5秒間フリーズし、その後必要な場所に移動します。 理論をテストする時間とツールはありませんでしたが、タイマーでキャッチする必要がありますが、これはKeyDownフォームのイベントでボタンの押下を処理したためだと思います。
WCFサービス、第2戦車、プレイヤー間の動きの同期
これが問題の始まりです。 後で理解したように、この時点から作業を開始する必要があり、その下ですでに迷路、顧客、その他すべてを調整する必要がありました。それが理由です。 主な問題は、2次元配列です。 WCF は2次元配列では機能しません 。 リスト<MazeCell []>でこの奇跡を作り直すために、かなり倒錯しなければなりませんでした。 さて、アーキテクチャを変更することに決めた場合、通常の配列を作成する方が簡単です。 エラーを見つけるのに長い時間がかかりましたが、それを修正するにはさらに時間がかかりました。
迷路のほぼすべてのクラスを書き換えることは時間でもエネルギーでもなかったため、必要に応じてリストを配列に展開し、結局は折りたたんでリストに戻す小さなラッパーを作成しました。 しかし、それだけではありません。WCFには、作業中に偶然見つけた落とし穴がたくさんあります。 練習がなければ、あなたは確かにそれらを見つけるでしょう。 これには、サービス側のストリーム、コントラクトのさまざまなパラメーター、およびクライアントへのカスタムクラスの転送が含まれます（注意！そのようなクラスにはメソッドがないことを忘れない人は、これは単なるデータコントラクトです！） 一般的には楽しかったです。
次に、座標について。 迷路全体をクライアントからクライアントに転送するのではなく、可変特性（タンクの座標）のみを転送することにしました（そして正しく実行しました）。 戦車が去り、座標が変更されました-敵に新しい位置を送信し、彼のクライアントはすべてを再描画します。 また、シェルを使用することを計画していました。
完了：データベース、グラフィックス、WPF
私たちは一日中、ほぼ一晩中ゲームに座っていました-私は朝3:30に寝ました すでにほとんど鼻をキーボードに埋めていて、何も考えませんでした。 私の友人はもう一時間座って寝ました。 午前9時に割り当てられた保護。 3:30までには、クライアントとサーバーがほとんどありました。 ベース、通常のグラフィックス、WPFを追加することはできませんでした。 プロジェクトを提出しましたか？ いや サービスでつまずきすぎた 私たちはこの分野であまり練習をしていません。たくさん実験しなければならず、多くの時間を費やしました。 しかし今、私たちはほとんどWCFの専門家です。
ペーパーという用語については、彼らは私たちをトップ3に入れ、アイデアは非常にクールであるが、実装は不十分であると述べています（そして、それを否定しません）。 しかし、そのようなプロジェクトを1日で渡すことは可能ですか？ はい、以上。 どんなに些細なことでも、主なものは自分への信仰です。 そして、作成する欲求。 作業中、「非常にありそうもない」を3回、「不可能」を2回作成しました。 「不可能」にゲーム自体に帰することができます。 はい、私たちは（学習の意味で）約2年間コーディングを行ってきましたが、これはこの規模の最初のプロジェクトです。 到着したとき、私たちはゲームの書き方をまったく理解していませんでした。 むしろ、私たちは何かを理解しましたが、私たちにとってはそれは不可能でした。 しかし、自分を信じようとすると、不可能なことさえ現実になります。 少し時間がかかるかもしれません。 WCFサービスからクライアントへの2次元配列の転送も、同じ「不可能」に起因する可能性があります。 はい、直接行うことはできませんが、いつでも何とかすることができます。 そして、「1日でC＃を学ぶ」ことについて...もちろん、あなたは学ぶことを学ぶことはありませんが、極端な状況では、問題の核心に素早く入り込み、経験を積むことができます。
日中、私たちはものすごい量の仕事をしました。さらに、これは私の小さな誇りの機会です。 それでも、私たちはゲームのプロトタイプを作成し、1日でそれを行いました。 より実践的なスキルがあれば、通常のベースさえ固定することができたでしょう。 負の経験も経験です。現在、計画、システム設計、WCFサービスに関する多くの知識があります。
幸運を祈ります。主なことは、恐れることなく試してみることです！