Split out the dependency on Lidgren

[dellis1972]

We need to split out the Networking and GamerServices into seperate projects so that the code MonoGame.Framework does not have a direct dependency.

This will mean users not using networking will not need to reference the dlls.

[bonesoul]

+1 on this.

[dellis1972]

This is on the todo list, it is however a large amount of work and
will probably result it the framework being spilt up further.

Dean

On 20 March 2012 12:06, raistlinthewiz
reply@reply.github.com
wrote:

+1 on this.

---

Reply to this email directly or view it on GitHub:
#381 (comment)

[Eversor]

+1 It's not such a big job, for obvious reasons GamerServices and Net depend on it, i do usually remove the 2 folders and a pair of references that give an error, everything works nicely!

[SimonDarksideJ]

Well I've no issue taking up this challenge while I'm doing the split "Core" project.
Arguably Networking and Gamer Services should have their own distinct libs, more so that they can be switched out with other solutions.
Any preferences for how the breakup should occur?

@tomspilman has had some particular views in the past about these kind of platform breakups

[KonajuGames]

I would have split them in the same manner as XNA, i.e. Framework.Net and
Framework.GamerServices assemblies.​ To go further, the Framework.Net
assembly could be the implementation-agnostic part (possibly a PCL) and a
Framework.Net.Lidgren assembly that implements the bits that use Lidgren,
and in future a Framework.Net.Enet assembly that uses Enet.

GamerServices could be split in a similar manner, with a common assembly
and assemblies supporting Game Center, Google Game Services, Buddy,
ScoreLoop, etc.

This would allow Net and GamerServices to be removed completely, or if
used, the specific implementation to be selected by the dev.

[tomspilman]

Any preferences for how the breakup should occur?

As @slygamer pointed out breaking it up like XNA does wouldn't be a bad thing. I just worry about the number of CSProj files we'll need to maintain with all these splits.

[SimonDarksideJ]

I wholeheartedly agree about the .csproj issue @tomspilman and PCL's wont help with everything just yet.
I'd say (as seems to the the best solution) to just start small with just the networking for now, most of that I believe we can put in a separate PCL and look to host code that wont fit into one in to a helper class, use this as a template for moving forward.

Interestingly enough, I've been doing testing (in the adrotator V2 project) with the current reflection helper but inside the PCL as it some support a level of reflection and found that there is no need for all the #if blocks.

Will se what I can come up with in a first draft for networking alone, might look at gamer services if I have time.

Only real query I have is whether to make work like a plugin or as a completely separate lib?

[KonajuGames]

Plugins won't work nicely on mobile or console where it needs to reference
all the required code at compile time.

[dellis1972]

I'm gonna throw this idea out there.

It might be possible to move to a single solution for the desktop platforms
if we use Conditionals for things like references etc. E.g

v4.5
v4.0

Then all we need to do is define a number of build configurations with the
appropriate properties like we do for the content builder.

That would reduce the number of csprj's we need to maintain and would have
the benefit of not having to add new files to 7-8 different projects.

I don't think this will work for android or iOS (it might though). Also
we'll need to check if Xamarin Studio supports conditionals in the csproj
files.

On 25 May 2013 04:43, slygamer notifications@github.com wrote:

Plugins won't work nicely on mobile or console where it needs to reference
all the required code at compile time.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/381#issuecomment-18439178
.

[SimonDarksideJ]

I suspect the conditionals will work in Xamarin Studio as it still follows VS pattern for the csprj / sln files

Interesting idea @dellis1972 will at that into the mix when experimenting

[tomspilman]

move to a single solution for the desktop platforms if we
use Conditionals for things like references

We've done this in a few places... it does work in VS2010/2012.

I would still like to investigate premake first. I just haven't had the time myself.

I suspect the conditionals will work in Xamarin Studio

I wouldn't be so sure. Last time i looked the support they had was hard coded to look for very specific keys in the places where they are normally found. This would have to be tested first.

[KonajuGames]

Yes, MonoDevelop/Xamarin Studio has just enough MSBuild support to allow it
to do its job.​

[SimonDarksideJ]

Hmm, will have a look into PreMake if I can find the time while mapping the split for network

[KonajuGames]

I have started a premake script (#1722). Still a long way to go. It is a
lot of work to get it functional, let alone right.​

[SimonDarksideJ]

Fantastic news @slygamer , considering @Ark-kun 's comments in #1733 , do you think it might be possible to automate the "piranha" portability tool to automatically generate the .portable project?

[tomspilman]

to automate the "piranha" portability tool

Do you have a link to this tool?

[SimonDarksideJ]

That I do not know yet Tom, just a reaction from the comments from @Ark-kun in #1733, best to ask that question in the other discussion.
Haven't found any reference to this tool mentioned or a repo it's maintained in.
My query at this point was just a reference, so if this "tool" proves useful, might be worth investigating if premake could run other tools to create other platforms

[KonajuGames]

Stripping the code out of assemblies is how reference assemblies are made.
Reference assemblies are used by the IDE and compiler when a different
platform than the host is targeted.

Reference assemblies are not the same as portable class libraries.

[SimonDarksideJ]

That is true, they are not PCL's, however the aim of the .Portable platform isn't so much to implement a PCL project but to give a way to build your game against a shim framework for all platforms and when coupled with an actual platform it just runs.
The .Portable platform never actually runs a game, it's more like a big interface for MonoGame (without interfaces)

@Ark-kuns proposal is interesting but personally I don't think it could cope with all of MonoGame's complexities at present.

[tomspilman]

The .Portable platform never actually runs a game, it's
more like a big interface for MonoGame (without interfaces)

Can you explain what this workflow is like for end users? For example if I install MonoGame from the installer... how does this .Portable platform appear? How do I use it?

[SimonDarksideJ]

Better to show you, read the latest post I did on the subject here - http://darkgenesis.zenithmoon.com/monogame-building-portable-solutions/ starting from the "Starting Fresh" chapter.
Also a demo project in my presentations repo - Demo 3 - https://github.com/DDReaper/DarkGenesisPresentations/tree/master/MonoGame/SneekPeekintoX-Plat/Demo3

but if you want the short / short version

• Build a new PCL project for your game
• Reference the MonoGame.Portable platform
• Build your game
• Create a new Platform project (Windows, iOS, Android, etc)
• Reference your game PCL
• Check references to the specific MonoGame platform dll for your game project
• Call the required functioning in your Game (engine?)
• Run

Repeat the last 5 steps for any other platform without changing the game code.

In each platform the only thing you need to worry about are the parts specific to those platforms.

Main aim is to have the core project as centralised for the core game code in a similar way to today with separate class libs for each platform but you get the benefit from the PCL solution that all code in the "Engine" PCL project will run on all platforms without having to rebuild them to find out.

[SimonDarksideJ]

Oh and in reference to the MonoGame installer, it acts like any other platform. Just needs a project template to create a PCL project with a reference to the PCL version of Monogame.
No different to any other platform in that respect

[tomspilman]

but if you want the short / short version

I'll test out your linked project and read thru your article... at first glance it seems just as complex as not being portable.

[SimonDarksideJ]

No more complex than creating a game using a separate lib, it pays off the more platforms you add to your portfolio.
Benefits from architecting your game correctly from the beginning, same as you would when you build cross platform apps (check out @slodge 's MvvMCross presentations using Xamarin)

[SimonDarksideJ]

Bear in mind, the example in the repo is just a very basic one as it was meant for the presentation and walk-through 💃

[tomspilman]

No more complex than creating a game using a separate lib

See we don't bother with that at all.

We have one csproj per-platform, use wildcard includes, and a few #ifs here and there for platform specific issues. At this moment i don't see PCL being any cleaner than our own technique.

[SimonDarksideJ]

Well to each their own @tomspilman it's another option when building projects cross platform. Main reason I started doing the .Portable platform was due to interest raised in the issues log plus personal interest.

As you yourself have stated, having too many #if's all over the place can make life difficult over time

[Ark-kun]

@tomspilman The point of some kind of portable MonoGame dll is that it allows to avoid platform hell when using MonoGame-based support libraries (think animation, physics, tile game engines) which aren't using anything platform-specific. Authors of these libraries are either forced to maintain and distribute separate platform-bound versions of their libraries or just don't bother and only release a version for a single platform. It's fine when you're the a single developer creating a game and have all the code, but when you don't have the sources to some classes you cannot do anything.

P.S. Either way I'm liberating myself from this platform-hell as I'm now able to automatically create portable MonoGame libraries (https://skydrive.live.com/redir?resid=E4ECA4072D08CEE5!2870&authkey=!AHOdZuFxNvZlP4I) from vanilla ones. Just a bit more fixing and tuning...

[Ark-kun]

My Piranha tool to https://github.com/Ark-kun/Piranha, but don't look there yet as I've managed to destabilize and break it with the shower of late-morning commits =(

[Ark-kun]

@tomspilman

Can you explain what this workflow is like for end users? For example if I install MonoGame from the installer... how does this .Portable platform appear? How do I use it?

I see the workflow like this:

1. There is a new project type: Portable MonoGame Library. This is just a standard .Net Portable Library Project with an added reference to the shim/reference/skeleton version of MonoGame.Framework.dll with CopyLocal=false and has the usual Game1.cs class file, but probably no Content folder (Are resources platform-specific? Probably yes, since there are AndroidAsset etc. content types)
2. User writes the game code (or just creates any classes and helpers that use XNA classes).
3. User builds the project and gets Game1.dll
4. User creates a plain old platform-specific MonoGame project (like "MonoGame Android Project")
5. User adds reference to his portable Game1.dll, removes the default Game1.cs file, adds content, builds project.
6. Repeat 5. for all platforms.

So the only difference is that Game code is moved to a separate PCL dll which is then shared.
Binary dll sharing and portability instead of the source code sharing and portability.

This doesn't make much difference when all game code is a single code base, but if you want to use shareable components this makes life much easier.

Basically the number of projects is:
Non-portable: Platforms.Count * Components.Count
Portable: Platforms.Count + Components.Count

Makes big difference even for 2 components (like game + animation lib).

[Nezz]

What do you think about moving on with this now that protobuild is in place?

[tomspilman]

I think it is very much worth considering.

I guess it means having a separate MonoGame.Framework.Net project for each platform? This new assembly would have a dependency on MonoGame.Framework, but not the other way around.

[KonajuGames]

I had started this a while ago in a branch in my local repo, but it would
be out of date now. I could update it and keep going with it.​

[JamesLupiani]

I'm not sure what's to be gained by having a MonoGame implementation of Microsoft.Xna.Framework.Net and (almost all of) Microsoft.Xna.Framework.GamerServices in the first place. They're basically managed wrappers around the Xbox LIVE API.

[tomspilman]

almost all of) Microsoft.Xna.Framework.GamerServices

Oh yea... I guess some parts of GamerServices are dependent on Lidgren as well.

[KonajuGames]

On some platforms such as iOS GamerServices wraps GameCenter.
GamerServices shouldn't be dependent on Lidgren.​

[tomspilman]

Done! #2514