search

MonoGame / MonoGame

One framework for creating powerful cross-platform games.
http://www.monogame.net
Other
11.3k stars 2.9k forks source link

Headline discussion: MonoGame Modularisation #2550

Open SimonDarksideJ opened 10 years ago

SimonDarksideJ commented 10 years ago

Note, this is a discussion point about the design for separating out XNA namespaces into separate DLL's as a focal discussion point. Discussions about individual separations and the work involved should be kept separate.

Right, following on from the .Net (networking) separation, I thought I'd open up a fresh discussion about moving on from there. There has been a lot of talk about splitting out the namespaces into separate deliverables (regardless of platform) to ease deliver, management and consumption of the Monogame.Framework.

A lot of the talk devolved into discussions about platforms or PCL's, this discussion is ONLY for discussing how the breakup should continue from an architectural view, please keep this discussion on target.

The XNA Story OK, So from XNA's view, their deployment had the following deliverables (as a start point for discussion only) excluding the already complete .NET separation

Initial MonoGame Proposal As others have stated on numerous occasions, I also do not feel that MonoGame should go this far. My gut feel (as a starter for 10) is that we should look towards the following design:

I also have a view that the MonoGame.Framework library should also contain all code that is non-platform specific (no #IFs) but this may need to be considered on a namespace by namespace basis as some may need to be in the separate library to allow for better modularisation or a plugin style approach.

Keep the fight clean and GO.

craftworkgames commented 10 years ago

Okay, the way I see it there's 2 primary reasons to split a project into different DLL's.

  1. To isolate a dependency.
  2. To make it easier to reference.

If you think about it, these two things are closely related. It really comes down to one rule. You don't want to reference dependencies you don't need.

The .Net (networking) split is a good example of this. I remember someone saying that the sample projects were difficult to maintain because they carried a dependency on networking that they didn't use.

Another example is referencing MonoGame from a 3rd party project. For example, it's possible to build Farseer Physics to work with MonoGame by swapping out the XNA references for MonoGame one's. But, currently this means you're building Farseer with all of MonoGame's dependencies even though it only needs a few core classes. All of the required classes are pure C# and carry no other dependencies themselves.

For this reason, I agree that the core MonoGame.Framework.dll should only contain non-platform specific code ideally.

thefiddler commented 10 years ago

In the proposed separation, would all platform-specific code go into MonoGame.Framework.Graphics and MonoGame.Framework.Storage? The issue I see with that is that MonoGame.Framework.Graphics will then carry code that has nothing to do with graphics: input drivers, audio, windowing at the very least.

In that case, MonoGame.Framework.Platform might be a better name:

Other than that, what is the actual goal of this separation? Is there a specific reason why the original XNA module separation is discarded?

KonajuGames commented 10 years ago

I'm not sure why Storage is called out to be separate, unless that was just an example. Also, I do not see why MonoGame.Framework should not contain any platform-specific code. We're not talking about PCL here, so what other reason for the emphasis on no platform-specific code in MonoGame.Framework?

Namespaces can be split across assemblies, and XNA does this. Some parts of Graphics, GamerServices, etc are in Microsoft.Xna.Framework.dll and the rest of the types in those namespaces are in their respective assemblies.

SimonDarksideJ commented 10 years ago

@thefiddler There are two options there, either

@KonajuGames I called out storage because as a working example I can could choose to use MG's way of storing files OR use my own implementation. I found myself doing this a lot in XNA days, i almost never use their .Storage dll. in my view it's a good next step with that namespace. But as with anything else it's up for discussion if it's a good idea to separate that namespace to its own DLL or not.

The examples I game were just (in my view) the best candidates for the next namespaces to separate out, based off previous discussions that have gone on both here and on the community site and beyond. Just my view, doesn't mean I'm right, lol

flibitijibibo commented 10 years ago

Something I get asked about frequently is whether or not FNA will somehow be binary-compatible with XNA4 itself, is that a concern at all with this separation project? I have no idea if this is even feasible (particularly since C++/CLI is involved there), and humorously, the only people who ask me about this are Wine developers, but it might be something to think about.

tomspilman commented 10 years ago

the only people who ask me about this are Wine developers

MonoGame uses regular Windows APIs. So it should work there, binary compatible or not.

Still, no, MonoGame isn't binary compatible nor is it a goal of the project.

SimonDarksideJ commented 10 years ago

So is there any consensus as to which name space should be next and the method of the split?

tomspilman commented 10 years ago

Well first I want to live with this first Net assembly split for a few more weeks before making another move. I've seen a few people have trouble with it, but nothing major yet.

Once things settle with the Net assembly we should look to move the code into a top level MonoGame.Framework.Net folder. We would take the time to rearrange the source at the same time using the partial class .platform.cs style we've developed.

After that it is hard to choose what the next step should be.

I know a common issue is 3rd-party libraries... mostly physics libraries... wanting access to math types without having to link against a bunch of different platform specific libraries. Not sure how to best achieve this.

SimonDarksideJ commented 10 years ago

I'd certainly be in favour of a re-org. I personally don't like these separate folders for each platform as it lends confusion to what is in use. So moving them together and using the .platform.cs will help give a clearing understanding and help ease (eventually?) merging them in to a single interface. But this should be a separate design choice, so maybe start a separate thread for that discussion.

The base types in a single lib will help a lot of people I think an also the 3rd party libraries. So maybe that is a good enough reason to keep MonoGame.Framework in a single lib and all other namespaces in another to begin with, but not sure which way you would name them, When we originally did the .core DLL, this moved the base code to a new DLL. (But I prefer the base code and types "non-platform specific" in a dll called MonoGame.Framework imho)

Taking a breather would be good as it would give me time to get the sample in line with the changes and update the NuGet's

craftworkgames commented 10 years ago

The base types in a single lib will help a lot of people I think an also the 3rd party libraries.

I agree. Maybe a good way to approach this is to consider the requirements of a few different 3rd party libraries. For example, Farseer Physics uses a small handful of the "math" classes. You can easily see in the source code here: https://farseerphysics.codeplex.com/SourceControl/latest#SourceFiles/Common/MathHelper.cs

I'm sure most of the physics engines that support XNA work the same way. I wonder what other libraries might be worth considering? Particle systems? GUI systems?

KonajuGames commented 10 years ago

Those libraries (physics, particles, GUI, etc) would more than likely be using many other parts of the framework as well, such as input, rendering, sound, etc.​ It is incredibly rare to see those small sections of the framework used on their own.

craftworkgames commented 10 years ago

@konajugames yes you're probably right about some of them. Although, I can vouch for Farseer physics because I recently recompiled it against MonoGame using only those classes in the common folder from MonoGame. It does provide an optional debug renderer but that's not required.

GUI of course needs rendering and input but probably not sound in most cases.

Particles probably only use rendering.

But, they all have math classes in common so I still say it's a sensible split.

Lastly, I've also seen all 3 types of libraries (physics, GUI and particles) implemented without needing rendering or input by providing interfaces for those things.

Math libraries are really hard to put behind interfaces.

SimonDarksideJ commented 10 years ago

Like with everything else it's a matter of taking steps. 1st step is to have a general library with just the base types / classes and structs. Then based on feedback either more can be moved in to the base to support more cases as required.

The question is, do we create a new lib for the base classes, or do we separate out the other namespaces leaving only the base classes in Monogame.Framework?

Either approach works, the question is how MonoGame should look following these changes?

P.S. With protobuild this is all very easy to do, so its just a question of what it should look like in the end.

KonajuGames commented 10 years ago

There's also the end users to think about. Try to minimize the disruption for the hundreds of existing projects out there that reference MonoGame.Framework at the moment.​

SimonDarksideJ commented 10 years ago

Well that goes without saying :dancers: Any ideas which path would be the least disruption?

I don't think for the other namespaces it would be too big of an issue because we would still ship them all by default as active in the templates and nuGet

thefiddler commented 10 years ago

I'd say both approaches would cause a similar amount of disruption downstream. There are two pertinent questions here:

. My gut feeling would be to keep cross-platform types in MonoGame.Framework and move the rest outside. Afterwards, as the required interfaces are hammered out, more types could be moved into the core library.

2014-05-20 16:06 GMT+02:00 Simon (Darkside) Jackson < notifications@github.com>:

Well that goes without saying [image: :dancers:] Any ideas which path would be the least disruption?

I don't think for the other namespaces it would be too big of an issue because we would still ship them all by default as active in the templates and nuGet

— Reply to this email directly or view it on GitHubhttps://github.com/mono/MonoGame/issues/2550#issuecomment-43629779 .

craftworkgames commented 9 years ago

Issue #3405 has evolved into this discussion. There may be others as well, what do we do about merging / dealing with multiple related issues?

craftworkgames commented 9 years ago

For reference, I created a complete list of XNA classes grouped by DLL and namespace. I couldn't find anything like this online so created it myself. It might come in handy.