Bloatfree

Gosu aims to contain everything that is necessary to write a game in clean C++ or Ruby code, yet not much more. Our aim is to get the annoying world of hardware and OS interaction out of your way. Think SDL with a very different, less C-ish style.

Of course there are things that are cool to have when creating games, but will not be reinvented within Gosu:

• not another set of smart pointers, containers, signals (this applies to C++, where we rely on the Boost libraries)
• no XML parser, HTTP client, or other unrelated functionality
• no high-level game features for the reasons below:

General

Gosu has been used for all sorts of small 2D games, especially during timed competitions. This includes top-down games, side-scrollers, games with pseudo-3D isometric perspective, a game with a skeletal animation system, ... To keep things this flexible, we will not add features that only make sense for very specific kinds of games, or that can be implemented in oh-so-many different ways.

Examples of things not going to be included in Gosu:

• bounding-box based collision detection (int? double? 2D only, or with a depth? ...)
• a map class (seriously - how? tiles? hexagons? polygons? ...)
• scrolling
• game objects
• ...

However, we won't mind publishing your well-written and tested add-on library that is completely not general.

Reality-driven

Everything in Gosu exists for the same single reason: It was necessary for an existing project. Nothing was, and will ever be, added out of boredom. Experience with other libraries shows that such "just in case" code will be tested poorly and likely just disappoint people.

Seen the other way around, this ensures that Gosu includes (or will soonish include) everything that is necessary to get a very complete game out of the door.

Modular (C++ only)

While there is a convenient, completely portable Window class which bundles all of Gosu's components for you, nothing prevents you from using the Graphics class alone. Or the Audio class. You could use Gosu just for timing or PNG loading/saving in a command-line tool, and still get away without paying for all the unused functionality.

Sometimes, you have to leave the world of portability for this to make sense - eg., when you don't use the Gosu::Window class, but a custom Win32 HWND instead, you need to call a Windows-only constructor. This makes it possible to use Gosu in conjunction with the Win32 API, Windows Forms, or your own X11 window (e.g. for complex level editors). Gosu does NOT dogmatically stand in your way when you do unportable things like that.

Radical

We will change the interface where it makes sense, and it will break code. This does not happen often, but who knows. Backward compatibility is the root of all evil, and we will not give in to it until 1.0.