とあるIT企業のインフラエンジニア。プライベートでは開発もちょっとやります。
※本ブログの内容はすべて個人の見解であり、所属する企業とは関連ありません。
2023/09/30 暫く更新停止中m
生活・子育て(10)
FaaS(1)
働き方(2)
SaaS(2)
自作PC(6)
IT入門(1)
IaaS(13)
IDaaS(2)
ITIL(1)
PHP(2)
OS(6)
システム監視(1)
コミュニティ(1)
PCアプリ(10)
ストレージ(4)
ブログ(9)
ActiveDirectory(2)
デバイス(7)
旅行(10)
デザイン(3)
カンファレンス(5)
セキュリティ(9)
インフラ(19)
コーディング(11)
ゲーム(28)
インターネット(18)
未分類(8)
28 [今日]
608 [昨日]
【報告】マリオカート集計表を終わりにした理由について
2021/06/01
ゲーム
お疲れ様です。
しらせです。
2019年の3月1日をもってサービスを1つ終了しました。
MarioKartScoreSheetは、私が2010年にジオシティーズで作成したのを皮切りに、2014年にはIDCFクラウドへ移植してマリオカートと対抗戦を愛する人たちがお互いに繋がりあえる環境を目指して提供を始めました。
最終的に利用者数は2000人を超えて、これまでに作成された集計表は30,000を超えていました。
なぜこのタイミングで終わりなのか、バックエンドで動いているシステムや今後について残そうと思います。
もくじ
1.停止するに至った経緯
正直、このサービスを提供し始めた当時はこれほど伸びると思っていませんでした。
当時私が好きだったマリオカートプレイヤーの「Xさん」がコミュ対抗戦で集計をする際に、少しでも楽ができるようにと始めたのがきっかけでした。
それから、口伝にいろんなプレイヤーに伝わって広がったことで、ジオシティーズ上で一方向的に提供するだけでなく、もっとコミュニティ性を高めようと考えるようになりました。
あれから8年が経った今、時代が少しずつ変わってきました。
きっかけは、このサービスをホストしているクラウド事業者の方針転換でした。
これは、個人利用から企業向けへの転換が図られたことで、私のアカウントも3月いっぱいで撤退を余儀なくされてしまいました。
一応、移植先の候補はいくつもあったのですが、手間も維持するお金も掛かることから今後の継続をずっと悩んでいました。
二つ目に、マリオカート界隈の変化です。
そもそもは、コミュ対抗戦といえばニコニコ生放送でしたが、今ではかなり下火になり対抗戦の内容も3レース構成から1レースに変わりました。
スコアシートの形式を変えようにも今の流れを知らない上に、手を入れる余地がありませんでした。
2.理由
こんな経緯から、このサービスをどうしようかなぁと悩んでたわけですが、最終的に継続しない方向にしました。
理由は以下の通りです。
- このサービスの拡張にこれ以上時間を割けないこと
- このサービスを惰性で続けるよりも、次の新しい世代のクリエイターにバトンタッチしたい
- 最終的に目指すコミュニティを作れなかったこと
すべて自分勝手な理由ですがインフラエンジニアが片手間で作るよりも、ちゃんとしたクリエイターに今後の未来を作ってもらいたい。
そのために、このサービスは続けない方が良いと思ったからです。
3.設計思想
ここからは、ちょっと技術的な内容に触れたいと思います。
設計段階で一番気を使ったところが、集計表の種類と編集のしやすさです。
基本的には1レース12人で行われるのですが、12人で順位を争う個人用をはじめ、6人2チーム対戦、4人3チーム対戦、3人4チーム対戦、2人6チーム対戦の5種類を提供していました。
最終的に、この5種類はそれぞれ別のデザインになってしまったのでメンテナンスが最悪に面倒でした。
そして、登録した集計表は後で何度でも修正ができるようにしました。
レースをした後に振り返って、スコアを修正するのに画像を手直しして配ってたら面倒ですからね!
集計表の登録管理のためには、ユーザー1人1人を識別する必要があります。
個別に認証システムを作っても良かったのですが、ほどよいコミュニティ性を兼ね備えた良い認証基盤となるTwitterがあったのでOAuthを拝借しました。
※この辺りが参考になると思います。
abraham/twitteroauth - GitHub
・OAuthライブラリを提供されています。
Oauth with the Twitter API — Twitter Developers
・ついったーの公式リファレンスです。参考程度
構想段階のメモ書き
4.技術仕様
最後に技術的な話です。
基本的に、サーバのOSとしてはCentOS6系を使って、ApacheとPHPによるフルスクラッチです。
表示部分はCSSで書いて、ページの中での集計部分はjsとjqueryで頑張ってました。
登録されるデータについてはデータベースは使っておらず、サーバ上にファイルとディレクトリを駆使して保存していました。
個人的に、結構よくできている仕組みだと思っていて、仮にユーザー数が1万、10万と増えていってもスケールアウトすることで耐えられたと思います(笑)
結局、処理性能にはあまり影響が無いということが分かったので、いちばん安い構成で毎月自分でバックアップする運用になりました。
データの格納に関する設計はこんな感じ。
inodeが許す限りファイル作成は続きます。ローカル容量不足で保存出来なくなったり処理が多くなった場合は/nfsのマウントポイントをNFSサーバに変えればいいだけです。めっちゃ楽。
ちなみに、私が実現できなかったコミュニティのところは、構想までは終わってました。。。
これをどなたか、こんな感じで実装してもらいたいです。。。
5.最後に
決してマリオカートが嫌いになったから終了したのではありません。
最近は、スプラートゥーンや別のゲームばっかりやってますが、マリオカートは64からやってるくらい好きです。
これからも別のゲームで便利なツールを作るかもしれません。
またどこかでお会いできる日を待ってます!
以上
お疲れさまでした。