カードゲームフレームワークの開発


7

やや汎用的なカードゲームフレームワークを構築するために、どのようなデザインパターンとアイデアを使用できますか?

これは、人気のスティーブジャクソンゲーム「マンチキン」のクローンを作ろうとしたためです。そのゲームの性質上、カードの機能を多くコード化する必要がなくなったため、開発は無秩序で行き詰まりました。私は何か一般的なものを構築したかったのですが、多くのオーバーライドされた関数と動作を決定するためのswitchステートメントを含む多くのクラスになってしまいました。

私は、デザインの経験が豊富な人が、汎用のカードゲームフレームワークを構築するこのようなタスク、または少なくとも拡張可能な何かを処理するのに何が必要かを知りました。または、マンチキンのようなカードゲームのシミュレーションを作成したい場合は、特定のフレームワークを作成することにこだわっています。

C#を使用したいと思います。

編集

最終的に達成したいことのいくつかを明確にしたいと思います。基本的にカスタム機能を備えたフェーズを実装できるフレームワークが必要です(フェーズ1:カードを引く、フェーズ2:アップキープルールを適用する、フェーズ3:カードを再生する、フェーズ4:解決するなど)。

その場合、カードとフェーズの両方に結び付けられるルールセットを定義するのが賢明だと思います。

次に、カードが定義され、ルールに関連付けられていると想定します。たとえば、ルールは「維持フェーズの間、トークンを1つ失う」とします。ただし、プレイヤーが持っているカードは「維持フェーズ中にトークンを失わないでください」を提供するかもしれません。したがって、これを結び付けることができればフレームワークの根幹の範囲内にあるとよいでしょう。

これも私のリーグからはずれていると思います。


1
私のために明確にしてください:マンチキンを苦痛なく開発できる何かを探していますか、それとも他のカードゲームでも使用できる一般的なカードゲームフレームワークを作成するという野望がありますか?(余談ですが、後者を検討している場合は、この時点で前者に焦点を当てることをお勧めします)
doppelgreener '19年

私はもうマンチキンにはあまり興味がありませんが、私は実際に別のカードゲーム(自分が作成したもの)を考えています。それは役に立ちますか?
ロブ

回答:


6

LUAやPythonのようなスクリプト言語を使用して、それぞれの特別な動作やカードを定義していました。

このようにして、「汎用」エンジンを定義し、カードの特殊性をメインコードから遠ざけて、小さくて簡単に編集できるスクリプトにすることができます。

XMLまたはその他の「静的」データに対するスクリプト言語の主な利点は、スクリプト言語が、エンジンが提供するパブリックメソッドを使用して独自の動作を「作成」できることです。

例:エンジンが "setDommage(target、dmg)"や "setVisualEffect(nameOfFxLuaScript)"などのメソッドを提供しているとします。このプソコードのようなことをするカードを持つことができます

------Card1 -- A simple fireball-----
// Fire ball
setDommage(target, 37);
setVisualEffect("fireBall.lua");

------Card2 -- A multitype ball (outch it hurts!)-----
// Fire ball
setDommage(target, 37);
setVisualEffect("fireBall.lua");

// Ice ball
if( player.protectionAgainstIce == false )
{
    setDommage(target, 102);
    setVisualEffect("iceBall.lua");
}

// thunderbolt
while( player.Alive )
{
    setDommage(target, 1005);
    setVisualEffect("thunderBolt.lua");
}

両方のカードは、同じエンジンのメソッドを使用し彼らは同じことをしません。ビヘイビアーは、エンジンから収集されたデータ(それらをループするプレーヤーリストなど)およびfor、ifなどのステートメントを使用することもできます。

2つ目ですが、少なくとも利点はありませんが、コンパイルする必要がないということです。ゲームを再コンパイルせずに、LUAスクリプトを変更して直接リロードできます。適切な設定が見つかるまで、テストや反復を行うのに非常に便利です。

3番目の利点は、エンジンで共有されるパブリックメソッドのリストを提供する限り(およびLUAをエンコードしない限り)、スクリプト言語を習得できる誰でも新しいカード/動作を作成できることです。そして、誰もが知っているように、あなたが彼らに素晴らしいツールを与えるとき、コミュニティは信じられないほどです;)


これはC#のLUAラッパーです:http : //luaforge.net/projects/luainterface/


あなたがたまたまあなたが説明しているものに似ているかもしれないプロジェクトへのリンクを持っていないでしょうか?これまでスクリプト言語を使用したことがありません。私は単にカードをXMLで定義し、それらを読み取ることを望んでいました。基本的に、ゲームはカードの機能を適用するだけです。
ロブ

XMLは悪い考えではありませんが、ごく限られた範囲にとどまります。スクリプトは、エンジンが提供するパブリックメソッドを使用してカスタム動作を作成する機能を提供します。このようにして、エンジンは可能な限り「一般的な」状態を維持できます。カードに適用する例はわかりませんが、WoW(アドオン)やAquaria(エンティティの動作)などのLUAを使用するゲームはたくさんあります。
Valkea '19年

ええと、スクリプト言語を使用することには本当にメリットがあると思います。したがって、この例では、ダメージがあります。カードゲームの場合、複数のものを使用して、可能なすべてのアクションを理解するか、一般的な「setActionEffect」を構築することをお勧めします。マンチキンでは、レベルに修飾子を適用してレベルを上げることができます。モンスターを消すこともできます。サイコロを調整することもできます。そのパズルのピースは、私が挑戦されたものであり、そのような複雑なものをモデル化する方法です。
ロブ

スクリプトがどのように彼の「エンジン」が「ProtectionAgainstX」や「CanDoY」などのプロパティのホスト全体にデボルブするのをどのように助けるかは本当にわかりません。実際、スクリプトはカプセル化を強制的に解除するように思われます。新しいカードを追加したり、基本的なゲームルールを変更したりするのがますます難しくなると思います。
Alex Schearer、

@アレックス:目標は、より一般的なものにすることです。そのため、ゲームのコードやコアを変更することなく、完全に異なるユニバースで使用できます。疑似コードで使用されている "protectionAgainstIce"は、 "if"ステートメントを示すために使用された悪い例でしたが、異なるもので再利用可能なより一般的なisProtectedAgainst( "ice")のようなものである必要があります( "fire"、 "ボール」、「レーザー」など)。このように、タイプ(火など)がゲームコアの外部でも定義されている限り、可能性の「無限」があります。
Valkea
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.