pygame-ceは、Pythonの2Dゲームライブラリpygameから分岐したディストリビューションです。名前が似ているうえにimport pygameという書き方まで共通なので、どちらを入れればよいのか、両方入れても問題ないのかが分かりにくくなっています。この記事では2026年9月時点の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にはこの属性がありません。
pygame-ceが本家pygameから分岐した経緯
公式が示す「元コア開発者によるfork」という定義
前提として、pygameはSimple DirectMedia Layer(SDL)をはじめとする複数のライブラリの上に構築された、クロスプラットフォームのフリーかつオープンソースなライブラリです。ウィンドウ生成・画像描画・音声再生・入力処理といったゲームに必要な土台をPythonから扱えるようにするもので、ゲームエンジンのようなGUIエディタは持ちません。この性格はpygame-ceでも変わりません。
そのうえでpygame-ceの公式READMEは、この配布物を「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での最初の公開は同年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-06 | 2025-10-05 |
| GitHubスター数 | 1,643 | 8,920 |
スター数は本家が5倍以上ありますが、これは2017年から積み上がった歴史の反映です。直近の動きを見ると、本家は2024年9月のリリースを最後に約2年間バージョンが上がっておらず、既定ブランチへの最終コミットも2025年10月で止まっています。一方のpygame-ceは3年半で31回リリースし、直近も更新が続いています。
「pygameは開発終了したのか」に対する事実ベースの回答
本家pygameのリポジトリが公式に開発終了を宣言した事実は確認できません。アーカイブもされていません。したがって「開発終了」と言い切るのは正確ではないというのが結論です。
ただし利用者の判断材料としては、宣言の有無より配布物が更新されているかどうかが効きます。本家2.6.1が対応するPythonの上限は後述のとおりPython 3.13で止まっており、Python 3.14以降を使う環境では新規にインストールする手段そのものがありません。宣言としては継続中、実務上は新しいPythonに追随していない、という二段構えで理解しておくと判断を誤りません。
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のリリースノートは、この版で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コンパイラ・フリースレッド版(GIL撤廃)・t-stringを最新版で解説で触れているような新しいランタイムを使うなら、ゲームライブラリ側は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._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・コンテナ・仮想マシンの違いと隔離レベルの選び方を実装者向けに解説、uvの使い方はuvとは?Pythonの環境構築・パッケージ管理・バージョン管理の使い方を徹底解説にまとめています。
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が使われている場合は、仮想環境の有効化が漏れていると判断できます。
なお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 or x < 40:
speed = -speed
screen.fill((16, 20, 28))
pygame.draw.circle(screen, (120, 200, 255), (int(x), 180), 24)
pygame.display.flip()
pygame.quit()
行数は25行ほどです。pygame.event.get()を毎フレーム呼ばないとOSがアプリを応答なしと判断するため、描画だけを回すループにはできません。
Clock.tickの戻り値でフレーム時間を扱う理由
clock.tick(60)は上限60FPSになるよう待機したうえで、直前の呼び出しからの経過時間をミリ秒で返します。上のコードはこれを1000で割って秒に直し、移動量をspeed * dtとして計算しています。
この一手間を省いてx += 3のようにフレーム単位の固定値で動かすと、描画が重い環境では遅く、軽い環境では速く動くゲームになります。tickは上限を設けるだけで下限を保証しないため、処理落ちしたフレームは必ず発生します。移動・アニメーション・タイマーの類は、最初から経過時間を掛ける形で書いておくほうが後から直す手間がありません。
実験段階のpygame.geometryを使う場合の前提
pygame.geometryはpygame-ce独自の当たり判定用モジュールで、円と線を矩形以外の形状として扱えます。ただし公式ドキュメントは実験段階のモジュールとして扱い、予告なく変更または削除される可能性があるため依存しないよう明記しています。
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
提供されるオブジェクトは版によって変わります。開発版のドキュメントは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以上なので、そもそもインストールできません。この場合は本家pygame 2.6.1を使い続けるほかありません。
もうひとつは、pygame本体をビルド済みバイナリごと配布物に固定していて、検証コストを払えない場合です。pygame-ceはSIMD最適化やバグ修正を継続的に取り込んでおり、2.5.8ではtransform.thresholdやPixelArrayの24ビットサーフェスへの書き込み不具合、draw.aacircleの幅計算などが修正されています。修正は歓迎すべきものですが、描画結果のピクセル単位一致を前提にしたテストを持つプロジェクトでは差分が出ます。リリース直前に入れ替える判断は避けてください。
この2条件に当てはまらないなら、移行しない理由はほぼありません。新規に学習を始める場合は最初からpygame-ceを選ぶべきです。Python 3.14以降では本家を選ぶ余地がなく、後から乗り換える手間が増えるだけだからです。
pygame-ceのライセンスと商用利用の条件
pygame-ceはGNU LGPL version 2.1で配布されています。本家pygameと同じライセンスです。
LGPLはコピーレフトの適用範囲をライブラリ自体に限る条件なので、pygame-ceを動的にリンクして使うゲーム本体のソースコード公開までは求められません。商用販売も可能です。一方で、pygame-ce自体に手を入れて配布する場合はその改変部分に条件が及びます。PyInstallerなどで単一実行ファイルに固めて配布する形態は静的リンクに近い扱いになりうるため、条項に沿った対応が必要です。オープンソースライセンスとは?主要9種の商用利用可否と義務を条項番号で解説で条項番号ごとの義務を確認したうえで判断してください。
pygame-ceの3D対応とSDL3移行の現在地
3D描画に対応していない理由と代替の選択肢
pygame-ceは2Dに特化したライブラリで、3Dシーンを組むためのAPIは提供していません。3Dが必要ならGodotのインストール手順|Windows・Mac・Linux対応とダウンロードから初期起動までの流れで扱っているGodotのような3D対応エンジンを選ぶほうが早道です。
SDL3への移行がどこまで進んでいるか
基盤ライブラリのSDLについては、2.5.8が実際にリンクしているのはSDL 2.32.10です。リリースノートにはSDL3向けの_audioと_sdl3_mixerモジュール追加といった作業項目が並んでいますが、これは移行作業が進行中という段階を示すもので、既定のビルドがSDL3になったわけではありません。SDL3前提の記事や情報を見かけたら、対象の版を確認してください。実行中のSDLバージョンは前述のpygame.get_sdl_version()で確認できます。
Pyxel・Godot・Siv3Dと並べたときのpygame-ceの選びどころ
Pythonで2Dゲームを作る選択肢はpygame-ceだけではありません。判断材料になる差を整理します。
| 選択肢 | 最新版 | 特徴 | 向く用途 |
|---|---|---|---|
| pygame-ce | 2.5.8(2026-08-09) | SDL2ベース・制約なし | Pythonで自由に組む2D |
| Pyxel | 2.9.9(2026-08-12) | レトロ風・色数と画面サイズに制約 | ドット絵の小規模作品 |
| Godot | — | GUIエディタ・3D対応 | 3Dや規模の大きい開発 |
| Siv3D | — | C++・機能同梱が厚い | C++で書ける場合 |
Pyxelはレトロゲーム向けエンジンで、パレットや画面サイズがあらかじめ絞られている分だけ完成までが速くなります。裏を返せば高解像度の作品には向きません。表現の制約を受け入れられないならpygame-ceのほうが素直です。Siv3Dとは?無料C++ゲーム開発フレームワークの特徴・インストール・使い方を解説で扱うSiv3Dは機能面では厚いものの言語がC++なので、Pythonの学習を兼ねるという目的とは噛み合いません。
pygame-ceを選ぶ判断が明確に立つのは、Pythonの文法を学びながらゲームの内部構造を自分で書きたい場合です。ゲームループもスプライト管理も自前で組む必要があるぶん、フレームレート制御や当たり判定といった仕組みが手を動かした結果として身につきます。逆に、短期間で見栄えのする成果物を出すことが目的なら、GUIエディタを持つエンジンを選んだほうが目的に合います。
よくある質問
pygame-ceとpygameはどちらを使うべきですか?
新規に始めるならpygame-ceです。本家pygameは2024年9月の2.6.1が最新で、配布wheelの対応上限がPython 3.13です。Python 3.14以降ではインストール自体ができません。Python 3.9以前を使い続ける必要がある場合だけ、本家pygameが選択肢になります。
pip install pygame-ceの後もimport pygameと書いてよいのですか?
はい。インストールされるディレクトリ名はpygameなので、import pygameと書きます。import pygame_ceやimport pygame-ceという書き方は存在しません。既存のコードやチュートリアルのimport文をそのまま使えます。
pygameは開発終了したのですか?
公式に開発終了が宣言された事実はなく、リポジトリもアーカイブされていません。ただし最新リリースは2024年9月29日の2.6.1、既定ブランチへの最終コミットは2025年10月5日で、新しいPythonへの追随は止まっています。宣言と実態を分けて理解してください。
pygame-ceは商用ゲームに使えますか?
使えます。ライセンスはGNU LGPL version 2.1で、ライブラリを動的にリンクして使う限りゲーム本体のソースコード公開義務は生じません。pygame-ce自体を改変して配布する場合や、単一実行ファイルへ固める配布形態を採る場合は、LGPLの該当条項に沿った対応を確認してください。
pygame-ceで3Dゲームは作れますか?
pygame-ceは2D描画に特化しており、3D用のAPIはありません。擬似3Dの表現を自前で実装することは可能ですが、本格的な3Dを扱うならGodotなど3D対応のエンジンを選ぶほうが実装量を抑えられます。