Kikoumori's Diary

cβ「シュミッドディーヴァ」のプレイ感想

ハンゲーム内でクローズドベータテストが行われていた「シュミッドディーヴァ」というゲームをプレイしてきました。

http://schmiddiva.hangame.co.jp/

公式の説明では「オンラインマジックバトル」とされていますが、基本はカードを使ったネットワーク対戦ボードゲームです。
もっとわかりやすく言うと、ほぼカルドセプトですｗ

カルドセプトなどボードゲーム系と一番違うところは、勝ちの基準が、所謂お金を一定値以上集めた者が勝ちということではなく、
プレイヤーにはライフポイントがあり、ダメージを受けそれが０になった者が負けるというスタイルであるところです。
カードゲームなんかでは、当たり前のシステムですが、ボードゲームでは結構新しいシステムではないでしょうか。
お金を溜めるスタイルの場合、ルール上どうしても決着までに時間が掛かったり、数字が細かくなったりして、
プレイヤーの各要素への操作による勝敗への影響みたいなものが、薄くわかりにくくなっているような気がします。
その点、今回のようなライフをやり取りするスタイルは、影響がダイレクトにライフの増減につながり、
戦略や戦術の良し悪しが比較的わかりやすくなっていると思います。

デッキ編集画面

基本的なルールの説明をすると。
プレイヤーはユニット、バトルマジック、フィールドマジックの３種類のカードから４０枚のデッキを組み対戦します。
プレイヤーは交互にダイスを振り、マップを移動し、止まった場所にユニットを召喚して、その土地を占領していきます。
カードには能力、効果に見合ったコストが設定されており、召喚時やマジック使用時にはコストを払わなければいけません。
そのコストはユニットで土地を占領するごとに上限が増加し、自分のターン毎に上限までポイントが貰えます。

対戦画面

相手の土地に止まった場合は、土地のレベル分のダメージを受けますが、戦闘を行い土地を奪うことでそれを回避することもできます。
戦闘では、侵略側が先に攻撃し、その攻撃で防御側がのユニットが破壊すると、その土地を奪うことができます。
ただし、戦闘には攻撃の前に侵略側も防御側もバトルマジックを２回まで使うことができ、
その効果によって勝敗ががらりと変ることもあり、このゲームの一番の見所になっています。
まぁ、しかしここらへんも２回使えるというところを除いて、カルドセプトによく似てますねｗ

勝敗の決着は、ダメージを受けライフが０になると負けとなるのですが、
ダメージは相手の土地に止まるか、ユニットが破壊されるかによって受けます。
ダメージを相手に与えるためには、ユニットを召喚し多くの土地を占領しなければなりませんが、
ユニットを多く土地に置けば、それだけ相手にユニットを破壊され、自分がダメージを受ける可能性も増します。
また、強力なユニットほど破壊されたときのダメージが大きくなったりもしますので、
そこらへんのどこに、どれだけ、どの程度のユニットを配置するかという点については、
他のボードゲームより気をつける必要があり、より戦略性が必要になっています。

また、個人的に、移動時のダイスが予め歩数がわかる固定ダイスとランダムな歩数が出るランダムダイスの２種類があったり、
手札を引きなおすシャッフルというものが、１ゲーム中で５回まですることができたりと、
ボードゲーム、カードゲーム特有の運による影響を抑えようというシステム作りには好感が持てました。

総評としては、ゲーム自体の面白さという点においては十分合格点であると思います。
これから、またさまざまな効果を持ったカードが追加されていけばより面白くなっていくでしょう。
ただし、問題は環境面にあります。cβではあるのでしかたないのですが、
フリーズ、同期ズレ等によってゲームが続けられなくなることが、４，５回に１回は起こっていました。
cβの期間は１週間ちょっとで、私は初めから最後までいましたが、明らかに人が少なくなっていき、
最終日には、もっと盛り上がるかと思っていましたが、過疎って１００人も居なかったと思います。

また、こういうカードゲームは運営によって繁栄するかどうかがはっきりと決まります。
というか、しっかりと運営しないと続かないともいえるでしょうか。
この「シュミッドディーヴァ」も課金方法やカードの追加等を間違えると、速攻でサービス停止に追い込まれる気がします。
まずは、ちゃんとプレイできるように不具合を修正することが１番でしょう。
そして、正式サービスが開始され、金儲けに走り過ぎないプレイヤーのことを考えた課金方法を取れれば、
それなりに繁栄していくのではないかと思います。

ちなみに明日、２１日１８時から６時間だけのオープンテスト（負荷テストとも公言されているｗ）もありますので、
「シュミッドディーヴァ」に興味があれば、一度参加してみてはどうでしょうか。

2007年09月20日（木） No.174 (ゲーム)

Comment(0) Trackback(0)

ネット対戦ボードゲームでの同期の考え方２

昨日の続き。。。

昨日考えたことの要点だけを記すと、同期の仕方として、結果だけを伝えるタイプと途中の選択も伝えるタイプがあるということ。
昨日は移動というシステムを対象に考えたが、途中の選択も伝えるタイプについては、
もう一つシステム的に分類できるタイプがある。

移動は途中の選択において、キャラが実際に動き視覚的にも途中の選択が確認できた。
これに対して、例えば土地を買い、そこに家を立てて、さらに家の色を何色かに塗るというシステムを考える。
（まぁ、モノポリーに毛がはえたようなものと想像してほしい。）
この場合、土地を買った後に、どういう家を建てるかを決め、さらに何色にするかを決めることになる。
この場合は、どういう家を建てるかを決めた時点では、何色かわからないので、
マップ上に実際に建てて、視覚的に見せることはできない。
次の選択である色の指定をしてからでないと、具体的に描画はできないのである。
このような、途中経過が結果として表示できないタイプがもう一つのシステムである。

そしてここで注意しなければならないのが、このような途中経過を具体的に描画できないタイプのシステムにおいては、
途中の選択も伝えるような方法は使えないのである。というか、使っても意味がないのである。
なぜならば、途中の選択の情報を送信したとしても、受け手の画面上ではなんの変化も起こらないからである。
（まぁ、内部のデータの整合性のためにやり取りする必要がものによってはあるのかもしれないが。）

ここで、家庭用のコンシューマーゲームでよくボードゲーム等をやる方なら別に珍しくもなんともないだろうが、
このような途中選択の結果を表現できないような対象であっても、情報を共有して表現する手段はある。
単純な話であるが、途中の選択動作自体を待機プレイヤーの画面上でも表示すればいいのである。
家庭用ゲームでは対戦時に操作プレイヤーと待機プレイヤーが同じ１つの画面を見ているので、
選択の途中経過などは、操作プレイヤーの画面がそのまま待機プレイヤーへの情報の伝達になっているのである。

しかし、このシステムはあくまで、多人数のプレイヤーが１つの画面で、操作者が常に１人であるから成り立っているわけで、
（コントローラーが２つあっても、結局操作するのは順番が回ってきたプレイヤーのみで、
その他のプレイヤーはせいぜいブーイングを入れる程度であるから、操作者は常に１人と言える。）
ＰＣでのネット対戦のような、各プレイヤーごとに１画面、操作もプレイヤーが同時に行うことがあるシステムでは問題が出てくる。
つまり、ＰＣでのネット対戦の場合、ある１人のプレイヤーの順番で操作中だからといって、
他のプレイヤーは他のプレイヤーで自分の画面があるため、そのプレイヤーの操作をずっと見ている必要はなく、
自分で操作しその結果を自分の画面上のみに反映させることで、勝手に違うことをしてもいいのである。

例えば、ボードゲームであれば、他プレイヤーとの戦力差を確認して、今後の戦略を練るといようなことが必要になる。
そのためには、自分の番が回って来た時に、情報を確認するのではなく、
他人のプレイヤーが操作している間に、情報を確認しておくべきであり、
また、全マップが１画面に表示されていないような場合であれば、
マップを確認しておき今後自分が進む先を確認しておくというような行為も重要になってくるわけである。

ましてや、ネット対戦は思考ゲームであっても、相手の長考や待機時間が長いことを嫌う人が多く、
さっさと進めたがる傾向があるので、（個人的には、思考ゲームでは、「考える」ということが醍醐味なのだから、
その時間を待てないようなやつは、思考ゲームをやるなと言いたいところではあるのだが）
他人の操作中に、次の自分の行動時間のための準備ができるという、
考慮時間を短縮し、ゲームの展開をスムーズにするシステムは歓迎されるだろう。

ここまでくれば、また新たな問題が見えてくるわけである。
つまり、操作プレイヤーの操作をどこまで、待機プレイヤーの画面に表示させるかという点である。
操作プレイヤーの行動を事細かに待機プレイヤーに伝えようと思うと、待機プレイヤーの画面にも、
操作プレイヤーの画面と同じようなものが表示されるようになり、待機プレイヤーの事前準備などの操作は行いにくくなるだろう。
情報の共有が少なすぎれば、対戦をしている、同じゲームをやっているという感覚が薄れてくるし、
連携が詳細になりすぎれば、その理解に時間を取られ、各プレイヤーの時間は失われるだろう。

当然こういう問題は、どちらを重視するかというようなバランスの問題でもあるのだが、
システムの構築としてもそれなりに難しい問題でもある。
まぁ、その話はまた今度、機会があれば・・・

ひとりごつ (@ ﾟДﾟ)ﾉﾀﾞｧｧｰｰｰｰｰﾝ!!

2007年09月09日（日） No.173 (独り言)

Comment(0) Trackback(0)

ネット対戦ボードゲームでの同期の考え方

なんとなく日記更新も滞ってるし、備忘録的に独り言を書いてみる。
とくに深く考えて書いてるわけでもないので、キツイツッコミは無しの方向で。

ネット対戦ボードゲームでの同期の取り方を考えてる。
プロトコルがどうだとかそういうことではなく、ゲームシステム的な部分で。

チャットとか、通信状態がどうだとかそういう部分を除いて、
ゲームの内容にかかわる部分でいうとボードゲームでは通信の必要があるのは、
・イベントの発生や獲得金の金額などの、なんらかの結果について
・移動方向や項目の選択などの、プレイヤーの選択について
単純に言えば、この二つである。

当然であるが、１つ目の「結果」については完璧に同期しなければゲームは成り立たない。
あるプレイヤーが１００円獲得したのに、違うプレイヤーの画面では５０円しか獲得していなかったり、
プレイヤーがゴールまで到達したのに、他プレイヤー上では一歩手前までしか進んでいなかったりしたら、
同じゲームをやっているはずなのに、プレイヤーごとにゲームの結果が違うなんてことになってしまうからである。

まぁ、結果に関しては当然同期するということで問題ないが、
２つ目の「選択」について、どこまで同期させるか、ということが悩ましいのである。

例えば、具体的に移動システムで考えてみると。
操作プレイヤーが移動するには、ルーレットを回し、そこで出た目の数だけ進むとして、
マップは分岐もあり移動方向は操作プレイヤーが選択するとする。
操作プレイヤー以外の待機プレイヤーは、操作プレイヤーから情報を受け取り、
その結果を各プレイヤーのアプリ上で同様の結果になるようにエミュレートするわけである。
ここで問題になるのは、操作プレイヤーと待機プレイヤーとの間でどこまでどのタイミングで同期をさせるかということ。

具体的な同期の仕方としては、
１．操作プレイヤーが全ての移動を終えてから、待機プレイヤーに移動先を報告し、そこから待機プレイヤーは移動を開始する。
２．操作プレイヤーの各所での操作を全て待機プレイヤーに送信し、その都度待機プレイヤーもその報告にしたがって処理を行う。
というような方法が考えられる。

１のような方法だと、操作プレイヤーが途中の分岐地点で移動方向を考えていたり、
移動距離が長い場合など、移動開始から停止地点の決定まに時間が掛かると、
待機プレイヤー上では、操作プレイヤーが何もせずに開始地点でずっと止まっているように見えてしまう。

では、２つ目の方では、問題がないかというとそうでもない。キャンセルの扱いである。
操作プレイヤーが分岐で、最初は右に行ったが、やはり思い直して左に行こうとするようなこともあるだろう。
そのような場合、その都度情報を送信するため、待機プレイヤーの画面でも、
最初は右に行ったがやはり戻って左に行ってと、キャラが右往左往することになる。

そういうことを考えると、今度は１の結果だけを送信する方が、
行ったり来たりする場合でも、開始地点からまっすぐ移動先まで行くので、
すっきりしていていいかもしれないという感じもする。
まぁ、２は２で、プレイヤーの試行錯誤などが感じられて、
対人戦をやっているという感じがして、臨場感がするともとれるかもしれないのだが。

結局のところ、どちらがいいということはなく、どういう同期の取り方、見せ方をするかという問題なのである。
これが結構悩ましくて、どうしたものかと思っているわけである。

さらに、もう一つの考え方として、キャンセルというシステム自体を盛り込まないという方法もある。
これは、そのシステム（今回の例では移動）が、プレイヤーが間違いやすいか、
途中で気が変りやすいかというような点も考慮しなくてはならなくなる。

例えば、移動の操作方法が、十字キーで１マスずつ移動方向を指定して進むというようなシステムの場合、
プレイヤーはさっさと移動したいがために、移動中十字キーを連打するということは容易に想像できるだろう。
この場合、連打のし過ぎで曲がるべき分岐点をそのまま直進してしまうというような、誤操作をしやすいということが考えられる。
そうならば、システムとしては、行き過ぎたときに少し戻って、行き先を変えられるという、
キャンセルシステムがあった方が便利だし、不快感も感じにくいだろう。

しかし、また別の例として、移動方向の指定が各分岐点で進行方向の矢印が大きく表示され、
プレイヤーはその矢印をクリックし、あとは自動で次の分岐点か停止地点まで移動するというシステムの場合、
矢印の押し間違いが起こりにくそうなのであれば、逆に戻る方向の矢印は表示しない、
キャンセルの無いシステムのほうが、選択肢が減ることで押し間違いもさらに減るだろうし、
また、画面もすっきりするし、ユーザビリティ的によくなるかもしれない。

結局は、キャンセルというシステムもその都度、必要であるかどうかを考えなければならないわけである。
まぁ、さっきのところを操作ミスしなければ勝てたのに、とかいうのが嫌いなので、
個人的にはキャンセル肯定派であるのだが。

とまぁ、いろいろとどうでもいいようなことを考えている今日この頃なのである。

2007年09月08日（土） No.172 (独り言)

Comment(0) Trackback(0)

Information: >> [HOME] >> [DIARY TOP]

管理人：きこうもり(黄蝙蝠、Kikoumori)
Mail：add-spice＠kikoumori.com

オンラインカードゲーム「Worlfard」稼動中！

カレンダー

最近の記事

スポンサードリンク

検索

<<2007年09月>>
日	月	火	水	木	金	土
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30