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