
Xenko Game Engine 2.0 released - bluesilver07
http://xenko.com/blog/release-xenko-2-0-0/
======
pjmlp
Congratulations on the work achieved, specially on adopting higher level
languages.

The growing adoption of C# among game engines, brings me back memories of when
game engines finally started to allow C++ on their source code.

~~~
pandaman
I have memories of people trying Java for the same purpose. I believe, the C#
will ultimately meet the same fate. Here is why (I believe that):

Switching from C/C++ to a GC language is nothing like switching from Assembler
to C/C++. We did not write Assembler because we liked it. We wrote it because
we targeted 8/16-bit archs, which did not fit C/C++ memory model quite well.
Because of this Assembler had huge speed and size advantage. As soon as flat
memory archs became viable almost everybody dropped Assembler without regret.
We lost a bit of performance (which could have been easily regained by
rewriting inner loops in Assembler) in exchange of reusable, portable code,
type system and terse program texts. These allowed to write much more complex
games by engaging bigger teams who could sensibly collaborate over a much
bigger project in C/C++.

What is the transition to GC from C++? You sacrifice a lot of performance for
freedom from managing memory. I don't know about other people but having
shipped few AAA games my only concern was fitting shit into available memory
(which GC does not help, to say the least). You allocate memory on load. If
you load multiple levels you nuke the previous level's memory. If you stream
you do the same but your "levels" are now "segments" in a pool. Of course, if
you want to go full-GC and allocate your structures byte by byte, uint32_t by
uint32_t - be my guest, not sure how you plan to compete but, hey, load times
(same as frame rate) are not that important as they say on the internet :)
Nevertheless, as soon as 32-bit targets become completely obsolete people will
find out that you can pre-allocate everything off-line in 64-bit so all you
will have to do at run-time is map/unmap pages (which GC won't help either).
In conclusion: one dropped performance on the floor (due to cache issues, SIMD
issues, off-line vs JIT quality issues etc) and picked up the solution to the
problem one should not have had in the first place.

~~~
nonsince
C# is, among GC languages, particularly bloated with regards to memory. There
is huge amounts of runtime type information (including stringified versions of
everything) and you have close to no control over memory management without
hooking into ugly APIs. I wish that Swift or Rust had been usable early enough
to get swept up in the hype train so that we could avoid this crap. Also, it
would mean I didn't have to use OOP to write games.

~~~
golergka
C# specifies the language, not the runtime. Apart from .NET and Mono, you can
compile C# to cpp (what Unity does under the hood, btw).

> Also, it would mean I didn't have to use OOP to write games.

There are many instances where other programming paradigms are more usable -
but in my experience, gameplay logic, specifically, maps very well onto
classic OOP concepts.

~~~
nonsince
If gameplay mapped well onto OOP then the big game companies would use it, and
not data-driven programming (specifically, entity-component systems). I think
that there are a couple things that require OOP-style dynamic dispatch, but
they don't need to be pervasive, even a function pointer stored as a struct
member is more than enough to provide all the benefits of OOP without having
to take on all the drawbacks.

------
zimbatm
How is this compared to Unity?

~~~
hesdeadjim
Frankly any comparison is going to be superficial unless the comparison is
done by a person who has actually shipped a non-trivial game on both engines.

So many of the problems you run into making a game on Unity, Unreal, etc come
down to the out-of-the-ordinary requirements of your game and the inevitable
peculiarities of the engine itself. Part of becoming an "expert" in building
games on a third party engine is knowing where the pain points lie, where you
should absolutely not fight The Way It's Done, and what bugs remain unfixed
for years on end (Unity asset bundle system, looking at you).

Edit: My point being that unless you know the needs of your particular game
and have familiarity with a candidate engine, it will be very difficult to
determine if your choice is "best" or not.

~~~
Pica_soO
Reminds me of all the "Lets make a battlezone like shooter"-gamedevs who
dropped by on the Spring-Engines dev site. And yes, you are perfectly capable
to do that. And no, it wont work well- for the reason, a RTS-Engin has a built
in lower physical Simulationframe update- and is allowed to act "slower" to
commands then a shooter. So, if you want that shooter to happen- engine
rewrite it is.

------
imaginenore
If I only had time to learn another game engine. But I'd rather spend it
making games with Unreal or Unity, and I doubt Xenko has something important
they don't.

------
je42
[https://github.com/SiliconStudio/xenko/graphs/contributors](https://github.com/SiliconStudio/xenko/graphs/contributors)

are they stopping with development?

~~~
swsieber
I think they are just closing the source as they make it commercial...

Edit: Oh, nevermind - on the home page they explicitly say that they're open
source.

~~~
adrianmalacoda
And by "open source" they mean a proprietary product[0] with "personal"
(stripped down and highly restrictive license) and "pro" versions[1],
naturally.

The old version (which is on github) is GPLv3 apparently.

[0] [http://xenko.com/legal/eula/](http://xenko.com/legal/eula/)

[1] [https://store-dev.xenko.com/get-xenko](https://store-dev.xenko.com/get-
xenko)

------
rwmj
Always tell me what the product is in the first sentence or two.

~~~
the_duke
Front page:

> Next-Level C# Game Engine

> Xenko is an open-source C# game engine designed for the future of gaming. It
> comes with a full toolchain and is especially well suited to create
> realistic games but allows you much more!

~~~
rwmj
But not on _this_ page, which happens to be the first page I've ever read on
this project.

The Economist is a good example here. In every article, every time a new name
or topic is introduced, it will provide a few words describing the
person/thing. An example taken from the first sentence of the first article I
opened: _" Much of the language used by Mike Pence, America’s vice-president,
[...]"_

~~~
derefr
Professional journalists write like this, because journalism is intended to be
consumed "statelessly"—i.e. with no assumption of previous knowledge.

Writers for "progress announcements" blogs like this one, don't tend to write
in this style, because these writers know that the only interest anyone would
have in a such a blog is if they already knew what the subject was and then
wanted to _subscribe_ for updates.

Which is to say, deep-linking to a progress-announcement blog from another
website is basically almost always entirely useless, and the webmasters of
such blogs would actually do well to disable it entirely (e.g. with a
robots.txt policy + a server-side hotlink-detection redirection rule) and just
suggest that people interested in sharing the announcement, should instead
write a few lines of "actual journalism" on their own blog about the release,
and then share _that_.

People who like linking directly to primary sources would hate this, but
sometimes primary sources are not in the easily-consumed essay or
encyclopedia-article styles that much of the modern web has become. Sometimes
a primary source is just a commit log, or a diary, where you need to "go back"
to get any context. The primary source gets to do what it likes; it's not
beholden to the Internet. If someone wants a good summary to share, _they 're_
beholden to write one.

------
bhewes
Cool to see Silicon Studio came out of SGI Japan.

------
Zekio
ohh you can use C# 7 features, gotta play around with it now

------
rel_ev
windows.. meh

