I recently made the switch over to using MonoGame for 2D projects. I’ve been building up a framework on top of MonoGame to cover all the most commonly used things to speed up development and avoid having to recreate the wheel for every project. This framework is called Nez and it is officially available on GitHub.
Some of the features included:
Scene/Entity/Component system with Component render layer tracking and optional entity systems (an implementation that operates on a group of entities that share a specific set of components)
SpatialHash for super fast broadphase physics lookups (note that Nez does not provide any physics engine. It provides collision data that you can do whatever you want to with.)
AABB, polygon and circle collision/trigger detection and resolution
linecasts, boxcasts, circlecasts (coming soon) against the SpatialHash for super fast lookups
efficient coroutines for breaking up large tasks across multiple frames or animation timing
in-game debug console with a bunch of included commands that is extendable by just adding an attribute to any static method
extensible rendering system. Add/remove renderers and post processors as needed. Fully control over render order, render texture size, scaling, etc
tween system. Tween any int/float/Vector/quaternion/color/rectangle field or property
sprites with sprite animations, scrolling sprites and repeating sprites
kick-ass particle system with added support for importing Particle Designer files. It even has particle collision detection and resolution.
optimized event emitter for core events that you can also add to any class of your own
scheduler for delayed and repeating tasks
synchronous or asynchronous asset loading
too much to list everything
Lots of Pipeline Tool importers are also included:
Texture Atlas Generator: give it a directory or a list of files and it will combine them all into a single atlas and provide easy access to the source UVs of each image. Also includes a per-folder sprite animation generation. The atlas generator uses an XML file as input with an Asset Type of System.String[]. The string array should specify the folder or folders where the source images are located.
Tiled Map Editor: import Tiled maps. Covers tile, image and object layers and rendering with full culling support built-in along with optimized collider generation.
Bitmap Fonts: imports BMFont files (from programs like Glyph Designer, Littera, etc). Outputs a single xnb file and includes SpriteBatch extension methods to display text the directly match the SpriteFont methods.
Texture Packer: imports a TexturePacker atlas and JSON file
Particle Designer Importer: imports Particle Designer particle systems for use with the Nez particle system
XMLTemplateMaker: this isn’t so much an imoporter as a helper to make your own importer. Pass it a class and it spits out an XML template that you can use for your own custom XML-to-object importers.
LibGdxAtlases: imports libGDX texture atlases
Overlap2D: imports Overlap2D projects. Imports almost all of the data but currently only offers renderers for the basics (no fancy stuff like Spriter animations, lights, etc).
If you are interested here is some light reading to learn a bit more about Nez:
Nice to see a unity buddy around :). I will try this today. Seems the kind of thing I had to write my own but someone did it for me :D. Lota thanks for that.
@HexDump, Nez is still early but it should already be quite useable. My TODO list for it is a mile long so there is still a lot more coming. Plus some more tutorials and a video overview next week. I figured it will never actually be done so it might as well be public so others can use it.
I didnt really want to make it myself. I was hoping to find something in some engine out there that had a complete toolset for 2D development but as it turns out there was none so now here we are and I did exactly what I didnt want to do: make a 2D framework myself! It was fun making it but now I look forward to actually getting back to making games with it and just adding to Nez as needed from here on out.
Quite true @Prime31. I was one of those writing engines instead of games in my “childhood”. I’m a bit fed up with writting tecnology. I want to write games :).
By the way, I’m curious, why did you switch to monodroid from unity3d?
@throbax I’m not sure why you would ever want mips in a 2D game, especially pixel art. If you are doing things correctly your art should already be the lowest resolution possible and then you just let Nez upscale it by an integer value with point sampling so that it remains pixel perfect in all situations.
I forgot to mention, the Scene transition system is now live. One line of code to transition to a new Scene with various effects. There are just 4 to start with but the system is fully extensible so it’s easy to make your own. Here is a short video with a few of the included transitions. More to come in the future.
@Fox9 absolutely. Nez doesn’t include built in support but it’s not hard to create a few components that wrap the features you need. Last week I threw together a hacky ChipmunkSharp implementation just to make sure it wasn’t too difficult to do. It didn’t take long at all to get the basics in.
Hi! I want to give it a shot but after examining the engine I found out that it mostly depends on static classes or static singleton objects. I read somewhere that almost everything static is a bad pattern in monogame. That static things wont dispose properly ond andro for example. That there are many monogame - andro related static memory issues.
Without you mentioning specific classes I can’t go into the design decisions that were made for them. Let me know which classes you are referring to and I’ll explain why a particular pattern was used.
Static classes indeed do not dispose of themselves. That is by design and what the static keyword is telling the compiler to do. Nez uses static classes as does the .NET framework, MonoGame and just about every other C# library ever written. Some examples are the Mathf class (math helper methods), several classes of extension methods (Rectangle, Vector2, SpriteBatch, etc), Lerps (for various interpolations) etc. If you have some example of a specific class that would cause an issue being static in Nez I’d love to hear about it.
Don’t believe everything you read when it comes to design patterns. There are lunatics all across the Internet that cry about certain design patterns daily. There is absolutely nothing wrong with using the singleton pattern where it makes sense or any other design pattern for that matter. Nez was built to be both extremely flexible for advanced users and extremely simple for new users. If using a singleton helps facilitate those goals and reduced the barrier to entry than it is a good decision IMO.
There is no point in passing around a single reference to an object all over a codebase just to avoid having it be a singleton. That’s just silly.
The Android issue he is referring to is that when an app is backgrounded, the Activity might be destroyed but the Process is still in memory. Allocations that are indirectly held by the Activity, including the Game object, are released. Allocations held by a static reference are considered part of the Process and therefore are not released. When the app is resumed, the Activity is recreated but the same Process is used along with its previous allocations.
