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

Making a Game in Rust

michaelfairley.com

Post reply on HN
Print view View original

101–110 of 125 posts

Re: Making a Game in Rust

#101

Post by barrkel »

Lerc wrote: post #48
steveklabnik wrote: post #44

Earlier quoted context omitted.

It's not a graphical game, but the introductory project in the book has been the "guessing game" for years now https://doc.rust-lang.org/stable/book/guessing-game.html

Yeah, it's the dynamic interactivity that I was looking for. I'm afriad console IO isn't a starter here. I'm sure it's fine as a console IO example, but it's just a completely different class of thing.

Polling the keyboard and using something like ncurses can work. I've implemented console Tetris in an hour using just those tools, and you get to write a game loop, rather than being called back by a framework like most GUI setups.

Re: Making a Game in Rust

#103

Post by lifthrasiir »

frubar wrote: post #97
lifthrasiir wrote: post #90

Earlier quoted context omitted.

Every calculation will have to check for NaN, so it's a non-starter when you need a lot of float calculations.

If the type proved there could be no NaN, why would the check be needed?

0.0 is a finite number that yields NaN when divided by itself. The initial checking is not sufficient.

Re: Making a Game in Rust

#104

Post by lifthrasiir »

yorwba wrote: post #96
lifthrasiir wrote: post #90

Earlier quoted context omitted.

Every calculation will have to check for NaN, so it's a non-starter when you need a lot of float calculations.

The problem was in the context of looking up min_by_key with the key being a floating-point number, so I think the only NaN-check necessary should be for that key. I did not intend to imply that it should be done for all calculations, only those that need totally-ordered floats. (Or if you are really sure NaN will never happen, you leave out the check altogether, and claim total ordering anyway.)

I guess that is a particularly bad use case of specialization, which itself is proposed as an RFC [1] and approved for implementation. It would look pretty similar to, say, C++'s `vector` and `vector` split, because it does something more than what it should do. Probably the better solution is to merge PartialOrd and Ord, as the benefit from having two traits has been always unclear (I personally have no strong opinion against or for that though).

[1] https://github.com/rust-lang/rfcs/blob/master/text/1210-impl...

Re: Making a Game in Rust

#105

Post by douche »

sitkack wrote: post #85
jamescostian wrote: post #27

Earlier quoted context omitted.

Dyon (from that link) looks very cool! I'd also like to add that JavaScript is another language used in this arena, and there is a crate with V8 bindings ( https://crates.io/crates/v8 ). Even Garry Newman (creator of Garry's mod) wrote that he believes JS would have been better than Lua for scripting: https://garry.tv/2014/08/16/i-fell-out-of-love-with-lua/

He even invoked Wadler's Law! It really is too bad that JavaScript is different from Lua. Lua predates it by 2 years. [1] Criticizing a language on syntax is something I would hope we could move past. Mr Newman didn't read about the history and purpose of Lua, otherwise he would know it was targeted at scripting data loads for simulations written in Fortran. Hence the 1 based indexing. Lua syntax is one of its SELLIN…

It's really too bad we don't use Lua in the browser...

Re: Making a Game in Rust

#106

Post by Qwertious »

BatFastard wrote: post #41
0xffff2 wrote: post #37

Earlier quoted context omitted.

Replace "game" with "software", and your post is equally valid.

As long as it is not flash! Some serious flash hating here.

Eh, AFAIK Flash's big problem is the implementation - it's horribly inefficient and insecure etc, but in theory someone could make their own clone of Flash and make a much better version that works well for all that stuff.

Re: Making a Game in Rust

#107

Post by cesarb »

felipemnoa wrote: post #34

This is probably not a popular opinion here in HN but why does it matter what language you use to make your game in? You can use virtually any language to make a game. From my point of view the best language for a game is that which makes you the most productive for cranking out that code. And we all have our own personal preferences about which language is best, which I think is fine, you should code with the one th…

What matters is not "what language you use to make your game", it's "which kind of software you can make with language X". That is, the focus of this article is not the "making a game" part, it's the "in Rust" part. It talks about where Rust helped, and which were the pain points. These are things of interest for Rust developers, in both senses: people using the Rust language, and the ones who develop the Rust language.

Re: Making a Game in Rust

#108

Post by akavel »

talldan wrote: post #98
jamescostian wrote: post #27

Earlier quoted context omitted.

Dyon (from that link) looks very cool! I'd also like to add that JavaScript is another language used in this arena, and there is a crate with V8 bindings ( https://crates.io/crates/v8 ). Even Garry Newman (creator of Garry's mod) wrote that he believes JS would have been better than Lua for scripting: https://garry.tv/2014/08/16/i-fell-out-of-love-with-lua/

Unfortunately, some of those syntax niceties the Garry's mod creator mentioned are things that have been identified as leading causes of bugs. ++ mutates a variable in place, has non-trivial pre/post behaviour (many junior devs don't understand it), and its brevity causes it to be used inline, which results in complex one liners. String concatenation using '+' is not considered to be a great feature in dynamically ty…

As to 'continue', starting with Lua 5.2 you can actually simulate it perfectly with a

  goto continue
and then a

  ::continue::
slapped immediately before the relevant loop's end. Surprisingly, it's not affected by the rule forbidding "going into new variable scope" - because "the scope of any variable ends before 'end', wink wink, nice trick we left here for you no?"

Re: Making a Game in Rust

#109

Post by hawski »

wyldfire wrote: post #6

> The include_* macros are great for “packaging”. Being able to compile small assets directly into the binary and eschewing run time file loading is fantastic for a small game. For C/C++/etc devs looking for something similar, BFD objcopy supports an "-I binary". It will emit an object file with _binary_objfile_start, _binary_objfile_end and _binary_objfile_size symbols. But I have got to say that making it a languag…

There is also an option to use assembler or inline asm. I found quite a nice utility that uses inline asm [0]. It's widely portable and I think that I will use it instead of my naive asm/shell combo that doesn't work with mingw asm.

The problem with objcopy outside of unconvenient usage and naming is that naive objcopy will result in your binary having executable stack [1]. You can change a symbol name, but that's also unconvenient.

Check resulting binary with:

  $ readelf -lW the_binary | grep GNU_STACK
    GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RWE  0x8
  $
Notice: RWE instead RW.

Also: https://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart#H...

[0] https://github.com/graphitemaster/incbin

[1] https://news.ycombinator.com/item?id=10816322#10818085

EDIT:

My shell script - bin2o.sh:

  #!/bin/sh
  set -e
  
  filename="$1"
  name=$(echo "$1" | sed "s/[^A-Za-z0-9]/_/g")
  obj="$2"
  
  echo \
  "	.section .rodata
  	.global ${name}
  	.type ${name}, @object
  	.global ${name}_size
  ${name}:
  	.incbin \"${filename}\"
  1:
  ${name}_size:
  	.int 1b - ${name}
  	.section .note.GNU-stack,\"\",%progbits
  " | gcc -x assembler -c - -o "$obj"

Re: Making a Game in Rust

#110

Post by Sean1708 »

flukus wrote: post #87
Pxtl wrote: post #9

Earlier quoted context omitted.

Agreed. I code in C# and there's facility for bundling assets into the binary but they're handled at the project file level and not the C# file level, and this means the keys to access this binary content is not available as a compile-time constant. You're still just passing strings around and hoping they match. Having first-class language support for resource files looks fantastic.

> and this means the keys to access this binary content is not available as a compile-time constant Isn't that exactly what resource files give you or am I confusing something? Anything you add in resource files have are accessible as a static variable.

It looks like you're right (for C# at least): https://msdn.microsoft.com/en-us/library/7k989cfy(v=vs.90).a...
Post reply on HN