
24 Hours of Rust Game Development - oliviff
http://iolivia.me/posts/24-hours-of-rust-game-dev/
======
jblow
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 is just overengineering + procrastination in almost
all cases.

(None of my games have ever had anything as complicated as a component
system).

If you want to make a simple game like this, just sit down and program it in
the obvious way. It will work. You don't need to be fancy.

~~~
whatshisface
> _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.

~~~
Impossible
For a simple game it seems like you could get away with vectors of mutable
structs. This looks like ECS where one entity has a single component and there
are only a few systems that update them (update, draw). For simple games you
can do the old-school arcade style model with memory allocated upfront for
everything (giant mutable gamestate struct) which was called out as not
scalable in the talk but it worked for countless classic console and arcade
games and scales all the way to Call of Duty. Another option is to avoid
mutation and go for a functional style where you return a new game state
struct after update (drawing probably shouldn't need to mutate), which might
not scale for large games but is completely reasonable for small games without
much state.

~~~
nine_k
I suppose you can have a giant game state and return a new immutable copy on
every frame if the amount of _change_ is small, and you reuse most of the
unchanged state.

------
jops
Only partially related to the post topic, but this rust game project is worth
checking out -
[https://github.com/citybound/citybound](https://github.com/citybound/citybound)

------
jabagawee
Title seems to have been changed to meet the following rule:

> If the original title begins with a number or number + gratuitous adjective,
> we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to
> "How To Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is
> meaningful, e.g. "The 5 Platonic Solids."

However, I believe the "24" in "24 Hours of Rust Game Development" is pretty
crucial.

~~~
dang
Yup, we've added 24 back.

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

~~~
reificator
The trouble is, `gg` means `good game` and `ez` means `easy`. But `ggez` means
`you suck and I'm better than you`.

~~~
whatshisface
I'd have to look up the error code to be sure but I think the borrow checker
emits that one occasionally.

~~~
the_duke
Well deserved upvote.

------
Calashle0202
While working through your experience with Rust, would you mind writing down
(doesn't have to be more than a couple of words and maybe a code snippet)
diagnostic errors that were hard to understand or that were misleading? That
feedback is invaluable in making rustc friendlier.

