# ggez: a lightweight Rust 2D and 3D game framework built on wgpu

> ggez is a batteries-included Rust game framework that borrows LÖVE's callback style, ships its own rendering, audio and resource loading, and deliberately leaves physics, ECS and GUI to other crates.

**ggez/ggez** — Rust library to create a Good Game Easily

- Repository: https://github.com/ggez/ggez
- Website: http://ggez.rs
- Stars: 4,697 · Forks: 441
- Language: Rust
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/ggez-ggez

## What ggez actually solves, and for whom

The README describes ggez as "a lightweight cross-platform game framework for making 2D and 3D games with minimum friction", with an API modelled on a Rustified version of the LÖVE framework. That framing is the whole pitch. If you have written a LÖVE game before, the shape of a ggez program will feel familiar: you build a context, implement callbacks, and hand control to a run loop that the framework owns.

The audience is narrower than "Rust game developers". The README states that ggez "is not meant to be everything to everyone, but rather a good base upon which to build". There is no editor, no scene graph and no asset pipeline. What you get is drawing, sound playback, resource loading from folders or zip files, input callbacks, a config file and timing helpers. What you do not get is listed explicitly as non-features: physics, animation, GUI, an assets manager, AI, ECS and networking, each with a pointer to the arewegameyet.rs ecosystem page or, for animation, the keyframe crate. That list is the most useful thing on the page, because it tells you the framework expects you to assemble the rest yourself.

So the fit is a solo developer or a small team writing a 2D game, a prototype or a teaching project, who wants a working window and canvas without writing a wgpu renderer first. It is a poor fit for anyone who wants an engine to make architectural decisions for them.

## Context, EventHandler, and the event loop ggez owns

ggez is composed of three parts according to the README: a Context object holding all the state needed to talk to the hardware, an EventHandler trait the user implements to register callbacks, and sub-modules such as graphics and audio that do the work. The README states the general pattern directly: create a struct holding your game data, implement EventHandler on it, build a Context from a ContextBuilder or Conf object, then call event::run() with the context and your handler.

That inversion matters. You do not write a while loop. You write update and draw methods and the framework calls them. The README's template shows update returning a GameResult and draw building a Canvas with graphics::Canvas::from_frame(ctx, Color::WHITE) before calling canvas.finish(ctx). Drawing goes into the canvas, not straight to the screen.

Underneath, the implementation details section names the dependencies: winit for windowing and events, rodio for sound, and a 2D drawing engine implemented with wgpu. The README also notes a threading constraint: ggez is "entirely thread-safe (though platform constraints mean the event-handling loop and drawing must be done in the main thread)". That is a real design boundary, not a footnote, and it shapes how you structure background work such as asset loading.

Math integration comes through the mint crate, and the Cargo.toml pins a comment on it: "Has to be the same version of mint that our math lib uses here." That pin is a hint about how tightly the math types are coupled across the dependency graph.

## Installing ggez and drawing your first frame

The README says ggez requires rustc >= 1.42 and is distributed on crates.io. Adding it is a single dependency line in Cargo.toml. Note that the README's usage line and the Cargo.toml in the repository both carry version 0.10.0, while the most recent published release listed on the repository is 0.9.3 from 2023-07-10. Check crates.io for what is actually published before you copy either number.

```toml
[dependencies]
ggez = "0.10.0"
```

The README's basic project template is the shortest path to a running window. It builds a Context with ContextBuilder::new taking a game id and an author string, constructs your game struct, and calls event::run. Your struct implements EventHandler with update and draw.

```rust
use ggez::{Context, ContextBuilder, GameResult};
use ggez::graphics::{self, Color};
use ggez::event::{self, EventHandler};

fn main() {
    let (mut ctx, event_loop) = ContextBuilder::new("my_game", "Cool Game Author")
        .build()
        .expect("aieee, could not create ggez context!");
    let my_game = MyGame::new(&mut ctx);
    event::run(ctx, event_loop, my_game);
}
```

If you would rather see a finished game than a skeleton, the README says to check out the source and run an example from the repository root. The astroblasto example is described as a small but complete Asteroids-like game.

```bash
git clone https://github.com/ggez/ggez.git
cd ggez
cargo run --example 05_astroblasto
```

The README points to docs/guides/HelloGezz.md (the Hello ggez guide) for a longer walkthrough, and to docs/FAQ.md when something fails to build.

## Platform support stops at the three desktop systems

The README's supported platforms list is blunt. Windows, Linux and MacOS are fully supported. Android, iOS and Web are described as "not officially supported but might work anyway", with a pointer to docs/BuildingForEveryPlatform.md for details. For anything on the web or on a phone, the README redirects you to good-web-game, a separate project, and notes that it covers ggez up to 0.7.

That gap is the single largest constraint on the project's reach. A framework built on winit and wgpu could in principle target the browser, but ggez's own documentation does not claim it does. If your plan involves shipping to a store or a browser tab, this is the point where you stop reading and evaluate good-web-game instead.

The second constraint is the absence of the non-features. No physics means you pick a physics crate. No ECS means you decide how entities are stored. No GUI means you build menus yourself or pull in another crate. None of that is a defect in a framework that states its scope, but it does mean the amount of code you write before your game is playable is larger than the README's short template suggests. The template gets a window on screen; it does not get you a game.

## ggez compared with macroquad and Bevy

The closest comparison in spirit is macroquad, another small Rust framework aimed at 2D games with a minimal API. The difference is in what the framework owns. ggez exposes a Context object and an EventHandler trait with update and draw callbacks, and the README's own framing is that it implements an API based on a Rustified LÖVE. macroquad's API is built around free functions and an implicit global context, which produces shorter programs but less explicit state. If you like seeing your context passed around, ggez's design is the more conventional one; if you want the fewest lines possible, it is not.

The comparison against Bevy is a difference of category rather than of taste. Bevy is an ECS-first engine where the ECS is the framework. ggez lists ECS as a non-feature and points at the arewegameyet.rs ECS page, so the two projects disagree about whether an entity component system belongs in the core. A ggez project can adopt an ECS crate, but the framework will not structure your code around it.

A third reference point is LÖVE itself. ggez's README is explicit that "finer details and performance characteristics may be different than LÖVE", and that ggez adds 3D drawing, which LÖVE has no API for. So the LÖVE comparison is about API familiarity, not about parity.

## Maintenance, release cadence and the MIT licence

The repository is not archived and the last push was on 2026-08-24, roughly a month before this writing, so work on the master branch is recent. That said, the release history tells a different story from the commit history. The three most recent releases listed are 0.9.1, 0.9.2 and 0.9.3, all published within four days of each other in July 2023. There is no later tagged release in the repository listing, while Cargo.toml in the repository declares version 0.10.0. The practical reading is that the repository carries changes that have not been cut into a release, and that the published crate may lag the source. Verify on crates.io which version you are actually pulling.

Upgrade cost is dominated by the graphics and windowing stack. Cargo.toml pins wgpu at 30 and winit at 0.30, both fast-moving crates. A major bump in either can ripple through ggez's public types, and the mint pin comment shows that even math type versions are coordinated across dependencies. Expect to rebuild and retest on minor bumps of the graphics stack, not just on ggez's own version changes.

Licensing is straightforward: the repository declares MIT in Cargo.toml and the README carries an MIT badge linking to the LICENSE file. MIT is permissive and imposes no source disclosure on your game. That is a statement about what the licence says, not legal advice; if your project has unusual distribution requirements, read the LICENSE file and talk to someone qualified.

## Conclusion

Adopt ggez if you want a small Rust game loop with drawing, sound and resource loading already wired up, and you are willing to choose your own physics, ECS and GUI crates. Skip it if you need an editor, a scene graph or a supported mobile and web target, since the README lists Android, iOS and Web as not officially supported. Before committing, check the examples directory and confirm the wgpu and winit versions in Cargo.toml match what your toolchain and target platform can build.

## FAQ

### What is ggez used for?

ggez is a Rust library for making 2D and 3D games, described in its README as a lightweight cross-platform game framework with an API based on a Rustified version of LÖVE. It provides drawing, sound, resource loading and event handling, and leaves physics, ECS and GUI to other crates.

### How do I install ggez in a Rust project?

The README says ggez requires rustc >= 1.42 and is distributed on crates.io, and that you add a dependency line to Cargo.toml. The README's usage section shows ggez = "0.10.0".

### Which platforms does ggez support?

The README lists Windows, Linux and MacOS as fully supported. Android, iOS and Web are described as not officially supported but possibly workable, with details in docs/BuildingForEveryPlatform.md and a pointer to good-web-game for those targets.

### Does ggez include a physics engine or an ECS?

No. The README lists physics, animation, GUI, assets manager, AI, ECS and networking as non-features, and points to the arewegameyet.rs ecosystem pages for each so you can choose a separate crate.

### What is ggez built on top of?

The README's implementation details section states that ggez uses winit for windowing and events, rodio for sound, and a 2D drawing engine implemented with wgpu. It also notes that the event-handling loop and drawing must run on the main thread.

## Sources

- [ggez/ggez on GitHub](https://github.com/ggez/ggez)
- [License: MIT](https://github.com/ggez/ggez/blob/master/LICENSE)
- [Project website](http://ggez.rs)
- [README](https://github.com/ggez/ggez/blob/master/README.md)
- [Releases](https://github.com/ggez/ggez/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ggez-ggez