
Amethyst: Data-driven game engine written in Rust - ingve
https://amethyst.rs/
======
forrestthewoods
Amethyst project very badly needs to eat their own dogfood and make some non-
trivial games.

I have serious doubts this project will be used for anything interesting. The
projects using it so far all look really really bad.

I think the project is doing a lot interesting things. But I think trying to
make a general purpose engine without a game is a BadIdea™.

Source: have shipped multiple games on multiple custom engines

~~~
pcwalton
I don't like the gatekeeping "make games, not engines" attitude. People want
to hack on projects that are interesting, and low-level game code is
interesting. This isn't a case in which where people can get hurt or lose
money if the project doesn't work, like Cryptocat or Mt. Gox or whatever. For
a project like Amethyst, the worst thing that can happen is that we discover
that certain techniques don't work well for games in Rust--which is itself a
valuable result!

~~~
reitzensteinm
It really rubs me the wrong way when I see comments like parent telling people
what they should do with their open source projects.

However, as a game developer, using an engine without some substantial
dogfooding (or orders of magnitude more use by third parties, ala Unity) is
simply a bad idea. I have done it multiple times and each time it's burnt me.

If you were trying to sell this as a commercial product, I'd be right there
with the parent comment. Since it's not, I'll just take my hit of dopamine
that I live in a world where cool stuff like this is being worked on, and add
it to the list of stuff I'd like to play with.

~~~
amethyst-engine
>However, as a game developer, using an engine without some substantial
dogfooding (or orders of magnitude more use by third parties, ala Unity) is
simply a bad idea. I have done it multiple times and each time it's burnt me.

Definitely don't bet your company/livelihood on an experimental tech. I will
say that as a general philosophy, we are far more concerned about correctness
and stability over rushing to get a product out to satisfy investors. Not
having to try to convince people to buy an unfinished product to satisfy
investors is one of the advantages of being a non-profit.

We'll get to the point of being production quality, will just take some time.

------
eridius
What does "data-driven" mean in this context?

And why are companies like DigitalOcean and Sentry sponsoring a game engine?

~~~
flohofwoe
In the context of game engines, "data-driven" usually means that its behaviour
(sometimes an entire game) can be built mostly by feeding it with data created
by artists, level- and game-designers as opposed to a mostly "programmer-
centric workflow".

A very simplified example is building surface materials with a "noodle graph"
(creating a "data processing graph" visually by connecting node outputs to
node inputs) instead of writing shader code. Of course building a noodle graph
is also just different type of programming ;)

The term "data-oriented-design" looks similar at first glance, but means
something entirely different (DOD is mostly about focusing on an efficient
data layout in memory to make better use of CPU caches).

~~~
dmos62
At first I thought that it's data-driven in the same sense that Lisp is. The
concept describing Lisp's phenomenon is called Homoiconicity [0], or "code as
data", but Homoiconicity means that "all code can be accessed and transformed
as data, _using the same representation_ ". Emphasis mine. A lisp program
could transform its own representation, because it's just a list of lists;
but, a "noodle graph" programming system doesn't necessarily have the ability
to parse its own structure; but I guess it could, all that is really needed is
for the program to be treated as data, as in something the program itself
could manipulate. I guess that's the meaning of data, something a program in
question could potentially manipulate; and that's the difference between
"data-driven" (or homoiconic) and code-as-code programming: the code-as-code
program can't manipulate its structure as a first-class citizen.

I started out saying that a data-driven program isn't necessarily homoiconic,
but I'm finishing with the realization that it is, they're synonyms. Also,
I'll add that data-driven doesn't contrast with programmer-centric workflow,
because it's still programming, that hasn't changed. The question is what
you're programming with.

[0]
[https://en.wikipedia.org/wiki/Homoiconicity](https://en.wikipedia.org/wiki/Homoiconicity)

