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

Are we game yet? – A guide to the Rust game development ecosystem

arewegameyet.rs

Post reply on HN
Print view View original

101–110 of 139 posts

Re: Are we game yet? – A guide to the Rust game development ecosystem

#101

Post by bluejekyll »

slmjkdbtl wrote: post #66
bluejekyll wrote: post #43

Earlier quoted context omitted.

You might want to look at bevy, there are some great tutorials available for it: https://bevyengine.org/

ECS is not for beginners who just want to get a quick game out, or anyone who has <500 entities in a scene

Since no one has directly said it, I think bevy hides a significant amount of the ECS from the developer in a really elegant way.

I agree with Weebs assessment as well. But in particular, bevy has an extremely simple ECS api.

(Though, I will admit, I’ve only dabbled in this space and mainly followed some tutorials, so your mileage may vary)

Re: Are we game yet? – A guide to the Rust game development ecosystem

#102

Post by slmjkdbtl »

helicalspiral wrote: post #90
slmjkdbtl wrote: post #68

Earlier quoted context omitted.

If you want to experience the high level game dev fun, DON'T use Rust, I recommend look at - love2d ( https://love2d.org/ ) - PICO-8 ( https://www.lexaloffle.com/pico-8.php ) - Clickteam Fusion ( https://www.clickteam.com/clickteam-fusion-2-5 ) - Godot ( https://godotengine.org/ ) - Stencyl ( http://www.stencyl.com/ ) - pygame ( https://www.pygame.org/ )

There's also https://github.com/ggez/ggez for Rust specifically.

Writing high level game logic in Rust is not fun, you spend more time waiting for compilation and dealing with language problems than real game dev fun.

Re: Are we game yet? – A guide to the Rust game development ecosystem

#103

Post by pjungwir »

throwaway894345 wrote: post #40

Are there any resources for developing 2D game graphics, especially for hobbyists? It seems like game development articles focus so much on frameworks and just assume everyone knows where to find / how to make graphics, audio, etc. I would be especially interested in a high level "how to make a game" that didn't go so in-depth into the programming details but which did include procuring the assets and perhaps some st…

The book Game Engine Architecture by Jason Gregory might be more detailed than you'd like, but it still covers a lot of those issues (for both 2D and 3D). As a programmer-but-not-a-game-programmer, I was fascinated to read about the different modules within a game and how they interact. Before reading, if I ever did write a game, I probably would have ignored the "don't write your own engine" advice. Maybe I still would. :-) But at least I have a taste of the awesome amount an engine gives you.

Re: Are we game yet? – A guide to the Rust game development ecosystem

#104

Post by jkarneges »

anchpop wrote: post #93
throwaway894345 wrote: post #40

Are there any resources for developing 2D game graphics, especially for hobbyists? It seems like game development articles focus so much on frameworks and just assume everyone knows where to find / how to make graphics, audio, etc. I would be especially interested in a high level "how to make a game" that didn't go so in-depth into the programming details but which did include procuring the assets and perhaps some st…

> Also, even the general approach for game development--presumably there's some white boarding phase followed by a wireframe phase etc like you have with app dev? What does that look like in game dev land, what are some reasonable tools for hobbyists for each stage, etc? If you're interested in learning more about this, I can't recommend enough The Art of Game Design: A Book of Lenses. The gist is that it's hard to m…

> it's hard to make an actually fun game

A zillion years ago I used to do hobby games as a solo dev, and it took me a long time to understand this. I was always interested in game engine elements (sprites, tilemaps, input, menus, audio, pathfinding, etc), and I could put those elements together to make halfway decent games (usually by copying existing genres). But assembling those elements is a skill of its own, and this is easy to overlook if you're a programmer who thinks programming is the only challenge to making a game (or making anything :)).

I didn't truly appreciate game design as a skill until I worked with a separate game designer on a project. He made decisions on things that would have never crossed my mind. From that point on, I started seeing game design everywhere. Notably, I started seeing it in older games, ones I had played many times and that inspired me to get into game dev in the first place. I hadn't realized how well thought out the classics were.

Re: Are we game yet? – A guide to the Rust game development ecosystem

#105

Post by gpm »

whateveracct wrote: post #57
ibraheemdev wrote: post #37

Earlier quoted context omitted.

Yup: https://docs.rs/typed_arena

That just has allocation, but no way to reset the arena & reclaim its memory. But then again, you'd have to make it so no allocations from the arena are alive & in use when you reset the arena. Definitely a downside :/ On a side-note: I'm fairly sure the ST trick + -XLinearTypes will allow a better & still type-safe arena allocator to be written in Haskell than is currently possible in Rust.

> but no way to reset the arena & reclaim its memory. But then again, you'd have to make it so no allocations from the arena are alive & in use when you reset the arena

Looks like that implementation doesn't, but the borrow checker can definitely specify that sort of constraint (it looks `fn foo(self) -> Self`). I think it's not exposed because the code assumes that all but the last chunk are completely filled - but it could also just be that no one asked for that.

Re: Are we game yet? – A guide to the Rust game development ecosystem

#106

Post by spartanatreyu »

slmjkdbtl wrote: post #102
helicalspiral wrote: post #90

Earlier quoted context omitted.

There's also https://github.com/ggez/ggez for Rust specifically.

Writing high level game logic in Rust is not fun, you spend more time waiting for compilation and dealing with language problems than real game dev fun.

Rust doesn't have to be slow, look at the Bevy engine for example

Re: Are we game yet? – A guide to the Rust game development ecosystem

#107

Post by pornel »

slmjkdbtl wrote: post #66
bluejekyll wrote: post #43

Earlier quoted context omitted.

You might want to look at bevy, there are some great tutorials available for it: https://bevyengine.org/

ECS is not for beginners who just want to get a quick game out, or anyone who has <500 entities in a scene

The basic OOP solution relies on mutable aliasing being available, where any entity can reference any other entity.

Rust won't let you have arbitrary mutable aliasing or risk dangling pointers, so you'd end up fighting the language. In Rust ECS is actually easier, and it's a better fit for the single ownership, shared XOR mutable model.

Re: Are we game yet? – A guide to the Rust game development ecosystem

#108

Post by slmjkdbtl »

pornel wrote: post #107
slmjkdbtl wrote: post #66

Earlier quoted context omitted.

ECS is not for beginners who just want to get a quick game out, or anyone who has <500 entities in a scene

The basic OOP solution relies on mutable aliasing being available, where any entity can reference any other entity. Rust won't let you have arbitrary mutable aliasing or risk dangling pointers, so you'd end up fighting the language. In Rust ECS is actually easier, and it's a better fit for the single ownership, shared XOR mutable model.

That's also why I don't recommend Rust for game dev beginners, I think the most important thing for beginner is to experience the fun of game dev, which is making game logic and making the actual game, even if you go Rust with ECS, you'll still spend most of the time learning ECS, solving compile errors and waiting compilation, stuff that does not have any game dev fun.

Re: Are we game yet? – A guide to the Rust game development ecosystem

#109

Post by pornel »

whateveracct wrote: post #57
ibraheemdev wrote: post #37

Earlier quoted context omitted.

Yup: https://docs.rs/typed_arena

That just has allocation, but no way to reset the arena & reclaim its memory. But then again, you'd have to make it so no allocations from the arena are alive & in use when you reset the arena. Definitely a downside :/ On a side-note: I'm fairly sure the ST trick + -XLinearTypes will allow a better & still type-safe arena allocator to be written in Haskell than is currently possible in Rust.

Borrows are scope based, so if you limit arena usage to a scope (e.g. inside your frame loop), then it should be fairly trivial to reset it.

Reclaiming should theoretically be possible too via a method that takes ownership of the arena (the borrow checker prevents moves while an object is borrowed).

Re: Are we game yet? – A guide to the Rust game development ecosystem

#110

Post by meheleventyone »

adwn wrote: post #34
indy wrote: post #30

Earlier quoted context omitted.

An issue that Jonathan Blow had was that one of the touted benefits of Rust is it's ownership semantics, yet the ECS (Entity Component System) that the talk demonstrated was effectively bypassing that.

> ownership semantics, yet the ECS (Entity Component System) that the talk demonstrated was effectively bypassing that. I don't see how that's the case [1]. The entities are owned by the ECS (or the game state, or whatever), not by each other. Entities can conceptually reference each other, but not own each other. The only time this is problematic, is when one entity is destroyed while another one is still holding a…

Yeah the confusion comes because entities are no longer a concrete element of the program but a concept tying components together. It’s just as valid to look at a subset of the components that are referenced by an entity id as a view as it is to look at them all. Like a relational database.

And by breaking things into components the granularity of ownership is increased compared with the equivalent concrete representation of the same data. So whilst you can’t reason about ownership of an entity as it primarily exists conceptually the ownership of its constituent parts is well defined.

Post reply on HN