The Xenko game engine is now open source!

Seems fairly newsworthy to me: The Xenko game engine was just released as a free and open-source project.

The interesting thing about this, and also the Godot game engine, is that they are released under a permissive MIT license which, if I understand it correctly, would open up a lot of possibilities for the future of game engines in general.

Announcement here:
https://xenko.com/blog/xenko-opensource-mit/

 

Pretty sure this is just a dying move because nobody wanted to pay licensing for a subpar engine.

 

It's not just dying, as a proprietary project it is now dead and buried.

The significant part is the permissive MIT license which means, if I understand it correctly, that anyone can extend or improve it and then essentially have their own game engine to market or do with as they please, with most of the heavy lifting done for them. This is different than a copyleft or GPL license which is more restrictive.

 

What @Murgilod said.
I've tried participating in the community once and it was just a wasteland. I'm still subscribed to forum updates and they hardly get 2 new users or a new forum post each week.

 

Yes, but there was already a popular open source game engine on the market by the name of Godot.

https://en.wikipedia.org/wiki/Godot_(game_engine)

A quick comparison of the functionality, supported platforms, and community with the above game engine has left me with the impression it won't just stop at being a failure as a commercial game engine. Godot feels like the superior choice here.

 

Godot is MIT too

 

I know, I mentioned Godot and its MIT status in the original post.

An important difference between Godot and Xenko is that Xenko is built in C#.

 

Yet despite choosing a cross-platform language with a cross-platform framework... it both supports fewer development platforms (you can only develop on Windows) and supports fewer target platforms (Win, Linux, Android, iOS, and UWP).

 

Sounds like the project is dead. The claim that team members will continue supporting it smells of BS to put a positive spin on things. This would be on their own time, while they have either been moved to new projects or worse. Don't expect any new major features.

I would think the best that can be hoped for is another group decides to take it private again under a new name. The project probably has complexity similar to something like Blender, but Blender has a support community and funding apparatus in place. I don't think Xenko survives long term without funding, and I don't think its community is large enough to crowd fund.

 

Isn't the main xenko developer working at unity already?

 

It had been dying for a while. Up until recently they had been letting developers use Xenko Pro for free and from the looks of it that promotion had been going on for an entire year. If providing it for free for an entire year wasn't enough to bring in new customers then I don't think making it open source will do any better.

That said Garage Games continues to stay in business to some degree regardless of the fact that their engine is positively ancient and open source so they might be hoping to find an alternative way to make money. Services, support, and so on.

 

This. And it is a pretty common move at that. It's usually the sign of the end.

 

Maybe Silicon Studio wants to focus on Enlighten?

 

There's a few people on their forum who are cheering the news. I don't think they understand what this means.

 

I think we probably can all agree the Xenko project was dead before they decided to give away their engine. I would think that part is more or less obvious.

The thing I find intriguing about both Godot and now Xenko is the idea that someone could use these code bases to create other more specialized engines. For example instead of a developer building some sort of game maker toolkit to sell in an asset store they could instead build their toolkit on top of one of these engines and sell it as a complete stand alone engine directly to the customer. That would seem like a more marketable and potentially lucrative type of product because the customer base would not be limited just to people already using a particular engine.

Does anyone have any thoughts on that aspect of it?

(It's not something I have any interest in doing myself, I just think the possibilities of it for the future of how people build games are interesting.)

 

That sounds interesting in theory, but the problem I see is the long term maintenance of the engine itself. For example it is relatively recent that Unity had to pull their web player and replaced it with WebGL due to a change in the browser market. Unity is in the middle of adding support for 64 bit android builds now, because Google will soon not allow 32 bit only builds.

One can imagine these types of significant changes will continue for any multiplatform engine every couple years, and if you're developing a front end toolkit are you also going to have the development bandwidth to be doing major platform changes to the back end to keep the engine relevant? At some point there will be new graphics API's, or a new trend in gaming (such as if VR had been more successful), where the engine would also need significant work to keep up.

 

Instead their customer base is limited to people not using an engine at all, and not currently writing their own engine. That seems to be a vanishingly small market.

The might be the opportunity to rebrand it as a tool for a specific corporate segment. Training simulators or something similar. But even there is weak, most corporates are slowly coming to realise that 'game engines' are actually legitimate pieces of software.

 

Creating a specialized engine isn't very realistic. If you're creating a specialized engine you don't want to start with a generic one and have to rework it. You'll start from scratch. Hello Games did this for No Man's Sky. Re-Logic did this for Terraria. Markkus Persson did this for Minecraft. None of these people started with an existing code base.

What's far more likely is that one of the game engines will largely cannibalize the other game engine and its community.

 

It's not cannibalism if they're different species.

 

cannibalize
verb

1. use (a machine) as a source of spare parts for another, similar machine.
   "cannibalizing two broken-down cars might provide spare parts to make one working car"

We aren't actually going to eat people that used to develop with Xenko. Although I am kind of hungry...

 

I was referring to this part:

So yes, keep yourself hungry for the feast later this week. We will heartily consume all 5 of their active users.

 

People are machines too!

 

Part machine, part human rights. Awareness and understanding of concepts is optional.

 

I'm not sure I agree with everyone's grim assessments. There is already at least one ongoing toolkit project like what I described built on Godot called RPG In A Box:

https://www.rpginabox.com

So it is clearly a doable thing. I'm pretty confident there will be more projects like this as time goes by, probably including some big success stories. Thanks for the opinions though.

 

Doable != practical

 

We have past examples to work off of. A number of years ago the two major open source frameworks available were Crystal Space and OGRE. Crystal Space went the way of the dinosaurs and hasn't had a release in six years. OGRE continues to be developed to this day.

Just being open source isn't enough. You need to have enough of a community to properly support the development of it and there aren't enough open source developers (both engine and end user) to support multiple competing solutions.

https://en.wikipedia.org/wiki/Crystal_Space
https://en.wikipedia.org/wiki/OGRE

 

If Xenko is less bug ridden than Godot then I could see it possibly finding a place in slot machine industry. A lot of companies cannot afford unity's gambling license (which i am told is very high because a major unity shareholder is in the gambling space and want's to lock competitors out) so they switched to godot or roll their own.

I have not used Xenko but it looks a lot closer to unity with c# and prefabs and those companies need something new employess with unity experience can get up to speed on easier.

 

Saying its dying and subpar makes it seem like you've never even touched the engine. Firstly the engines Patreon page seems to gain 45 dollars every 3 days at time of writing. Secondly the engine is more stable, flexible and is light year's ahead in C# Support. Unity still doesn't have Async. The lack of tutorials is the only downside, although there are people like me who will make tutorials on the engine once we are done with are projects. Their discord is very active and there are lots of people willing to help you. I've decided to switch to the engine myself. In my opinion the engine is better than Unity. Another weak point is the learning curve which isn't that big if you've used a different C# engine before. It helps keep those zero effort game developers away from the engine. They usually use Unity due to the low learning curve causing it to have a image problem. So its not a move to save a dying engine but to help game devs that put effort into their games have a better experience. (I'm in no way affiliated with Xenko)

 

No you can get it to work on Linux. I have done that Before. However I'm not sure about Mac.

 

It's being Crowd Funded gaining about 45 dollars every 3 days at time of writing. Currently at 640 dollars If I remember correctly.

 

No he is still working On Xenko as part of the community.

 

Official support for the Xenko editor on Linux wasn't implemented at the time of that post and from the looks of it that appears to continue to be the case. Keep in mind I'm not saying you can't run it in Wine, but Wine is at best a subpar solution that is very hit and miss.

https://github.com/xenko3d/xenko/issues/8

Godot is currently receiving $8,876 per month ($286 per day). If we're going solely off of monetary contributions then it's very clear that it's stomping Xenko which is only receiving $640 per month ($20 per day). I don't know where you got your numbers from but they're not coming up for me on any of my searches.

https://www.patreon.com/godotengine
https://www.patreon.com/xenko

If you're referring to the C# 5.0 feature, we've had that since Unity 2017.

http://www.stevevermeulen.com/index.php/2017/09/using-async-await-in-unity3d-2017/

That said I'm willing to bet it's nowhere near as useful as Unity's ECS framework.

Spoiler: Unity ECS

An opinion that seems to have been based on Unity 5. We are now years beyond that release and the game engine is far superior to what it was in the past. I highly recommend you properly learn Unity before you try to make comparisons.

 

@Mikolaj2004 are you being paid to revive this thread?

This is the point that you chose to play up? You do realize that's less than a minimum wage in a developing country...
There is a janitor in Greece who's getting paid more than that.

 

People tend to forget that it is completely open source.
You can dive in and build / alter whatever you want, and you're not bound to the stupid restrictions. (Hello full internal UnityEditor, and extending the default editors nightmare)

Which is a win for sure.

Also seems decent C# alternative for those who doesn't want to pay anything / buy Pro / pay subscription for Unreal.
No ToS, no EULA, no corporate BS.

Godot is python driven. And that's a no go for a people like myself.

Also,
ECS (pure) as stated, is light years from being user-friendly. Yeah, it's fast. (pure)
And it's near useless for indie, unless you'd want to built every native component on your own.

 

There is an unofficial third party module that allows you to use Python with Godot, but the official languages are GDScript (a variant of Python in the same sense that UnityScript was a variant of JavaScript) and C#. It's the exact same release of C# that is used by Xenko too.

https://godotengine.org/features
http://docs.godotengine.org/en/3.0/getting_started/scripting/c_sharp/

 

It's why he is working on it part time.

 

I based it from the patron checking it every 3 days and writing down its growth. I'm independent from Xenko, Silicon Studios or Unity. I still haven't gotten around to uninstalling unity 2018.3 beta which is the version I based it on. Unity Async https://forum.unity.com/threads/will-unity-ever-make-a-move-to-async-await-task.557908/ I compiled the engine myself and got it running on linux. I'm using Windows now. Have you seen this post on the github road map? https://github.com/xenko3d/xenko/issues/17

 

Xenko uses DotNet while Godot uses Mono. Unity also uses DotNet but an older version. Xenko supports the latest C# version. Even if Godot supports it, the support that C# gets is very limited and needs to mature since its still very buggy.

 

I've used unity since Unity 4. Can't remember which version. I've switched from Unity 5.3 beta.

 

Xenko uses .NET for the editor, but the actual game engine is Mono. I'll give you that they're working towards using .NET Standard for the game engine but that's in beta and hasn't been released yet.

https://github.com/xenko3d/xenko/search?q=using+Mono

Unity uses multiple solutions depending on the build target. We have access to C# 7.3 as of Unity 2018.3.

https://blogs.unity3d.com/2018/12/13/introducing-unity-2018-3/

Only within the editor. Currently it's restricted to C# 7.x since it's dependent on Mono.

It's exactly as I thought. You're completely out of touch with the current state of Unity. Which leads me to suspect you're completely out of touch with the current state of Godot too. Come back once you're no longer ignorant of the competition and then I'll consider taking your comparisons seriously. Until then they're only a source of entertainment at best.

 

The beta is going to end soon. There is a developer meeting being hosted on discord to see what they will be doing with version 3.2+

 

Again. Why would you play this up?
"We have 1 guy working on the engine part time,"
That's not something to write home about.

 

Haven't focused so much on Unity on Desktop, but building for Android I get a choice of Mono and il2cpp I believe. I think Unity uses Mono (and that's fine)

 

I'm only saying that there is always 1 guy working on it part time. There are more developers contributing to the project but they are not getting paid.

 

https://stackoverflow.com/questions...no-and-net-still-confuse-me-who-is-who-who-do

 

Godot currently has two full-time employees and they're working their way towards a third.

Okay, but this isn't unique to Xenko. It's a common fact of open source projects that there are people contributing that aren't being paid. Check the Github repositories for the two projects.

https://github.com/godotengine/godot - 18,673 commits, 5 branches, 21 releases, 785 contributors
https://github.com/xenko3d/xenko - 462 commits, 4 branches, 6 releases, 21 contributors

Godot has more than thirty-seven times the number of people contributing to the project and they've made more than forty times the number of commits. That's more commits per person than the Xenko project but then Godot has those full-time employees so it's completely expected.

 

That was written less than a year ago and references UnityScript. I'd say the lines on whether Mono is .Net got blurrier when Microsoft bought Xamarin and got ownership of the project and started caring about .Net on Linux and ther non-Windows platforms (EDIT: sorry it seems Microsoft/Xamarin officially gifted ownership to the .NET Foundation)

 

Plus Unity has been experimenting with compilers in an attempt to increase performance beyond what you can achieve with the normal .NET/Mono compilers. Just having a newer framework is definitely nice, but unlike Godot and Xenko we will have compilers that are optimized for game development and will push performance in ways they won't be able to.

I love open source but two full-time developers and a few hundred occasional contributors are simply no match compared to the performance of several hundred full-time developers and hundreds to thousands of beta testers (on a side note I would love to know if there are any public stats for the actual number of beta testers).

 

$640 covers about 2-3 days of dev work. Enough to address a few easy bugs, but no feature development. Still sounds dead.

 

It depends where that person lives.

For me that's two month of dev work.