やはり佐藤四段は胸中穏やかではなかったというか、本当に大変な状態だったんだなあ。そんな中で最終的には山本さんときちんと協力して、ponanzaの最善手に従うのではなく読みの絞り込みをさせて判断するという、森内名人が解説中に語っていた方法論に行き着いたのはやっぱり凄い。
その後の自戦記も必読。指し筋がちぐはぐになった背景とか、『「コンピューターは頓死しないですよね？」って聞いたら「いやぁ。ポナは結構頓死するんですよ（笑）」』のくだりとか、ponanzaと初めて気があった瞬間とか、対局の裏側が綴られていてとても面白い。あとはコンピューター将棋の特徴というか、判断力とか盤面の捉え方とかの差が垣間見えてくるのが興味深い。こりゃ三浦九段&GPS将棋の解説も楽しみだ。
追記: 三浦九段&GPS戦の解説がきた。
実は三浦九段も自分の手で局面を大きく動かしてあの優位を築いていたのか。そして最後の方は相談というよりも覚悟を決めるための話し合いだったのか。そしてそれを佐藤&ponanzaタッグが両者ともに見逃していて、そこでチームとしての負けを一旦認めたことで心が晴れて行ったというくだりが本当に胸を打つ。
新・世界樹の迷宮やってて中断していたドンキーコングリターンズ 3Dをクリアしたんだが、なんつーか良いか悪いかで言えば間違いなく良いんだけど、でもこれ絶賛するにはあまりにもアクションゲームとして終わってる部分が目につきすぎる。以下は流石にこれはダメだと思う所。
異様に慣性のキツい操作性とかやたらめったらキャラが滑る所はバランス調整の範疇だし、その点はまあ好き好きだろうと思うので、俺はまったく好ましく思わんがその点は客観的な原点材料ではないかなあと思う。でも上記の部分は流石に気付いてくれ、任天堂だろうと思ってしまうのも事実。
通常のステージはそこそこの難度なのに対して強制スクロール面、特にロケットに乗って進むステージが異様に難しいのも気にかかる所。ラスボスはそのロケットに乗っての強制スクロールの前半→ラスボスという流れなのだが、前半で二桁回数死んだ後にラスボス初見撃破は流石にちょっとアレだった。
ボロボロと手に入るバナナコインで1UPをゴッソリ買い込み、ガンガン死につつステージギミックを突破していくというゲームデザインはとても良いと思うんだけどねえ。
Catyには一応クラスシステムがあるが、OOPLのそれとは違ってどっちかっつーとモジュールに近い役割だ。それじゃなんで既にモジュールがあるのにクラスを用意したのかというと、それは物理的なファイルに束縛されるモジュールよりはクラスの方が演算に使う上で便利だからだ。(これは結果論に近いが、歴史的経緯を書き連ねると長い上に面白くない。)
Catyのクラスには継承という概念はなく、代わりにクラス同士の&演算がある。
class A = {
command hello :: void -> string {
"hello"
};
};
class B = {
command bye :: void -> string {
"bye"
};
};
class C = A & B; // hello と byeを持ったクラスになる。
class D = B & C; // 両辺を入れ替えても同じ。
class E = A & C; // helloがバッティングするのでエラー。
これは型同士の&演算とほぼ同じで、例えば指数型(X->Y)を導入したとすれば、大体以下の型定義及び演算と同じ。
type A = {
"hello": boid -> string,
*: any?,
};
type B = {
"bye": boid -> string,
*: any?,
};
type C = A & B;
&演算は両辺の共通項を取り出す演算なので、直観的にはクラスやオブジェクトの定義を狭める機能になる。それで新たなプロパティを定義可能なのは一見不思議だが、この例では未知のプロパティ全てが&演算における単位元として扱われているので、「単位元&具体的なプロパティ」が延々と計算されている。つまり結果的に範囲を狭めているのであり、またクラスはデフォルトでオープンなので前述の演算が成立する。(厳密には違うというか指数型同士の&演算の困難について書いていないのでこの説明は適当なのだが、まあ概ねこんな感じで捉える事にしている。)
これを利用することで実用上はほぼモジュール同士の演算のような事が可能になり、これはProgramming in the largeのaggrigation演算なのだ……ということらしい。まだ元の論文とか読んでないのでわからん。しかしCatyScriptはスキーマ含めても極めて小さな言語だと思うが、内部的には相当複雑になってきた。
今回面倒なので書かなかったこと:
最後にとあるクラス群をサンプル代わりに置いておく。いやこれ書いたの檜山さんなんだが、これがまともに動かないせいでいくつかの極めてクリティカルなバグが発見され、さらにその全てが直すのにゲロ吐きそうになる代物だった。
module aa-walker;
/*
# Forward 線形順序を順方向のみに辿る
# Backward 線形順序を逆方向方のみに辿る
# Linear 線形順序を両方向方に辿る
# Random ランダムにレコードを選ぶ。同じレコードを何度も辿るかも知れない。
統計的には全数列挙可能でなくてはならない。
# Enum 同じレコードを二度は辿らない。順序がどうなるかは何も保証されない。
# Tree ツリーに対する自由な移動を提供する。
*/
/** ウォーカー一般
*/
@[multi-hidden]
signature Walker<Input> =
{
/** ウォーカーの使用をやめる
* 後始末がされ、サーバー側資源は開放される。
*/
command w-close :: Input -> any?;
};
/** 線形順序マップを順方向のみに辿るウォーカー
*/
@[multi-hidden]
signature ForwardWalker<ForwardWalkerInput, ForwardWalkerOutput>
conforms Walker<ForwardWalkerInput>
=
{
/** ウォーカー開始 */
command w-forward-start :: void -> ForwardWalkerOutput;
/** 次の位置に移動 */
command w-next :: ForwardWalkerInput -> ForwardWalkerOutput;
/** 先頭位置に移動 */
command w-first :: ForwardWalkerInput -> ForwardWalkerOutput;
};
/** 線形順序マップを逆方向方のみに辿るウォーカー
*/
@[multi-hidden]
signature BackwardWalker<BackwardWalkerInput, BackwardWalkerOutput>
conforms Walker<BackwardWalkerInput>
=
{
/** ウォーカー開始 */
command w-backward-start :: void -> BackwardWalkerOutput;
/** 前の位置に移動 */
command w-prev :: BackwardWalkerInput -> BackwardWalkerOutput;
/** 末尾位置に移動 */
command w-last :: BackwardWalkerInput -> BackwardWalkerOutput;
};
/** 線形順序マップを両方向方に辿るウォーカー
*/
@[multi-hidden]
signature LinearWalker<LinearWalkerInput, LinearWalkerOutput>
=
use(w-next, w-first)ForwardWalker<LinearWalkerInput, LinearWalkerOutput>
&
use(w-prev, w-last) BackwardWalker<LinearWalkerInput, LinearWalkerOutput>
&
{
/** ウォーカー開始 */
command w-linear-start :: void -> LinearWalkerOutput;
}
;
/** ツリー形状マップに対する自由な移動を提供するウォーカー
*/
@[multi-hidden]
signature TreeWalker<TreeWalkerInput, TreeWalkerOutput>
=
unuse(w-linear-start)LinearWalker<TreeWalkerInput, TreeWalkerOutput>
&
{
/** ウォーカー開始 */
command w-tree-start :: void -> TreeWalkerOutput;
/** ルートノードに移動 */
command w-root :: TreeWalkerInput -> TreeWalkerOutput;
/** 親ノードに移動 */
command w-parent :: TreeWalkerInput -> TreeWalkerOutput;
/** 最初の子ノードに移動 */
command w-first-child :: TreeWalkerInput -> TreeWalkerOutput;
/** 最後のの子ノードに移動 */
command w-last-child :: TreeWalkerInput -> TreeWalkerOutput;
/** n番目の子ノードに移動 */
command w-nth-child [integer(minimum=1) n]:: TreeWalkerInput -> TreeWalkerOutput;
/** dレベル上の祖先ードに移動 */
command w-ancestor [integer d] ::TreeWalkerInput -> TreeWalkerOutput;
/** dレベル下の最初の子孫ードに移動 */
command w-first-descendant [integer d] :: TreeWalkerInput -> TreeWalkerOutput;
};
/** マップ内をランダムに移動するウォーカー
*/
@[multi-hidden]
signature RandomWalker<RandomWalkerInput, RandomWalkerOutput>
conforms Walker<RandomWalkerInput>
=
{
/** ウォーカー開始 */
command w-random-start :: void -> RandomWalkerOutput;
/** ランダムに移動 */
command w-move :: RandomWalkerInput -> RandomWalkerOutput;
};
/** マップのノードを列挙するウォーカー
*/
@[multi-hidden]
signature EnumWalker<EnumWalkerInput, EnumWalkerOutput>
conforms Walker<EnumWalkerInput>
=
{
/** ウォーカー開始 */
command w-enum-start :: void -> EnumWalkerOutput;
/** 一度訪れた位置以外に移動 */
command w-visit :: EnumWalkerInput -> EnumWalkerOutput;
};
もう散々いろんなとこで言及されてると思うけど、ロックマンシリーズに関わってた面子でもろロックマンなゲームが開発開始だと。これはカプコン怒るんじゃないのとか、でもカプコンはもうオールスターゲームとかにゲストで出す以外にロックマン作る気ないように思えるからなあとか、いろいろ複雑な心境ではある。でもきちんとロックマンの遺伝子を受け継いだゲームになってんならそれでいいかもとか思ってしまう。
意外とないんだよ、もろにロックマンなゲームって。例えばジャンプ中の制御にしたって、「慣性が殆どかからない」「十字キーの左右を離したら即座に横へのベクトルがゼロになる」「歩いてすぐジャンプとある程度歩いてジャンプで横へのベクトルが同じ」「ジャンプ高度が細かく制御できる」を全部満たしてるゲームは殆どなく、こういう無茶な挙動を前提としてロックマンシリーズ(特にX以降)はとんでもないアルゴリズムのボスを作れたりするんだよな。
他にはライフ+残機制で1ダメージのペナルティが非常に低いというのもシリーズの特徴で、これのおかげで多少のゴリ押しで「最初の1機で中間地点、次の1機でボスに到達、最後の1機でボス撃破」というクリアの流れが出来ている。だから場面場面の難度はクソ高いけどクリアするだけならそんなに大変ではないことが多く、一方でノーミスクリアのようなやり込みの熱さに繋がっている。これが魂斗羅なんかは完全に逆で、個々の場面はそこまで難しくないケースが多いがいかんせんミスしたら武器を落としてしまうので、ミスからのリカバリーが難しい。ロックマンっぽい事が一部で話題になったガンマンストーリーも、細部を見ると魂斗羅ルールだったりするし。
なので本家のシリーズが軒並み厳しい現状、しっかりした内容になってくれるならこれでもいいかなあと思わなくもない。……いや本当は無印とXとZXをきっちり完結させてくれと思っているのだが。
2020年東京オリンピックの開催が決まったが、なんつーか俺としてはどうでもいい。元からオリンピック自体に興味ないし。ただなんで東京が候補に名乗りを上げたかというのは結構疑問で、
実際問題良くわからん。まあ、これを機にエロ表現規制をしたいと思っているチンカス連中には朗報かもしれんが。
なのでまあ、本当にどうでもいい。
Linked Open Dataについてちょこちょこ調べているが、まあこれは以下のURIを見るのが手っ取り早い。
まず以下のようなものがLinked Dataとされている。
またCreative Commonsのようなライセンスの下で公開されたデータはLinked Open Dataと呼び、以下の5段階で格付けされるのだと。
最初3つはともかく、残り2つはなんだかなあ。最後の一つは別にスタンドアローンなデータをアグリゲートして関連付けるのをさらに他人が行ったっていいのでどうでもいいっちゃいいし、何よりいい加減RDFは諦めろよBerners-Lee。いや誰が何言っても諦めないとは思うが。しかしURIという中央集権的な機構に語彙が紐付けられ、さらに仕組みが複雑な割にできること自体は素朴なRDFはもういい加減忘れた方がいいんじゃないかな。
(どこまで書いていいのかわからんのでボカすが)とある方面では一般向けの情報公開の一環としてLODを推進という動きはあるそうなのだが、やはり語彙のコンセンサスが全然取れないという問題があるそうだ。ここら辺はologの方が明らかに優れた知識表現の手法だろうが、やはり標準技術という錦の御旗は相当強いようで。
最近Cookie Clickerなんてのが流行っていて、まあぶっちゃけ一過性のネタだろうとは思いつつ、意外と俺が放置系シミュレーションゲームと呼んでいる(箱庭系のぬるい奴だと思って良い)奴として結構面白い作りになっていて感心した。
一見単に見てくれのインパクトのみのネタゲーかと思いきや、ゲームの本質である「ルールを理解し、そのルール内での最適行動を探す」という部分はきちんと作られている。箱庭系シミュレーションに顕著な自分なりの目標を設定できるか、あるいは単にゲーム世界の発展を眺めているだけで楽しめる人でないと何が面白いのかさっぱりわからんところも同じではある。
エレキヴァイオリンはさっぱり上達していないのだが(まあそこまで練習してねえから当たり前)、しかしあの原始的な構造の木ペグはどうにかしてくれと思う。調べてみると「機械式にしたら音が悪くなった」だの、挙句の果てには「ギターも木ペグにしたら音が良くなった」だの出てくるのだが、それきちんとダブルブラインドテストしたのか?
仮に木ペグの方が音が良いとして(何を持って良いとするかという根本的な問題はこの際無視)、それでもビギナーの手にするようなエレキヴァイオリンそんな木ペグの音質に拘ってもしょうがねえだろ。それよか「そもそもチューニングできない」を解決してまともな音が出る方が重要でしょ。木ペグ使ったチューニングなんてある程度上達して、もっと高いクラフトマンシップのモデルを手にしてからでいいんじゃねえの?
じゃあ結局お前はどうしてんのかって? クリップ式チューナーをエレキヴァイオリンにくっつけてチューニングしてるに決まってる。そうじゃねえとチューニングの手間がかかりすぎるもの。
楽器やオーディオの世界では、ダブルブラインドテストや周波数特性などのデータが出されることは実際かなり稀に思える。これは何故かというのを俺なりに考えてみたが、
のどっちかあるいは両方なんだろうなあ、という結論にしかならん。いやだって客を騙すつもりがなかったら絶対にやるでしょ、ダブルブラインドテスト。
Epiphoneなんかは独自のロック機構を備えたブリッジのサステインに及ぼす影響のデータを公開していて、そこでは6弦はむしろサステインが落ちるけどプレーン弦は向上見たいな結果になっていて、そういうデータなんだよ俺が欲しいのは。できればデータの取得方法まできっちり書いて。
当たり前だろ馬鹿野郎。客を泥棒呼ばわりして買えるものも買えなくして、そんで売上が下がりましたって馬鹿じゃねえのか。
あとそもそも音楽業界が音楽をファッションあるいはファンアイテムとしてしか扱ってこなかったという側面も結構効いていると思っていて、前者が趣味の多様化で壊滅した後に残ったのは後者で、そりゃジャニーズとAKBでチャートが溢れかえるわけだ。本当なら音楽ジャーナリズムも含めてもっとまともな音楽文化を根付かせるべきだったのに。
あらゆる手段で音楽が売れる土壌をぶっ壊してんだから、そりゃ売れなくなるって。
まあ一方で世界的にCDが売れなくなってきたという話もあるのだが、逆にダウンロード・ストリーミング販売は伸びているはず。というか既にアメリカでもヨーロッパ諸国でもCDよりも有料配信の方が伸びつつあって、CDに収益を依存している日本とは逆のはず。
一方で日本ではダウンロード販売の売上が減少を続けているようだが、これはガラケーからスマートフォンへの移行が進んでいるのでガラケー向きの音楽コンテンツの売上が落ちていると考えるのが自然だろう。
AKB商法とかV系商法の類で見掛け上のCD売上は高い水準でも、商法が商法だけに普及率という点ではイマイチというのが実態ではないかな。