記事一覧
嘘バルズ構築記録#9
間が空いたのでコーディングする前に整理する。
マリガンの一連の処理が終わった後、先攻1ターン目開始時のResultがそれぞれに送られる。
ResultはPerformResult()という関数（コルーチン）で処理をする。
PerformResult()はResult内のLog配列に従って演出処理をする。
すべての演出が完了したら、Result内のBoardの状態とクライアント上の盤面状態を比較し
嘘バルズ構築記録#8
部品作りクライアント側にサーバとのインターフェイスを組み込んでいきたいところだったが、そもそもクライアント側の実装が後回しだらけだったので、最低限必要なパーツを作っていく。
マリガン処理の修正
ライバルズの相手のマリガン待機って交換してから待機だったんだな。
というわけで#6のマリガン操作を受け付ける処理を以下に修正。
サーバは、クライアントからのマリガン操作を受け付けて処理をし、送信者にの
嘘バルズ構築記録#7
サーバとクライアントの連携ゲームの流れに沿って考えてみる
内容が#2の処理と被るが
マッチングから１ターン目開始まで
クライアントAが、サーバに「プレイヤー名とデッキ情報」を送ってマッチングを要求する。
クライアントBが、（以下Aと同じ）
サーバが、AとBの要求を受けてマッチングする（細かいマッチング処理とかはとりあえず考えない）
サーバが、AとBにマッチングが成功したことと相手の基本情
嘘バルズ構築記録#6
手札の操作とりあえず実装すべきはマウスオーバーとドラッグ。
Godotの3Dオブジェクトに対するマウス操作
カードにArea3Dと適当なコリジョンを設定して、input_ray_pickableがtrueならCollisionObject3Dのマウス系シグナルを飛ばしてくれるので、それを使ってごにょごにょする。
マウスオーバー
mouse_entered()が来たら実行し、mouse_ex
嘘バルズ構築記録#5
タイトルが長いので変更。
クライアントサイドイメージ
とりあえず見た目から。
これは模倣なので模倣元に倣えばいい。楽である。
Godotのシーンエディタで適当にMeshInstance3Dを配置する
ぴったり合うカメラ設定が見つからないがまあ大体で。
手札や他のHUD表示部分は2Dでも良かったか。
操作
PCでのマウス操作のみを考える。それ以外の操作方法はとりあえず考えない。
ほとんどの
ハースライクDCGの構造研究のための実装実験#4
ユニットのアタック考えていくと結構要素がある
攻撃対象を制限するシステム
優先攻撃対象（におうだち）
攻撃されない（ステルス）
ライバルズでは追加で
ブロック
ウォール
制限を無視する効果として「ねらい撃ち」がある。（ステルスは無効化できない）
攻撃ユニットにねらい撃ちがあればステルス以外の全対象
ねらい撃ちが無い場合は、
におうだちが機能しているユニットがいるならそのユニットの
ハースライクDCGの構造研究のための実装実験#3
カードのプレイ操作に必要な情報から分けると二種類に分類できる。
盤面に空きないとプレイできないもの
盤面に空きがなくてもプレイできるもの
盤面に空きないとプレイできないもの
ライバルズで言えばユニットや建物。
特にライバルズでは配置する位置もプレイ時に指定することになる。
必要な情報は「使用するカード」「配置する位置」「召喚時効果の選択情報」
召喚時効果がなければその位置にユニットを配置す
ハースライクDCGの構造研究のための実装実験#2
オンライン対戦ゲームを実装するにあたって最も有効なチート対策は、ゲームのルール処理を全てサーバ上で行い、クライアント（プレイヤー端末）には必要な情報のみを送り、有効な入力のみを受け付けるようにすること。
リアルタイムでフレーム単位の処理が必要なゲームではこの方法は現状では実装が非常に難しいが、カードゲーム等のターンベースには最適である。（専用のサーバを用意する、という点がいささかネックではあるが）
ハースライクDCGの構造研究のための実装実験#1
ここで言うハースライクDCGとは
二人のプレイヤーが交互にターンを進行し、一方がプレイ中は他方が如何なる介入も出来ない。
ターンごとに、カードを使用するためのリソース値が基本的に1づつ増える。
攻撃力と体力を持つカードを盤面に出して互いに殴り合い、相手プレイヤーの体力を0にした方が勝ち。
等の特徴を持つものとする。
何したいいままで自作のDCGメカニクスを弄ってきたが、王道のメカニクスが
他人様のアナログカード（シール）ゲームを勝手にデジタル化してみたのを振り返る（前編）
始まり自分のデジタルカードゲームの実装パターンを、他の物にも応用できるのか？ を試してみた感じ。
基盤構築内部的な盤面状態とルール処理自体は一日か二日で出来ていた気がする。
インターフェイス部分は、昔noteに下書きだけして放置していた記事に書いてあった方法を試してみることに。
UI模索操作（プレイヤーがゲームに介入する入力）自体は微妙な差を吸収すれば一種類しかないので（手札から一枚選んで、
ぼくのかんがえたさいきょうにシンプルで公平なデジタルカードゲームシステム
構成要素
重要な構成要素は三つ
同時ターン制
手札公開制
デッキライフ制
同時ターン制
採用理由は「先攻後攻の有利不利がない」
このシステムがマイナーな理由の考察としては、
コンボを成立させるシステムが難しい
というのに尽きるか？
どうでもいいけど、英語では"Turn-based WeGo"と呼ばれてるっぽい？
手札公開制
採用理由は「読み合い」
手は見えているけど頭の中は見え