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

71–78 of 78 posts

Re: 24 Hours of Rust Game Development

#71

Post by ehsanu1 »

visualphoenix wrote: post #68
jorgeavaldez wrote: post #35

Earlier quoted context omitted.

For some people (myself included) the technology is part of the fun. The cargo cult popularity can definitely influence the decision to play with the technology, and by no means does it indicate that it is entirely appropriate for the task at hand. I personally use it as an exercise to familiarize myself with the patterns in a toy environment, which leaves me better equipped to apply them for a problem that lends its…

I agree. It's definitely fun to play with new programming languages and technologies. Using games as a medium to explore a new language is a great way to learn and have fun at the same time. That said, when a game development luminary like jblow takes the time to make a comment, it's good to think about why. It seems to bother jblow that people are buying into the use of this system without thinking about the costs a…

I'd say the gulf between monolithic and microservice architectures is much wider than between ECS and non-ECS in games. The cost of microservices is much higher than that of ECS.

While building a game using some inheritance based approach, one will quickly hit limits even with a single engineer, whereas a monolithic web app can scale to a team of a couple dozen engineers easily.

Re: 24 Hours of Rust Game Development

#72

Post by jblow »

ehsanu1 wrote: post #71
visualphoenix wrote: post #68

Earlier quoted context omitted.

I agree. It's definitely fun to play with new programming languages and technologies. Using games as a medium to explore a new language is a great way to learn and have fun at the same time. That said, when a game development luminary like jblow takes the time to make a comment, it's good to think about why. It seems to bother jblow that people are buying into the use of this system without thinking about the costs a…

I'd say the gulf between monolithic and microservice architectures is much wider than between ECS and non-ECS in games. The cost of microservices is much higher than that of ECS. While building a game using some inheritance based approach, one will quickly hit limits even with a single engineer, whereas a monolithic web app can scale to a team of a couple dozen engineers easily.

The idea that you would “quickly hit limits” on a 1-programmer project is completely baseless. In fact a 1-programmer project is easier without an ECS as it’s one less system whose constraints you would have to comply with at all times.

Please stop saying this stuff as it just contributes to the general confusion.

Re: 24 Hours of Rust Game Development

#73

Post by jblow »

blixt wrote: post #61
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 sure there are plenty of people out there who have a knee-jerk "ECS can solve that" reaction, but also be careful that you're not yourself just having a knee-jerk reaction here. A full-fledged ECS can in fact be very helpful when writing game jam style code and you need to quickly iterate on ideas. Separating each unique idea into components (health, movement, ammo) and systems (physics, damage, AI) lets you turn…

If you can quickly iterate with a component system, you can iterate even faster just with regular procedures. Component systems aren’t magic (in fact they introduce friction).

Re: 24 Hours of Rust Game Development

#74

Post by drainyard »

ehsanu1 wrote: post #71
visualphoenix wrote: post #68

Earlier quoted context omitted.

I agree. It's definitely fun to play with new programming languages and technologies. Using games as a medium to explore a new language is a great way to learn and have fun at the same time. That said, when a game development luminary like jblow takes the time to make a comment, it's good to think about why. It seems to bother jblow that people are buying into the use of this system without thinking about the costs a…

I'd say the gulf between monolithic and microservice architectures is much wider than between ECS and non-ECS in games. The cost of microservices is much higher than that of ECS. While building a game using some inheritance based approach, one will quickly hit limits even with a single engineer, whereas a monolithic web app can scale to a team of a couple dozen engineers easily.

You don't have to use an inheritance based approach if you don't make it an ECS. The point is that using any "something-based" approach is not necessary for most small and even medium sized games. Just make what seems obvious until it doesn't work and then change it. If you start thinking about architecture from the start you will have an issue when you find out it won't work for your project no matter the architecture you are using.

Re: 24 Hours of Rust Game Development

#75

Post by alkonaut »

afterparty wrote: post #69
alkonaut wrote: post #66

Earlier quoted context omitted.

If I made a game though, it would likely be because I wanted to learn how an ECS works, or how to make an ECS, or how to make a game engine in general. Also I'd probably quit once the ECS was done but before anything was actually playable, because all the fun stuff (in my opinion) would be the technical plumbing and engine details, and not actually making anything creative with it. As another example of this: I just…

hi, I'm interested in audio programming. Any tips/advice on a good starting point, etc.

If you are also interested in learning rust (as I am) you'll find an enthusiastic and new "RustDSP" community.

I'll mention that rust is young for this (e.g. VST dev), so if you don't want to learn rust but just want to get something finished - then Rust is probably not what you want. It's great for audio programming but the GUI buits are still immature.

https://github.com/rust-dsp/rust-vst

Re: 24 Hours of Rust Game Development

#76

Post by PyroLagus »

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…

Correct me if I'm wrong, but isn't ECS a really fitting architecture for a simulation/tycoon game? There are lots of entities and components that have to be updated and whose updates could be parallelized. Granted, the game in the post is far from a full-scale tycoon, but wouldn't it make sense to just start with an ECS if you're going to use it in the end anyways?

Re: 24 Hours of Rust Game Development

#77

Post by blixt »

jblow wrote: post #73
blixt wrote: post #61

Earlier quoted context omitted.

I'm sure there are plenty of people out there who have a knee-jerk "ECS can solve that" reaction, but also be careful that you're not yourself just having a knee-jerk reaction here. A full-fledged ECS can in fact be very helpful when writing game jam style code and you need to quickly iterate on ideas. Separating each unique idea into components (health, movement, ammo) and systems (physics, damage, AI) lets you turn…

If you can quickly iterate with a component system, you can iterate even faster just with regular procedures. Component systems aren’t magic (in fact they introduce friction).

They're definitely not magic, but they're also not just friction on top of regular procedures. They have use cases and used correctly they make a game mechanics into composable and configurable puzzle pieces that are easy to move around. Things that are much more difficult when you write all your game code into a classic run loop.

I think the debate here came down to whether a person who is inexperienced with either strategy for making a game is much more efficient with one thing or another, and I can't say that for sure. But I can say that in my experience the ECS pattern has had benefits for quick prototyping and experimentation, and shouldn't be dismissed out of hand in such a scenario.

Re: 24 Hours of Rust Game Development

#78

Post by afterparty »

alkonaut wrote: post #75
afterparty wrote: post #69

Earlier quoted context omitted.

hi, I'm interested in audio programming. Any tips/advice on a good starting point, etc.

If you are also interested in learning rust (as I am) you'll find an enthusiastic and new "RustDSP" community. I'll mention that rust is young for this (e.g. VST dev), so if you don't want to learn rust but just want to get something finished - then Rust is probably not what you want. It's great for audio programming but the GUI buits are still immature. https://github.com/rust-dsp/rust-vst

thanks! I'll look into it
Post reply on HN