今年プレイしたゲームで一番楽しかったのはこれ!サバイバー系の新作をチェック! #楽しい
この記事のタイトルは はてなブログのAIタイトルアシスト(β版)によって作成されました。
この記事は mhidakaが2つ目を建立した Advent Calendar 2023 7日目です。 adventar.org
こんにちはこんにちは ytRinoです。 はてなでAndroidアプリエンジニアをしたりDroidKaigiのスタッフをしたりしています。
今年遊んだゲームをつらつらと書きます。ものすごく久しぶりのブログがこんなんでいいのかという気もしますが、まあいいでしょう。
だいたい最近プレイした順。最近はカジュアルゲーをやっていることがおおいです。
8番出口
おすすめ: ★★★ プレイ時間: 2時間
最近話題になってるやつですね。初クリアまで1時間半かかりました。初回クリアで全異変コンプ勢です。クリアしてから配信の動画などみたら気づいてないやつが何個かありました:thinking:
ところどころゾワっときたので苦手な人は配信でワイワイみるぐらいでちょうどいいタイプのやつ。
でも面白かったらワンコインだし買うといいと思います。
Party Animals
おすすめ: ★★★★ プレイ時間: 50時間
癖のある操作感のかわいい動物たちで殴る蹴るの戦いを繰り広げるパーティーゲーム。Gang Beastを整えた感じのやつ。ローカルや身内マルチもできるけど、メインは野良クイックマッチなのでソロでも楽しいよ。ホントダヨ
キャラのスキンも豊富でよい。
Disney Speedstorm
おすすめ: ★★ プレイ時間: 40時間
基本無料のディズニー版マリオカート。 12月からシーズン5「Let it go」が始まり、アナ雪のキャラやステージが追加された。
マリオカートとの違いはキャラごとに使えるアイテムが違っていて、キャラごとのユニーク1種+汎用4種で固定されていること。
あと基本無料なだけあってソシャゲ的システムになっていて、レースをしてアイテム集め->レベル上げてマシン性能アップ、ピースを集めてレベル上限解放、課金で人気キャラ開放、などまあまあアレです。
マルチでキャラレベル差のある人と当たるとなすすべなく負けます(一応近い人とあたりやすいらしい?)。CPUでもちょっとレベル差あるときつくなるのでエグい。
じゃあなんでやってるのかというとゲーム機がPCしかないけどマリオカート的なものがやりたくなる時があるからです。
サムライブリンガー
おすすめ: ★ プレイ時間: 5時間
ドットテイストな和風ローグライトアクション。ジャンプと斬りを合わせるとジャンプ斬りになるなどスキルの組み合わせシナジーでビルドを組むタイプ。
ローグライト要素はステージのランダム生成と武器のドロップぐらいで、スキルは一度手に入れたらつけ放題なので、死んでもお気に入りのビルドで最初から無双できるのが◯。耐性装備周りなどはちょっと面倒。
リトルノア 楽園の後継者
おすすめ: ★★★ プレイ時間: 9時間
ローグライトアクション。グラフィックの雰囲気もよしで値段も手頃。アクションゲーが下手なのを自覚する最近ですが、そんな自分でも手軽に雑魚をボコりつつボスはそれなりのいい塩梅のゲーム。
永続強化が多く、というか多すぎてクリアまで結構死んだ方だと思うけどまだ全然埋まらない。
東方天空璋
おすすめ: ★★★ プレイ時間: 6時間
2017年発売。最近は東方もSteamで買えてありがたい。
霊夢・冬でNormalクリア。Extraクリアしたら鬼形獣やろうと思っていたのにまだExtraクリアしてません 。というか天空璋むずくないですか?
好きな東方は妖々夢、永夜抄、風神録です。好きなキャラは咲夜さんです。原作厨です。よろしくお願いします。
Diablo IV
おすすめ: ★★ プレイ時間: ???
Diablo3はなんだかんだ文句言われつつ自分はそれなりに楽しんだ勢。ハクスラはPath of Exile(PoE)を崇めているため買うべきか悩んでいたが結局買った。
買ったものの、プレシーズンからやってシーズン1の途中で辞めてしまった。
というのも、マウスとキーボードで手を酷使するゲームはすぐに手を痛めてしまい厳しいのである。かといってハクスラをコントローラーは厳しい。移動をクリックに割り当てないなどで頑張っていたが、名声のだるさやダンジョンの繰り返しがいまいちなこともあって続かなかった。
(その点PoEは移動がはじめからスキルスロットに割り当てられるし、たくさんのスキルボタンを忙しく回さないとビルドが成立しないということがないのが良い。)
その後聞いた話によれば名声もシーズンリセットなしになったようなので拡張が出るころにまたやると思う。
・・・が来年はPath of Exile 2のbetaも始まるのであった。来年も今年に続きハクスラの話題が多い年になりそう
この前のセールでSteamで40%オフになってて早すぎるだろと思ってしまった。
ビビッドナイト
おすすめ: ★★★ プレイ時間: 8時間
ローグライトデッキビルド。キャラがポップでゲームのテンポもよい。マウスポチポチで手軽に遊べる。
デッキビルドゲーにありがちな1ターンの行動が重要、というよりもテンポよくバシーンするタイプ。
キャラの合成でランクを上げたり、キャラの属性を一定数集めるとボーナス能力が発動するなどがあり、残すキャラ捨てるキャラの選択が発生する。
来年に新作のVivid Worldなるものが出るらしいですね。
MISTROGUE ミストと生けるダンジョン
おすすめ: ★ プレイ時間: 10時間
ハクスラx不思議のダンジョンを謳う国産アクションゲー。 スキルのシナジーがゲームのキモで、それをクエストと言う形で配布&学習させてくれるところなどは良いのだが、ゲームバランス、グラフィック、ビルドの幅、操作性、などあらゆるところが惜しい。
Stumble Guys
おすすめ: ★ プレイ時間: 10時間
どうみてもFall Guysクローンです。本当にありがとうございました。
この手のゲームは性能差がないのが良いところなのに、相手をこけさせるエモートなどが実装されていて、だいぶp2wの様相を呈しているので最近はやっていません。
なんでFall Guysをやらないのかと言えばゲーム機がPCしかないけど宗教的な理由でEpic gamesを常用できないからです。
東方華彩乱戦2
おすすめ: ★★ プレイ時間: 8時間
東方二次創作アクション。キャラのグラフィックが良い。コレクション要素も多くプレイアブルキャラも多い。妖夢でクリアしたところまでやった。DLC多すぎだろう。
東方夜雀食堂 - Touhou Mystia's Izakaya
おすすめ: ★★ プレイ時間: 4時間
東方二次創作料理ゲー。キャラのドットが良い。未クリア。DLC多すぎだろう。
サバイバー系
世ではVampior Surviversがヒットして以来、サバイバー系と呼ばれるゲームが出まくっていますね。 今年はこの手のを結構やっていて数が多すぎるので一部をおすすめ順に載せます。
バイオプロトタイプ
おすすめ: ★★★★ プレイ時間: 30時間
実験生物の脳に器官をキメラのように繋げて無双するゲーム。 永続強化なし。Wave制。
角、触覚、脚など攻撃用の器官を脊髄や腸などの接続用の器官で繋いで強化していく。
面白いのは、器官ごとにつなげる器官やが違うことと、つなげた器官は脳から繋いだ順番に、前の器官を起点に発生する。
例えば弾を複数だす器官を繋げていくと、最初の複数の弾が着弾するとそこから次の器官の弾が発射され、倍々で増えていく・・・という感じ。
自分がやっていた頃は日本語訳はやや怪しかったが普通に遊べるレベル。
Brotato
おすすめ: ★★★★ プレイ時間: 5時間
ローグライクのヒット作のBinding of Isaacみたいなグラフィックだが別物っぽい。 永続強化なし。 Wave制。
最大6個の武器を装備して斧やら銃やらを使い生き残るやつ。金を集めてパッシブや武器を買いながら強化していく。同じ武器を3つ集めるとランクアップできる。
シンプルながらバランスもよく、ヴァンサバの次を求める人にうってつけ。
20 minutes till dawn
おすすめ: ★★★ プレイ時間: 5時間
最近買ったのでそんなにやってない。ドット絵のできが良く、雰囲気にピンときたら買い。 永続強化あり。永続強化は何でもかんでもつけれるわけではなく選択制。
サバイバー系の売れ線なので特に言うことがない
グリードランド
おすすめ: ★★★ プレイ時間: 15時間
銃やらよくわからない兵器で武装してまあまあ気持ち悪い生物を蹴散らしていくやつ。永続強化あり。3Dグラフィックで未開の地に降り立って銃で汚物を消毒したいなら買い。
サバイバー系といいつつツインスティックシューターでもあり、自分で攻撃方向を指定することもできる。永続強化は装備コスト制で自動攻撃やオートエイムも(コスト安いけど)一応装備オプションということになっている。
Spell Disk
おすすめ: ★★★ プレイ時間: 5時間
バイオプロトタイプ的な連鎖シナジーがビルドのキモ。永続強化あり。ステージ制。
攻撃スペルとそれを起動するディスクを組み合わせて装備していく。スペルを起動するにはディスクにチャージする必要があり、そのチャージが特定の属性のスペル発動だったり時間・移動距離などディスクごとに色々な条件で貯まる。いかにお互いのディスクのチャージを貯めやすいシナジーを組めるかが重要。
ザコ敵が大量に湧くタイプではなく、それぞれがめちゃくちゃ攻撃してくるし普通に痛い。もっと手軽なヴァンサバ的サバイバー(?)が好きな人向けに、より無双系寄りのサバイバーモードがある。
Dungeon 100
おすすめ: ★★ プレイ時間: 13時間
魔法の弾をパッシブで増やしたり並列にしたり自分の周りくるくるさせたり空から降るようにしたりといろいろ変化させながらさいきょうのびるどを求めていくやつ。 Wave制。100Wave。
基本的には手札の左のスキルから自動で使われるのでクールダウンや特性を考慮しながらどの手札を残しどの順番で並べるかのシナジーゲー。
最初から100wまで行けるわけではなく、クリアするごとに一定ずつ増えていき、その時の最終階層を突破したビルドは次回以降のその階のボスとして登場する。
つまりうっかり引きが良くて強すぎるビルドを組んでしまうと、次回以降に過去の自分に勝てなくなって詰む。
他のプレイヤーの100階クリアデータに挑戦することもできる。
God Weapons
おすすめ: ★★ プレイ時間: 5時間
サバイバー+荷物整理ゲー。 永続強化あり。Wave制。
カバンを拡張しながら武器やパッシブ装備をうまく敷き詰めて、隣接ボーナスなどを組み合わせながら進んでいく。
Death Must Die
おすすめ: ★★ プレイ時間: 6時間
サバイバーに武器や防具などがハクスラ要素としてあるやつ。永続強化要素は装備と特定アチーブメントの達成でアンロックされる初期パッシブ。一定時間ごとにボスがでて20分ぐらいで終わり。
レベルアップ時のランダム能力獲得のときに、全体からのランダムではなく、まず炎や氷など各属性をもつ神が抽選され、その神が提供する能力から3つが抽選される。神ごとリロールしたり能力部分だけリロールしたりできる。
職業は色々あるが近接職の差別化がいまいちなので魔法使いばっかりやってる。
Soulstone Survivors
おすすめ: ★ プレイ時間: 20時間
いかにもヴァンサバコピーという感じで、なつかしテイスト3Dグラフィックな魔法サバイバー。自分たちで作っている別ゲーの素材流用して流行りのサバイバーに便乗した雰囲気がある。永続強化あり。ステージ制。
スキルが派手で最初は楽しいのだが、後半になると敵の(ボスの)範囲攻撃が苛烈すぎてそこら中が赤い予告エリアだらけになり、回避を連打しまくるゲームになる。
9th Sentinel Sisters
おすすめ: ★ プレイ時間: 3時間
国産サバイバー系でまだアーリーアクセス。サバイバー系といいつつ攻撃方向は手動のみなのでどちらかというとツインスティックシューター。
美少女!ロボ!という感じで日本からもサバイバー系でヒット出て欲しい!と密かに期待しているのですが現状はアーリーだな、という感想。今のところ美少女要素はほぼ皆無。おすすめというか期待をこめて。
おわり
Steamリプレイが今年の分が出てたらそれを見ようと思っていたけどまだ出ていなかったのでダラダラ列挙しました。ちなみに去年はPath of Exile漬けだったようです。来年はPoE2が楽しみです。
シレン6やりたかったのにSwitchだけとか許せない
Application Contextは使ってはいけない
タイトルは誇張です。
みんな大好きpotatotipsという勉強会で以下のようなトークがあったようです。(現場には行っていません)
曰く「ActivityContextで何千回もやったら数回リークが検出された。 なるべくApplicationContextを使おう」とのことらしいですが、間違いなく死人が出る(誇張)と思いますのでご注意ください。
(追記20160527: 修正されたようです なんかすみません) speakerdeck.com
結論
Application Contextは使わないでください。(誇張)
(実際は使うときは使う)
なぜApplication Contextなのか
Application Context使おうぜ!という根拠の記事としてこちらのフェンリルのDeveloper's Blogの [追記あり] Android 開発で気をつけたいこと 〜変数名と Context について〜 (フェンリル | デベロッパーズブログ) という2012年3月の記事が2年に1回ぐらい話題になると思います。
そしてこの根拠としてあげられるのが2009年1月のAndroid Developersのブログ Avoiding memory leaks | Android Developers Blog です。
たしかに最後のまとめには
・Try using the context-application instead of a context-activity
超訳) Application Contextを使おう!
とあり、いかにもApplication Contextが正解かのように見えないこともないです。
その詳細がその前段にあり、雑に訳すとこんな感じのことが書かれています。
Contextに関連したメモリリークを避ける簡単な方法が2つあって、1つはそのContextをそのスコープ外で使わないこと、もう1つはApplication Contextを使うこと。このContextはActivityのLifecycleに依存しない。長生きするオブジェクトでContextが必要なときはApplicationオブジェクト思い出せばおk
この2つは本質的には同じことを言っていて「スコープ考えて使おうか…」です。「Application Context最高! これ使っておけばメモリリークにサヨナラ!」とは言っていません。
ちなみに、上記フェンリルのブログの
Context の引数として以下のように Activity 自身を MainActivity.this のようにして渡しても、一見問題なく動作するのですが、メモリーリークをする危険性があります。 (参考 URL : http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks.html )
new Intent(MainActivity.this, FooActivity.class);
特に理由がない場合は、以下のように this ではなく getApplicationContext を使用する方が無難ですし、メモリリークが起きることを回避することができます。
new Intent(getApplication(), FooActivity.class);
に対しては以下のように明確に否定されています
知り合いに聞かれたhttp://t.co/JTzInmjeKI
— Yuki Anzai (@yanzm) June 25, 2015
に書かれているメモリリークの例のことです。
はっきり言ってこの例はナンセンスです。
Intentのコンストラクタに渡すContextは、パッケージ名(Stringだよ)の取得にしか使われていません。
ただ、これだけでは「じゃあやっぱりいつもスコープ広いApplication Contextでいいじゃん」と言えなくもないですが、そもそも「なんでApplication ContextとActivity Contextがあるのか」というのを考えてみましょう。
なぜActivity Contextなのか
考えましたか?
今ぱっと出てこずに考えたあなたはAndroid 2級です。Rxよりも先に学ぶべきことがあります。
というのは半分冗談です:bow:が、
具体的なApplication ContextとActivity Contextの違いについてはこちらの2012年2月の記事にものすごーくいい感じに実際の結果とともに書いてありますので御覧ください。
Yukiの枝折: Android:引数はthisか?getApplicationContextか?ActivityとApplicationの違い
つまるところActivityにはそれぞれのthemeなんかがあるので適当にやってると思った通りにならないことがあるどころか、上記記事のように最悪クラッシュします。
まあそれは動かしてみればすぐわかるので、大した問題では無いように思うえるかもしれませんが。
Contextの違いついて、もう少し長い、具体的なシチュエーションの説明がAndroid DevelopersのGoogle+のポストにあります。2012年3月の投稿です。
plus.google.com 雑に訳すと、
ViewをつくるのにApplication Contextを使うのが癖になってるなら、思った通りのものが出来上がらない、なんてことにぶち当たるまでそう長くはないだろう。でもApplication Contextダメだって言うなら何を使えばいいんだ? それはそのViewをどこに置くか次第だ。
ActionBar
にはgetThemedContext()
があってaction barに適切なthemeがついたやつを使える。Theme.Holo.Light.DarkActionBar
なんかはActivityのコンテンツ部分とは全く異なる見た目になる。
Dialog
にはdialog windowに必要なthemeが使えるgetContext()
がある。AlertDialog.Builder
を使ってるならViewのinflate時にはDialog
オブジェクトはないだろうから、API11からgetContext()
を追加した。
他にはサブペインと他とで大きく異なる見た目にするのにもContext
が使える。ContextThemeWrapper
ってのでContext
をくるんでLayoutInflater
なんかに渡せばいい。
これらを使い分ければ最高のアプリを作るのが楽になるはずだ。
(詳しくは原文をあたってください)
つまり、特にViewに関連するところでApplication Contextを使うのはアンチパターンです。(上記の例で言えばActivity Contextも適切でないパターンまで発展してますが)
あなたが
AndroidManifest.xml
の<activity>
に一度でもandroid:theme
と書いたことがあるのであればApplication Contextを使うのをやめましょう。android:theme
を<application>
にしか書いたことがない人も今のうちにやめたほうが良いでしょう。
結論
特に理由がないときはApplication ContextではなくActivity Contextを使いましょう
Butterknife 7.0で@FindViewになるはずだった@InjectView、リリース直前で@Bindに変更される
README.md out of date · Issue #274 · JakeWharton/butterknife · GitHub
上記のやりとりがきっかけとなったのか、はたまたタイミングが重なっただけか、 長らくsnapshotだったButterknife 7.0.0が今日(6/28)リリースされていた。
で、この7.0にはResource Injection #140 (初版)という機能追加の他にもう一つ破壊的(?)な変更があった。
@FindView
長らく「これって"inject"じゃなくね…?」という話があるとか無いとかで、僕なんかの末端ユーザは「なるほど」という雑な感想しか持っていなかったのだけど、Jakeも気になっていたのかついに@InjectView
にとってかわり、新しく@FindView
というアノテーションがうまれた。Butterknife.inject()
はButterknife.bind()
になった。3月のことである。
それから3ヶ月、その間にGoogle I/Oで発表されたDataBindingなんかの話もJake的には「Butterknife、まだまだいけるっしょ」 (雑)というスタンスのようだ。が、リリースはされないままだった。
@Bind
で、ようやく最初の「今週末にリリースするよ」という言葉通りリリースされたわけだが…
Say hello to ButterKnife 7.0. A unified 'Bind' annotation, bind/unbind methods, and resource binding!
Full changes: https://t.co/v3FzSimWCq
— Jake Wharton (@JakeWharton) 2015, 6月 28
Lots coming to ButterKnife 8.0, but first needed to get these changes that I've been sitting on for a few months. Stay tuned.
— Jake Wharton (@JakeWharton) 2015, 6月 28
( ゚д゚)ポカーン Bind...? てか8.0のプランが…?
お分かり頂けただろうか…直前になって@Bind
に変更されている…
Sorry, the view "injection" joke died with this version. There are 142 too many Reddit comments about view injection without the quotes.
— Jake Wharton (@JakeWharton) 2015, 6月 28
ハハッ
DataBindingの話にやはり思うところがあったのか、#bind()
なんだから@Bind
だろと思っただけなのかよくわからないが、
とにかく@InjectView
は@Bind
になったのであった。
(ちなみに初版では@InjectString
などだったリソース系は、実際にmergeされたときには@ResourceString
になり、同様に@BindString
に変更されてリリースされた)
以上、急に変更されてリリースされたのが面白かったというメモ書きでした。
ところでこちらは来ないんでしょうか Split the compiler and runtime into separate artifacts. by riotopsys · Pull Request #210 · JakeWharton/butterknife · GitHub
RxJavaでフィボナッチ
RxJavaでフィボナッチ数列を生成しようとしたけど面白くなかった - visible true
を見て自分でもやってみた。
(RxJava(というかRxAndroid)をさわっては見てるけどOperator多すぎて困る。)
はじめはscanとかで出来そうって思ったけどあんまりうまく行かないのでFn-1とFn-2のストリームをzipするとかいう大げさなものが出来上がった。
Fn-1とFn-2をSubjectとして、流れてきた値をFn-1 -> Fn-2, Fn -> Fn-1へと流す。
そうするとzip
されて次のFnに流れてくる。
それぞれのストリームの流れもlogしてみると予想していたきれいなzipとは違ってるけどまあなんとなく動いているか、というところ。
なんかもっといい感じn(
Android書いてる間に書いていてretrolambdaもないのでJava8っぽさ0だ