--- title: "pygame-ceとは？pygameとの違い・インストールと移行判断【2.5.8対応】" url: "https://www.issoh.co.jp/tech/details/11391/" published: 2026-03-17 updated: 2026-10-13 categories: ["Python"] publisher: "株式会社一創" --- # pygame-ceとは？pygameとの違い・インストールと移行判断【2.5.8対応】 pygame-ceは、Pythonの2Dゲームライブラリpygameから分岐したディストリビューションです。名前が似ているうえに`import pygame`という書き方まで共通なので、どちらを入れればよいのか、両方入れても問題ないのかが分かりにくくなっています。この記事では2026年10月時点のPyPI・GitHub・実際の実行環境から取った値をもとに、両者の差分、インストール手順、既存コードを移すかどうかの判断基準を整理します。 ## まとめ：pygame-ceとpygameの選択基準 - pygame-ceは公式に「元コア開発者によるupstream pygameのfork」と定義されたディストリビューションで、パッケージ名は`pygame-ce`、import名は`pygame`のままです。 - 最新版はpygame-ceが2.5.8（2026年8月9日公開）、本家pygameが2.6.1（2024年9月29日公開）です。 - Python 3.14以降ではpygame 2.6.1の配布wheelが存在せず、実質的にpygame-ceを選ぶことになります。 - 両者は同じ`pygame/`ディレクトリを配布するため併存できません。`pip uninstall pygame`を先に実行します。 - どちらが入っているかは`pygame.IS_CE`で判別できます。pygame-ceなら1、本家pygameにはこの属性がありません。 - ブラウザで遊べる形にするならPyScriptの`py-game`（実験的機能）かpygbagを使い、メインループを`asyncio`対応に書き換えます。 ## pygame-ceが本家pygameから分岐した経緯 ### 公式が示す「元コア開発者によるfork」という定義 前提として、pygameはSimple DirectMedia Layer（SDL）をはじめとする複数のライブラリの上に構築された、クロスプラットフォームのフリーかつオープンソースなライブラリです。ウィンドウ生成・画像描画・音声再生・入力処理といったゲームに必要な土台をPythonから扱えるようにするもので、ゲームエンジンのようなGUIエディタは持ちません。この性格はpygame-ceでも変わりません。 そのうえでpygame-ceの[GitHubリポジトリのREADME](https://github.com/pygame-community/pygame-ce)は、この配布物を「pygame - Community Edition」と呼び、「It is a fork of the upstream pygame project by its former core developers.」（upstream pygameプロジェクトの、その元コア開発者によるforkである）と定義しています。分岐の目的についても、より頻繁なリリース、継続的なバグ修正と機能追加、そしてより民主的なガバナンスモデルの3点を掲げると明記されています。開発体制の話であって、別のライブラリを新規に作り直したわけではありません。 GitHubのリポジトリ`pygame-community/pygame-ce`は2023年2月9日に作成され、[PyPIのpygame-ceページ](https://pypi.org/project/pygame-ce/)での最初の公開は同年2月13日のバージョン2.1.3です。バージョン番号を1から振り直さず本家の続きから始めている点も、fork元との連続性を示しています。 ### 本家pygameとpygame-ceのリリース実績の差 更新頻度の差は、公開日を並べると数字で確認できます。 | 項目 | pygame-ce | pygame（本家） | | ---------------------- | ----------------- | ----------------- | | 最新版 | 2.5.8 | 2.6.1 | | 最新版の公開日 | 2026-08-09 | 2024-09-29 | | 直前版の公開日 | 2026-03-02（2.5.7） | 2024-06-25（2.6.0） | | PyPI累計リリース数（開発版含む） | 31 | — | | 既定ブランチの最終コミット | 2026-09-26 | 2025-10-05 | | GitHubスター数（2026-10-13） | 1,688 | 8,968 | スター数は本家が5倍以上ありますが、この数値だけでは現在の保守状況や更新頻度は判断できません。直近の動きを見ると、[PyPIの本家pygame](https://pypi.org/project/pygame/)は2024年9月のリリースを最後に約2年間バージョンが上がっておらず、[本家のGitHubリポジトリ](https://github.com/pygame/pygame)も既定ブランチへの最終コミットが2025年10月で止まっています。一方のpygame-ceは3年半で31回リリースし、直近も更新が続いています。 ### 「pygameは開発終了したのか」に対する事実ベースの回答 本家pygameのリポジトリが公式に開発終了を宣言した事実は確認できません。アーカイブもされていません。したがって「開発終了」と言い切るのは正確ではないというのが結論です。 ただし利用者の判断材料としては、宣言の有無より配布物が更新されているかどうかが効きます。本家2.6.1の配布wheelは後述のとおりPython 3.13までです。Python 3.14以降ではソースからのビルドが必要になり、成功するかどうかは手元にSDLの開発環境があるかに左右されます。宣言としては継続中、実務上は新しいPythonに追随していない、という二段構えで理解しておくと判断を誤りません。 配布側はすでにこの実態に合わせて動いています。Linux向けパッケージ集のnixpkgsは、2026年1月3日の[コミット「python3Packages.pygame: switch to pygame-ce for python>=3.14」](https://github.com/NixOS/nixpkgs/commit/6c60114666b9d95b8ee55b537457b94b46e301a5)で、Python 3.14以降の`python3Packages.pygame`が既定でpygame-ceを指すように変えました。従来の本家は`pygame-original`という名前で残しています。Pythonの公式フォーラムでも、2026年5月の[「Python 3.14でPyGameとOpenGLをインストールできない」という相談](https://discuss.python.org/t/cant-install-pygame-and-opengl-on-python-3-14/107506)に対し、PyGameは現在信頼できる形で保守されておらずコミュニティがpygame-ceへforkした、という回答が付いています。 ## pygame-ceとpygameの実差分 ### 対応Pythonバージョンを分けるwheelタグ PyPIのメタデータ上、pygame-ce 2.5.8の`requires_python`は3.10以上、pygame 2.6.1は3.6以上です。この表記だけを見ると本家のほうが広く見えますが、実際に配布されているwheelのPythonタグを並べると上限が逆転します。 | 配布物 | CPython向けwheelタグ | 対応Python | | --------------- | --------------------------------------------------------- | ---------- | | pygame-ce 2.5.8 | cp310 / cp311 / cp312 / cp313 / cp314 / cp315 | 3.10から3.15 | | pygame 2.6.1 | cp36 / cp37 / cp38 / cp39 / cp310 / cp311 / cp312 / cp313 | 3.6から3.13 | [pygame-ce 2.5.8のリリースノート](https://github.com/pygame-community/pygame-ce/releases/tag/2.5.8)は、この版でPython 3.15対応を追加し対応範囲がPython 3.10から3.15になったと述べています。逆に本家2.6.1はcp313が上限です。 この差はエラーとして表に出ます。Python 3.14.6の仮想環境で`pip install pygame`を実行すると、適合するwheelが見つからずソースからのビルドに切り替わり、`SDL.h`を見つけられずコンパイルが失敗します。表示されるのは次のメッセージです。 ``` ERROR: Failed building wheel for pygame Failed to build pygame error: failed-wheel-build-for-install ``` SDLの開発ヘッダを自前で用意すればビルドできる余地は残りますが、コマンド1本で入らない時点で初学者向けの選択肢ではありません。[Python 3.14のJITコンパイラとは？有効化の手順と実測、フリースレッド版と新機能](/tech/details/9409/)で触れているような新しいランタイムを使うなら、ゲームライブラリ側はpygame-ceに寄せる前提で環境を組むことになります。 macOS向けwheelの作り方にも違いがあります。pygame-ceはIntelとApple Siliconの両対応バイナリを1ファイルにまとめたuniversal2形式で配布し、本家はx86\_64とarm64を別ファイルに分けています。どちらでも導入はできますが、CIで特定アーキテクチャのwheelを取りに行く運用をしている場合はファイル名の形が変わる点に注意が必要です。 ### pygame-ceだけに同梱されるモジュール 両者のwheelを展開して`pygame/`配下のファイルを突き合わせると、pygame-ce 2.5.8にだけ入っていて本家2.6.1には存在しないモジュールが確認できます。 | モジュール | 内容 | 安定度 | | --------------- | ------------------------------------- | ---- | | pygame.window | pygame.\_sdl2.videoを公開API化したWindowクラス | 安定 | | pygame.system | 搭載RAM・電源状態・優先ロケール等の取得 | 安定 | | pygame.typing | Point・RectLike・ColorLike等の型エイリアス | 安定 | | pygame.geometry | CircleとLineのオブジェクト | 実験段階 | 各モジュールの仕様は公式ドキュメントの[pygame.Window](https://pyga.me/docs/ref/window.html)・[pygame.system](https://pyga.me/docs/ref/system.html)・[pygame.typing](https://pyga.me/docs/ref/typing.html)の各ページにまとまっています。本家でウィンドウを直接扱う場合は`pygame._sdl2.video`配下のクラスを使う必要があり、アンダースコア始まりの内部モジュールに依存する形になります。pygame-ceはこれを`pygame.Window`として公開APIに引き上げました。`pygame.typing`が入ったことで、型ヒントを書くときにライブラリ側が用意したエイリアスをそのまま使えます。 逆方向の差もあります。本家に含まれる`fastevent`、`draw_py`、`threads`はpygame-ce 2.5.8には同梱されていません。これらを直接importしているコードは移行時に書き換えが必要です。 ### 実行中に判別するpygame.IS\_CE どちらが入っているかはimport名からは分かりません。判別には`pygame.IS_CE`を使います。 ``` import pygame print(pygame.ver) print(getattr(pygame, "IS_CE", 0)) print(pygame.get_sdl_version()) ``` pygame-ce 2.5.8をPython 3.14.6で実行した出力は次のとおりです。1行目はimport時に自動表示されるバナーです。 ``` pygame-ce 2.5.8 (SDL 2.32.10, Python 3.14.6) 2.5.8 1 (2, 32, 10) ``` 本家pygameの`__init__.py`には`IS_CE`という名前が1か所も現れないため、そのまま属性参照すると`AttributeError`になります。上のように`getattr`で既定値0を指定しておけば、どちらの環境でも落ちずに分岐できます。CIやバグ報告のテンプレートに1行入れておくと、環境差の切り分けが速くなります。 ## pygame-ceのインストールと本家との競合回避 ### pipとuvでpygame-ceを導入する手順 pipで入れる場合は次のコマンドです。パッケージ名にはハイフンが入ります。 ``` pip install pygame-ce ``` uvを使うプロジェクトでは、依存としてそのまま追加できます。 ``` uv add pygame-ce ``` 公式READMEは、システムのPythonを汚さないために仮想環境を作ってからインストールする手順を案内しています。Linuxディストリビューションによっては、システムPythonへのpip installが外部管理エラーで拒否されるため、この手順が事実上の必須になります。 ``` python3 -m venv venv source venv/bin/activate pip install pygame-ce ``` 仮想環境そのものの選び方は[仮想環境とは？venv・コンテナ・仮想マシンの違いと隔離レベルの選び方を実装者向けに解説](/tech/details/13536/)、uvの使い方は[uvとは？Pythonの環境構築・パッケージ管理・バージョン管理の使い方を徹底解説](/tech/details/4384/)にまとめています。 ### pygameとpygame-ceを同時に入れてはいけない理由 pygame-ceの公式リリースノートは、インストール手順の先頭に次の1行を置いています。 ``` pip uninstall pygame # (if previously installed, to avoid package conflicts) pip install pygame-ce --upgrade ``` 理由はwheelの中身を見ると明確です。pygame 2.6.1のwheelは`pygame/`配下に608ファイル、pygame-ce 2.5.8は同じ`pygame/`配下に666ファイルを配置します。配布名は違ってもインストール先のディレクトリが同一なので、後から入れたほうが前のファイルを上書きし、片方をアンインストールするともう片方も壊れます。両方入った状態で発生する`ModuleNotFoundError`や不可解な属性エラーの多くはこれが原因です。 すでに混ざってしまった環境は、個別に消すより仮想環境を作り直すほうが確実です。 ### 導入直後のバナーで確認する3つの値 pygame-ceは`import pygame`の時点でバナーを標準出力に表示します。ここに必要な情報が3つ揃っています。 ``` pygame-ce 2.5.8 (SDL 2.32.10, Python 3.14.6) ``` 先頭が`pygame-ce`であれば本家ではないこと、括弧内の第1項が実際にリンクされているSDLのバージョン、第2項が動いているPythonのバージョンです。想定と違うPythonが使われている場合は、仮想環境の有効化に加え、IDEのインタープリター設定や実行コマンドの参照先を確認します。 なお`python -m pygame --version`は使えません。pygameパッケージには`__main__`が用意されておらず、`No module named pygame.__main__`で終了します。配布物としての名前とバージョンを確認したいときは`pip show pygame-ce`を使ってください。 ## 最小構成で動かすpygame-ceのゲームループ ここからはpygame-ceを初めて動かす人向けに、最小構成のコードで一巡を確認します。公式ドキュメントもクイックスタートの冒頭でゲームループの組み方を最初の関門として挙げており、ここを押さえれば個々のAPIは後から足せます。 ### 実行を確認した最小のメインループ ウィンドウを開き、イベントを処理し、状態を更新して描画するという一巡が、pygameとpygame-ceに共通する骨格です。次のコードはpygame-ce 2.5.8で実際に実行し、例外を出さずに動作することを確認したものです。円が左右の壁で折り返します。 ``` import pygame pygame.init() screen = pygame.display.set_mode((480, 360)) pygame.display.set_caption("pygame-ce minimal loop") clock = pygame.time.Clock() x, speed = 40.0, 180.0 # 1秒あたり180ピクセル running = True while running: dt = clock.tick(60) / 1000.0 # 直前フレームからの経過秒 for event in pygame.event.get(): if event.type == pygame.QUIT: running = False elif event.type == pygame.KEYDOWN and event.key == pygame.K_ESCAPE: running = False x += speed * dt if x > 440: x, speed = 440.0, -abs(speed) elif x < 40: x, speed = 40.0, abs(speed) screen.fill((16, 20, 28)) pygame.draw.circle(screen, (120, 200, 255), (int(x), 180), 24) pygame.display.flip() pygame.quit() ``` 行数は30行ほどです。`pygame.event.get()`はイベントを取り出すと同時に内部処理を進めます。イベントを取得しない設計でも`pygame.event.pump()`などで定期的に処理しないと、OSから応答なしと判断されることがあります。壁に当たったときは座標を境界へ戻してから向きを変えているため、処理が一瞬止まって`dt`が大きくなっても円が画面外に出たままにはなりません。 ### display.flipとdisplay.updateの使い分け 上のループは毎フレームの最後で`pygame.display.flip()`を呼び、画面全体を書き換えています。似た関数に`pygame.display.update()`があり、[pygame.displayのリファレンス](https://pyga.me/docs/ref/display.html)は両者の違いを次のように定義しています。 | 呼び方 | 書き換える範囲 | OpenGL表示 | | ------------ | ------------- | -------- | | flip() | 画面全体 | バッファを交換 | | update() | 画面全体（flipと同じ） | 対象外 | | update(rect) | 指定した矩形だけ | 対象外 | | update(None) | どこも書き換えない | 対象外 | 引数なしの`update()`と`flip()`は同じ結果になります。差が出るのは矩形を渡したときで、変化した領域だけを書き換えられます。ただしリファレンスは、矩形1つごとに処理コストがかかり、現在のハードウェアでは少数の矩形を渡しただけで部分更新の節約分を上回ると注意しています。`screen.fill()`で毎フレーム全体を塗り直す書き方なら`flip()`で十分です。`update(None)`は「全体を更新」ではなく「何も更新しない」意味になるため、変数がNoneのまま渡ると画面が止まって見えます。`pygame.OPENGL`で表示する場合は`flip()`を使ってください。 ### Clock.tickの戻り値でフレーム時間を扱う理由 `clock.tick(60)`は上限60FPSになるよう待機したうえで、直前の呼び出しからの経過時間をミリ秒で返します。上のコードはこれを1000で割って秒に直し、移動量を`speed * dt`として計算しています。 この一手間を省いて`x += 3`のようにフレーム単位の固定値で動かすと、描画が重い環境では遅く、軽い環境では速く動くゲームになります。`tick`は上限を設けるだけで下限を保証しないため、処理負荷によっては設定したFPSを下回ります。移動・アニメーション・タイマーの類は、最初から経過時間を掛ける形で書いておくほうが後から直す手間がありません。 ### 実験段階のpygame.geometryを使う場合の前提 `pygame.geometry`はpygame-ce独自の当たり判定用モジュールで、円と線を矩形以外の形状として扱えます。ただし[公式ドキュメントのトップページ](https://pyga.me/docs/)は実験段階のモジュールとして扱い、予告なく変更または削除される可能性があるため依存しないよう明記しています。 ``` import pygame.geometry circle = pygame.geometry.Circle(100, 100, 50) print(circle.r, round(circle.area, 3)) print(circle.collidepoint(120, 100)) print(circle.collidepoint(160, 100)) ``` 2.5.8での出力は次のようになります。 ``` 50.0 7853.982 True False ``` 提供されるオブジェクトは版によって変わります。[pygame.geometryのリファレンス](https://pyga.me/docs/ref/geometry.html)はCircle・Line・Polygonの3つを挙げますが、2.5.8に実際に入っているのはCircleとLineの2つだけです。ドキュメントの記述を信じてPolygonを書くとimport時点で失敗するので、使う版で実物を確認してください。長期運用するプロジェクトでは、当たり判定は`Rect`や`Mask`など安定APIで組み、geometryは検証用に留めるのが安全です。 ## 既存pygameコードをpygame-ceへ移すときの判断基準 ### import文を書き換えずに済む範囲 移行作業の実体は、パッケージを入れ替えるだけです。インストール先のディレクトリ名が`pygame`なので、`import pygame`も`from pygame.locals import *`もそのまま動きます。ソースコードの一括置換は必要ありません。 書き換えが要るのは、pygame-ceが同梱をやめたモジュールを使っている箇所です。具体的には`pygame.fastevent`、`pygame.draw_py`、`pygame.threads`の3つで、これらをimportしているコードは移行時に代替を検討する必要があります。`fastevent`は通常のイベントキューで置き換えられます。 逆に、`pygame._sdl2.video.Window`を直接使っていたコードは移行後もそのまま動きます。pygame-ceは`pygame.Window`を追加しただけで、内部モジュール側を削っていません。 ### 移行を見送るべき条件 移行しないほうがよい条件は限られますが、実在します。 ひとつはPython 3.9以前で動かし続ける必要がある場合です。pygame-ce 2.5.8の`requires_python`は3.10以上なので、最新版には移行できません。PyPIの配布wheelを見ると、Python 3.9向けは2.5.5、Python 3.8向けは2.5.2までのpygame-ceにあります。旧版のpygame-ceへ移るか本家pygame 2.6.1を使い続けるかは、次の条件と合わせて判断します。 もうひとつは、pygame本体をビルド済みバイナリごと配布物に固定していて、検証コストを払えない場合です。pygame-ceは[SIMDとは？AVX2・NEONの仕組みと自動ベクトル化・組み込み関数の書き方](/tech/details/18123/)で扱うSIMD命令による最適化やバグ修正を継続的に取り込んでおり、2.5.8では`transform.threshold`や`PixelArray`の24ビットサーフェスへの書き込み不具合、`draw.aacircle`の幅計算などが修正されています。修正は歓迎すべきものですが、描画結果のピクセル単位一致を前提にしたテストを持つプロジェクトでは差分が出ます。リリース直前に入れ替える判断は避けてください。 既存プロジェクトでは、この2条件に加え、依存ライブラリが配布名`pygame`を要求していないかと、回帰テストの結果を確認して移行を決めます。新規開発や学習を始める場合は、最初からpygame-ceを選ぶべきです。Python 3.14以降向けの公式wheelがあり、ソースビルドを避けて導入できるからです。 ## pygame-ceをブラウザで動かすPyScriptとpygbag pygame-ceで作ったゲームは、Pythonを入れていない相手にもURL1本で遊んでもらえます。手段は2つあり、どちらもPythonをWebAssemblyで動かす仕組みの上に乗っています。共通の前提は、メインループの中でブラウザに描画の順番を返すことです。`clock.tick()`で待つループのままでは、ブラウザ側の描画が進みません。 ### PyScriptのpy-gameによる埋め込みと制約 [PyScriptのPyGame-CEガイド](https://docs.pyscript.net/latest/user-guide/pygame-ce/)（2026.7.3版）は、HTMLに`