  |
はてなキーワード: クロスプラットフォームとは
ロールバック方式はそれまでGGPOというオープンソースで、市販タイトルだとスカルガールズなどが採用していたものの
ロールバックはよく発生するし強みである水中戦にならないという特徴があるにも関わらずディレイの方がまともに遊べる場合もあった
スト5なんかで自社開発のロールバックもあったけどカクカク水中戦はGGPO以下で、ラグ環境ではプレイできたもんじゃなかった
そこに一石を投じたのがアークのsteam版GGXXAC+Rで、発売からしばらくたっているのに急にテスト版の連続公開をしだして、
そこで自社開発ロールバックのみならずリプレイ途中操作ほか熱帯周りの様々な機能を研究開発した
成果をGGXrdR2やBBCFなどの発売済みタイトルに実装したところ一時的に海外人口が爆増したのと
新作のGGSTでも海外にバカウケ（そもそもロルバの研究が始まったきっかけがGGST開発前、レヴ2終盤で行われた次回作アンケートで海外から「ロールバックがなかったら買わない」という抗議があったから当初国内で最も望まれていたクロスプラットフォームを後回しにしてまでロルバ実装を優先した経緯がある）
これによってGGPOに頼らず自社開発でロルバ乗せれば外人に売れるという前例ができて今は同人ゲームすら自炊でロールバックを実装する流れになってる
という歴史がありながら、それまではオープンソースのGGPOがある程度優秀だったわけで特定のゲームがそれを動かしたわけでもなく
ACPRを10選に入れるのもたまたま過去作のPC版が実験場になっただけなので微妙
ARMSはそれよりも回線相性以前にスイッチそのものに入力遅延があるという前提で、どう見せるか（過去にはバンナムがPS3や亜熱帯でラグるのをどう見せ方で誤魔化すかという研究をしていた）の答えを出したっていうのがエポックメイキングな点であって
あと https://anond.hatelabo.jp/20241108101539 にもまとめて反論するけど
0秒マッチングが1番大事で当時ツイッターで業界人にメチャ驚かれてて間違いなくその後のゲームに影響を与えてるのと
人口いなかったらEVOJAPANのメイン種目に選ばれてねえから
スイッチが普及してからスマブラSPが出るまでは覇権格ゲーの一画で間違いなかった
空ガがなく対空が重要、
各キャラ通常時ガードさせて有利な技が1種類くらいしかないしシステム上ディレイ固めの概念がないため固めの入れ込みの隙間が空きやすい
というゲーム性と一致しただけで
全部同時に飽きた
７月頭に早めの夏休みを取り、夏休みだし何か新しいことをするかと考え、最近流行りのゼンゼロをスタート。
ゼンゼロの進行がプレイヤーレベル依存でストップしたので、気になっていたスタレも開始。
同じくスタレもプレイヤーレベル依存でストップされ、原神、鳴潮と始めていったが流石にしんどくなってくる。
鳴潮開幕の「いやあ、ホントよかった。もうちょっとしたら私の十八番、初級巡尉必須応急スキル――心肺蘇生法！を使うところだったよ（原文ママ）」がキツすぎて思わずストーリーを全部スキップしてしまった所で限界を覚える。
もうちょい根性があったらエーテルゲイザーなんかもやってたと思う（ちなみに崩壊3rdは結構前に第1部だけ全部やって、第1.5部がうわキツで投げたよ）。
とにかく思ったのが、どのゲームも同じすぎるなってこと。
似たようなゲームばっかダウンロードしておいて何言ってんだって思うかもだけど、俺のゲーム選びの条件が「PCでも出来るクロスプラットフォーム基本無料一人プレイゲームで、知名度が高いものを順番に」だったんだよね。
・３人制ならアタッカー/攻撃的サポート/守備的サポ（ヒーラー）、４人制ならアタッカー/攻撃的サポート×２/守備的サポ（ヒーラー） のテンプレパーティー編成
・ボタン１通常攻撃 ボタン２特殊攻撃 ボタン３回避 ボタン４必殺技のテンプレボタン編成
・基本的にはデイリークエスト＋素材周回用スタミナ消費でプレイヤーレベルアップ
スタレだけはちょっと違うんだけど。
なんかね、ほんまに一緒過ぎる。
ソシャゲが出たばっかの頃にどれもドリランドだなーとかどれもモバマスだなーって感じた頃の感覚が蘇るわ。
スマホゲーの方は結構分岐が出てきたけど、PC向けってなるとネトゲ以外はアクションRPGに収束し終えたんかなと。
色々同時にやって思ったのは、スタ消化が放置ポチーで終わるスタレがマジでありがてえってこと。
つうか戦闘もアクションだろうと最終的にはボタンポチポチするだけなんだからもうコマンドでええやんってのは正しいかなと。
ただ演出多目で戦闘テンポが若干重めだからいざ普通にやるとなんか長ーなとはなる。
ブレイク値や支援攻撃システムのおかげで戦闘の展開がマンネリしてないのは評価出来る。が、最終的にはポチポチと同じことするだけでイマイチ張りがない。
推奨レベル下げて雑魚がバシバシ死ぬようにするとテンポよくなるけど、そうなると今度はこっちが強すぎて退屈ではある。
敵が硬すぎるんだよな―結局のところはさ。
ブレイク溜めた後にカリンでガリガリ削りまくってもなかなか減らないんだよなー。
でもなーんか最終的にはそこまで世界が広がらないっていうか、ご近所で起きた事件をインターネット上で解決っていうグリッドマンやパスワード探偵なノリなんよね。そこ含めて３０年前のノリなのは流石に古いなあ。
さっきも言ったけどスタミナ消化がオートなの嬉しいね。
つうかなんでPC対応のゲームは頑なにスキップ入れないのかね。
SF的世界観構築は悪くないしキャラも魅力的なんだが、ストーリーが凡百すぎてしょっぱかったかなあ。
皆がヘルタペロペロの話ばっかしかしなくなるのも納得のピンとこなさがあったぜ。
まあスタレだけはもうちょい続けるつもりだから何とかたどり着けるかな―。
マ ジ で し ん ど い 。
いやまあ素材調達が凄い早く終わるからガチのネトゲと比べるとテンポはいいんだが、それにしても全体としてヘビーというか変な意味で噛みごたえがあるね。
育成についてはアタッカーと草主人公さえいればあとは飯食わせておけばどうにかなるから最終的には軽いのかもだけど。
何が重いってフィールド移動だよ。
なんでこんなスタミナないんだろうなコイツら。
初期の２倍近くまでスタミナ伸ばして刻晴引けてリネットも貰ってで動きやすくなってもまだまだ「うっわー移動に時間かかるわー」って感じる。
戦闘後にアイテム手動で拾わされるのもしんどいし、スタミナ消化のテンポも悪いし（濃縮樹脂手に入れたけど、これ５回使い切るだけでも毎日はダルくない？）。
なーんかもうマジで重いよコレ。
んでまあストーリーもまだ岩の国までしかやってないが、つ ま ら ん。
なんだよ「折り紙のカエルさんを追いかけ、気づいたら折り紙のリスさんや折り紙のキリンさんをお手伝いすることになりました」ってなんだよ。
確かにスマホゲーのパズルが知育テストって言われることはあるけどストーリーまで絵本のレベルは凄すぎるだろ。
パイモンが可愛い以外に続ける要素が思いつかないぐらいしんどかったが、パイモンは凄い可愛かった。
SEKIROみたいなのを期待してたんですが、結局は回避して攻撃ボタン連打じゃないですか。
ポケモンみたいにモンスター集めて戦わせるって聞いたんですが、結局はバフ効果のつくモンスター呼んでバフかけてから必殺技撃つだけじゃないっすか。
さっきも言ったけどストーリーは翻訳がコケているのか元がエグいのかとにかく見てられないぐらいにアレ。
独自用語っぽく出してくるけど要するにそれって「魔力」「モンスター」「怪奇現状』『適応者』ぐらいの意味しかないっすよね？
変装スキル・終奏スキル・共鳴解放あたりの意味が最初ごっちゃになるのもマジで分かりにくかったな。
移動が快適だった所だけは評価したいんだけどね。
壁登りがダッシュでできるとか、平地をダッシュする分にはスタ消化しないどころか回復するとか、原神を遊んでからコレを体験するともう原神には戻れないぜ。
でも最終的に「終奏スキルでバフつけたアタッカーが共鳴開放して、あとは共鳴解放貯まるまで適当に通常攻撃連打する」みたいな戦闘は原神未満じゃねとも思う。
売りだったはずのパリィが「たまに敵が光るからタイミングよくボタンを押してね」ってブレイクチャンス以上でも以下でもないとはガッカリすぎたよ。
って感じかねえ。
コマンドRPGなんて今時やってられねーと舐めていたが、結局ソシャゲのアクションなんてボタンポチポチするだけになるんだから漫画やアニメでも見ながらコマンドRPGでええわってのが俺の結論かもですわ。
ガチでソウルライクじみたノリのスマホゲーアクションRPGでたら面白そうやなとは思うねえ。
Minecraft は、頭に浮かぶものなら何でも作れるブロックでできたゲームです。無限に材料が使えるクリエイティブモードで遊ぶことも、危険から身を守る道具を探すサバイバルモードで楽しむこともできます。クロスプラットフォームでシームレスに遊べる Minecraft: Bedrock Edition なら、ソロでも友達と一緒でも冒険に出かけられます。採掘できるブロックや探検できるバイオーム、友達になれる (または戦える) モブなどでいっぱいの、ランダムに生成される無限の世界を探索しましょう。Minecraft の遊び方はあなた次第… 思いのままに遊んでください!
Minecraft マーケットプレイス - マーケットプレイスで最新のコミュニティ製コンテンツを探しましょう! お気に入りのクリエイターによるユニークな世界、スキン、テクスチャ パックをお楽しみください。
スラッシュ コマンド - アイテムの譲渡、モブの召喚、時間の変更など、ゲームの機能に手を加えることができます。
アドオン - 無料のアドオンで、ゲームの遊び心地をさらにカスタマイズしましょう! IT に詳しい方なら、ゲーム内のデータドリブンな動作を変更して、新しいリソース パックを作成できます。
Realms と Realms Plus - Minecraft がホストするあなただけのプライベート サーバーである Realms では、最大 10 人の友達とのクロスプラットフォーム プレイがいつでもどこでも楽しめます。Realms Plus なら、150 を超えるマーケットプレイス アイテムがすぐに利用できるうえ、新作も毎月登場します。プライベートな Realms サーバーで友達とシェアしましょう。アプリ内で 30 日間の無料試用版をお試しください。
マルチプレイヤー - 無料の Xbox Live アカウントがあれば、最大 4 人の友達とのオンライン プレイが楽しめます。
サーバー - 無料の巨大マルチプレイヤー サーバーに参加して、何千ものプレイヤーと一緒に遊びましょう! コミュニティが用意した超巨大な世界を探索し、ユニークなミニゲームで競い合い、満員のロビーで友達の輪を広げましょう!
『Project Mugen』という新作ゲームの開発情報が公開された。
https://m.youtube.com/watch?v=ZhdXubIXA-U&feature=youtu.be
これを見て俺は驚愕した。ワイヤーアクションでビル街の空中を飛び回るモーションはただの『Marvel's Spider-Man』のパクリじゃないか！
こんなパクリゲーで勝負するなんて中華企業は自分でアイデアを生み出す発想力がないのだろうか。終わっている。
でもよく思い出すとワイヤーアクションで移動するゲームは『SEKIRO: SHADOWS DIE TWICE』やコーエーテクモゲームスが公開した『進撃の巨人』があったな。
SEKIRO の公開は 2019 年、Marvel's Spider-Man は 2018 年、進撃の巨人は 2016 年、ということはつまり……
なんてこった！
オリジナルは進撃の巨人で、スパイダーマンもSEKIROもProject Mugenも全部ただのパクリゲーだった！じゃあゲーム業界そのものが自分のアイデアで勝負しないクソカスパクリ泥棒社会だったってことか！見損なった！
しかもProject Mugen の罪はそれだけではない。このゲーム、なんと『オープンワールド・アクションRPG』なのである。
ヤバすぎる……オープンワールドは全部 GTA Ⅲ のパクリだ。スカイリムも、今流行っている原神もゼルダティアキンも、ポケモンSV も GTA Ⅲ をパクっているんだ……
あの任天堂ですらパクリに手を染めているなんて、ゲーム業界の闇は深すぎる…… マジで終わっているのかもしれない……。
しかもだ。Project Mugen はオープンワールドの都市のマップを自動生成で作ったらしい。
これは罪が深すぎる！
オープンワールドマップの自動生成は『No Man's Sky』で1800京個の惑星を作るために開発された技術だ。あるいは、『The Matrix Awakens:An Unreal Engine 5 Experience』でも都市の自動生成を開発していた。
こんなものまでパクるなんて、他人の努力を馬鹿にしているのか……。
いやまてよ、そもそもマップを自動で作るというアイデアは、ポケモンの不思議のダンジョンシリーズのような「ローグライク」ゲームで使われる技術だ。そのオリジナルは名前の通り1980年代からある『Rogue』だ。
ということは、ポケモン不思議のダンジョンも、Epic Gamesも Rogue をパクってんのか…… こいつら全員カス過ぎる…… ゲーム業界は本当に人格破綻者しかいないらしい。
そしてRPGは1981年の『ウルティマ』や『ウィザードリィ』のパクリだ。そもそもコンピュータRPGってのは、TRPGのパクリだ。呆れてもう言葉が出ない。
Project Mugen の罪はまだまだある。Project Mugen ではシーンに配置されてるオブジェクトを掴んで動かしたり、敵にぶつけたりする機能があるらしい。
これは『ゼルダの冒険 ティアーズ オブ ザ キングダム』のウルトラハンドのパクリだし、『SCARLET NEXUS』の念力のパクリだ！
そんでもって、物理演算エンジンをゲームに組み込むアイデアは『リトルビッグプラネット』のパクリだ！ゼルダもSCARLET NEXUSもパクリ泥棒だ！
だいたい、Project Mugen はキャラクターのセルルック(トゥーンシェーディング)な見た目からして、もう既にパクリだ。
最近のゲームだと原神も『BLUE PROTOCOL』もキャラクターの 3D モデルがセルルックに描写されているが、これは『GUILTY GEAR』シリーズのパクリだ。
ていうかセルルックとは「アニメ画のような」という意味なのだから、ゲームなのにアニメをパクっている！
これは文化盗用だ！ゲーム業界の内部だけじゃなくて外からもパクってくるなんて、社会の悪だ！ゲームならゲームのビジュアルで勝負しろよ！
そんでもって、GUILTY GEAR とかスマブラとかの格ゲーって言われるジャンルは全部ストリートファイターのパクリだ。
はあ。俺はゲームっていうのはどこを見てもパクリだらけの最悪の肥溜めなのが分かった。
こんなのは間違っている。ゲーム会社は他人の努力をパクらないで、オリジナリティで勝負しろ。
ワイヤーアクションも、オープンワールドも、アクションRPGも、物理演算も、プロシージャル生成も、セルルックも、クロスプラットフォームも、レイトレーシングも、3Dアニメーションも、全部先駆者がいる。
Appleお前なぁ・・・学習コスト高すぎんだよ！！！！！
ナンチャラKitとかよぅ・・・イノベーティブだって！？Appleデバイスでしか使えないやんけ！！！！！
VulkanとかFlutterとかのほうが話題になっちゃってる現状を見ろよ！！！！！
何故かわかるか！？
VulkanとかFlutterはほかのプラットフォームでも使えるからなんだよ！！！！！
お前どうせDirect3Dみたいな立場を夢見てんだろ！！！！！
macOSのゲーム環境がウンコなのDirectXのせいだろ！！！！！
なんでマイクソソフトの真似しようとしてんだよ！！！！！
Flutterが流行の兆しを見せたからってやっつけでSwiftUIなんて作りやがって！
そういう仕事するからSwift(SwiftUI)は未完成とかって言われるんだぞ！！！！！
いまだUI Kit使われてるのはそういうことやぞ！！！！！
WindowsのWSL2がそこそこ使えるLinux環境整備しちゃって開発者みんなWindowsだLinuxだと言い始めてる現状をマジで直視しろよ！！！
これでQualcommがまともに使えるラップトップ向けSoCでもリリースしてみろ！
M1のマイナーチェンジのくせにメジャーナンバー上げてマーケティングで劇的性能アップなイメージ振りまいてる場合じゃなくなるぞ！！！！！
ブランディングネームなんてお前の胸先三寸だってバレてんだよ！！！！！
Apple信者！いまのAppleの開発環境の学習コスト高すぎてマジで微妙だってのは知ってくれ！！！！！
そのコストを負っているのは開発者でWindowsやLinux、Android界隈がクロスプラットフォームを強化していて眩しく見え始めていることを認識してくれ！！！！！
Apple信者お前らだけがAppleの目を覚まさせられるんだ！！！！！
1つのIDEで開発をしクロスプラットフォーム対応することが流行っている昨今、自動でガベコレに頼っていてリソース管理経験に乏しい開発者はマジで底辺にしか漂流できないので覚えたほうが良いぞ。
そうは言ってもリソース管理めちゃくちゃ頑張らなきゃいけない仕事が無いんじゃ・・・
ライトなコンピュータユーザを一切合切無視してギークがギークのため情報共有するためのエントリ。
感想ははてブへ、質問はトラバに投げれば誰かが答えるんじゃないか？(他力本願)
セキュリティの懸念があるけれど通常モードはセキュアを維持するため機能制限があるので制限開放のため開発者は初手でデベロッパーモードにするしかない。
利用途中でデベロッパーモードにするとストレージがファクトリーリセットされるので注意。
Webでエンタメを楽しんだりWebツールを中心に利用するのであれば、5万円未満の低性能機で必要十分。
この用途では実質的にタブレットPCのような運用へなりやすいのでフリップする2 in 1機やタブレット機がオススメ。
ただし、Webベースのゲームは楽しめるがAndroid Appレイヤーを用いたゲームは非常に厳しいので諦めたほうが良く、そこそこの負荷の掛かるAndroid Appツールも鈍足でストレスになるのでWeb版があるならそっちを使ったほうが良い。
Core i7クラスのCPUや16GB以上のワーキングメモリ、SSDストレージなど高性能機でChromeOSを使うとその分だけ快適になる。
Android Appレイヤーを用いたゲームも快適に動き、ウマ娘クラスの3DCGなAndroid Appゲームも高速に動く。
しかし、高性能機は空冷ファンを搭載していることが多く、高負荷を掛ければファンは唸るしウルサイ。
Google Play StoreにてAABパッケージがほぼ強制になったとは言え、開発段階でx86_64を意識しないと処理が非効率になりがちのようなので、Android Appレイヤーを中心に運用したいと思っているのであれば素直にARM機を探してきたほうが良い。
1つのIDEで開発をしクロスプラットフォーム対応することが流行っている昨今、自動でガベコレに頼っていてリソース管理経験に乏しい開発者はマジで底辺にしか漂流できないので覚えたほうが良いぞ。
それがWeb系のフロントエンドでもバックエンドでもそうだから底辺から脱したいのであれば覚えろ。
しっかりリソース管理できているChromebook向けビルドはアーキテクチャによらずサクサクなのでクロスプラットフォームなビルドはマジで開発チームの腕が如実に反映される。
ちなみにSnapdragon 8 Gen1なChromebookの公式発表は今のとこ無いのでAndroid Appレイヤーをブンブン回すのは難しい。
メーカーはもうちょっと頑張れ。
Chromebookの大半はタッチスクリーンディスプレイを搭載しているし、Android StudioでAndroidManifest.xmlを何も考えずに生成すると勝手にChromeOSをサポートするので結果的にChromeOSで動くAndroid App数が多くなるという現象が起きている。
Android Studioが雑なのかXcodeが厳密なのかは意見が分かれると思うけど、タッチパッドでiOS App操作というセンスがクソなのは万人が納得するところだと思う。
ARM系のSoCであればワンチャンいける可能性はあるものの、市場に出ているChromebookの大半はx86_64でGPSモジュールを積んでいないのでGPSを使おうと思うとBluetoothあたりでGPSレシーバを接続するしか無い。
当然A-GPSは使えないので精度がそこまでではないから期待し過ぎに注意。
Android AppレイヤーではUSB over MIDIが使えるのでDTMあたりに活用することは可能なものの、iOSと比較してレイテンシがそこそこ大きくDTMに活用しようと思うユーザは不満を持ってしまうかも知れない(ハードにもよるけど0.5msecくらいズレる)。
そもそも既存のAndroid AppなDAWはVSTやLV2などの外部プラグインに対応していないのでAUプラグインが使えるiOSのほうがDTMへ向くんじゃないだろうか？
ただし、DAW単体でDTMを完結するとレイテンシはほとんど気にならなくなるので絶対にAndroid AppでDTMが不可能というわけでもない。
Linuxレイヤー側でDTMをするのはレイテンシが大きすぎるしJackも上手く動作しないのでオススメできない。
ChromeOS向けマルチタスクへ対応していないとAndroid Appはフロントエンド(プライマリ)からフォーカスが外れてバックエンドへ行くとスリープする。
Android Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちる。
まぁAndroid Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちるっていう部分はAndroidスマホで実行しても同じなので正直に言ってスリープされることを考慮しないデバックってAndroid App開発者は何やってんの？とは思う。
ICT教育で日本中の学生がChromeOSを使うようになっているので、ゲームであれツールであれ何であれChromeOS向けのマルチタスクは考慮しておくとスリープしたり落ちたりするAndroid Appよりも支持されるのは間違いないのではないか。
LXC/LXDなのでDockerに慣れ親しんでる人にはわかりやすいかも？
デフォルトのイメージはChromeOS向けにカスタムされたDebian。
別のLinuxディストリビューションへ置き換えることも出来るが一部機能が制限される可能性がある。
ChromeOSで動作するGoogle日本語入力とは別にLinuxレイヤー側で日本語入力を用意する必要がある。
選択できるIMは幅広いのでMozcだろうがSKKだろうが漢直だろうが何でもイケる。
ただ特殊なものを選ぶとChromeOS側と齟齬が発生するのでfcitx-mozcあたりが無難っちゃ無難。
ChromeOSへマウントされたUSB機器、というかシリアル接続された機器はLinuxレイヤー上から認識しない。
見掛け上で接続されているハードのすべてはソフトで仮想接続されているだけなので、一部経路から上手く認識しなかったりする。
つまりLinuxレイヤーではUSB Pass Throughが使えないが、Android AppレイヤーではUSB Pass Throughが使えるということ。
Linuxレイヤーでゲームやろうと思ってもUSBゲームパッド動かないのでマウスとキーボードで完結できるFPSみたいなゲームしか上手くプレイできないぞ。
言うなればAndroid Appレイヤーでスクリーンキャプチャ系のアプリによってLinuxレイヤーで動くGUIアプリをキャプチャしようと思ってもキャプチャできず撮像は暗転している。
ChromeOSがホストでLinuxレイヤーとAndroid Appレイヤーはゲストなのでそりゃそうなんだけど気付かないとハマる。
LXC/LXD on LXC/LXDになるので面倒くさくなること請け合いだ。
どうしても仮想環境がChromebookに欲しいのであればKVMとかのほうが安定している。
ただしゲストOS上へ仮想環境を構築しているという前提は認識しておくべき。
つまりゲストOSの制限はKVMも引き継ぐ。
ただしこれはDockerが導入できないという意味ではない。
自分で解決する気概があるのならばDockerは便利に使える。
CLIツール系は普通に動くのでWeb開発であれば何も意識しないで普通にできる。
ただ、PSD形式みたいなもんは扱いにくいのでWebデザイナーは悲しい思いをするかも知れない。
GIMPやInkscapeなども動くけれどデザイナーはAdobe使いたいんじゃなかろうか？
Android App向けIDEのAndroid StudioはChromeOS向けが存在するのでAndorid App開発が可能。
しかしデベロッパーモードでなければエミュレータや実機デバックに制限が発生するので注意。
UnityやUEを使いたいところだけれど、Linux版のUnityやUEは不安定なのでゲーム向けIDEが欲しいのであればGodotがオススメだ。
ライセンスはMITなので商用利用だってイケる。
3Dのほか2Dゲームもいける上に、最近のIDEよろしくマウスでポチポチとUIを作れるし、軽量動作、物理演算、日本語ドキュメントまで揃っているので中高生もガンガン使える素晴らしいIDEだ。
浅い部分を触っているうちはYoutubeを観たり、プリインストールされているGoogle Play StoreからAndoird Appをインストールして使うみたいな気軽な運用ができる。
言ってしまえばライトユーザの視点ではノートパソコンの形をしたAndorid機がChromebookだと言える。
しかし一度Linuxレイヤーへ手を出すとUbuntuという何でもできるようになったLinuxディストリビューションが存在する中で、昔懐かしい複雑怪奇なLinuxディストリビューションを体験することとなってしまう。
ただ、Chromebookで何でもやろうとするからそうなるだけで、APTからIDEをインストールしてちょっとした開発をするなんて使い方であるならば業務利用でも意外となんとかなる・・・というか何も意識しないで使える。
そもそもHTTP使えるなら今どきの開発は何とかなるので、Chromebookへ対してギークがゴチャゴチャ言うのはほぼ間違いなく不満を言いつつDIYを楽しんでる。
Ubuhtuならばアレができるコレができると言うならば最初からUbuntu使えよって話。
ギークとは不便を見つけてゴチャゴチャ言う、そういう鳴き声の動物なのだ。
少なくともGoogle系エコシステムとしてのChromeOSは非常に完成度が高くなりつつある。
Googleアシスタントは元よりAndoridスマホとの連携もよく、ハードウェアへもそこそこの投資ができるのであれば多くのChromebookではUSIペンが使えるし、USBポートはUSB-Cだ。
そこそこのChromebookは多くの場合HiDPIなIPS液晶でありグレアなのは気に食わないが美しい。
デベロッパーモードにするとセキュアさは下がるが普通に使えばローリングリリースのアップデートを無償で得られ、Gentoo LinuxベースなChromeOSは潜在的なマルウェアの絶対数がそもそもWindowsやMacよりも少ないという利点がある。
Bluetoothイヤホン・ヘッドフォン・ヘッドセットも使えるし、NestスピーカーやNest Hub、Nest Camを持っているのであればGoogleアシスタントからのコントロールが容易なのは想像が付くだろう。Android AppレイヤーはGoogleのホームマネジメントアプリであるGoogle Homeも動く。
大胆にも憎きCapsLockキーをデフォルトで殺し、Everything Buttonキーとして独自キーバインドを与えたのも面白い。
もちろんこれは選択するハードによるものの指紋認証でロックを解除することまでできる。
Googleエコシステムへ浸かっていてGoogleへ個人情報を捧げられるのであればChromebookはアリな選択肢だと断言できる。
敢えて欠点を挙げるのならば、たった一言で欠点を表現することが可能だ。
「Chromebookじゃなくても別に良くね？」
そう、ギークがLinuxを使いたいのであれば別にChromebookじゃなくても良い。
というかギークは別にLinuxじゃなくともHaikuであろうが超漢字Ⅴだろうが喜ぶ生き物だ。OSは別になんだって良い。
このエントリは単にChromebookという新しい沼へギークの皆さんをご案内しているに過ぎないのだ。
https://d.potato4d.me/entry/20220405-nodejs/
が話題になっているけど、本来人類に必要なのはクロスプラットフォームな実行環境であってNodeじゃない。
TSが流行ったのはJSがクソだから。BabelしなきゃいけないのもJSにトランスパイルしなきゃいけないからであって、必要なのはJVMやCLRのような言語実行環境。
Reactが流行ったのはshadow domだけど、必要なのはDOMじゃなくてちゃんとした「アプリ」開発用のイベントモデルとレイアウトマネージャ含むGUI環境。
フロント界隈の流行廃りって本質的な改善ってよりもほかの良い技術をいかにブラウザ/Electron等JSエンジンという限られた環境に持ち込んで幸せになるかがメインに見えるので地獄に見える。
「アプリ」書くのになんでドキュメント記述用のHTMLに今ものっかってんだよと。
MavenやらGemsができて依存管理楽になったとか、RailsがでたときのようなCoC良いねとか開発の考え方を変えるフレームワーク、 rspec/Cucumberがでてテスト最高とか、c10kも怖くない非同期I/Oとか、好きな言語が使えるJVM/CLRそもサーバーならrustでもgoでも好きなものが動くとかとか本来の開発を楽にするという意味のブレークスルーってあんまりみられない気がしている。なんでフロント界隈の新技術ってあんまりわくわくしない。
逆にちゃんとしたクロスプラットフォーム実行環境がブラウザしかないということなんだけど、ブラウザなかなか進化しないし RIA は Apple 様が切り捨てるからなぁ。
ということですべてはブラウザが悪い。JavaScript 以外がちゃんと動くクロスプラットフォームのGUI環境が必要。でもプリインでモバイルでも動いてOSから独立して協調して作られていて、Webという既存の大量の資源にアクセスしやすいものは現時点で実質ブラウザ一択。つまりWASM に期待。次にHTMLであるべき文書はともかくSPAなんてもう「アプリ」なんだからHTML手書き文化もうやめてネイティブアプリ並みの GUI 作成環境も復権しよう。
するとクライアントでも好きな言語が使える。そして同じ言語がいいとサーバサイドで Node.js を使う必要もなくなりへっぽこプログラマが Node のイベントモデルを理解せずに使うこともなくなる。
そしてそれらができたときに Node というか JS/HTML の呪いから解放され人類に平和が訪れるのだ。君はその後も Node.js を使っても良いし使わなくてもいい。
例えばソーシャルゲーム的要素（基本プレイ無料、強さに関係するガチャ）を詰め込んだボーダーブレイク家庭版はソシャゲ扱いされてないわけよ。プラットフォームがPS4だから。
PUBGモバイルは「PUBGのスマホ版」って扱いされがちなのに、パクリゲーの荒野行動はソシャゲあつかいされたりもする。
使ってる側に多分「こういうもんだからソシャゲ」っていう基準がないように思える。
まぁなんとなくだけど
「無料ゲーム」「強さに関係するガチャ」「スタミナ制」「モバイル最適化」「同システム/クロスプラットフォーム以外のスマホ展開」
最初に結論から書くと、「毎日新聞さん正論すぎる」「だけどまだちょっと時間あるで」。
『「COCOA」がグーグルとアップル基本ソフト最新仕様に未対応』
→ https://mainichi.jp/articles/20210315/k00/00m/020/165000c
うん。コード見てる人はだいたい知ってる。
まあ、そうですね…。
COCOAの動作の基盤となっているのは、Exposure Notification API（曝露通知API）というやつで、GoogleとAppleが共同で開発した、AndroidとiOSの両方で使えるAPI。OSと近いところで動くライブラリみたいなもので、おかげでBluetoothを使っても電力消費は最小限で済むし、アプリがプライバシー関係でよからぬ手出しができないようにもなってる。iPhoneではiOSの一部として組み込まれているし、AndroidはGoogle Play経由の「Google Play 開発者サービス」の新しい版に含まれてる、みたい。
このAPIにはバージョンがあって、V1ってのが最初のやつで、もう少し検出方法が洗練されたV2ってのがある。Exposure Notification APIのセットの中にV1とV2が重複しつつ混在してて、今から作るアプリなら使えるAPIバージョンをアプリ側で確認して、使える方を使う、という感じになるかと思う。
現在、COCOAがまがりなりにも動いていることからも分かるように、API V2が使えるようになっても、後方互換性のためにV1も使えるようになっている。Apple/GoogleはV1のメソッドとかには「deprecated」（使用不可）っていう印をつけて、今後は使わないように、と言ってる。
「deprecated」になったやつは、Apple/Googleは「もう使わんでね。いつ使えなくなっても文句言わんでね」という扱いをする。だから、「ソフトの更新次第で作動停止」という指摘は間違いではない。間違いではないが…。
Apple/Googleのデベロッパならよく知っていると思うけれど、「deprecated」になったからといって、そのAPIを予告なく使えなくすることは、まず、ないのです。
増田はIOSのデベロッパなのでiOSの例をあげると、画面を表示する基本的な部品であるところの UIWebView っていのうがあったんだけど、これはiPhone OSの頃からあった古い古い部品で、これまでずっと使われてきた。これはwebの画面を表示するのと同じやりかたができるので、iOSのアプリはほぼみんな使ってたんだけど、いろいろ問題もあるので、iOS 8の頃に WKWebView っていう新しい部品を出したのです。で、UIWebView をdeprecatedにしたのがiOS 12のとき。
ここからAppleは、「UIWebViewを使ったアプリをApp Storeに提出したら警告するからね」→「今後新規アプリやバージョンアップのときUIWebView使ってたらリジェクトするからね」→「UIWebView使ってるアプリはAppStoreから削除するからね」という感じにデベロッパの様子を見て期限を延長したりしながら段階を踏んで、ほんとに削除（一時的な非表示）始めたのは去年の12月ですよ。しかもiOS 14でもまだ既存アプリのUIWebViewは動く。
もちろん、滅茶苦茶使われていたUIWebViewと比べたら、Exposure Notification APIみたいなマイナーなAPIでこんな丁寧なことはやらないかもしれないけれど、でも重要度で言ったらExposeure Notification APIなんて「超重要」でしょ。V1が全然使えないならまだしも、一応動いてるし。
Exposure Notification API V1は、使えなくなる前には必ずデベロッパに期限を知らせるはずで、いきなり切るはずはない（ないよね（ないんじゃないかな（まちょっと覚悟はしておけ）））。
だから、COCOAが急に使えなくなっちゃう！ と不安になる必要は、当面はないと思っていい。かな。
これはスレたデベロッパであるがゆえの油断であると言われてしまえば、そのとおりです。「deprecated」は「deprecated」。普通のプロジェクトなら、すぐさま対応を検討して、バージョンアップ計画を立てるのが正しい。普通のプロジェクト、なら。
記事中では「21年2月になって、ようやく最新使用に対応するための具体的な検討に着手した」って言ってて、まあこれはダメなんだけど、そもそもプロジェクト運営がグダグダだったんでしょうがねーんじゃね？ というのがいちヲチャーとしての感想ではある。だって、Android版動いてなかったんじゃよ？ プロジェクト立て直す時間はあるはずなので、体勢立て直してから検討してもいいかな、という気はしている。それくらいの時間はある。はず。
そういう意味で、毎日新聞の記事はちょっと叩きすぎな感はある。正論ではありますよ。正論では。
で、ここでぶっちゃけてしまうと、実はもうCOCOAは要らないっちゃ要らないのです。
保健当局がアプリを作れない／作らない国／地域のために、iOSでもAndroidでも、AppleとGoogleが用意したCOCOA相当機能「Exposure Notification Express」というやつが、OSに組み込まれている。これを使うことにすれば、当局はサーバ側のバックエンドだけ用意すればいい。
『グーグルとアップルの新型コロナ接触確認機能に新たな仕組み「Exposure Notification Express」――日本には影響なし』
→ https://k-tai.watch.impress.co.jp/docs/news/1274374.html
『Supporting Exposure Notifications Express』
「だけ」って簡単な言うな。そりゃ大変だけろうれど、わざわざ使いづらい／どマイナーなミドルウェアXamarin（Microsoft謹製）使って、頑張ってクロスプラットフォームなアプリを開発／運用するよりはずっと負担は少ないよね（必要な予算も）。
もう、バンザイして、Expressにしたらいいんじゃね？ と、増田は考えるんじゃよ。知らんけど。
COCOAは嫌いになっても、Exposure Notificationの仕組みは嫌いにならないでください…(´・ω・`)
COCOAは出自がアレで、採用の意思決定が不透明で、契約もテキトウで、アプリ運用も誰が何をどうしたらいいのかわかってない／身動きができない、という悲惨なアプリです。
でも、2月以降変わってきたんですよ。COCOAの立て直しチームにCode for Japanの人やオープンソースの知見を持った方が参加して、githubでのissue解決の動きも再開している。ちょっと見てみてくださいよ、いろんな人が寄ってたかってコードを検証して、それが反映されつつあります。
『Issues・cocoa-mhlw/cocoa・GitHub』
→ https://github.com/cocoa-mhlw/cocoa/issues
いままでよりはまともに動くようになるはず。
前述のように、Exposure Notification APIで消費されるCPU資源も、通信も、ストレージも、バッテリも微々たるものです。
Exposure Notification API自体は非常によくできており、プライバシーに関しても、よくまあここまで、というくらい考慮されています。アプリ側でいろんな悪さを仕込むことは技術的には可能ですが、小細工を仕込んでもAppleやGoogleのアプリ審査で弾かれます（通常の小細工入りアプリが弾かれる程度には）。運営への不信からプライバシーについても疑ってしまう人もいるけど、COCOAはその点まず心配ありません。
だから、渋々でいいので、もうしばらくスマホの奥においといてもらえませんか。そんなにお邪魔にはならないですよ？
そして万が一曝露通知が届いたりしたら宝くじ大当たり級の驚きが（うれしくない）
