Introducing Nez: 2D Framework for MonoGame

Update: Nez has officially been released! You can get it on GitHub.

If you have followed along with the 2D framework evaluation posts you will already know how we ended up here. Nez is the result of this journey. Nez aims to be a lightweight 2D framework that sits on top of MonoGame. It provides a solid, but flexible base to work with that's easy enough for beginners but customizable to the core for pros.

Background: What Exactly Does MonoGame Provide?

MonoGame provides an open source, C# cross platform base that gets you access to the underlying hardware: input/audio/display/etc. You get an assortment of expected base classes to work with (like Vector2/Texture/Rectangle/Sound) and overridable Update and Draw methods. MonoGame also provides a class called SpriteBatch that lets you render a texture on screen. That's about it.

MonoGame makes no assumptions about how you are going to make a game. If you want to stuff your entire game in those two methods (Update/Draw) then so be it. This, in my opinion, is where XNA/MonoGame really thrives. You get to work in C# and you get to do things your own way.

Enter Nez

The goal of Nez is to fill in the gaps and provide a whole slew of tools to make developing a 2D game faster and easier. At its heart, Nez provides a scene-entity-component hierarchy immediately familiar to anyone who has made a game in the last 15 years. You get coroutine support, a scheduler system, an in-game debug console, conditional logs/asserts and tons more "nice little things" to make development fun again. Various importers come standard: Tiled maps, Particle Designer particle systems, sprite atlas generation, bitmap fonts and more. A brief explanation of some of the core systems follows.

Scene/Entity/Component/Systems

Create a Scene, create some Entitys and add Components. We've all seen this pattern before. Nez also provides the option of using Entity systems much like Artemis.

Rendering

At the highest level, you tell your Scene how you want your game to look via a SceneResolutionPolicy. The SceneResolutionPolicy decides what size your game's backbuffer will be and how it changes when the screen size changes. Options include fixed width, fixed height, show all (with pixel perfect variants that only scale in whole numbers for pixel art games) and more. You can choose to use a SceneResolutionPolicy or bypass the system completely. As with most things Nez, it is entirely up to you.

Nez differs a bit from many other frameworks out there in that it lets you add your own custom renderer. Out of the box, Nez provides some basic renderers that let you filter what is rendered and to render to the screen or a render target. Subclass the Renderer class and you are free to render however you want. Each scene can have multiple Renderers so you are free to do things however you see fit. If you want to use 10 Renderers for your base game and 2 Renderers for your HUD so be it.

PostProcessors go hand-in-hand with Renderers. You can add one or more PostProcessors with an Effect (Effects are essentially what MonoGame/XNA call shaders) to any scene. PostProcessors are called after all the Renderers are finished and they can be used for adding fancy effects, merging multiple render targets or whatever else you come up with. Like the Renderer class, PostProcessor is useable out of the box and overridable for when you need more control. Several post processors are included as examples for how to make your own including bloom, vignette, scanlines and more.

Game Physics

Important to note here is that I said game physics. Nez does not, and will not ever have a realistic physics simulation library built in. There are already plenty of excellent physics libraries out there (Box2D, Farseer, etc) and to be completely honest I don't think they are a good fit for making games (unless the point of the game is realistic physics of course!) Fighting with a realistic physics simulation to make a decidedly unrealistic video game is not my idea of blissful fun. That's a story for a whole other post though so I'll just drop that right here.

Nez provides game physics out of the box. It uses a lot of the concepts of a realistic physics simulation (SpatialHash for efficient broad phase detection, Minkowski Sum/Separating Axis Theorem for narrow phase) but it removes the idea of friction, velocity, mass, etc. You of course can implement those things if you want to but that is not the main purpose of Nez's physics.

The Nez physics system is designed to provide fast access with an arbitrarily sized game world for things like line casts, overlap checks and collider intersections (circle, box, polygon). All available data is provided including a vector that can be used to separate objects after a collision. This data lets you make your game movement have the perfect feel since you are always in control. You never have to defer to random forces, masses or friction. Move your objects exactly how you want to move them and use the collision data to keep them constrained the way you want to.

Conclusion

There is so much more to Nez that it is nearly impossible to sum up in a single blog post. If there is any interest in deep-dives into the details and design decisions of the various systems of Nez just hit me up on Twitter and I'll whip up a blog post with the gory details.