Scenegraph Monogame

Hello, colleagues! I want to share my developments and wishes. Initially, I was uncomfortable when I tried to use only the Monogame component system (IGameComponent in Game.Conmponents). But when I tried the popular C# game engine (I won’t say the name), I was attracted to the game object management system. I tried to recreate a similar system, but with my own facilities. The result is a SceneGraph project of containers with components.

ZZZ.Framework Hyperlink to Github project:

  • Objects with components and child objects.
  • Automatic start and shutdown of components.
  • Functions and methods for adding/removing/receiving components and child objects.
  • Automatic addition of related components (for example, the SpriteRenderer sprite drawing component is linked to the Transformer positioning component. The Transformer component will be automatically added along with SpriteRenderer if it is missing).
  • A system of registrars. For example, if you create an UpdaterRegistrar~IGameComponent~ logger and add it to the SceneGraph root, it will automatically receive every IGameComponent added to any container on the scene. Registrars make it possible to fill in data and monitor components. For example, UpdaterRegistrar~IGameComponent~ will call the Update(GameTime) method from IGameComponent.

After creating ZZZ.Framework, I used it in conjunction with Monogame. This resulted in several 2D projects:

  • Transforming: 2D positioning by vector, scaling and rotation. The Transformer component is the main component of each container. I will highlight from the advantage that Transformer automatically creates a new position if its parent container has changed its position. It is possible to translate from local to world coordinates, and vice versa.
  • Rendering: Draws each renderComponent depending on the RenderLayer layer. The advantage is that one component can be drawn on multiple layers. The same applies to the Camera component (the camera displays certain layers). The base component renderComponent is the basis for creating other drawable components (for example, SpriteRenderer, TextRender and TilemapRenderer).
  • FarseerPhysics: The FarseerPhysics project is connected to the project and Rigidbody and Collider components are created. The rigid body and the collider can work in conjunction or not. Of the minuses, I will add that I could not link Collider with child Colliders…
  • Tiling: A simple tile system. There are static, animated and managed tiles (the managed tile changes itself depending on the neighboring tile). There are also physical colliders for each tile. Downloading from a file .tmx is not supported yet.
  • Animating: A system for animating sprites, depending on the values of the parameters in the AnimatorController. The controller has stages and conditions for which the animation of the object is played. There is also synchronization of one AnimatorController for other objects (for example, the animation of the legs is played together with the animation of the body, although there is only one AnimatorController).
  • Auding: sound and music components. Sound components can change their volume and balance depending on the position of the listener. The music component can play a playlist with music.
  • Asseting: There is an AssetManager that can create copies of objects, save to XML and upload content files. With proper use and compliance with the rules of object serialization, you can save the entire scene to an XML file and upload it back. Note that in XML files, media files will only have a path to the physical file. And if the media file was not downloaded from the file, then it will be fully serialized into an XML file).

The writing code is like a beginner’s. Somewhere in the project there are crutch solutions, but they are temporary.

The projects described above are wrappers of Monogame classes. This makes it possible for cross-platform development.
Actually, in this post I wanted to find like-minded people and critics. Perhaps some people will like this idea and they will create their own components and use them in other projects (not only in Monogame). Maybe someone will criticize this project and write a worthy criticism.

Still, for those who are interested in the idea, I can prepare a video and demonstrate the functionality of the project.

Hyperlink to Github project. See Monogame folder.

1 Like

Hey, I have been also working on a (somewhat) complete package of features for monogame in the last 1.5 years. The result is a ui library, ecs library, physics engine, and deferred renderer, audio, input library, and level editor (using the ui library), all under one monogame project.

My project focus on a 2d engine, as I don’t have the time to go create a full blown 3d engine, too much work. So this project that you are describing looks similar to what I am doing, which is cool! I would like to see a video of a “features overview” if you would like to share with us. If not, some sort of example project with one scene that showcases most things would be cool too.

Thanks for the answer! I am attaching a demo version Demo on Github. I also posted a demo project on github.

Is your project publicly available?

Hey, I don’t have it hosted on Github, my version control is PlasticSCM, so I think they store the repo somewhere else.
But I can show it to you if you want, there is nothing secret about it :slight_smile:
Btw, nice scene component framework. I could download and take a look on visual studio. I couldn’t run the demo though. All projects create only a static library, there was no exe

I am also very interested in starting a 2D engine with editor project with the help of some members of MonoGame community if anyone is interested. I have been working with MonoGame since 2018 and I have learned a lot. I just feel that it takes too long to build a game or prototype with it, although working with C# is great!

Let me know if you would like to be in the team. I want to keep the project simple, no 3D, just purely 2D stuff, but nice. And what I mean by nice is, to have out of the box: level editor window, inspector, 2d light and shadows, normal maps, UI library, ECS scene, 2D physics system, particle system (and editor), spritesheets, etc…

I have some of those features in the project I am currently working on, but somehow I don’t think it was implemented in the best way, and I would love to rewrite them and also get help from other people who want to jump in and own a certain area of the engine, so we can all grow it together and learn together. Hopefully, it can become a somewhat default 2D engine for MonoGame.

I will make a post about it in the main threat. Explaining the project.

What are your thoughts?

I will look at your project with pleasure. But I can’t guarantee that I will always be able to participate in it, since I am engaged in my own project :slight_smile:

Wow. It’s really a lot of work.
I’m also working on something similar now, as it seems to me that many others on this forum are too (I’ve already started all over again several times :D). I looked at the source code and many things are similar to the things that I implemented in my engine.
It seems to me that most likely you were oriented towards Unity (like me) or Godot.
I have a few questions:
How long did it take to develop?
Did you do this alone or is it a team effort?
How did you solve the problem with loading and unloading assets? Is it automatic? I want to create a resource management system like in Unity, when resources are released along with unloading the scene. Now I’m looking for a solution to this problem.

P.S. The demo didn’t start. I run the file but nothing happens.

Greetings! It took about a year to develop. But I work alone in my free time from my main job. Unfortunately, I don’t plan to implement automatic resource release. I prefer to use the Dispose() method.
I can’t figure out why my project isn’t starting yet. I think the problem is in the Net.Framework version. My project uses version 4.8 and the KNI library.

Share your project :slight_smile:

I will definitely make it public when I have something to show. I hope this happens before I get old :slight_smile:

If you’re interested, I found a solution for automatic resource management by creating classes:

  • AssetManager stores a cache of loaded unmanaged assets that are wrapped in WeekReference
  • GameAsset (and GameAsset<T>) encapsulates the loading of unmanaged resources such as textures.

The principle of operation is simple: there is RemoveUnusedAssets method which goes through all the elements in the cache, looks at the IsAlive property in WeekReference and if it is false then disposes the resource through Content.UnloadAsset(). This method is also called when Scene is deleted