Live data from Hacker News

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

pragprog.com

71–80 of 83 posts

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

#71

Earlier quoted context omitted.

I've coded MUDs for about 25 years now, and I use a lot of these patterns in my code. Nice to see someone else thinks its useful. I think a key strategy that is not touched on too much in the talk is flexibility in your effect system, whatever your effect system may be. It should be trivial to take an effect (heal, damage, stat boost, etc) and let anything in your game apply it to actors with just a few lines of code…

Do you know of any articles or resource that go into your style a bit deeper? I'd love to hear more on how your effects system works and how that compares to a component-based or ECS architecture.

I wouldn't call it an architecture, more a goal. When I say effect system, I just mean how you apply various effects to your players/npcs. I wouldn't prescribe how to get there - it could just be your component system.

For myself, I go at it from a baseline approach: effects are one of the fundamental building blocks of the game. As much as possible, if something in the game does something, I try to do it through effects. This includes skills, spells, weapons, armor, commands, AI, systems, etc.

If everything does everything through these effects, you can make anything do anything in response to anything without having to special code it.

I don't make it that flexible for various reasons. But I think it's a good place to be philosophy-wise for something like a MUD.

As an example from the video, there is an Attack, Use, and Defense class that Items use, with specific attributes assigned to them (armor, dodge bonus, min damage, max damage, etc). With effects, you might have a list of effects that trigger on wear, on attack, on activate, etc.

A common effect is a damage effect. You could make an item that damages someone you hit with it (typical weapon), damages you when you wear it, or damages a target when you activate it. But you could do this with literally any effect you programmed for any spell or command. You can make an item heal you when you wear it. Or provides a heal over time when you wear it. Or heals your target when you hit them with it.

You can even combine them. I could make an item that, when worn, transfers everyone in the game to the wearer's location and kills them. I could do the very same thing for a spell. Or when someone enters a tile. Or a command. Etc.

I can do this because there is an admin command that can transfer everyone in the game to a location. It does this by effects. I have an admin command that can insta-kill anyone. It does this by effects. I can assign these effects to any place that uses effects.

I arrived at this solution because, when working long term on MUDs, I found myself coding the same thing over and over for different subsystems for different content creators. Ultimately my mantra turned into "non coders shouldn't need coders to build new, cool things" and this is how I went about doing that.

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

#72
post #66
post #62

Earlier quoted context omitted.

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.

I am not talking about data oriented programming. With or without that sort of memory layout optimization, ECS "component" still refers to un-abstracted chunks of concrete data rather than interfaces/protocols/etc.

Let's step back even further and consider Unity's pre-DOTS "entities" and "components." These do not take the data oriented approach, are not typically even classified as ECS (e.g. because they lack the System aspect of that design). However, the components are clearly chunks of concrete data (transforms, meshes, rendering parameters, rigid bodies, etc.) rather than interfaces/protocols.

This is the sense in which ECS means "component." That book is not relevant to this sense.

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

#73
post #23

The book sounds awesome to get your hands dirty with Rust :) is there a promo code for Latin-american countries?

by any chance, can you reccomend a good book for learning programming thats written for a spanish speaking audience?

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

#74
post #44

Earlier quoted context omitted.

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…

Frictions a funny thing in this sense and what hurts one person helps another.

One example is that a concrete entity is much harder to change than one that is composed of concrete components. So for example an artist I work with took some components from an FPS game we made, some other random components we had and a couple of components made in people’s spare time, made a bunch of art and ended up with a pretty convincing prototype of a multiplayer shooter. He couldn’t have done that at all following a concrete entity approach.

Composition and in particular making composition data-driven and runtime malleable is very flexible even if you don’t care for the ECS approach.

But a large part of the problem is that we end up promulgating opinion divorced from context and often a lot of that context is not really more complex than the approach someone is used to. Like if you have no problems with the concrete entity approach which has been a successful pattern since forever then there isn’t that much compelling you to change. That doesn’t make it the one true way or that because someone famous and opinionated likes it that there isn’t an alternative that will better serve someone else’s needs.

Horses for courses.

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

#75

Earlier quoted context omitted.

ECS is entrenched in rogue development in general, at least going by r/roguelikedev. It (or at least a component architecture, if not fully blown ECS) seems to be a good fit since these style of games tend to have a lot of composition (in items, effects, behaviour). Personally, while my experience is a bit limited, I quite like the ECS style. It just makes logical sense to me as a way of composing entities from diffe…

I’ve not yet used Godot. What is the Godot style like? And are there some documents about it and example code of it?

Godot uses a hierarchy of nodes, you can think of it as one step further than entities being composed of components. The hierarchy and how nodes operate on it define the game. In practice though you end up with things that look very entity like IMO so it’s not that different.

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

#76
post #60
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?

how you replace bracket-lib is the core of the exercise. There's more than one way to do it.

Translating the implementation to bevy on the fly as you read the book would probably be much more difficult than what I described.

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

#77

Earlier quoted context omitted.

> 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.

Broadly speaking yes, it's good and bad at different things. Specifically ownership is obviously the big challenge, and is often associated with heap allocation and dynamic dispatch. But the latter two in their own right are not any harder or more limited in Rust than anything else.

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

#78

Earlier quoted context omitted.

Do you know of any articles or resource that go into your style a bit deeper? I'd love to hear more on how your effects system works and how that compares to a component-based or ECS architecture.

I wouldn't call it an architecture, more a goal. When I say effect system, I just mean how you apply various effects to your players/npcs. I wouldn't prescribe how to get there - it could just be your component system. For myself, I go at it from a baseline approach: effects are one of the fundamental building blocks of the game. As much as possible, if something in the game does something, I try to do it through eff…

Thanks for elaborating!

I've actually tinkered with MUD development in the past and that actually does make a lot of sense.

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

#79
post #72
post #66

Earlier quoted context omitted.

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

I am not talking about data oriented programming. With or without that sort of memory layout optimization, ECS "component" still refers to un-abstracted chunks of concrete data rather than interfaces/protocols/etc. Let's step back even further and consider Unity's pre-DOTS "entities" and "components." These do not take the data oriented approach, are not typically even classified as ECS (e.g. because they lack the Sy…

A book that I clearly referred it was only one of the first ones that somehow started talking about this, I never stated it was the definition of ECS.

Apparently making the point about how relevant this specific book is, is what matters in this whole thread.

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

#80
post #60
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?

[deleted]
Post reply on HN