SINCE : 2001.05.29
MOVED INTO HERE : 2006.01.01
遊星ゲームズ
FrontPage | RSS


2009/07/26 02:04

咲6巻
 日記

 さっき出てることを知って、買ってきた。
 夜だったので、売ってるコンビニを捜して歩き回ったり。

amazon 麻雀マンガってのは、ボードゲームマンガなんです。もちろん、麻雀もボードゲームなのだから。
 そして、しかも、囲碁や将棋と決定的に違うところがある。麻雀はマルチプレイヤーズゲームなんである。
 我々ボードゲーマーの領分に一番近いところにある物語が麻雀マンガというわけで、これは読まないわけにはいかない。
 しかも、大変幸せなことに、ムダにたくさんある(笑)

 とくにこの『咲』というマンガ。かなりマルチゲームを扱っている。
 他家と協力したり利用したり、1対1の対戦にはない要素をちゃんと描いている。そういうところが好き。ボードゲーマー向けのマンガ!とか思ってたりする。
 まあ美少女もいいけど。

 やってることはめちゃくちゃですがね-。嶺上開花(リンシャンカイホウ)が得意な主人公なんて、もうその時点でなんかもうおかしいし。
 しかし。めちゃくちゃだけど、意外とゲームのことをよく表現した話という気もしている。
 麻雀打ってれば誰でも経験あると思うけど、たしかに嶺上開花で和了る人だって、いないわけじゃない。デジタルにやってると、そもそも(カン)する機会自体あまりないし、嶺上牌で和了れるなんて考えもしないけど、でも、和了るつもりで槓する人がそれをやって、本当に和了ってしまうことも、まったくないわけではない。
「自分は運がいい」「ツモがいい」「流れがいい」というようなオカルトを、心から信じている人もいる。
 たぶん、そういうのを信じていると打ち筋が変わるんだろう。いわゆるデジタル打ちの観点からは明らかに間違いのオカルトではあっても、ときにはそれが正解という場面もある。
 もちろん、あくまで絶対的に正しいのは数字だけど。でもマルチプレイヤーズゲームには、必勝法が存在しないのだ。

 それに……、この話、架空の世界の、高校生麻雀全国大会なんである。
 学生スポーツってのは、けっこうこういうものなんである。サッカーでも野球でもなんでも、けっこうそう。
 もちろん日々の鍛錬や技術、理論は大前提条件として、その上でだけど。
 怪物が一人いると、そのチームがぽんぽんと勝ち上がってしまったりするんである。それはもう、どんな力でもいい。勢いだろうと運だろうとかまわない。
 特にトーナメント形式の大会はそう。特別な星の下に生まれてくることが必要なんだと、よく思う。
 そりゃあ、嶺上開花を4回も和了るとか、ふつうはありえないけど。でも、それはマンガ表現の上での話だ。
 マンガという媒体では、ただ単にリアルな描写をするよりも、多少大げさに書いたほうが説得力がある。説得力がある以上、そのほうが読者にとって、現実に近いともいえる。

 というわけでじつは意外と好きなマンガ。6巻は、海底(ハイテイ)使いVS嶺上使いの対決が佳境に入ってきたーというお話。


2009/07/18 00:04

ボードゲームを作って売ってくれるサイト「The Game Crafter」
 日記

 Tech Crunchで紹介されてたボードゲームのコンポーネントやらルールやらをアップロードすると、印刷、制作をしてくれて、販売までしてくれるらしい。

ユーザはまず、自分が作りたいボードゲームやカードゲーム用のイラストや部品(サイコロ、駒など)、遊び方やルールのドキュメンテーションなどをアップロードする。もちろん、それらを書いたり描いたりネット上などから集めたりというたいへんな作業は全部ユーザがやる。でも、素材が揃えば、あとは一気呵成だ。ただし現状では、ユーザは駒のデザインができないなど制約がある。でも同社は、今後は何でもユーザが指定/設計できるようにすると言っている。

 ていうかそんな商売がなりたつ国があるのかー。日本にいると想像できない世界だーと思った。

このサイトのすてきなところは、ユーザが前払い金などをいっさい払わなくてよいこと。印刷、製作、流通とすべてをサイトがやってくれて、売れたら売上の50%を取る。50%は大きいようだが、サイトの説明によると、全部自分でやると、メーカーの手元に入るのは小売り売上額の30%程度だという〔まあそんなもんでしょ〕。また、権利は完全にユーザにあるから、ほかのところで売ってもよい。

 だそうです。


kamata -2009/07/18 09:21
>ていうかそんな商売がなりたつ国があるのかー。日本にいると想像できない世界だーと思った。
 日本だと同人出版業に相当するビジネスですが……

 英語テキストは用意できているので、VSシステム東方セットの英語版を作る需要があればうちは即座に頼めますが、問題はVSのルール著作権関係ですかね。


てらしま -2009/07/18 15:18

 日本だと同人出版業に相当するビジネスですが……
 ですが、同人ゲームの流通をやろうとすること自体考えられないし、そもそもそういう形態の同人ユーザ自体少ないですよねえ。
 それとも、やってみれば意外となんだろうか。


kamata -2009/07/20 11:21
 この会社「TGC」の制作概要部分で触れられているのですが、
http://www.thegamecrafter.com/publish
 TGCはもともとそれ自体が零細ゲームメーカー(日本で言えば中堅同人事業に相当)で、そこそこうまくやっていたので、提携や交流のあった他のデザイナー/メーカー/同人集団からボドゲの実製作委託を過去にも頻繁に請け負っていて、そのノウハウでこの『作りますよ』事業を始めたみたいです。むしろ拡大しての狙い目顧客層は「小規模遊興のための個人的なゲーム」("Familiy Game Authers")や「教育・知育教材」("Teachers")の市場と考えてるんじゃないでしょうか。
 「見込みはよくわからんが、とりあえず事業として始めてみよう」は、商業流通と同人クラス市場の線引きが明確ではない欧米だから気安くできたオプション、とは言えますが、それなら前の「輸入ゲーム問屋業」の話のように、日本のアナログゲーム市場同じ空気の世界ではないでしょうか。

 日本の同人ゲーム全体でも、部分製作請負・素材提供・スタッフ紹介斡旋みたいなことが個人・サークルレベルで行われてはいるようですから、案外需要はあるかもしれません。
 「まずはポータルの情報サイト運営から」という着手が無難そうですが、これまでなかなか日本でこの種のビジネスが出てこなかったのは、みんな情報サイトだけで満足しちゃうからかも。


2009/07/16 03:36

PHP フレームワーク作りのポイント
 プログラム

 PHPにはいろんなフレームワークがあって、その中のどれが一般的!というのはたぶん、あまり決まっていない。たくさんあるし、どれも長所と短所がある。選ぶのが難しい。
「別にフレームワークなんかいらない」というのも一つの選択肢だし(そしてそれがけっこう採用されている)、フレームワーク自作!というのもいいだろう。

 個人的な現状での結論は、フルスクラッチだ。なぜなら、既存のモノを選ぶと高級すぎるから。できるだけ機能の少ないフレームワークをまず作る。
 PHPで仕事をする以上、PHPの技術者が集まってるはずで。しかし標準的なフレームワークは決まっていないから、みんな共通で知っているのはネイティブPHPだけなんである。そんな状況で、フレームワーク独自の記法とか、大量のライブラリのAPIをみんなに読んでもらうとか、そんなことは現実的じゃない。
 誰もが知っているフレームワークとかが、あるなら考えるけど。Zend Frameworkとかがそういうものになってくのかもしれないけど。あれはそんなに悪くなさそうとは思うんだけど、なんか好きじゃない(笑)。

 個人的な意見ですよあくまで。経験も浅いし。
 経験十年!なんて人たちの意見と食い違っていることもあると思いますが。そのときは、どれが説得力あるか判断するのは読者諸氏です。


 フレームワークを選ぶ/改造するときは、次にあげるような基準で考えるといい。と思う。または、自作するときは次のような機能を作る。

 まず一番大切なこと。

  • グローバルスコープを使わない
     あまりにあたりまえのことだ。変数だろうと関数だろうと、グローバルにはなにも置いてはならない。置いていいのはクラス定義だけ。
     定数も同じだ。define文はできる限り使わないようにする。
     グローバルをひとつでも使うと、そこから汚染が拡がっていくことになる。できる限り早い段階で撲滅しておきたい。
     選んだフレームワークやライブラリがグローバルを使っているならしかたないけど。それ以外では、絶対に使わないようにしなければいけない。
     ただ、これをフレームワークの選定基準にしてしまうと、けっこうな数が落第になってしまうわけだが(笑)。
  • ネイティブPHPを活かす
     フレームワークを使う以上、本当なら、できるだけフレームワークが用意したモノを使うべきだ。と思う。
     でもたとえば「Util::dateFormat()」という関数があったとき。それはPHP標準のdate()関数じゃダメなのか?
     そもそも日付の整形処理を書くときに、このUtil::dateFormat()を、APIリファレンスの中から発見できるのだろうか? 開発メンバー全員が?
     はっきりいってムリ。
     本当なら、たとえまったく同じ機能だとしても、ラップしてあることには意味がある。本当なら、採用したフレームワークが用意したモノをできるだけ使うべきなんだけど。現実的にムリなんだからしかたない。
     フレームワークにはたいてい、いろんなライブラリが付属している。なぜなら、そうしておけば「これもできます!」といえるから。
     客寄せのためなんである。
     というか一般に「あれもこれもできます!」系のものでないと、選ばれないんである。残念なことに。
     だから、有名な奴はたいてい、過剰だ。
     わたし自身はわりと、リファレンスを必死で読むほうだ。でもしょうじきなところ、いつも徒労感がある。いっそのこと、それらを使わないことにしてしまっていい。
  • 配列を使わない
    amazon フレームワークには、たとえばO-Rマッピング用のライブラリとかがついているかもしれない。でも、それを使う前にちょっと待とう。find()メソッドが、2次元の連想配列を返していないだろうか?
     そうなっていたら、その部分は自作したほうがいい。連想配列ではなく、データを格納するためにはオブジェクトを使うべきだ。
     たとえ全部publicメンバだったとしても、オブジェクト指向には、クラスで宣言していないメンバを追加したくないインセンティブが働く。いっぽう連想配列は、あとから勝手にいろいろ追加されてしまう。
    「基本型への固執」(『リファクタリング』)は本当に、最悪の病理だ。汚染はあっという間に拡がる。PHPは特に。
     アクティブレコードにするかどうかはなんでもいいけど、とにかく連想配列は撲滅しておいたほうがいい。
  • 高級なファクトリー機構は使わない
     フレームワークが、オブジェクトを生成するためのファクトリー機構を用意しているかもしれない。
     名前を文字列で渡すと対応するオブジェクトが作られるとか(……まあ、こんなアホな仕組みをなぜ作っちゃうのか知らないけど)。
     実際のところ、よほどよくできたメンバーが集まっていない限り、そういうのは結果的に無視されることになる。みんなわりと、newと書きたがる。
     本当にnewと書かせたくないのなら、newできない仕組みを組みこまなければならないだろう。

 あとは、たぶん自作じゃないと組みこまれていないけど必要なからくりを作る。

  • 本番環境用と開発環境用、二つの設定ファイル置き場(ディレクトリ)を作る
     本番環境用の設定行をコメントアウトしてその下に開発環境用の設定を書くとか、なんであえてそんなリスクを犯すの?という話だ。
     はじめから分けておき、$_SERVERかなにかを見て、自動的にディレクトリを差し替える仕組みを作っておく。
  • 設定ファイルは細かく分ける
     何百行もある設定ファイルとか。管理できると思うほうがどうかしてる。
     そういうのはすぐに「使わなくなったけど怖くて消せない設定」が溜まっていくことになる。
     DB用ならDB用と、できる限り細かく分割する。そうすれば、影響範囲が特定しやすいから、あとで不要になったときに消せる。いややっぱり怖くて消せないかもしれないけど、可能性があるだけマシ。
     もちろん、グローバルスコープも定数も使わない。static変数またはクラス定数だけを書いたクラスになるだろう。ほんとにconst1行しか書いてないクラスとかでいいから、細かく細かく分けるべき。いくら細かくしても、あとでどうせ勝手に追加されて大きくなっていくんだし。
     .iniファイルとかXMLとかでもいいけど、あまり高級なものをつかうと、不具合が出たときに疑う対象が増えてしまう。かえって手間になる。コアな部分ほどシンプルな実装を採用したほうがいいと思う。
     高級なフレームワークを敬遠する理由は、そういうところにもある。
  • テストコード置き場を作る
     リリース用のファイルとテストコードが同じ場所に混在しているとか、それこそ管理できるはずがない。
     リリースのときには消さなきゃならないわけだから、プロジェクトリーダーにとっては、そういうのも管理対象に含まれているんである。
     というわけで、テストコード専用のディレクトリをはじめから作っておく。
     とはいえ、置き場を作ったとしても、そこを使ってくれるのは理解のある少数だけかもしれない。それがしょうじきなところだ。だけどそれでも、ないよりはマシなのだ。
  • バックアップのとりかたを考えておく
     ソースのバックアップはできるだけ毎日とる。
     これはあとで戻せるようにするためじゃなくて「いつでも戻せるから」と宣言するため。ソース中にコメントアウトを残すとか、そういう愚かな行為をさせないためにバックアップをとるんである。
     SVNを使うとか、いろいろやれることはあると思う。

 ようするに、開発メンバーはつねに予想以上にフリーダムだ。でも、それでもプロジェクトリーダーは管理しなければならない。開発前に手間を減らす工夫をしておかなければ大変なことになる。
 有名なフレームワークをダウンロードしてきて使うのは、もちろんいい。けど、それで手間が増えてしまうくらいなら、簡単なものを自作したほうがいい。
 けっこう、できの悪いフレームワークがあったりするし。
 機能を限定したライブラリじゃなくてフレームワークの開発ばかりが盛んなところが、PHPの現状をよくあらわしている。つまり、けっきょくどう使っていいのかが決まっていないんである。
 いわゆるアーキテクトたちにとっては、腕の見せどころ!といえなくもない。
 じつは、そこらのJavaだの.NETだのの開発よりもよほど、高い技術力を持ったアーキテクトの存在を必要としてる。
 しかし、PHPはどうもバカにされる言語なので。技術力に見あう報酬は約束できませんがねー。


2009/07/14 00:23

オアシス
 ボードゲーム

2009/07/14 00:23 てらしま
オアシス
OASIS
2004年
Amigo
Alan R.Moon & Aaron Weissblum
3~5人(4人)
60分
thx to play:game
amazon

 傑作と呼ばれることがあるゲームだけど、やったことなかった。最近やったのだけど、たしかにおもしろい。
 陣取りゲームなのだけど、いろんなところに細かい工夫がなされている。
 舞台はゴビ砂漠らしい。砂漠の民族の一員となり、広い土地と財産を手に入れる。

 まず、自分のデッキからカードをめくる。1枚だけでもいいし、たくさんめくってもいい。めくる枚数が少ないほど、デッキに補充できるカードが多くなる。
 これを全員がやる。全員の前に、数枚ずつのカードが提示される。
 各プレイヤーは、地位タイルというモノを持っている。この地位タイルには、プレイ順を表す数字が書かれている。この順番にしたがい「自分以外のプレイヤーが提示したカード」をとっていく。
 そうしたら、自分の地位タイルをその相手に渡す。つまり、1番に選ばれたら、次のラウンドで1番になれる。
 もちろん、1番は選択肢が多いから、有利だ。しかもそれに加え、タイルを1枚追加で配置できるという特権までついてくる。この1番タイルは「族長」と呼ばれる。
 つまり、できるだけたくさんの贈り物を提示したほうがいい。けれどもちろん、贈り物をしすぎれば財産を失う。財産というのは、各自に与えられているデッキのこと。贈り物の枚数が少ないほどデッキの補充枚数が多いというルールだから、毎ターン多くの贈り物を出し続けることはできない。

 この提示したカードには「贈り物」という名前がつけられている。贈り物をできるだけたくさんすると高い名誉を得られる、というどこかの民族の風習を思い起こさせる。
「ポトラッチ」とかいったかと思うけど、あれはアメリカ大陸の話だった。ゴビ砂漠にそんな風習あったのかどうか知らない。

 このあたりの贈り物ルールがまずおもしろい。
 無駄がなくよくできているし。族長になるためにたくさんめくるのか、このラウンドは我慢するのか。選択肢はどうせ「もう一枚めくるかどうか」くらいのものなんだけど、これが楽しい。

 さてしかし、陣取りゲームなのである。ボードにはたくさんのマスが描かれている。そこに置くタイルもたくさん入っている。

 贈り物でもらったカードには、なにか絵が描かれている。そこに描かれているモノをもらえるんである。
 地形タイルをもらったら、それをボード上に置く。「自分の土地」はかたまり4つまでしか主張できないから、地形タイルは、すでに置いた地形タイルのとなりにつなげて置いていくことになる。
 そうやって、自分の土地が増えていく。
 しかし、それだけでは得点にならない。各地形に対応する「得点マーカー」が必要になる。
 ゲーム終了時の得点計算方法は、基本的に「土地の数×対応する得点マーカーの数」だ。
 ボードを横切るシルクロードに配置できる「ラクダ」なんてのもあるけど、これも得点方法は地形タイルと似たようなもの。
 陣取りではあるし、土地はたくさん持っていたほうがいい。でも土地だけではダメ。というか、得点マーカーがなければゼロ点だ。

 これ、若干、直感に反していると思う。カタンで不毛な最長交易路合戦が起こってしまうような現象が、このゲームでも起こりそうだ。
 なにしろ、盤面の土地は他人と競っているわけでもあるし。つい熱くなってしまいそうだ。
 けれど、じつは土地は、得点マーカーと等価値なんである。
 効率のいいとりかたは決まっていて。「土地と得点マーカーを同数ずつ集める」が正解だ。ゲームボードから受ける直感よりも、じっさいの得点マーカーの価値が高いという気がする。
 ちなみに同じ理屈で、ドミニオン:陰謀のカード「公爵」の適正枚数もわかる。公爵の適正枚数は、つねに「公領の枚数マイナス3または4枚」である。
 これは考えれば誰でもわかることだけど、逆にいえば、少しだけ考えなければわからない。
 ドミニオンはそういうのを考えるゲームだからそれでいいが、こういう陣取りゲームに適したルールかというと微妙かもしれない。というような気も、少しする。
 まあしかし、それは知っている人が最初にいえばいいだろう。
 じっさいはもちろん、そんなに都合よくいくわけではない。陣取りなのはたしかだから、まだ得点がないとわかっていても土地を広げる選択だって、もちろんある。

 あと、直感に反するかもしれない点がもうひとつ。
 たとえば「岩場」という地形タイルが10個あるとき。岩場に対応する得点マーカー1個の価値は10点だ。たとえば、2個ある「草原」に対応する得点マーカー4個よりも高い。
 自然と、できるだけ1色でまとめていくことになる。そのほうが得点が高いんである。
 数字で考えれば明確に、自分にとって高得点な選択肢が見つかる。だが、印象のみでプレイしていると間違える。
 数字を意識してプレイするプレイヤーは、じつはそれほど多数派ではない。このゲームは、数字を考えたほうが明確に有利。だから、はっきりと優劣が生まれてしまう可能性が高いと思う。
 そのあたりは、インストするときに説明してしまったほうがいいのかもしれない、などとも思う。

 地形やラクダにはそれぞれ、配置ルールに特色がある。そのあたりのルールは若干細かいけど、どれもわかりやすいから心配するほどではない。
 地形タイルをどこに置くかの選択が、これまた楽しい。
「このへんか?」「いやとなりかも」みたいな、序盤は囲碁のようなおもしろさがある。じっさい、最初に置いたタイルからはつなげて広げていかなければならないわけだから。他のプレイヤーが飛びこんできづらいようにとか、いろいろ考えたくなるんである。
 陣取りゲームのおもしろさだ。

 贈り物ルールも、陣取りも、どちらもやっていて楽しい。たしかに傑作だ。

cut4.jpg

2009/07/13 02:26

片目の海賊
 ボードゲーム

2009/07/13 02:09 てらしま
片目の海賊
Einauge sei wachsam!
2009年
Amigo
Wolfgang Kramer
Michael Kiesling
2~5人(4~5人)
45分
thx to play:game
amazon

 なんか小品っぽい箱とタイトル。海賊というテーマも、地味な佳作みたいなゲームをイメージしてしまう。なんか食指が動かない。なんか。
 でも、そんなわたしの勝手なイメージとは裏腹に、これはおもしろい。システムもいちいち「なるほど」と思わされるし。さすがのクラマー&キースリング。

 とりあえず、やることは「島カード」を買うこと。場に6枚出ていて、値段が書いてあるのでそれを買う。
 買うと、そこに書かれたモノがもらえる。剣と、お金と、宝石だ。
 プレイヤーたちはもちろん海賊なんだけど、それとは別に「片目の海賊」という敵がいる。らしい。片目の海賊も島カードを持っていて、そのカードを奪うためにはカトラスを持って戦わなければならない。というわけで、剣はそれに使う。
 ターンにやることは「島カードの購入」「(剣があれば)片目の海賊が持つ島カードを奪う」というあたり。
 お金は島カードを買うため。カトラスも島カードを買うためだけど、購入と別にやれるから、たくさん持っているとよりたくさんの島カードをとれる。
 ゲームの目的は、宝石をたくさん集めることだ。

 で、すごく感心したのは、同じ色のカードを獲得したときのルール。
 すでに同じ色を持っているカードを獲得したときは、「すべてのその色のカードに書かれている資源を獲得」する。
 前回剣を獲得したのなら、今回は、新たに獲得したカードの資源に加えて剣を獲得できる。何気に拡大再生産ゲームなのである。
 シンプルでわかりやすいし、ゲームに無用なステップを増やしていないし。たしかに拡大再生産を実現しているけど、カードを獲得したときにしか効果がないから、差がつきすぎることはない。これは見事なルールだなあと思った。

片目の海賊 カードにはもうひとつ、宝箱も書かれている。これで、登場するリソースは4つだ。
 お金は、カードの購入に使う。剣は、片目の海賊と戦うために使う。宝石はそのまま得点。宝箱は、ゲーム終了時に各色で1位に7点、2位に4点が入る、いわゆる株券。
 各リソースの役割は明確すぎるほど明確だ。
 宝石で即時得点を目指すか、宝箱でゲーム終了時の大量得点を目指すか。お金で生産力を伸ばし高価なカードも買えるようにするか、剣で枚数を増やせるようにするか。
 最初にとったカードは、その後同じ色をとるたびに効果を発揮する。カードの種類は同じでも、宝石を先にとるか剣を先にとるかで意味がぜんぜん違う。
 つまりこれは、サンクトペテルブルグでいえば、職人と建物と貴族に対応する。アウグスブルグプエルトリコ、あとじつはストーンエイジなど、わたしがここで勝手に使っている(笑)用語でいえば「街系ゲーム」の王道といっていい。
 そういう種類のゲームなのである。
 そういうゲームは長時間ゲーム(最近の基準でいえば)になりがちだ。でも片目の海賊は、そうでもない。なにがすごいって、それがすごい。最近の流行の一派(?)である、いきすぎているくらいのシンプル指向に乗りながら、これをやってるというのがすごい。
 街系ゲームの要素をまとめて織りこんでおきながら、ここまでシンプルなルールとプレイ時間なのである。
 見た目よりすごいことやってる気がする。

 サンクトペテルブルグはすごく好きなゲームなんだけど、最近ああいうゲームはあまり見ていなかった気がする。それは「得点をとろうとしなければとれない」ゲーム性に原因があった気がしている。
 いつ得点をとりにいけばいいのかというのは、考えなければわからない。経験もものをいう。やりこんだプレイヤーや、同系列のゲームになれたプレイヤーに、初プレイの人は絶対勝てないのである。
 そこがおもしろい、というかそれこそがゲームだとも思うけど。カジュアルプレイの場やファミリー向けには向かない。
 また、プレイヤーがどれだけ考えるかわからない。考えれば考えるだけ成果があるからだ。だから、プレイ時間が確定できない。
 片目の海賊も、あるていどはそう。考えなければ勝てないだろう。でも、はじめからカードでバランスがとられているから、漫然とやってもそれなりにプレイできる。そういうふうにできていると思う。
 その中で「俺は宝石を集める!」という意志を示したり、2位狙いで宝箱をとったり、いろいろなプレイができたりもする。
 何気にすごいと思う。おもしろい。

cut4.jpg

FrontPageを



Copyright © 2001-2024 てらしま(terrasima @gmail.com)