Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hands-On Rust: Effective Learning Through 2D Game Development and Play

pragprog.com

Post reply on HN
Print view View original

61–70 of 83 posts

Re: Hands-On Rust: Effective Learning Through 2D Game Development and Play

#61

Post by brundolf »

verdagon wrote: post #37
halvnykterist wrote: post #3

I can't help but be heavily skeptical of approaches to a (traditional) roguelike that use ECS. The idea is very entrenched in the rust gamedev community, but for a turn based tile based game there's extremely little benefit and a lot of added complexity. Bob Nystrom has an excellent talk on roguelike architecture [0] and rust as a language itself doesn't prevent any of these approaches. If anything, the existence of…

Indeed, ECS might not be a good fit for turn-based games. We explored the topic quite thoroughly in [0] and came to the conclusion that Roguelikes are more suited for something in-between ECS and OO, named just "EC". ECS is better suited to real-time games, or games which have a lot of iteration over large arrays and parallel (not as in multi-threading, but as in, batchable) computations, where ECS can really shine d…

> Idiomatic Rust tends to dislike heap allocation and virtual dispatch

Maybe Rust the way most people end up writing it, but Rust the language has no issue with these things. I think the idioms come more from the fact that Rust empowers you to avoid these things, not that it's poorly-suited to them.

Re: Hands-On Rust: Effective Learning Through 2D Game Development and Play

#62

Post by Rusky »

pjmlp wrote: post #58
glowcoil wrote: post #52

Earlier quoted context omitted.

> There has been an explosive growth in component software technologies since the first edition of this classic book was published. The advent of EJB, J2EE, CORBA 3, COM+ and the .NET framework are evidence of a maturing market in component software that goes 'beyond OOP'. This book seems to be discussing distributed object systems, which is a sense of the word "component" that has little or nothing to do with the se…

I also did not state that book was the canonical ECS model, rather that it was one of the first sources to move into discussing components instead of classes. COM and DirectX aren't distributed object systems, nor Objective-C protocols, for example. Don't confuse COM with DCOM and COM+. Then there are the component models based on traits, mixins, patterns, message passing, type classes,... plenty of variants scattere…

You are still conflating two totally unrelated things.

The book is one of the first sources to move into discussing "components," as in coding against interfaces/protocols/traits/etc.

ECS deals with "components," as in pieces of data composed using a relational model. This has nothing to do with interfaces or protocols whatsoever! It is practically the opposite thing- working directly with raw data, with no abstraction boundary.

You can't just pattern match on the word "component" and expect it to mean the same thing to everyone.

Re: Hands-On Rust: Effective Learning Through 2D Game Development and Play

#63

Post by platz »

moth-fuzz wrote: post #59
modernerd wrote: post #6

Earlier quoted context omitted.

I think Jonathan Blow's take is right: > ECS only starts to make sense when you are big enough to have multiple teams, with one team building the engine and the other using the engine to make the game; or you are an engine company and your customer makes the game. If that is not your situation, do not rathole. https://twitter.com/Jonathan_Blow/status/1427358365357789199 Most of the arguments I've seen for ECS in Rust…

This is an interesting happenstance in the Rust community that I think is largely cultural rather than technical. Backlash against some figurative idea of OOP is popular. ECS is popular as the messianic retort to that OOP figure. But when you look at it from an architectural standpoint, ECS is quite possibly one of the hardest things to do in Rust compared to other designs. Let me get this straight - you want to avoi…

are these message channels deterministic? Or would order of delivery and processing be resolved by chance?

Re: Hands-On Rust: Effective Learning Through 2D Game Development and Play

#64

Post by nyanpasu64 »

platz wrote: post #63
moth-fuzz wrote: post #59

Earlier quoted context omitted.

This is an interesting happenstance in the Rust community that I think is largely cultural rather than technical. Backlash against some figurative idea of OOP is popular. ECS is popular as the messianic retort to that OOP figure. But when you look at it from an architectural standpoint, ECS is quite possibly one of the hardest things to do in Rust compared to other designs. Let me get this straight - you want to avoi…

are these message channels deterministic? Or would order of delivery and processing be resolved by chance?

Message channels are deterministic if they're only used on a single thread.

Re: Hands-On Rust: Effective Learning Through 2D Game Development and Play

#65

Post by ngrilly »

pjmlp wrote: post #48
dgb23 wrote: post #41

Earlier quoted context omitted.

Not sure I get what you mean. As I see it, ECS has more of a relational character. Feels more like data pipeline than operations/messages on objects. I think the mental model matters the most here and that depends on how you think of objects. But then any attempt of defining OO objectively seems to be futile, there are conflicting historical and contemporary notions plus a whole bunch of jargon on top, depending on w…

That is when data oriented programming gets into the equation. Classical ECS as it originally appeared on the literature is coding against interfaces, COM or Objective-C protocols style. So yeah, one composes those interfaces together, there is no class inheritance, only composition, delegation, and a system is composed from a jungle of such components. It is also a reason why DirectX is COM based, instead of basic W…

What do you mean by classical ECS? I’ve always read that the Entity-Component-System approach originated in the gaming industry, completely unrelated to what you wrote about COM, etc.

Re: Hands-On Rust: Effective Learning Through 2D Game Development and Play

#66

Post by pjmlp »

Rusky wrote: post #62
pjmlp wrote: post #58

Earlier quoted context omitted.

I also did not state that book was the canonical ECS model, rather that it was one of the first sources to move into discussing components instead of classes. COM and DirectX aren't distributed object systems, nor Objective-C protocols, for example. Don't confuse COM with DCOM and COM+. Then there are the component models based on traits, mixins, patterns, message passing, type classes,... plenty of variants scattere…

You are still conflating two totally unrelated things. The book is one of the first sources to move into discussing "components," as in coding against interfaces/protocols/traits/etc. ECS deals with "components," as in pieces of data composed using a relational model. This has nothing to do with interfaces or protocols whatsoever! It is practically the opposite thing- working directly with raw data, with no abstracti…

That is the next step, data oriented programming, which many confuse with ECS, as they tend to be used together.

Re: Hands-On Rust: Effective Learning Through 2D Game Development and Play

#67

Post by pjmlp »

ngrilly wrote: post #65
pjmlp wrote: post #48

Earlier quoted context omitted.

That is when data oriented programming gets into the equation. Classical ECS as it originally appeared on the literature is coding against interfaces, COM or Objective-C protocols style. So yeah, one composes those interfaces together, there is no class inheritance, only composition, delegation, and a system is composed from a jungle of such components. It is also a reason why DirectX is COM based, instead of basic W…

What do you mean by classical ECS? I’ve always read that the Entity-Component-System approach originated in the gaming industry, completely unrelated to what you wrote about COM, etc.

Yes, the famous GDC talk.

Usually most stuff in game development tends to be rediscovered, as most people don't come from CS backgrounds.

Re: Hands-On Rust: Effective Learning Through 2D Game Development and Play

#68

Post by verdagon »

brundolf wrote: post #61
verdagon wrote: post #37

Earlier quoted context omitted.

Indeed, ECS might not be a good fit for turn-based games. We explored the topic quite thoroughly in [0] and came to the conclusion that Roguelikes are more suited for something in-between ECS and OO, named just "EC". ECS is better suited to real-time games, or games which have a lot of iteration over large arrays and parallel (not as in multi-threading, but as in, batchable) computations, where ECS can really shine d…

> Idiomatic Rust tends to dislike heap allocation and virtual dispatch Maybe Rust the way most people end up writing it, but Rust the language has no issue with these things. I think the idioms come more from the fact that Rust empowers you to avoid these things, not that it's poorly-suited to them.

I think both are true. Rust is poorly-suited to certain architectures, and empowers us to use other architectures. Rust's idioms take both its strengths and weaknesses into account.

It can make up for it in other ways, but in my experience, Rust is poorly-suited for Roguelike architecture specifically.

Re: Hands-On Rust: Effective Learning Through 2D Game Development and Play

#69

Post by [deleted] »

moth-fuzz wrote: post #59
modernerd wrote: post #6

Earlier quoted context omitted.

I think Jonathan Blow's take is right: > ECS only starts to make sense when you are big enough to have multiple teams, with one team building the engine and the other using the engine to make the game; or you are an engine company and your customer makes the game. If that is not your situation, do not rathole. https://twitter.com/Jonathan_Blow/status/1427358365357789199 Most of the arguments I've seen for ECS in Rust…

This is an interesting happenstance in the Rust community that I think is largely cultural rather than technical. Backlash against some figurative idea of OOP is popular. ECS is popular as the messianic retort to that OOP figure. But when you look at it from an architectural standpoint, ECS is quite possibly one of the hardest things to do in Rust compared to other designs. Let me get this straight - you want to avoi…

[deleted]

Re: Hands-On Rust: Effective Learning Through 2D Game Development and Play

#70

Post by wlamartin »

nulldata wrote: post #33
halvnykterist wrote: post #3

I can't help but be heavily skeptical of approaches to a (traditional) roguelike that use ECS. The idea is very entrenched in the rust gamedev community, but for a turn based tile based game there's extremely little benefit and a lot of added complexity. Bob Nystrom has an excellent talk on roguelike architecture [0] and rust as a language itself doesn't prevent any of these approaches. If anything, the existence of…

ECS might have a higher initial complexity overhead, but once you scale up, ECS can really help you keep complexity at bay. There's a great talk [0] from the Overwatch developers where they talk about how they built Overwatch using the ECS architecture. They barely mention performance at all, but instead talk about how it helped deal with complexity. [0] https://www.gdcvault.com/play/1024001/-Overwatch-Gameplay-Ar...

At https://story.ai we're using Shipyard ECS to model the data behind the structured editing experience. Although at first I was suspicious, I've come to realise it's an extremely elegant way to handle our complexity.

Consider for example, a snippet that reads along the lines of:

    when there is a new stripe charge
       send a slack message
It's very nice to attach something like a "ScopeContext" component to each Entity that has a "TokenLine" component, that is a Vec of EntityIds that are sharing values into scope. Very easy to model and add without interfering with other data structures.
Post reply on HN