TRPGでPvP？

元ネタはこちら
https://twitter.com/tokutomohide/status/1184753614012567553

TRPGって興味深いなぁ～と思うモノの一つがPvP。ボードゲームやカードゲームでのPvPはいいのにTRPGはダメって人も多いと思う。
あれってなんでなんだろうねぇ。

とりあえず定義として
PvP
https://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AC%E3%82%A4%E3%83%A4%E3%83%BC%E5%AF%BE%E3%83%97%E3%83%AC%E3%82%A4%E3%83%A4%E3%83%BC

2人以上の（人間）プレイヤー同士で行われるゲーム内戦闘

としておく。
……「プレイヤーじゃなくてキャラクタだろ？」って突っ込みは、一端おいといて*1。
「キャラクタ同士が、手をつなぎ合って協力するのではなく、敵対して場合によっては相手を殺害するまでを視野に入れた行動を取る」くらいの感じ、を想定。

おいちゃん的には
・システムとメンツによる
ってのが最終的な見解なんだけど、つまり「システムとメンツでいくつかの条件がそろった時はOK、それ以外はNG」って考える事が多いかなぁ。

PvPの場合、多くの場合において「勝ち負け」が発生して、勝ったほうはいいんだけど、負けたほうに禍根が残りやすいので。
また、どちらかというとTRPGは「勝敗を決める」ゲームであるというよりは「協力してナニかを行う」と考えている人のほうが多いと思うので……それはつまり「誰も負けない」を、想定したり想起したり前提にしていたりする、事が多いので。
主に敗者に対する「なんらかの配慮」がない限り、PvPは「事故につながる可能性が高かったり、一因になったりしうる」ので。

その辺りから「一定の前提条件が満たせている環境」以外では、PvPは「禁止、NG、御法度」と言われることは、少なからずあると思うし、おいちゃんもそれにはtrueを感じるかなぁ、と。

かみ砕いて。
まず、システム的に「ほぼNGであろう」と思われるTopが、D&D系列。
あれでPvPとかされてもメインのダンジョンがほぼ攻略できないと思われるので、チガウと思う。

それ以外だと……後は「メンツによる」んだけど、(ライト)ファンタジー系なんかは、比較的「条件のそろうメンツが集まりにくい」ので、割と忌避する可能性が高いかなぁ。
……いやまぁGURPS ルナルで「ド派手なセッション」もやったから、「無理」とは言わんが(笑

普段おいちゃんがやる*2システムだと。

・深淵：普通に発生しうる
・シャドウラン(第2版)：普通に発生しうる
・ヴァンパイア:ザ・マスカレード：普通に発生しうる
・ソードワールドRPG(文庫版/完全版)：滅多にない
・GURPS ルナル：滅多にない
・央華封神RPG：ない

こんな感じ、かなぁ。

内訳。

・深淵：普通に発生しうる
おいちゃん、いわゆる昨今の言い方だと「渦型」と呼ばれる類いのセッションが好き*3なのと。
テンプレートは「全部OK」なので。
……「白馬を連れた娘」と「奇妙な旅人」とか1パーティにいたら、大概、以下略、でしょ？(笑
その辺は「選んだテンプレートによっては起きうる」事を前提に「それがOKな人」って募集をするかなぁ。基本。

・シャドウラン(第2版)：普通に発生しうる
「仲間、と呼ばれる人達が、信用できるんならチームカルマも差し上げますし、チーム組んで頂いてよいですよ」って発言をする(笑
なお、情報は基本「全部伏せて、紙に書いて個人に手渡し」をする、ので。……特においちゃんが望んでいる訳ではないが*4、情報を隠したりごまかしたりバミったり詐欺ったり、色々(笑
勿論「組める相手とは組む」ものですが、同時に「組むに足らない相手であれば食らう」事も、ちょいちょいと拝見したり拝聴したり拝聞したり(笑
その結果としてのPvPは、そりゃ「あり得るよねぇ」と、しか。

・ヴァンパイア:ザ・マスカレード：普通に発生しうる
クランにもよるし立ち位置にもよるのですが。状況によっては「PvPも起きうる」よねぇ、と。時々、真っ二つに割れますしｗ
まぁ「PvPしてる余裕がない」事も往々にあるので*5、「PvPの前にまず保身」って流れでPvPがお流れになる……事もあるし「保身のために仲間を売る」事も、ほら、ねぇ(笑

・ソードワールドRPG(文庫版/完全版)：滅多にない
たま～～に「PvPがおきそうな」シナリオも組みますが。
どちらかというと「みんなで仲良く協力して」のほうがシナリオ的にもシステム的にも組みやすいので、滅多にやりませぬ。

・GURPS ルナル：滅多にない
身内の「500cpセッション」とかいう機知外セッションは除外して。
通常、コンベでやるような時だと「穏当に」組むので、PvPは想定してないですねぇ。

・央華封神RPG：ない
システム的に「悪いことをしたら落ちる」ので、やらない、し、基本「極めてやりにくい」と思う。

こんな感じ。
………うんシステムが悪いよねぇおいちゃんは悪くない*6。

で。
PvPが「出来うる」システムにおいて、後は「メンツ次第」。

まず
・キャラクターとプレイヤーの分離が出来ないタイプがいたら、NG(やらない/やらせない)
ここは絶対。それが出来ない人は、PvPは間違いなく「止めたほうがいい」。

そこを前提にして、あと最低限としては
・PvPをしかけるからには、自分のキャラクタが殺される覚悟がある
事が、必須。「自分は仕掛けるけど他人が仕掛けてきたら怒る」タイプは、やっぱり駄目。

で、あとは
・それなりに理由とか筋とかがあるPvPをする事
ってのが、以外と外せないライン。
「ボクのキャラクタは通り魔のように発作的に無差別に人を殺します」ってキャラにしたら、まずそもそも「今ここにいるかどうか？(捕まってないかどうか？)」で1ハードルあるし、さらに「そんなキャラであれば警察機構含めてあちこちから警戒されているであろうからほぼ確実に動向は見張られてるよねぇ」って話しになるので、多分、セッションは困難だと思う。
そんな風に「なぜ、その対象とPvPしたいのか？」について、相応に筋と理由が通せないと、PvPは厳しいのではないかしらん。

最後に
・卓の全員が「PvPあり、でよい」って合意が取れること
が、重要。まぁ「マスターがPvPありきって今日は考えてる」んならマスター紹介でそのように言うけど(それで入ってきて「PvPはイヤだ」言われてもさすがに知らん)。
そうでない場合は「卓の全員の合意」が取れない限り、原則として認めないかなぁ。TRPGは「みんなで楽しむ遊び」だから。

この辺の条件が満たせるのが、下限。
……ただまぁ「PvPをやりたい」って人の何割かが、ここに引っかかったりするので、色々と難しい。

後は、出来うる限り望ましいのが

・演出がちゃんと出来ること
これは「PvPそのものの演出」だけではなくて「いつ、そのキャラクタを屠るか」のタイミングとか、その辺を含めて。
やっぱり理想は「クライマックスで殺る」が、一番、楽しいよねぇ(笑
後は「戦闘はするけど逃がす」とか*7。
そういった「相手の事もちゃんと配慮する」行動が、TRPGを楽しくする秘訣だと思うの。

………まぁ書いていてなんだけど、結構山盛りの前提条件が必要なんだよねぇPvPをやろうとすると。
で、「見知った、気心の知れたメンツ」でやると、勿論それは「とても楽しいひととき」になる可能性、が、山盛りであるんだけど。
そうでない場合、これだけの前提条件を「初対面*8」でどれくらい満たせるか？ ってのが、ちょっと厳しいかなぁ、と。
「わかっているつもりだったけどいざ自分のPCが殺されたら実は理解してなくて納得してなかったでござる」とかも、あるしねぇ。

という感じなので。
「(PvPが)TRPGはダメって人も多い」のは、そんな辺りが、理由の一つなのではないかなぁ？ と、おいちゃんは愚考してみたり。

「あんた、コンベでちょいちょいやってるじゃん*9」とか言うなちゃんと色々配慮はしてるんだ(笑
まぁ「PvPありあり」って言って、本当にPvPに発展するの、半分以下くらいの確率だしねぇ。基本的には「PvPしている暇を与えない」ので、皆さん、生き残る事に必死でいらっしゃいますしｗｗｗ

……なんて話しをツイッターで書こうかと思ったのですが割と長文になったのと「せっかくだし残しておくかねぇ」と思ったので、雑文を、ちょろりと。

*1:本当に「プレイヤーvsプレイヤー」なら、それは警察案件になるので(笑

*2:……やる、って言わせてくれ……まだやる気は山盛りであるんだ orz

*3:というかそれしかやらない

*4:アジテーターはこういう物言いをするよねぇｗ

*5:by おいちゃんのセッション

*6:責任転嫁

*7:その後は、嬉し恥ずかし 敵対関係ｗ

*8:コンベだと、初対面さん多いよね

*9:おいちゃんがマスター

日付関連の小ネタ

片や。
PHPでstrotimeは割とよく使われる関数かなぁ、と思います(DateTimeクラスのコンストラクタに渡す引数、と読み替えてもよいです)。

片や。
善し悪しはとりあえず置いておくとしまして、MySQLを使っていると「0000-00-00」というブツが出てくることは、まぁ時々*1、あります。

んで。

<?php

$t = strtotime('0000-00-00');
var_dump($t);
echo date(DATE_ATOM, $t), "\n";
echo "\n";

$t = strtotime('0000-00-00 00:00:00');
var_dump($t);
echo date(DATE_ATOM, $t), "\n";
echo "\n";

$date = new \DateTime('0000-00-00');
echo $date->format(\DateTime::ATOM), "\n";

それを食わせてみると

int(-62170016400)
-0001-11-30T00:00:00+09:00

int(-62170016400)
-0001-11-30T00:00:00+09:00

-0001-11-30T00:00:00+09:00

なんとも味わい深い出力が得られるんですねぇ……エラー時、strtotimeならfalse、DateTimeなら例外を出して頂ける事を期待するんですが、その辺も特に出てこない orz

ちょっと(ある意味)興味深い事例だったので、めも。
………お願いすなおにエラーにして orz

*1:しょっちゅう？

リファクタリングとリメイクのあいだ

リファクタリングは、乱暴に言ってしまうと「大改造!!劇的ビフォーアフター」だよ、とかよく説明をします。
多分そんなに間違ってないんじゃないかなぁ。

で、安心したリファクタのためにはやはりテストが重要で。
なのでもしテストコードがないコードをリファクタする時は、「まず先にテストコードを、ある程度しっかり書いておく」と、安全に安心にリファクタをする事ができると思うんですね。

まぁ勿論、テストを書いている時点で「通常は気づかない、微細な(仕様を含む)バグ」が新たに見つかる事もあり、それはそれで「リファクタをして良かったよねぇ」のONE PIECEになるのではないか、と思います。

………で。
リファクタと称される案件にお会いした時に、時々、ごくまれに、僅かながら、全くないとは言えない程度に極小の確率で*1、遭遇するのが。
・リファクタをしたい
・テストを書きたい
・テストを書くために「現在の仕様」を理解したい
・現在の仕様が「誰にもわからない」
・だからといって「動いているコードが正解」とも言いにくいほどにあちこちに綻びがある*2

……さて。リファクタとは？

多分ここが分岐点で。
・多少綻びがあるにしても「仕様」がある程度明らかであるなら、リファクタリング
・そもそも「仕様ってなに？」状態だと、リファクタにはなり得ず、結果的にリメイク

ってのが、なんとなく「リファクタリングとリメイクのあいだ」なんじゃないかなぁ、と。

…………書いてて血ぃ吐きそうですが orz

*1:つまりしょっちゅう

*2:契約を管理するシステムで「入力した情報(PDF出力では使っている)の半分以上がDBに保存されず揮発する」システムが正常だとは、あんまり思えないんですよねぇ……(実話 orz)

仮想世界のお金のお話

今となっては割と普通になってきた感のある「なんで人はがちゃで散財をするのか？(極論)」というお話ですが。
比較的初期の頃に、この手のお話を大変に丁寧に書かれたこの書籍を、今日は紹介。

人はなぜ形のないものを買うのか

一方で「経済学の准教授」という側面と、もう一方で「かなりギリギリのゲーム廃人」という側面が大変にナイスに融合した、素晴らしい論調の内容です(笑

ただ、ものすごく残念な事に、書かれている方はすでにお亡くなりになっています。
gallu.hatenadiary.jp

この本も「一読の価値はまちがいなくある」ので。
残念ながら、電子書籍になっていない上に新刊がないので中古オンリーになってしまいますが、是非、手に取って読んでみてください。

成功もいいけど、失敗もね

失敗学、ってぇのがありまして、端的には「失敗に学ぼう」というものでございます。
成功は、とかく「運や偶然やまぐれ」が介在しやすいのと、また成功した時に「どこが本当の"成功の要因"だったか」の検証は、なかなかに難しいものなのですが。

一方で失敗は「これをやったら、運がよっぽどヨクナイ限りは同じような目に遭うよねぇ」と考えやすく、他人の失敗から学ぶのは、とても大切なものでございます。

この手のお話で、まずトップに出てくるのがこちら。

失敗の本質―日本軍の組織論的研究 (中公文庫)

よい書籍……なのですが、幾分、読みにくさでも定評が以下略。
なので、

「超」入門 失敗の本質 日本軍と現代日本に共通する23の組織的ジレンマ

こちらを読んでおくと、大変に読みやすいかと思います。

また、失敗学自体について、読みやすい書籍を1～2冊読んでおくとよいか、と思います。
「これでなければ」ではないのですが、おいちゃんの手元にはこれがあり、そこそこ読みやすかったと思います。

失敗学 (図解雑学)

また、同じ方が書いているこの書籍も面白かったので、合わせて。

失敗学実践講義 文庫増補版 (講談社文庫)

こういった「失敗」という切り口をどれくらい活用できるか？ は、割と死活問題な気がするんですよねぇ。

プロジェクトはマネジメントしませんと、されませんと

プロマネのスキルは。
勿論「プロマネになりたい」のであれば必要なのですが、「がっつり現場でがりごりとプログラム書きたい」人も、最低限くらいは踏まえておいたほうがよい、と思われるスキルでございます。

世界一わかりやすいプロジェクトマネジメント 第4版

「世界一わかりやすい」かどうかは知りませんが、読みやすくわかりやすい書籍だと思われます。
一つポイントなのは「実はこの本、"プロジェクトマネジメントの本"ではあるけれども"システム系のプロジェクトマネジメントの本"ではない」、って所。
読んでて9割がた普通に「あるある」な内容なので結構気づきにくいのですが、実はこの本「プロジェクトマネジメントの本」なので、別に「システム開発用」ではないんですよね。
どこも「同じような感じなんだなぁ」ってのを、切実に感じるところでございます。

もう一つ。
PMBOKはやっておいたほうが良いと思う、ってんで、この本をよく勧めます。

プロジェクトマネジメント標準 PMBOK入門: PMBOK 第6版対応版

割合とあっさりと読めるので、入り口用にオススメです。

PMBOKもまぁ色々と「……ちょっと」とか言われたりすることもあるみたいですが、それは「PMBOKをちゃんと踏まえたその先」のお話なので。
まずこの辺くらいは、しっかりと踏まえておきたいものでございます。

ドラッカー……を、ちょっと手加減して

一度は読んでおきたいドラッカー。
ただ、いきなり「マネジメント」から行くと少々歯ごたえがあるので。

図解で学ぶ ドラッカー入門

いや別にこの本でなくてもよいのですが、いわゆる「入門」とか「初心者向け」とか「ｎ日でわかる」とか「図解」とか、その手の「敷居の低い本」を読んでから本編(マネジメントとか)に行くと挫折しにくいので、オススメでございます。
ちな、「とりあえず入門書だけ読む」のであれば、「異なる著者の初心者本を、2～3冊」ってのをオススメしておりますので、合わせて覚えておいてもらえれば。

その後ですが、「実践するドラッカー」シリーズを読んでみると、割と「身近なお話」になりやすいので、身になりやすいか、と。

実践するドラッカー【行動編】

実践するドラッカー【チーム編】

とりあえずこの2冊を紹介しました。