24 Hours of Rust Game Development • Hacker News Board

Re: 24 Hours of Rust Game Development

#31

Post by nine_k » Tue, Mar 05, 2019, 3:37 AM UTC

Impossible wrote: post #25

whatshisface wrote: post #17

Earlier quoted context omitted.

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

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 cou…

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.

Re: 24 Hours of Rust Game Development

#32

Post by keyle » Tue, Mar 05, 2019, 3:42 AM UTC

dyarosla wrote: post #30

keithnz wrote: post #28

Earlier quoted context omitted.

100% of my game programming is mulling over a framework to use

You’re doing it wrong then. It should be 100% spent on building your own framework. What game??

Thank you guys you gave me a genuine big laugh. That said game programming is extremely hard. Probably the hardest IT field imho, so send my regards to all my fellow procrastinators.

Re: 24 Hours of Rust Game Development

#33

Post by cheez » Tue, Mar 05, 2019, 4:10 AM UTC

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…

Ah you are my hero for saying this, given that it comes from you.

Re: 24 Hours of Rust Game Development

#34

Post by [deleted] » Tue, Mar 05, 2019, 4:11 AM UTC

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.

[deleted]

Re: 24 Hours of Rust Game Development

#35

Post by jorgeavaldez » Tue, Mar 05, 2019, 4:23 AM UTC

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…

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 itself to the technology. It also helps in preparing me to find those applications with a better understanding of the costs and semantics. While the knowledge may not be used for a practical purpose, at the end of the day, I learn something new, and I have a new way of looking at problems and understanding how to solve them with fresh perspective.

Re: 24 Hours of Rust Game Development

#36

Post by sbov » Tue, Mar 05, 2019, 4:42 AM UTC

dyarosla wrote: post #30

keithnz wrote: post #28

Earlier quoted context omitted.

100% of my game programming is mulling over a framework to use

You’re doing it wrong then. It should be 100% spent on building your own framework. What game??

The python network library Twisted was originally written for a game they wanted to program. They never ended up writing the game.

Re: 24 Hours of Rust Game Development

#37

Post by the_duke » Tue, Mar 05, 2019, 6:36 AM UTC

whatshisface wrote: post #23

reificator wrote: post #8

Earlier quoted context omitted.

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

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

Well deserved upvote.

Re: 24 Hours of Rust Game Development

#38

Post by TeMPOraL » Tue, Mar 05, 2019, 8:05 AM UTC

tenaciousDaniel wrote: post #3

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.

The challenge is gathering consensus on how to pronounce it :p

"Oh Jeez", Morty-style.

Re: 24 Hours of Rust Game Development

#39

Post by mtzet » Tue, Mar 05, 2019, 8:49 AM UTC

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 where all the data is just available.

There are scant few sources for learning this, Handmade Hero being a notable exception.

Re: 24 Hours of Rust Game Development

#40

Post by atoav » Tue, Mar 05, 2019, 8:51 AM UTC

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 complex. But where the real difference showed up was when I tried to extend: in the first thing I basically had to have all the code in my head, in the second I could just inherit from the Scene Class and make a new one with completely new rules.

If I were to do something now I would give a ECS a go, especially in Rust which really lends itself to ECS. I don’t think a ECS is any more complicated than relying on Object orientation. The problems you will have to solve with OOP will get incredibly hairy incredibly fast and I say that as someone who came to Rust from a OOP background.

Of course you can just use my first approach and write a huge loop with a lot of if else clauses and deal with every new thing in a new way.

This is the way I’d recommend it to a real beginner, who cares about pixels on the screen and doesn’t mind if they have to rewrite half of the code if they want to change or add a tiny detail.