Amethyst: Data-driven game engine written in Rust | Hacker News Reader

Amethyst: Data-driven game engine written in Rust

amethyst.rs

192 pointsingve35 comments

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

What projects currently use Amethyst? I can't find any information on the site about current users.

> What projects currently use Amethyst? I can't find any information on the site about current users.

You can find a thread containing links to current projects on our forums: https://community.amethyst.rs/c/showcase

Evoli in particular is, as the poster above suggested, a game we are developing to force ourselves to use our own engine and drive development priorities.

That being said, we are pre-1.0 and making a large, commercial project with Amethyst right now would be quite challenging. Our goal is to improve this significantly by the end of the year.

Do you have some specific doubts about the design or is this based purely on the lack of good looking examples?

Anyway they plan to back a few showcase games so they are headed in that direction, this is one of them:

https://github.com/khskarl/evoli

I'm not so deterred by the lack of examples but I do have doubts about the design and how complex it seems. Maybe that pays off with bigger projects, we shall see.

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!

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.

>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.

can you share which platforms burned you?

None of that invalidates the core issue that "trying to make a general purpose engine without a game is a BadIdea™" ("...if you want it to be used by other people" implied) is a pretty strong belief among experienced game developers.

OTOH there's Unity, who never developed a large game themselves, only demos and samples.

> OTOH there's Unity, who never developed a large game themselves, only demos and samples.

Possibly to the engine's detriment (though a cottage industry of add-ons in the assert store has helped bridge the most serious gaps)

And I think the engine is generally heading in the right direction now.

I 1000% support people hacking on things to learn.

But I don’t think Amethyst is a “just to learn” thing. They setup an actual foundation. There are sponsors. A lot of work has gone into a website and documentation. There is community outreach.

I really dislike the negativity of the internet. I don’t want to be a negative Nancy. I want Amethyst to succeed and be a useful tool in the Rust gaming ecosystem.

But right now I’m not seeing a path to that. I don’t think the engine makers need to switch focus to shipping an actual game. But I do think they need to clone a bunch of existing games with their engine to find the weak points.

Show me a page with Amethyst clones of Pong, PacMan, Super Mario, Doom, Warcraft 1, Quake 2, etc. Not complete games of course. But sufficient to convince me that a full clone could conceivably be made.

Our book includes a Pong tutorial. =)

Maybe it's just lack of good designers/artists, not a code quality issue.

We do suffer from a bit of a dearth of artists/modelers. We recently had one join who is doing a lot of nice work to the editor UI.

There's a few of us who have quite a bit of experience in the gaming industry and with game design, both from working at studios and game engine companies. We could definitely use more, if anyone is interested. =)

> Source: have shipped multiple games on multiple custom engines

Nice! Which games? We'd certainly welcome more feedback from experienced game devs and engine devs on what they want in a game engine.

Having been a developer of multiple custom engines (including but not limited to engines intended for external licensing in AAA game development), I can confirm that the problems that must be solved for small scale projects are dramatically different from the problems encountered at medium and large scale.

If Amethyst is intended to be a tool for single-developer, small game development, that's great. Carry on with what you are doing.

If you want it to be used for bigger projects, you won't know what you don't know until you actually try to make that big project.

(I assume that Forrest is posting here because he sees potential in your technology, and wants to encourage you to reach that potential. The internet is littered with the remains of game engines with big potential that didn't survive because they didn't take this lesson into account.)

Yup, this is true. There are a few of us on the team who work/have worked on some very well known engines (and their ecosystems) meant for AAA game development. =)

The more challenging thing at the moment is developing or improving fundamental libraries/tools in Rust, which is a fairly young language. Being able to leverage existing C/C++ libraries helps, but in general isn't what we prefer to do.

>I assume that Forrest is posting here because he sees potential in your technology, and wants to encourage you to reach that potential.

Any and all feedback is welcome, as are contributions.

Life is all about trade-offs. There’s no such thing as average. (https://www.thestar.com/news/insight/2016/01/16/when-us-air-...) If you try to build an engine for the general use case then you’re likely to make an engine that isn’t good enough for anyone.

My fear with Amethyst is that in 5 years it still won’t be good enough to make a commercial game of any genre. That’s the trajectory I see.

But I don’t think it has to be that way! And I think dogfooding would go a long ways towards building an engine that is both useable and extendable.

A more definitive statement regarding projects using Amethyst:

We have several so-called showcase games lined up. The only official one at the moment is Evoli: https://github.com/amethyst/evoli

It will have its first stable v0.1.0 MVP release in a matter of days. It’s designed to be easy to contribute to at scale so it’s a very suitable starter project for anyone looking to tinker with Amethyst in its current state.

As mentioned, the engine itself is still considered pre-release, but games like Evoli and more to come will demonstrate where Amethyst already shines, e.g. games that can take especially good advantage of the engine’s very close marriage to the specs ECS.

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

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

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

We are a 501(c)(3) non-profit. Many companies like DO and Sentry have programs for open-source and/or non-profit companies where they provide free or discounted services in exchange for some exposure.

So it is no active support but rather 'Amethyst uses resources freely provided by XYZ'? Support implies endorsement to me.

I'm not sure what you mean, I'm afraid. They actively support us by discussing our needs and figuring out how they can best support us. They've each specifically asked to have their names and logos associated with our project.

Perhaps if you can reframe your question I can better answer?

I think they were asking: Are they sponsoring you via "hard cash" or "merely" via services provided (e.g. DO probably via server resources)?

No, I wondered about the passive taking and calling if support or actual involvement of humans who decided to support the project.

Thanks, the answer my confusion. Very cool!

I saw other projects say they were 'supported' by some things when in reality they simple used free stuff.

Sure, no problem. To be fair, we take all the free stuff we can get, as we are almost entirely community funded and volunteer driven.

In terms of straight cash support, Mozilla recently gave us a grant to work on WASM-related things.

I think they should be using the phrase "data-oriented" as in: http://www.dataorienteddesign.com/dodmain/

But maybe they have reasons for using data driven. Its heavily based around entity component systems.

Was just about to comment that. They should fix the text to data oriented, not data driven.

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).

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

More information on what we mean by that term can be found here: https://book.amethyst.rs/stable/glossary.html

If viewed as goals, we aren't quite there yet, but we're working on it. =)

Generally the mentioned tools, particularly an editor of some sort in the style of the Unity or Unreal editors, are an important component of a data driven game engine. I didn't see anything skimming over the site about an editor. Is that part of the plan?

Yup. You can find the current editor work here: https://github.com/amethyst/atelier-editor

It is in very early stages. We are developing it as a WASM app that runs in a system webview, or can be accessed via a regular web browser for a more cloud-y experience. I'll take this opportunity to promote the awesome Yew project (https://github.com/DenisKolodin/yew) which is what we use for the frontend.

Reply on news.ycombinator.com