Create My Own Color Struct?

It does not. It’s perfectly fine (legally) to use your own abstractions to hide MG stuff behind. It’s also fine to build a commercial engine on top of MonoGame. You just need to include the original license in source code distributions.

@Shadowblitz16 I don’t really get the point of what you’re trying to do though. It made sense to me when you said you wanted your engine to be usable without MonoGame, but by directly using MG classes internally that’s not going to work. There’s also no benefit in recreating MG structs and it’s a pain to do.

2 Likes

I forgot to mention including the MG licence, but probably because it sounded like he wanted to obscure it entirely… EDIT Which no matter what, would be wrong…

It’s a lot of work for not a lot of pay off. MonoGame itself is already an abstraction of the machines that are out there…

1 Like

well my original plan was to expose the monogame color struct as part of my engine, so that I didn’t need to include monogame itself.

for example I would only have to do this…
`
using AC.Engine.Graphics

namespace AC.Engine
{
    class Texture
    {
        list<Color> data;
	public Texture()
	{
	   data  = new list<Color>();
	}
    }
}

`

I would be fine with including the mg licence as long as I could sell my editor and runner

1 Like

MonoGame is MIT-licensed, so yes, you can sell products based on it. Doesn’t matter if they are games, engines, educational software, etc.

It is not uncommon to abstract away from a specific platform. That helps to make games portable in general. MonoGame is already portable on so many platforms, which is nice and convenient. Eventually I want to go down to lower level frameworks as time permits. For myself, while building a specific type of engine, there will probably never be a perfect framework that matches up to my work flow, or custom tool chains, hence why I like to minimize the use of the framework directly in my game. This is also why I choose not to use Unity, as I want my own APIs and work flow.

My first iteration of my current game engine, I essentially wrapped MonoGame. This left me with a very MonoGame feeling game, which is not a bad thing, just not quite where I was wanting to be. I was able to do much my work flow, but it wasn’t so clean as I would have liked.

In my second iteration, which is a work in progress now, I wanted as much of my game engine as possible to be in the work flow I wanted, and using as much .NET Standard 2.0. I also wanted to push MonoGame farther down in my library so I could really focus on my engine and less on platform and technology. I decided to go with a Domain Driven Design approach.

Without going into an excruciating explanation of DDD, I simply have 3 major tiers. Application, Domain, and Infrastructure. Each tier might be 1 library or a collection of libraries (depending on how you want to organize your code).

The Domain is the heart of the engine runtime. There is no MonoGame references in it. Matter of fact, there are no technology or infrastructure references beyond what comes in the .NET standard. When I need access to some type of “infrastructure”, which could be devices, video, sound, network, etc. I define interfaces for all of those infrastructure elements and the way I want to use them. That’s the heart of what the Domain tier tries to accomplish. Focus on solving your domain problems. This approach also allows for easier unit testing, since I can mock the infrastructure services.

The Infrastructure tier is the part that talks to any of the local hardware or network resources. I can build different infrastructure tiers, based on what platform/framework I want. The Infrastructure tier wraps the platform specific code into a class that implements the interfaces defined in my Domain. The domain does not reference the infrastructure tier, ever, rather the infrastructure tier references the Domain, and implements it’s interfaces.

I then have my Application tier, which references the Domain and the Infrastructure. This is where I do my dependency injection. When I construct my Domain Game instance, I can inject the infrastructure elements needed. The application tier actually does very little, other than subclass the Framework.Game object and instantiate my Domain.Game object. Action methods simply call the action methods in my Domain.Game, which then transforms all of that to satisfy my game’s needs.

Using this approach, you can do it sort of trial and error, but it really helps to work out how you want your Domain to function, as you might choose to go down a path that is terribly incompatible with some types of infrastructures, and the transforms might be costly (can’t imagine how I figured that out :stuck_out_tongue: ). I have spent a lot of time in just figuring out how I want to inject the infrastructure objects into my system, and how those will be referenced. So far, it has been time well spent.

If you are not familiar with Domain Driven Design, there is plenty of material that will leave you in daze. I actually follow the model Microsoft illustrates for DDD. It is in the context of micro-services, which is more attuned to what I do professionally, but it very much can be applied to game development.

I know this is off topic a bit, in the area of implementing color, I went with using .NET Standard for color in every place in my Domain. I defined an IColor interface with a ToSystemColor() method. In my Infrastructure tier, I created Color struct that implements the interface, wraps the MonoGame Color, and provides a constructor that takes a System.Drawing.Color, and implements the ToSystemColor(), returning a System.Drawing.Color.

	public Color(System.Drawing.Color c) {
		_color = new Microsoft.Xna.Framework.Color(c.R, c.G, c.B, c.A);
	}

	public System.Drawing.Color ToSystemColor() {
		return System.Drawing.Color.FromArgb(_color.A, _color.R, _color.G, _color.B);
	}

For anything MonoGame specific, I can use the Color class I created to wrap the MonoGame Color. In my Interface methods that require color, I make sure they use System.Drawing.Color.

Design a DDD-oriented microservice