New Xenko Game Engine - Uses C# and Free Open Source

Competition to light the fires are always nice. Though things like Bullet physics engine(not bad but not great), lack of VR integration among other things will stop it from being a huge threat.

 

True, there are certain features that are lacking from this Paradox engine. From what I've seen, a big draw for Paradox development is going to be from people wanting to use the rendering engine integration that they're building into it. This is a little less useful for games, just because of the requirements for assets to take advantage of it. But if they could get it working with VR, visualization simulations would probably be able to make excellent use of some of the rendering tricks they're implementing.

 

Would it be any better than unreal tour in paris?

Also, I have my laptop back, yay! It seems paradox has no unix editors / platform targets. I'll probably stick with Unity so I don't leave my friends with macs behind. Though I will create crappy UIs for them because of the 16:10 displays.

 

It's supposed to be released this month, well that's what they said anyway. The biggest pro's I can see from my side is a superior renderer, great post supplied by silicon studios and open source.

Now I'm usually not an advocate for open source as I believe it's better to pay for a product and you solely work on your game, but after trying everything out under the sun. I'm starting to believe it would be easier if you could add in your own core features, I'd wrap Nvidia's Apex and a couple of gameworks features into it. Also easy access to bug fixes, personally I've used OpenTk and SharpDX intensively so I know the score with it.

Probably a lot more custom bit's and pieces I could do, offline modding is not a problem.

Biggest con is obviously it's far from finished and well behind UE4 and Unity, so it really depends on how much work it's going to be.

@RichardKain

The rendering features wouldn't be worth it for mobile, but for PC games it shouldn't be an issue as UE4 is already doing it.

 

I have to admit, this engine is starting to impress. It's definitely the best looking engine I've seen in terms of GRFX!..

It's still lacking bits n' pieces, but for the most part looks great.!

 

definitely taken shape nicely i seen your post on the forums and regarding the things you mentioned that they dont have, when they come into play id happily play with it

 

This forum thread is a bit old. By digging it up, I hope that I will not unleash the wrath of the Unity Gods

Anyway I just wanted to point out for those interested that Paradox 3D has been renamed to Xenko, and that a new version (1.5.0-beta) has just been released.

Disclaimer: although I have been using Unity for almost 5 years, I recently joined the Xenko team in Silicon Studio (Japan). I apologize in advance for my lack of hindsight regarding Xenko.

 

Shaping up nicely. I hope it will be ported to Linux, etc. soon. Also, if possible, talk to Nintendo about supporting Xenko on Nintendo platforms as well.

Anyway, after finishing my current project I'll evaluate Xenko for future projects and if I'll like what I see, I'll switch over.

In any case, since you're Xenko dev, I have licensing question and a feature request.

Licensing question: For the modified version of Xenko, do I have to distribute my game's code (C# scripts) or only engine code? If only the latter, that's fine for me, if both then you should change it to encourage modification of engine (most people would gladly change engine code and then distribute engine sources if they won't have to distribute game's code as well, even in commercial projects.

Feature request: I'd like CSG/ProBuilder-style level editing tools to be added and node-based material editor for those who can't write shaders. That's literally only UE feature I miss in Unity and while I can use asset store for both, built-in thing like this would be IMO better.

 

As far as I understand, the current license (GPL v3) doesn't allow you to do that (you will have to distribute all your code). But if you believe that your modifications are worth for everyone, you can create a pull-request on our GitHub project and it might get integrated (after review) in a future release. I understand that this is quite restrictive for now and it might change at some point (probably not before the project moves from the beta). I'm not exactly an expert on this, so you might find more detailed explanation on Xenko's forum or answers websites (there are already topics about this issue).

Since this forum is on a Unity website, I would rather not pollute it and stick to posting news about the engine. I you have some requests, please go to Xenko's forum and answers websites. You can also open issues in the GitHub project.

 

Still lacking some basics at the moment like Navmesh / Terrain / AI right? I tried it out a couple of months back, very interesting if not a little buggy. Not much in the way of support either, from the community (as it's small for the moment) or from Silicon themselves.

It's promising, very cool stuff and I did enjoy messing about. But as an engine to use full time for studio's / indie's, it's way too far behind UE4 / Unity.

 

eh.

 

That's really bad choice of license for game engine.
GPL is viral, so you'll have to provide code for everything you use, plus you'll be locked out from using any 3rd party library that is not compatible with GPL. (pretty much anything proprietary)

 

That is not entirely true.
You only need to distribute your code if you make modification to the engine or compile it yourself. Xenko also provides binaries that are not under this license.
Anyway even if you do make some changes, you can still use any other library (even proprietary but with some restrictions: see http://www.gnu.org/licenses/gpl-faq.en.html#FSWithNFLibs). And as you can see in the license page on GitHub, another bunch of other libraries are also used.
Unity is proprietary and doesn't prevent you from making games, so I'm sure to really get your point.

 

The API sucks. Even though Unity's has issues, this is far worse.

 

Thank you for you kind word and the appreciation of our work. You are certainly an expert in our field and we hope to hear from you again.

 

Err, years of experience with GPL, being ex-Linux fan, and repeatedly contacting FSF with licensing questions in the past?

By the way, your link says "no, unless it is a system library".
http://www.gnu.org/licenses/gpl-faq.en.html#GPLIncompatibleLibs

Combining your GPL project with proprietary code, makes it a derivative, said derivative MUST be licensed with GPL, except you have no permission to do so with proprietary code you used.

Seriously...

Unity is also not a GPL-licensed product. If it were, it would be a product to avoid, because you'd have to release every script you write.

GPL is viral, and you have to release your code along the product, plus provide a place where any user of the product can download that code for the next 5 years. GPL kinda works on server software, because in that case you don't distribute it. The license is only used when people want to make a political statement and support FSF.

Either way, if your goal is to make people benefit from your software, consider better licenses: BSD, Mit, or LGPL (assuming the engine can be turned into library). LGPL would give the engine decent exposure and it will be possible to use it as commercial software. If your goal is to support Stallman's political ideas through making game engines, well, good luck with that.

If you are not sure what you're doing with licenses, then I highly recommend to contact licensing@fsf.org for further info. They don't give legal advice, but should provide decent assistance with your licensing query.

 

It comes down to "technicalities" and too much interpretation, if I modify shaders (which is used for all sorts of things from renderers to mesh components) I am effectively changing the engine. Tools will impact engine state as well, in essence an engine is a suite of tools.

You say that you can have different licenses on binaries, but what's the incentive when Unity is far more "complete"? If C# isn't that important to you, then UE4 is light years ahead in pretty much every scenario plus it doesn't require open state re-distribution.

I have to agree with @neginfinity, it ain't making a whole load of sense.

 

Lol, yeah I know that was outta nowhere and I don't have YEEEEAAAAAARRRRSSS in the industry. But from a getting used to standpoint, ow. It made my inner explorer rear his head in excitement, but the programmer inside had a bit of a heart attack.

Also, the API website doesn't display properly so it compounds the issues.

Overall:
- It looks pretty
- It will take some getting used to
- I need to take a weekend off like I did to learn unity
- I need a cup of coffee EDIT: Done
- I need to fix my browser for the API website
- Its development will be interesting

Btw, has anyone looked at stingray in a while?

 

I have to agree with everyone else on the GPL. I found a bug in OSVR for Unity that was taking me down from 80fps to 55. I fixed it and then told them how to fix it. There are other bugs and feature improvements that I want to make and will contribute back to the project (as soon as I figure out the Git ramifications of using a different version of Unity than the master does. Keeping a version of Unity for every project I may decide to contribute to could get burdensome. As could making the changes and Unity and recreating them in my repository) None of those fixes and improvements would come to pass if I was then unable to use my game commercially. Now, the same could be said of Unity. But I think as a closed source solution, their situation is different. An open source license designed around a product typically used as a tool for making money should create an incentive to use the code and improve the product. The GPL creates an incentive to avoid the code.

 

As a copyright owner you can put your work under multiple licenses. Licensing their source under the GPL does not mean they cannot compile a binary and license that under any other license they want. Mysql does the same thing. Lots of open source projects let you choose between licenses.

Now I also feel that GPL is bad for game engines. I also think it's less then honest to license something as GPL when you know that for 99% of all use cases, it's unusable. Companies that do this want to get the advantages of being known as open source without actually giving anything, because they know almost no one will be able to actually use their open source version. What benefit is there from a project being open source if I can't actually modify it and use it in my game?

UE4 does it right. They don't pretend to be open source, but they give you full access to it. That's a more honest approach.

Sorry for the rant, but as a major open source contributor I really have an issue with projects that do this.

 

Yeah, I know. That's how dual licensing works in project like Qt, CGAL, etc. The thing is, end user won't be the "copyright owner" and they'll be stuck with GPL.

GPL works well on content producing tools, not on code people are supposed to link with.
GIMP, Blender - those are GPL, and there's no issue with this... as long as content producing tool doesn't do makhuman kind of stunt.

Spoiler

Makehuman team decided to license original topology under GPL, with exception that "content produced exported from distribution can be used for any purpose"... the trouble is, they removed mhx/mhx2 export (you could generate facial blendshapes there, for example) from original distro, and now if you want to use their content for commercial purposes, you'll be stuck with dae/fbx, because mhx2 export now falls under GPL. Sometimes I just don't understand what the hell people are thinking when they make licensing decisions like that.

 

I'm cynical, but I think it's mostly intentional. They think they can get more media attention.

 

They can get more people buying daz, poser and working with fuse instead. Or maybe someone will get angry and create alternative topology and release it for free, no strings attached.

Either way, that's offtopic for this thread, so I'll shut up about makehuman.

 

I think you got it a bit wrong. So please let me clarify my opinion on this matter. Again IANAL and I can't speak for the company. Here are only my thoughts as a developer.

But just consider this: we provide binaries (for free) so you can do the same as with any proprietary software. The additional (huge advantage IMHO) as having the source opened is that you can actually step into our code while debugging (even when using the binary version). Can you do that with Unity?

Also we certainly are not an open-source company, neither do we pretend to be one. There is no ill-intend here. We just want to provide our users with the best experience, while protecting our product. In the future some parts may become MIT (or equivalent). We ourselves are using some libraries licensed that way.

Regarding the link I provided, I you read the rest of the GPL FAQ, you will see that you can have any proprietary library in a GPL software as long as their respective authors allow you to do so. It also mean that you can useone of your own library since you are the owner without releasing the source, as long as you distribute a working binary.

I hope that this will leverage some of your concerns. And again remember that there is binary signed version. So you don't have to worry if you want to make your games.

 

That's always a tough business if someone else can do it better. I think unreal is the only pleasant networking experience I've had.

 

I can do that with unreal engine. Also there are people that disassemble unity code routinely.

Look, you've chosen very wrong license for that.

The purpose of GPL is to exterminate every single possibility of somehow using that software in closed source product. It "prevents evil proprietary company from stealing free code", pretty much, that's its intent. GPL is very successful at that. There's no loopholes I'm aware of. For example, if you communicate with GPLed software via IPC or TCP-IP, that still apparently counts as making derivative if the GPLed portion of the product is inseparable from proprietary component(yes, I explicitly asked about this scenario fsf directly). GPLv3 has amazing restriction that if hardware that is supposed to run software checks for that software signature, then you need to private private key that is used for signing software packages.

What you say about your "intent" is nice, but, if you don't have explicit exception that allows linking with proprietary code in your license, you do NOT allow users to do that. That MUST be within the license. Another thing is that when people invoke "copyright owner can choose the license", then if project has more than one author, you'll need permission from all of them. That's another reason why this thing should be within the license.

For example, OGRE3D right now uses MIT license. Irrlicht is zlib license. Saurbraten is zlib license. LibSDL is zlib-licensed, allegro is "gift-ware", etc. See the pattern?

I've checked your website, the project is using unmodified GPLv3 without any exceptions added. It means your project DOES NOT allow users to use it with proprietary code.

In addition to reading GPL FAQ you need to read GPL itself.

No offense, but I'm getting impression that you guys are not very familiar with ramifications of opensource licenses. You should fix that asap, otherwise people will stay away from the project. It is a very serious thing.

----

A brief/rough overview of licenses:
GPL: Convert all your code to GPL or die. You shall not have the code if you did not convert!
LGPL: Submit modifications back to community.
MIT/BSD: Do whatever you want, just mention us.
Old MIT: DO NOT USE US FOR ADVERTISING YOUR PRODUCT!!!

For the best experience + protection, choose LGPL. That one can be dynamically linked with proprietary code.

 

Just use the binary version and you will be fine. Unreal only released their code recently. People have been using their binaries for years before that.

I don't get why people get scared when source code is released even with the restrictive license, while they don't have issues with proprietary closed source. Being able to SEE the code is a great advantage. And most users won't need to make any change in the engine to be able to make games with it.

That say, your concerns are well known in our team and company. I just arrived there recently (3 months ago). And the license was already chosen at that time.

Since I'm definitely not a lawyer and cannot make any decisions myself regarding licensing , I would rather discuss the engine itself if you don't mind (or more precisely the editor since it is the part I'm working on).

No hard feeling though, as I myself would also have prefered another license (LGPL, or MIT).

 

Again define "engine", it's a bunch of tools / shaders derived from DX / GL API.. You WILL need to modify them for any game of serious merit, as long as the Binary version allows you to do extend the editor / modify shaders / rendering API etc. then it may not be an issue for many..

After all Unity allows you to do it (to a certain extent) sure Unity does need to be more "open" because it does invoke restrictions we need access to. But that's something they are working on, metaphorically it's like an open "binary" which is pretty sweet.. But being allowed to fix issues and not relying on Unity removes a lot of headaches, I'm not sure what cost your support packages are.. If they are reasonable that might make the engine more enticing..

Otherwise, I'm impressed with how the engines coming along. Although the only thing that would even make me consider switching full time is the ease of use of Unity mixed with the power and toolsets of UE, that's a winning formula.

Or as @PenguinEmporium said, it'll end up the way of Stingray.. I've not heard ANYONE mention a thing about it, even though as a binary release engine it is pretty good, had some stuff even Unity was lacking. But ultimately isn't as good as either UE4 or Unity..

 

I did not know that modifying shaders also could be considered a derivative work. Also in our case I don't think they are part of the GPL package.

Anyway, we have in our engine a custom shading language which allows inheritance. So I don't think you need to actually modify the existing one but just derived from them (I must admit i don't know much about shaders, I'm just a tool guy).

 

If shaders are licensed under GPL, yes that one counts.
Inheriting from a GPL class also creates derivative which will be put under GPL too.
As I said, the license is very thorough.

Because breaching the license means legal trouble and GPL is very strict.
Also, any GPL-licensed product can be resold by anyone for any price or given away for free - GPL allows that, which means that using GPLed code for commercial purposes is very difficult. Any user also can hijack your product and may create their own derivative. The license is trouble for commercial use and even game dev.

With proprietary license you usually don't have to worry about that, and have strictly defined list of things you can and cannot do, and those things are compatible with commercial use. As a game dev, you'll usually want software that allows you to release your game as proprietary or closed source.

For example, Unity compiles C# code into into dll. Dll is then dynamically loaded. So, if we put under GPL, that will also make all scripts you write licensed under GPL as well, because GPL does not allow dynamic or static linking with proprietary code AND deriving from unity-provided classes also counts as linking with the code.

----

Either way, good luck with your engine, but do spend time and research opensoruce licenses properly next time.

 

That exactly what you can do with our engine.

I don't know how many time i will have to write this: the code has been released with a GPL license so that users can see the internal of the engine. But users that want to make release their game as proprietary or closed source CAN DO IT with our signed binaries. Think of it as two different products: the fact the the source code is available on GitHub doesn't impact at all the usage of the released binary version.

We ('they' because it was before I arrived) certainly did. It just that people don't get that having multi-licensed product actually give you the best of the two worlds. People that are scared by making their game GPL (i.e. releasing their code) or that just want to use the engine (like you do with Unity) can do so with the binary version and sell their game if they wish so. Open-source community-ies can benefit from our engine and integrate it in other open-source GPL products (note that they can also use the binaries from less-restrictive licenses such as MIT or Apache).
Both type of users can still see the internal by navigating through our GitHub repository or step into the code while debugging (great advantage).

So again, you are just worrying too much, for no reason (apart from misunderstanding the intent).

 

Dude, I'm not worrying about anything. I know this stuff, and the whole things is not MY problem, it is YOURS.

I have unreal engine with source code access, I have unity engine that can be used for quicker prototyping, and should I ever need write some lower level stuff I could grab irrlicht, sdl, allegro, build on top of Qt or just go nuts and bring back from the dead my own mini-framework or with sufficient time I can write new one from scratch. I have literally no reason to be concerned about anything licensing related right now, and I have zero reason to investigate your product/project.

The whole licensing thing is something YOU might want to be concerned about. That's the only reason why I brought that up is because you're apparently trying to gain users and at the same time you somehow managed to select the worst possible license for that kind of thing so I figured that for the so called "greater good" and "improvement of the industry" it might make sense to point at obvious licensing problems..

However, since the whole licensing chat is going in circles and

"people aren't using GPLed engine because they're stupid" (hint: they are not)., I'm just gonna wash my hands and walk away.

Whatever. One more engine, one less engine, it doesn't matter. You've been given info I believe was necessary, and what you're gonna do with it does not concern me.

Have a nice day.

 

Do you think coding something in unity is faster for prototyping than using a blueprint in unreal? What if someone is familiar with unreal's environment?

I haven't had enough time to get used to the unreal environment, but it's hard to imagine anything being easier to use than blueprint. I even wrote my own nodes for blueprint once! They were useless but I see how they could be used

 

I hope what you are meaning to say is that the binary versions are under a different license and not under the GPL. Otherwise all of the problems that others have mentioned still apply.

 

//offtopic. consider moving that into separate thread.

Spoiler

I am familiar with both environments.

For someone with programmer's mindset, blueprints lose in both speed and power compared to both C# in unity and C++ in unreal. Like all visual programming tools, they're incredibly inefficient when you're already thinking in code - making even the most trivial things takes longer, and even simplest problem that would take few lines of code tend to turn into large unweildy graph.

Of course, all visual-minded folks will squeal in delight when they get access to visual tools, becuase those things will give them SOME way to work with code-related sections. However, they won't be working efficiently. On other hand, they won't have the time to study programming properly to begin with.

So, it is pretty much a crutch for non-programmers. Not a superior technology for quick development.

The one area where you really want visual aid, though is AI behavior. You really need visual feedback here and because that thing can have multiple modes of operation and switch back and forth with them or even treat them in stack-like fashion, decision/behavior trees are very useful. However, decision/behavior trees in UE4 are not blueprints, and their nodes can be written in C++ as well.

On other hand, this kind design can be handled by coroutines (which may be implemented as green threads) - IF the environment can serialize/deserialize state of coroutine. Unity is unable to do that currently out of the box (state of coroutines is reset upon deserialization), and UE4 doesn't come with green thread library for C++, and using OS threads for AI is a really bad idea..

So Behavior Trees are the way to go for AI development.

There's huge difference between "easy" and "powerful". I want maximum power from my tools and tools that give you most power usually take time to learn them.

Easy to get started with tools, however, usually lock you into small subcategory of problems where they work well, should you move away from that area, you're screwed.

There's saying: "GUIs make simple things simple, and complex ones impossible", and there's a lot of truth in it. That idea applies to programming in general. If something is simple to start with, there's a hard limit to what you can do with it somewhere.

 

yea... now that you mention it, I did spend a lot of time making a lot of visual clutter to achieve something very very simple with blueprints.

That's an ongoing problem that doesn't get talked about enough.

 

Yeah don't thread drift please, tis selfish

 

Speaking of which someone might want to rename the thread. They changed the name of the engine to Xenko.

http://xenko.com/

 

That's nice

 

oh... oops. I'll try to be more polite in threads about other game engines.

 

The engine progress is too much slow, while Unity have active teams working all days.
For 3D games, lot of tools and features are missing , they have only have the basic lights and shaders no GI systems, no probes system, no reflections. Also there is no asset store system and no plugins.
The forums are very empty and not active .
It looks more like some hobby 3D engine project, i really don't know what they are aiming for ?
Perhaps some few people will success making a small 3D game , but i would not bet on it to make a commercial 3D game.

 

Was replying to someone above. I really should quote more.

 

Although to be fair Unity has been breaking quite a bit lately. Hopefully the problems will be solved just as quickly.

 

Here's the thing. I actually completely understand what you're saying and I think some folks have missed the point a bit. The source code is provided as a mechanism of debugging. It is there to make it possible to debug the engine along with your game. But I also think you're missing the point a bit of what makes GPL licensing bad.

It is good for you guys because you retain full control over that source and restrict what people can do with it. MIT licensing is great for open source products but not good if you intend to some day have some kind of monetization model as it is too easy for people to copy and see the same product. However, the problem is that GPL is too restrictive.

What good to me as a developer is debugging the engine code? The licensing is so restrictive that I couldn't do anything about it even if I found a problem, other than be able to point you to specific bugs. To be honest, you guys are the developers and QA so I'd rather not have to debug your product. The source would be great if I could make modifications to it without restriction, but that's not the case so I'd rather just submit a bug and let you worry about it.

If you intend to provide source you should look at other licenses, or come up with your own. Users would much rather you prevent them from redistributing the source. Or require them to submit engine modifications back to you, but allow them to recompile their changes and use their modifications (or at least bug fixes) in their projects without forcing them to open source their own projects. Does that make sense?

 

Blueprints aren't really meant to replace code altogether, they're more for high-level scripting for non-technical people and rapid prototyping. Most people still do the "heavy lifting" in C++ for practicalilty and performance reasons, and then expose custom blueprints for level and game designers to snap together and script the gameplay without having to go back to the programmers and waiting for them to implement changes.

Back on topic, I think that any new engine is great news. It is always healthy to have competition cropping up to keep you pushing to do better, and 90% of innovation is built off the groundwork laid by those that came before us. If the Unity team see something innovative in Xenko that they decide to put in further down the line then that can only be a good thing for us.

Don't be hostile or mocking towards a new engine, they all start off rough around the edges, but if it grows into a quality product it will either mean more choices for you, or a better Unity product.

 

It's nothing to with mocking a new engine, I think everyone will agree having more solid options is a benefit. Crux of the matter is Xenko and any other startup engines are in direct competition with Unity / UE4.

For them to succeed they need users, as the cost / investment into current class leaders are in most cases high. They need to not only do everything right, but rise above to give effective reasons why a user base should potentially forgo years of fiscal / time investment in other products.

It won't be easy to convince people to switch, I hope their product does rise above and becomes a viable alternative. But the market is fickle ("queue Stingray"), so it's vital to asses consumer input.

 

@GoesTo11 Yes the license for binary is different (not GPL) and allows you to sell your game for free without royalties, as far as 1.x version is concerned, which is our beta version. When we move to non-beta (i.e. 2.x and further) the licensing might change. More details here: http://xenko.com/features/licensing/ (I should have provided the link first, instead of going into lengthy discussions).

@neginfinity Got your point. Thank you for trying to help. I realize I might have reacted a bit too strong. My deepest apologies for that.

In any case, I'm happy to see that there is some interest in this engine. We are trying to bring new features as fast as possible.

 

Epic will improve and optimise Blueprints to generate code as fast as C++ done manually in some future version.

I really don't see anything new in Xenko, and it lacks so much editor, tools and features.
I seen innovative things in Crysis engine instead with their last features.
It is more than a year Xenko is out , but as you can see, the progress is too slow , while it will progress Unity will also be bringing more features, Xneko can't catch with Unity.

 

I used them just because of all the tutorials on their youtube channel that made use of them. It also allowed me to get away with not knowing the editor or environment at all. It fit into a "dabble" time space.

Oh. What's the appropriate amount of topic drift on a general topic about another engine? Can we talk about edge's new javascript engine? I just wanna know if there are any features that are stupid - like... a javascript object that allows duplicate keys!

 

"use strict";
Should always be using that anyway with JavaScript. It won't allow duplicate keys or use of undeclared variables.