Guinea Pig 2nd

http://d.hatena.ne.jp/murishinai/ の続き。 https://note.com/shikatanai から移動する予定

あるゲーム開発の記録

 開発・運営していたモバイルのゲームが平成の終了と同時に終わった。社内からもすっかりその空気や記憶が消え、ほとぼりが冷めてきたこの時期に、ぼやき的な開発記録を書く。プログラマからの視点であり、全部うろ覚えで適当である。

開発に向けた経緯、あるいは地獄への入り口

 今から何年も前のこと。

 簡単に言うと石を売れるゲームを模索していた。しかしガチャの実装は不可能だった。理由は簡単で、ガチャというのは継続的に圧倒的な物量の供給があってこその販売戦略であって、そしてその膨大なアセットを適切に管理できてこそ可能な商売の手段であり、世の有象無象が過去を懐かしんで怨嗟とともに口汚く罵るよりもはるかに大変な事業なのである。開発規模が小さい自分のチームでその選択肢をとることは出来なかった。

 結局ない知恵を絞っても革新的なことが出来るわけもなく、時間回復のスタミナ的なところへの課金アイテム設定となった。一応なけなしのDLCというか追加要素もあったが、費用対効果として働くことが出来るだけの仕組みが用意できなかった。

 石を売ると言うことは、石をサーバで管理すると言うことである。クライアントの端末を信じるのであれば別にサーバを立てる必要はないのだが、そのような選択肢は最初から当然排除された。しかしこれが最初の壁となる。

 つまりモバイルゲームのためのサーバを運用した経験がないのである。そこで、サーバサイドを外注することになるのだが、このあたりで自分の力不足をかなり露呈させることになった。ある程度カスタマイズ可能な構成を発注したのであるが、最後までまとまりきらないセキュリティ要件や、自社の偉い人側の知識不足、あるいは自分のプレゼン力不足のせいで、良いものを発注できなかった。

上司へ新時代の常識が説明できない

 お金を扱うのであるので、もちろんサーバサイドというかデータベースはトランザクションが保証されなければならない。その一方で、どれだけユーザ数が増えたとしても安定したパフォーマンスで動作させねばならない。しかし、トランザクションを保証した(レガシーな)データベースへのやりとりは、その作りにも寄るが、ユーザ数の増大に伴って徐々に破綻していくものである。と言う、あちらが立てばこちらが立たないという話について、自社の中ではかなり議論が紛糾した。他にはセキュリティ要件についても同様にどこまでもガチガチに漏れない認証が求められたり、サーバの可用性というか、決してエラーを起こさず安定して動き続け、最終的には監視が不要である仕組みが求められた。少なくともオンプレミスではそれは実現できないであろう。

 とにかく、クラックなどの攻撃に無制限に強く、どのような大量アクセスにも挫けることはなく、そして一切のエラーが発生せず、全てのデータ操作は安全であり、そして応答性の早さを無邪気に要求された。これについても、本当に自分の力不足というか、現実的なラインにおける妥協と、緊急時における復旧方法についての理解を深めるべきであった。必要なのは竜を倒す方法ではなく、いかに味方は全滅しないかの説明であった。

 このあたりの頭の悪いやりとりについて、サーバサイドを担当してくれた外注会社はとても素晴らしい提案をしてくれたと今になって思う。

AWSへの入門

 おおむね以下の構成となった。

・EC2(ELB(MultiAZ) + AutoScaling) の多インスタンス構成。 ・web は nginx で受けて処理は RoR(unicorn) ・環境は Packer で構築し Terraform で管理する ・DynamoDB + SQS + SNS ・データのやりとりは、書き込みを SNS から SQS で詰んで、読み込みは直接。 ・SQS からの書き込み処理を常に行う Worker を EC2 に置く。 ・監視に Mackerel で通知先は Slack

 理解に時間をかけたのは DynamoDB で、当時は予約された分しか読み書きが保証されなかったため、大分肝を冷やしながらキャパシティの設定を手動でやっていた。今となっては自動で調整してくれるオプションがついたため、そちらに丸投げしている。

 どれだけユーザ規模が増えても耐えられること、そして極力メンテナンスフリーで、と言う要求に対して、ベストアンサーであったと思う。当時は Lambda がなく、サーバレスで関数単位の処理を任せることが出来なかったので、そこはやむなく EC2 でインスタンスを持つこととなった。

 当時も Aurora はなかったが、それにしても安易に RDS を選択しなかったのは本当に感謝しかない。シンプルな KVS であることと、スキーマレスで動的に内容を定義していけるのは本当に素晴らしい仕組みであった。一方で、自分の理解が追いつかず、パーティションキーとソートキーについて価値のある議論が出来なかったことは今でも悔やまれる。

……のように AWS への入門からやってしまったため、サーバが実際に何をするかについての議論について深く踏み込むことが出来なかった。月が落ちてくるような極端な心配は早く片付けて、何をして欲しいのかという所に尽力すべきであった。

 サーバーサイドではいくつかの定型機能を提案され、そして実装をお願いしたが、そのほとんどが使われることがなかった。必要なのは自由なカスタマイズ性と、いい感じに DynamoDB + SQS を Wrap してくれることであり、どのようなデータレイアウトであるべきか、あるいはテーブルの設計をするべきかを知らない我々は、本当に必要な機能を正しく予測することが出来なかった。

 最後の手段として、自由に記述できる、独自のクラスを動的に読み込んで実行する機能を提供してもらったが、結果としては実質この最後の手段がメインの戦力・サーバの価値となってしまっている。発注仕様はこの部分を掘り下げるべきであった。

いつも通りの開発

 外注へのサーバサイド発注アンド仕様決定と、クライアントアプリの実装は平行で行われた。クライアントアプリは最初、スタンドアロンで開発を行い、サーバの完成に伴って部分的に処理をサーバサイドへ移動させる想定であった。もちろん、モック的な考えも開発経験もあるわけはなく、スタンドアロンで動くアプリとサーバと連携するアプリとではプログラムの書き直しを余儀なくされた。

 クライアント開発は Unity を使って行われた。これ自体は非常に強力で生産性の高いツールであるのだが、データの外部化、つまり Asset Bundle となると話は全く変わる。元々 PC 用の安定した通信環境を前提として設計されているリモートの Asset Bundle 処理は、そのまま提供されている API を使うと、ダウンロードしたデータは最大で(確か) 180 日しか保持されず、そして、保持したファイルの数に比例してそのヘルスチェックを行うため、アプリの起動が遅くなるのである。自分の記憶においては、(他社で言うと)テクテクテクテクがこの罠を踏み、あらかじめデータをダウンロードした方がアプリの起動が遅くなると言う本末転倒な現象が発生していた。

 そのため Asset Bundle を自前で保存する機構から実装を求められた。あの不自由な iOS や、ストレージが内部にあるのか外部にあるのか常に生きているのかオフラインなのか保証されない Android でそれを実装するのである。とにかく Asset Bundle はそれ自身の融通の気かなさと、モバイルにおける様々な環境の信頼性の少なさから、今でもなお Unity では利用したくない技術のひとつになっている。

 アプリの実装もまた、自分の経験不足が最後まで仇となった。まず UI についてであるが、当時の Unity は OnGUI から uGUI への移行期間であったが、勇気を持って uGUI を選択することが出来なかった。Canvas のパフォーマンスが未知数であったことと、デザイナーに対して正しいツールの説明が出来なかったからである。

 ここでもうひとつ、さらに大きな負債として立ちはだかってくるのが、国内で大手のモーション作成ツールである。ここは元々、主にコンシューマゲーム機などへの画像減色ツールなどの提供を行っていたのであるが、それと並行してゲームへのモーションを付けるツールの提供も行っていた。デザイナのスキルがそれでロックインされていたため UI の動きについてもこの大手ツールを使う流れになっていた。これがひとつ、非常に良くないところであった。今であったらどうにかして uGUI と Unity の Animator でお願いしているところである。

 この大手ツールはそもそもパフォーマンスが悪く、さらにそのツールで作られたデータのインポート・エクスポートにも難があった。(Unity)C#で記述しているには(GC的な意味で)無駄の多いランタイムであったり、あらゆる表現を可能にしたいが為に、使わない・使い切れない大量のシェーダ・マテリアル・データを抱え込む仕様であった。そこまでリッチなものを作りたいわけでも(我々の規模としても)作れるわけでもなく、そしてさらに悪いことに UI としてもこのツールの利用を決定してしまったため、開発は大いに難航した。パフォーマンスが出ないであったり、デザイナが作ったデータの受け渡しに非常に手間取ったり、繰り返すが、このときに自分の Unity への熟達が十分であれば、すべて Unity で解決していたであろう。

終わらないパラメータと地獄のようなExcel

 全てに於いて想定の甘さという話に着地するのであるが、ゲームのシステムディレクターは必要なパラメータを洗い出せなかった。実装に従い必要な情報が増え、そして都度Excelはレイアウトが変わる。さらに悪いことに、中途半端に別シート参照果ては別ファイル参照という小賢しいテクニックでもってデータが作られてくるため、そもそもこのデータのやりとりに最後まで苦労をした。特に何も言われずデータのレイアウトは変わり、数値と信じていたものは文字列に変わり、見栄えのために空白のセルや結合されたセルがあちらこちらに舞い、そして xlsx ではなく xls であった。要は新しい(リボン)UIを拒絶した結果がここに来たのである。そういえばその人は Windows もOSや必要ソフトのインストールの次にすることは XP や 7 のスタイルから Windows 95 のスタイルへ直すことであった。使っているエディタも未だにサクラである。

自分に対して唯一の救いとなったC#

 そんな中、開発言語として C# が採用されていたのは自分にとって非常に助かったことであった。とは言え、この場合比較対象として想定に出るのは Java くらいであって、これが C++(C++11以降) であったとしたら、それはそれでそれほど開発の楽さは変わった感はない。つまり、必要なのはさくっとコールバックを書くための楽な文法であり、その場で変数のキャプチャを伴う関数の定義ができれば何でも良かったのである。当時の Java であったら、そのたびに生成される匿名クラスの記述量に憤死していたであろう。そして、当時の MonoDevelop-Unity は(今となっては Rider には及ばないにしても)それでも十分パワフルであった。

無計画であった集金方法

 話をゲームに戻す。ガチャではないスタイルで実装されていたこのゲームの集金モデルは、あまりにも楽観的すぎる予測とともに設計されていた。基本無料でガチャをやらないのであれば、例えば Homescapes のように、あるいは他のゲームのように、支払いへの導線を綿密に作り、あるいは支払いではないにしてもリワード型の広告をふんだんに盛り込むべきであった。今になって思うと、石よりも必要なのはこの部分の実装であった。この部分が最初から厳密に仕上がっていれば、今でも細々とこのゲームは緩慢なアップデートを繰り返し生き続けていられたのかも知れない。

ようやくのサービスインとフェードアウト

 そんなこんなで、ひたすら苦痛の中でどうにか生み出されたこのゲームのサービスが始まった。結果としては先に述べたように、あまりにも集金への導線が薄かったため、開発費に対してこれがペイしないことは直ちに判明した。いくつかの再起を図って、機能改善や石の消費を伴う追加要素、果ては英語版のリリースまで行ったのであるが、その全てが徒労に終わった。元々開発力のないチームであったというのもあり、結局大きな事は何一つ出来なかった。あとにはユーザから中途半端に吸い上げた、浮いた金(石)だけが残った。

サービスのクローズと返金と

 アプリやそのサービスが、元々想定の乏しいプアな作りであったため、返金への対応はかなり後手後手となった。アプリの内側から直接連絡を受けることは出来ず、大分プリミティブな方法での返金対応となった。ただでさえ赤字を出しているプロジェクトが、ここで自分を殺すためにさらに余計な人件費を嵩ませることになった。当たり前の話であるが、サービスを伴うアプリを作るときには、その閉じ方も想定するべきであり、どこまでも行き当たりばったりにサービスを行かしておくのは、結果として最大限の損失に繋がる。

繋がる未来があるとするなら

 これ以上思い出すことはない。ある種の運営型アプリはこの業界にとってレッドオーシャンであることは既知であり、そして一発ホームランを狙うにしては投げる球のコストがアホみたいに高くなりすぎている。

 Unity についての知見は溜まった。また Unity もどんどん機能を増やし改善され、いろんなことが少ないコストで出来るようになった。しかし、それを上回る速度で iOSAndroid は無駄に複雑化していく。ただ単にゲームを作るだけであれば Unity は非常に優秀な環境であるが、モバイルにおけるネイティブの機能と使おうと思った瞬間に修羅の道と化す。Unity は、ちゃんとしたネイティブの知識を持たずには、ほとんどまともにモバイルでゲームを作ることが出来ない。そのゲームが数千円で売り切られるのなら問題はないが、実際には基本無料の上に様々な SDK を乗せてようやく収益が見込まれ、そして人に遊んでもらえる環境となる。そしてその様々な SDK は Unity と仲が悪かったり、他の SDK と仲が悪かったりする。

 あるいはそもそも、ゲーム業界という IT で最も神の加護の下にない世界には、もはや生きるための余地はないのかもしれない。馬鹿のひとつ覚えのようにやれインディーだ個人開発だなんだと吹き上がっているが、どんなに良いものを作っても金を稼ぐ事に繋がらなければただの負債であるし、知名度が足りなければ、あるいは宣伝する手段がなければその価値は目に見える場所にあるゴミにも満たない。無である。

 この業界に、少なくとも自分に、繋がる未来は、おそらくない。ただただ大手が AAA 級と呼ばれるゴージャスなコンテンツを提供するか、ハイクオリティで盛り沢山の絵と声を用意したガチャを作るか、あるいは元から知名度のあるクリエイターが約束された名作を生み出すか。

 ただそれだけである。

対戦ゲームがしんどい話

ネタ元: https://anond.hatelabo.jp/20200214153233

 雑に思ったことを書くだけ。雑すぎるところについては言及しない。

負けると楽しくない件

 ブコメ見てたら5割の勝率でも人は楽しくないらしいけど、実際にランクマやると初心者は4割勝てればかなりすごい方だと思う。強い人は6割以上勝つんだろうけど、初心者は4割も厳しい。(略)負けてばかりなので昇格もできないし、同じところにずっと居続けるというのは変化がないということなので面白さを感じないというか単純に飽きる。徒労感を感じる。

勝率がつきまとう問題

 単に数字だけ出されると、平均値である50%を境界にして勝った、負けたの印象になりやすいので、少なくとも低ランクのうちは明示的な褒めが必要なのかなとか思ったりした。

 つまり、5割勝ってる場合はSだかSSみたいなローカル評価を出して、そっから10%減ってく刻みで A, B, C, D, E みたいな評価を、気休めでも良いから出してあげればと思う。3割以上勝ってれば評価Bみたいな。

負けに対する徒労感

 ガチャゲーみたいなのだったら、とにかく対戦を(完遂)したら無料石を配るみたいなインセンティブの与え方はあると思うんですけどね。あるいはデイリークエストみたいな奴。n回対戦するとか、n回ガードするとか、n回攻撃ボタンを押すとか、そう言うほとんど実行可能な目標を作って、それを達成したらなんかいいことを与える奴。

 最終的に勝ちがすべてになってしまうデザインであると、この問題はどうしようもない。

 模範的な解法としては「負けた試合に対して、どこをどうすれば良かったのか」という PDCA 改善ができる何かがあれば良いのだけど、まだまだそれが自動化される未来は来ない。

投了できない件

 将棋や囲碁の場合、絶対に勝てない状況になれば投了する。敗者側が相手の実力を認めて降参するという意味でもあり、必要以上に敗者を痛めつけて恥辱を味わわせない配慮でもある。格ゲーにはそういったシステムがない。100%負けるとわかってる状況でも最後まで付き合わされる。こんなにばかばかしいことはない。

 要はあんまり心を折りたくないという話でしかないのですが、トレーニングモードの操作が充実して行ってる現代において、ランクマッチもある種のトレーニングと考えた場合、さっくり投了できる仕組みは実装してもいいのではないだろうか。結果として断線する/される確率も減るとは思う。

 これも、囲碁将棋の場合、投了に至ったあとは検討が始まって、何が敗着であるのか話し合ったりできるのですが、少なくともネット越しの格ゲーの場合はそれが非常に困難である。

 理想的には、トレーニングモードのように色んな情報を出した上で、フレーム単位で巻き戻して検討ができる、もっと理想的にはその瞬間から入力の練習ができるようなものがあれば、次は同じ展開にならないような努力に繋がることができる。

負けないことが目的になってしまう件

 勝って楽しいかといったら、実はそんなに楽しくはない。ランクマというのは1回勝てばいいわけではなく、勝率4割以上キープできないと降格する。上位ランクに行くほど要求される水準が厳しくなる(なので快楽を求めてサブアカなど使って初心者狩りにやってくる中級者がよくいる)。1回勝っても次もまた勝たなきゃいけないということになるので緊張感から解放されない。勝っても少しほっとするだけ。ランクマやってる限り常に勝利を求められ、継続的なストレスから解放されない。楽しさを感じている余裕がなくなり、勝ってもそんなに楽しくない。

 ランクマッチという機構である以上どうしようもない。ランクマッチだけど(よっぽど連勝連敗しない限りは)勝っても負けても自分のランクに影響がない状態というタイミングを宣言できれば良いのかもしれないけど……。

 理想的には、ランクマッチ以外のエンジョイできる場所がもっと楽に実現できれば良いのかもしれないけど。今はいわゆる部屋を建てて(フレンドなどと)やるくらいしかない。

敗北時の精神的ダメージがきつい問題

 1対1で運要素の少ないゲームの場合、負けた原因はすべて自分にあるということになる。無力感を突きつけられる。自分の全てを否定されたような気持ちになる。就活で不採用通知をもらったときの気持ちに似ている。これに向き合い続けられる人は精神的に相当タフだと思う。世の中のエンジョイ勢は苦痛を味わっても勝利のためにゲームしたいとは思わないのですぐにやめてしまう。格ゲーガチ勢はストイックすぎる。

 これ、スマブラの時間制ポイントバトル(スコア不可視)がぼちぼち緩和してるポイントだよなぁ、とか気付いたところがあって。

 普通の対戦ゲームの場合、相手を打ち負かしたところで勝敗が決し、大体の場合はそこでの勝ち負けがそのまま試合の勝ち負けに繋がっていく。

 つまり、プレイでミスしたところの体験がそのまま敗北へと繋がる流れになっていて、おそらく大分これは悪い体験なのではないかと思われる。

 スマブラの時間制ポイントバトルの場合、ゲームの終了はタイムアップがあって、そこから結果発表につながり勝敗が決まる。勝利や敗北に対して、プレイヤーの直前の操作がそれほど関係がないのである。「操作をミスったから負けた」と言う感覚は、少なくとも通常の対戦格ゲーよりは薄まっているように思える。

 結局、負けたことは、その決まった結果はどうしようもないので、あとは切り替えて次の試合に臨むしかないわけで、それを緩和できる見せ方があれば、それはどうにかなればと思う。

コンボがつらい件

 グラブルVSは簡単コンボといわれているが、結局、壁際では長いコンボができてしまう。安定して最大コンボできるようになるにはある程度練習が必要。トレーニングモードで最大コンボできるようになるのは割とはやいが、実戦でできるようになるにはかなりの時間を要する。練習が楽しい人もいるらしいけど、普通は別に楽しくない。(略)コンボできることが前提の作りになっている。コンボ始動技を当てた回数では勝っているのにコンボできないから試合に負けるということも起きる。ばかばかしくはないか。

 コンボを否定することはなかなか難しい。プレイヤースキルが高い方が強まる、という構造を否定しちゃうと、それは運ゲーになってしまうので……。

 根本的には「頭で分かっている操作」と「実際に実現できた振る舞い」の差違が激しいのが問題だと思っている。要は、ここもまた PDCA の話でしかなくて、何故コンボが入力できないのか、どこをどう改善すれば良いのか、という部分の難易度の問題なのだと思う。

起き攻めの件

 普通のスポーツの場合、寝技のない格闘技は相手がダウンしたら距離を取って仕切り直すが、格ゲーでは起き攻めが推奨されている。これがいつまでたっても慣れない。ものすごい抵抗を感じる。とくにダウン側に起き蹴りがない2D格闘で起き攻めをするのはフェアではないと強く感じる。(一応、グラブルVSでは起き上がりに無敵技を入れることで相手の起き攻めに対して一方的に勝つこともできる。が、奥義以外に無敵技を持ってないキャラクターもいる)

 どうしようもない。

 起き上がり側にも「リバーサルを狙って無敵を出す」あるいは「起き上がりタイミングや起き上がり位置をずらして逃げることで拒否する」みたいな選択肢があれば良かったのだけど、そこで択を迫るような被されをされたらどうしようもないし、そここそ読みあいと呼ばれる運ゲーの域になるので……。

 あえて言うなら、どうすればその起き攻めを捌けたのか? というのがあとから分かるのならまだいいのだけれど。

超必殺技の件

 2D格闘でおなじみのゲージ消費の超必殺技。3D格闘にもある。初心者が一発逆転できるようにという意図もあるのかもしれないが、実際には初心者が超必殺技を当てるのはとても難しい。結局経験者がコンボダメージを伸ばすために使うことになる。初心者は一方的に超必殺技を食らうだけなので面白くない。また、いちいち演出が入ってだるい。

 おそらく「初心者が一発逆転できるように」という意図はない。単に時間経過による緊張感を出すためにある。初心者が面白くないのはまた別の問題で、そもそも初心者が面白い事なんてまずない。

結論というか個人的に思うこと

 ストリートファイター2が世に出てからもう何年も経つのだけど、多分この問題はどうしようもない。

 囲碁、将棋であればハンデを付けるというやり方があるのだけど、どうもコンピュータの対戦ゲームにおいて、そのような文化が成立していない。

 最終的に、初学者と熟達した人のバランスが崩れていく宿命にあるのだから、実力差があってもぼちぼちどうにかなるようなシチュエーションの対戦を、文化的に育てていかないと、心を折る人が無限に生成されていくだけだと思う。

そろそろ、ネット(はてブ)で吠えるのをやめて、現実の行動に移そうと思った

 割と自覚的に、はてなブックマークのブックマークコメントで、特に性犯罪の加害者について自分の怒りをストレートにぶちまけるコメントをしてきた。死ねとか殺せとか生きてる価値がないとか無限大遠方に移動しろとか呼吸をやめろとか、そんなの。

 その上でブックマークコメントを書いた。

性差別や性暴力の話になるとケンカになる問題|アルテイシアの熟女入門|アルテイシア - 幻冬舎plus

私はずっと性暴力とか性犯罪とかそういうのに殺意を向けんばかりに怒っているのだけど、もっと殺意増し増しでブコメ書いた方がいいのかな……とか思った

2020/08/18 17:12
b.hatena.ne.jp

 スターがむっさついた。性犯罪についてこれ以上怒る事についておそらくポジティブなリアクションなのだろう。

 正直な話、これ以上と言われると2つの意味でそろそろつらい。

 ひとつは、はてブを眺めて性犯罪のエントリが目に入るたびにこれ以上怒るべきなのか、このサービスの一部はは怒りのために存在するのか。そんなことを思ってつらくなった。何の根拠もないけど、強くて汚い言葉を書き出すたびに、脳が高揚してどこかの何かが切れていく気がしている。いわゆるQoLが下がってる気がする。

 もうひとつは、ブックマークのコメントで怒りを吐き出すことで、そこでもうそれでやってやった感を得ているところがあるのではないか、と言うのに気付いた。ここにこの怒りの言葉を書いたから世直しになったのではないかと。これで世界が良くなったのではないかと。

 多分きっと、そんなことはない。こんなサービスのこんな何のバズりもしたこともなくコンテンツを抱えているわけでもない、このブログだって月間100PV程度の流れ弾しか来ない自分の怒りは、多分はてなブックマークの外の誰にも届いていない。ぶっちゃけネットの行動なんて世界に響かない。

 なので、性犯罪に対する怒りについては、はてなブックマークのコメントに過剰に注ぐことはせずに、例えば自分が誰か若い世代を育てることがあるのなら、その相手への啓蒙へ、自分が会社の経営に関わることがあるのであれば、潜在的な女性蔑視やら不平等がないか目を光らせ、何か進言するような。投票行動をすることがあるのなら、出来る限りこの国の(意思決定の場における)男女不均衡が正されるような選択肢を。今自分がやっている以上に意識して心がけて、そう言う現実の行動に向けていくようにしようと思った。

 とにかく性犯罪者やら性差別やらそう言うエントリに対して、ブックマークのコメントで半ば憂さ晴らしのような怒りをこれ以上強くストレートにぶつけることは、少なくとも自分の健康や行動にとって良くないことであると感じたので。もっと現実に足を付けて、この世界の物理的な行動として、様々な性差別、性犯罪に対して拒否を伝えていこうと思った。

 ネットだけでは世界は何も変わらない、気がする。

noteに移動しようと思っている

 はてなブログは面白いくらい Google にインデックスされていかないので、(少なくとも2ndとしてはてなブログに書いていったものは)徐々に note に移動していこうと思う。

 ちゃんと世界に認識されてってる、他所のはてなブログはどうやってるんだろう。今のところ体感で、はてなブログはてなダイアリーよりも Google は見てくれない。

ブログについて思うことというか何というか

 もし本当に俺がグラブルバーサスについて色々書いたことについて、それをちゃんと世の人に見てもらいたいのであれば、SNS連携をしてセルクマをしてURLをもっともっと露出させて……みたいな活動が必要なのだとしたら

 まで書いて、すごく馬鹿らしくなってきたので、他サービス使って比較実験してみようとか思ったりした。

はてなブログがよく分からない

 せっかくなのでちょっとだけ意識してグラブルバーサスの記事を書いてみたのだけど、一切外からリンクされないというか、はてなブログのトップの方からキーワード関係で導線が貼られない

 はてなブログ タグとやらで繋がるらしいのだけど、でもおそらくこれはまだリリースされていないっぽくて、ブログの編集からエントリにどのタグを付与するかとかそう言う設定がどこにもない

 今のところ、はてなダイアリーが一番このあたりの感覚が良かったというか……一体何なんだこのサービスは。