Hi there. I hope you don’t mind me posting on this thread – I came across it while researching Amethyst, and thought that you might be interested in hearing why I’m researching it. I have no particular opinion about what you should do with your project, but I do have opinions about what I’m looking for! And I know that this sort of input is helpful to me when making decisions about my own projects.
Brief background: I’ve been developing software both professionally and as a hobby for about two decades. Mostly these days I work on architecture and infrastructure for distributed server systems, but I’ve worked in other areas, and have dabbled in game programming off and on over the years. I’m interested in building games that simulate complex non-physical systems and scale up: “real” examples of this at various complexity levels would include Factorio, Europa Universalis, or Civilization. i.e, games that are sometimes caricatured as being “spreadsheets with graphics”. I already have a day job that I like, and I have no interest in going into business to support my programming habit, so if I ever release this, I expect it will be as free software/OSS.
I haven’t decided to use Amethyst yet, but I’m seriously evaluating it for my next project. My next step is to build a “hello world” game to try it out.
So, why am I evaluating Amethyst? The first reason is simple: I’m interested in finally learning Rust. I spent a lot of time writing C++ code in the past, and would like to try out the more modern and hopefully less aggravating alternative; I’d also prefer to use more performant components to be sure that the system can scale up. Using Rust narrows the field of libraries and tools considerably (although I was pleasantly surprised to see that there is a field these days).
Within that scope, the main thing that’s appealing to me about Amethyst is that it is built around a framework for organizing computation around data that isn’t tied to a particular set of assumptions about the “physics” of the game. Put another way: I’ve tried out Unity and Godot in the past, and found that while they work really well for games that involve objects moving around in space and interacting via collisions, if your game is meant to feel more discrete (operating according to non-physical rules), you end up having to disable the built-in goodies and build everything yourself anyway – and most of the docs are aimed at the “3d action” use case, which doesn’t help. The emphasis on object-oriented design also makes it difficult to build systems that combine data across multiple objects (like: I have a complex system of pipes, and every tick water flows through them based on how many inputs and outputs exist). And it’s hard to understand the performance implications of choices you make around, eg, organizing work into Godot’s Nodes. I can build algorithms; I know how to write this code, if the framework gets out of my way and lets me do it!
Amethyst’s architecture seems to be designed very well for this: I can have a Component for each discrete sub-system, and a System to drive its computation forward. If Components interact, I can create a System to join them together. If I want them to be represented on the screen, I can create a System that takes the game state and “pushes” it into Transforms; if the built in rendering isn’t well suited to what I’m doing, I can create a parallel System to handle rendering. If I don’t need collisions, I don’t create the Components that collisions use, and in fact I can disable the whole collision System if my game doesn’t need it.
(I also like the idea of States, but that’s further afield from my experience and I can’t comment on it without trying it out)
This is very similar to the type of design I’ve seen succeed when working on distributed systems with external storage, but adapted for the wildly different constraints of game development. I have a few lingering questions (how best to handle multi-stage processing; what do I do about forks and joins between individual entities in the data dependency graph). But I also like that in the worst case, if the ECS doesn’t work for some aspect of the game, for whatever reason, I can make a new Resource with everything organized just how I want it, stuff it into the World, and call it a day.
I also really appreciate that there’s clear and easy to find documentation on how Entities, Components and Systems are organized and what the basic performance tradeoffs around them are. Since I hope to build systems that will scale up, I’m a little nervous about easy-to-use frameworks where the architecture isn’t clearly explained; I worry that I’ll buy into something that I regret down the road.
Oh, and while I know it’s important for some of your users, 3D is just not something I care about. My game ideas don’t need it, and I don’t have a stable of engineers and artists hanging around to deal with all the complexity it adds. I can make my terrible 2D programmer art in Inkscape and blit it onto the drawing surface, thankyouverymuch.
I also don’t need a built in level editor; most of my worlds will be procedurally generated anyway, and the few that aren’t I can either find an external tool for (I’ve heard that Tiled is good for maps, for instance), or just bite the bullet and do them by hand. I think the thing I’ll miss the most is actually the visual editor for particle systems (being able to drag and tune the parameters in real time was super handy) … and my understanding is that Amethyst doesn’t have particle systems built in anyway.
The main alternative to Amethyst I have identified is ggez, and I’ll probably prototype both of them if I have time. My main concern there is that with ggez, I’ll probably end up reimplementing a lot of the infrastructure and architecture in Amethyst – poorly. Or I might end up using specs/legion directly, in which case why not use a system built around them in the first place?