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

51–60 of 83 posts

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

#51

Post by cardanome »

dgb23 wrote: post #44
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…

I really like Jonathan Blow, but I sometimes wish he would substantiate these kind of claims more so an outsider could learn what he is actually saying and why. I've watched a lengthy video of his on that topic but I didn't get out anything other than "you don't need it". No concrete implementation cases where it gets in the way or how a category of problems is better modeled in a different way.

I am beginning to suspect people like him because he speaks slowly with lots of repetition and in a relatively accessible way.

Sure he might have lot's of valuable experience but every video I have watched of him was like a 1 hour rambling opinion piece which could be 3 minutes of actual content.

His video reaction to the rustconf ECS video had some good points but they were very nitpicky and not really justifying the length of the video at all.

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

#52

Post by glowcoil »

pjmlp wrote: post #20
cardanome wrote: post #10

Earlier quoted context omitted.

ECS is for me the natural way to design games. I wouldn't even know to design them any other way. I started game dev with love2d which is a pretty minimalist framework. When I participated in a game jam, I needed a very flexible system that would allow for quick prototyping and would handle many different entities. I ended up writing something which I later realized would be an ECS system. It worked great and I would…

ECS and OOP are sides of the same coin, although apparently it is only visible to those that read SIGPLAN papers. "Component Software: Beyond Object-Oriented Programming" https://www.amazon.com/-/en/Clemens-Szyperski/dp/0201745720 One of the first publications on the matter.

> 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 sense used by game developers in reference to the ECS architecture. Distributed object systems are designed to enable an object-oriented design philosophy to be used for a system which spans multiple address spaces or machines. The entity-component-system architecture is a methodology for organizing data layout and program functionality, usually within a single address space on a single machine, where the data associated with a given entity is spread across multiple components or subsystems and associated by index relations (much like a relational database), rather than being all grouped together in one place (as encouraged in OOP).

These two concepts (distributed object systems and ECS) are designed to solve different problems, they are generally used in different scenarios, and they apply at different levels of system organization. There is so little resemblance between the two that I have to conclude someone calling them "sides of the same coin" is either completely unfamiliar with one of them or is being deliberately misleading.

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

#54

Post by modernerd »

dgb23 wrote: post #44
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…

I really like Jonathan Blow, but I sometimes wish he would substantiate these kind of claims more so an outsider could learn what he is actually saying and why. I've watched a lengthy video of his on that topic but I didn't get out anything other than "you don't need it". No concrete implementation cases where it gets in the way or how a category of problems is better modeled in a different way.

On why ECS gets in the way for him:

> Because it is far more complicated, thus takes far more work, than what you actually need to do. That work has a large opportunity cost. https://twitter.com/Jonathan_Blow/status/1427378984145154048

To me this has more nuance than, “you ain't gonna need it”. I don't think “concrete implementations” would do all that much to strengthen his argument that unnecessary complexity gets in the way of shipping for indie devs:

> Even 10% friction more than I ever had would have killed me. I wouldn't have been able to make the things I had. Even 5% more friction would have been really bad. https://youtu.be/4t1K66dMhWk?t=3635

And…

> I have, several times, built games where I barely managed to finish. … I've just experienced that too many times to increase friction. I need to decrease friction. https://youtu.be/4t1K66dMhWk?t=3072

And again, in relation to entities rather than Rust's borrow checker:

> If you are trying to focus on the way your entities are set up, you are mis-directing your effort and that's going to make it harder. Try to solve the problem that makes your game interesting. What is it about the gameplay that makes it interesting … that users can see? Focus on that, solve those problems. https://www.youtube.com/watch?v=w7W3xM2tzRA

On what he uses instead of ECS/components in his engines:

> One struct per entity type, with a base struct that is common to all of them. https://twitter.com/Jonathan_Blow/status/1427376307453665280

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

#55

Post by halvnykterist »

MaulingMonkey wrote: post #47
halvnykterist wrote: post #17

Earlier quoted context omitted.

> Composition over inheritance (especially in Rust, which doesn't really have inheritance - although you can fake it with traits) This does not require ECS, you can happily have something like struct Entity { components: Vec >, } (Nor do I think this is a good way of setting up a traditional roguelike) > Replication; if you want to replicate state across multiple nodes, a good ECS can really help you I'm not sure wha…

struct Entity { components: Vec >, } At this point you're effectively just hand-rolling your own ECS - and perhaps being in denial about it by touting the fact that the ECS is half implemented at best - rather than eschewing an ECS outright, IMO. If you want to skip the ECS, embrace the natural typing of the language - then you don't need to build something to query and filter components, and can instead just use the…

The crucial difference between having a vector of components is in access patterns - in ECS you iterate over entities that have a given set of component, using queries, with entities that have vectors of components you're still iterating over entities. For something like a roguelike you're generally just dealing with one entity at a time, so this is a very important distinction.

That said, I don't think just having a vector of components is good design, you can do a lot better than that. I think the most natural thing to do in most roguelikes is to have an "Entity" type that's shared between players and monsters and has things that you'd expect those things to have, along with an inventory and potentially some kinds of tags governing behavior. Type Objects etc fit nicely into that kind of scheme.

>and Entity enumeration without archetype filtering may eventually become a performance hazard if done too frequently and naively, I'm specifically talking about turn based tile based games, here, so iterating over all entities matching a given set of components is rarely going to be a performance concern. It's far more important to make sure you're efficient when it comes to things like AI routines and pathfinding.

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

#56

Post by timClicks »

dudul wrote: post #24

I started reading this book a few months ago. It is pretty good, I really like learning while working on a "sort of real world" project. However, being completely new to Rust I find that the author doesn't spend enough time discussing the language, it's syntax and nuances. It is hard to talk both about rust alongside video game design techniques. I put it down after reading 1/4th of it. I'm planning to spend some tim…

That's a very difficult balance as an author writing a project-based book for a language. It's really difficult to know how much time to spend where: the language (Rust), the projects background (gamedev patterns) or the project code.

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

#57

Post by ffhhj »

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 is nothing compared to the eclipsing aspects of games that a gamedev has to solve:

* Structures persistency (save/load/stream)

* Optmized seamless world expansion

* Where to get assets and content from (licenses, generated, etc.)

* Affordable and responsive multiplayer

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

#58

Post by pjmlp »

glowcoil wrote: post #52
pjmlp wrote: post #20

Earlier quoted context omitted.

ECS and OOP are sides of the same coin, although apparently it is only visible to those that read SIGPLAN papers. "Component Software: Beyond Object-Oriented Programming" https://www.amazon.com/-/en/Clemens-Szyperski/dp/0201745720 One of the first publications on the matter.

> 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 scattered around SIGPLAN and ECOOP papers.

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

#59

Post by moth-fuzz »

modernerd wrote: post #6
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…

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 avoid shared mutability but you have all your gamestate in centralized stores? That systems will necessarily have to have shared, mutable access to? Possibly concurrently? I think it's a good idea architecturally, but also I think it's a tough problem to solve, and I think the claims that Rust lends itself to that architecture are false. It's even tougher in Rust than in other languages, I'd say. And though I've read the source code to many Rust ECS libraries, they all do it in different ways, and all of them feel like hacks.

I definitely feel like the most "rustic" way to do game design, just based on what's easy to do in the language itself without resorting to workarounds, is to have individual actors maintain their individual state, and then have a common interface via a trait that would call update() or render() virtually in a loop or whatever. Then have them message each other via mpsc channels. That's pretty much rust straight from the book, and, it's also a bog standard GameObject architecture straight outta the 2000s.

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

#60

Post by rtoway »

ttymck wrote: post #53

It is a very good learning guide. Keep in mind I am someone who negotiates the borrow checker by adding-and-removing */&/to_owned() rather haphazardly. I found it especially satisfying to port the game from racketlib/rltk to bevy afterwards.

I was thinking of following the book but with Bevy. How do you replace bracket-lib?
Post reply on HN