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

24 Hours of Rust Game Development

iolivia.me

Post reply on HN
Print view View original

51–60 of 78 posts

Re: 24 Hours of Rust Game Development

#51

Post by meheleventyone »

pjmlp wrote: post #46
meheleventyone wrote: post #41

Earlier quoted context omitted.

FWIW I don't think Jon is suggesting an OOP approach either. ECS advocates definitely promote that as the dichotomy though. There are lots of ways to structure game state without having to go the fine grained route.

Specially since many just learned it by doing, instead of reading the OOP literature regarding ECS systems. https://www.amazon.com/Component-Software-Object-Oriented-Pr...

ECS as meant here though is definitely imperative/functionally structured. Although there is a lot of familial resemblance with other component approaches.

Re: 24 Hours of Rust Game Development

#52

Post by flohofwoe »

golergka wrote: post #50
jblow wrote: post #16

It is fine that people are experimenting with putting graphics on the screen and playing with new languages. But I just wanted to comment that you don't need an "Entity Component System" in a game, and especially not for a very simple not-yet-a-game like shown here. (You also don't need inheritance or composition). It bothers me that so many people are buying into this hive-mind marketing on ECS, when in reality it i…

You don't need it to implement it a small-scope if the goal of your game project is to implement the game at hand. If the goal of your game project is to learn about tech and then use it on your main job, that's another matter. On my job, I work on a Unity3d-based match3 mobile game. I am constantly running into game logic as a performance bottleneck – modern match3 games with "live" boards that you can play on while…

I think you're talking about the new Unity ECS, which is a very specific implementation, while the OP talks about the general idea of composition via components, which is indeed overkill for many games.

If you're having an area of code which has a performance problem and can be isolated into a tight loop, the new Unity ECS is probably a good choice, but only in the specific context of Unity. And not because of the idea of "entities, components, and systems", but because the Unity ECS comes with a "toolbox" that makes it simple to run parallel code over flat arrays of structs, and with a limited C# subset created for writing high-performance code.

But it's important to note that outside of Unity, or other "behemoth engines" you can get close to that performance with a lot less effort, just by using a sane data layout and running your code in a simple loop (instead of running the same code in lots of tiny pieces interleaved with unrelated code, as is often the case with "traditional" entity-component systems.

Re: 24 Hours of Rust Game Development

#53

Post by emsy »

atoav wrote: post #40
jblow wrote: post #16

It is fine that people are experimenting with putting graphics on the screen and playing with new languages. But I just wanted to comment that you don't need an "Entity Component System" in a game, and especially not for a very simple not-yet-a-game like shown here. (You also don't need inheritance or composition). It bothers me that so many people are buying into this hive-mind marketing on ECS, when in reality it i…

That is definitly true for your first game. My first game was written in processing, which is a wonderfully visual way of learning to program. Obviously I had a huge loop with a myriad of nested if statements. Next thing I did was in Pyglet, this time I used Scene objectes that represented a statemachine that could switch arbitraily between other scene objects. Was much more comfortable to work with but slightly more…

You can have a non-ECS system without a giant inlined loop. If you look at an ECS for a typical 2D game what do you need? Components for: Sprites, Animation, Sound, Physics, Scripts, Pathfinding. All of which can be accomplished by function calls split up into separate source files. You can even begin with having everything inlined and pull the code out later once you've figured out what you want to do. ECS is overengineered abstraction to fit the set of all possible use cases instead of your specific use case. And if you write an engine that way you end up with an undebuggable mess of indirection for everything.

Re: 24 Hours of Rust Game Development

#54

Post by Manishearth »

whatshisface wrote: post #17
jblow wrote: post #16

It is fine that people are experimenting with putting graphics on the screen and playing with new languages. But I just wanted to comment that you don't need an "Entity Component System" in a game, and especially not for a very simple not-yet-a-game like shown here. (You also don't need inheritance or composition). It bothers me that so many people are buying into this hive-mind marketing on ECS, when in reality it i…

> If you want to make a simple game like this, just sit down and program it in the obvious way. It will work. I have heard that the restrictions imposed by the Rust compiler make it surprisingly hard to get it working the normal way. The first time I heard of ECS was in a Rust talk about how it helped them stop fighting the borrow checker.

> hard to get it working the normal way

This is mostly for complex games, otherwise for simple stuff there are ways to get it working.

Re: 24 Hours of Rust Game Development

#55

Post by pjmlp »

mtzet wrote: post #49
pjmlp wrote: post #47

Earlier quoted context omitted.

ECS builds up on protocol/interface oriented programming, where COM is the poster child how to organized such components. There is CS literature about component oriented programming.

Component oriented programming seems to about about inherting only interfaces, but still abstracting the data behind function interfaces? That's not at all what ECS's are about.

Component architecture doesn't specify how the data is stored, you are free to do SoA or AoS, depending on the case.

Re: 24 Hours of Rust Game Development

#56

Post by pjmlp »

meheleventyone wrote: post #51
pjmlp wrote: post #46

Earlier quoted context omitted.

Specially since many just learned it by doing, instead of reading the OOP literature regarding ECS systems. https://www.amazon.com/Component-Software-Object-Oriented-Pr...

ECS as meant here though is definitely imperative/functionally structured. Although there is a lot of familial resemblance with other component approaches.

SoA and AoS are othorgonal to components implementation.

Re: 24 Hours of Rust Game Development

#57

Post by rkangel »

jblow wrote: post #16

It is fine that people are experimenting with putting graphics on the screen and playing with new languages. But I just wanted to comment that you don't need an "Entity Component System" in a game, and especially not for a very simple not-yet-a-game like shown here. (You also don't need inheritance or composition). It bothers me that so many people are buying into this hive-mind marketing on ECS, when in reality it i…

This specific article starts with them doing a non-ECS design, and then running into problems, looking for the right solution, and having ECS solve them. I agree with your point that an ECS is not a one-size-fits-all solution (because nothing ever is), but this article is evidence that it can help even in some simple cases.

Re: 24 Hours of Rust Game Development

#58

Post by rkangel »

slavik81 wrote: post #9
codetrotter wrote: post #2

> ggez Off-topic but that’s a darn nice name for a game engine. Certainly ggez means “good game easy”. At least that’s how I read it. Clever because “gg” and “ez” is gamer terminology used by people that play video games, with “gg” meaning a match was good (equivalent of “thanks for the match”) and putting them together you get a new meaning which is that it will be easy to create a good game.

"gg ez" is a taunt some players use when they win. Overwatch chat infamously auto-replaces that phrase with messages like, "I'm wrestling with some insecurity issues in my life but thank you for playing with me." That being said, it is a clever name for an engine for the reasons you stated. And it's short, which is always nice.

I have been playing OW on and off for ages and didn't know that. Thanks!

Re: 24 Hours of Rust Game Development

#60

Post by eigenloss »

visualphoenix wrote: post #20
jblow wrote: post #16

It is fine that people are experimenting with putting graphics on the screen and playing with new languages. But I just wanted to comment that you don't need an "Entity Component System" in a game, and especially not for a very simple not-yet-a-game like shown here. (You also don't need inheritance or composition). It bothers me that so many people are buying into this hive-mind marketing on ECS, when in reality it i…

+1. Like you, I've seen both sides. Unreal lineage evolved from inheritance-based into ECS-like. Frostbyte is heavily ECS. Googling... the author is ex-amazon, ex-microsoft - with xbone and 360 title experience. Perhaps the author was exposed to that pattern at one of those institutions, or perhaps the author saw the 2018 Rust Conf Closing Keynote[0] and was inspired to continue down that path. I think people tend to…

Especially ironic given that Rust's default package/project management tool is named 'cargo.'
Post reply on HN