Roguelike Tutorial: Up-to-Date and Literate | Hacker News Reader

Roguelike Tutorial: Up-to-Date and Literate

aimlesslygoingforward.com

165 pointsluu26 comments

If you are interested in both roguelikes and rust, there's an embarrassment of riches for tutorials.

In addition to the (very good!) tutorial on the OP by Tomas Sedovic, I wanted to mention the rust roguelike tutorial by Herbert Wolverson / The Bracket:

http://bfnightly.bracketproductions.com/rustbook/

The main difference is that on this case they use rltk_rs, a pure-rust library for roguelike development, instead of libtcod. It is also way, way longer.

I don't know how/if Hervert has even attempted at solving the issues mentioned by Tomas with regards to repetition / code generation and literate programming.

Oh this meets my interests very much. I was considering spending some time with rust during my Christmas vacation and this seems like a good candidate for leveling up my rust skills. Thanks for the link!

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've been looking for some more examples of using the Specs project, thanks!

The bfnightly tutorial is a very good tutorial, but I do want to warn that it's not always terribly idiomatic Rust: Herbert was using the writing of the tutorial as a way of practicing Rust, so there are places where the explanations aren't quite correct and other places where the code isn't what an experienced Rust programmer would write. An example that jumped out at me (this from Chapter 8) was the use of

    &s.to_string()

which is an expression that could be shortened to just s. (Specifically, s has type &str, calling to_string() on it converts it to a String, and borrowing it allows it to be coerced back to a &str but now with unnecessary copying.) Elsewhere (this from Chapter 3) it has explanations like

> Copy and Clone allow this [type] to be used as a "value" type (that is, it just passes around the value instead of pointers)

which is also not a correct explanation, or at least is a misleading one: things can still be passed by value even without Copy and Clone and without any pointers at all. (Arguably, he meant, "You can share the value without using borrows," but that's not what the explanation said.)

That said, all this is nitpicky (and I suspect that Herbert would be receptive to feedback along these lines—I just haven't had a chance yet to provide it!) because the tutorial's explanation of roguelike-writing is still very good, and in fact I've been following it as a guide for writing a tutorial on top of a different Rust library myself! But I do want to warn about using it as a model for learning Rust specifically.

My understanding is that the only reason for example literals can be passed without borrows is because in fact they are Copy

If you're interested in the technical aspects of roguelikes, such as map generation and simulation, I recommend checking out the articles at roguebasin: http://www.roguebasin.com/index.php?title=Articles

I recently finished the tutorial[0] as well, mostly to re-teach myself Python, and I'm planning to have a lot of fun rewriting it in C and Lua sometime next year. Roguelikes, both technically and as a genre, are probably right up HN's alley.

Also I'd recommend the subreddit[1] to anyone interested.

[0]http://www.roguebasin.com/index.php?title=Complete_Roguelike...

[1]https://old.reddit.com/r/roguelikedev/

The developer diaries for Cogmind are also a treat: https://www.gridsagegames.com/cogmind/

They so made me want to create a roguelike. And I had never even played one before.

On the topic of game dev diaries, Factorio's devs have been making some of the best weekly posts in the industry: https://factorio.com/blog/

Roguelike creators need to experiment a bit more with different themes and different core mechanics to make gameplayore interesting and diverse.

> High Fantasy is the vanilla ice cream of video game themes

https://www.goldenkronehotel.com/wp/2018/08/01/things-i-hate...

> We have lots and lots of fantasy dungeon crawlers, so naturally if you want to really distinguish your project, go for any unique theme that’s not a fantasy dungeon crawler.

https://www.gridsagegames.com/blog/2018/10/how-to-make-a-rog...

https://www.gridsagegames.com/blog/gsg-content/uploads/2018/...

For commercial roguelikes, sure, but the roguelike community overall really is a hobbyist community. It mostly seems to consist of developers who have come to the realization that while CRUD and web apps have been a good way to pay the mortgage, the real reason they got into computers in the first place was to play D&D.

Might as well make the game you want to play, because chances are the game you want to sell, won't.

Cogmind is a good example of a roguelike which took a different direction thematically and aesthetically and it seems to have worked out well for them.

Go too far and you end up drawing the ire of the roguelike purists, for calling your game roguelike. Unfortunate reality. Roguelite has different overarching connotations as well, so it's a bit polarizing.

I'm surprised the context is always fantasy instead of sci fi, given the games are inherently tech dependent.

Historical reasons mostly, but also fantasy is a lot easier. You don't have to pretend to be realistic. That said, if fantasy is vanilla then sci-fi is chocolate.

>Historical reasons mostly, but also fantasy is a lot easier. You don't have to pretend to be realistic.

I know what you mean to say but good fantasy tries as hard to be "realistic" (in terms of plausibility and internal consistency) as good science fiction.

Although in terms of providing recognizable game mechanics that resonate with a genre, fantasy is definitely easier thanks to the influence of D&D.

rogue, and most of its descendants, are really just a computer-implementation of DnD/ADnD -- particularly focusing on the combat mechanics.

This is also where most of the core mechanics come from -- dungeoneering, permadeath, the lack of interest in keeping your character alive & the lack of interest in things like backstory and what-not, the general weapon mechanics (eg [+1, +2] for accuracy, damage bonus) and combat rules, etc.

In this context, anything but fantasy would be surprising

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.

[1]: http://www.roguebasin.com/index.php?title=Seven_Day_Roguelik...

this literate programming is really cool. Thinking about the caveats at the end, I wonder if anyone's ever implemented something like this on top of git or similar? seems like the iterations of the evolving code across the tutorial could be mapped to commits or branches

Where's the actual game?!

The link to the tutorial and its repo is linked at the top of the article:

http://tomassedovic.github.io/roguelike-tutorial/

https://github.com/tomassedovic/roguelike-tutorial

There are no official builds you can download since this is something you're supposed to read and follow along, building your own game in the process.

I have made my own "proper" roguelike (moved away from libtocd, but kept Rust) but that was unrelated to the post.

(I'm the author of the article, but not the OP)

> And I'm also unsure whether he needs to build the list of include statements like I do or whether that's somehow captured in the annotation itself.

> the workflow could be better. In the example above, we had to define the function body, prelude, if statement, else statement and both if/else blocks.

> It would be much better if we could inverse this: defining the whole function block with holes for the if/else blocks that the code generation would put in.

The original CWEB and newer NOWEB do handle these things a bit better - sections can be defined and included in any order, and sections can define which file their in.

It lends itself particularly well to laying out a program "top down", ie:

We define the utility ctof as consisting of a c file: ctof.c.

It has the following structure:

standard header includes

defining constants for conversion

defining the function ctof that converts a float value of degrees Celsius to Fahrenheit, returning a float

A help procedure that prints help

A main function that parses command line parameters, and conditionally call the help procedure or ctof function... Etc

Then can go on to define the inner bit of ctof first (the calculation).

In general literate programming is very nice. It can be a bit of a challenge when breaking out small sections (we define a loop that iterates over an array like so...) - because of scoping issues - if the programming language discourages many small (max 10 lines) functions/procedures.

At that point the literate system itself takes on the role of a macro assembler of sorts - which can work with old school "structured programming" - short programs, well defined global state (a few array/lists, a few "in" and "out" global variables).

See eg: http://literateprogramming.com/cweb_download.html (historic relevance)

http://leoeditor.com/ (not sure if it's alive - an interesting idea in "all literate, all the time"

https://www.cs.tufts.edu/~nr/noweb/ modern-ish take on literate programming - if you want LaTeX for the document part

Finally, the most pragmatic variant I'm aware of - literate markdown tangle - which might be close enough to what's in op to encourage a port:

https://github.com/driusan/lmt/blob/master/README.md

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

Reply on news.ycombinator.com