最近の記事

嘘バルズ構築記録#9

間が空いたのでコーディングする前に整理する。 マリガンの一連の処理が終わった後、先攻1ターン目開始時のResultがそれぞれに送られる。 ResultはPerformResult()という関数(コルーチン)で処理をする。 PerformResult()はResult内のLog配列に従って演出処理をする。 すべての演出が完了したら、Result内のBoardの状態とクライアント上の盤面状態を比較し、もし一致しなければクライアントの盤面を強制的にResultのBoardの状態に

    • 嘘バルズ構築記録#8

      部品作りクライアント側にサーバとのインターフェイスを組み込んでいきたいところだったが、そもそもクライアント側の実装が後回しだらけだったので、最低限必要なパーツを作っていく。 マリガン処理の修正 ライバルズの相手のマリガン待機って交換してから待機だったんだな。 というわけで#6のマリガン操作を受け付ける処理を以下に修正。 サーバは、クライアントからのマリガン操作を受け付けて処理をし、送信者にのみ結果を返す。 結果を受け取ったクライアントはマリガン処理を完了させ、サーバに

      • 嘘バルズ構築記録#7

        サーバとクライアントの連携ゲームの流れに沿って考えてみる 内容が#2の処理と被るが マッチングから1ターン目開始まで クライアントAが、サーバに「プレイヤー名とデッキ情報」を送ってマッチングを要求する。 クライアントBが、(以下Aと同じ) サーバが、AとBの要求を受けてマッチングする(細かいマッチング処理とかはとりあえず考えない) サーバが、AとBにマッチングが成功したことと相手の基本情報を伝える AとBは、マッチング成功を受けて対戦画面を作成し、準備が完了したら

        • 嘘バルズ構築記録#6

          手札の操作とりあえず実装すべきはマウスオーバーとドラッグ。 Godotの3Dオブジェクトに対するマウス操作 カードにArea3Dと適当なコリジョンを設定して、input_ray_pickableがtrueならCollisionObject3Dのマウス系シグナルを飛ばしてくれるので、それを使ってごにょごにょする。 マウスオーバー mouse_entered()が来たら実行し、mouse_exited()が来たら元に戻す。 Area3Dの位置はそのままにして、表示する部分

        嘘バルズ構築記録#9

          嘘バルズ構築記録#5

          タイトルが長いので変更。 クライアントサイドイメージ とりあえず見た目から。 これは模倣なので模倣元に倣えばいい。楽である。 Godotのシーンエディタで適当にMeshInstance3Dを配置する ぴったり合うカメラ設定が見つからないがまあ大体で。 手札や他のHUD表示部分は2Dでも良かったか。 操作 PCでのマウス操作のみを考える。それ以外の操作方法はとりあえず考えない。 ほとんどの操作はドラッグが起点になる。 ドラッグ操作が終了した後に追加の選択が発生する場合

          嘘バルズ構築記録#5

          ハースライクDCGの構造研究のための実装実験#4

          ユニットのアタック考えていくと結構要素がある 攻撃対象を制限するシステム 優先攻撃対象(におうだち) 攻撃されない(ステルス) ライバルズでは追加で ブロック ウォール 制限を無視する効果として「ねらい撃ち」がある。(ステルスは無効化できない) 攻撃ユニットにねらい撃ちがあればステルス以外の全対象 ねらい撃ちが無い場合は、 におうだちが機能しているユニットがいるならそのユニットのみ。 におうだちがいない場合は、 ステルスを持たない前衛と、前がステルス状態かそ

          ハースライクDCGの構造研究のための実装実験#4

          ハースライクDCGの構造研究のための実装実験#3

          カードのプレイ操作に必要な情報から分けると二種類に分類できる。 盤面に空きないとプレイできないもの 盤面に空きがなくてもプレイできるもの 盤面に空きないとプレイできないもの ライバルズで言えばユニットや建物。 特にライバルズでは配置する位置もプレイ時に指定することになる。 必要な情報は「使用するカード」「配置する位置」「召喚時効果の選択情報」 召喚時効果がなければその位置にユニットを配置するだけだが、多岐にわたる召喚時効果によって実装がややっこしくなる。 可能なら、召

          ハースライクDCGの構造研究のための実装実験#3

          ハースライクDCGの構造研究のための実装実験#2

          オンライン対戦ゲームを実装するにあたって最も有効なチート対策は、ゲームのルール処理を全てサーバ上で行い、クライアント(プレイヤー端末)には必要な情報のみを送り、有効な入力のみを受け付けるようにすること。 リアルタイムでフレーム単位の処理が必要なゲームではこの方法は現状では実装が非常に難しいが、カードゲーム等のターンベースには最適である。(専用のサーバを用意する、という点がいささかネックではあるが) つまりオンライン対戦カードゲームを作るということは、サーバ(ルール処理)とク

          ハースライクDCGの構造研究のための実装実験#2

          ハースライクDCGの構造研究のための実装実験#1

          ここで言うハースライクDCGとは 二人のプレイヤーが交互にターンを進行し、一方がプレイ中は他方が如何なる介入も出来ない。 ターンごとに、カードを使用するためのリソース値が基本的に1づつ増える。 攻撃力と体力を持つカードを盤面に出して互いに殴り合い、相手プレイヤーの体力を0にした方が勝ち。 等の特徴を持つものとする。 何したいいままで自作のDCGメカニクスを弄ってきたが、王道のメカニクスがどういう風に実装されるのか知っておくのも悪くはない。 そして研究が目的なので、

          ハースライクDCGの構造研究のための実装実験#1

          他人様のアナログカード(シール)ゲームを勝手にデジタル化してみたのを振り返る(前編)

          始まり自分のデジタルカードゲームの実装パターンを、他の物にも応用できるのか? を試してみた感じ。 基盤構築内部的な盤面状態とルール処理自体は一日か二日で出来ていた気がする。 インターフェイス部分は、昔noteに下書きだけして放置していた記事に書いてあった方法を試してみることに。 UI模索操作(プレイヤーがゲームに介入する入力)自体は微妙な差を吸収すれば一種類しかないので(手札から一枚選んで、盤面の一か所を対象にプレイ)、非常に単純。 プレイする対象の位置が重要な場合、カ

          他人様のアナログカード(シール)ゲームを勝手にデジタル化してみたのを振り返る(前編)

          ぼくのかんがえた(略)カードゲームシステムをUnityの習作として組んでみた。

          始まり色々あって、せっかくだから今更Unity触ってみるか。 ↓ とりあえずサンプルを触る。 アクション系はあんまり乗り気になれない。何か目標はないものか? ↓ そういえば一年前にオンライン対戦カードゲーム(HTML)を動くところまで組んで放置していたので、あれをUnityで組みなおしてみるか。 CPU戦までとりあえず2Dで適当に画面を構築して、入力操作、スプライト操作等を調べながら弄る。 ゲームのルール部分を組んでいく。手始めにCPU戦をC#で組んでいく。 publi

          ぼくのかんがえた(略)カードゲームシステムをUnityの習作として組んでみた。

          ぼくのかんがえたさいきょうにシンプルで公平なデジタルカードゲームシステム

          構成要素 重要な構成要素は三つ 同時ターン制 手札公開制 デッキライフ制 同時ターン制 採用理由は「先攻後攻の有利不利がない」 このシステムがマイナーな理由の考察としては、 コンボを成立させるシステムが難しい というのに尽きるか? どうでもいいけど、英語では"Turn-based WeGo"と呼ばれてるっぽい? 手札公開制 採用理由は「読み合い」 手は見えているけど頭の中は見えない。 互いの可能性を確認したうえで、相手が何を出すか考え自分が何を出すかを決

          ぼくのかんがえたさいきょうにシンプルで公平なデジタルカードゲームシステム