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は、この配布物を「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ページでの最初の公開は同年2月13日のバージョン2.1.3です。バージョン番号を1から振り直さず本家の続きから始めている点も、fork元との連続性を示しています。

本家pygameとpygame-ceのリリース実績の差

更新頻度の差は、公開日を並べると数字で確認できます。

スター数は本家が5倍以上ありますが、この数値だけでは現在の保守状況や更新頻度は判断できません。直近の動きを見ると、PyPIの本家pygameは2024年9月のリリースを最後に約2年間バージョンが上がっておらず、本家のGitHubリポジトリも既定ブランチへの最終コミットが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」で、Python 3.14以降のpython3Packages.pygameが既定でpygame-ceを指すように変えました。従来の本家はpygame-originalという名前で残しています。Pythonの公式フォーラムでも、2026年5月の「Python 3.14でPyGameとOpenGLをインストールできない」という相談に対し、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タグを並べると上限が逆転します。

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コンパイラとは？有効化の手順と実測、フリースレッド版と新機能で触れているような新しいランタイムを使うなら、ゲームライブラリ側は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.system・pygame.typingの各ページにまとまっています。本家でウィンドウを直接扱う場合は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が使われている場合は、仮想環境の有効化に加え、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のリファレンスは両者の違いを次のように定義しています。

引数なしの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独自の当たり判定用モジュールで、円と線を矩形以外の形状として扱えます。ただし公式ドキュメントのトップページは実験段階のモジュールとして扱い、予告なく変更または削除される可能性があるため依存しないよう明記しています。

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のリファレンスは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の仕組みと自動ベクトル化・組み込み関数の書き方で扱う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ガイド（2026.7.3版）は、HTMLに<script type="py-game" src="my_game.py">と書くだけでpygame-ce入りのPyodideが起動すると説明しています。pipでのインストールは不要です。ただし同ガイドはこの機能を実験的と明記しており、守るべき制約を次のように挙げています。

• clock.tick(fps)をawait asyncio.sleep(1/fps)に置き換え、ブラウザに描画の時間を渡す。
• 画像や音声は設定のfilesで明示的に読み込ませる。
• ブラウザ側に同梱されるPythonとpygame-ceの版は最新より遅れることがあり、2.4.1が同梱されていれば「since 2.5」の関数は動かない。
• pygame-ceは常にメインスレッドで動き、Web Workerは使えない。

同梱版の遅れは見落としやすい落とし穴です。手元の2.5.8で動いたpygame.Windowやpygame.geometryが、ブラウザでは属性エラーになることがあります。起動時にブラウザのコンソールへ出る版を確認してから、使う関数を決めてください。

pygbagによるゲームフォルダのブラウザ向け変換

pygbagは、ゲームのフォルダをブラウザで動く形にまとめて配信するツールで、PyPIでの最新版は0.9.3です。pip install pygbagで入れ、pygbag ゲームのフォルダで実行します。フォルダにはmain.pyが必要で、そのループはasyncio対応でなければなりません。

ローカルとPyScriptの両方で動く形に書き換えた最小のループが次のコードです。pygame-ce 2.5.8とPython 3.14.6のローカル環境で実行し、120フレームを処理して終了することを確認しました。

import asyncio
import pygame

async def main():
    pygame.init()
    screen = pygame.display.set_mode((320, 240))
    x, speed = 20.0, 150.0
    frames = 0
    while frames < 120:  # 検証用に120フレームで終了
        for event in pygame.event.get():
            if event.type == pygame.QUIT:
                pygame.quit()
                return
        x += speed / 60
        if x > 300 or x < 20:
            speed = -speed
        screen.fill((0, 0, 0))
        pygame.draw.circle(screen, (255, 200, 0), (int(x), 120), 12)
        pygame.display.flip()
        frames += 1
        await asyncio.sleep(1 / 60)  # ブラウザへ描画の機会を渡す
    print("frames", frames, "x", round(x, 1))
    pygame.quit()

try:
    asyncio.get_running_loop()  # PyScriptでは実行中のイベントループがある
    asyncio.create_task(main())
except RuntimeError:
    asyncio.run(main())  # ローカルのPython

出力はframes 120 x 285.0でした。末尾の分岐はPyScriptのガイドが示す書き方で、実行中のイベントループがあるPyScriptではcreate_task()、ローカルではasyncio.run()で起動します。pygbagのREADMEは末尾をasyncio.run(main())とし、その後ろにsys.exitやpygame.quitを書かないよう注意しています。ブラウザではpygame.QUITイベントが発生しませんが、ローカルでウィンドウを閉じるために処理は残します。asyncio.sleep(1/60)は描画にかかる時間を差し引かないため、実際のフレームレートは60を下回ります。PyScriptのガイドも同じ点を指摘し、正確に合わせたい場合はvsync=1とブラウザのrequestAnimationFrameに同期させる書き方を別途示しています。最初からブラウザ公開を予定しているなら、ゲームループをこの形で書いておけば後から構造を変えずに済みます。

pygame-ceのライセンスと商用利用の条件

pygame-ceはGNU LGPL version 2.1で配布されています。本家pygameと同じライセンスです。

READMEのライセンス識別子はLGPL-2.1-or-laterです。LGPL 2.1第6条の条件を満たせば、ゲーム本体のソースコードを公開せずに配布でき、商用販売も可能です。その条件には、ライセンス文の添付・利用告知に加え、利用者がライブラリを差し替えられること、その改変をデバッグするためのリバースエンジニアリングを認めることなどが含まれます。一方で、pygame-ce自体に手を入れて配布する場合はその改変部分に条件が及びます。PyInstallerなどで単一実行ファイルにまとめる場合も、ファイル数だけではLGPL上の扱いは決まりません。利用者によるライブラリの差し替えや再結合が可能かなど、実際の配布構成を第6条に照らして確認します。オープンソースライセンスとは？主要9種の商用利用可否と義務を条項番号で解説で条項番号ごとの義務を確認したうえで判断してください。

pygame-ceの公式ドキュメント・GitHub・Discordの探し方

pygame-ceの情報源は本家pygameと別の場所にあります。検索でpygame.orgのページに着地した場合、それは本家の情報なので、pygame-ce固有の関数が載っていないことがあります。

pygame-ceのドキュメントはモジュール単位のAPIリファレンスに加え、チュートリアルと実験的モジュールの一覧を持っています。追加バージョンの注記では「pygame」と「pygame-ce」のどちらを指すかを確認してください。pygame-ceでの追加時期だけでは本家での有無までは判断できないため、本家のリファレンスも照合します。Discordへの入口はpygame-ceの公式サイトのナビゲーションとフッターにあります。

pygame-ceの3D対応とSDL3移行の現在地

3Dシーン管理の非搭載とOpenGL連携・代替エンジン

pygame-ceは2Dに特化したライブラリで、カメラ・メッシュ・ライトといった3Dシーンを組むためのAPIは提供していません。pygame.display.set_mode()にpygame.OPENGLを渡せばOpenGL用のウィンドウは作れるので、PyOpenGLなど外部のOpenGLバインディングで3D描画を書くことはできますが、描画処理はすべて自前になります。3Dが主目的ならGodotのインストール方法｜Windows・Mac・Linux別の手順と動作要件【4.7.2対応】で手順を示しているGodotのような3D対応エンジンを選ぶほうが早道です。

SDL3移行の進捗と2.5.8のSDL2依存

基盤ライブラリのSDLについては、macOS上のPython 3.14.6でPyPIのwheelから入れたpygame-ce 2.5.8がリンクしていたのはSDL 2.32.10でした。SDLの版は配布物やビルド方法によって異なるため、使用環境でも確認してください。リリースノートにはSDL3向けの_audioと_sdl3_mixerモジュール追加といった作業項目が並んでいますが、これは移行作業が進行中という段階を示すもので、既定のビルドがSDL3になったわけではありません。SDL3前提の記事や情報を見かけたら、対象の版を確認してください。実行中のSDLバージョンは前述のpygame.get_sdl_version()で確認できます。

Pyxel・Godot・Siv3Dと並べたときのpygame-ceの選びどころ

Pythonで2Dゲームを作る選択肢はpygame-ceだけではありません。判断材料になる差を整理します。

Pyxelはレトロゲーム向けエンジンで、パレットや画面サイズがあらかじめ絞られている分だけ完成までが速くなります。裏を返せば高解像度の作品には向きません。表現の制約を受け入れられないならpygame-ceのほうが素直です。Siv3Dとは？無料C++フレームワークのインストールと使い方【v0.6.16対応】で扱うSiv3Dは機能面では厚いものの言語がC++なので、Pythonの学習を兼ねるという目的とは噛み合いません。

pygame-ceを選ぶ判断が明確に立つのは、Pythonの文法を学びながらゲームの内部構造を自分で書きたい場合です。ゲームループを自分で組み、スプライト管理にはpygame.spriteのSpriteやGroupを利用できるため、フレームレート制御や当たり判定といった仕組みが手を動かした結果として身につきます。逆に、短期間で見栄えのする成果物を出すことが目的なら、GUIエディタを持つエンジンを選んだほうが目的に合います。販売や運用を前提にした規模のゲームを外部に任せる場合は、エンジン選定から相談できるゲームアプリ開発の支援を使う方法もあります。

よくある質問

pygame-ceとpygameはどちらを使うべきですか？

新規に始めるならpygame-ceです。本家pygameは2024年9月の2.6.1が最新で、配布wheelの対応上限がPython 3.13です。Python 3.14以降向けの公式wheelはなく、インストールには環境に応じたソースビルドが必要です。既存の依存関係や配布物との互換性を保つ必要がある場合は、本家pygameを使い続ける選択肢も残ります。Python 3.9以前では、2.5.5以前の旧版pygame-ceも候補に入れて判断してください。

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への追随は止まっています。nixpkgsはPython 3.14以降のpygameを既定でpygame-ceに切り替えました。宣言と実態を分けて理解してください。

pygame-ceは商用ゲームに使えますか？

使えます。pygame-ceのライセンス表記はLGPL-2.1-or-laterです。LGPL 2.1第6条の配布条件を満たせば、ゲーム本体のソースコードを公開せずに商用配布できます。pygame-ce自体を改変して配布する場合や、単一実行ファイルへ固める配布形態を採る場合は、LGPLの該当条項に沿った対応を確認してください。

pygame-ceで3Dゲームは作れますか？

pygame-ceには3Dシーン管理の高水準APIはありませんが、OpenGL用ウィンドウを作成し、外部のOpenGLバインディングと組み合わせて3D描画を行うことはできます。擬似3Dの表現を自前で実装することは可能ですが、本格的な3Dを扱うならGodotなど3D対応のエンジンを選ぶほうが実装量を抑えられます。

関連記事

• uvとは？Pythonの環境構築・パッケージ管理・バージョン管理の使い方を徹底解説
• 仮想環境とは？venv・コンテナ・仮想マシンの違いと隔離レベルの選び方を実装者向けに解説
• Python 3.14のJITコンパイラとは？有効化の手順と実測、フリースレッド版と新機能
• Godotのインストール方法｜Windows・Mac・Linux別の手順と動作要件【4.7.2対応】
• オープンソースライセンスとは？主要9種の商用利用可否と義務を条項番号で解説