アーティストではない場合のゲームの作成方法

すべてのプログラマーが面白いゲームを作りたいと思った瞬間がありました。 多くのプログラマーはこれらの夢を実現し、さらには成功しますが、これは彼らに関するものではありません。 それは、ゲームをプレイするのが好きな人、知識や経験がなくても一度ゲームを作成しようとして、世界的な名声（および大きな利益）を達成した孤独なヒーローの例に触発されたが、彼は余裕がないグルイグロストロヤと競います。



しないでください...

小さな紹介

すぐに予約します。私たちの目標はお金を稼ぐことではありません-このトピックに関する多くの記事がHabréにあります。 いいえ、夢のゲームを作ります。





多くの人は、ゲームは時間と労力の無駄であり、真面目な人はこのトピックについてまったく話すべきではないと考えています。 しかし、ここに集まった人々は深刻ではないので、私たちは部分的に同意します-あなたがそれらをプレイする場合、ゲームは本当に多くの時間がかかります。 ただし、ゲームの開発には何倍も時間がかかりますが、多くのメリットがあります。 たとえば、ゲーム以外のアプリケーションの開発には見られない原則、アプローチ、アルゴリズムに慣れることができます。 または、ツール（たとえば、プログラミング言語）を所有するスキルを深め、異常で刺激的なことを行います。 自分でゲーム開発（成功しなくても）は常に特別で比類のない体験であると付け加えます（そして多くの人が同意します）。それを恐怖と愛で思い出します。



私たちは、最新のゲームエンジン、フレームワーク、ライブラリを使用しません。ゲームプレイの本質を見て、内部から感じます。 柔軟な開発方法論は放棄します（1人の作業を整理する必要があるため、タスクは簡素化されます）。 サウンドのデザイナー、アーティスト、作曲家、スペシャリストを探すために時間とエネルギーを費やすことはありません-私たちはできる限りのことをすべてします完成したフレーム上のグラフィック）。 最終的には、ツールを実際に研究して適切なツールを選択することすらしません。使用方法がわかっているもので実行します。 たとえば、Javaの場合、後で必要に応じてAndroid（またはコーヒーメーカー）に転送します。



「ああ!!! ホラー！ 悪夢！ どうしてそんなナンセンスに時間を費やすことができますか！ ここから出て、もっと面白いものを読んでいきましょう！」



これはなぜですか？ つまり、車輪を再発明しますか？ 既製のゲームエンジンを使用してみませんか？ 答えは簡単です。彼については何も知りませんが、今はゲームが欲しいです。 平均的なプログラマーの考え方を想像してください。「私はゲームを作りたい！ 肉、爆発、ポンプがあり、 コロバニーを奪うことができ 、プロットは爆撃され、これは他のどこでも起こったことはありません！ 私は今すぐ書き始めます！ 今、私たちに人気のあるものを見てみましょう...ええ、X、Y、Z。Zを取り、誰もが今書いています...」。 そして、エンジンの研究を開始します。 そして、彼はそのアイデアを投げます。なぜなら、それにはすでに十分な時間がないからです。 フィン。 または、大丈夫、それはあきらめませんが、実際にエンジンを学習することなく、ゲームに取り入れられます。 まあ、その後、彼は誰にも彼の最初の「工芸品」を見せない良心を持っています。 通常はそうではありません（アプリケーションストアに行って、自分で確認してください）-まあ、まあ、私は利益を望み、耐える力はありません。 かつてゲームの作成は熱狂的な創造的な人々でした。 悲しいかな、この時間は取り返しのつかないほど過ぎました-ゲームの主なものは魂ではなく、ビジネスモデルです（少なくともそれについての会話はもっとたくさんあります）。 私たちの目標はシンプルです。魂でゲームを作ります。 したがって、ツールから抽象化し（誰でも実行できます）、タスクに集中します。



それでは、続けましょう。

私自身の苦い経験の詳細には触れませんが、ゲーム開発におけるプログラマーの主な問題の1つはグラフィックスだと言います。 プログラマーは通常、描画の方法を知らず（例外はあります）、アーティストは通常​​、プログラミングの方法を知りません（例外はあります）。 そして、グラフィックがなければ、あなたは認めなければなりません、まれなゲームはバイパスされます。 どうする？



オプションがあります：















後者について詳しく見ていきましょう（一部は他の人ほど気のめいるように見えないからです）。 経験の浅いゲーマーの多くは、クールでモダンなグラフィックのないゲームはプレイヤーの心をつかむことができないと考えています。ゲームの名前でさえゲームに変えることすらできません。 ADOM 、 NetHack 、 Dwarf Fortressなどの傑作の開発者は、そのような議論に暗黙的に反対しています。 外観は常に決定的な要因ではありません。ASCIIを使用すると、いくつかの興味深い利点が得られます。

• 開発の過程で、プログラマーはゲームプレイ、ゲームの仕組み、プロットコンポーネントなどに焦点を当て、些細なことに気を散らすことなく;
• グラフィックコンポーネントの開発にはあまり時間がかかりません。動作するプロトタイプ（つまり、理解できるプレイするバージョンですが、続ける価値はあります）は、はるかに早く準備できます。
• フレームワークとグラフィックエンジンを学ぶ必要はありません。
• ゲームを開発する5年間でグラフィックスが陳腐化することはありません。
• 筋金入りの労働者は、グラフィカル環境を持たないプラットフォーム上でも製品を評価できます。
• すべてが正しく行われていれば、クールなグラフィックを後で固定できます。

上記の長い紹介は、初心者のイグロデロフが恐怖や偏見を克服し、心配をやめ、それでもそのようなことをしようとするのを助けることを意図しました。 準備はいい？ それでは始めましょう。

最初のステップ。 アイデア

どうやって？ まだわからない？



コンピューターの電源を切り、食べに行き、散歩し、運動します。 または最悪の場合、眠ります。 ゲームを思い付くということは、窓を洗うことではありません-プロセスの洞察は得られません。 通常、ゲームのアイデアは、まったく考えないときに突然、予期せずに生まれます。 これが突然起こった場合は、鉛筆をより速くつかみ、アイデアが消えるまで書き留めてください。 クリエイティブプロセスはすべてこの方法で実装されます。



そして、他の人のゲームをコピーできます。 まあ、コピー。 もちろん、あなたがどれほど頭がいいかを隅々まで言って不敬に戦うのではなく、あなたの製品で他の人の開発を使ってください。 多くの場合、ゲーマーはこれを持っているので、これがあなたの夢から具体的にどのくらい残っているのでしょうか？彼らはいくつかの迷惑なことを除いてゲームのすべてを好きですが、それが異なって行われた場合...誰が知っています誰かの良いアイデアを思い浮かべるのはあなたの夢でしょう。



しかし、私たちは簡単な方法で進みます-私たちはすでにアイデアを持っていると仮定し、私たちは長い間それについて考えていませんでした。 最初の壮大なプロジェクトとして、Obsidian- Pathfinder Adventuresの優れたゲームのクローンを作成します。



「これは一体何だ！ テーブルはありますか？」



彼らが言うように、 プールコイパス？ 私たちはすでに偏見を放棄しているように見えるので、私たちは大胆にアイデアを洗練し始めます。 当然、ゲームを1対1でクローンすることはありませんが、基本的なメカニズムは借用します。 さらに、ターンベースの協調型ボードゲームの実装には次の利点があります。

• それは段階的です-これにより、タイマー、同期、最適化、FPS、その他の退屈なことを心配する必要がなくなります。
• 協力的です。つまり、プレイヤー同士は競争しませんが、決定論的なルールに従って特定の「環境」と対戦します。これにより、ゲーム開発の最も難しい段階の1つであるAI （ AI ）をプログラムする必要がなくなります。
• それは意味があります-テーブルトップは一般に気まぐれな人々であり、彼らは何も傷つけません：彼らに思慮深いメカニズムと面白いゲームプレイを与えます-あなたは1つの美しい写真に出かけません（それはいくつかの身近なものに何かを与えますか？）
• 多くのeスポーツマンは同意しませんが、個人的にはゲームは面白い物語を語るべきです-本のように、特別な芸術的手段を使用するだけです。
• 彼女は面白く、誰もが楽しめるわけではありません。説明したアプローチは、あなたが何人いようとも、その後の夢に適用できます。

一般的に、ゲームは興味深く、価値があり、注目に値します。そして、私たちにとって重要なことは、クローンを実装することを面白くするために非常に複雑です（「難しい」とは「難しい」という意味ではありません）。



このケースでは、1つのグローバルな概念変更を行います-カードを放棄します。 むしろ、私たちはまったく拒否しませんが、サイズと色が異なる立方体にカードを置き換えます（技術的には、正しい六角形以外の形状があるため、「立方体」を使用することはまったく正しくありませんが、「骨」と呼ぶのは珍しいです）それは不快ですが、アメリカのデイジーを使用することは味のしるしの兆候なので、そのままにしておきましょう）。 今、デッキの代わりに、プレイヤーはバッグを持っています。 また、場所にはバッグがあり、そこから研究プロセスのプレイヤーが任意のキューブを引き出します。 キューブの色によって、キューブのタイプが決まり、それに応じて、テストに合格するためのルールが決まります。 その結果、キャラクターの個人的な特性（強さ、器用さなど）はなくなりますが、新しい興味深いメカニズムが表示されます（詳細は後ほど）。



遊ぶのは楽しいですか？ 私には見当がつかず、実際のプロトタイプが完成するまで誰もこれを理解できません。 しかし、ゲームを楽しむのではなく、開発を楽しみますか？ したがって、成功の疑いはないはずです。

ステップ2 設計

アイデアを持つことは、物語の3分の1にすぎません。 今、この考えを発展させることが重要です。 つまり、公園を散歩したり、スチームバスを浴びたりするのではなく、テーブルに座ってペンで紙を取り（またはお気に入りのテキストエディターを開き）、デザインドキュメントを慎重に作成し、ゲームメカニクスのあらゆる側面を入念に作成します。 これには時間がかかりますので、一気に文章を完成させることを期待しないでください。 そして、すべてを一度にすべて検討することさえ望んでいません-実装するにつれて、多くの変更と変更を行う必要があることがわかります（そして、時にはグローバルに何かをやり直します）が、開発プロセスが始まる前に何らかの基礎が存在しなければなりません。





そして、壮大なアイデアの最初の波に対処した後に初めて、頭を取り、ドキュメントの構造を決定し、それをコンテンツで整然と満たし始めます（不要な繰り返しや特に矛盾を避けるために、すでに書かれた内容で毎秒をチェックします）。 次第に、次のように意味のある簡潔なものが得られます。



設計を説明するときは、特に一人で作業する場合は、考えを表現しやすい言語を選択してください。 プロジェクトにサードパーティの開発者を参加させる必要がある場合は、あなたの頭の中で起こっているすべての創造的なナンセンスを彼らが理解していることを確認してください。



続行するには、引用されたドキュメントを少なくとも斜めに読むことを強くお勧めします。将来的には、その解釈について詳しく説明することなく、そこに提示されている用語と概念を参照するからです。



「著者、壁に向かって自殺してください。 文字が多すぎます。」

ステップ3 モデリング

つまり、すべて同じデザインで、より詳細なものです。

多くの人がIDEを開いてコーディングを始めたいと思っていますが、もう少し忍耐強く待ってください。 アイデアが頭を圧倒すると、キーボードに触れるだけで手が空の高さの距離に突進するように思えます-ストーブでコーヒーが沸騰する前に、アプリケーションの作業バージョンはゴミ箱に行く準備ができています... 同じことを何度も書き直さないように（特に、3時間の開発後にレイアウトが機能せず、新たに開始する必要があることを確認しないように）、最初にアプリケーションの主要構造を検討（および文書化）することをお勧めします。



開発者として、オブジェクト指向プログラミング（OOP）に精通しているので、プロジェクトでその原則を使用します。 しかし、OOPの場合、退屈なUMLダイアグラムの束から開発を開始することほど期待されていません。 （ UMLが何なのかわかりませんか？私も忘れそうになりましたが、喜んで思い出します-私が勤勉なプログラマーであることを示すためです。



ユースケース図から始めましょう。 ユーザー（プレーヤー）が将来のシステムとやり取りする方法を説明します。





「ええと...それは何のことですか？」



冗談です、冗談です...そして、おそらく、私はそれについて冗談を言うのをやめます-これは深刻な問題です（結局、夢です）。 ユースケースの図では、システムがユーザーに提供する可能性を表示する必要があります。 詳細に。 しかし、この特定のタイプのダイアグラムが私にとって最悪であることが判明したのは歴史的に起こりました-明らかに十分な忍耐がありません。 そして、あなたはそのように私を見る必要はありません-私たちは大学で卒業証書を保護していませんが、私たちは仕事のプロセスを楽しんでいます。 このプロセスでは、ユースケースはそれほど重要ではありません。 アプリケーションを独立したモジュールに正しく分割すること、つまり、ビジュアルインターフェイスの機能がゲームメカニクスに影響を与えないようにゲームを実装し、必要に応じてグラフィックコンポーネントを簡単に変更できるようにすることがはるかに重要です。



この点は、次のコンポーネント図で詳しく説明できます。





ここで、アプリケーションの一部である特定のサブシステムをすでに特定しました。後で示すように、それらはすべて互いに独立して開発されます。



また、同じ段階で、ゲームのメインサイクルがどのように見えるかを推定します（または、最も興味深い部分は、スクリプト内のキャラクターを実装する部分です）。 これには、アクティビティ図が適しています。





そして最後に、入出力システムを介したエンドユーザーとゲームエンジンとの相互作用のシーケンスを一般的な用語で示すとよいでしょう。





夜は長く、夜明けのずっと前です。 テーブルに座った後、他の20個の図を落ち着いて描きます。将来的には、それらが存在することで、選択した道を歩み、自尊心を高め、部屋のインテリアを更新し、色あせた壁紙で色あせた壁紙を吊るし、簡単にあなたのビジョンを伝えることができますすぐにあなたの新しいスタジオのドアに大急ぎで駆けつける仲間の開発者（私たちは成功を目指していません、覚えていますか？）



これまでのところ、誰もが愛するクラス図（クラス）を引用するつもりはありません-多くのクラスが突破することが期待されており、最初は3つの画面の画像は追加されません。 適切なサブシステムの開発に進むにつれて、断片に分割して徐々に配置する方が適切です。

ステップ4 ツール選択

すでに合意したように、さまざまなオペレーティングシステムを実行するデスクトップとモバイルデバイスの両方で実行されるクロスプラットフォームアプリケーションを開発します。プログラミング言語としてJavaを選択します。後者はより新しく新鮮なため、Kotlinはさらに優れており、前任者を圧倒するinりの波で泳ぐ時間はまだありません（同時に、誰かがそれを所有していない場合はトレーニングします）。JVMはご存じのとおり、どこでも利用できます（30億台のデバイスで）、WindowsとUNIXの両方をサポートし、SSH接続を介したリモートサーバー上でも再生できます（必要な場合は不明ですが、そのような機会を提供します）。また、金持ちになってアーティストを雇うときにAndroidに転送しますが、それについては後で詳しく説明します。



ライブラリ（ライブラリなしではどこにもアクセスできません）クロスプラットフォームの要件に応じて選択します。Mavenをビルドシステムとして使用します。またはGradle。それとも、Maven、それから始めましょう。すぐに、バージョン管理システム（好きなもの）をセットアップすることをお勧めします。そうすることで、何年も経った後、それがかつてどれほど素晴らしかったかを懐かしい気持ちで思い出しやすくなります。IDEは、使い慣れた、お気に入りの、便利なものも選択します。



実際、他に何も必要ありません。開発を開始できます。

ステップ5 プロジェクトの作成と設定

IDEを使用する場合、プロジェクトの作成は簡単です。 私たちの将来の傑作のためにいくつかの邪悪な名前（たとえば、 Dice ）を選択する必要があり、設定でMavenサポートを有効にすることを忘れずに、 pom.xml



ファイルに必要な識別子を書き込みます。

 <modelVersion>4.0.0</modelVersion> <groupId>my.company</groupId> <artifactId>dice</artifactId> <version>1.0</version> <packaging>jar</packaging>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、デフォルトでは存在しないKotlinサポートを追加します。

 <dependency> <groupId>org.jetbrains.kotlin</groupId> <artifactId>kotlin-stdlib</artifactId> <version>${kotlin.version}</version> </dependency>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、私たちが詳しく説明しないいくつかの設定：

 <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> <kotlin.version>1.3.20</kotlin.version> <kotlin.compiler.incremental>true</kotlin.compiler.incremental> </properties>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一度に3つのパッケージを作成してみましょう（なぜ何か試してみませんか？）：

• model
  
  
  
  -ゲームワールドのオブジェクトを記述するクラス。
• game-ゲームプレイを実装するクラス用。
• ui
  
  
  
  ユーザー対話を担当するクラス用。

後者にはインターフェースのみが含まれ、そのメソッドはデータの入出力に使用します。 一般に特定の実装を別のプロジェクトに保存しますが、それについては後で詳しく説明します。 それまでは、スプレーしすぎないように、これらのクラスを並べて追加します。



すぐに完璧にしようとしないでください。パッケージ名、インターフェース、クラス、メソッドの詳細を熟考してください。 オブジェクト同士の相互作用を徹底的に規定します-これはすべて、数十回以上変化します。 プロジェクトが発展するにつれて、多くのものがugくてかさばり、あなたにとっても効果的でないように見えます-現代のIDEでのリファクタリングは非常に安価な操作なので、気軽に変更してください。



また、 main



機能を備えたクラスを作成します。これで、すばらしい成果に備えることができます。 IDE自体を起動に使用できますが、後で見るように、この方法は私たちの目的には適していません（標準のIDEコンソールは、必要に応じてグラフィカルな結果を表示できません）。したがって、バッチ（またはUNIXシステムのシェル）を使用して外部からの起動を構成しますファイル。 ただし、その前に、いくつかの追加設定を行います。



mvn package



操作が完了した後、コンパイルされたすべてのクラスを含むJARアーカイブの出力を取得します。 まず、デフォルトでは、このアーカイブには、プロジェクトが機能するために必要な依存関係が含まれていません（これまでのところ、それらはありませんが、将来的には確実に表示されます）。 次に、 main



メソッドを含むメインクラスへのパスがアーカイブマニフェストファイルで指定されていないため、 java -jar dice-1.0.jar



プロジェクトを開始java -jar dice-1.0.jar



ません。 これを修正するには、 pom.xml



追加の設定を追加します。

 <build> <plugins> <plugin> <artifactId>maven-assembly-plugin</artifactId> <version>2.6</version> <executions> <execution> <phase>package</phase> <goals> <goal>single</goal> </goals> </execution> </executions> <configuration> <descriptorRefs> <descriptorRef>jar-with-dependencies</descriptorRef> </descriptorRefs> <archive> <manifest> <mainClass>my.company.dice.MainKt</mainClass> </manifest> </archive> </configuration> </plugin> </plugins> </build>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メインクラスの名前に注意してください。 クラスの外部に含まれるKotlin関数（ main



関数など）の場合、クラスはコンパイル中に作成されます（JVMは何も知らず、知りたくないため）。 クラスの名前は、 Kt



追加したファイルの名前です。 つまり、メインクラスにMain



という名前を付けた場合、 MainKt.class



ファイルにコンパイルされます。 jarファイルのマニフェストで示す必要があるのは、この最後の1つです。



これで、プロジェクトをビルドすると、出力に2つのjarファイルdice-1.0.jar



およびdice-1.0-jar-with-dependencies.jar



が取得されます。 第二に興味があります。 スタートアップスクリプトを作成します。



dice.bat （Windows用）

 @ECHO OFF rem Compiling call "path_to_maven\mvn.bat" -f "path_to_project\Dice\pom.xml" package if errorlevel 1 echo Project compilation failed! & pause & goto :EOF rem Running java -jar path_to_project\Dice\target\dice-1.0-jar-with-dependencies.jar pause
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

dice.sh （UNIXの場合）

 #!/bin/sh # Compiling mvn -f "path_to_project/Dice/pom.xml" package if [[ "$?" -ne 0 ]] ; then echo 'Project compilation failed!'; exit $rc fi # Running java -jar path_to_project/Dice/target/dice-1.0-jar-with-dependencies.jar
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンパイルが失敗すると、スクリプトの中断が強制されることに注意してください。 それ以外の場合、最後のハープではなく、前回の正常なアセンブリから残っているファイルが起動されます（違いが見つからないこともあります）。 多くの場合、開発者はmvn clean package



コマンドを使用して以前にコンパイルされたすべてのファイルを削除しますが、この場合、コンパイルプロセス全体は常に（ソースコードが変更されていなくても）最初から開始され、多くの時間がかかります。 しかし、待つことはできません-ゲームを作成する必要があります。



そのため、プロジェクトは正常に起動しますが、これまでのところ何もしません。 心配しないでください、すぐに修正します。

ステップ6 主なオブジェクト

徐々に、ゲームプレイに必要なクラスをmodel



パッケージに追加し始めます。





キューブがすべてです。最初に追加します。 各ダイ（ Die



クラスのインスタンス）は、そのタイプ（色）とサイズによって特徴付けられます。 キューブのタイプについては、個別の列挙（ Die.Type



）を作成し、サイズを4から12の整数でマークします。また、 roll()



メソッドを実装しroll()



。これは、キューブで使用可能な範囲（1からサイズ値まで）から任意の均一に分散した数を生成します。



クラスは、キューブを相互に比較できるComparable



インターフェイスを実装します（後で複数のキューブを順序付けられた行に表示するときに便利です）。 より大きなキューブはより早く配置されます。

 class Die(val type: Type, val size: Int) : Comparable<Die> { enum class Type { PHYSICAL, //Blue SOMATIC, //Green MENTAL, //Purple VERBAL, //Yellow DIVINE, //Cyan WOUND, //Gray ENEMY, //Red VILLAIN, //Orange OBSTACLE, //Brown ALLY //White } fun roll() = (1.. size).random() override fun toString() = "d$size" override fun compareTo(other: Die): Int { return compareValuesBy(this, other, Die::type, { -it.size }) } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ほこりを集めないために、キューブはハンドバッグ（ Bag



クラスのコピー）に保管されます。 バッグ内で何が起こっているかを推測することしかできないため、順序付けられたコレクションを使用する意味はありません。 のようです。 セット（セット）は必要なアイデアをうまく​​実装しますが、2つの理由で適合しません。 まず、それらを使用するときは、 equals()



およびhashCode()



メソッドを実装する必要がありますが、キューブのタイプとサイズを比較するのは間違っているため、どのようにすればよいか明確ではありません-任意の数の同じキューブをセットに格納できます。 第二に、キューブを袋から取り出すと、毎回異なる非決定的なものだけでなく、ランダムなものが得られることが期待されます。 したがって、順序付けられたコレクション（リスト）を使用し、新しい要素を追加するたびput()



メソッドで）または発行する直前（ draw()



メソッドで）シャッフルすることをお勧めします。



examine()



メソッドは、不確実性に飽き飽きしているプレーヤーがハートのテーブルのバッグの中身を振る場合（ソートに注意を払う）と、 clear()



メソッド-振られたキューブがバッグに戻らない場合に適しています。

 open class Bag { protected val dice = LinkedList<Die>() val size get() = dice.size fun put(vararg dice: Die) { dice.forEach(this.dice::addLast) this.dice.shuffle() } fun draw(): Die = dice.pollFirst() fun clear() = dice.clear() fun examine() = dice.sorted().toList() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

キューブ付きバッグに加えて、キューブ付きヒープ（ Pile



クラスのインスタンス）も必要です。 1つ目と2つ目は、コンテンツがプレーヤーに表示される点で異なります。したがって、必要に応じてヒープからキューブを削除し、プレーヤーは特定のインスタンスを選択できます。 removeDie()



メソッドを使用してこのアイデアを実装します。

 class Pile : Bag() { fun removeDie(die: Die) = dice.remove(die) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、主人公であるヒーローに目を向けます。 つまり、今後キャラクターをヒーローと呼びます（JavaでCharacter



という名前でクラスを呼び出さない理由はあります）。 キャラクターにはさまざまな種類がありますが（クラスに入れるには単語class



を使用しないほうが良いです）、作業中のプロトタイプでは、 Brawler （つまり、強さと強さに重点を置いたFighter）とHunter （別名Ranger / Thief、に重点を置きます）器用さとステルス）。 主人公のクラスは彼の特性、スキル、キューブの初期セットを決定しますが、後で見られるように、主人公はクラスに厳密に結び付けられないため、個人設定は1か所で簡単に変更できます。



デザインドキュメントに従って、ヒーローに必要なプロパティを追加しましょう。名前、お気に入りのキューブの種類、サイコロの制限、習得済みのスキル、未熟なスキル、リセット用の手、バッグ、パイル。 コレクションプロパティの実装の機能に注意してください。 文明世界全体で、オブジェクト内に格納されているコレクションへの外部アクセス（ゲッターの助けを借りて）を提供するのは悪い形と考えられています-悪徳プログラマーは、クラスの知識がなくてもこれらのコレクションの内容を変更できます。 これに対処する1つの方法は、要素を追加および削除し、その番号を取得し、インデックスでアクセスするための個別のメソッドを実装することです。 ゲッターを実装できますが、同時にコレクション自体ではなく、その不変のコピーを返します-少数の要素の場合、それだけを実行することは特に怖くありません。

 data class Hero(val type: Type) { enum class Type { BRAWLER HUNTER } var name = "" var isAlive = true var favoredDieType: Die.Type = Die.Type.ALLY val hand = Hand(0) val bag: Bag = Bag() val discardPile: Pile = Pile() private val diceLimits = mutableListOf<DiceLimit>() private val skills = mutableListOf<Skill>() private val dormantSkills = mutableListOf<Skill>() fun addDiceLimit(limit: DiceLimit) = diceLimits.add(limit) fun getDiceLimits(): List<DiceLimit> = Collections.unmodifiableList(diceLimits) fun addSkill(skill: Skill) = skills.add(skill) fun getSkills(): List<Skill> = Collections.unmodifiableList(skills) fun addDormantSkill(skill: Skill) = dormantSkills.add(skill) fun getDormantSkills(): List<Skill> = Collections.unmodifiableList(dormantSkills) fun increaseDiceLimit(type: Die.Type) { diceLimits.find { it.type == type }?.let { when { it.current < it.maximal -> it.current++ else -> throw IllegalArgumentException("Already at maximum") } } ?: throw IllegalArgumentException("Incorrect type specified") } fun hideDieFromHand(die: Die) { bag.put(die) hand.removeDie(die) } fun discardDieFromHand(die: Die) { discardPile.put(die) hand.removeDie(die) } fun hasSkill(type: Skill.Type) = skills.any { it.type == type } fun improveSkill(type: Skill.Type) { dormantSkills .find { it.type == type } ?.let { skills.add(it) dormantSkills.remove(it) } skills .find { it.type == type } ?.let { when { it.level < it.maxLevel -> it.level += 1 else -> throw IllegalStateException("Skill already maxed out") } } ?: throw IllegalArgumentException("Skill not found") } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ヒーローの手（彼が現在持っている立方体）は、別のオブジェクト（ Hand



クラス）によって記述されます。 連合キューブをメインアームから分離しておくという設計上の決定は、最初に思いついたものの1つでした。 最初は非常にクールな機能のように見えましたが、後に膨大な数の問題と不便を生み出しました。 それでも、簡単な方法を探しているわけではないため、 dice



とallies



リストはサービスにあり、追加、受信、削除する必要があるすべてのメソッドがあります（そのうちのいくつかは、2つのリストのどちらにアクセスするかを巧妙に決定します）。 手からキューブを削除すると、後続のすべてのキューブがリストの最上部に移動し、空白を埋めます-将来的には検索が大幅に容易になります（ null



状況を処理する必要はありません）。

 class Hand(var capacity: Int) { private val dice = LinkedList<Die>() private val allies = LinkedList<Die>() val dieCount get() = dice.size val allyDieCount get() = allies.size fun dieAt(index: Int) = when { (index in 0 until dieCount) -> dice[index] else -> null } fun allyDieAt(index: Int) = when { (index in 0 until allyDieCount) -> allies[index] else -> null } fun addDie(die: Die) = when { die.type == Die.Type.ALLY -> allies.addLast(die) else -> dice.addLast(die) } fun removeDie(die: Die) = when { die.type == Die.Type.ALLY -> allies.remove(die) else -> dice.remove(die) } fun findDieOfType(type: Die.Type): Die? = when (type) { Die.Type.ALLY -> if (allies.isNotEmpty()) allies.first else null else -> dice.firstOrNull { it.type == type } } fun examine(): List<Die> = (dice + allies).sorted() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

DiceLimit



クラスのオブジェクトのコレクションは、ヒーローがスクリプトの最初に持つことができる各タイプのキューブの数に制限を設定します。 特別なことはありません。最初に、各タイプの最大値と現在の値を決定します。

 class DiceLimit(val type: Die.Type, val initial: Int, val maximal: Int, var current: Int)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、スキルがあればもっと面白いです。 それぞれを個別に実装する必要があります（詳細は後ほど説明します）が、 HitとShoot （クラスごとに1つ）の2つだけを検討します。 スキルは、初期レベルから最大レベルまで開発（「ポンプ」）できます。これは、サイコロのロールに追加される修正に影響を与えることがよくあります。 これは、プロパティlevel



、 maxLevel



、 modifier1



およびmodifier2



maxLevel



れます。

 class Skill(val type: Type) { enum class Type { //Brawler HIT, //Hunter SHOOT, } var level = 1 var maxLevel = 3 var isActive = true var modifier1 = 0 var modifier2 = 0 }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Hero



クラスの補助メソッドに注意してください。これにより、手からダイスを隠したりロールしたり、ヒーローに特定のスキルがあるかどうかを確認したり、学習したスキルのレベルを上げたり、新しいスキルを習得したりできます。 それらはすべて遅かれ早かれ必要になりますが、今はそれらについて詳しくは説明しません。



作成しなければならないクラスの数を恐れないでください。 この複雑なプロジェクトでは、数百が一般的なものです。 ここでは、あらゆる深刻な職業と同様に、私たちは小さなことから始め、徐々にペースを上げていきます。1か月で、私たちはその範囲に恐ろしくなります。 忘れないでください、私たちはまだ一人の小さなスタジオです-私たちは圧倒的な仕事に直面していません。



「何かがうんざりした。 私はタバコを吸うか、何か...」



そして、私たちは続けます。

主人公とその能力が説明されていますが、今度は敵の力-大きくて恐ろしいゲームメカニクスに行きましょう。 むしろ、ヒーローが対話しなければならないオブジェクト。





私たちの勇敢な主人公は、3種類のキューブとカードに直面します：悪役（ Villain



クラス）、敵（ Enemy



クラス）、障害（ Obstacle



クラス）、「脅威」という一般用語の下で団結します限定）。 各脅威には、そのような脅威に直面したときの行動の特別なルールを記述し、ゲームプレイに多様性を追加する一連の特徴的な機能（ Trait



）があります。

 sealed class Threat { var name: String = "" var description: String = "" private val traits = mutableListOf<Trait>() fun addTrait(trait: Trait) = traits.add(trait) fun getTraits(): List<Trait> = traits } class Obstacle(val tier: Int, vararg val dieTypes: Die.Type) : Threat() class Villain : Threat() class Enemy : Threat() enum class Trait { MODIFIER_PLUS_ONE, //Add +1 modifier MODIFIER_PLUS_TWO, //Add +2 modifier }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Trait



クラスのオブジェクトのリストは可変（ MutableList



）として定義されていますが、不変のList



インターフェースとして提供されていることに注意してください。 これはKotlinで機能しますが、結果のリストが変更可能なインターフェイスに変換されたり、さまざまな変更を加えたりすることを妨げるものがないため、このアプローチは安全ではありません-Javaコードからクラスにアクセスする場合（ List



インターフェイスが変更可能な場合）、これは特に簡単です。 コレクションを保護する最も妄想的な方法は、次のようなことです。

 fun getTraits(): List<Trait> = Collections.unmodifiableList(traits)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、私たちは問題に近づいていくのにそれほど慎重ではありません（ただし、警告されています）。



ゲームメカニクスの特性により、 Obstacle



クラスは追加フィールドがある点で対応するクラスとは異なりますが、それらに焦点を合わせません。



脅威カード（および設計文書を注意深く読んだ場合、これらはカードであることを忘れないでください）は、 Deck



クラスで表されるデッキに結合されます。

 class Deck<E: Threat> { private val cards = LinkedList<E>() val size get() = cards.size fun addToTop(card: E) = cards.addFirst(card) fun addToBottom(card: E) = cards.addLast(card) fun revealTop(): E = cards.first fun drawFromTop(): E = cards.removeFirst() fun shuffle() = cards.shuffle() fun clear() = cards.clear() fun examine() = cards.toList() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、クラスがパラメーター化され、適切なメソッドを使用して混合できる順序付きリスト（または双方向キュー）が含まれていることを除いて、異常なものはありません。 敵や障害物のデッキは、文字通り一瞬のうちに考慮に入れる必要があります...



... Location



クラスの各インスタンスは、ヒーローがスクリプトの一部として訪問しなければならない一意の場所を記述します。

 class Location { var name: String = "" var description: String = "" var isOpen = true var closingDifficulty = 0 lateinit var bag: Bag var villain: Villain? = null lateinit var enemies: Deck<Enemy> lateinit var obstacles: Deck<Obstacle> private val specialRules = mutableListOf<SpecialRule>() fun addSpecialRule(rule: SpecialRule) = specialRules.add(rule) fun getSpecialRules() = specialRules }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

各地域には、名前、説明、閉鎖の難易度、「オープン/クローズ」のサインがあります。 ここのどこかに、悪役が潜んでいる可能性があります（または、潜んでいない可能性があり、その結果として、 villain



プロパティがnull



なる場合がありnull



）。 各エリアには、キューブの入ったバッグと脅威のあるデッキがあります。 地形には、独自のゲーム機能（ SpecialRule



）をSpecialRule



こともできます。これは、脅威のプロパティと同様に、ゲームプレイに多様性を追加します。 ご覧のとおり、近い将来に実装する予定がない場合でも、将来の機能の基盤を構築しています（実際には、モデリング段階が必要です）。



最後に、スクリプト（ Scenario



クラス）を実装します。

 class Scenario { var name = "" var description = "" var level = 0 var initialTimer = 0 private val allySkills = mutableListOf<AllySkill>() private val specialRules = mutableListOf<SpecialRule>() fun addAllySkill(skill: AllySkill) = allySkills.add(skill) fun getAllySkills(): List<AllySkill> = Collections.unmodifiableList(allySkills) fun addSpecialRule(rule: SpecialRule) = specialRules.add(rule) fun getSpecialRules(): List<SpecialRule> = Collections.unmodifiableList(specialRules) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

各シナリオは、タイマーのレベルと初期値によって特徴付けられます。 前に見たものと同様に、特別なルール（ specialRules



）と同盟者のスキルが設定されます（考慮から逃します）。 スクリプトには、場所（ Location



クラスのオブジェクト）のリストも含めるべきだと思うかもしれませんが、論理的には、これは本当にそうです。 しかし、後で見られるように、このような接続はどこでも使用せず、技術的な利点もありません。



これまでに検討したすべてのクラスがmodel



パッケージに含まれていることを思い出してください。子供の頃、壮大なおもちゃの戦いを見越して、テーブルの表面に兵士を配置しました。 そして今、いくつかの痛みを伴う瞬間の後、最高司令官の合図で、私たちはおもちゃを押し合わせ、ゲームプレイの結果を楽しんで、戦いに突入します。 しかし、その前に、取り決め自体について少し説明します。



「そう...」

7番目のステップ。 パターンとジェネレーター

以前に考慮されたオブジェクトを生成するプロセスが、たとえばロケーション（地形）になることを少し想像してみましょう。クラスのインスタンスを作成し、Location



フィールドを値で初期化する必要があります。したがって、ゲームで使用するローカリティごとに必要です。ただし、待ってください。各場所にはバッグも必要であり、これも生成する必要があります。また、バッグにはキューブがあります-これらは、対応するクラス（Die



）のインスタンスでもあります。これは敵や障害物のことではありません-それらは一般的にデッキに集められる必要があります。また、悪役は地形自体を決定するのではなく、シナリオの機能を1レベル上に配置します。さて、あなたはポイントを得る。 上記のソースコードは次のようになります。

 val location = Location().apply { name = "Some location" description = "Some description" isOpen = true closingDifficulty = 4 bag = Bag().apply { put(Die(Die.Type.PHYSICAL, 4)) put(Die(Die.Type.SOMATIC, 4)) put(Die(Die.Type.MENTAL, 4)) put(Die(Die.Type.ENEMY, 6)) put(Die(Die.Type.OBSTACLE, 6)) put(Die(Die.Type.VILLAIN, 6)) } villain = Villain().apply { name = "Some villain" description = "Some description" addTrait(Trait.MODIFIER_PLUS_ONE) } enemies = Deck<Enemy>().apply { addToTop(Enemy().apply { name = "Some enemy" description = "Some description" }) addToTop(Enemy().apply { name = "Other enemy" description = "Some description" }) shuffle() } obstacles = Deck<Obstacle>().apply { addToTop(Obstacle(1, Die.Type.PHYSICAL, Die.Type.VERBAL).apply { name = "Some obstacle" description = "Some Description" }) } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、Kotlin言語と設計のおかげでもありapply{}



ます。Javaでは、コードは2倍扱いにくくなります。さらに、私たちが言ったように多くの場所があり、それらのほかに、シナリオ、冒険、そしてスキルと特徴を持つヒーローもいます-一般に、ゲームデザイナーがすることがあります。



ただし、ゲームデザイナーはコードを記述しないため、ゲームの世界でわずかな変化があったときにプロジェクトを再コンパイルするのは不便です。ここでは、有能なプログラマーは、クラスコードからオブジェクトの記述を分離する必要があることに反対します-理想的には、後者のインスタンスは、必要に応じて前者に基づいて動的に生成されます。このような図面を実装し、それらをテンプレートと呼ぶだけで、特別なクラスのインスタンスとして表します。このようなパターンを使用すると、特別なプログラムコード（ジェネレーター）が前述のモデルから最終的なオブジェクトを作成します。





したがって、オブジェクトのクラスごとに、テンプレートインターフェイスとジェネレータクラスの2つの新しいエンティティを定義する必要があります。そして、かなりの量のオブジェクトが蓄積されているため、多数のエンティティもあります...下品です：





気を散らさないように、深く呼吸し、注意深く聞いてください。まず、図にはゲームワールドのすべてのオブジェクトが表示されているわけではなく、メインのオブジェクトのみが表示されています。第二に、不必要な詳細で回路を過負荷にしないために、他の図ですでに述べた接続のいくつかは省略されました。



キューブの生成-シンプルなものから始めましょう。 「どう？ -あなたは言います。 -コンストラクターが足りませんか？はい、はい、同じもので、タイプとサイズがあります。」いいえ、十分ではありません。実際、多くの場合（ルールを読んで）、キューブは任意の量で任意に生成する必要があります（たとえば、「青または緑の1〜3個のキューブ」）。さらに、スクリプトの複雑さのレベルに応じてサイズを選択します。したがって、特別なインターフェイスを導入しますDieTypeFilter



。

 interface DieTypeFilter { fun test(type: Die.Type): Boolean }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このインターフェイスのさまざまな実装は、キューブのタイプが異なるルールセット（思い浮かぶもの）に対応しているかどうかをチェックします。たとえば、タイプが厳密に指定された値（「青」）または値の範囲（「青、黄、緑」）に対応するかどうか。または、反対に、指定されたタイプ以外のすべてのタイプに対応します（「それがどんな場合でも白でなかった場合」-何でも、それだけ）。必要な特定の実装が事前に明確ではない場合でも、重要ではありません-後で追加できますが、システムはこれを中断しません（多態性、覚えていますか？）。

 class SingleDieTypeFilter(val type: Die.Type): DieTypeFilter { override fun test(type: Die.Type) = (this.type == type) } class InvertedSingleDieTypeFilter(val type: Die.Type): DieTypeFilter { override fun test(type: Die.Type) = (this.type != type) } class MultipleDieTypeFilter(vararg val types: Die.Type): DieTypeFilter { override fun test(type: Die.Type) = (type in types) } class InvertedMultipleDieTypeFilter(vararg val types: Die.Type): DieTypeFilter { override fun test(type: Die.Type) = (type !in types) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

キューブのサイズも任意に設定されますが、これについては後で詳しく説明します。それまでの間、キューブジェネレーター（DieGenerator



）を作成します。これは、クラスコンストラクターとは異なりDie



、キューブの明示的なタイプとサイズではなく、フィルターと複雑さのレベルを受け入れます。

 private val DISTRIBUTION_LEVEL1 = intArrayOf(4, 4, 4, 4, 6, 6, 6, 6, 8) private val DISTRIBUTION_LEVEL2 = intArrayOf(4, 6, 6, 6, 6, 8, 8, 8, 8, 10) private val DISTRIBUTION_LEVEL3 = intArrayOf(6, 8, 8, 8, 10, 10, 10, 10, 12, 12, 12) private val DISTRIBUTIONS = arrayOf( intArrayOf(4), DISTRIBUTION_LEVEL1, DISTRIBUTION_LEVEL2, DISTRIBUTION_LEVEL3 ) fun getMaxLevel() = DISTRIBUTIONS.size - 1 fun generateDie(filter: DieTypeFilter, level: Int) = Die(generateDieType(filter), generateDieSize(level)) private fun generateDieType(filter: DieTypeFilter): Die.Type { var type: Die.Type do { type = Die.Type.values().random() } while (!filter.test(type)) return type } private fun generateDieSize(level: Int) = DISTRIBUTIONS[if (level < 1 || level > getMaxLevel()) 0 else level].random()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Javaでは、これらのメソッドは静的になりますが、Kotlinを扱うため、そのようなクラスは必要ありません。これは、以下で説明する他のジェネレーターにも当てはまります（それにもかかわらず、論理レベルでは、クラスの概念を使用します）。



2つのプライベートメソッドは、キューブのタイプとサイズを個別に生成します。それぞれについて興味深いことが言えます。このメソッドgenerateDieType()



は、次のようにフィルターを渡すことで無限ループに駆動できます。

 override fun test(filter: DieTypeFilter) = false
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

（作家は、ストーリー中に登場人物自身が観客を指す場合、論理的な矛盾から抜け出し、穴を空けることができると強く信じています）。このメソッドgenerateDieSize()



は、配列（各レベルに1つ）の形式で指定された分布に基づいて、疑似ランダムサイズを生成します。老後、金持ちになってマルチカラーのプレイブロックを購入すると、サイコロをプレイすることができません。なぜなら、それらからランダムにバッグを集める方法がわからないからです（隣人に尋ねてその場で背を向ける以外は）。これは逆さまにシャッフルできるカードのデッキではなく、特別なメカニズムとデバイスが必要です。誰かがアイデアを持っている（そして、彼がこの時点まで読んでいる忍耐を持っていた）場合は、コメントで共有してください。



そして、バッグについて話しているので、バッグ用のテンプレートを開発します。あなたの仲間とは異なり、このテンプレート（BagTemplate



）は特定のクラスになります。他のテンプレートが含まれています-それぞれが、Plan



1つ以上のキューブ（以前に作成された要件を覚えていますか？）がバッグに追加されるルール（または）を記述します。

 class BagTemplate { class Plan(val minQuantity: Int, val maxQuantity: Int, val filter: DieTypeFilter) val plans = mutableListOf<Plan>() fun addPlan(minQuantity: Int, maxQuantity: Int, filter: DieTypeFilter) { plans.add(Plan(minQuantity, maxQuantity, filter)) } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

各プランは、キューブのタイプのパターンと、このパターンを満たすキューブの数（最小および最大）を定義します。このアプローチのおかげで、派手なルールに従ってバッグを生成することができます（そして、私の隣人はきっぱりと私を助けることを拒否するので、私は私の古い年齢で再び激しく泣きます）。このようなもの：

 private fun realizePlan(plan: BagTemplate.Plan, level: Int): Array<Die> { val count = (plan.minQuantity..plan.maxQuantity).shuffled().last() return (1..count).map { generateDie(plan.filter, level) }.toTypedArray() } fun generateBag(template: BagTemplate, level: Int): Bag { return template.plans.asSequence() .map { realizePlan(it, level) } .fold(Bag()) { b, d -> b.put(*d); b } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私と同じように、あなたがこのすべての機能主義に疲れているなら、自分を締めてください-それは悪化するだけです。しかし、その後、インターネット上の多くの不明瞭なチュートリアルとは異なり、実際の理解可能な主題領域に関連して、さまざまな巧妙な方法の使用を研究する機会があります。



それ自体では、バッグはフィールドに横たわることはありません-あなたはヒーローと場所にそれらを与える必要があります。後者から始めましょう。

 interface LocationTemplate { val name: String val description: String val bagTemplate: BagTemplate val basicClosingDifficulty: Int val enemyCardsCount: Int val obstacleCardsCount: Int val enemyCardPool: Collection<EnemyTemplate> val obstacleCardPool: Collection<ObstacleTemplate> val specialRules: List<SpecialRule> }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Kotlin言語では、メソッドの代わりにget()



インターフェイスプロパティを使用できます-これははるかに簡潔です。バッグテンプレートについてはすでによく知っています。残りの方法を検討してください。このプロパティbasicClosingDifficulty



は、地形を閉じるためのチェックの基本的な複雑さを設定します。ここでいう「基本」とは、最終的な複雑さがシナリオのレベルに依存することのみを意味し、この段階では不明です。さらに、敵と障害物（および同時に悪役）のパターンを定義する必要があります。さらに、テンプレートで説明されているさまざまな敵や障害物から、すべてが使用されるわけではなく、限られた数だけが使用されます（リプレイ値を増やすため）。SpecialRule



エリアの特別なルール（）は単純な列挙（enum class



）によって実装されるため、別のテンプレートは必要ありません。

 interface EnemyTemplate { val name: String val description: String val traits: List<Trait> } interface ObstacleTemplate { val name: String val description: String val tier: Int val dieTypes: Array<Die.Type> val traits: List<Trait> } interface VillainTemplate { val name: String val description: String val traits: List<Trait> }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、ジェネレーターに個々のオブジェクトだけでなく、それらを含むデッキ全体も作成させます。

 fun generateVillain(template: VillainTemplate) = Villain().apply { name = template.name description = template.description template.traits.forEach { addTrait(it) } } fun generateEnemy(template: EnemyTemplate) = Enemy().apply { name = template.name description = template.description template.traits.forEach { addTrait(it) } } fun generateObstacle(template: ObstacleTemplate) = Obstacle(template.tier, *template.dieTypes).apply { name = template.name description = template.description template.traits.forEach { addTrait(it) } } fun generateEnemyDeck(types: Collection<EnemyTemplate>, limit: Int?): Deck<Enemy> { val deck = types .map { generateEnemy(it) } .shuffled() .fold(Deck<Enemy>()) { d, c -> d.addToTop(c); d } limit?.let { while (deck.size > it) deck.drawFromTop() } return deck } fun generateObstacleDeck(templates: Collection<ObstacleTemplate>, limit: Int?): Deck<Obstacle> { val deck = templates .map { generateObstacle(it) } .shuffled() .fold(Deck<Obstacle>()) { d, c -> d.addToTop(c); d } limit?.let { while (deck.size > it) deck.drawFromTop() } return deck }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

デッキに必要以上のカードがある場合（パラメーターlimit



）、そこから削除します。キューブとカードのパックでバッグを生成できるので、最終的に地形を作成できます。

 fun generateLocation(template: LocationTemplate, level: Int) = Location().apply { name = template.name description = template.description bag = generateBag(template.bagTemplate, level) closingDifficulty = template.basicClosingDifficulty + level * 2 enemies = generateEnemyDeck(template.enemyCardPool, template.enemyCardsCount) obstacles = generateObstacleDeck(template.obstacleCardPool, template.obstacleCardsCount) template.specialRules.forEach { addSpecialRule(it) } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

章の冒頭でコードで明示的に設定した地形は、完全に異なる外観になります。

 class SomeLocationTemplate: LocationTemplate { override val name = "Some location" override val description = "Some description" override val bagTemplate = BagTemplate().apply { addPlan(1, 1, SingleDieTypeFilter(Die.Type.PHYSICAL)) addPlan(1, 1, SingleDieTypeFilter(Die.Type.SOMATIC)) addPlan(1, 2, SingleDieTypeFilter(Die.Type.MENTAL)) addPlan(2, 2, MultipleDieTypeFilter(Die.Type.ENEMY, Die.Type.OBSTACLE)) } override val basicClosingDifficulty = 2 override val enemyCardsCount = 2 override val obstacleCardsCount = 1 override val enemyCardPool = listOf( SomeEnemyTemplate(), OtherEnemyTemplate() ) override val obstacleCardPool = listOf( SomeObstacleTemplate() ) override val specialRules = emptyList<SpecialRule>() } class SomeEnemyTemplate: EnemyTemplate { override val name = "Some enemy" override val description = "Some description" override val traits = emptyList<Trait>() } class OtherEnemyTemplate: EnemyTemplate { override val name = "Other enemy" override val description = "Some description" override val traits = emptyList<Trait>() } class SomeObstacleTemplate: ObstacleTemplate { override val name = "Some obstacle" override val description = "Some description" override val traits = emptyList<Trait>() override val tier = 1 override val dieTypes = arrayOf( Die.Type.PHYSICAL, Die.Type.VERBAL ) } val location = generateLocation(SomeLocationTemplate(), 1)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

シナリオの生成も同様に行われます。

 interface ScenarioTemplate { val name: String val description: String val initialTimer: Int val staticLocations: List<LocationTemplate> val dynamicLocationsPool: List<LocationTemplate> val villains: List<VillainTemplate> val specialRules: List<SpecialRule> fun calculateDynamicLocationsCount(numberOfHeroes: Int) = numberOfHeroes + 2 }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

規則に従って、動的に生成される場所の数はヒーローの数に依存します。インターフェイスは、必要に応じて特定の実装で再定義できる標準の計算関数を定義します。この要件により、シナリオジェネレーターはこれらのシナリオの地形も生成します。同じ場所で悪役は地域間でランダムに分散されます。

 fun generateScenario(template: ScenarioTemplate, level: Int) = Scenario().apply { name =template.name description = template.description this.level = level initialTimer = template.initialTimer template.specialRules.forEach { addSpecialRule(it) } } fun generateLocations(template: ScenarioTemplate, level: Int, numberOfHeroes: Int): List<Location> { val locations = template.staticLocations.map { generateLocation(it, level) } + template.dynamicLocationsPool .map { generateLocation(it, level) } .shuffled() .take(template.calculateDynamicLocationsCount(numberOfHeroes)) val villains = template.villains .map(::generateVillain) .shuffled() locations.forEachIndexed { index, location -> if (index < villains.size) { location.villain = villains[index] location.bag.put(generateDie(SingleDieTypeFilter(Die.Type.VILLAIN), level)) } } return locations }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

多くの熱心な読者は、クラスのソースコードではなく、一部のテキストファイル（スクリプト）にテンプレートを保存する必要があることに反対するでしょう。同意します。帽子を脱ぎますが、頭に灰を振りかけません。一方が他方に干渉しないからです。必要に応じて、テンプレートの特別な実装を定義するだけで、そのプロパティ値は外部ファイルからロードされます。これからの生成プロセスは、1つのiotaを変更しません。



まあ、彼らは何も忘れていないようです...ああ、そうです、ヒーロー-彼らも生成する必要があります、それは彼ら自身のテンプレートも必要とすることを意味します。次に例を示します。

 interface HeroTemplate { val type: Hero.Type val initialHandCapacity: Int val favoredDieType: Die.Type val initialDice: Collection<Die> val initialSkills: List<SkillTemplate> val dormantSkills: List<SkillTemplate> fun getDiceCount(type: Die.Type): Pair<Int, Int>? }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、すぐに2つの奇妙な点に気付きます。まず、テンプレートを使用してバッグとキューブを生成しません。なんで？はい。ヒーローのタイプ（クラス）ごとに初期キューブのリストが厳密に定義されているため、作成プロセスを複雑にする意味はありません。第二に、getDiceCount()



これはどんな種類のかすですか？落ち着いて、これらはDiceLimit



キューブの制限を設定するものです。そして、それらのテンプレートは、特定の値がより明確に記録されるような奇妙な形で選択されました。例から自分の目で確かめてください：

 class BrawlerHeroTemplate : HeroTemplate { override val type = Hero.Type.BRAWLER override val favoredDieType = PHYSICAL override val initialHandCapacity = 4 override val initialDice = listOf( Die(PHYSICAL, 6), Die(PHYSICAL, 6), Die(PHYSICAL, 4), Die(PHYSICAL, 4), Die(PHYSICAL, 4), Die(PHYSICAL, 4), Die(PHYSICAL, 4), Die(PHYSICAL, 4), Die(SOMATIC, 6), Die(SOMATIC, 4), Die(SOMATIC, 4), Die(SOMATIC, 4), Die(MENTAL, 4), Die(VERBAL, 4), Die(VERBAL, 4) ) override fun getDiceCount(type: Die.Type) = when (type) { PHYSICAL -> 8 to 12 SOMATIC -> 4 to 7 MENTAL -> 1 to 2 VERBAL -> 2 to 4 else -> null } override val initialSkills = listOf( HitSkillTemplate() ) override val dormantSkills = listOf<SkillTemplate>() } class HunterHeroTemplate : HeroTemplate { override val type = Hero.Type.HUNTER override val favoredDieType = SOMATIC override val initialHandCapacity = 5 override val initialDice = listOf( Die(PHYSICAL, 4), Die(PHYSICAL, 4), Die(PHYSICAL, 4), Die(SOMATIC, 6), Die(SOMATIC, 6), Die(SOMATIC, 4), Die(SOMATIC, 4), Die(SOMATIC, 4), Die(SOMATIC, 4), Die(SOMATIC, 4), Die(MENTAL, 6), Die(MENTAL, 4), Die(MENTAL, 4), Die(MENTAL, 4), Die(VERBAL, 4) ) override fun getDiceCount(type: Die.Type) = when (type) { PHYSICAL -> 3 to 5 SOMATIC -> 7 to 11 MENTAL -> 4 to 7 VERBAL -> 1 to 2 else -> null } override val initialSkills = listOf( ShootSkillTemplate() ) override val dormantSkills = listOf<SkillTemplate>() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、ジェネレータを作成する前に、スキルのテンプレートを定義します。

 interface SkillTemplate { val type: Skill.Type val maxLevel: Int val modifier1: Int val modifier2: Int val isActive get() = true } class HitSkillTemplate : SkillTemplate { override val type = Skill.Type.HIT override val maxLevel = 3 override val modifier1 = +1 override val modifier2 = +3 } class ShootSkillTemplate : SkillTemplate { override val type = Skill.Type.SHOOT override val maxLevel = 3 override val modifier1 = +0 override val modifier2 = +2 }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

残念ながら、敵や台本と同じようにバッチでリベットスキルを使うことはできません。新しいスキルごとにゲームメカニクスの拡張が必要になり、ゲームエンジンに新しいコードを追加します。この点でヒーローがいる場合でも簡単です。おそらく、このプロセスは抽象化できますが、私はまだ方法を思いつきません。はい、正直に言うとあまり試みられていません。

 fun generateSkill(template: SkillTemplate, initialLevel: Int = 1): Skill { val skill = Skill(template.type) skill.isActive = template.isActive skill.level = initialLevel skill.maxLevel = template.maxLevel skill.modifier1 = template.modifier1 skill.modifier2 = template.modifier2 return skill } fun generateHero(type: Hero.Type, name: String = ""): Hero { val template = when (type) { BRAWLER -> BrawlerHeroTemplate() HUNTER -> HunterHeroTemplate() } val hero = Hero(type) hero.name = name hero.isAlive = true hero.favoredDieType = template.favoredDieType hero.hand.capacity = template.initialHandCapacity template.initialDice.forEach { hero.bag.put(it) } for ((t, l) in Die.Type.values().map { it to template.getDiceCount(it) }) { l?.let { hero.addDiceLimit(DiceLimit(t, it.first, it.second, it.first)) } } template.initialSkills .map { generateSkill(it) } .forEach { hero.addSkill(it) } template.dormantSkills .map { generateSkill(it, 0) } .forEach { hero.addDormantSkill(it) } return hero }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ほんの数点が印象的です。まず、生成メソッド自体がヒーローのクラスに応じて目的のテンプレートを選択します。第二に、名前をすぐに指定する必要はありません（生成段階で名前を知らないこともあります）。第三に、Kotlinは前例のない量のシンタックスシュガーをもたらしました。少し恥ずかしくない。

ステップ8。ゲームサイクル

最後に、最も興味深いことに到達しました-ゲームサイクルの実装です。簡単に言えば、彼らは「ゲームを作る」ことを始めました。多くの初期開発者は、ゲーム制作などのすべてを除き、この段階から正確に開始することがよくあります。特に、すべての種類の意味のない小さなスキーム、pfff ...しかし、急ぎません（まだ朝から遠いです）。したがって、もう少しモデリングします。はい、もう一度。





ご覧のとおり、ゲームサイクルの特定のフラグメントは、上記で引用したものよりも桁違いに小さくなっています。コースを移行し、地形を探索し（2種類のキューブのみを使用して会議を説明する）、ターン終了時にキューブを破棄するプロセスのみを検討します。そして、シナリオを完成させて負けました（はい、まだゲームに勝つことはできません）-しかし、あなたはどうですか？タイマーは毎ターン減少し、その完了時に何かをする必要があります。たとえば、メッセージを表示してゲームを終了します。すべてはルールに書かれているとおりです。ヒーローが死んだら別のゲームを完了する必要がありますが、誰も彼らに危害を加えることはないので、そのままにします。勝つためには、すべてのエリアを閉じる必要がありますが、それが1つだけであっても困難です。したがって、この瞬間を残しましょう。スプレーしすぎても意味がありません-エッセンスを理解し、残りの時間を後で自由時間に終えることが重要ですそしてあなた-ゲームを書きに行くあなたの夢の）。



そのため、最初に必要なオブジェクトを決定する必要があります。



ヒーローズスクリプト。場所。

私たちはすでにそれらの作成プロセスをレビューしました-それを繰り返すことはしません。小さな例で使用する地形パターンにのみ注意してください。

 class TestLocationTemplate : LocationTemplate { override val name = "Test" override val description = "Some Description" override val basicClosingDifficulty = 0 override val enemyCardsCount = 0 override val obstacleCardsCount = 0 override val bagTemplate = BagTemplate().apply { addPlan(2, 2, SingleDieTypeFilter(Die.Type.PHYSICAL)) addPlan(2, 2, SingleDieTypeFilter(Die.Type.SOMATIC)) addPlan(2, 2, SingleDieTypeFilter(Die.Type.MENTAL)) addPlan(2, 2, SingleDieTypeFilter(Die.Type.VERBAL)) addPlan(2, 2, SingleDieTypeFilter(Die.Type.DIVINE)) } override val enemyCardPool = emptyList<EnemyTemplate>() override val obstacleCardPool = emptyList<ObstacleTemplate>() override val specialRules = emptyList<SpecialRule>() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のように、バッグには「ポジティブ」キューブ（青、緑、紫、黄色、青）しかありません。この地域には敵や障害物はなく、悪役や傷は見つかりません。特別なルールもありません-それらの実装は非常に二次的です。



保持されたキューブのヒープ。

または抑止パイル。青い立方体を地形のバッグに入れるので、チェックで使用したり、使用後に特別なヒープに保管したりできます。これにはクラスのインスタンスが役立ちPile



ます。



修飾子。

つまり、サイコロの結果に加算または減算する必要がある数値。各キューブにグローバル修飾子または個別の修飾子を実装できます。 （より明確に）2番目のオプションを選択するため、単純なクラスを作成しますDiePair



。

 class DiePair(val die: Die, var modifier: Int = 0)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

エリア内のキャラクターの場所。

良い方法で、この瞬間は特別な構造を使用して追跡する必要があります。たとえばMap<Location, List<Hero>>



、各ローカリティに現在いるヒーローのリストが含まれるフォームのマップ（および反対の方法-特定のヒーローがいるローカリティを決定する方法）。あなたはこのルートを行くことに決める場合は、クラスを追加することを忘れないでくださいLocation



メソッドの実装をequals()



し、hashCode()



うまくいけば、理由を説明する必要はありません- 。このエリアは1つだけであり、ヒーローはそれをどこにも残さないので、これに時間を無駄にしません。



主人公の手を確認します。

ゲームの過程で、ヒーローは常にチェック（以下で説明）を実行する必要があります。つまり、手からキューブを取り出し、それらをスロー（モディファイアを追加）し、複数のキューブがある場合に結果を集計（要約、最大/最小、平均など）し、それらをスローと比較します別のキューブ（エリアのバッグから取り出されるもの）、および結果に応じて、次のアクションを実行します。しかし、まず第一に、主人公が原則的にテストに合格できるかどうか、つまり、必要なキューブを手に持っているかどうかを理解する必要があります。このために、シンプルなインターフェイスを提供しますHandFilter



。

 interface HandFilter { fun test(hand: Hand): Boolean }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

インターフェースの実装は、ヒーローの手（クラスオブジェクトHand



）を入力として受け取り、チェックの結果に応じてtrue



どちらかを返しますfalse



。ゲームのフラグメントには、単一の実装が必要です。青、緑、紫、または黄色のキューブが満たされた場合、ヒーローの手に同じ色のキューブがあるかどうかを判断する必要があります。

 class SingleDieHandFilter(private vararg val types: Die.Type) : HandFilter { override fun test(hand: Hand) = (0 until hand.dieCount).mapNotNull { hand.dieAt(it) }.any { it.type in types } || (Die.Type.ALLY in types && hand.allyDieCount > 0) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

はい、機能主義です。



アクティブ/選択されたアイテム。

主人公の手がテストの実行に適していることを確認したので、プレイヤーは、このテストに合格するサイコロ（またはキューブ）を手から選択する必要があります。まず、適切な位置（目的のタイプのキューブがある）を強調表示（ハイライト）する必要があります。次に、選択したキューブに何らかの方法でマークを付ける必要があります。これらの要件の両方について、クラスが適切HandMask



であり、実際には、整数のセット（選択された位置の数）とそれらを追加および削除するためのメソッドが含まれています。

 class HandMask { private val positions = mutableSetOf<Int>() private val allyPositions = mutableSetOf<Int>() val positionCount get() = positions.size val allyPositionCount get() = allyPositions.size fun addPosition(position: Int) = positions.add(position) fun removePosition(position: Int) = positions.remove(position) fun addAllyPosition(position: Int) = allyPositions.add(position) fun removeAllyPosition(position: Int) = allyPositions.remove(position) fun checkPosition(position: Int) = position in positions fun checkAllyPosition(position: Int) = position in allyPositions fun switchPosition(position: Int) { if (!removePosition(position)) { addPosition(position) } } fun switchAllyPosition(position: Int) { if (!removeAllyPosition(position)) { addAllyPosition(position) } } fun clear() { positions.clear() allyPositions.clear() } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ホワイトキューブを別の手で保管するという「邪悪な」アイデアにどのように苦しんでいるのか、すでに述べました。この愚かさのために、2つのセットを処理し、提示された各メソッドを複製する必要があります。誰かがこの要件の実装を簡素化する方法についてアイデアを持っている場合（たとえば、1つのセットを使用しますが、ホワイトキューブの場合、インデックスは100から始まる-または他の同様に不明瞭なもの）-コメントで共有します。



ところで、ヒープ（PileMask



）からキューブを選択するには、同様のクラスを実装する必要がありますが、この機能はこの例の範囲外です。



手からのキューブの選択。

ただし、許容可能な位置を「強調」するだけでは不十分です。キューブを選択するプロセスでこの「強調」を変更することが重要です。つまり、プレーヤーが自分の手からダイスを1つだけ取る必要がある場合、このダイスを選択すると、他のすべてのポジションにアクセスできなくなります。さらに、各段階で、プレーヤーの目標の達成を制御する必要があります。つまり、選択したキューブが1つまたは別のテストに合格するのに十分かどうかを理解する必要があります。このような難しいタスクには、複雑なクラスの複雑なインスタンスが必要です。

 abstract class HandMaskRule(val hand: Hand) { abstract fun checkMask(mask: HandMask): Boolean abstract fun isPositionActive(mask: HandMask, position: Int): Boolean abstract fun isAllyPositionActive(mask: HandMask, position: Int): Boolean fun getCheckedDice(mask: HandMask): List<Die> { return ((0 until hand.dieCount).filter(mask::checkPosition).map(hand::dieAt)) .plus((0 until hand.allyDieCount).filter(mask::checkAllyPosition).map(hand::allyDieAt)) .filterNotNull() } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

かなり複雑なロジックです。このクラスが理解できない場合は、理解して許します。そして、まだ説明しようとします。このクラスの実装は、常に処理対象の手（オブジェクトHand



）への参照を保存します。各メソッドはマスク（HandMask



）を受け取ります。これは、選択の現在の状態を反映します（どの位置がプレーヤーによって選択され、どの位置が選択されないか）。このメソッドcheckMask()



は、選択したキューブがテストに合格するのに十分かどうかを報告します。このメソッドisPositionActive()



は、特定の位置を強調表示する必要があるかどうか、この位置にキューブをテストに追加（または既に選択されているキューブを削除）できるかどうかを示します。方法isAllyPositionActive()



は白サイコロでも同じです（はい、私は知っています、私はばかです）。さて、ヘルパーメソッドgetCheckedDice()



単に、マスクに対応する手からすべてのキューブのリストを返します-これは、それらを一度に取り、テーブルに投げて、面白いノックを楽しむために必要です。



この抽象クラスの2つの実現（驚き、驚き！）が必要です。最初は、特定のタイプ（白ではない）の新しいキューブを取得するときに、テストに合格するプロセスを制御します。覚えているように、このようなチェックには任意の数の青いキューブを追加できます。

 class StatDieAcquireHandMaskRule(hand: Hand, private val requiredType: Die.Type) : HandMaskRule(hand) { /** * Define how many dice of specified type are currently checked */ private fun checkedDieCount(mask: HandMask) = (0 until hand.dieCount) .filter(mask::checkPosition) .mapNotNull(hand::dieAt) .count { it.type === requiredType } override fun checkMask(mask: HandMask) = (mask.allyPositionCount == 0 && checkedDieCount(mask) == 1) override fun isPositionActive(mask: HandMask, position: Int) = with(hand.dieAt(position)) { when { mask.checkPosition(position) -> true this == null -> false this.type === Die.Type.DIVINE -> true this.type === requiredType && checkedDieCount(mask) < 1 -> true else -> false } } override fun isAllyPositionActive(mask: HandMask, position: Int) = false }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2番目の実装はより複雑です。ターン終了時にサイコロを制御します。この場合、2つのオプションが可能です。手のキューブの数が最大許容サイズ（容量）を超える場合、すべての余分なキューブに加えて、必要な数の追加のキューブを破棄する必要があります。サイズを超えない場合、何もリセットできません（または、必要に応じてリセットできます）。灰色のサイコロを捨てることはできません。

 class DiscardExtraDiceHandMaskRule(hand: Hand) : HandMaskRule(hand) { private val minDiceToDiscard = if (hand.dieCount > hand.capacity) min(hand.dieCount - hand.woundCount, hand.dieCount - hand.capacity) else 0 private val maxDiceToDiscard = hand.dieCount - hand.woundCount override fun checkMask(mask: HandMask) = (mask.positionCount in minDiceToDiscard..maxDiceToDiscard) && (mask.allyPositionCount in 0..hand.allyDieCount) override fun isPositionActive(mask: HandMask, position: Int) = when { mask.checkPosition(position) -> true hand.dieAt(position) == null -> false hand.dieAt(position)!!.type == Die.Type.WOUND -> false mask.positionCount < maxDiceToDiscard -> true else -> false } override fun isAllyPositionActive(mask: HandMask, position: Int) = hand.allyDieAt(position) != null }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Nezhdanchik：クラスには、以前は存在しなかっHand



たプロパティが突然現れましたwoundCount



。実装は自分で書くことができます。簡単です。同時に練習します。



チェックに合格。

最終的にそれらに着きました。サイコロが手から取られたら、それらを投げる時間です。キューブごとに、サイズ、修飾子、スローの結果を考慮する必要があります。バッグから一度に取り出すことができるキューブは1つだけですが、複数のサイコロをセットして、ロールの結果を集計できます。一般的に、サイコロから抽象化し、戦場での軍隊を代表しましょう。一方では、敵がいます-彼はただ一人ですが、彼は強くて凶暴です。反対に、対戦相手は彼と同等の強さですが、サポートがあります。戦闘の結果は1回の短い小競り合いで決定され、勝者は1人だけになることができます...



すみません 一般的な戦いをシミュレートするために、特別なクラスを実装します。

 class DieBattleCheck(val method: Method, opponent: DiePair? = null) { enum class Method { SUM, AVG_UP, AVG_DOWN, MAX, MIN } private inner class Wrap(val pair: DiePair, var roll: Int) private infix fun DiePair.with(roll: Int) = Wrap(this, roll) private val opponent: Wrap? = opponent?.with(0) private val heroics = ArrayList<Wrap>() var isRolled = false var result: Int? = null val heroPairCount get() = heroics.size fun getOpponentPair() = opponent?.pair fun getOpponentResult() = when { isRolled -> opponent?.roll ?: 0 else -> throw IllegalStateException("Not rolled yet") } fun addHeroPair(pair: DiePair) { if (method == Method.SUM && heroics.size > 0) { pair.modifier = 0 } heroics.add(pair with 0) } fun addHeroPair(die: Die, modifier: Int) = addHeroPair(DiePair(die, modifier)) fun clearHeroPairs() = heroics.clear() fun getHeroPairAt(index: Int) = heroics[index].pair fun getHeroResultAt(index: Int) = when { isRolled -> when { (index in 0 until heroics.size) -> heroics[index].roll else -> 0 } else -> throw IllegalStateException("Not rolled yet") } fun roll() { fun roll(wrap: Wrap) { wrap.roll = wrap.pair.die.roll() } isRolled = true opponent?.let { roll(it) } heroics.forEach { roll(it) } } fun calculateResult() { if (!isRolled) { throw IllegalStateException("Not rolled yet") } val opponentResult = opponent?.let { it.roll + it.pair.modifier } ?: 0 val stats = heroics.map { it.roll + it.pair.modifier } val heroResult = when (method) { DieBattleCheck.Method.SUM -> stats.sum() DieBattleCheck.Method.AVG_UP -> ceil(stats.average()).toInt() DieBattleCheck.Method.AVG_DOWN -> floor(stats.average()).toInt() DieBattleCheck.Method.MAX -> stats.max() ?: 0 DieBattleCheck.Method.MIN -> stats.min() ?: 0 } result = heroResult - opponentResult } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

各キューブには修飾子を設定できるため、オブジェクトにデータを保存しますDiePair



。のようです。実際、いいえ、キューブと修飾子に加えて、そのスローの結果も保存する必要があります（キューブ自体はこの値を生成しますが、プロパティには保存しません）。したがって、各ペアをラッパーでラップします（Wrap



）。中置法に注意してくださいwith



hehe。



クラスコンストラクターは、集計メソッド（内部列挙のインスタンスMethod



）と対戦相手（存在しない場合があります）を定義します。ヒーローキューブのリストは、適切な方法を使用して作成されます。また、テストに関係するペアを取得するための多数のメソッドと、それらのスローの結果（存在する場合）も提供します。メソッドは各キューブの同名



メソッドをroll()



呼び出し、中間結果を保存し、その実行の事実をフラグでマークしますisRolled



。スローの最終結果はすぐに計算されないことに注意してください。これcalculateResult()



には特別なメソッドがあり、その結果はプロパティに最終値を書き込むことresult



です。なぜこれが必要なのですか？劇的な効果のため。メソッドroll()



は数回実行され、そのたびにキューブの面に異なる値が表示されます（実際のように）。そして、キューブがテーブルに落ち着いたときにのみ、最終結果（ヒーローのキューブと対戦相手のキューブの値の違い）の運命を学びます。ストレスを軽減するために、結果が0の場合はテストに合格したと見なされます。



ゲームエンジンの状態。

洗練されたオブジェクトが整理され、よりシンプルになりました。ゲームエンジンの現在の「進行」、それが置かれているステージまたはフェーズを制御する必要があると言うことは、大きな発見ではありません。これには特別な列挙が役立ちます。

 enum class GamePhase { SCENARIO_START, HERO_TURN_START, HERO_TURN_END, LOCATION_BEFORE_EXPLORATION, LOCATION_ENCOUNTER_STAT, LOCATION_ENCOUNTER_DIVINE, LOCATION_AFTER_EXPLORATION, GAME_LOSS }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際、さらに多くのフェーズがありますが、この例で使用されるフェーズのみを選択しました。ゲームエンジンのフェーズを変更するchangePhaseX()



にX



は、上記のリストの値であるメソッドを使用します。これらの方法では、エンジンのすべての内部変数は、対応するフェーズの開始に適した値に削減されますが、それ以降はさらに削減されます。



メッセージ

ゲームエンジンの状態を維持するだけでは不十分です。ユーザーが何らかの形で彼について通知することも重要です-さもなければ、後者は彼の画面で何が起こっているかをどのように知るのでしょうか？そのため、もう1つリストが必要です。

 enum class StatusMessage { EMPTY, CHOOSE_DICE_PERFORM_CHECK, END_OF_TURN_DISCARD_EXTRA, END_OF_TURN_DISCARD_OPTIONAL, CHOOSE_ACTION_BEFORE_EXPLORATION, CHOOSE_ACTION_AFTER_EXPLORATION, ENCOUNTER_PHYSICAL, ENCOUNTER_SOMATIC, ENCOUNTER_MENTAL, ENCOUNTER_VERBAL, ENCOUNTER_DIVINE, DIE_ACQUIRE_SUCCESS, DIE_ACQUIRE_FAILURE, GAME_LOSS_OUT_OF_TIME }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、この例のすべての可能な状態は、この列挙の値によって記述されています。それらのそれぞれについて、画面に表示されるテキスト行が提供されます（ただし、EMPTY



これは特別な意味です）が、これについては少し後で学習します。



アクション

ユーザーとゲームエンジン間の通信には、単純なメッセージでは不十分です。また、彼が現時点で取ることができる最初のアクションを知らせることも重要です（調査、ブロックの通過、移動の完了-それはすべて良いことです）。これを行うために、特別なクラスを開発します。

 class Action( val type: Type, var isEnabled: Boolean = true, val data: Int = 0 ) { enum class Type { NONE, //Blank type CONFIRM, //Confirm some action CANCEL, //Cancel action HAND_POSITION, //Some position in hand HAND_ALLY_POSITION, //Some ally position in hand EXPLORE_LOCATION, //Explore current location FINISH_TURN, //Finish current turn ACQUIRE, //Acquire (DIVINE) die FORFEIT, //Remove die from game HIDE, //Put die into bag DISCARD, //Put die to discard pile } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

内部列挙Type



は、実行されるアクションのタイプを記述します。このフィールドはisEnabled



、非アクティブ状態のアクションを表示するために必要です。つまり、このアクションは通常使用可能であるが、現時点では何らかの理由で実行できないことを報告することです（このような表示は、アクションがまったく表示されない場合よりもはるかに有益です）。プロパティdata



（一部のタイプのアクションに必要）には、追加の詳細（ユーザーが選択した位置のインデックスやリストから選択したアイテムの番号など）を報告する特別な値が格納されます。



クラスAction



ゲームエンジンと入出力システムの間の主要な「インターフェース」です（以下について）。多くの場合、いくつかのアクションがあるので（そうでなければ、なぜ選択するのですか？）、それらはグループ（リスト）に結合されます。標準のコレクションを使用する代わりに、独自の拡張コレクションを作成します。

 class ActionList : Iterable<Action> { private val actions = mutableListOf<Action>() val size get() = actions.size fun add(action: Action): ActionList { actions.add(action) return this } fun add(type: Action.Type, enabled: Boolean = true): ActionList { add(Action(type, enabled)) return this } fun addAll(actions: ActionList): ActionList { actions.forEach { add(it) } return this } fun remove(type: Action.Type): ActionList { actions.removeIf { it.type == type } return this } operator fun get(index: Int) = actions[index] operator fun get(type: Action.Type) = actions.find { it.type == type } override fun iterator(): Iterator<Action> = ActionListIterator() private inner class ActionListIterator : Iterator<Action> { private var position = -1 override fun hasNext() = (actions.size > position + 1) override fun next() = actions[++position] } companion object { val EMPTY get() = ActionList() } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このクラスには、リストにアクションを追加および削除するためのさまざまなメソッド（チェーン化可能）、およびインデックスとタイプの両方を取得するためのさまざまなメソッドが含まれます（「オーバーロード」に注意してくださいget()



-角括弧演算子はリストに適用できます）。インターフェースの実装により、Iterator



クラスであらゆる種類の狂気のたわごと（機能、aha）でさまざまなストリーム操作を行うことができます。空のリストをすばやく作成するために、EMPTY値も提供されます。



スクリーン。

最後に、現在表示されているさまざまな種類のコンテンツを説明する別のリスト...あなたは私を見て目を瞬きます。このクラスをより明確に説明する方法を考え始めたとき、私は本当に何も理解できなかったので、テーブルに頭を打ちました。自分自身を理解し、私は願っています。

 enum class GameScreen { HERO_TURN_START, LOCATION_INTERIOR, GAME_LOSS }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

例で使用されているもののみを選択しました。個別のレンダリング方法がそれらのそれぞれに提供されます...私は再び不可解に説明します。



「表示」および「入力」。

そして今、私たちはついに最も重要なポイントに到達しました-ゲームエンジンとユーザー（プレイヤー）との相互作用です。このような長い導入にまだ飽きていない場合は、これら2つの部分を機能的に分離することに同意したことをおそらく覚えているでしょう。したがって、I / Oシステムの特定の実装の代わりに、インターフェイスのみを提供します。より正確には、2。



最初のインターフェースGameRenderer



、画面に画像を表示するように設計されています。画面サイズ、特定のグラフィックライブラリなどから抽象化されていることを思い出してください。 「draw me this」というコマンドを送信するだけです。画面についての不明瞭な会話を理解している人は、これらの画面のそれぞれがインターフェイス内に独自のメソッドを持っていることをすでに推測しています。

 interface GameRenderer { fun drawHeroTurnStart(hero: Hero) fun drawLocationInteriorScreen( location: Location, heroesAtLocation: List<Hero>, timer: Int, currentHero: Hero, battleCheck: DieBattleCheck?, encounteredDie: DiePair?, pickedDice: HandMask, activePositions: HandMask, statusMessage: StatusMessage, actions: ActionList ) fun drawGameLoss(message: StatusMessage) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

追加の説明は必要ないと思います-転送されたすべてのオブジェクトの目的は上記で詳細に説明されています。



ユーザー入力のために、別のインターフェイスを実装します- GameInteractor



（はい、スペルチェックスクリプトは常にこの単語を強調しますが、それは…と思われますが）。彼の方法は、さまざまな状況で必要なコマンドをプレイヤーに要求します：提案されたもののリストからアクションを選択し、リストから要素を選択し、手からキューブを選択し、少なくとも何かを押すだけなど。入力は同期的である（ゲームは段階的である）こと、つまり、ユーザーがリクエストに応答するまでゲームサイクルの実行が中断されることに注意してください。

 interface GameInteractor{ fun anyInput() fun pickAction(list: ActionList): Action fun pickDiceFromHand(activePositions: HandMask, actions: ActionList): Action }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最後の方法についてもう少し。名前が示すように、fromは、ユーザーを手からキューブを選択するように招待し、オブジェクトHandMask



-アクティブなポジションの数を提供します。メソッドの実行は、それらのいくつかが選択されるまで続きます。この場合、メソッドは、フィールド内の選択された位置の番号とともにタイプHAND_POSITION



（またはHAND_ALLY_POSITION



mda）のアクションを返しますdata



。さらに、オブジェクトから別のアクション（CONFIRM



またはなどCANCEL



）を選択することもできますActionList



。入力メソッドの実装では、フィールドがisEnabled



設定されている状況を区別しfalse



、そのようなアクションのユーザー入力を無視する必要があります。



ゲームエンジンクラス。

私たちは仕事に必要なすべての良さ、時が来た、そして実装されるエンジンを考慮しました。クラスを作成するGame



次のコンテンツ：





メソッドstart()



-ゲームへのエントリポイント。ここでは、変数が初期化され、ヒーローが計量され、手が立方体で満たされ、レポーターはあらゆる面からカメラで輝きます。メインサイクルは毎分起動され、その後は停止できなくなります。メソッドdrawInitialHand()



はそれ自体を物語っています（drawOfType()



クラスメソッドのコードを考慮しなかったようですBag



が、一緒に長い道のりを進んだ後、このコードを自分で書くことができます）。このメソッドにrefillHeroHand()



は2つのオプション（引数の値に応じてredrawScreen



）があります：高速で静か（ゲームの開始時にすべてのヒーローの手を満たす必要がある場合）、および大声でパトスで、移動の終わりにバッグからキューブを丁寧に取り除き、手を適切なサイズにする必要があります。



次で始まる名前のメソッドの束changePhase



、-すでに述べたように、それらは現在のゲームフェーズを変更する役割を果たし、ゲーム変数の対応する値の割り当てに従事しています。ここではactions



、このフェーズに特有のアクションが追加されるリストが形成されます。一般化された形式



のユーティリティメソッドpickDiceFromHand()



は、手からキューブを選択します。ここHandMaskRule



では、選択規則を定義する使い慣れたクラスのオブジェクトが渡されます。また、選択を拒否するallowCancel



機能（）、onEachLoop



および選択したキューブのリストが変更されるたびにコードを呼び出す必要がある関数（通常は画面の再描画）も示します。このメソッドによって選択されたキューブは、collectPickedDice()



およびメソッドを使用して手で組み立てることができますcollectPickedAllyDice()



。



別のユーティリティメソッドperformStatDieAcquireCheck()



新しいキューブを取得するためのテストに合格したヒーローを完全に実装します。このメソッドの中心的な役割は、オブジェクトによって果たされますDieBattleCheck



。プロセスは、メソッドによるキューブの選択から始まりますpickDiceFromHand()



（各ステップで、「参加者」のリストが更新されますDieBattleCheck



）。選択したキューブが手から削除され、その後「ロール」が発生します-各ダイは値を更新し（連続して8回）、その後、結果が計算されて表示されます。ロールに成功すると、新しいダイスがヒーローの手に落ちます。テストに参加しているキューブは、保持されている（青の場合shouldDiscard = true



）か、破棄されている（の場合shouldDiscard = false



）か、バッグの中に隠されています（の場合）。



主な方法processCycle()



無限ループ（私は失神せずに尋ねます）が含まれます。最初に画面が描画され、次にユーザーに入力が求められ、次にこの入力が処理されます-その後のすべての結果。メソッドdrawScreen()



は、GameRenderer



現在の値に応じて、目的のインターフェイスメソッドを呼び出し、screen



必要なオブジェクトを入力に渡します。



また、このクラスには、いくつかのヘルパーメソッドが含まれていますcheckLocationCanBeExplored()



、checkHeroCanAttemptStatCheck()



とcheckHeroCanAcquireDie()



。彼らの名前は彼ら自身のために語っています。したがって、私たちはそれらについて詳しくは述べません。Audio



赤い波線で下線が引かれたクラスメソッド呼び出しもあります。とりあえずコメントしてください。その目的は後で検討します。





以上で、ゲームの準備は完了です（hehe）。残りの些細な事は残りました、それらについては以下に。

ステップ9。画像を表示する

そこで、今日の会話のメイントピック、つまりアプリケーションのグラフィックコンポーネントについて説明します。ご存知のように、私たちの仕事はインターフェイスGameRenderer



とその3つのメソッドを実装することです。チームにはまだ才能のあるアーティストがいないため、疑似グラフィックを使用して独自にこれを行います。しかし、初心者にとっては、出口で一般的に見られるものを理解しておくといいでしょう。そして、およそ次の内容の3つの画面を見たいと思います。









表示されている画像は、Javaアプリケーションのコンソールで通常使用されるものとは異なるものであり、通常の機能でprinltn()



は明らかに不十分であることを、大多数がすでに認識していると思います。また、画面上の任意の場所にジャンプして、異なる色でシンボルを描画できるようにしたいと思います。チップとデールのANSIコード



が私たちの助けに駆けつけます 。奇妙な文字列を出力に送信することで、テキスト/背景の色、文字の描画方法、画面上のカーソルの位置などを変更するなど、奇妙な効果を得ることができます。もちろん、それらを純粋な形で紹介するのではなく、クラスのメソッドの背後に実装を隠します。そして、クラス自体をゼロから書くことはしません-幸いなことに、賢い人々が私たちのためにそれをしてくれました。Jansiなどの軽量ライブラリをダウンロードしてプロジェクトに接続するだけです。

 <dependency> <groupId>org.fusesource.jansi</groupId> <artifactId>jansi</artifactId> <version>1.17.1</version> <scope>compile</scope> </dependency>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、作成を開始できます。このライブラリは、チェーン化できる便利なメソッドの束を持つクラスオブジェクトAnsi



（静的呼び出しの結果として取得されるAnsi.ansi()



）を提供します。それはStringBuilder



'a の原則に基づいて動作します-最初にオブジェクトを作成し、それを印刷に送ります。便利なメソッドのうち、便利なものを見つけます。

• a()
  
  
  
  -文字を表示します。
• cursor()
  
  
  
  -画面上でカーソルを移動します。
• eraseLine()
  
  
  
  -まるで自分自身のことを話すかのように。
• eraseScreen()
  
  
  
  -同様に;
• fg(), bg(), fgBright(), bgBright()
  
  
  
  -テキストと背景色を操作するための非常に不便な方法-独自の、より快適なものにします。
• reset()
  
  
  
  -設定された色設定、フリッカーなどをリセットします。

ConsoleRenderer



私たちの仕事に役立つかもしれないユーティリティメソッドを持つクラスを作成しましょう。最初のバージョンは次のようになります。

 abstract class ConsoleRenderer() { protected lateinit var ansi: Ansi init { AnsiConsole.systemInstall() clearScreen() resetAnsi() } private fun resetAnsi() { ansi = Ansi.ansi() } fun clearScreen() { print(Ansi.ansi().eraseScreen(Ansi.Erase.ALL).cursor(1, 1)) } protected fun render() { print(ansi.toString()) resetAnsi() } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このメソッドresetAnsi()



はAnsi



、必要なコマンド（移動、出力など）で満たされる新しい（空の）オブジェクトを作成します。記入が完了すると、生成されたオブジェクトはメソッドによって印刷のために送信されrender()



、変数は新しいオブジェクトで初期化されます。まだ複雑なことはありませんか？もしそうなら、このクラスを他の便利なメソッドで埋め始めます。



サイズから始めましょう。ほとんどの端末の標準コンソールのサイズは80x24です。2つの定数CONSOLE_WIDTH



とでこの事実に注意しCONSOLE_HEIGHT



ます。私たちは特定の値に執着することはせず、デザインを可能な限りゴム状にしようとします（ウェブのように）。座標の番号付けは1から始まり、最初の座標は行、2番目の座標は列です。これらすべてを知って、ユーティリティメソッドを記述しますdrawHorizontalLine()



指定された文字列を指定された文字で埋めます。

 protected fun drawHorizontalLine(offsetY: Int, filler: Char) { ansi.cursor(offsetY, 1) (1..CONSOLE_WIDTH).forEach { ansi.a(filler) } //for (i in 1..CONSOLE_WIDTH) { ansi.a(filler) } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

繰り返しになりますが、コマンドを呼び出しa()



たりcursor()



、すぐにエフェクトを実行したりすることはなく、Ansi



対応する一連のコマンドをオブジェクトに追加するだけです。これらのシーケンスが印刷用に送信されたときにのみ、画面に表示されます。



古典的なサイクルの使用との間for



で機能的なアプローチClosedRange



とforEach{}



根本的な違いはありません-各開発者は、それがより便利であると判断しました。しかし、私は新しいものすべてを愛している猿であり、光沢のあるブラケットが新しい行にラップされておらず、コードがよりコンパクトに見えるという理由だけで、機能主義であなたをだまし続けます。同じことを行う



別のユーティリティメソッドを実装しますdrawBlankLine()



drawHorizontalLine(offsetY, ' ')



、拡張子のみ。場合によっては、行を完全に空にする必要はありませんが、最初と最後に垂直線を残す必要があります（フレーム、そうです）。コードは次のようになります。

 protected fun drawBlankLine(offsetY: Int, drawBorders: Boolean = true) { ansi.cursor(offsetY, 1) if (drawBorders) { ansi.a('│') (2 until CONSOLE_WIDTH).forEach { ansi.a(' ') } ansi.a('│') } else { ansi.eraseLine(Ansi.Erase.ALL) } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

どのように、疑似グラフィックスからフレームを描画したことはありませんか？シンボルは、ソースコードに直接挿入できます。Altキーを押しながら、数字キーパッドで文字コードを入力します。放して 必要なASCIIコードはどのエンコードでも同じです。これが最小限の紳士のセットです。









そして、Minecraftのように、可能性はあなたの想像力の限界によってのみ制限されます。そして画面サイズ。

 protected fun drawCenteredCaption(offsetY: Int, text: String, color: Color, drawBorders: Boolean = true) { val center = (CONSOLE_WIDTH - text.length) / 2 ansi.cursor(offsetY, 1) ansi.a(if (drawBorders) '│' else ' ') (2 until center).forEach { ansi.a(' ') } ansi.color(color).a(text).reset() (text.length + center until CONSOLE_WIDTH).forEach { ansi.a(' ') } ansi.a(if (drawBorders) '│' else ' ') }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

花について少し話しましょう。このクラスにAnsi



はColor



、8つの原色（黒、青、緑、シアン、赤、紫、黄、グレー）の定数が含まれています。これらは、色を識別するために非常に不便なfg()/bg()



暗いバージョンまたは明るいバージョンのメソッドの入力に渡す必要がありますfgBright()/bgBright()



方法では、1つの値では不十分です-少なくとも2つ（色と明るさ）が必要です。したがって、定数のリストと拡張メソッドを作成します（キューブの種類とヒーローのクラスに色をマップバインドします）。

 protected enum class Color { BLACK, DARK_BLUE, DARK_GREEN, DARK_CYAN, DARK_RED, DARK_MAGENTA, DARK_YELLOW, LIGHT_GRAY, DARK_GRAY, LIGHT_BLUE, LIGHT_GREEN, LIGHT_CYAN, LIGHT_RED, LIGHT_MAGENTA, LIGHT_YELLOW, WHITE } protected fun Ansi.color(color: Color?): Ansi = when (color) { Color.BLACK -> fgBlack() Color.DARK_BLUE -> fgBlue() Color.DARK_GREEN -> fgGreen() Color.DARK_CYAN -> fgCyan() Color.DARK_RED -> fgRed() Color.DARK_MAGENTA -> fgMagenta() Color.DARK_YELLOW -> fgYellow() Color.LIGHT_GRAY -> fg(Ansi.Color.WHITE) Color.DARK_GRAY -> fgBrightBlack() Color.LIGHT_BLUE -> fgBrightBlue() Color.LIGHT_GREEN -> fgBrightGreen() Color.LIGHT_CYAN -> fgBrightCyan() Color.LIGHT_RED -> fgBrightRed() Color.LIGHT_MAGENTA -> fgBrightMagenta() Color.LIGHT_YELLOW -> fgBrightYellow() Color.WHITE -> fgBright(Ansi.Color.WHITE) else -> this } protected fun Ansi.background(color: Color?): Ansi = when (color) { Color.BLACK -> ansi.bg(Ansi.Color.BLACK) Color.DARK_BLUE -> ansi.bg(Ansi.Color.BLUE) Color.DARK_GREEN -> ansi.bgGreen() Color.DARK_CYAN -> ansi.bg(Ansi.Color.CYAN) Color.DARK_RED -> ansi.bgRed() Color.DARK_MAGENTA -> ansi.bgMagenta() Color.DARK_YELLOW -> ansi.bgYellow() Color.LIGHT_GRAY -> ansi.bg(Ansi.Color.WHITE) Color.DARK_GRAY -> ansi.bgBright(Ansi.Color.BLACK) Color.LIGHT_BLUE -> ansi.bgBright(Ansi.Color.BLUE) Color.LIGHT_GREEN -> ansi.bgBrightGreen() Color.LIGHT_CYAN -> ansi.bgBright(Ansi.Color.CYAN) Color.LIGHT_RED -> ansi.bgBrightRed() Color.LIGHT_MAGENTA -> ansi.bgBright(Ansi.Color.MAGENTA) Color.LIGHT_YELLOW -> ansi.bgBrightYellow() Color.WHITE -> ansi.bgBright(Ansi.Color.WHITE) else -> this } protected val dieColors = mapOf( Die.Type.PHYSICAL to Color.LIGHT_BLUE, Die.Type.SOMATIC to Color.LIGHT_GREEN, Die.Type.MENTAL to Color.LIGHT_MAGENTA, Die.Type.VERBAL to Color.LIGHT_YELLOW, Die.Type.DIVINE to Color.LIGHT_CYAN, Die.Type.WOUND to Color.DARK_GRAY, Die.Type.ENEMY to Color.DARK_RED, Die.Type.VILLAIN to Color.LIGHT_RED, Die.Type.OBSTACLE to Color.DARK_YELLOW, Die.Type.ALLY to Color.WHITE ) protected val heroColors = mapOf( Hero.Type.BRAWLER to Color.LIGHT_BLUE, Hero.Type.HUNTER to Color.LIGHT_GREEN )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

現在、利用可能な16色のそれぞれは、単一の定数によって一意に識別されます。さらにいくつかのユーティリティメソッドを記述しますが、その前にもう1つ



、テキスト文字列の定数をどこに保存するかを考えます。



「文字列定数は、すべて1か所に保存されるように、別々のファイルに取り出す必要があります。これにより、文字列定数の保守が容易になります。また、ローカライズにとっても重要です...」



文字列定数を別のファイルに移動する必要があります...そうですね。我慢します。この種のリソースを操作するための標準Javaメカニズムは、java.util.ResourceBundle



ファイルを操作するオブジェクトです.properties



。このようなファイルから始めます。

 # Game status messages choose_dice_perform_check=Choose dice to perform check: end_of_turn_discard_extra=END OF TURN: Discard extra dice: end_of_turn_discard_optional=END OF TURN: Discard any dice, if needed: choose_action_before_exploration=Choose your action: choose_action_after_exploration=Already explored this turn. Choose what to do now: encounter_physical=Encountered PHYSICAL die. Need to pass respective check or lose this die. encounter_somatic=Encountered SOMATIC die. Need to pass respective check or lose this die. encounter_mental=Encountered MENTAL die. Need to pass respective check or lose this die. encounter_verbal=Encountered VERBAL die. Need to pass respective check or lose this die. encounter_divine=Encountered DIVINE die. Can be acquired automatically (no checks needed): die_acquire_success=You have acquired the die! die_acquire_failure=You have failed to acquire the die. game_loss_out_of_time=You ran out of time # Die types physical=PHYSICAL somatic=SOMATIC mental=MENTAL verbal=VERBAL divine=DIVINE ally=ALLY wound=WOUND enemy=ENEMY villain=VILLAIN obstacle=OBSTACLE # Hero types and descriptions brawler=Brawler hunter=Hunter # Various labels avg=avg bag=Bag bag_size=Bag size class=Class closed=Closed discard=Discard empty=Empty encountered=Encountered fail=Fail hand=Hand heros_turn=%s's turn max=max min=min perform_check=Perform check: pile=Pile received_new_die=Received new die result=Result success=Success sum=sum time=Time total=Total # Action names and descriptions action_confirm_key=ENTER action_confirm_name=Confirm action_cancel_key=ESC action_cancel_name=Cancel action_explore_location_key=E action_explore_location_name=xplore action_finish_turn_key=F action_finish_turn_name=inish action_hide_key=H action_hide_name=ide action_discard_key=D action_discard_name=iscard action_acquire_key=A action_acquire_name=cquire action_leave_key=L action_leave_name=eave action_forfeit_key=F action_forfeit_name=orfeit
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

各行には、文字で区切られたキーと値のペアが含まれています=



。ファイルはどこにでも置くことができます-主なことは、ファイルへのパスがクラスパスの一部であることです。アクションのテキストは2つの部分で構成されていることに注意してください。最初の文字は、画面に表示されるときに黄色で強調表示されるだけでなく、このアクションを実行するために押す必要があるキーも決定します。したがって、それらを別々に保存すると便利です。



ただし、特定の形式（たとえば、Androidでは文字列の保存方法が異なる）から抽象化し、文字列定数を読み込むためのインターフェイスについて説明します。

 interface StringLoader { fun loadString(key: String): String }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

キーは入力に送信され、出力は特定の行です。実装は、インターフェース自体と同じくらい簡単です（ファイルがpathに沿っていると仮定しますsrc/main/resources/text/strings.properties



）。

 class PropertiesStringLoader() : StringLoader { private val properties = ResourceBundle.getBundle("text.strings") override fun loadString(key: String) = properties.getString(key) ?: "" }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これdrawStatusMessage()



で、ゲームエンジンの現在の状態を画面に表示するStatusMessage



方法drawActionList()



（ActionList



）と使用可能なアクションのリストを表示する方法（）を実装することは難しくありません。魂だけが望む他の公式な方法と同様に。





なぜ私たち全員がこれをしたのですか？はい、この素晴らしいclassからインターフェース実装を継承するためにGameRenderer



。





これは、最初の最も単純なメソッドの実装がどのように見えるかです：

 override fun drawGameLoss(message: StatusMessage) { val centerY = CONSOLE_HEIGHT / 2 (1 until centerY).forEach { drawBlankLine(it, false) } val data = loadString(message.toString().toLowerCase()).toUpperCase() drawCenteredCaption(centerY, data, LIGHT_RED, false) (centerY + 1..CONSOLE_HEIGHT).forEach { drawBlankLine(it, false) } render() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

超自然的なものではなくdata



、画面の中央にテキスト行（）を赤で1つだけ描画します（drawCenteredCaption()



）。コードの残りは、画面の残りを空白行で埋めます。おそらく誰かがこれが必要な理由を尋ねるでしょう-結局のところclearScreen()



、メソッドがあり、メソッドの最初にそれを呼び出し、画面をクリアしてから、必要なテキストを描画するだけで十分です。残念ながら、これは私たちが使用しない怠laなアプローチです。その理由は非常に簡単です。このアプローチでは、画面上の一部の位置が2回描画され、特に画面が連続して数回連続して描画される場合（アニメーション中）に、ちらつきが顕著になります。したがって、私たちのタスクは、適切な場所に適切なキャラクターを描くだけでなく、全体を埋めることです空の文字を含む画面の残りの部分（他のレンダリングからのアーティファクトが画面に残らないようにするため）。そして、このタスクはそれほど単純ではありません。



次の方法は、この原則に従います。

 override fun drawHeroTurnStart(hero: Hero) { val centerY = (CONSOLE_HEIGHT - 5) / 2 (1 until centerY).forEach { drawBlankLine(it, false) } ansi.color(heroColors[hero.type]) drawHorizontalLine(centerY, '─') drawHorizontalLine(centerY + 4, '─') ansi.reset() ansi.cursor(centerY + 1, 1).eraseLine() ansi.cursor(centerY + 3, 1).eraseLine() ansi.cursor(centerY + 2, 1) val text = String.format(loadString("heros_turn"), hero.name.toUpperCase()) val index = text.indexOf(hero.name.toUpperCase()) val center = (CONSOLE_WIDTH - text.length) / 2 ansi.cursor(centerY + 2, center) ansi.eraseLine(Ansi.Erase.BACKWARD) ansi.a(text.substring(0, index)) ansi.color(heroColors[hero.type]).a(hero.name.toUpperCase()).reset() ansi.a(text.substring(index + hero.name.length)) ansi.eraseLine(Ansi.Erase.FORWARD) (centerY + 5..CONSOLE_HEIGHT).forEach { drawBlankLine(it, false) } render() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、中央揃えのテキストに加えて、2本の水平線もあります（上のスクリーンショットを参照）。中央のレタリングは2色で表示されることに注意してください。また、学校で数学を学ぶことはまだ有用であることを確認してください。



さて、最も単純なメソッドを見て、実装を知る時が来ましたdrawLocationInteriorScreen()



。あなた自身が理解しているように、ここにはさらに桁違いのコードがあります。さらに、画面のコンテンツはユーザーのアクションに応じて動的に変化するため、常に再描画する必要があります（アニメーションを使用する場合もあります）。さて、最終的にあなたを終わらせるために：上記のスクリーンショットに加えて、このメソッドのフレームワークでは、さらに3つの表示を実装する必要があることを想像してください：









したがって、ここにあなたへの私の素晴らしいアドバイスがあります：1つのメソッドにすべてのコードを押し込まないでください。実装をいくつかのメソッドに分割します（各メソッドが1回だけ呼び出される場合でも）。さて、「ゴム」を忘れないでください。





このすべてのコードの動作をチェックすることに関連する1つの小さな問題があります。組み込みのIDEコンソールはANSIエスケープシーケンスをサポートしないため、外部端末でアプリケーションを起動する必要があります（以前に起動するためのスクリプトを既に作成しました）。さらに、ANSIサポートでは、Windowsですべてがうまくいくわけではありません-私の知る限り、標準のcmd.exeでのみ高品質の表示が可能になります（そして、私たちが焦点を当てない問題もあります）。また、PowerShellはシーケンスを認識することをすぐには学習しませんでした（現在の要求にもかかわらず）。運が悪い場合は、落胆しないでください-常に代替ソリューションがあります（たとえば、これ）。そして次に進みます。

ステップ10 ユーザー入力

画面に画像を表示することは、戦いの半分です。ユーザーから制御コマンドを正しく受信することも同様に重要です。また、このタスクは、以前のすべてのタスクよりも実装が技術的にはるかに困難であることが判明する可能性があります。しかし、まず最初に。



あなたが思い出すように、クラスメソッドを実装する必要に直面していますGameInteractor



。それらは3つしかありませんが、特別な注意が必要です。まず、同期。プレイヤーがキーを押すまで、ゲームエンジンの作業を中断する必要があります。第二に、クリック処理。残念ながら、標準クラスの容量はReader



、Scanner



、Console



これらのほとんどの押しを認識するために十分ではありません。私たちは、各コマンドの後にEnterキーを押しにユーザを必要としません。KeyListener



'aのようなものが必要ですが、それはSwingフレームワークにしっかりと接続されており、コンソールアプリケーションにはこのグラフィック見掛け倒しはありません。



どうする？もちろん、ライブラリの検索は、今回は完全にネイティブコードに依存します。 「さようなら、クロスプラットフォーム」とはどういう意味ですか？残念ながら、軽量でプラットフォームに依存しない形式でシンプルな機能を実装するライブラリをまだ見つけていません。それまでの間、モンスターjLineに注目しましょう。jLineは、コンソールで高度なユーザーインターフェイスを構築するためのハーベスターを実装しています。はい、ネイティブ実装です。はい、WindowsとLinux / UNIXの両方をサポートします（適切なライブラリを提供することにより）。そして、はい、使用上のその機能のほとんどは、我々は百年は必要ありません。必要なのは、小さな、不十分に文書化された機会だけであり、その作業をこれから分析します。

 <dependency> <groupId>jline</groupId> <artifactId>jline</artifactId> <version>2.14.6</version> <scope>compile</scope> </dependency>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

3番目の最新バージョンではなく、ConsoleReader



methodを持つクラスがある2番目のバージョンが必要であることに注意してくださいreadCharacter()



。名前が示すように、このメソッドはキーボードで押された文字のコードを返します（同時に動作しますが、これが必要です）。残りは技術的な問題です。シンボルとアクションのタイプ間の対応表（Action.Type



）を作成し、一方をクリックして他方を返します。



「キーボードのすべてのキーが1文字で表現できるわけではないことをご存知ですか？多くのキーは、2、3、4文字のエスケープシーケンスを使用します。彼らと一緒にいる方法は？」



「文字以外のキー」（矢印、Fキー、ホーム、挿入、PgUp / Dn、終了、削除、テンキーなど）を認識したい場合、入力タスクは複雑になることに注意してください。しかし、私たちは望んでいないので、継続します。ConsoleInteractor



必要なサービスメソッドを持つクラスを作成しましょう。

 abstract class ConsoleInteractor { private val reader = ConsoleReader() private val mapper = mapOf( CONFIRM to 13.toChar(), CANCEL to 27.toChar(), EXPLORE_LOCATION to 'e', FINISH_TURN to 'f', ACQUIRE to 'a', LEAVE to 'l', FORFEIT to 'f', HIDE to 'h', DISCARD to 'd', ) protected fun read() = reader.readCharacter().toChar() protected open fun getIndexForKey(key: Char) = "1234567890abcdefghijklmnopqrstuvw".indexOf(key) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

マップmapper



とメソッドを設定しますread()



。さらにgetIndexForKey()



、リストからアイテムを選択する必要がある場合や、手からキューブを選択する必要がある場合に使用する方法を提供します。このクラスからインターフェース実装を継承することは残っていますGameInteractor



。





そして、実際には、コード：

 class ConsoleGameInteractor : ConsoleInteractor(), GameInteractor { override fun anyInput() { read() } override fun pickAction(list: ActionList): Action { while (true) { val key = read() list .filter(Action::isEnabled) .find { mapper[it.type] == key } ?.let { return it } } } override fun pickDiceFromHand(activePositions: HandMask, actions: ActionList) : Action { while (true) { val key = read() actions.forEach { if (mapper[it.type] == key && it.isEnabled) return it } when (key) { in '1'..'9' -> { val index = key - '1' if (activePositions.checkPosition(index)) { return Action(HAND_POSITION, data = index) } } '0' -> { if (activePositions.checkPosition(9)) { return Action(HAND_POSITION, data = 9) } } in 'a'..'f' -> { val allyIndex = key - 'a' if (activePositions.checkAllyPosition(allyIndex)) { return Action(HAND_ALLY_POSITION, data = allyIndex) } } } } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メソッドの実装は、さまざまな不適切なナンセンスを出さないように、非常に丁寧で礼儀正しいものです。選択したアクションがアクティブであり、選択した手の位置が許容セットに含まれていることを確認します。そして、私たち全員が私たちの周りの人々に対して丁寧であることを願っています。

ステップ11。音と音楽

しかし、それなしではどうでしょうか？サウンドをオフにしてゲームをプレイしたことがある場合（たとえば、自宅に誰もいないときにタブレットをカバーの下に置いた場合）、どれだけ負けているかを実感できたかもしれません。ゲームの半分だけをプレイするようなものです。多くのゲームは、音の伴奏なしでは想像できません。多くの場合、これは不可逆的な要件ですが、逆の状況があります（たとえば、原則として音がない場合、またはそれらがなければ悲惨であり、それらがなければ良いでしょう）。良い仕事をすることは、実際には一見したほど簡単ではありません（理由は大規模なスタジオで高度な専門家がこれを行うためです）が、それは、ほとんどの場合、ゲーム内にオーディオコンポーネント（少なくともいくつか）を持っている方がはるかに良いことです彼女が全くいないより最後の手段として、後で音質を改善できますが、時間と気分が許すとき。



このジャンルの特性により、私たちのゲームは傑作のサウンドエフェクトによって特徴付けられることはありません。ボードゲームのデジタル版をプレイした場合、その意味は理解できます。音はその均一性をはじき、すぐに退屈になり、しばらくすると、音なしで演奏することは深刻な損失のようには見えなくなります。問題は、この現象に対処する効果的な方法がないという事実によって悪化します。ゲームサウンドを完全に異なるものに置き換えると、時間が経つとうんざりします。良いゲームでは、サウンドはゲームプレイを補完し、進行中のアクションの雰囲気を明らかにし、生き生きとしたものにします-雰囲気がただのゴミ袋のあるテーブルであり、ゲームプレイ全体がサイコロを投げることで構成されている場合、これを達成することは困難です。それにもかかわらず、これはまさに私たちが発言するものです。シルクはここにあり、キャストはここにあり、ざわめき、大きな叫び声にざわめきます。まるでスクリーン上の画像を観察していないかのように、実際の物理的なオブジェクトと実際にやり取りしているように。それらは完全に、しかし控えめに発声する必要があります-スクリプト全体で同じ100回聞こえるので、音が前面に出てはなりません-ゲームプレイを穏やかにシェーディングするだけです。これを有能に達成する方法は？わからない、音が特別じゃない。目立つ欠陥に気づき、磨くように、できるだけゲームをプレイすることをお勧めします（このアドバイスは、音だけでなく適用されます）。これを有能に達成する方法は？わからない、音が特別じゃない。目立つ欠陥に気づき、磨くように、できるだけゲームをプレイすることをお勧めします（このアドバイスは、音だけでなく適用されます）。これを有能に達成する方法は？わからない、音が特別じゃない。目立つ欠陥に気づき、磨くように、できるだけゲームをプレイすることをお勧めします（このアドバイスは、音だけでなく適用されます）。



理論で、それを整理し、それが練習に移る時が来たようです。そしてその前に、質問をする必要があります。実際、ゲームファイルをどこで取得するのでしょうか。最も簡単で確実な方法-古いマイクを使用して、または電話を使用しても、見苦しい品質で自分で録音することができます。インターネットには、パイナップルの上部のねじを緩めたり、ブーツで氷を砕いたりして、骨を砕いてカリカリとした背骨の効果を実現する方法に関するビデオがたくさんあります。シュルレアリスムの美学に馴染みのない人は、自分の声や台所用品を楽器として使うことができます（これが行われた例や成功例さえあります）。または、freesound.orgにアクセスできますずっと前に他の百人があなたのためにこれをした場所。ライセンスのみに注意してください：多くの著者は、大きな咳や床に投げられたコインのオーディオ録音に非常に敏感です-あなたは決して、元の作成者にお金を払ったり、彼の創造的な仮名に言及しないで彼らの労働の成果を悪用することは決してしません（時には非常に奇妙です）コメントで。



好きなファイルをドラッグアンドドロップして、クラスパスのどこかに置きます。それらを識別するために、各インスタンスが1つのサウンドエフェクトに対応する列挙を使用します。

 enum class Sound { TURN_START, //Hero starts the turn BATTLE_CHECK_ROLL, //Perform check, type BATTLE_CHECK_SUCCESS, //Check was successful BATTLE_CHECK_FAILURE, //Check failed DIE_DRAW, //Draw die from bag DIE_HIDE, //Remove die to bag DIE_DISCARD, //Remove die to pile DIE_REMOVE, //Remove die entirely DIE_PICK, //Check/uncheck the die TRAVEL, //Move hero to another location ENCOUNTER_STAT, //Hero encounters STAT die ENCOUNTER_DIVINE, //Hero encounters DIVINE die ENCOUNTER_ALLY, //Hero encounters ALLY die ENCOUNTER_WOUND, //Hero encounters WOUND die ENCOUNTER_OBSTACLE, //Hero encounters OBSTACLE die ENCOUNTER_ENEMY, //Hero encounters ENEMY die ENCOUNTER_VILLAIN, //Hero encounters VILLAIN die DEFEAT_OBSTACLE, //Hero defeats OBSTACLE die DEFEAT_ENEMY, //Hero defeats ENEMY die DEFEAT_VILLAIN, //Hero defeats VILLAIN die TAKE_DAMAGE, //Hero takes damage HERO_DEATH, //Hero death CLOSE_LOCATION, //Location closed GAME_VICTORY, //Scenario completed GAME_LOSS, //Scenario failed ERROR, //When something unexpected happens }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サウンドの再生方法はハードウェアプラットフォームによって異なるため、インターフェイスを使用して特定の実装から抽象化できます。たとえば、これは：

 interface SoundPlayer { fun play(sound: Sound) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

前述のインターフェイスGameRenderer



およびと同様にGameInteractor



、その実装もクラスインスタンスへの入力に渡す必要がありますGame



。まず、実装は次のようになります。

 class MuteSoundPlayer : SoundPlayer { override fun play(sound: Sound) { //Do nothing } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、より興味深い実装を検討しますが、今は音楽について話しましょう。

効果音と同様に、ゲームの雰囲気を作り出す上で大きな役割を果たします。同様に、優れたゲームは不適切な音楽によって台無しにされる可能性があります。音と同様に、音楽は控えめで、芸術的な効果が必要な場合を除いて、画面上のアクションに適切に対応する必要があります（待ち伏せされ容赦なく殺されたメインの運命を誰かが真剣に吹き込んだことを期待しないでください）ヒーロー、彼の悲劇的な死の場面が子供の歌からの楽しい小さな音楽を伴う場合）。これを達成するのは非常に難しく、特別に訓練された人々がそのような問題に対処します（私たちはそれらに不慣れです）が、ゲーム構築の天才の初心者として、私たちも何かをすることができます。たとえば、どこかに行くfreemusicarchive.orgまたはsoundcloud.com（やYouTube）と自分好みに何かを見つけます。デスクトップの場合、アンビエントは良い選択です。はっきりしたメロディーのない静かで滑らかな音楽で、背景の作成に適しています。ライセンスに注意を払ってください。無料の音楽でさえ、金銭的な報酬ではないにしても、少なくとも普遍的な認識に値する才能のある作曲家によって書かれていることもあります。



もう1つ列挙を作成しましょう。

 enum class Music { SCENARIO_MUSIC_1, SCENARIO_MUSIC_2, SCENARIO_MUSIC_3, }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同様に、インターフェースとそのデフォルトの実装を定義します。

 interface MusicPlayer { fun play(music: Music) fun stop() } class MuteMusicPlayer : MusicPlayer { override fun play(music: Music) { //Do nothing } override fun stop() { //Do nothing } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、再生を開始する方法と停止する方法の2つが必要です。また、追加の方法（一時停止/再開、巻き戻しなど）が将来便利になる可能性も十分にありますが、これまでのところ、この2つで十分です。



毎回オブジェクト間でプレーヤークラスへの参照を渡すことは、非常に便利な解決策ではないようです。私は別のオブジェクトにサウンドや音楽メソッドを演奏し、それにするために必要なすべての作ることを提案するベンチャー企業ですので、1時間で、我々は、一つだけekzepmlyarプレーヤーが必要一匹狼（シングルトン）。したがって、同じインスタンスへのリンクを絶えず送信せずに、アプリケーション内のどこからでも責任あるオーディオサブシステムを常に利用できます。次のようになります。





クラスAudio



は私たちのシングルトンです。サブシステムに単一のファサードを提供します...ところで、ここにファサード（ファサード）があります。これは、これらのインターネット上で徹底的に設計され、繰り返し（例とともに）記述された別のデザインパターンです。したがって、すでに後列から不満の叫び声を聞いたので、私は長い間知られていることの説明をやめて、先に進みます。コードは次のとおりです。

 object Audio { private var soundPlayer: SoundPlayer = MuteSoundPlayer() private var musicPlayer: MusicPlayer = MuteMusicPlayer() fun init(soundPlayer: SoundPlayer, musicPlayer: MusicPlayer) { this.soundPlayer = soundPlayer this.musicPlayer = musicPlayer } fun playSound(sound: Sound) = this.soundPlayer.play(sound) fun playMusic(music: Music) = this.musicPlayer.play(music) fun stopMusic() = this.musicPlayer.stop() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

init()



必要なオブジェクトで初期化することにより、最初のどこかで一度だけ呼び出すだけで十分であり、将来的には実装の詳細を完全に忘れて便利なメソッドを使用します。あなたがそうしなくても、心配しないでください、システムは死ぬでしょう-オブジェクトはデフォルトのクラスによって初期化されます。



以上です。実際の再生を処理するために残ります。サウンド（または、賢い人が言うように、サンプル）の再生に関しては、Javaには便利なクラスAudioSystem



とインターフェースがありますClip



。必要なのは、オーディオファイルへのパスを正しく設定することです（クラスパスにあります、覚えていますか？）。

 import javax.sound.sampled.AudioSystem class BasicSoundPlayer : SoundPlayer { private fun pathToFile(sound: Sound) = "/sound/${sound.toString().toLowerCase()}.wav" override fun play(sound: Sound) { val url = javaClass.getResource(pathToFile(sound)) val audioIn = AudioSystem.getAudioInputStream(url) val clip = AudioSystem.getClip() clip.open(audioIn) clip.start() } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メソッドopen()



はそれを捨てることができますIOException



（特に、ファイル形式が気に入らなかった場合-この場合、オーディオエディターでファイルを開いて再保存することをお勧めします）。そのため、ブロックにラップすることをお勧めしますtry-catch



が、最初は、音に問題があるたびにクラッシュしました。



「何て言えばいいのかさえわからない...」



音楽では事態はさらに悪化します。私の知る限り、Javaで音楽ファイル（mp3形式など）を再生する標準的な方法はないため、いずれにしてもサードパーティのライブラリを使用する必要があります（さまざまなライブラリがあります）。かなり人気のあるJLayerなど、最小限の機能を備えた軽量のものが適しています。依存して追加します：

 <dependencies> <dependency> <groupId>com.googlecode.soundlibs</groupId> <artifactId>jlayer</artifactId> <version>1.0.1.4</version> <scope>compile</scope> </dependency> </dependencies>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、プレーヤーの助けを借りて実装します。

 class BasicMusicPlayer : MusicPlayer { private var currentMusic: Music? = null private var thread: PlayerThread? = null private fun pathToFile(music: Music) = "/music/${music.toString().toLowerCase()}.mp3" override fun play(music: Music) { if (currentMusic == music) { return } currentMusic = music thread?.finish() Thread.yield() thread = PlayerThread(pathToFile(music)) thread?.start() } override fun stop() { currentMusic = null thread?.finish() } // Thread responsible for playback private inner class PlayerThread(private val musicPath: String) : Thread() { private lateinit var player: Player private var isLoaded = false private var isFinished = false init { isDaemon = true } override fun run() { loop@ while (!isFinished) { try { player = Player(javaClass.getResource(musicPath).openConnection().apply { useCaches = false }.getInputStream()) isLoaded = true player.play() } catch (ex: Exception) { finish() break@loop } player.close() } } fun finish() { isFinished = true this.interrupt() if (isLoaded) { player.close() } } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まず、このライブラリは同期的に再生を実行し、ファイルの終わりに達するまでメインストリームをブロックします。したがって、個別のスレッド（PlayerThread



）を実装し、それを「オプション」（デーモン）にしなければなりません。そうすることで、アプリケーションが早期に終了することはありません。次に、現在再生中の音楽ファイルの識別子（currentMusic



）がプレーヤーコードに保存されます。 2番目のコマンドが突然再生される場合、最初から再生を開始しません。第三に、音楽ファイルの最後に到達すると、その再生が再び開始されます-ストリームがコマンドによって明示的に停止されるまで続きますfinish()



（または既に述べたように、他のスレッドが完了するまで）。第4に、上記のコードは一見不必要なフラグとコマンドでいっぱいですが、徹底的にデバッグおよびテストされています-プレイヤーは期待どおりに動作し、システムを遅くせず、途中で突然中断せず、メモリリークを引き起こさず、遺伝子組み換えオブジェクトを含まず、輝きます鮮度と純度。それを取り、プロジェクトで大胆に使用してください。

ステップ12。ローカリゼーション

私たちのゲームはほとんど準備ができていますが、誰もそれをプレイしません。 なんで？



「ロシア語はありません！..ロシア語はありません！..ロシア語を追加してください！..犬を開発し



てください！」店舗のウェブサイトで面白いストーリーゲーム（特にモバイル）のページを開き、レビューを読んでください。彼らは素晴らしい、手描きのグラフィックを賞賛し始めますか？または大気のサウンドトラックに驚嘆しますか？または、最初の1分間から中毒性があり、最後まで手放さないエキサイティングなストーリーを話しますか？



いや不満な「プレイヤー」は多くのユニットを指示し、通常はゲームを削除します。そして、彼らはまた返金を必要とします-そして、これらすべては一つの簡単な理由のために。はい、あなたは傑作を95のすべての言語に翻訳するのを忘れていました。むしろ、キャリアが最も大声で叫ぶ人。それだけです！分かりますか？数ヶ月のハードワーク、長い眠れぬ夜、絶え間ない神経衰弱-これはすべて、尻尾の下のハムスターです。膨大な数のプレイヤーを失いましたが、これは修正できません。



だから先に考えてください。対象読者を決定し、いくつかの主要言語を選択し、翻訳サービスを注文します...一般的に、他の人がテーマ記事で複数回説明したことをすべて行います（私よりも賢い）。問題の技術的な側面に焦点を当て、製品を安全にローカライズする方法について説明します。



まず、テンプレートに入ります。名前と説明が単純なものとして保存される前に覚えていString



ますか？今では機能しません。デフォルトの言語に加えて、サポートする予定のすべての言語への翻訳も提供する必要があります。たとえば、次のように：

 class TestEnemyTemplate : EnemyTemplate { override val name = "Test enemy" override val description = "Some enemy standing in your way." override val nameLocalizations = mapOf( "ru" to " -", "ar" to "بعض العدو", "iw" to "איזה אויב", "zh" to "一些敵人", "ua" to "і " ) override val descriptionLocalizations = mapOf( "ru" to " - .", "ar" to "وصف العدو", "iw" to "תיאור האויב", "zh" to "一些敵人的描述", "ua" to " ї і   ." ) override val traits = listOf<Trait>() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テンプレートの場合、このアプローチは非常に適しています。どの言語の翻訳も指定したくない場合は、その必要はありません-常にデフォルト値があります。ただし、最終的なオブジェクトでは、複数の異なるフィールドに行を広げたくないでしょう。したがって、1つを残しますが、そのタイプは置き換えます。

 class LocalizedString(defaultValue: String, localizations: Map<String, String>) { private val default: String = defaultValue private val values: Map<String, String> = localizations.toMap() operator fun get(lang: String) = values.getOrDefault(lang, default) override fun equals(other: Any?) = when { this === other -> true other !is LocalizedString -> false else -> default == other.default } override fun hashCode(): Int { return default.hashCode() } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それに応じてジェネレーターコードを修正します。

 fun generateEnemy(template: EnemyTemplate) = Enemy().apply { name = LocalizedString(template.name, template.nameLocalizations) description = LocalizedString(template.description, template.descriptionLocalizations) template.traits.forEach { addTrait(it) } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

当然、同じアプローチを残りのタイプのテンプレートに適用する必要があります。変更の準備ができたら、問題なく使用できます。

 val language = Locale.getDefault().language val enemyName = enemy.name[language]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例では、言語のみが考慮されるローカライズの簡易バージョンを提供しています。一般に、クラスオブジェクトLocale



は国と地域も定義します。これがアプリケーションで重要な場合は、LocalizedString



外観が少し異なりますが、とにかく満足しています。



テンプレートを処理しましたが、アプリケーションで使用されるサービスラインをローカライズする必要があります。幸いなことに、これにResourceBundle



は必要なメカニズムがすべて含まれています。翻訳済みのファイルを準備し、ダウンロード方法を変更するだけです。

 # Game status messages choose_dice_perform_check=    : end_of_turn_discard_extra= :   : end_of_turn_discard_optional= :    : choose_action_before_exploration=,  : choose_action_after_exploration= .   ? encounter_physical=  .   . encounter_somatic=  .   . encounter_mental=  .   . encounter_verbal=  .   . encounter_divine=  .    : die_acquire_success=   ! die_acquire_failure=    . game_loss_out_of_time=    # Die types physical= somatic= mental= verbal= divine= ally= wound= enemy= villain= obstacle= # Hero types and descriptions brawler= hunter= # Various labels avg= bag= bag_size=  class= closed= discard= empty= encountered=  fail= hand= heros_turn= %s max= min= perform_check= : pile= received_new_die=   result= success= sum= time= total= # Action names and descriptions action_confirm_key=ENTER action_confirm_name= action_cancel_key=ESC action_cancel_name= action_explore_location_key=E action_explore_location_name= action_finish_turn_key=F action_finish_turn_name=  action_hide_key=H action_bag_name= action_discard_key=D action_discard_name= action_acquire_key=A action_acquire_name= action_leave_key=L action_leave_name= action_forfeit_key=F action_forfeit_name=
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

記録のために私は言いません：ロシア語でフレーズを書くことは英語よりはるかに複雑です。決定的なケースで名詞を使用するか、性別から離脱する必要がある場合（およびそのような要件は必ず成立します）、まず要件を満たし、次にサイボーグによって行われた機械翻訳のように見えない結果を得るために汗をかかなければなりません鶏の脳を持つ。また、アクションキーを変更しないことに注意してください-以前と同じように、後者は英語と同じ文字を使用して実行されます（ちなみに、ラテン語以外のキーボードレイアウトでは機能しませんが、これは私たちのビジネスではありません-今のところはそのままにしておきます）。

 class PropertiesStringLoader(locale: Locale) : StringLoader { private val properties = ResourceBundle.getBundle("text.strings", locale) override fun loadString(key: String) = properties.getString(key) ?: "" }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

。

すでに述べたように、ResourceBundle



彼自身がローカライズファイルの中から現在のロケールに最も近いものを見つける責任を負います。そして、見つからない場合は、デフォルトのファイル（string.properties



）を取得します。そして、すべてがうまくいきます...





さまざまな言語でアプリケーションの動作をテストするために、オペレーティングシステムの設定を変更する必要はありません。JREの起動時に必要な言語を指定するだけです。

 java -Duser.language=ru -jar path_to_project\Dice\target\dice-1.0-jar-with-dependencies.jar
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてのエキサイティングな冒険の後、結果は誇らしげに一般大衆に示され、大声で宣言されます：「私たちは犬ではありません！」





そしてそれは良いことです。

ステップ13 すべてをまとめる

気配りのある読者は、特定のパッケージの名前に一度だけ言及し、決して戻ってこなかったことに気付いたに違いありません。まず、各開発者は、どのクラスをどのパッケージに配置するかに関して、独自の考慮事項を持っています。第二に、プロジェクトに取り組むにつれて、より多くの新しいクラスが追加されると、考えが変わります。第三に、アプリケーションの構造の変更は簡単で安価です（そして、最新のバージョン管理システムが移行を検出するため、履歴を失うことはありません）。クラス、パッケージ、メソッド、変数の名前を大胆に変更します-ドキュメントを更新することを忘れないでください、そうですか？）。



そして私たちに残っているのは、プロジェクトをまとめて立ち上げることだけです。覚えているように、メソッドmain()



をすでに作成しました。今度はその内容を埋めます。必要なもの：

• スクリプトと地形;
• ヒーローズ
• インターフェイスの実装GameInteractor
  
  
  
  。
• インターフェイスの実装GameRenderer
  
  
  
  およびStringLoader
  
  
  
  ;
• インターフェイスの実装SoundPlayer
  
  
  
  およびMusicPlayer
  
  
  
  ;
• クラスオブジェクトGame
  
  
  
  。
• シャンパンのボトル。

行こう！

 fun main(args: Array<String>) { Audio.init(BasicSoundPlayer(), BasicMusicPlayer()) val loader = PropertiesStringLoader(Locale.getDefault()) val renderer = ConsoleGameRenderer(loader) val interactor = ConsoleGameInteractor() val template = TestScenarioTemplate() val scenario = generateScenario(template, 1) val locations = generateLocations(template, 1, heroes.size) val heroes = listOf( generateHero(Hero.Type.BRAWLER, "Brawler"), generateHero(Hero.Type.HUNTER, "Hunter") ) val game = Game(renderer, interactor, scenario, locations, heroes) game.start() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私たちは最初の実用プロトタイプを立ち上げて楽しみます。行くぞ

ステップ14。ゲームバランス

うーん...

ステップ15。テスト

今すぐことを書かれた最初の作業プロトタイプのコードの主要な部分は、ユニットテストのカップルを追加していいだろう...



「どのように？たった今？はい、テストは最初に記述し、次にコードを記述しなければなりませんでした！」



多くの読者は、単体テストの記述が作業コード（TDDその他のファッショナブルな方法論）。他の人は激怒します：少なくとも何かを開発し始めたとしても、人々がテストで頭をだますことは何もありません。別のカップルがベースボードの隙間からofい出して、「これらのテストが必要な理由がわからない-すべてが私にとってうまくいく」と”病に言うでしょう...そして彼らはブーツで顔に押し込まれ、すぐに押し戻されます。私はイデオロギー的対立を開始し始めません（彼らはすでにインターネット上でそれらに満ちています）。したがって、私はすべての人に部分的に同意します。はい、テストは時々役に立ちます（特に、頻繁に変更される、または複雑な計算に関連するコードで）、はい、ユニットテストはすべてのコードに適していません（たとえば、ユーザーまたは外部システムとの相互作用をカバーしません）、はい、ユニットテスト以外にもあります他の種の多く（まあ、少なくとも5つが命名された）、そして、はい、私たちはテストを書くことに集中しません-私たちの記事は何か他のものについてです。



多くのプログラマー（特に初心者）はテストを怠ります。多くの人は、アプリケーションの機能がテストで十分にカバーされていないと言うことで正当化しています。たとえば、ユーザーインターフェースをテストするための特殊なフレームワークを使用して複雑な構造をフェンスするよりも、アプリケーションを起動して、すべてが外観と相互作用に問題がないかどうかを確認する方がはるかに簡単です。そして、インターフェイスを実装していたときにお知らせしますRenderer



-それだけでした。ただし、コードの中には、単体テストの概念が優れているメソッドがあります。



たとえば、ジェネレーター。そしてそれだけです。これは理想的なブラックボックスです。テンプレートは入力に送信され、ゲームワールドのオブジェクトは出力で取得されます。内部では何が起こりますが、テストする必要があるのはまさに彼です。たとえば、次のように：

 public class DieGeneratorTest { @Test public void testGetMaxLevel() { assertEquals("Max level should be 3", 3, DieGeneratorKt.getMaxLevel()); } @Test public void testDieGenerationSize() { DieTypeFilter filter = new SingleDieTypeFilter(Die.Type.ALLY); List<? extends List<Integer>> allowedSizes = Arrays.asList( null, Arrays.asList(4, 6, 8), Arrays.asList(4, 6, 8, 10), Arrays.asList(6, 8, 10, 12) ); IntStream.rangeClosed(1, 3).forEach(level -> { for (int i = 0; i < 10; i++) { int size = DieGeneratorKt.generateDie(filter, level).getSize(); assertTrue("Incorrect level of die generated: " + size, allowedSizes.get(level).contains(size)); assertTrue("Incorrect die size: " + size, size >= 4); assertTrue("Incorrect die size: " + size, size <= 12); assertTrue("Incorrect die size: " + size, size % 2 == 0); } }); } @Test public void testDieGenerationType() { List<Die.Type> allowedTypes1 = Arrays.asList(Die.Type.PHYSICAL); List<Die.Type> allowedTypes2 = Arrays.asList(Die.Type.PHYSICAL, Die.Type.SOMATIC, Die.Type.MENTAL, Die.Type.VERBAL); List<Die.Type> allowedTypes3 = Arrays.asList(Die.Type.ALLY, Die.Type.VILLAIN, Die.Type.ENEMY); for (int i = 0; i < 10; i++) { Die.Type type1 = DieGeneratorKt.generateDie(new SingleDieTypeFilter(Die.Type.PHYSICAL), 1).getType(); assertTrue("Incorrect die type: " + type1, allowedTypes1.contains(type1)); Die.Type type2 = DieGeneratorKt.generateDie(new StatsDieTypeFilter(), 1).getType(); assertTrue("Incorrect die type: " + type2, allowedTypes2.contains(type2)); Die.Type type3 = DieGeneratorKt.generateDie(new MultipleDieTypeFilter(Die.Type.ALLY, Die.Type.VILLAIN, Die.Type.ENEMY), 1).getType(); assertTrue("Incorrect die type: " + type3, allowedTypes3.contains(type3)); } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または：

 public class BagGeneratorTest { @Test public void testGenerateBag() { BagTemplate template1 = new BagTemplate(); template1.addPlan(0, 10, new SingleDieTypeFilter(Die.Type.PHYSICAL)); template1.addPlan(5, 5, new SingleDieTypeFilter(Die.Type.SOMATIC)); template1.setFixedDieCount(null); BagTemplate template2 = new BagTemplate(); template2.addPlan(10, 10, new SingleDieTypeFilter(Die.Type.DIVINE)); template2.setFixedDieCount(5); BagTemplate template3 = new BagTemplate(); template3.addPlan(10, 10, new SingleDieTypeFilter(Die.Type.ALLY)); template3.setFixedDieCount(50); for (int i = 0; i < 10; i++) { Bag bag1 = BagGeneratorKt.generateBag(template1, 1); assertTrue("Incorrect bag size: " + bag1.getSize(), bag1.getSize() >= 5 && bag1.getSize() <= 15); assertEquals("Incorrect number of SOMATIC dice", 5, bag1.examine().stream().filter(d -> d.getType() == Die.Type.SOMATIC).count()); Bag bag2 = BagGeneratorKt.generateBag(template2, 1); assertEquals("Incorrect bag size", 5, bag2.getSize()); Bag bag3 = BagGeneratorKt.generateBag(template3, 1); assertEquals("Incorrect bag size", 50, bag3.getSize()); List<Die.Type> dieTypes3 = bag3.examine().stream().map(Die::getType).distinct().collect(Collectors.toList()); assertEquals("Incorrect die types", 1, dieTypes3.size()); assertEquals("Incorrect die types", Die.Type.ALLY, dieTypes3.get(0)); } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

またはこのように：

 public class LocationGeneratorTest { private void testLocationGeneration(String name, LocationTemplate template) { System.out.println("Template: " + template.getName()); assertEquals("Incorrect template type", name, template.getName()); IntStream.rangeClosed(1, 3).forEach(level -> { Location location = LocationGeneratorKt.generateLocation(template, level); assertEquals("Incorrect location type", name, location.getName().get("")); assertTrue("Location not open by default", location.isOpen()); int closingDifficulty = location.getClosingDifficulty(); assertTrue("Closing difficulty too small", closingDifficulty > 0); assertEquals("Incorrect closing difficulty", closingDifficulty, template.getBasicClosingDifficulty() + level * 2); Bag bag = location.getBag(); assertNotNull("Bag is null", bag); assertTrue("Bag is empty", location.getBag().getSize() > 0); Deck<Enemy> enemies = location.getEnemies(); assertNotNull("Enemies are null", enemies); assertEquals("Incorrect enemy threat count", enemies.getSize(), template.getEnemyCardsCount()); if (bag.drawOfType(Die.Type.ENEMY) != null) { assertTrue("Enemy cards not specified", enemies.getSize() > 0); } Deck<Obstacle> obstacles = location.getObstacles(); assertNotNull("Obstacles are null", obstacles); assertEquals("Incorrect obstacle threat count", obstacles.getSize(), template.getObstacleCardsCount()); List<SpecialRule> specialRules = location.getSpecialRules(); assertNotNull("SpecialRules are null", specialRules); }); } @Test public void testGenerateLocation() { testLocationGeneration("Test Location", new TestLocationTemplate()); testLocationGeneration("Test Location 2", new TestLocationTemplate2()); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「ストップ、ストップ、ストップ！」これは何？ Java ???」



あなたは理解しています。さらに、ジェネレーター自体の実装を開始する前に、最初にこのようなテストを記述することをお勧めします。もちろん、テスト対象のコードは非常に単純であり、メソッドはテストなしで初めて動作する可能性が高いですが、テストを作成すると、それを永久に忘れ、将来起こりうる問題から保護します（その解決には多くの時間がかかります。特に開発の開始時から） 5年が経過し、メソッド内のすべてがそこでどのように機能するかをすでに忘れていました）。また、テストが失敗したために突然プロジェクトの収集が停止した場合、システム要件が変更され、古いテストでそれらが満たされなくなった理由がわかります（どう思いましたか？）。



その他。クラスHandMaskRule



とその相続人を覚えていますか？ある時点で、スキルを使用するためにヒーローが3つのサイコロを手から取る必要があり、これらのサイコロの種類には厳しい制限があることを想像してください（たとえば、「最初のサイコロは青、緑、白、2番目は黄色、白、青、そして3番目-青または紫 "-あなたは困難を感じますか？）。クラスの実装にアプローチする方法は？まあ...まず、入力パラメータと出力パラメータを決めることができます。明らかに、3つの配列（またはセット）を受け入れるクラスが必要です。各配列には、それぞれ、1番目、2番目、3番目のキューブの有効な型が含まれています。それから何？つぶしますか？再帰？何かを見逃したらどうなりますか？深い入り口を作ります。クラスメソッドの実装を延期し、テストを作成します。要件はシンプルで理解しやすく、正式に定式化されているためです。そして、いくつかのテストを作成する方が良いでしょう...しかし、ここではそのようなものを検討します：

 public class TripleDieHandMaskRuleTest { private Hand hand; @Before public void init() { hand = new Hand(10); hand.addDie(new Die(Die.Type.PHYSICAL, 4)); //0 hand.addDie(new Die(Die.Type.PHYSICAL, 4)); //1 hand.addDie(new Die(Die.Type.SOMATIC, 4)); //2 hand.addDie(new Die(Die.Type.SOMATIC, 4)); //3 hand.addDie(new Die(Die.Type.MENTAL, 4)); //4 hand.addDie(new Die(Die.Type.MENTAL, 4)); //5 hand.addDie(new Die(Die.Type.VERBAL, 4)); //6 hand.addDie(new Die(Die.Type.VERBAL, 4)); //7 hand.addDie(new Die(Die.Type.DIVINE, 4)); //8 hand.addDie(new Die(Die.Type.DIVINE, 4)); //9 hand.addDie(new Die(Die.Type.ALLY, 4)); //A (0) hand.addDie(new Die(Die.Type.ALLY, 4)); //B (1) } @Test public void testRule1() { HandMaskRule rule = new TripleDieHandMaskRule( hand, new Die.Type[]{Die.Type.PHYSICAL, Die.Type.SOMATIC}, new Die.Type[]{Die.Type.MENTAL, Die.Type.VERBAL}, new Die.Type[]{Die.Type.PHYSICAL, Die.Type.ALLY} ); HandMask mask = new HandMask(); assertTrue("Ally should be on", rule.isAllyPositionActive(mask, 0)); assertTrue("Ally should be on", rule.isAllyPositionActive(mask, 1)); assertTrue("Should be on", rule.isPositionActive(mask, 0)); assertTrue("Should be on", rule.isPositionActive(mask, 1)); assertTrue("Should be on", rule.isPositionActive(mask, 2)); assertTrue("Should be on", rule.isPositionActive(mask, 3)); assertTrue("Should be on", rule.isPositionActive(mask, 4)); assertTrue("Should be on", rule.isPositionActive(mask, 5)); assertTrue("Should be on", rule.isPositionActive(mask, 6)); assertTrue("Should be on", rule.isPositionActive(mask, 7)); assertFalse("Should be off", rule.isPositionActive(mask, 8)); assertFalse("Should be off", rule.isPositionActive(mask, 9)); assertFalse("Rule should not be met yet", rule.checkMask(mask)); mask.addPosition(0); assertTrue("Ally should be on", rule.isAllyPositionActive(mask, 0)); assertTrue("Ally should be on", rule.isAllyPositionActive(mask, 1)); assertTrue("Should be on", rule.isPositionActive(mask, 0)); assertTrue("Should be on", rule.isPositionActive(mask, 1)); assertTrue("Should be on", rule.isPositionActive(mask, 2)); assertTrue("Should be on", rule.isPositionActive(mask, 3)); assertTrue("Should be on", rule.isPositionActive(mask, 4)); assertTrue("Should be on", rule.isPositionActive(mask, 5)); assertTrue("Should be on", rule.isPositionActive(mask, 6)); assertTrue("Should be on", rule.isPositionActive(mask, 7)); assertFalse("Should be off", rule.isPositionActive(mask, 8)); assertFalse("Should be off", rule.isPositionActive(mask, 9)); assertFalse("Rule should not be met yet", rule.checkMask(mask)); mask.addPosition(4); assertTrue("Ally should be on", rule.isAllyPositionActive(mask, 0)); assertTrue("Ally should be on", rule.isAllyPositionActive(mask, 1)); assertTrue("Should be on", rule.isPositionActive(mask, 0)); assertTrue("Should be on", rule.isPositionActive(mask, 1)); assertTrue("Should be on", rule.isPositionActive(mask, 2)); assertTrue("Should be on", rule.isPositionActive(mask, 3)); assertTrue("Should be on", rule.isPositionActive(mask, 4)); assertFalse("Should be off", rule.isPositionActive(mask, 5)); assertFalse("Should be off", rule.isPositionActive(mask, 6)); assertFalse("Should be off", rule.isPositionActive(mask, 7)); assertFalse("Should be off", rule.isPositionActive(mask, 8)); assertFalse("Should be off", rule.isPositionActive(mask, 9)); assertFalse("Rule should not be met yet", rule.checkMask(mask)); mask.addAllyPosition(0); assertTrue("Ally should be on", rule.isAllyPositionActive(mask, 0)); assertFalse("Ally should be off", rule.isAllyPositionActive(mask, 1)); assertTrue("Should be on", rule.isPositionActive(mask, 0)); assertFalse("Should be off", rule.isPositionActive(mask, 1)); assertFalse("Should be off", rule.isPositionActive(mask, 2)); assertFalse("Should be off", rule.isPositionActive(mask, 3)); assertTrue("Should be on", rule.isPositionActive(mask, 4)); assertFalse("Should be off", rule.isPositionActive(mask, 5)); assertFalse("Should be off", rule.isPositionActive(mask, 6)); assertFalse("Should be off", rule.isPositionActive(mask, 7)); assertFalse("Should be off", rule.isPositionActive(mask, 8)); assertFalse("Should be off", rule.isPositionActive(mask, 9)); assertTrue("Rule should be met", rule.checkMask(mask)); mask.removePosition(0); assertTrue("Ally should be on", rule.isAllyPositionActive(mask, 0)); assertFalse("Ally should be off", rule.isAllyPositionActive(mask, 1)); assertTrue("Should be on", rule.isPositionActive(mask, 0)); assertTrue("Should be on", rule.isPositionActive(mask, 1)); assertTrue("Should be on", rule.isPositionActive(mask, 2)); assertTrue("Should be on", rule.isPositionActive(mask, 3)); assertTrue("Should be on", rule.isPositionActive(mask, 4)); assertFalse("Should be off", rule.isPositionActive(mask, 5)); assertFalse("Should be off", rule.isPositionActive(mask, 6)); assertFalse("Should be off", rule.isPositionActive(mask, 7)); assertFalse("Should be off", rule.isPositionActive(mask, 8)); assertFalse("Should be off", rule.isPositionActive(mask, 9)); assertFalse("Rule should not be met again", rule.checkMask(mask)); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは骨が折れますが、開始するまでは見かけほどではありません（ある時点で、さらに楽しくなります）。しかし、そのようなテスト（および別の機会のためのいくつかのテスト）を書くと、あなたは突然落ち着きと自信を感じます。これで、小さなタイプミスでメソッドが台無しになり、不愉快な驚きにつながり、手作業でテストするのがはるかに難しくなります。少しずつ、クラスの必要なメソッドを実装し始めます。そして最後にテストを実行して、どこかで間違いを犯したことを確認します。問題箇所を見つけて書き直してください。準備が整うまで繰り返します。

 class TripleDieHandMaskRule( hand: Hand, types1: Array<Die.Type>, types2: Array<Die.Type>, types3: Array<Die.Type>) : HandMaskRule(hand) { private val types1 = types1.toSet() private val types2 = types2.toSet() private val types3 = types3.toSet() override fun checkMask(mask: HandMask): Boolean { if (mask.positionCount + mask.allyPositionCount != 3) { return false } return getCheckedDice(mask).asSequence() .filter { it.type in types1 } .any { d1 -> getCheckedDice(mask) .filter { d2 -> d2 !== d1 } .filter { it.type in types2 } .any { d2 -> getCheckedDice(mask) .filter { d3 -> d3 !== d1 } .filter { d3 -> d3 !== d2 } .any { it.type in types3 } } } } override fun isPositionActive(mask: HandMask, position: Int): Boolean { if (mask.checkPosition(position)) { return true } val die = hand.dieAt(position) ?: return false return when (mask.positionCount + mask.allyPositionCount) { 0 -> die.type in types1 || die.type in types2 || die.type in types3 1 -> with(getCheckedDice(mask).first()) { (this.type in types1 && (die.type in types2 || die.type in types3)) || (this.type in types2 && (die.type in types1 || die.type in types3)) || (this.type in types3 && (die.type in types1 || die.type in types2)) } 2-> with(getCheckedDice(mask)) { val d1 = this[0] val d2 = this[1] (d1.type in types1 && d2.type in types2 && die.type in types3) || (d2.type in types1 && d1.type in types2 && die.type in types3) || (d1.type in types1 && d2.type in types3 && die.type in types2) || (d2.type in types1 && d1.type in types3 && die.type in types2) || (d1.type in types2 && d2.type in types3 && die.type in types1) || (d2.type in types2 && d1.type in types3 && die.type in types1) } 3 -> false else -> false } } override fun isAllyPositionActive(mask: HandMask, position: Int): Boolean { if (mask.checkAllyPosition(position)) { return true } if (hand.allyDieAt(position) == null) { return false } return when (mask.positionCount + mask.allyPositionCount) { 0 -> ALLY in types1 || ALLY in types2 || ALLY in types3 1 -> with(getCheckedDice(mask).first()) { (this.type in types1 && (ALLY in types2 || ALLY in types3)) || (this.type in types2 && (ALLY in types1 || ALLY in types3)) || (this.type in types3 && (ALLY in types1 || ALLY in types2)) } 2-> with(getCheckedDice(mask)) { val d1 = this[0] val d2 = this[1] (d1.type in types1 && d2.type in types2 && ALLY in types3) || (d2.type in types1 && d1.type in types2 && ALLY in types3) || (d1.type in types1 && d2.type in types3 && ALLY in types2) || (d2.type in types1 && d1.type in types3 && ALLY in types2) || (d1.type in types2 && d2.type in types3 && ALLY in types1) || (d2.type in types2 && d1.type in types3 && ALLY in types1) } 3 -> false else -> false } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このような機能をより簡単に実装する方法についてアイデアがある場合は、コメントを歓迎します。そして、テストを書くことでこのクラスの実装を始めるのに十分なほど頭が良かったと信じられないほど嬉しいです。



「そして、私は<...>も<...>非常に<...>うれしい<...>です。入ろう！<...>戻る！<...>ギャップに！」

ステップ16。モジュール性

予想通り、成熟した子供は一生親の保護下にいることはできません。遅かれ早かれ、自分の道を選んで大胆に道を進み、困難や混乱を克服しなければなりません。そのため、私たちが開発したコンポーネントは非常に成熟していたため、1つの屋根の下でcr屈になりました。それらをいくつかの部分に分ける時が来ました。



かなり些細な作業に直面しています。これまでに作成されたすべてのクラスを3つのグループに分ける必要があります。

• 基本機能：モジュール、ゲームエンジン、コネクタインターフェイス、プラットフォームに依存しない実装（コア）;
• シナリオ、地形、敵、障害物のテンプレート-いわゆる「アドベンチャー」（アドベンチャー）のコンポーネント。
• 特定のプラットフォームに固有のインターフェイスの特定の実装：この場合、コンソールアプリケーション（cli）。

この分離の結果は、最終的に次の図のようになります。





追加のプロジェクトを作成し、対応するクラスを転送します。そして、プロジェクト間の相互作用を正しく構成する必要があります。



コア

プロジェクトこのプロジェクトは純粋なエンジンです。特定のクラスはすべて他のプロジェクトに転送されました-基本的な機能であるコアのみが残りました。必要に応じてライブラリ。起動クラスはもうありません。パッケージをビルドする必要もありません。このプロジェクトのアセンブリは、ローカルのMavenリポジトリでホストされ（詳細は後述）、他のプロジェクトで依存関係として使用されます。



ファイルpom.xml



は次のとおりです。

 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>my.company</groupId> <artifactId>dice-core</artifactId> <version>1.0</version> <packaging>jar</packaging> <dependencies> <dependency> <groupId>org.jetbrains.kotlin</groupId> <artifactId>kotlin-stdlib</artifactId> <version>${kotlin.version}</version> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit-dep</artifactId> <version>4.8.2</version> <scope>test</scope> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.jetbrains.kotlin</groupId> <!-- other Kotlin setup --> </plugin> </plugins> </build> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> <kotlin.version>1.3.20</kotlin.version> <kotlin.compiler.incremental>true</kotlin.compiler.incremental> </properties> </project>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これから、次のように収集します。

 mvn -f "path_to_project/DiceCore/pom.xml" install
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Cliプロジェクト

これは、アプリケーションへのエントリポイントです-エンドユーザーが対話するのはこのプロジェクトです。カーネルは依存関係として使用されます。この例ではコンソールで作業しているため、プロジェクトにはそれで作業するために必要なクラスが含まれます（突然コーヒーメーカーでゲームを開始したい場合は、単にこのプロジェクトを対応する実装の同様のプロジェクトに置き換えます）。すぐにリソース（ライン、オーディオファイルなど）を追加します。外部ライブラリへの依存関係は



ファイルにpom.xml



転送されます：

 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>my.company</groupId> <artifactId>dice-cli</artifactId> <version>1.0</version> <packaging>jar</packaging> <dependencies> <dependency> <groupId>org.jetbrains.kotlin</groupId> <artifactId>kotlin-stdlib</artifactId> <version>${kotlin.version}</version> </dependency> <dependency> <groupId>my.company</groupId> <artifactId>dice-core</artifactId> <version>1.0</version> <scope>compile</scope> </dependency> <dependency> <groupId>org.fusesource.jansi</groupId> <artifactId>jansi</artifactId> <version>1.17.1</version> <scope>compile</scope> </dependency> <dependency> <groupId>jline</groupId> <artifactId>jline</artifactId> <version>2.14.6</version> <scope>compile</scope> </dependency> <dependency> <groupId>com.googlecode.soundlibs</groupId> <artifactId>jlayer</artifactId> <version>1.0.1.4</version> <scope>compile</scope> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.jetbrains.kotlin</groupId> <!-- other Kotlin setup --> </plugin> <plugin> <artifactId>maven-assembly-plugin</artifactId> <version>2.6</version> <executions> <execution> <phase>package</phase> <goals> <goal>single</goal> </goals> </execution> </executions> <configuration> <descriptorRefs> <descriptorRef>jar-with-dependencies</descriptorRef> </descriptorRefs> <archive> <manifest> <mainClass>my.company.dice.MainKt</mainClass> </manifest> </archive> </configuration> </plugin> </plugins> </build> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> <kotlin.version>1.3.20</kotlin.version> <kotlin.compiler.incremental>true</kotlin.compiler.incremental> </properties> </project>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

既に見たこのプロジェクトをビルドして実行するスクリプト-繰り返しません。



冒険

最後に、別のプロジェクトでプロットを取り出します。つまり、あなたの会社のシナリオ部門のスタッフが想像できる、ゲーム世界のすべてのシナリオ、地形、敵、およびその他のユニークなオブジェクト（まあ、これまでのところ、私たち自身の病気の想像力だけです-私たちはまだこの地域で唯一のゲームデザイナーです）。アイデアは、スクリプトをセットにグループ化し（アドベンチャー）、そのようなセットを個別のプロジェクトとして配布することです（ボードゲームやビデオゲームの世界で行われる方法と同様）。つまり、jarアーカイブを収集し、それらを別のフォルダーに配置して、ゲームエンジンがこのフォルダーをスキャンし、そこに含まれるすべてのアドベンチャーを自動的に接続するようにします。ただし、このアプローチの技術的な実装には非常に多くの困難が伴います。



どこから始めますか？まあ、まず、特定のJavaクラスの形式でテンプレートを配布しているという事実から（ええ、私をbeatり、oldる-私はこれを予見していました）。その場合、これらのクラスは起動時にアプリケーションのクラスパスに存在する必要があります。この要件を強制することは難しくありません。適切な環境変数にjarファイルを明示的に登録します（Java 6以降、*- wildcardsも使用できます）。

 java -classpath "path_to_project/DiceCli/target/adventures/*" -jar path_to_project/DiceCli/target/dice-1.0-jar-with-dependencies.jar
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「ばか、または何？ -jarスイッチを使用すると、-classpathスイッチは無視されます！」



ただし、これは機能しません。実行可能jarアーカイブのクラスパスは、内部ファイルに明示的に記述する必要がありますMETA-INF/MANIFEST.MF



（セクションの名前は- Claspath:



）。このため、特別なプラグインも利用可能です（maven-compiler-pluginまたは、最悪の場合、maven-assembly-plugin）。ただし、マニフェスト内のワイルドカードは機能しません。依存するjarファイルの名前を明示的に指定する必要があります。つまり、それらを事前に知ることです。これは、私たちの場合は問題です。



とにかく、私はそれを望んでいませんでした。プロジェクトを再コンパイルする必要がないようにしたかった。フォルダーへadventures/



任意の数のアドベンチャーを投げることができたため、実行中にすべてのアドベンチャーがゲームエンジンに表示されました。残念ながら、一見明らかな機能は、Javaの世界の標準的な表現を超えています。したがって、それは歓迎されません。独立した冒険を広めるには、異なるアプローチを実装する必要があります。どっち？私は知りません、コメントに書いてください-確かに誰かがスマートなアイデアを持っています。



それまではわかりません。名前を知らなくても、プロジェクトを再コンパイルしなくても、クラスパスに依存関係を動的に追加できる小さな（または見た目によっては大きな）トリックがあります



。Windowsの場合：

 @ECHO OFF call "path_to_maven\mvn.bat" -f "path_to_project\DiceCore\pom.xml" install call "path_to_maven\mvn.bat" -f "path_to_project\DiceCli\pom.xml" package call "path_to_maven\mvn.bat" -f "path_to_project\TestAdventure\pom.xml" package mkdir path_to_project\DiceCli\target\adventures copy "path_to_project\TestAdventure\target\test-adventure-1.0.jar" path_to_project\DiceCli\target\adventures\ chcp 65001 cd path_to_project\DiceCli\target\ java -Dfile.encoding=UTF-8 -cp "dice-cli-1.0-jar-with-dependencies.jar;adventures\*" my.company.dice.MainKt pause
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Unixの場合：

 #!/bin/sh mvn -f "path_to_project/DiceCore/pom.xml" install mvn -f "path_to_project/DiceCli/pom.xml" package mvn -f "path_to_project/TestAdventure/pom.xml" package mkdir path_to_project/DiceCli/target/adventures cp path_to_project/TestAdventure/target/test-adventure-1.0.jar path_to_project/DiceCli/target/adventures/ cd path_to_project/DiceCli/target/ java -cp "dice-cli-1.0-jar-with-dependencies.jar:adventures/*" my.company.dice.MainKt
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、ここにトリックがあります。キーを使用する代わりに-jar



、Cliプロジェクトをクラスパスに追加し、その中に含まれるクラスをエントリポイントとして明示的に指定しますMainKt



。さらに、ここでフォルダからすべてのアーカイブを接続しますadventures/



。



この曲がった決定がどれほど大きいかをもう一度示す必要はありません-私自身、感謝します。コメントであなたのアイデアを提案してください。お願いします。 （ಥ﹏ಥ）

ステップ17。 プロット

少し歌詞。

私たちの記事はワークフローの技術的な側面に関するものですが、ゲームは単なるソフトウェアコードではありません。これらは面白いイベントと活気のあるキャラクターを備えたエキサイティングな世界であり、あなたは頭で思いっきり飛び込み、現実の世界を放棄します。そのような世界はそれぞれ独自の方法で珍しく、独自の方法で興味深いものであり、その多くは何年も経った今でも覚えています。あなたの世界も温かい気持ちで思い出されたいなら、それを珍しくて面白くしてください。



ここで私たちはスクリプトライターではなくプログラマーであることは知っていますが、ゲームのジャンルの物語の要素（経験のあるゲーマー、そうですね）についての基本的なアイデアはあります。どんな本でもそうですが、ストーリーには目（主人公が直面している問題を徐々に説明します）、発展、2、3回の興味深いターン、クライマックス（読者が興奮して凍りついて息をするのを忘れるときのプロットの最も急性の瞬間）と否認（どのイベントが徐々に論理的な結論に達するか）。控えめな表現、論理的な根拠のないこと、プロットの穴を避けてください。すべての開始行は適切な結論に達するはずです。



さて、私たちの話を他の人に読んでみましょう-側からの公平な外観は、作られた欠陥を理解し、それらを時間内に修正するのに非常によく役立ちます。





幸運なことに、私はTolkienではありません。ゲームの世界をあまり詳しく説明していませんでしたが、それを十分に興味深いものにしようとしました。同時に、彼はいくつかのあいまいさを導入することを許可しました。各あいまいさは自分のやり方で自由に解釈できます。たとえば、封建制度と現代の民主的制度、邪悪な暴君、組織的な犯罪グループ、最高の目標と当たり前の生存、居酒屋でのバス乗りと戦い-キャラクターも何らかの理由で撮影します：弓/クロスボウ、またはアサルトライフルから。世界には魔法のようなものがあり（その存在が戦術的な能力にゲームプレイを追加します）、神秘主義の要素（あるべき姿）があります。



私は陰謀の決まり文句や幻想的な消費財から離れたいと思っていました-これらすべてのエルフ、ノーム、ドラゴン、黒、そして絶対的な世界の悪（と同様に：選択されたヒーロー、古代の予言、スーパーアーティファクト、壮大な戦い...）また、私は実際に世界を生き生きとさせたいと思ったので、各キャラクターが（マイナーなものでも）出会って、ゲームの仕組みの要素が世界の法則に適合し、ヒーローの成長が自然に発生し、場所の敵や障害物の存在が場所自体の特徴によって論理的に正当化されるように、自分の物語と動機付けを持ちました...など。残念なことに、この願望は残酷な冗談を演じ、開発プロセスを非常に遅くし、ゲームの慣習から離れることは常に可能ではありませんでした。それにもかかわらず、最終製品からの満足度は桁違いに大きいことが判明しました。



このすべてで私は何を言いたいですか？よく考え抜かれた興味深いプロットはそれほど必要ではないかもしれませんが、あなたのゲームはその存在に苦しむことはありません：せいぜい、プレイヤーはそれを楽しむでしょう、最悪の場合、彼らは単にそれを無視します。そして、特に熱心な人は、ストーリーがどのように終わるかを知るために、ゲームにいくつかの機能的な欠陥を許しさえします。

次は？

さらにプログラミングが終了し、ゲームデザインが開始されます。今はコードを書くのではなく、スクリプト、場所、敵を熟考します。これがすべてのかすです。あなたがまだ一人で働いているなら、私はあなたを祝福します-あなたはほとんどのゲームプロジェクトが急ぐ段階に達しました。大規模なAAAスタジオでは、特別な人々がデザイナーや脚本家として働いており、そのためにお金を受け取ります-彼らは単に行き先がありません。しかし、私たちにはたくさんの選択肢があります：散歩に行く、食事をする、平凡な方法で寝る-しかし、そこでできることは、蓄積された経験と知識を使用して、新しいプロジェクトを開始することです。



あなたがまだここにいて、すべての費用で継続したい場合は、困難に備えてください。時間の不足、怠、創造的なインスピレーションの欠如-何かが常にあなたをそらします。これらすべての障害を克服するのは簡単ではありません（このトピックについては多くの記事が書かれています）が、可能です。まず、プロジェクトのさらなる発展を慎重に計画することをお勧めします。幸いなことに、私たちは喜びのために働いています。出版社は私たちを押し付けません。誰も特定の期限を守る必要はありません。プロジェクトの「ロードマップ」を作成し、主要な段階を特定し、（勇気がある場合は）実装の条件を概算します。自分でノートブックを入手し（電子化できます）、その中にあるアイデアを絶えず書き留めてください（夜中に突然目が覚めても）。表で進捗状況をマークします（たとえば、そのような）またはその他の補助。開始ドキュメント：将来の巨大なファンコミュニティのための外部、公開（たとえばwiki）と、自分自身のための内部（リンクを共有しません）-信じてください。一般的に、ゲームに関する付随情報をできるだけ多く書きます。ゲーム自体を書くことを忘れないでください。基本的なオプションを提案しましたが、具体的なアドバイスはしません。各自が自分の作業プロセスを整理するのがより便利な方法を自分で決定します。



「それでも、ゲームのバランスについては話したくないのですか？」



完璧なゲームを初めて作成してもうまくいかないという事実にすぐに備えましょう。動作するプロトタイプは良いです-最初はプロジェクトの実行可能性を示し、あなたを納得させるか失望させ、「継続する価値はありますか？」という非常に重要な質問に答えます。しかし、彼は他の多くの質問には答えません。その主な質問は、おそらく「長期的に私のゲームをプレイするのは面白いでしょうか？」です。このテーマについては、非常に多くの理論と記事があります（繰り返します）。単純すぎるゲームはプレイヤーに挑戦しないので、面白いゲームはやや難しいはずです。一方、複雑さが法外な場合は、頑固なハードコアプレーヤーまたは誰かに何かを証明しようとしている人だけがゲームの観客から残ります。ゲームは非常に多様であり、理想的には-目標を達成するためのいくつかのオプションを提供し、各プレイヤーが好みのオプションを選択できるようにします。一つの合格戦略が残りを支配するべきではありません。そうでなければ、彼らはそれを使用するだけです...など。



言い換えれば、ゲームのバランスをとる必要があります。これは、ルールが明確に形式化されているボードゲームに特に当てはまります。どうやってやるの？ わからない。数学モデルを作成できる数学者の友人がいない場合（私はそれを見たことがあります）、それについて何も理解していない（そして私たちは理解していない）場合、唯一の方法は プレイテストの直感に頼ることです。最初に自分でゲームをプレイします。あなたが疲れたとき-あなたの妻を演じることを申し出ます。離婚後、他の親relative、友人、知人、路上でランダムな人々と遊ぶことを申し出ます。完全に一人になったら、アセンブリをインターネットにアップロードします。人々は興味を持ち、遊びたいと思うでしょう、そしてあなたは彼らに答えます：「あなたからのフィードバック！誰かがあなたと同じようにあなたの夢を愛し、あなたと一緒に働きたいかもしれません-あなたは志を同じくする人々または少なくともサポートグループを見つけるでしょう（なぜ私はこの記事を書いたと思いますか？）（Hehe）。



冗談はともかく、私たちに...すべての皆さんの成功を願っています。続きを読む（だれが考えたでしょう！）-ゲームのデザインなどについて。私たちが調べたすべての問題は、すでに何らかの形で記事や文献で取り上げられています（ただし、まだここにいる場合は、読むように促すことは明らかに不要です）。あなたの印象を共有し、フォーラムでコミュニケーションを取りましょう-一般に、あなたはすでに私をより良く知っています。怠けてはいけません、あなたは成功します。



この楽観的なメモで、あなたの休暇を取らせてください。ご清聴ありがとうございました。じゃあね！



「えっ！どっちを見ますか？これをすべて携帯電話で起動する方法は？無駄に待っていましたか、それとも何ですか？」

あとがき。Android

ゲームエンジンとAndroidプラットフォームの統合について説明するために、クラスをそのままにしGame



て、同様の、しかしはるかに単純なクラスを考えてみましょうMainMenu



。名前が示すように、アプリケーションのメインメニューを実装することを目的としており、実際、ユーザーが対話を開始する最初のクラスです。





classのように、Game



無限ループを定義します。各反復で画面が描画され、ユーザーからコマンドが要求されます。ここには複雑なロジックはなく、これらのコマンドははるかに小さくなっています。基本的に1つのことを実装しています-「終了」。





簡単ですね。 それとスピーチについて。 コードも一桁単純です。

 class MainMenu( private val renderer: MenuRenderer, private val interactor: MenuInteractor ) { private var actions = ActionList.EMPTY fun start() { Audio.playMusic(Music.MENU_MAIN) actions = ActionList() actions.add(Action.Type.NEW_ADVENTURE) actions.add(Action.Type.CONTINUE_ADVENTURE, false) actions.add(Action.Type.MANUAL, false) actions.add(Action.Type.EXIT) processCycle() } private fun processCycle() { while (true) { renderer.drawMainMenu(actions) when (interactor.pickAction(actions).type) { Action.Type.NEW_ADVENTURE -> TODO() Action.Type.CONTINUE_ADVENTURE -> TODO() Action.Type.MANUAL -> TODO() Action.Type.EXIT -> { Audio.stopMusic() Audio.playSound(Sound.LEAVE) renderer.clearScreen() Thread.sleep(500) return } else -> throw AssertionError("Should not happen") } } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ユーザーとの対話は、以前に見られたものと同様に機能するインターフェースMenuRenderer



とを使用して実装されますMenuInteractor



。

 interface MenuRenderer: Renderer { fun drawMainMenu(actions: ActionList) } interface Interactor { fun anyInput() fun pickAction(list: ActionList): Action }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

既に理解しているように、インターフェイスを特定の実装から意図的に分離しました。必要なのは、Cliプロジェクトを新しいプロジェクトに置き換え（Droidと呼びましょう）、Coreプロジェクトに依存関係を追加することです。やってみましょう。



Android Studioを実行し（通常はAndroid向けのプロジェクトが開発されます）、単純なプロジェクトを作成し、不要な標準見掛け倒しをすべて削除し、Kotlin言語のサポートのみを残します。また、Coreプロジェクトへの依存関係を追加します。これは、マシンのローカルMavenリポジトリに保存されます。

 apply plugin: 'com.android.application' apply plugin: 'kotlin-android' apply plugin: 'kotlin-android-extensions' android { compileSdkVersion 28 defaultConfig { applicationId "my.company.dice" minSdkVersion 14 targetSdkVersion 28 versionCode 1 versionName "1.0" } } dependencies { implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version" implementation "my.company:dice-core:1.0" }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、デフォルトでは、誰も依存関係を認識しません。プロジェクトのビルド時にローカルリポジトリ（mavenLocal）を使用する必要があることを明示的に示す必要があります。

 buildscript { ext.kotlin_version = '1.3.20' repositories { google() jcenter() mavenLocal() } dependencies { classpath 'com.android.tools.build:gradle:3.3.0' classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version" } } allprojects { repositories { google() jcenter() mavenLocal() } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

以前に開発されたすべてのクラスが使用のためにアクセス可能であり、実装のためのインターフェースであることがわかります。私たちは、に興味がある、ことで、大規模、我々はすでにおなじみのインターフェイスです：SoundPlayer



、MusicPlayer



、MenuInteractor



（アナログGameInteractor



）MenuRenderer



（アナログGameRenderer



）およびStringLoader



そのため私は、Androidの実装に新しい、特定を書きます。ただし、その前に、ユーザーが新しいシステムとどのように相互作用するかを一般的に把握します。



インターフェイス要素のレンダリングには、Androidの標準コンポーネント（ボタン、画像、入力フィールドなど）は使用しません。代わりに、クラスの機能に制限しCanvas



ます。これを行うには、単一のクラスの子孫を作成するだけで十分ですView



-これが「キャンバス」になります。入力の場合、キーボードはもうないため、少し複雑になります。画面の特定の部分でのユーザー入力がコマンドの入力と見なされるようにインターフェイスを設計する必要があります。これを行うには、同じ相続人を使用しますView



-このようにして、彼はユーザーとゲームエンジンの間の仲介者として機能します（システムコンソールがそのような仲介者として機能する方法に似ています）。



ビューのメインアクティビティを作成し、マニフェストに書き込みましょう。

 <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="my.company.dice"> <application android:icon="@mipmap/ic_launcher" android:label="@string/app_name" android:theme="@style/AppTheme"> <activity android:name=".ui.MainActivity" android:screenOrientation="sensorLandscape" android:configChanges="orientation|keyboardHidden|screenSize"> <intent-filter> <category android:name="android.intent.category.LAUNCHER"/> <action android:name="android.intent.action.MAIN"/> </intent-filter> </activity> </application> </manifest>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アクティビティを横向きに修正します-他のほとんどのゲームの場合のように、ポートレートをポートレートにすることはできません。さらに、デバイスの画面全体に拡張し、それに応じてメインテーマを処方します。

 <resources> <style name="AppTheme" parent="android:Theme.Black.NoTitleBar.Fullscreen"/> </resources>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、リソースに入ったので、必要なローカライズされた文字列をCliプロジェクトから転送し、目的の形式にします。

 <resources> <string name="action_new_adventure_key">N</string> <string name="action_new_adventure_name">ew adventure</string> <string name="action_continue_adventure_key">C</string> <string name="action_continue_adventure_name">ontinue adventure</string> <string name="action_manual_key">M</string> <string name="action_manual_name">anual</string> <string name="action_exit_key">X</string> <string name="action_exit_name">Exit</string> </resources>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メインメニューで使用されるサウンドと音楽のファイル（各タイプの1つ）と同様に、それらをそれぞれ/assets/sound/leave.wav



andに配置し/assets/music/menu_main.mp3



ます。



リソースを理解したら、設計を行うときでした（はい）。コンソールとは異なり、Androidプラットフォームには独自のアーキテクチャ機能があり、特定のアプローチと方法を使用する必要があります。





気をつけないでください、今私はすべてを詳細に説明します。



おそらく、最も難しいクラスDiceSurface



- クラス- View



システムの独立した部分を結合するために呼び出される非常に後継者から始めます（必要に応じて、クラスから継承することもできますSurfaceView



-またはGlSurfaceView



-別のスレッドで描画することもできますが、アニメーションベースのターンベースのゲームがあります、これは複雑なグラフィック出力を必要としないため、複雑にしません）。前述のように、その実装により、画像出力とクリック処理の2つの問題が同時に解決されます。それぞれに予想外の問題があります。それらを順番に考えてみましょう。



コンソールにペイントすると、レンダラーは出力コマンドを送信し、画面に画像を形成しました。 Androidの場合、状況は逆です。レンダリングはView自体によって開始され、メソッドonDraw()



が実行されるまでに、何を、どのように、どこに描画するかをすでに知っているはずです。しかし、drawMainMenu()



インターフェースメソッドはMainMenu



どうですか？彼は今、出力を制御していませんか？



機能的なインターフェースを使用してこの問題を解決してみましょう。クラスDiceSurface



には特別なパラメーターが含まれますinstructions



。実際には、メソッドが呼び出されるたびに実行する必要があるコードのブロックですonDraw()



。レンダラーは、パブリックメソッドを使用して、どの特定の指示に従うべきかを示します。興味のある方は、と呼ばれるパターンを使用戦略（戦略）。次のようになります。

 typealias RenderInstructions = (Canvas, Paint) -> Unit class DiceSurface(context: Context) : View(context) { private var instructions: RenderInstructions = { _, _ -> } private val paint = Paint().apply { color = Color.YELLOW style = Paint.Style.STROKE isAntiAlias = true } fun updateInstructions(instructions: RenderInstructions) { this.instructions = instructions this.postInvalidate() } override fun onDraw(canvas: Canvas) { super.onDraw(canvas) canvas.drawColor(Color.BLACK) //Fill background with black color instructions.invoke(canvas, paint) //Execute current render instructions } } class DroidMenuRenderer(private val surface: DiceSurface): MenuRenderer { override fun clearScreen() { surface.updateInstructions { _, _ -> } } override fun drawMainMenu(actions: ActionList) { surface.updateInstructions { c, p -> val canvasWidth = c.width val canvasHeight = c.height //Draw title text p.textSize = canvasHeight / 3f p.strokeWidth = 0f p.color = Color.parseColor("#ff808000") c.drawText( "DICE", (canvasWidth - p.measureText("DICE")) / 2f, (buttonTop - p.ascent() - p.descent()) / 2f, p ) //Other instructions... } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、すべてのグラフィカル機能はまだRendererクラスにありますが、今回はコマンドを直接実行するのではなく、Viewによる実行の準備をします。プロパティのタイプに注意してinstructions



ください-別のインターフェイスを作成してその唯一のメソッドを呼び出すことができますが、Kotlinはコードの量を大幅に削減できます。



次に、Interactorについて説明します。以前は、データ入力は同期でした。コンソール（キーボード）からデータを要求すると、ユーザーがキーを押すまでアプリケーション（サイクル）が中断されました。 Androidでは、このようなトリックは機能しません。独自のLooperがあり、その機能は中断することはありません。つまり、入力は非同期でなければなりません。つまり、Interactorインターフェースメソッドはエンジンを一時停止してコマンドを待機しますが、Activityとそのすべてのビューは遅かれ早かれこのコマンドを送信するまで機能し続けます。



このアプローチは、標準インターフェースを使用して実装するのが非常に簡単BlockingQueue



です。クラスDroidMenuInteractor



はメソッドを呼び出しますtake()



、要素（既知のクラスのインスタンスAction



）がキューに表示されるまで、ゲームストリームの実行を一時停止します。DiceSurface



、ユーザーのクリックに合わせて調整し（標準onTouchEvent()



クラスメソッドView



）、オブジェクトを生成し、メソッドによってキューに追加しますoffer()



。次のようになります。

 class DiceSurface(context: Context) : View(context) { private val actionQueue: BlockingQueue<Action> = LinkedBlockingQueue<Action>() fun awaitAction(): Action = actionQueue.take() override fun onTouchEvent(event: MotionEvent): Boolean { if (event.action == MotionEvent.ACTION_UP) { actionQueue.offer(Action(Action.Type.NONE), 200, TimeUnit.MILLISECONDS) } return true } } class DroidMenuInteractor(private val surface: DiceSurface) : Interactor { override fun anyInput() { surface.awaitAction() } override fun pickAction(list: ActionList): Action { while (true) { val type = surface.awaitAction().type list .filter(Action::isEnabled) .find { it.type == type } ?.let { return it } } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、InteractorはメソッドawaitAction()



を呼び出し、キューに何かがあれば、受信したコマンドを処理します。チームがキューに追加される方法に注意してください。 UIストリームは連続して実行されるため、ユーザーは画面を何度も連続してクリックすることができます。これは、特にゲームエンジンがコマンドを受信する準備ができていない場合（たとえば、アニメーション中）にハングアップする可能性がありますこの場合、キューの容量を増やすか、タイムアウト値を減らすか、またはその両方が役立ちます。



もちろん、コマンドを転送しますが、それは唯一のものです。押す座標を区別する必要があり、それらの値に応じて、このコマンドまたはそのコマンドを呼び出します。ただし、これは不運です-Interactorは、アクティブなボタンが画面上のどの場所に描画されるかわかりません-レンダラーがレンダリングを担当します。次のように相互作用を確立します。このクラスDiceSurface



は、特別なコレクション-アクティブな長方形（またはこのポイントに到達した場合は他の形状）のリストを格納します。このような長方形には、頂点の座標と境界の座標が含まれますAction



。レンダラーはこれらの長方形を生成してリストに追加し、メソッドonTouchEvent()



はどの長方形が押されたかを判断し、対応する長方形をキューに追加しますAction



。

 private class ActiveRect(val action: Action, left: Float, top: Float, right: Float, bottom: Float) { val rect = RectF(left, top, right, bottom) fun check(x: Float, y: Float, w: Float, h: Float) = rect.contains(x / w, y / h) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このメソッドcheck()



は、指定された座標が長方形の内側にあるかどうかを確認します。レンダラーの作業段階では（これがまさに長方形が作成される瞬間です）、キャンバスのサイズについてはわからないことに注意してください。したがって、座標を相対値（画面の幅または高さの割合）で0〜1の値で保存し、押すときに再カウントする必要があります。このアプローチは、アスペクト比を考慮に入れていないため、完全に正確ではありません。将来的には、やり直す必要があります。ただし、最初の教育的なタスクについてはそれで十分です。



クラスDiceSurface



に追加のフィールドを実装し、2つのメソッド（addRectangle()



およびclearRectangles()



）を追加して外部から（レンダラー側から）制御しonTouchEvent()



、長方形の座標を考慮して拡張します。

 class DiceSurface(context: Context) : View(context) { private val actionQueue: BlockingQueue<Action> = LinkedBlockingQueue<Action>() private val rectangles: MutableSet<ActiveRect> = Collections.newSetFromMap(ConcurrentHashMap<ActiveRect, Boolean>()) private var instructions: RenderInstructions = { _, _ -> } private val paint = Paint().apply { color = Color.YELLOW style = Paint.Style.STROKE isAntiAlias = true } fun updateInstructions(instructions: RenderInstructions) { this.instructions = instructions this.postInvalidate() } fun clearRectangles() { rectangles.clear() } fun addRectangle(action: Action, left: Float, top: Float, right: Float, bottom: Float) { rectangles.add(ActiveRect(action, left, top, right, bottom)) } fun awaitAction(): Action = actionQueue.take() override fun onTouchEvent(event: MotionEvent): Boolean { if (event.action == MotionEvent.ACTION_UP) { with(rectangles.firstOrNull { it.check(event.x, event.y, width.toFloat(), height.toFloat()) }) { if (this != null) { actionQueue.put(action) } else { actionQueue.offer(Action(Action.Type.NONE), 200, TimeUnit.MILLISECONDS) } } } return true } override fun onDraw(canvas: Canvas) { super.onDraw(canvas) canvas.drawColor(Color.BLACK) instructions(canvas, paint) } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

競合するコレクションを使用して四角形を保存します- ConcurrentModificationException



異なるスレッドによってセットが同時に更新および移動された場合に発生を回避できます（この場合は発生します）。



クラスコードDroidMenuInteractor



は変更されませんが、DroidMenuRenderer



変更されます。各項目の表示に4つのボタンを追加しますActionList



。画面の幅全体に均等に配置された見出しDICEの下に配置します。さて、アクティブな長方形を忘れないでください。

 class DroidMenuRenderer ( private val surface: DiceSurface, private val loader: StringLoader ) : MenuRenderer { protected val helper = StringLoadHelper(loader) override fun clearScreen() { surface.clearRectangles() surface.updateInstructions { _, _ -> } } override fun drawMainMenu(actions: ActionList) { //Prepare rectangles surface.clearRectangles() val percentage = 1.0f / actions.size actions.forEachIndexed { i, a -> surface.addRectangle(a, i * percentage, 0.45f, i * percentage + percentage, 1f) } //Prepare instructions surface.updateInstructions { c, p -> val canvasWidth = c.width val canvasHeight = c.height val buttonTop = canvasHeight * 0.45f val buttonWidth = canvasWidth / actions.size val padding = canvasHeight / 144f //Draw title text p.textSize = canvasHeight / 3f p.strokeWidth = 0f p.color = Color.parseColor("#ff808000") p.isFakeBoldText = true c.drawText( "DICE", (canvasWidth - p.measureText("DICE")) / 2f, (buttonTop - p.ascent() - p.descent()) / 2f, p ) p.isFakeBoldText = false //Draw action buttons p.textSize = canvasHeight / 24f actions.forEachIndexed { i, a -> p.color = if (a.isEnabled) Color.YELLOW else Color.LTGRAY p.strokeWidth = canvasHeight / 240f c.drawRect( i * buttonWidth + padding, buttonTop + padding, i * buttonWidth + buttonWidth - padding, canvasHeight - padding, p ) val name = mergeActionData(helper.loadActionData(a)) p.strokeWidth = 0f c.drawText( name, i * buttonWidth + (buttonWidth - p.measureText(name)) / 2f, (canvasHeight + buttonTop - p.ascent() - p.descent()) / 2f, p ) } } } private fun mergeActionData(data: Array<String>) = if (data.size > 1) { if (data[1].first().isLowerCase()) data[0] + data[1] else data[1] } else data.getOrNull(0) ?: "" }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここStringLoader



で、ヘルパークラスのインターフェイスと機能に戻りますStringLoadHelper



（図には示されていません）。最初の実装には名前がResourceStringLoader



あり、（明らかに）アプリケーションリソースからローカライズされた文字列をロードします。ただし、リソース識別子が事前にわからないため、これは動的に行われます。外出先でリソース識別子を作成する必要があります。

 class ResourceStringLoader(context: Context) : StringLoader { private val packageName = context.packageName private val resources = context.resources override fun loadString(key: String): String = resources.getString(resources.getIdentifier(key, "string", packageName)) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

音と音楽について話すことは残っています。Android MediaPlayer



には、これらのことを扱う素晴らしいクラスがあります。音楽を演奏するための良いものはありません：

 class DroidMusicPlayer(private val context: Context): MusicPlayer { private var currentMusic: Music? = null private val player = MediaPlayer() override fun play(music: Music) { if (currentMusic == music) { return } currentMusic = music player.setAudioStreamType(AudioManager.STREAM_MUSIC) val afd = context.assets.openFd("music/${music.toString().toLowerCase()}.mp3") player.setDataSource(afd.fileDescriptor, afd.startOffset, afd.length) player.setOnCompletionListener { it.seekTo(0) it.start() } player.prepare() player.start() } override fun stop() { currentMusic = null player.release() } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2つのポイント。まず、メソッドprepare()



は同期的に実行されます。これは、ファイルサイズが大きい場合（バッファリングのため）、システムを中断します。別のスレッドで実行するか、非同期メソッドprepareAsync()



とを使用することをお勧めしますOnPreparedListener



。第二に、再生をアクティビティライフサイクル（ユーザーがアプリケーションを最小化すると一時停止し、回復すると再開する）を関連付けると便利ですが、そうしませんでした。 Ai-ai-ai ...



サウンドMediaPlayer



にも適していますが、数が少なくシンプルな場合（この場合のように）、それで十分ですSoundPool



。その利点は、サウンドファイルが既にメモリにロードされている場合、その再生が即座に開始されることです。欠点は明らかです-十分なメモリがない可能性があります（しかし、私たちにとっては十分ですが、控えめです）。

 class DroidSoundPlayer(context: Context) : SoundPlayer { private val soundPool: SoundPool = SoundPool(2, AudioManager.STREAM_MUSIC, 100) private val sounds = mutableMapOf<Sound, Int>() private val rate = 1f private val lock = ReentrantReadWriteLock() init { Thread(SoundLoader(context)).start() } override fun play(sound: Sound) { if (lock.readLock().tryLock()) { try { sounds[sound]?.let { s -> soundPool.play(s, 1f, 1f, 1, 0, rate) } } finally { lock.readLock().unlock() } } } private inner class SoundLoader(private val context: Context) : Runnable { override fun run() { val assets = context.assets lock.writeLock().lock() try { Sound.values().forEach { s -> sounds[s] = soundPool.load( assets.openFd("sound/${s.toString().toLowerCase()}.wav"), 1 ) } } finally { lock.writeLock().unlock() } } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クラスを作成するとき、列挙からのすべてのサウンドSound



は別のストリームでリポジトリにロードされます。今回は同期コレクションを使用しませんが、標準クラスを使用してミューテックスを実装しReentrantReadWriteLock



ます。



さて、最後に、私たちMainActivity



は内部ですべてのコンポーネントを一緒にブラインドします-これを忘れていませんか？MainMenu



（およびGame



その後）別のスレッドで起動する必要があることに注意してください。

 class MainActivity : Activity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) Audio.init(DroidSoundPlayer(this), DroidMusicPlayer(this)) val surface = DiceSurface(this) val renderer = DroidMenuRenderer(surface) val interactor = DroidMenuInteractor(surface, ResourceStringLoader(this)) setContentView(surface) Thread { MainMenu(renderer, interactor).start() finish() }.start() } override fun onBackPressed() { } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際、それがすべてです。 すべての苦痛の後、私たちのアプリケーションのメイン画面は単純に驚くほどに見えます：





まあ、つまり、知的なアーティストが私たちのランクに登場するとき、それは驚くほどに見えます、そして、彼の助けでこのスカラーは完全に再描画されます。

便利なリンク

私は知っている、多くはこのポイントにまっすぐにスクロールしました。大丈夫です-ほとんどの読者はタブを完全に閉じています。それにもかかわらず、この一貫性のないおしゃべりの流れすべてに耐えたユニット- 尊敬と尊敬、無限の愛と感謝。まあとリンク、もちろん、それらなしで。まず、プロジェクトのソースコード（プロジェクトの現在の状態は、記事で検討されている状態よりもはるかに進んでいることに注意してください）：

• プロジェクトのコア ;
• Cliプロジェクト。
• プロジェクトドロイドを。

さて、突然誰かがプロジェクトを開始して見たいと思うようになり、自分で怠inessを集めるために、ここに作業バージョンへのリンクがあります：LINK！



ここでは、便利なランチャーを使用して起動します（作成について別の記事を書くことができます）。 JavaFXを使用するため、OpenJDK（書き込みおよびヘルプ）を搭載したマシンでは起動しない場合がありますが、少なくともファイルパスを手動で登録する必要はありません。インストールのヘルプはreadme.txtファイルに含まれています（覚えていますか？）。ダウンロードして、見て、使用して、最後に私は黙っています。



プロジェクト、使用するツール、メカニック、または興味深いソリューションに興味がある場合、またはゲームがわからない場合は、別の記事で詳細を調べることができます。必要に応じて。必要ない場合は、コメント、後悔、提案を送信してください。話したいです。



すべて最高。