Great stuff, lines up a lot with what I'd care about as an ex-gamedev and spending a bit of time with Rust. One minor point:<p>> First class code hot-loading support would be a huge boon for game developers. The majority of game code is not particularly amenable to automated testing, and lots of iteration is done by playing the game itself to observe changes. I’ve got something hacked up with dylib reloading, but it requires plenty of per-project boilerplate and some additional shenanigans to disable it in production builds.<p>Lua is a great fit here and interops with Rust(and just about everything else) very well.
I largely echo the sentiment of using Rust for game development. The world doesn't need another Flappy Bird clone but that's what I wrote because I ended up porting a Go version that was using SDL originally by Francesc Campoy from the Golang team: <a href="https://github.com/campoy/flappy-gopher" rel="nofollow">https://github.com/campoy/flappy-gopher</a><p>I was able to build the Rust version fast, and the SDL library is actually quite usable/stable for most things.<p>Flappy-Rust has particle effects, the beginnings of parallax-scrolling and basic collision detection. The rust code ended up being pretty reasonable however I'm quite sure there are a few places I could have simplified the sharing of assets.<p>If anyone is interested in this space check out my repo: <a href="https://github.com/deckarep/flappy-rust" rel="nofollow">https://github.com/deckarep/flappy-rust</a><p>Also please see the README.md where I talk a bit more in-depth about how the Rust version differs from the Go version.<p>Here is a .gif preview of the first iteration of the game: <a href="https://github.com/deckarep/flappy-rust/blob/master/flappy-rust.gif" rel="nofollow">https://github.com/deckarep/flappy-rust/blob/master/flappy-r...</a>
It would be nice to have a minimal gameish program as a example for people learning Rust.<p>When I teach kids javascript I start with an etch-a-sketch. It's aided by a simple library to hide the mechanics of the HTML canvas element, context, etc. This allows it to be small enough that they can view it all in one go and build upon it.<p><pre><code> print("Draw with the arrow keys");
var cx=320;
var cy=240;
function update() {
// the arrow keys have key codes 37,38,39 and 40
if (keyIsDown(38)) { cy-=1; }
if (keyIsDown(40)) { cy+=1; }
if (keyIsDown(37)) { cx-=1; }
if (keyIsDown(39)) { cx+=1; }
fillCircle(cx,cy,6);
}
run(update);
</code></pre>
There might be merit in writing one of these in every language (and a companion that uses the mouse), maybe placing it on github . With a really simple program like this you can focus on learning the language while making something. It's a tough job figuring out how to learn a language while simultaneoulsy learning how to write the boilerplate needed to get something onscreen.
> 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.<p>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.<p>But I have got to say that making it a language feature means that Rust is truly a batteries included language.
I wasn't even aware that you were allowed to ship Rust code in iOS apps, I thought that Apple had a whitelist of allowed languages?<p>EDIT: And for those interested, you might want to check out Rust's recent inclusion in a AAA title: <a href="https://www.reddit.com/r/rust/comments/69s225/rust_makes_it_into_a_aaa_video_game_as_an_art/" rel="nofollow">https://www.reddit.com/r/rust/comments/69s225/rust_makes_it_...</a> :P
> I had two or three false-start attempts at learning Rust where I’d spend a few hours with it, not get anything done, and put it down until a few months later<p>This sounds (sort of) encouraging. I was kind of expecting to learn it by putting in an hour here and there e.g. 2-4h/month. But I'm beginning to think that might not cut it...
Neat! I was just complaining about the lack of multiplatform Rust games proving out the concept. If only there were some consoles or handhelds on the list... although iOS/Android being on the list is somewhat encouraging.
About floats implementing <i>PartialOrd</i> and not <i>Ord</i>:<p>I have not tried out Rust yet, but couldn't this be solved by wrapping the float in a single-field struct that checks for NaN on construction, implements <i>Ord</i> using <i>PartialOrd</i> and otherwise passes everything through to the ordinary float inside?<p>If this isn't possible, I'm definitely interested in the reasons.
The performance on my Android phone (Nexus 6) is not good. I would have thought Rust would be fast. The fps is fairly low, a lot lower than Maps or Chrome, at least when Maps isn't freezing up. And it seems the transitions between levels might be proportional to fps, because they are irritatingly long.
It is an interesting educational project but staying away from Unreal or Unity3D is really a tough decision if your project is going to need some more features that are already developed and well tested in one of these engines.
Great writeup. Eye opening that you can actually write iOS apps with rust. w00t, totally trying this for my next app. (It's a bit overly bit expensive for my liking but otherwise I would have given your game a shot).
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 that you feel most productive with. At the end of the day users will not be able to tell the difference. All that matters is whether your game is fun or not.