あなたがオペレーティングシステムになるビデオゲーム
(plbrault.com)- You’re the OS は、プレイヤーがオペレーティングシステムの役割を担い、CPUコア、プロセス、メモリページ、スワップ領域を管理して、ユーザーによる再起動を防ぐゲーム
- 基本の流れは、待機中のプロセスをCPUに割り当て、アクティブなプロセスを取り外す方式で、長く放置されたプロセスは starvation 段階 を経て終了する
- 時間が経つほどプロセス数とメモリ圧迫が増し、ディスク上のページをRAMに戻す メモリスワッピング まで自分で処理しなければならない
- 実装は Python/Pygame ベースで、pygbag により WebAssembly ビルドを作成し、ブラウザでも実行できる
- 正確なオペレーティングシステムのシミュレーションではないが、その前提を明確にすれば、プロセススケジューリングやRAM不足の状況を説明するのに活用できる
オペレーティングシステムになるゲームのアイデア
- このゲームは、プレイヤーがオペレーティングシステムとなって CPUコア、プロセス、メモリページ、スワップ領域 を管理するという構想から始まった
- 目標は、ユーザーがシステムが遅すぎると感じないようにプロセスへCPU時間を割り当て、必要なときにメモリページをスワップすること
- シンプルな2Dゲームに合わせ、完全なゲームエンジンではなく Pygame を選んだ
- Python をもう一度使ってみたかったことも選定理由だった
- Pygame は pygbag を通じて WebAssembly にコンパイルでき、ブラウザ実行に向いている
- 開発期間は8か月のあいだに散発的に数週間ほどだった
プロセススケジューリングとゲーム終了条件
- ゲームの中心となる操作は プロセスとCPU の管理
- 待機中のプロセスをクリックすると、利用可能なCPUに割り当てられる
- アクティブなプロセスをクリックすると、そのCPUから取り外される
- 待機中のプロセスは時間の経過とともに、色と絵文字で表示される6段階の starvation レベル をたどる
- 最終段階に長く留まりすぎると、ユーザーがそのプロセスを終了する
- 10個のプロセスが終了すると、ユーザーがオペレーティングシステムであるプレイヤーを再起動し、ゲームは終了する
- 長く生き残るには、各プロセスが starvation 段階をすべて経る前に十分なCPU時間を得る必要がある
I/Oとメモリスワッピング
- アクティブなプロセスはI/Oイベントを待って blocked 状態 になることがある
- blocked プロセスはCPU時間を無駄にするため、CPUから取り外したほうがよい
- I/Oイベントは、発生時に見た目が変わるボタンをクリックして処理する
- 時間が経つにつれてより多くのプロセスが登場し、難易度が上がる
- ある時点から、全プロセスが使うメモリ量がRAMを上回り、RAMとディスク間のページスワッピング が必要になる
- アクティブなプロセスがディスク上のページにアクセスしようとすると、プロセスとそのページが点滅する
- この表示を見て、必要なページをスワップしなければならない
- ディスク上のページを待つプロセスは、そのページがRAMに戻るまで blocked 状態のままとなる
- blocked 状態が長く続きすぎると starvation 段階を進み続け、最終的に終了することがある
難易度とカスタム設定
- ゲームには複数の 難易度レベル がある
- 難易度はCPU数、RAM容量、開始時に存在するプロセス数、I/Oイベント発生確率などに影響する
- カスタムモード では、これらの設定をそれぞれ独立して調整できる
教育的価値と限界
- このゲームはまず ゲーム であり、現実性よりも遊べることを優先して設計されている
- 実際のオペレーティングシステムを正確に描写していない部分がある
- プレイヤーが実際のコンピュータ並みに素早く反応することは想定していない
- プロセスは現実の一般的なプロセスよりもはるかに少ないメモリページしか使わない
- ユーザーが新しいプロセスを無限に実行し続ける構造は、難易度を上げるためのゲームメカニクスである
- 教育目的で作られたものではないが、正確な描写ではないことを明確にすれば、オペレーティングシステムの原理を紹介するうえで価値があるかもしれない
- プロセススケジューリング と メモリスワッピング を説明する例として使える
- CPUコアが多いとはどういうことか、RAMが不足すると何が起きるかを示せる
WebAssemblyコンパイルと配布
- WebAssembly へのコンパイルは、pygame-web ドキュメント のおかげで予想より簡単だった
- 主な手順は pygbag のインストールと、ドキュメントにあるコード修正の適用
- 最大の問題は、絵文字レンダリングに使っていた pygame-emojis ライブラリが pygbag と一緒に動作しなかったこと
- 代わりに OpenMoji から SVG ファイルをダウンロードした
- GIMP でサイズ調整し、PNG として書き出して使用した
- ブラウザ版は基本的にデスクトップ版と同じ比率を保ちながら、ブラウザのビューポートに合わせてサイズ調整される
- デスクトップ版がより小さいウィンドウサイズを使うと、画面が引き伸ばされて見えることがある
- このゲームはレトロスタイルなので、ピクセル化はそれほど深刻には感じられなかった
- ゲームは itch.io でブラウザからプレイできる
- ソースコードは GitHub で公開されている
1件のコメント
Hacker News のコメント
面白そうなアイデアとして、デフラグゲームが思い浮かぶ。基本的には円形配置の Tetris で、よく使うデータブロックは外側のトラックへ、古いファイルやアーカイブ系のファイル形式は内側のトラックへ送るほど得点が高くなる、という感じ
昔、グラフィカルなデフラグツールが魔法のように動くのを見るのが好きだったし、デフラグゲームが出たら本気で遊んでみたい
見下ろし型の 2D ゲームで、大きな空の倉庫に一人でいる。一定間隔でトラックが奥にいろいろな品物を降ろし、手前のカウンターでは何人かが特定の品物を要求する。やることは、要求をできるだけ早く処理できるように倉庫内の品物を配置すること。色、機能、名前など、自分に合ったやり方で整理すればいい
ゲームが進むにつれて、トラックはより多様な品物を運んでくるようになり、たいてい複数のカテゴリーにまたがる品物も増え、要求もだんだん複雑になる。最後には、ゲーム全体を通じて倉庫がどう変化したかをタイムラプスで見せてくれるので、戦略が時間とともに進化していく様子が見られる
かなりよくできていてシンプル。実際、HN のコメントで開発者の一人を通じて知った
https://boardgamegeek.com/boardgame/376284/defrag
https://www.defraggame.com
昔はこれらよりももっと直接的な模倣に近い古いゲームもいくつか遊んだ記憶があるが、他の人が見つけられるかは分からない
Ender's Game みたいに、トッププレイヤーが自分でも知らないうちに、どこかの重要インフラのメモリを割り当てていると想像するといい
https://xkcd.com/1897/
この Web サイトを半文読んだだけで、完全に納得した
こういう問題を理解する最良の方法の一つだ。「これから君がメモリ管理者だ。幸運を祈る」
アイデアが本当に良い。かわいく仕立てて、レストラン経営シミュレーションみたいにもできそう。ただしレストランがコンピューターで、客がリソースという形
Human Resource Machine もこの点で素晴らしかった。ある瞬間に「待って、今自分は連結リストを作ったのか？」と思った記憶がある
実のところ、人間の生活は一種のオペレーティングシステムに近いと思う。私たちは毎日、タスク、リソース、入出力、ストレージ、キャッシュ、状態を扱いながら生きている
ダッシュボードはオペレーティングシステムに不可欠なツールで、人間規模では銀行、ToDo、カレンダー、受信トレイのようなものだ。だから多くの「自己啓発」の概念は、オペレーティングシステムのベストプラクティスとしてきれいに翻訳できる。たとえば割り当て管理のための FIFO や LIFO、デッドロックを解消するための事前計画、並行性の管理、ジャストインタイムのガベージコレクションなど
[0] https://algorithmstoliveby.com/
たとえば歯車が先端技術だった時代には、頭の中で歯車が回る絵を描いて、考える行為を歯車の動きになぞらえた人たちがいた。漫画などでは、今でも時々そういう表現を見かける気がする
https://en.m.wikipedia.org/wiki/Autonomic_nervous_system
ちなみにこれは 9 月 30 日に HN に投稿されたが、まったく注目されず、投稿者も自分のコメントを削除した
その時にも書いたが、本当に良いコンセプトだ。レベルを追加するといい。たとえば、興味深い製品の中のマイクロコントローラー、スマートフォン、SaaS 企業のロードバランサーや API サーバーのようにレベルを分ければ、概念を一つずつ導入できる。そうすれば大学レベルのオペレーティングシステムの授業になる
自動化のためのちょっとしたプログラミングを入れて、オペレーティングシステムのキャッシュアルゴリズムまで深掘りできるとよい。LRU はいい。高校卒業前に終えられたかもしれない授業だ
https://news.ycombinator.com/item?id=36938032
すばらしいアイデアだけど、自分には難しすぎる。通常モードでもゲーム開始20秒で狂ったようにクリックする羽目になり、ブロックされたプロセスを巡回させても赤いプロセスが積み上がる
いくつかのプロセスは入出力イベントが結局来なくて死んだ。イージーモードも同じか、むしろさらに難しい気がする。メモリが問題になるところまで行くことすらないし、この速度なら行きたいとも思わない
年を取ったのかもしれないし、オペレーティングシステムになるのがストレスだというのは分かるけど、自分の仕事もすでにストレスだ。もう一つ仕事が欲しいわけではない
最初は簡単に始まり、だんだん難しくなりつつも自分の快適ゾーンのすぐ外側にとどまるくらいの、もっと寛容なペースなら、とても面白いゲームになり得る
こういうゲームには大きな未来がある
UnityやUnrealのようなゲームエンジンが提供できる範囲を超えて革新するゲームは、設計上、最近出ているものより成功しやすい方向へ進んでいる
エンジン利用者が触れないほど領域の外にある超オタク向けゲームを作れば、別リーグに立てる。ゲームの見た目がひどくても、面白くて使えるならそれでいい
インディーゲームは、5年前の意味でのインディーゲームという点では死んだ。今はこういうものが新しいインディーゲームだ。GG。ちなみに自分は商業タイトルを2本以上出した、失敗したインディー開発者だ
Zachtronicsが止まってしまったのは残念だ。彼らは常に先を行っていた
それにこのゲームはUnityでも作れそうだ
「予想外のブレイクスルーになってゲームの方向性を変えるヒット作になる」という意味なら、どちらにしても確率は極めて低いが、枠の外にあるゲームの方がその確率は高いかもしれない
ホームランの確率は高いが、アウトになる確率も高く、ヒットを打つ確率は低い
ここ数年にも技術オタク向けゲームはいくつもあったが、ヒット作と呼べるものはなかった。おそらく自分のゲームは作れるだろうが、観客層が本質的に小さいので、成功の上限も限られる。今後これが変わるとも思えない
むしろ逆の可能性が高い。若い世代はあまりオタク化しておらず、低レベルの題材や技術からさらに遠ざかっているように見える
ゲームが高い使用率で難しくなるにつれて、マイルストーンや性能目標を達成して得たトークンで、小さな反復作業を自動化するアップグレードを「購入」できるようにすべきだ。Universal Paperclipsみたいな感じだ
その後、単純な自動化を妨げる病的なワークロードを投げつけ、ユーザーが手動で解かなければならないようにする。するとユーザーは少し良い自動化を買うが、また少し病的なワークロードに阻まれる。こうしてゲーム進行のループが完成する
そのうちオペレーティングシステムが作業を自動化できるようにスクリプト言語を提供するんだろう？
ああ、分かった……
とてもクール。先週投稿されていたゲームを思い出した。Defcon関連だったかな？ オペコードが入ったTetrisブロックのような四角形が落ちてきて、ユーザーは最大の数を「スコア」メモリレジスタへ混ぜ込むルーブ・ゴールドバーグ式のシーケンスを配置しなければならないゲームだった
https://news.ycombinator.com/item?id=37083309