Did you know that Xenko is basically MonoGame with a 3d editor?

Hi,

It appears that many people have never heard of the Xenko (soon to be Stride) game engine: https://stride3d.net

It was commercially developed by world-class engineers and got open sourced after it could not commercially compete with unity or unreal. For example Alexandre Mutel, the developer of SharpDX was part of the team.

It should be quite interesting for MonoGame developers, because the API is almost identical. But you also get a fully featured 3d level/asset editor and has very high quality shaders and materials. It should be quite easy to port existing MonoGame projects.

Xenko has an ECS and many more convenience features… Also, Xenko projects are just visual studio solutions.

Please don’t get me wrong, I’m not here to say that one is better than the other, I was just surprised that many .NET developers aren’t aware of that option.

Looking forward to hearing your thoughts…

I had a look at it, and while it looks good on the surface, I found a lot of issues with it.

I suppose it feels exactly like what it is, unfinished.

It does not build from source, there are several issues waiting to be fixed by somebody, even the build log on the website shows multiple targets do not build.

The editor is fine, if that is what you want. I want code that compiles and only want editors for things that are a pain to do in code.

It has a lot of nice rendering features I would love to look at. Sadly the way it has been written makes finding code that actually does something tedious.

This is an artifact of the fact they wanted to support multiple graphics API’s and target platforms so they had to abstract things a lot. I don’t think they have done a bad job of that, it’s just that I would have to spend a lot of time learning how the abstraction worked if I was going to use Xenko.

From what I can see, it looks like they have chosen to use some external libraries that have changed.
Asssimp is the prime suspect.

This ends up killing a lot of projects

I would be cautious using it, I don’t know if it is actively under development. If it is, I may be interested in helping as long as I get to add the things I need to make it useful :slight_smile:

However if you are attracted by the editor and all the tools, just get UE4 or unity. You know they are updated constantly.

Monogame is a totally different thing, you don’t get a Monogame scene editor because it is not a game engine.

102>CSC : error CS0006: Metadata file ‘C:\GitHub\xenko\sources\engine\Xenko.Assets.Models\bin\Debug\net472\Xenko.Assets.Models.dll’ could not be found
102>CSC : error CS0006: Metadata file ‘C:\GitHub\xenko\sources\editor\Xenko.Assets.Presentation\bin\Debug\net472\Xenko.Assets.Presentation.dll’ could not be found
102>CSC : error CS0006: Metadata file ‘C:\GitHub\xenko\sources\assets\Xenko.Core.Assets.CompilerApp\bin\Debug\net472\Xenko.Core.Assets.CompilerApp.exe’ could not be found
102>CSC : error CS0006: Metadata file ‘C:\GitHub\xenko\sources\editor\Xenko.Editor\bin\Debug\net472\Xenko.Editor.dll’ could not be found

2 Likes

IMHO, it’s not basically MonoGame with a 3D editor in terms of ease of coding ^_^y

Once you open Xenko project in Visual Studio mostly you can see are script of each object/entities, the game project is heavily ties within it’s Editor.

Unlike MonoGame by reading the code, you can already have an idea what’s going on, you can easily follow the game logic : )

What’s good about Xenko : is out of the box you can do PBR, nice shadow and GI with support for DirectX 12( using SharpDX) and Vulkan( using SharpVulkan).

What I don’t like about Xenko : Very slow project loading and building project, game hang from time to time.

But of course I wish both MonoGame and Xenko to move forward and progress ^_^y

1 Like

I’m working with Xenko for some months now and it doesn’t feel unfinished to me. In fact, I’m building the engine from source almost every day and I’ve also set up our TeamCity build server to do so. Our customers can even download the custom build of the engine via the official launcher, which is pretty awesome:

So it seems there was something wrong with your build environment. When did you last have look at it? There have been almost 200 pull requests merged since it went open source.

Yes, it takes a while to understand the code, but that is because their systems do abstractions where it’s needed for proper scalability. If it clicks, you would be amazed by the possibilities and how clean it is to extend the engine.

The repo is self-sustained, there is no external lib that would change without someone updating it in the repo. The error messages you posted only mean that you didn’t initialize your git repository with git LFS, since that is required to download the referenced binaries (as stated in the build instructions). You are probably using an old git version without LFS?

Development is very active, the lead developer from Silicon Studio is maintaining the open-source repo. If you want to see an easy example of how to extend the rendering pipeline including editor support, you can find that here: https://github.com/tebjan/Xenko.CustomRootRenderFeature

It would be great to see some more people working on it. I’m quite excited about it…

1 Like

This highly depends on how you want to work. Xenko’s core/low-level API is very similar to MonoGame but you have an engine and ECS scaffolding (like Unity) on top of it. Using the ECS has many advantages in terms of keeping things independent from each other and adding localized game logic to entities. If you want to learn this game development style, I would recommend watching Unity video tutorials or these Xenko tutorials: https://www.youtube.com/playlist?list=PLM8hj-JyVnYr-usNqX5aeXG0IwTY9FVge

But if you want to work like in MonoGame, by extending the Game class, you can do so:

public class MyGame : Game
{
    //override Initialize(), Update(), Draw() etc.
}

And then run it like that in the Main method:

static void Main(string[] args)
{
    using (var game = new MyGame())
    {
        game.Run();
    }
}
2 Likes

Nope, totally up to date.

And the errors look like API changes, functions that don’t match prototypes, rather than missing libraries

The messages you posted look like missing dlls that didn’t compile. As i said, if your build environment is set up according to the readme.md current master branch compiles fine… so something is missing on your machine. Did you install the FBX SDK? All VS workloads listed?

The message I posted was the end result of all other issues.

They are xenko dll’s that failed to build, and not just one of them either.

Yes FBX SDK is installed.

Looking at the project homepage, 4 of the builds are broken. So it isn’t just me

Ah, these banners at GitHub you mean? These never worked… Don’t know why. I think a few tests cannot be executed after Xenko got open sourced. They worked only internally at Silicon Studio.

From my daily experience, the builds are fine and even our build server runs them.

Regarding your error messages, do a search on the GitHub issues or create a new one. I’m sure it’s easy to fix.

Now I see what you meant when you said Xenko was like MonoGame.

3 Likes

This:

And this:

Are the flaws in your argument.

For the debate, use what works for you.

:pray: :tea:

:smiley:

Where do you see a flaw there, my private build and the build on our TeamCity server don’t have anything to do with the official builds of Xenko.

Just a quick follow up on this, I was directed to this post on reddit that explains it in more details with code examples:

All builds are green now, btw:


Now that games for smartphones such as iPhone and Android are rapidly gaining power, a game engine that cannot be developed on a Mac is worthless.
Unfortunately, Mac are inevitable when developing games for iOS.
The reason why Unity is overwhelmingly strong is that it is great for mobile environments.
It is the exact opposite of aiming for super high image quality with an ultra high performance machine.
Most mobile game developers want more agility than higher quality.

yes i agree, that’s why Stride has a highly customizable render pipeline. you can choose whether your project is for high or low end devices via the available graphics API:

  • OpenGLES 2/3
  • OpenGL
  • DirectX11
  • DirectX12
  • Vulkan

And also the feature level of the graphics API. Depending on the choices you made, the engine compiles different shaders for different builds.

yes, but with Xamarin that isn’t difficult. and they are advancing fast, so every step they make is in Stride fro free: https://docs.microsoft.com/en-us/xamarin/ios/get-started/installation/windows/?pivots=windows

with this you can pair a mac anywhere in the local network and develop on windows.

Ok! You have my attention.

I think you missed the point.