That's like saying one should build a bike instead of a car because they are unsure about which color the headlights should be.

To me it's more like you need to move a piano, why are you trying to use a tricycle?

I don't care about memory stuff, because the language does not let me do something stupid.

That's an answer I can respect -- It's why I favor Ada and Pascal over C dialects when it's at all possible. Sadly due to the nature of certain tasks and/or targets and/or compiler availability/efficiency, it's not always possible -- or at least, not always the best choice.

I think given what you are talking about with this "ECS" thing is basically objects, the lack of proper objects (in particular inheritance and prototypes) is what you're butting heads with. The language may not be suited to the task. Doesn't mean you can't do it though.

If they don't use a custom engine, like Frostbite (EA) or Creation Engine (Bethesda), they mostly use Unreal UE, Crytek CryEngine, AutoDesk Stingray, etc.

Which are written in? :p

When working with a language this new with libraries/apis that barely seem out of beta -- which this Amethyst seems to be -- I would think you'd be working at the engine creation level, not at the "I'll just grab an off the shelf engine and go" level. I was just looking at it from that point of view. The point of view of "this language is new, so you use SDL with OpenGL / Vulkan, or you use directX, or OpenAL"

However, I see this kind of problem as a more generic thing

From what you've said about your problem, it SOUNDS very much like a language specific problem that could be solved almost instantly by actually having objects and inheritance. Hence my suggestion of switching to a language that has those things. With a lack of objects easy mass manipulation of game type data would be a painful process at best -- you'd end up writing your own hardcoded workaround to behave LIKE there were objects.

Much akin to the handful of cases I had to abuse "record" back in the '80's to port object Pascal code on some projects to UCSD Pascal for platforms that lacked object Pascal compilers/interpreters. It could be done, but it sucked.

Which is probably what you'll end up having to do, abuse "struct" to fake objects/object like behaviors passing by reference. Something like:

struct EnvObject { // an object in the world that can move
    x : i32,
    y : i32,
    move_x : i32,
    move_y : i32,
    model : u32 // offset into model or sprite buffer
}

fn EnvObject_update(envObject : &EnvObject) {
    envObject.x += envObject.moveX
    envObject.y += envObject.moveY
}

So long as all your "pretend inheritance" structs match the order of previous ones on variable offsets... no, the lack of proper pointers and the typecasting of PBR is still gonna bone you on that. Hmm... perhaps if envObject were a child type of the struct for each element, you could then pass the uniform child? Yeah, that would work. Probably be a cleaner implementation than the rather obtuse "trait" thing that just looks to be trying to make the code as painfully cryptic as possible.

But that remains my biggest objection to rust, it REEKS of someone going "how illegible and hard to follow can we make this language?" -- again as if someone looked at the most obtuse parts of C++ and went "Hold my beer." -- made all the worse by the "wah wah, I don't wanna type" of garbage like "fn" or "impl", or the jackass obtuse behavior of 'let' and 'mut'.

All of them have an ECS at some point

Following those links, what they're calling ECS I'm used to hearing called -- and implemented -- as objects with methods and properties because that's what they ARE. The video for unity made me laugh though, since they're implementing this "ECS" thing with objects... even has a screencap of code that's showing a class with properties and methods... You have elements with data about them and behaviors -- aka objects with properties and methods.

To me that's not "ECS", that's just plain OOP. It's what OOP was built to DO!

Again I suspect I'm just behind on pointless new nomenclature being assigned to things we've been doing for 30 or so years without all the jargon... that or they are using the term when they grab the mallet to drive the square peg of what should be objects with inheritance into languages incapable of doing them.

Though admittedly, last time I dealt with anything in serious game dev (as opposed to my stupid little retrocomputing projects), the Quake II and Dark engines were bleeding edge. Well, that's not entirely fair I was brought in on a fairly large project about eight years ago to implement a version of my raster font kerning system in C++ as it is faster (at least once display lists are in place) than trying to do vector... much less monospace fonts look like arse.

They really needed some fancy acronym for loading data into objects? THIS is a goodly part of what I'm always seeing as a contributor to what's WRONG with modern development. Taking simple EXISTING concepts and throwing jargon at it to make it sound more important than it is.

Oh if only George Carlin had been a developer. "We'd like to begin the boarding process"... unneccessary word, process. Of course it's a process. Makes it sound important, it isn't. It's getting on the plane.

Get on the plane, get on the plane... f___ you, I'm getting IN the plane. Evel Knievel can get ON the plane.

"In the unlikely event of a sudden change in cabin pressure" -- ROOF FLIES OFF!

"In the unlikely event of a water landing . . ." Well, what exactly is a water landing? Am I mistaken, or does this sound somewhat similar to CRASHING INTO THE OCEAN?!?

I often feel that way when dealing with a lot of the terminology that's cropped up over the past decade. New pointless convoluted language for the sole purpose of making things sound more important or more complex than they are -- OR to create a duplicitous lie to hide ones sins.

I started my journey with Delphi, and although I like it, the community is small and game-dev is rather difficult with it.

I only really mentioned it as a half-joke. Game dev isn't that difficult with it though apart from the lack of anyone else doing it -- at least not if you're working at the engine level. If you're looking for easy off the shelf 'framework' style engines you are pretty much sierra oscar lima.

Which to my thinking is the difference between development and content generation. Developers write ENGINES, content generators use them. A bit harsh, but there is a clear line on that.

serious pain points (like composition over inheritance)

Ok, that's a new one I haven't heard. Given that inheritance was created to SOLVE pain points like endlessly redundantly having to type of copy the same code over and over again to do the same task, eliminate the headaches of tracking your own prototyping, and so forth.

That doesn't sound right to me; but then I have encountered a LOT of developers who seem deathly afraid of objects and OOP in general -- see PHP dev's who refuse to use PDO because it uses objects or insist on using the garbage pointless overhead inducing functional wrappers for mysqli. As if the difference between mysql_query($conn, $query) is magically easier to understand over $conn->query($query)...

Amethyst does have a website

Given it doesn't show up on any search engine for even its own bloody name -- or even related relevant tersm -- I wonder just what dumbass black-hat trick they used to get themselves completely pimp-slapped off the web.

-- View Source -- Oh... utter and complete incompetence at using HTML. That's what. The laugh being they use that semantic-UI rubbish that does EVERYTHING EXCEPT encourage the use of semantic markup. Hence the first heading on the page being depth 3 (gibberish), lack of a list around the menu, DIV for nothing, endless pointless presentational classes for nothing, presentational images static in the markup, DIV doing numbered heading's job... hardly a shock they're wasting 15k of HTML on their home page to deliver 1.2k of plaintext and NOTHING that qualifies as a content image -- not even 4k of markup's bloody huffing JOB!

Don't even get me started about the botched placement of the charset meta and middle finger to accessibility in their viewport meta by disabling the user's ability to zoom on mobile.

Jason Knight Wow, that's quite a long text. Thank you again for discussing stuff with me :)

SOUNDS very much like a language specific problem

to be honest, I don't think so. Modularization is not Rust-specific and something I'd also do in C or Pascal. I'd use the same architecture and then have the same problem of how to encapsulate each part to be self-contained without depending on one another (too much).

With a lack of objects

It's not like there are no "objects". It's just that Rust is not OOP, so the word seems wrong and it boils down to the naming of things. The struct keyword is the proper way to declare and define one, though, and is not a hack at all!

By the way, there also is no inheritance. Rust is purely compositional. With composition, you can do the same things as with inheritance, and a lot more. It is more versatile, so I don't think it is a constriction.

lack of proper pointers and the typecasting of PBR

Wow, you are using a pointer in your own example, you realize that? And what do you mean by PBR?

"pretend inheritance" [..] Probably be a cleaner implementation than the rather obtuse "trait" thing

I have the feeling you are falling into the same trap I did when I started out with Rust. You try to understand Rust with OOP references, but Rust is not OOP. Rust does not have inheritance and it does not try to emulate it or pretend to be able to even do it. Rust needs a different way of thinking and doing stuff, which, however, is unrelated to the original problem. Rust uses pure composition. Traits are a way to define behavior and can then be implemented on a struct. When you need certain behavior, all you have to do is request a trait (as type), and users of your API can pass whatever they want, as long as it just implements that trait (fyi, you can do that with any number of traits you need).

trait Area {
    fn area(&self) -> f32;
}

struct Square {
    a: f32,
}

struct Circle {
    r: f32,
}

impl Area for Square {
    fn area(&self) -> f32 {
        self.a * self.a
    }
}

impl Area for Circle {
    fn area(&self) -> f32 {
        3.14 * self.r * self.r
    }
}

// ...

fn print_area(shape: &Area) {
    let area = shape.area();
    println!("{}", area);
}

// ...

fn main() {
    let square = Square { a: 3. };
    let circle = Circle { r: 3. };

    print_area(&square);
    print_area(&circle);
}

(you can run the above code on the Rust-Lang website)

To me that's not "ECS", that's just plain OOP.

It's a certain way to do things... OOP is quite big, and an ECS can be implemented using OOP (or not) and can be implemented in different ways. So yeah, this discussion might just be about naming things and scope.

Ok, that's a new one I haven't heard.

The idea of "Composition over inheritance" was mainly popularized by the book "Design Patterns" by the Gang of Four. The thing is that composition can do the same as inheritance, but is a lot more versatile, because it is not bound by parents. Inheritance is mainly painful, when you try to do multi-inheritance and evolve an architecture and at some point have to wonder what to actually inherit from. Composition does away with that and says that you have to do a stricter modularization, so that you can always match anything in any way. There is no true composition baked into Pascal or C++ or JS, so you always have to come up with workarounds, however Rust goes that other way and if you need Inheritance, you have to come up with some workaround (but why though?). If you want to have a short example of how inheritance is a pain and should evolve into composition, look here :)

utter and complete incompetence at using HTML.

I don't use Amethyst because the devs are proficient web devs. No one can do everything! It's an opensource project, they don't have money, and if you don't like the HTML, you can improve it and that way contribute to the project :) .

I use Amethyst, because it is built in a way which I would also build an engine if I had to write one. To be exact, I did start to write an engine in C++ in nearly exactly that way, before finding out about Amethyst.

Wow, that's quite a long text.

For me that's a drive-by post. I have little use for the TLDR mouth-breathers who seem to be taking over society with their "wah wah, I don't wanna read; teh wurdzies eets hurtz!" BS! I kind of miss the days when users net-wide used to kvetch about 32k being too small for the typical forum post. Now you give these cheeto-fingered half-tweets 280 characters and they don't know what to do with it.

to be honest, I don't think so. Modularization is not Rust-specific and something I'd also do in C or Pascal. I'd use the same architecture and then have the same problem of how to encapsulate each part to be self-contained without depending on one another (too much).

Aka what the scope encapsulation of objects accomplishes even if you don't use inheritance! BUT, the LACK of inheritance or at least common prototyping is what's biting you here. You need a uniform prototype from the start so that things like your main loop have something to work with in a uniform manner instead of having every "world object" in your game needing a unique handler.

It's not like there are no "objects". It's just that Rust is not OOP, so the word seems wrong and it boils down to the naming of things. The struct keyword is the proper way to declare and define one, though, and is not a hack at all!

Structures (aka Records in Pascal) are NOT objects -- if they were C++ and Object Pascal wouldn't even exist, and would in fact use STRUCT (or Pascal's RECORD) instead of CLASS (or OBJECT).

There is no scope isolation of methods, no associated methods, no memory isolation or speeding of references at the compilation level. They're not objects by any stretch of the imagination.

... and without inheritance, they aren't objects either. Which is why even though they CALL struct with "traits" objects in Rust, they are not by any stretch of the imagination actually objects. Everything that makes objects worth using does not even exist in Rust.

With composition, you can do the same things as with inheritance, and a lot more.

HOW? I don't see that at all. It's a massive step BACKWARDS in usability and functionality.

Wow, you are using a pointer in your own example, you realize that? And what do you mean by PBR?

Notice the word "proper" -- as someone who started out in assembly, went to pascal, ADA, smalltalk, and C, to call what Rust does a 'pointer' is a crime against the word almost as massive as calling what they do with STRUCT and object.

... and PBR == pass by reference. What the & sign does in arguments in C, or what var does when inside the arguments list in pascal? Aka, send it a pointer to the data structure, not passing the data on the stack.

Rust forces typecasting of references, meaning you cannot pass a generic prototype... aka one of the ENTIRE reasons to use objects for the very subject we're talking about.

Admittedly, a lot of ALLEGEDLY experienced OOP programmers don't entirely seem to grasp that aspect of it.

I have the feeling you are falling into the same trap I did when I started out with Rust. You try to understand Rust with OOP references, but Rust is not OOP.

Actually I don't view Rust in that sense, but for the JOB AT HAND we are discussing I'm thinking on how I would optimally solve the problem, then trying to adapt that to the painfully agonizing limitations of the language -- and coming to the conclusion it is utterly unsuited to the task.

Rust needs a different way of thinking and doing stuff, which, however, is unrelated to the original problem.

That "different way of thinking" feeling to me like going for a trip with Mr. Peabody in the wayback machine to the worst of bad early '80's interpreters and pre-object methodology. We wanted that type of nonsense we'd still be writing software in DiBol.

The idea of "Composition over inheritance" was mainly popularized by the book "Design Patterns" by the Gang of Four.

Yup, and like a great many things having come to that having learned machine langauge FIRST and how to use objects PROPERLY in Object Pascal, ADA, and Smalltalk I found that book to be utter and complete tripe written by people who didn't understand how to use objects properly.

Though you spend ANY time writing ADA -- or Eiffel -- you wonder just what the blazes their smoking... but they came at it from the point of view of people who learned C first; and to be frank C can really fill your head with some over the top BS when it comes to overthinking the solution to EVERY problem! I think it just goes hand-in-hand with the raging chodo "C folks" have for needlessly cryptic syntax, they assume everything else needs to be as painfully cryptic and convoluted as the language itself

If you want to have a short example of how inheritance is a pain and should evolve into composition, look

I read that page four times trying to figure out what their beef was. To be brutally frank the only conclusion I could draw from it is that they didn't understand enough about objects to be telling others they are bad.

That they somehow managed to have what should have been a unique extension of "dog" up-tree inherit a method back to a sibling extension? PURE INCOMPETENCE that shouldn't even be POSSIBLE!

Their test case reeks of incompetence I rarely see outside of Java. In fact, I would have suspect that they learned objects in Java -- since no language will make you absolutely HATE objects like Java. Objects are useful, they solve problems, they're ONLY as difficult or confusing as you make them -- but forcing EVERYTHING in the language to be an object? That's just special; in the same way some Olympics are special.

I don't use Amethyst because the devs are proficient web devs

I was just trying to figure out why I was unable to find ANY information about it in ANY search engine, even searching for "Amethyst game engine" drawing a complete blank in Google, Yahoo, Yandex, and Bing. They appear to have been pimp-slapped clear off of search entirely.

... and really if they can't handle something as simple as semantic HTML, I'm not sure I'd trust them to make a game engine. It's often funny how "programmers" scoff at HTML for being "simple" or "easy" and "not a real programming language" -- you'll hear that garbage parroted all the time when 99.99% of the folks saying that couldn't write a single line of it properly to save their lives!

I use Amethyst, because it is built in a way which I would also build an engine if I had to write one.

Really that's where we differ is how we think about solving these problems. All this talk of "composition" and "modularization" and screwing around with shoe-horning object-like behavior into a language that doesn't have real objects REEKS to be of taking a problem that should be resolved in five minutes, and making it into a multi-week long struggle that will likely keep biting you every single day you develop the project!

I reject Rust because it doesn't work how I think about solving problems. What I see of Amethyst seems similarly flawed. They don't even seem to think in terms of solving problems efficiently and all because of some strange claim that doing more work in as convoluted a manner as possible is magically "easier". After 40 years of programming that strikes me as the same type of BS we saw with Prolog, Ruby, Forth, Comal, and the host of other 'revolutionary' languages that never amounted to anything more than a "also ran". MOSTLY because you can only peddle cool-aid to the cultists for so long before it starts killing them.

Just like how I reject half-witted ignorant TRASH like bootcrap, jQuery, react, vue, etc, etc... since not only do they not solve problems the way I think about solving them, they flip the bird at the underlying technologies and good practices.

But again I started out in RCA 1802 machine langauge, spent a good three years hand assembling code before I ever even had access to a high level language, came up through the microcomputer revolution and NOT the C and Unix world, and worked a good number of years in languages where the 'problems' people bitch about with things like Java and C++ simply don't exist.

I'm a relic of the cultural divide that honestly thought C and unix would be dead by the mid 1990's and that ACTUALLY gave us the world of computing we know today, instead of the big iron jackasses who ran companies like DEC, Wang, and Wyse into the ground. How the blazes the technologies and methodologies of those big iron jackasses ended up having an overwhelming resurgence remains a mystery to me.

Well, apart from career academics who never embraced the personal computer and the efforts of ONE lone developer that pulled unix and posixisms back from the brink of extinction. There are times I really don't know whether to praise or curse Linus Torvalds. Without his efforts you can bet your sweet bippy NOBODY apart from fringe whackjobs would be talking about unix or unix-likes today! Sorry FreeBSD, but that's the truth!