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

Unlikely, blueprints are compiled into bytecode which runs on a VM I believe, and current performance is around 10x slower than C++ (depending on programmer skill of course). They might be able to bring it down a bit over time, but it will always be a lot slower.

I agree with your point about Xenko though. They need a hook, a differentiator that will set them apart from Unity, as although they will be able to close the gap on Unity to some extent, they will struggle to surpass them for a good few years without a compelling reason.

Having the engine source available is a good start, as being able to modify the core engine would be attractive to some devs.

Kryptos, you mention that the engine source is GPL but the binaries are not. Does this mean that if someone wants to create a game that involves modifying the source to create custom binaries, they will have to release their source under GPL as well? Might cause some issues for those who want to integrate proprietary IP with the source...

 

Under the definition / terms of GPL, then yes. It sounds to me like Xenko only really provides the source for debugging purposes. The licensing is prohibitive to custom modifications of the source unless you plan to release an open source game yourself.

 

Blueprints call functions written in C++.

I think it would be the best if you guys moved that elsewhere. To unreal forums, perhaps. Lots of blueprint enthusiasts there.

When people DO use GPL engine, content is usually released under another license. There were few Q3-based games developed that way few years ago (Id software released almost all their engines under GPL). That sorta works, because artistic content is not software, but data being used by that software and GPL does not automatically apply to program input/output.

The problem happens when source code comes into play. Their website mentions that scripting is done C#, which falls into linking category if it works in the same way as unity does, unless they did something something insane there, like writing their own C# interpreter for the sole purpose of running engine scripts through it. Then again, given obnoxious nature of GPL, that would probably fall under derived work too.

 

Yes they will have to release their source code in GPLv3 too. Note the same things might happen if you compile the source code yourself even with no modification. That's probably why our binary runtime versions are signed.

Note that all this licensing stuff only apply for our beta 1.x versions. When we move away from beta to 2.x and beyond (which will mean that our product as achieved some maturity), things might be different. For now everything is free (and royalty-free). That's probably why the license is not more permissive.

And as far as I understand (I'm not part of selling, just a software developer), you can also negotiate other terms. Quoting from the licensing page in our website:

 

Apart from last version of C# and .Net, efficient asynchronous scripting with async/await pattern, maybe ;-)

Feel free to open an issue of GitHub if you think an important part is missing form the engine or the editor (especially the editor in my case since that what I'm working on).

Technically Xenko is not out yet, but in open beta. I cannot predict the future, we will see.

 

@Kryptos, I am going to start my exploration of 3D game dev alternatives with Xenko.

I have a couple of quick questions about Xenko and am posting here because it may be useful to others as well.

1. Does it basically work like Unity in that everything is centered around a Scene Editor?
   Basically, I mean do I have to go into some kind of scene editor to do things or can I just bring up a text editor/code IDE and start programming and do everything that way?
   
   
2. Does it also have the gameobject model and the component-based design?

 

I've used it briefly, but answer to your questions is "yes". Even though it wasn't helpful for you (since you can't use it), maybe it will help someone else.

 

Ha ha! Actually I got it installed after all. I don't know why people make things so crazy. lol The installer kept saying it found no version of Direct X installed on my laptop. I have DX11 installed. Came that way. But I finally just unchecked that option entirely and it let me proceed with Finish despite it saying Not Found and Required and being unchecked. lol

So, now it is installing. I edited my post but I guess not before you read it. Anyway thanks!

EDIT:
And then upon first building & running the Space Escape example 3D project I got a dos window that opened with red error text. Alright on to Torque3D!

 

This is only an advantage while IL2CPP is incomplete. One of the advantages it brings is an upgraded C# and .NET.

http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-in-unity/

 

You may need to run DX9 installer. DX11 comes with only DX11, you need to run installer for DX9 to get complete DirectX. Blame M$ for this.

 

I may circle back right now I am working through the installation & setup of Torque3D. I tell you they certainly don't make this stuff quick n easy. Kind of reminds me of the good ole days. lol

 

Unity shares some of the blame for not including the redistributable copy of DirectX.

 

Maybe, but IL2CPP does have other limitations, forcing you into an AOT environment which actually does impose some limitations, especially in terms of reflection.

 

Well by tools i meaned not specially editor , but also all features and tools around :
- cinematic
- visual shader editor
- visual particles editor
- vertex painter
- terrain and grass tools + wind system + terrain and grass, trees shaders (transparency, wind)
- Editor visual animation tool like mecanim
- Character Animation timeline editor to manage events during animations and IK settings
- Ligthmap generator or import + editor second UV auto generation for scene static models
- Visual Physics editor
There could be more , but some of these hight level tools are what gives you power to speed up a game creation.

Until someone don't make a big game using the engine, i am not sure they will appear. You could say it is open source and you could make the tools , but lot of people like many using Unity just put the time making the game and using advanced tools instead of loosing months and years making tools.

The install asked so much packages and was so long and so big that i just gave up, they could looks at Unity 5.3 new install system.

 

Well being fair to Xenko, I have also thrown out Godot and Torque3D. The final one that shall not be named is installing now. Maybe it will actually install and launch fine. I don't know. All I know is I am not wasting my entire Christmas break just installing crap and trying to get things to run.

I am already feeling tempted to just ditch the 3D game engine idea completely and spend my Christmas break building a simple ray casting engine in 2D Wolfenstein & Doom style. At least then by the end of my break I could have a little area I could wander around in. But I will give this last one a try first.

 

One of the nice things about it is that the launcher will handle the process of acquiring and updating it. Only thing you need to do manually is install a copy of Visual Studio. It requires a minimum of 2013 but they added support for 2015 with 4.10.

 

If it's in general discussion, some drift is fine really. It's a pretty general place. Any drift in other parts of the forum are pretty much stomped on. Although like any social situation, I'd imagine it to be common sense rather than a hard rule in general. Like this topic should relate to xenko. If it means comparing xenko to other options that's fine. If it means comparing ue4 to unity, that's not fine, no.

You didn't need this spelled out you wily old troll, you.

 

Yeah, I won't post about my research efforts any more. I just figured since I wrote about my experience with Xenko (and Unity 5 last night) it was only fair to share my (unproductive) experiences with those other two as well. I'll only say the one that shall not be named actually worked without a hitch and seems way more approachable than I was expecting.

Anyway, I hope Xenko does well. Although I am also not even sure why we have a thread discussing Xenko here either.

 

Tis the gravity of the unity community. It's so large it pulls chunks off of other forums.

Your assertion is accurate.

Duplicate keys are already not possible, I was just wondering if maybe microsoft's new javascript engine would allow it. Like... two arrays sharing an index! Or something absurd like that.

 

Technically in JavaScript you actually can define an object with duplicate keys, but when the object is generated it just uses the last one declared, so it's like reassigning the value. i.e.:

Code (csharp):

1.  
2. var someObject = {
3.     name: "foo",
4.     age:  99,
5.     name: "bar"
6. };
7.  

In the above example, someObject.name will equal "bar". However, if you've specified "use strict" you'll get an error instead as it doesn't allow you to define the key twice, even though the key will only ever exist once on the object.

I get to have lots of fun with javascript in my day-to-day. Tens of thousands of lines of it I've written over the last year building a large scale application using AngularJS and WebAPI.

I don't know why they would... unless it's somehow part of the ECMA 6 standard... which it isn't. This is just the general nature of javascript. Take this example for instance:

Code (csharp):

1.  
2. var obj = {
3.    name: 'foo'
4. };
5.  

The exact same can be accomplished by doing:

Code (csharp):

1.  
2. var obj = {};
3. obj.name = 'foo';
4.  

And

Code (csharp):

1.  
2. var obj = {};
3. obj['name'] = 'foo';
4.  

All of those examples generate the same object with a .name property. That's why you can also do this:

Code (csharp):

1.  
2. var obj = {
3.    prop1: 20,
4.    prop2: 30,
5.    prop3: 40
6. };
7.  
8. for(var key in obj)
9. {
10.     Console.log(obj[key]);
11. }
12.  

Even more interesting example:

Code (csharp):

1.  
2. var obj = {
3.       doAction: function() { alert('hello');}
4. };
5.  
6. obj.doAction();
7.  
8. //Or
9.  
10. obj['doAction']();
11.  
12. //Or
13.  
14. obj['doAction'].call(this);
15.  
16. //Or
17.  
18. obj.doAction.call(this);
19.  
20. //Or
21.  
22. obj.doAction.apply(this, args);
23.  
24. //etc.... you get the picture
25.  
26.  

If duplicate keys were allowed on an object it would completely destroy all of this functionality, which would be bad for a lot of code out there. As an example, I wrote a fluent model validator for AngularJS that we use in our code. You create the validator from a model, validate fields, etc. So:

Code (csharp):

1.  
2. var validator = validationService.Create(model);
3.  
4. validator.ForField('person')
5.      .AddRule(validationService.Rules.NotNull('Person cannot be null'));
6.  
7. validator.ForField('person.age')
8.     .AddRule(validationService.Rules.Min(18, 'Person must be at least 18'));
9.  
10. validator.Validate();
11.  

As you can see above I pass a model which the validator holds a reference to. Then when I call ForField it adds a field validator for the specified field. That method takes a selector. The first example uses "person", and the second uses "person.age". The validator actually splits on the "." and traverses the object tree uses those selector keys to retrieve the model values. Again, this would not be possible if duplicate keys existed.

 

Hey there, if you're serious about working on the game engine, a great introduction into the topic is on this channel. Astronomically, he even "tests" it with a Doom style game. He's a great YouTuber if you can get past his err... odd voice.

 

I was talking about something very nice and much simpler than that. A simple raycasting engine as in the old Wolfenstein 3D and Doom... hang on a second let me have a look around for a demo... ah I found a great article with a fantastic example...

A First Person Engine In 265 Lines

The awesome web demo for it is here.

That's what I was thinking about doing. The beauty is I'd be working completely in 2D tech still and these days this kind of thing would be fast as heck allowing much higher resolutions to be used. That was my idea anyway. And the demo I just found seems to be proving that out.

Instead of looking like this:


Now it's no big deal to make them look like this:


Not that "looks" are top of my list (actually near bottom) but when it's relatively simple to do then sure might as well do it.

The main advantage is levels are built incredibly quick as just a 2D array. Can drop that baby right inside the code.

 

You all know you've just been NecroPwned, right?

 

Answering your questions:

1. Not everything is centered around the editor. You can actually do everything in code. And also build your game from Visual Studio without even starting the editor. But I do think that managing your assets will be much easier from the editor. Creating all of them by hand will require a lot of times.
2. It is component-based. Although it works a bit differently than Unity.

I haven't had this kind of issues. What is the configuration of your machine? And as someone answered you need to install the whole DirectX SDK, not only DX11.

 

Thanks for replying I appreciate that. I've went on to other things and back to Unity 4.6 for 3D now. Been a busy night and day. I don't like to dilly dally when I'm wanting to get something done. lol

 

If you want a simple mode-7 style base to work off, I've got something you could rework... (It's in C++ and SDL2 though, of which might be a bit over your head... )

 

Those engines never used raycasting.
There was a story when someone mentioned that idea (that Doom used raycasting) to Doom programmers, they laughed their a**es off.

It is polygonal rendering. It is not Quake1/Descent style where everything is 3d, but it is still polygons. The difference is that those kinds of renderers only can handle two cases: polygon parallel to floor, and polygon perpendicular to the floor. Also, there's no zbuffer and depth is probably handled by something akin to painter's algorithm. Oh, and map is 2d.

You'll still need to handle invisible surface removal though - if you want normal framerate, around 600 fps or so.

I probably have some C++ "framework" lying around that could be used for full-software rendering based on SDL. This kind of stuff is very easy to write.

 

That could be. I've never heard anyone say it wasn't raycasting before. The mags of the time used to cover it quite extensively explaining how it was done and including little diagrams of the raycasting and such.

And searching for wolfenstein 3d engine and ray casting both support the idea. As does this interview with John Carmack where he says that for Quake he set out to break the bonds of raycasting to make the first true 3D game.

At the end of the day I think it is safe to call it raycasting. It's definitely raycasting to me because all you are doing is sending out rays from the player/camera position in the direction facing until you hit an object. Based on the distance of the ray before it finds an object gives you the scale and the offset of the position the ray collided at gives you the slice of texture to display. It's always just displaying slices of textures. The process (minus the visual stuff) is very similar to the way I do my 2D game dev. When the player is falling I cast out a ray in the direction the player is moving and check for tiles. Of course that raycasting is just a fancy way of saying I am scanning through a 2d array that is my tile map layer containing the collision tile markers. Just a simple loop. Move a bit, check. Move a bit, check.

 

Yes, most of the id tech engines actually used polygon-based algorithms.

However, that "256 lines of 3D" (Heh, what a way to simplify! ) article GarBenjamin linked to appears to already have some sort of hidden surface removal. If it stepped through millions of walls, one could probably remove all but the nearest one anyway, since it's that simple. Of course, one thing that could prove challenging is drawing sprites with that algorithm. Even then though, one could potentially draw a square slice,t hen put a sprite on it.

And as for "easy to write..." That depends on how far you dare go.

 

And you know... that could be a potential basis for a raytracer...

 

Those engines do not have a good reason to shoot rays.

Why shoot rays when you can rotate the world? Or when you can just KNOW list of regions that are visible from the point in which you're located?

I was talking about 13h-style app with full software rendering which gives you a pixel buffer and you decide what to do with this. There's no "how far to go" in this scenario.

If you wanna write 3d dungeon crawler, yeah, there will be couple of places where you can go nuts and have some fun. The good idea is to have clear goal of what you're writing though.

 

Yes, in that context, that is true. Sometimes however, even if the concept itself seems simple, the code works against you any way it can. (Example: trying to position and scale sprites in pseudo-3D environments... )

 

I don't see what is supposed to be difficult there, no offense. Might depend on definition of "pseudo-3d", though.

 

Yep... that's what I thought too, until I tried to do it myself in C++/SDL2, and got the weirdest buggiest mess I'd ever seen. Basically, I was able to get the Mode7 scaling layer bit right, but trying to put sprites in the right positions was hell. (And still is... I could try raycasting for it though, that's what I haven't tried)

 

I've dealt with those kinds of things about 12 years ago and I don't remember significant issues there. Then again, I knew how to work out perspective projection on paper before learning about matrix transforms and one of the first programs I wrote was software 3d rasterizer that supported textures and tranpsarency in 256 color mode.

So I don't understand the problem.

If you still have difficulty with that, you could try asking for help on the forum.

 

True. I guess I could send you a PM on it if you're willing to help.

 

Please stay on the subject.
Open another thread to discuss old ray tracing or other techniques

 

Heh... I was thinking of closing it like that anyway.

 

I said that to my boss yesterday.

Me too, I work at a startup! Me and 2 other people are doing the entire site for a company I'll name when the project is done! It's not enough people, but we're almost done

Actually, part of the website uses angular. I wanted to use vue but since we're trying to support internet explorer there are issues using templates... vue wants you to use strings for your templating, lol. It cuts down on xhr, sure, but typing html in a string is a terrible experience.

I'm going to write my own pretty soon, actually. Since I don't really utilize the data binding or directives from either, all that I've found interesting is making partial pages and assembling different combinations of pages in a single page. So I'm making my own light weight angular that is only the templating bit which will have a config of files to xhr and load based on the windowhash change event. It's funny how simple that part actually is.

 

If all you care about is templating, have a look at handlebars or underscore, both good templating libraries for JavaScript. Why reinvent the wheel?

 

Because I'm a game designer by nature, reinventing the wheel is what I do!

It also isn't very hard with jquery. Just ajax for the files that aren't cached already and... that's it. I'm going to put a little spin on it for my own amusement.

specify an object not only for routing but for the content of the route. A little vue-like, but based on assembling your loaded templates.

Code (JavaScript):

1. templates = {
2.     'home_header' : {
3.         'source' : 'site/public/whatever.html'
4.     }
5. }
6.  
7. assembly = {
8.     'home' : ['home_header', 'home_body', 'home_footer']
9. }

I haven't done that part yet so pardon the terrible names. But the idea would be to define a page by a series partials or templates and define partials as a series of templates. I haven't thought of a good name for it, but it'll be fun to make for sure!

 

It's also worth noting that if you do end up wanting to use just a little bit of the databinding, which I would highly recommend as it becomes unit testable, handlebars or underscore can easily be combined with backbone or knockout which are lighter weight model binding for javascript without all the extra angular stuff.

 

I know the feeling! I reinvent the wheel in my spare time just for fun. I wrote 80% of an IRC application because I wanted to write it in WPF, for no good reason. I never used it and never finished it but was a fun project.

So this really is angular-like. If you combine AngularJS with UI-Router you get stateful routes with route inheritance hierarcies and URL parameters that populate a $stateParams object that you have available to your controllers. You also get a lot of great stuff for free. Here is an example of a defined route:

Code (csharp):

1.  
2. $stateProvider.state('product', {
3.      abstract: true,
4.      url: '/product',
5.      template: '<div ui-view></div>'
6. }).state('product.selectattributes', {
7.      url: '/selectattributes/{productId:[0-9]+}',
8.      templateUrl: '/ionui/ui/productmanagement/views/attributeconfiguration/attributecontainer.html'
9. });
10.  

This defines a base route for product, so <apppath>/product. It's just a base placeholder state with a template that says, here's where we're putting our stuff (hence the ui-view attribute). Then we add a route below it. Using "product.selectattributes" tells us that the selectattributes route is a child of product, so the url will actually be:
<apppath>/product/selectattributes/{productId:[0-9]+}

It allows us to specify {productId} as the route parameter, and the :[0-9]+ is just a regex expression that says in order to match, the parameter has to be an integer. Now when we setup our controller and inject $stateParams it will have a productId property so:

Code (csharp):

1.  
2. 'use strict';
3. (function(angular) {
4.    angular
5.        .module('Example')
6.        .controller('attributeController', AttributeController);
7.  
8.    AttributeController.$inject = ['$stateParams', '$log'];
9.  
10.     function AttributeController($stateParams, $log) {
11.         $.log($stateParams.productId);
12.     }
13. })(angular);
14.  

The "Example" app will already have been configured, and assuming the attributecontainer.html view specifies "attributeContoller" as it's ng-controller, when that route gets hit, $stateParams will be injected for you and will already have that productId property assigned.

The beauty of this is several things - You can actually have a single file with loads of templates if you want. You can even put those templates in with your other HTML... you don't actually have to load them as separate files which saves on your requests. Even when you do include them as separate files, Angular has a template cache. Once it loads and compiles your templates it caches those templates and won't make the request again for those HTML files unless you clear the cache so you also get that performance boost for free.

I should also mention that you can also inject $state and do fun stuff like this in your code:

Code (csharp):

1.  
2. $state.go('home');
3.  

In fact, you could do this after handling a button click:

Code (csharp):

1.  
2. $state.go('product.selectattributes', {productId: 4});
3.  

So it allows you to programmatically trigger and traverse your routes and even provide data to your routes by route name and your code doesn't have to be at all aware of the URLs. There is also a third parameter that lets you specify whether to inherit the parent $stateParams, whether to refresh the whole page, and whether or not to replace the URL in the URL bar which is handy when building wizard type stuff or configurations for sub-options that you don't want to change the URL for (i.e. you don't want them navigating their directly).

 

I'll keep that in mind. Vue is a lightweight angular - but we're trying to support internet explorer, so, you know...

I plan to have a feature to preload files. No particular reason, just an optional thing. Angular doesn't let go of the resources so why not

 

This thing keeps going waaaaaay off-topic. One would think @Tomnnn is in here a lot. Of course, I did a bit as well. @Tomnnn you really have a skill in it though.

 

@hippocoder said some drift was ok. And the topic was dying down a bit so we just ran with it.

 

Yeah can't be all humbug now can we.

This man is dangerous. Do not approach him on forums unless you'd like to go off topic, and perhaps never return!

 

I had help this time!

Yes. It became a discussion about html templating technologies. Somehow.

Hey! That guy stole my avatar!

(۶ૈ ۜ ᵒ̌▱๋ᵒ̌ )۶

--edit
Joking aside, I would find it hard to believe that the owner of this particular thread has any issue with my keeping the thread alive and drawing more and more eyes to it

 

XD
This whole post made me LOL!