Canonical example of MonoGame "middleware" library? (+ other questions about improving the experience of installing reusable libraries into MonoGame game projects)

1

I’m trying to port the LTrees library from XNA to MonoGame, and running into some issues (most of which I expect, given that I’m using a pre-release version of the content pipeline and associated tools).

But it made me wonder, is there yet a 3rd-party project that anyone can point me to, which:

  • is a “middleware”-type library intended for use in a MonoGame-based game (i.e. not a game, just a reusable library).
  • has solved the conundrum of handling all the build permutations for all the platforms that MonoGame supports (it gets even more complicated if the library has a content pipeline DLL providing custom importers and processors, because then there are 3 possible platforms just for the content pipeline DLL). I see MonoGame itself uses Protobuild - is that the recommended approach for 3rd party libraries too?
  • has figured out how to package things in order to reduce or eliminate the number of manual steps end users must go through to use the library in their game.

Apart from thinking about how to author libraries like these, I’ve also been thinking about the end-user experience.

In my perfect scenario, all that would be necessary to bring a library like LTrees into your MonoGame game project would be:

  • Open NuGet package manager, search for library, install (or equivalent for Mac and Linux environments)
  • That’s it…

Of course there are a number of things that need to happen to make that possible:

  • Add references for the correct platform version of the library - perhaps using a .targets file, which I think is how MonoGame itself does it?
  • Figure out how to deal with any .xnb files included with the library (which would themselves be platform-specific). Perhaps a convention of putting .xnb files into the “content” folder of a NuGet package?
  • If the library has custom importers / processors, ideally they would be able to “register” themselves with the .mgcb file - again, probably requires a convention for where the .mgcb file(s) are stored.

I realise that’s probably a long way off, but I wondered if that’s at all aligned with where MonoGame’s core developers want to get to? If it were as easy as that, I think you’d see an explosion (well, loud bang, anyway) of reusable components (like LTrees), that any MonoGame-based game could easily make use of.

I read this thread, and it sounds like some of the pre-requisite pieces are in progress.

Anyway, sorry for all the questions! I’m guessing that a lot of the answers might be “not yet”, or “no plans”, but that’s fine - I really just want to get a feel for the current state of affairs, as well as perhaps some idea of whether it’s going to get easier to build “middleware” libraries for MonoGame in the future.

2 Likes
2

By the way, the MonoGame port of LTrees will be here when it’s done:

But the version there now is still for XNA 4.0.

1 Like
3

Hi tgjones,

I would love to help you with the port of this!

I am in fact working on a project that makes use of a similar algorithm, so I think that it would benefit me highly to contribute to this as much as I can. :smile:

Give me a week or so to take a look at the code and then I will see what the state of the github repo is.

Cheers.

4

Awesome, thanks LoveDuckie.

Actually I’ve started on the port, but the changes are just on my computer so far. I’ve got it compiling (by commenting out the calls to GraphicsDevice.Reset and GraphicsDevice.Present and Game.Exit), but not yet running.

(See above questions, I was hoping to “copy” whatever the best practices are for compiling this sort of library. I don’t want to manually copy XNBs around, for example; I know how to get MSBuild to do most of the things I need, but of course if someone else has a good example I can copy from, that’s even better…)

5

I’ve got LTrees working with MonoGame! :slight_smile: It’s not yet an automatic build process though; anyone who wants to try it will have to first use the Pipeline tool to build the .mgcb content projects in LTreeDemo and LTreesLibrary, then build the solution and run LTreeDemo.

I’ve included all the necessary MonoGame libraries in lib/MonoGame. (Once MonoGame publishes the content pipeline DLLs and tools in a NuGet package, I’ll remove these from the repo.)

At the moment, I’ve only tried it on the Windows (DirectX) platform. I’d like to setup some build scripts to compile it for other platforms, and then eventually package it all up into several NuGet packages (one for each platform; I don’t think NuGet’s built-in multiplatform support is good enough for this kind of thing).