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

41–50 of 78 posts

Re: 24 Hours of Rust Game Development

#41

Post by meheleventyone »

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…

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.

Re: 24 Hours of Rust Game Development

#42

Post by Svenstaro »

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.

I picked the name because the parts themselves are indeed what you said but when provided in combination it's a bit of a mean thing to say to say to the other team as you proclaim your easy victory in the context of online games. Sometimes it's also used ironically after the end of a long drawn out game that quite obviously wasn't easy for either side.

However, I was aware of that and decided to instead embrace it as a tongue in cheek kind of thing as I wanted to make a love2d clone and love is all about nice things so I wanted to make a game framework with all of the mean things. Hence why the logo is a salt shaker.

I never thought icefox would grow ggez into what it is otherwise I might have picked a less mean theme but maybe not. :)

Re: 24 Hours of Rust Game Development

#43

Post by mypalmike »

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…

I'm kind of fascinated by the source code of this developer i found a couple years ago when exploring ECS: https://github.com/DaanVanYperen

Lots of interesting game-jam entries cranked out quickly using "pure" ECS : many small components, many small systems. Playable versions of some are here - http://www.mostlyoriginal.net/

Re: 24 Hours of Rust Game Development

#44

Post by codetrotter »

Svenstaro wrote: post #42
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.

I picked the name because the parts themselves are indeed what you said but when provided in combination it's a bit of a mean thing to say to say to the other team as you proclaim your easy victory in the context of online games. Sometimes it's also used ironically after the end of a long drawn out game that quite obviously wasn't easy for either side. However, I was aware of that and decided to instead embrace it as…

Interesting and makes sense I think. Thanks for giving this background info on the name :)

Re: 24 Hours of Rust Game Development

#46

Post by pjmlp »

meheleventyone wrote: post #41
atoav wrote: post #40

Earlier quoted context omitted.

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…

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

Re: 24 Hours of Rust Game Development

#47

Post by pjmlp »

mtzet wrote: post #39
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…

By the obvious way, I'm guessing you would just have a single type 'entity' and put all entities in an array? While that may be obvious to you, it's not obvious to a lot of programmers (myself included) who grew up learning about object orientation, abstractions and modelling behaviour on the real world. ECS's for all their added complexity come with the breath of fresh air that is classical imperative programming wh…

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.

Re: 24 Hours of Rust Game Development

#48

Post by StavrosK »

StavrosK wrote: post #10
m0meni wrote: post #7

Earlier quoted context omitted.

You seem disproportionately angry about this because of your personal experiences. It means you can create a "Good Game Easily"

It means that as much as "Sieg heil" means "hail to victory" and is an appropriate thing to say before a football match. You can't just take an existing phrase and pretend it doesn't mean what it means and feedback of the current meaning as "personal experiences".

Dismiss* feedback, missed a word there.

Re: 24 Hours of Rust Game Development

#49

Post by mtzet »

pjmlp wrote: post #47
mtzet wrote: post #39

Earlier quoted context omitted.

By the obvious way, I'm guessing you would just have a single type 'entity' and put all entities in an array? While that may be obvious to you, it's not obvious to a lot of programmers (myself included) who grew up learning about object orientation, abstractions and modelling behaviour on the real world. ECS's for all their added complexity come with the breath of fresh air that is classical imperative programming wh…

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.

Re: 24 Hours of Rust Game Development

#50

Post by golergka »

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 they flow is a combinatorial nightmare sometimes. Obviously, I can't rewrite already released project to take advantage of ECS, but I constantly toy with it in my free time so we don't run into the same problems in the future - without any desire to make a complete game with these toy projects.

Post reply on HN