Thanks for this! I want to check the WEB-inspired approaches at some point, this is super useful.
The Markdown one seems interesting too.
I'll probably stick with this for stuff where there's some expectation of drive-by contributions (the tutorial has seen a bunch, it was one of the motivations behind this) because requiring additional tooling can often be a bar that's too high.
Agreed on the general literate programming note. I'm not sure I'll ever pick it up for something that doesn't have an obvious accompanying article/book to come with it, but if I ever write another tutorial or something, I'll definitely use it from the beginning.
But knowing what's out there is definitely important (and AsciiDoctor is extensible so these things could probably be added as plugins).
This comment feels like a bit of a non-sequitor, but I agree. Cogmind is amazing, my own roguelike is quite abstract and a lot of the ones that really gripped me are not yer classic orcs and trolls.
If this is the reaction to the theme in the Rust tutorial that the original post talks about, that's because it's basically a port of the classic Python+libtcod one. It implements the same game, but walks the reader through doing it in Rust.
I (not OP but the author of the article and the Rust tut) wanted to use the same game & structure so folks can compare and contrast. A lot of folks are coming from Python or are familiar with libtcod. Plus it's trained generations of RL devs for better or worse.
If you do want to see roguelike creators experimenting, check out the annual Seven Day Roguelike Challenge[1]. Lots of absolutely amazing stuff keeps coming out of that, including most of my favourites.
For what ever it's worth, anyone looking into starting a roguelike in Rust would probably do much better by folloving the The Bracket link above.
In addition to it being a pure Rust library (which does make a difference when you get started, but also when you try to distribute your game) it compiles to WebAssembly as well meaning you can use the same code to produce a game that runs on the desktop and the web. And the tutorial covers much more ground as well, including ECS for those interested.
And finally, both the tutorial and tcod-rs are barely maintained anymore. I try to address questions/fix serious issues from time to time, but the chances of this seeing any significant developments in the future are very slim. The RLTK stuff is actively maintained and developed.
(I'm not the OP, but I did write the linked post, the tutorial -- which is based on the classic Python+libtcod one as well as started tcod-rs)
I was about to say a similar thing. Yes, in a CS-sense anything you can do in one Turing-complete language you can do in any other Turing-complete lang. They almost certainly were not disputing that.
If you factor in the real world, the number shrinks as you get to things like performance, cross-platform support, ease of packaging and distribution.
But still, Nu could plausibly have been written in Assembly, C, C++, D, Go, Nim, Zig, Haskell and so on.
You would have lost some of Rust's strengths and weaknesses and imported another set (regarding the language, tooling, performance, ease of debugging and so on).
I took the comment to mean that as far as they (all people intimately familiar with the language, tooling and ecosystem) are concerned, this would be a trade-off that would be negative enough to not begin or finish the project in the first place.
I don't know what plans and requirements the Nu authors had. But for my own game (a roguelike written in Rust) the requirements on the performance, distribution, stability, ease of development and dependency management meant that Rust was (at the time) pretty much the only viable choice for me.
Could someone have written it in C? Sure. Could I have written it in C? Likely, yes. Would I have ever finish the game in C? Almost certainly no. For various reasons none of the other languages would have done in those circumstances, not really.
Human language is an imperfect method for transferring information and sometimes one trades off brevity for nuance.
(disclaimer: not a physicist, never looked into the maths, but I'm intrigued by QF)
There are deterministic interpretations that are very much on the table.
The Everett's Many Worlds[1] is fully deterministic (and depending on your view, the simplest one too): the universe is a quantum wave function evolving according to the Shrödinger's equation. That's it.
A lot (if not all) of the hidden variables theories are also deterministic. The apparent non-determinism stems from the aforementioned variables that we don't/can't see.
I keep hearing more and more about the Pilot wave theory[2] recently. And that's a hidden-variables deterministic interpretation.
Yes, and harassers - including stalkers - take advantage of the fuzziness. Including by using terms like "just hitting on" for something which is much better described as "harassment".
Having them side by side, you can see that they contain the same vertical amount of space. Inconsolata's glyphs are smaller, but they're still in the box of the same height.
It does seem that the "font size" only refers to the height, though. The width is clearly variable.
To anyone who actually understands this properly: is the above correct or is that just an artefact of how the website renders the text?
A font’s dimensions at a given “font-size” are actually completely up to the designer. Something like x-height can only be determined by rendering and then measuring. Editors tend to be full of character measuring code. x-height also doesn’t say anything about the length of descenders and ascenders. Some fonts are exactly the same size though, there a bunch of variations of Courier to be used as a replacement (for licensing reasons). If they’re not designed to the same dimensions you cannot be sure text will fit on the page with the other font. And if they’re the same size they can still look larger or smaller by a wide margin. It’s a wonderful world :)
What you’re noticing is the variation in “x-height”, that is, the height of the middle part of the lowercase letterforms, not counting ascenders/descenders.
Width can always vary. Combinations of greater width and x-height make the letters look bigger.
At least, that’s the way I’ve always understood it.
(disclaimer: I work at Red Hat, not on any OS/distro)
This is a nitpick, but Red Hat did not get bought by IBM. What happened was IBM announcing the intention to buy Red Hat.
It's maybe a subtle, but possibly important distinction. Red Hat is still its own independent entity until the deal goes through (which means IIRC passing the board's approval, SEC and likely other stuff). This is expected to happen in late 2019 I believe, but it might still fall through.
This doesn't absolutely dispel any possibility of IBM's influence, but it should be very low/zero until the merger actually goes through. But I also don't know how all this works.
