MonoGame editor

1

I’ve been having this idea for a while now… I wonder if we could make an open source, community-driven, plugin-based editor for MonoGame.

The core would contain the bare minimum and everything else would be done through plugins (that can have dependencies on each other). It would be really cool if it could run using MonoGame itself and a very lightweight, but expandable GUI lib (window handling and docking should be handled).

The goal of the editor IMO should mostly be for authoring content and speeding up your workflow to keep things code-first (that’s what draws most people to MG anyway), but the plugin architecture shouldn’t limit you to that. I imagine a couple of different plugin types. A nice thing to have would be a plugin for embedding a Game and running it from the editor (could be extended with dynamic content reloading and stuff). We’d have to get some fixes into MonoGame for this, but I have a fair idea of what needs to happen :slight_smile: Secondly we would need some simple plugins to make plugin development easier like a simple text editor, a node editor GUI extension etc. These should be very modular and focus on very specific things. This is probably the most important part to get right, a base set of useful tools will draw people to use the editor for making their authoring tools and likely contribute reusable stuff back to the editor afterwards.

Using those base tools we could build stuff for authoring content like a texture generation system, a live shader editor using e.g. MGShaderEditor and the great HLSL Tools by tgjones (or even node-based shader generation), a game state machine that can generate skeleton code, a GUI system and more specific stuff for certain game genres e.g. questing system for RPGs or level designers. Then there’d be more engine based stuff like a full rendering pipeline.

There is a lot of open source stuff built on MonoGame with permissive licenses and we could build on all this greatness we already have for MonoGame and bring it together a bit. Thinking about Nez, MG.Extended, DigitalRune, ProtoGame, your rendering engine and less extensive but very useful tools/libs like Penumbra, MGShaderEditor, QuakeConsole, SadConsole. And beyond that there’s surely a whole bunch of cool tools and libs that are not as exposed as the aforementioned.

Some of the high-level goals of this plan are

  1. Bring together the fragmented utilities that people have built on MonoGame.
  2. Expose lesser known, but useful tools to the community.
  3. Incentivize the creation of new tools and contribution of them to the community.
  4. Make it easier to get started with MonoGame and increase flexibility in how you want to develop your game. A subgoal of this is to draw more people to the framework.

While I’m slightly skeptical if we can actually pull this off, I think about it occasionally and always get really excited so I’d definitely be up for trying! It would be a nice experiment in any case :smiley:

1 Like
2

This is a great idea. There are already been some progress on certain platforms into this area such as https://github.com/tgjones/gemini. It sounds feasible to create a cross-platform, extendable desktop tool. However, I would love to see some progress on existing areas of planned features for MonoGame before this rabbit hole is developed.

3

I’ve dabbled with Gemini before. I found it a bit hard to get into, mostly because I had no experience with WPF or designing GUI’s using XAML in general :confused: But it’s very powerful and you can do a lot with little effort once you get the hang of it (though I didn’t get that far). But I’d like the UI to be more easy to use at the expense of being far less flexible. And of course we want it to be cross-platform.

What areas specifically?

1 Like
4
5

Ah yes, the graphics upgrade. I’m not sure how you think this will affect the editor though. I suspect most people won’t use the newer API’s for a while either. I’ll post a quick summary/update of the current state of affairs in a linked post.

6

It’s an interesting idea. I’ve actually made a few prototype MonoGame / WPF editors before.

One of the projects called Astrid Animator is available for download on itch.io. Although, it’s probably a bit broken at the moment. I haven’t had a lot of time to keep working on it.

I’m currently working on another one called MonoGame Content Factory which is more along the lines of what you’re talking about. I’ve thought about open sourcing it but I’m currently using some proprietary code among other reasons.

That said, if an open source project did get off the ground I’d be happy to help get the WPF bits working. It can be a bit fiddly getting MonoGame to play nicely with WPF.

I’ve also tossed around another idea, which is to flip it around and build a GUI in MonoGame and create an editor from that. This would remove the dependency on WPF and make a truly cross platform editor. It’s a bit crazy, but it could work. I’m pretty sure the LibGDX guys did something similar. If I recall correctly Spine is built with LibGDX.

Anyway… it’s an interesting idea.

1 Like
7

That’s how the Unity editor is built, from their own GUI.

8

Im always doing and redoing little editors i really think a dedicated official monogame gui namespace with classes. Would go a long way to start this sort of thing. So many people have worked on them, yet its scattered.
I have a button manager that even has a save and load box ive redone it about 20 times and i still hate it hell it can do just about everything i even made a spacial algorithm to handle clicks for when i had like 40 buttons to check, its still horrible and i hate it. My bad drawing skills don’t help, heck i realized plain squares make the best buttons.

Case in point.

How do you make editors when we don;t even have a official set of working button panels labels ect, Worse monogame is a graphical api for games by its nature, drawing of all its visual components has to be fast.

I remember shawn hargraves saying xna had action delegates for just this thing and sure they are easy to use you can make simple buttons.

but…

Its far far far from stuff like createPanel add label add button, scrollbars, list buttons toggle buttons, text boxes, Menu lists, numerical input boxes save menus load menus dialog boxes description popouts , Drag and drop items ect, all those are needed and more. Every regular app needs them and so do games.

Will each and every add on be using his its own ground up gui?
Instead of everyone pulling resources to improve just one existing monogame gui namespace. Even if it starts out mediocre i think its overdue. Each add on and editor with different button layouts setups quirks buggs and functionality or lack thereof that would be a waste. Lets face it gui’s are not fun to make yet.

Having effortless and seamless gui functionality is 90% of a editor and a prime ingredient in almost every game too. My only real worry is bloat.

9

I would much prefer this and it would also showcase a little what you can do in MonoGame.

I consider additional GUI controls to be a part of these base tools. Yes we we would need a good toolkit to unify plugins. There are other things I considered for unification purposes like a Scene class (or ar least an interface) people can agree on with models, lights and a camera.

Edit: put the high level goals in the original post

10

While I agree that having a powerful and functional GUI system is desirable, I’m not sure it’d seal the deal on making a general MonoGame editor. My concern is with the word “general”. My imagination may be lacking, but I don’t see a way to make a truly generalized editor that allows people to build content, without making assumptions about their data.

As an example, lets say person 1 is building a 2D tile based game.
Person 2 is building an FPS.
Person 3 is building a mostly procedural resource game, but needs to create some prefabs.
The data structures backing each game are going to vary intensely.

I think that before declaring a GUI framework needs to be created, we should ponder what common threads can be pulled into an editor.

11

I like the idea of having a GUI framework.
Definitely the possibility to create user interfaces or editor interfaces in a Monogame environment (rather than a winforms one) is very appealing to those of us running on other platforms

12

The idea is not to make a general editor, the idea is to make a very lightweight editor that you can get plugins for that help you make your game. By default you won’t have any plugins installed.

Controlling or even knowing about the data structures backing these games are outside the scope of the base editor. The goal is not to be like the Unity editor or whatever game engine editor you’d like to compare it to.

@cdhanna and @hokum In general I think you misinterpreted the idea I have here. The focus is not the GUI tools, it’s the plugin architecture. The base GUI toolkit will be as minimal as possible and not for use inside games itself, it will not be written for flexibility, but ease of use. It will be much more like WinForms than WPF, maybe that gives some perspective. It will be for stylistically unified editor interfaces, not generic in-game user interfaces. My idea is that the style will be fixed except for the colors. I’d like those to be determined by an editor theme, I think just a light and dark theme is sufficient. We could possibly support custom themes, but I don’t think that’s necessary.

Obviously you can use these tools however you want, so if you want to make a cross-platform app with the GUI, you can do that. You just can’t change the style much unless you dig into the code, but there are way better alternatives out there in this case.

13

@wilmotil I reread your comment and there’s some points I’d like to make.

It will not be official, though I hope to get a large part of the community behind it.

The editor should not use the Game class. Rather I’d like to write some code to interface with either SDL or native windowing systems to get paint events/message so the editor can act more like a regular editor than an actual MonoGame game.

14

I think before anyone can discuss this seriously we need to define a common set of terms explicitly.

idea is to make a very lightweight editor that you can get plugins for
that help you make your game. By default you won’t have any plugins
installed.

When you say “Editor” i think about the nurbs editing class i never finished for making terrain.
I used the mouse and had a few buttons to alter it ect. I think about the the google sketchup 3d app. Which i thought had such a nice button and graphical user interface to its editor i even used it to make some .x files in xna.

The focus is not the GUI tools, it’s the plugin architecture. The base
GUI toolkit will be as minimal as possible and not for use inside games
itself

I might say but i want the GUI toolkit in my game ?

When you say get “paint events” messages but “not use game1”. I think winforms slow gdi painting i don’t think monogame or even direct x but windows gdi applications not meant for games. I think that nurbs editor would be useless in real time and need to run from game1.

The goal is not to be like the Unity editor or whatever game engine editor you’d like to compare it to.

But a goal to not be like something else is no goal at all it doesn’t say anything.

Are we talking about a separate app like winforms that creates a game1 in its window ?

What does a plugin actually do then for a game1 project? Does it just download and install other projects into your game1 thru some sort of interface ? Is it a search engine downloader and installer?

When you say “editor plugin” in but not “use game1” That context is unclear to me at all, how this relates to, the editor i would like to make. Is this a editor at all, is that the correct word. Will i plugin a camera to be accessed from game1 to my mono-game project, or does this only work in the editor ?
What will it actually do and how?
What are its responsibility’s and were do they extend to and end at ?

In MonoGame when i think of ‘plugin’ i literally think of example code or someone who has posted up a helper class or even a namespace.

It will be much more like WinForms
It will be for stylistically unified editor interfaces, not generic in-game user interfaces

There is not enough context here to visualize what this means.
What would be a good comparison to a existing known application.

Winforms is basically a event based ‘non-real time visual graphical user interface’.
But we need a ‘real time’ graphical user interface in a game, at least most people do.

When i hear GUI i think a graphical user interface which in almost any app is the assorted types of buttons panels there callbacks and routines for placement and control layout and control commands that access or interact with normally private or internal methods safely.

I mean that is what winforms is. take its buttons panels and all that stuff away and its just nothing its not even suited for graphics then. I might as build all that from monogame then from scratch

So while different terms mean different things depending on context.
In fact we maybe talking about completely different things with the same words.

Unless we strictly define our terms we can’t all be on the same page.
Such that i think we need to define what each word is to mean and in what context.
With similar examples of existing things if possible, as we use those terms.

MonoGame Gui ?
MonoGame Editor ?
MonoGame Plugin ?

15

When talking about this stuff it’s all too easy to get lost in the technical details of how things are going to work and forgetting the big question.

How does it to help people make games?

It’s a big question. To be honest, I don’t really have an answer but I think it’s a good starting point.

For example, let’s say I’m working on a game and I want to add some smokey fire to my game. For this I’d probably want to use some sort of particle system. At this point I could roll my own particle system, or use an existing library. I could manually hard code the effects in code, or use a particle editor to create them.

If smokey fire is the only particle effect you want in your game using a particle editor is probably overkill. On the other hand if you’re planning on having lots of effects then using an editor is they only way to stay sane.

Okay, so now I know I want to use a particle editor for the particle effects in my game but I don’t have an editor. I could find an existing one (pros and cons) or I could write my own (more pros and cons). In either case, there’s going to be some work to do, but that’s okay I’m a game developer. I like work :wink:

This process is going to turn up in a bunch of places in my game. Levels, GUI, entities, sound effects, sprites, animations, 3D models, etc. In some cases there’s already obvious solutions. I don’t think we should be trying to reinvent the wheel here. Nor should we be trying to create the ultimate generic solution either.

My point is that it doesn’t have to be perfect. It just needs to solve an immediate problem. It certainly won’t solve every problem in every game but it could go a long way to making someone’s life a little easier. This applies to every editor and library out there. They are one way to get to an end goal. That’s okay.

I’ve seen this kind of project before in other game development communities. Sometimes they work and sometimes they don’t. Quite often the problem is that the editor is a little too generic trying to solve all the problems for all the things. Or it has it’s heart in the right place, but it’s not so easy to use (i.e. write a plugin for).

That’s not to say it has no value though. Often just having the code on github is a tremendous resource for other people wanting to create their own editors. If that’s the goal, by all means, do that.

All I’m saying is, tackle this from the perspective of solving a real problem when creating a real game and things will go a whole lot better.

16

Effective things eliminate duplication by offering easily overridable generic implementations.

Case in point

Game1 : Game

What does it give me or do for me.
Not much and a whole lot at the same time.

17

Then put it in:

You have the wrong idea. If you check out the internals you’ll see Game just runs a simple loop consuming some necessary events for input, focus change, etc. from SDL or through WinAPI depending on what template you’re using. By catching the paint events you only have to redraw when stuff gets invalidated instead of redrawing the whole thing at 60 fps so it would in fact be faster and less resource intensive than an actual Game. And you can use DirectX/OpenGL like usual through the MonoGame API.
I’m not entirely sure how flexible the SDL API is in terms of this though.

I’ve stated the goals in the main post. Don’t interpret this out of context, I was making a point that the editor will not be connected to the datastructures in your game.

Like I said above there won’t be a Game implementation in the editor, but I’d like a plugin for embedding your game in the editor.

I haven’t given much thought to how that type of plugins would work yet. Like I said, the focus is content authoring tools. Those do not interact with your runtime.

I think the paragraph above explained this, the editor/plugins won’t be running inside your game.

My comparison with WinForms was not for the visuals, it was for the structure.

That fits way better for this editor than an actual game. The fact that I cal it an editor and that it won’t use Game doesn’t mean it will be unresponsive…

Then use EmptyKeys or one of the other great GUI solutions around, this is not the goal of the toolkit that comes with the editor. Like I said, the GUI is not the goal it’s the means.

Sorry if I was unclear about any of this. When I say ‘editor’ I mean the core without any plugins. By GUI toolkit I mean the library that will handle the UI of the editor. Compare it to GTK or WinForms. By plugin I mean separate libraries that run on top of the editor to help you make a game.

@willmotil I hope that cleared things up a bit.

To everyone reading and possibly with high expectations, can I just say that this is by no means a very developed idea. I don’t have anything on paper and I haven’t written a single line of code yet. I’m just playing with the idea and wanted to see what the rest of the community thought about it for now.

I fully agree! The intent is to solve these kinds of problems where there are no decent or free alternatives. GitHub Issues could serve for feature requests and thumbs up’s for priorities so we can get an idea of what people need.

Thanks for the tips @craftworkgames :smiley:

I’d like to reiterate that this is not something from MonoGame officially and the name of this project will not be “MonoGame Editor”. I’m not a maintainer or in any way involved in the organisation of MonoGame, I’m just an enthusiastic contributor/community member :slight_smile:

18

This clears it up quite a bit i think.

When I say

Editor
I mean the core without any plugins.

GUI toolkit
I mean the library that will handle the UI of the editor. Compare it to GTK or WinForms.

Plugin
I mean separate libraries that run on top of the editor to help you make a game.

So if i were to make a analogy to this idea like so.

  • This Visual Studio is a C# code editor and compiler for applications.

  • This MonoGame Studio is a MonoGame plugin linker / code editor for games.

Is that about right ?

19

Yes on the plugin linker, but no on the code editor. The editor will by itself be completely useless. It just manages plugins.

20

So will it output many possible linked plugins for use in a game1 project ultimately then ?
If so in what way do you envision a user will interface or use those plugins from a game project to say will it create a class file with accessor methods and such ? Or a entire project or will you need to load content the resulting output of the editor ect?