22 ms·

Roguelike Tutorial in Rust (2019)

327 points by wsc981 4y ago

graboid 4y ago
Holy cow, that's amazing. And it is so extensive. Thanks a lot for the link.
fredrikholm 4y ago
I used this to learn Rust (after `book`), highly recommended!
Winsaucerer 4y ago
I started working through this, except to make things difficult for myself I used Godot for drawing everything, via https://github.com/godot-rust/godot-rust https://github.com/godot-rust/godot-rust. I only got to about halfway through section 2, but I think it was going well.
hiyer 4y ago
Medium subscribers can read an HTML version of this book for free here - https://medium.com/pragmatic-programmers/table-of-contents-197f27b96b7b https://medium.com/pragmatic-programmers/table-of-contents-1...
- deleted 4y ago
  [deleted]
CGamesPlay 4y ago
Man, this Specs [0] library is so strange to me, coming from a Unity background. Is there some sort of comparison as to why one way is better than the other? [0] https://docs.rs/specs https://docs.rs/specs
- nextaccountic 4y ago
  Maybe you would like Bevy's ECS more? https://bevyengine.org/learn/book/getting-started/ecs/ https://bevyengine.org/learn/book/getting-started/ecs/ (it's a later design that incorporated some improvements, like, you don't need to define a struct and impl a trait to define a system)
  - dymk 4y ago
    Bevy's ECS is incredibly ergonomic and makes writing ECS code fun. You give Bevy a function and it automagically turns it into a system by doing dependency injection. No need to write an impl for it, the system takes care of that for you. It makes prototyping very fun, as it's cheap to experiment with different system configurations.
- jakkos 4y ago
  If you mean a comparison between SPECS' paradigm, ECS, and Unity's mix of OOP/composition, the main benefit of ECS is performance. The way ECS loops over arrays of data means that the memory accesses it makes are nearly always already in cache. Games spend a surprisingly large amount of time just waiting to receive values from memory. In the right circumstances, normally when dealing with huge numbers of objects (think simulation games), ECS can be entire orders of magnitude faster. Other than that some people just prefer coding in ECS. Unity has been developing its own separate ECS framework for a while now.
- pornel 4y ago
  It is a very different and seemingly weird approach. It's almost like writing SQL queries for your game world (e.g. "find all entities with a Flying component and attach them a WooshSound component). A clever memory layout makes these queries super fast. It makes separation of concerns very natural. Different parts/layers of the game, like inputs, AI, sounds, graphics, effects and animations can be coded separately. You don't end up with "god class" for player's object that does a bit of everything. You have player entity that has components attached, and each system operates on its own set of components. I can't really do it justice in a comment. It's a quite different approach, so it's not directly comparable. It's like OOP vs Rust's traits. ECS happens to match Rust's memory model and traits incredibly well. Here's a more in-depth talk about this: https://www.youtube.com/watch?v=aKLntZcp27M https://www.youtube.com/watch?v=aKLntZcp27M
  - wdroz 4y ago
    Even the Data-oriented design[0] is eyes opening (which is part of the ECS). The classic example is[1]: Instead of having a list of structs, where each struct get some types (int, float, ...), you use one struct, where the fields are list of types (array of int, array of floats, ...) [0] -- https://en.wikipedia.org/wiki/Data-oriented_design https://en.wikipedia.org/wiki/Data-oriented_design [1] -- https://en.wikipedia.org/wiki/AoS_and_SoA https://en.wikipedia.org/wiki/AoS_and_SoA
    - kramerger 4y ago
      Unity uses ECS, just in a more visual way.
      - wdroz 4y ago
        I did some Unity3d back in 2013, I don't remember using ECS (intentionally?). After a quick search, it's seem that the MonoBehaviour are the old way and ECS the new ways? That's nice.
        kramerger 4y ago
- bodge5000 4y ago
  ECS is an absolute pain to work with and makes everything so much slower...until it clicks. In the past I've compared it to learning programming all over again. The SQL reply summed it up quite nicely, basically you perform queries for anything with a class attached and then perform your operations on all of those. It sounds really inefficient, but in terms of raw performance the results usually speak for themselves. A good example I encountered with Bevy, another Rust ECS framework, is imagine you want your camera to follow your player. Rather than having a script on your camera and a different one on your player, you could just attach a generic class to both, query through anything with that class and update the position of it based on the input.
suby 4y ago
75 comment discussion here from 2020 https://news.ycombinator.com/item?id=22020229 https://news.ycombinator.com/item?id=22020229
sanjayts 4y ago
What's the relation between this tutorial and the "hands on rust" book? Overlapping content or contains bits and pieces from the book?
m4nu3l 4y ago
I'm currently using Godot 3 for my solo indie project. It's a six-degrees of freedom space shooter. I use rigid bodies and physics very extensively, but what have proved to be very hard-to-remove bottlenecks were the scene tree and scripts. At some point the game was spending more time on those things that on the physics simulation. I have rewritten some code in C++ over time and parallelized as much as I can. However I'm starting to think that scripting languages are a false economy. There is no intrinsic reason you can't have a concise and easy to use language that can be quickly (in debug mode) compiled to the metal and dynamically linked to the project. I might look at godot-rust at some point although It's a bit late considering the amount of code I have written already.
- medo-bear 4y ago
  > However I'm starting to think that scripting languages are a false economy. There is no intrinsic reason you can't have a concise and easy to use language that can be quickly (in debug mode) compiled to the metal and dynamically linked to the project. This might interest you: * https://reader.tymoon.eu/article/413 https://reader.tymoon.eu/article/413 * https://github.com/Shinmera/talks/blob/master/gic2021-highly-dynamic/paper.pdf https://github.com/Shinmera/talks/blob/master/gic2021-highly... and the very recent still front-page discussion on hn: * https://news.ycombinator.com/item?id=32043026 https://news.ycombinator.com/item?id=32043026
- krapp 4y ago
  >However I'm starting to think that scripting languages are a false economy. This is likely more an indictment of Godot's 3D capabilities or GDScript than scripting languages as a whole.
  - m4nu3l 4y ago
    No, not really. It's not about the 3D capabilities (I have different types of issues there) or about GDScript per se (other scripting languages have even worse issues like the GIL in Python), but the issue I had is that a lot of time was spent doing these: - Counting references. - Variant related conversions. - Resolving methods. - Interpreting the bytecode. - Sorting nodes before calling update functions. - Triggering callbacks etc. All of these would amount to a good percentage of the time spent in the main thread. I managed to optimize by a combination of parallelism (gladly GDScript has no GIL!) and by rewriting somethings in C++. I still have some bottlenecks with the rendering but that should be easier to scale back.
bodge5000 4y ago
Maybe a good place to ask, does anyone have any recommendations for game dev frameworks? Preferably something performant, stable and not too much of a pain to work with. Been using Godot for a year or two and loving it, but I do want to try out the code only workflow, I feel like it'd suit me better being freed of the constraints of an engine, but I'd at very least like to try so I can be sure. I tried Bevy before and it was fantastic, but its just not production ready. Also tried Raylib, the main problem with that being the sheer number of bindings somewhat segments the community and makes it harder to figure out how to start off with, but it might be worth another go. Might also consider going without a framework and just finding libraries to fill in what I need, but that might not play nice with "not too much of a pain to work with"
- krapp 4y ago
  May be more lower level than what you're looking for but my current drug of choice when I want to write all the code is SDL2 and LuaJIT in Visual Studio.
  - bodge5000 4y ago
    SDL2 I've been heavily tempted by, but it has a similar problem as Raylib where everyones writing it in a different language. Great when you know what your doing, but a bit more difficult to get up and started with. But maybe it is worth that extra time investment just for how popular and battle-tested it is
- pizza234 4y ago
  In Rust, there is none; they're just not ready, and not used either (there are very few full games written in Rust). The Bevy maintainers in particular give very low priority to foundational functionalities (see 1 frame lag and the unusable stages+states), and focus on advanced ones instead. There aren't so many alternatives actually (SDL is a very valid framework, but it isn't a game engine), and the choice depends on what's your real goal (experiment or develop a real game). In my opinion, if the goal is to produce a real game, for somebody who doesn't have significant experience, documentation (including: availability of books) is the top priority.
0xRusty 4y ago
Absolutely incredible depth covered here. Very generous of the OP to provide such a detailed tutorial and reference! I'm going to try and go through this in a lot more detail when I get some time.
chungus 4y ago
This is what I used to learn Rust, in tandem with The Book. I would read a chapter of The Book, then do a chapter of Herbert's Roguelike Tutorial. Very well written and fun material, that guides you deep into a tricky space with very little previous knowledge required. The maintainer is also very responsive to questions and pull requests. And has done an interesting talk[0] on procedural map generation at the annual 'Roguelike Celebration' conference[1] which is happening in October. (and for which the Call For Papers is still open) [0] https://youtu.be/TlLIOgWYVpI https://youtu.be/TlLIOgWYVpI [1] https://www.roguelike.club/ https://www.roguelike.club/
- drivers99 4y ago
  What’s “The Book”? Someone else mentioned `book` in backticks as well so I’m guessing there’s one canonical book that Rust people are referring to.
  - dhagz 4y ago
    They're referring to this[1]. [1]: https://doc.rust-lang.org/stable/book/ https://doc.rust-lang.org/stable/book/
    - SnowHill9902 4y ago
      I found it quite shallow. Am I alone in this? What’s a better resource for learning Rust from a C++ background?
      - lr1970 4y ago
        I found that the following book is much better suited for programmers with C/C++ experience: "Programming Rust, 2-nd edition" by Jim Blandy, Jason Orendorff, Leonora F. S. Tindall [1] [1] https://www.oreilly.com/library/view/programming-rust-2nd/9781492052586/ https://www.oreilly.com/library/view/programming-rust-2nd/97...
- thealienthing 4y ago
  Amazing how powerful the concept of building a game is in teaching someone to program. The combination of graphics and learning some technical chops helps the user really get seasoned quickly in any language while also giving them something they can show their friends and family. Having someone cool to show off really helps maintain that excitement in the learning process.
wcarss 4y ago
Maybe a few years out of date, another tutorial bringing you through implementing a roguelike in rust: https://tomassedovic.github.io/roguelike-tutorial/ https://tomassedovic.github.io/roguelike-tutorial/ I followed this one in 2018 and really enjoyed it, and it made a playable and impressive little roguelike! Though I didn't end up learning rust very deeply from the effort, it was a worthwhile experience and I are least gained some familiarity.
lordleft 4y ago
One of the great blessings of the roguelike genre, especially in its purer-ASCII expressions, is that the barrier to create a complete and gripping game was considerably lower than games that required lots of art assets, animations, etc. It's a genre born out of the constraints of early computing.
- zasdffaa 4y ago
  Hard to call it gripping when I'm trying to find out how to do X in the interface. I suppose like emacs it comes with time. I admit on the few times I played it and managed not to get frustrated I do start to perceive it at least partly in 3 dimensions with immersion, like an interactive cinema in my head, bit like when I played AD&D as a kid (which I admit I miss).
  - kadoban 4y ago
    That is the big downside, it takes a while to get invested in it, especially these days when there's a thousand other things optimized to pull your attention. Once you get into them though, they're some of my favorite games. NetHack might be the most absorbing game I've ever played, and there's a few others with that art style that came close.
- jaunkst 4y ago
  That is one of the reasons why I got into programming. Not exactly because of roguelikes but MUDs. After playing muds, and wanting to make my own I started with Diku, and then started building them from scratch in many other languages. The ECS pattern became something really interesting to me just because of the highly serializable state. One of the MUDs my community was involved in had a great developer behind it. It was just so amazing how fast new features were added to the system. The idea that you don't need assets, animations, etc is critical. I would love for a book series that would cover something like this in multiple languages.
greybox 4y ago
It's wonderful that someone took it upon themselves to write this and release it open source, thank you!
GuB-42 4y ago
There are orcs, dragons, spiders, gelatinous cubes but no rust monsters. Disappointed. No seriously, that's great, and maybe rust monsters will be included eventually. Technically, it has an interesting effect (damages metal items) which may have a place in a tutorial like this.
kramerger 4y ago
I don't get it, how can people use this to learn rust? Sure, game development can be fun. But this looks more like a tutorial for rltk. It quickly gets pretty confusing if you don't already know some rust, gamedev and rougelike. (I recommend beginners to look at rust by examples instead)
- stu2b50 4y ago
  I consider this kind of tutorial to be about the middle area of learning. It's probably too much for a beginner to rust, but it's great at turning someone who merely knows rust to someone proficient in rust.
- otikik 4y ago
  If you are a beginner to Rust and gamedev and roguelikes, it might be too much for you, yes. Different tools for different people. Absolutely. That said, the Venn Diagram of "roguelike enthusiasts" and "game developers" approaches a circle.
throwaway894345 4y ago
I'm a little embarrassed to say that I've heard "roguelike" mentioned frequently, but I still have no idea what it means. What are some popular roguelike games that I might have played or could easily play to get an idea?
- cupofpython 4y ago
  Dead Cells is a popular recent one. Hades classifies as well I believe. A ~roguelike~ rogue-lite is something where you start from the beginning repeatedly, and each "run" or playthrough you change the game state somehow (varies by game) so that the next run is easier / you have more in-game options for progression. Almost always with randomized game features available each run. It's worth noting that "rogue-like" is a description for the Game Play Loop, not the look / feel of the game. A roguelike can be top-down, side scroller, 2d, 3D, etc.
  - fknorangesite 4y ago
    > Hades classifies as well I believe. ... each "run" or playthrough you change the game state somehow (varies by game) so that the next run is easier / you have more in-game options for progression. Usually this is how the community differentiates between "roguelikes" (i.e., like the original Rogue[1] - with no persistence between runs), and "roguelites" where there is some amount of carryover, like in Hades. Of course, like any time you have a bunch of dorks arguing about nomenclature, there are a bunch of grey-area examples that people fight over as if it matters more than it actually does. Anyway, tangent: Hades fucking rules. [1] https://en.wikipedia.org/wiki/Rogue_(video_game) https://en.wikipedia.org/wiki/Rogue_(video_game)
    - cupofpython 4y ago
      Oh cool, I wasn't aware of that distinction
  - hypertele-Xii 4y ago
    > each "run" or playthrough you change the game state somehow (varies by game) so that the next run is easier / you have more in-game options for progression. You've fallen for the hostile takeover. Roguelike used to mean the exact opposite of that: Each run starts from scratch, independent of all previous runs. Some roguelikes, that is, games like Rogue [0], implemented "player ghosts", monsters based on previously dead player characters, but that's the only persistent progression in a roguelike. It saddens me that the term has been hijacked by modern indie developers to pretend to mean just about any game that has any amount of randomness in it. Dead Cells is not a roguelike. Hades is not a roguelike. They are action RPGs more like Diablo. Diablo, by the way, is also not a roguelike. WHAT IS A ROGUELIKE? As the name suggests, it is a game like Rogue. The genre hasn't evolved a better name yet, kind of how first-person shooters were originally called "Doom clones". So what was Rogue like? First and foremost it was a turn-based tactics game, where you had an unbounded amount of time to ponder your next move. It had highly randomized content, you'd have to make do with what you found. It was a dungeon crawling, exploration, turn-based tactical combat game with permadeath and no persistence of progression. You lose, you start all over. [0] https://en.wikipedia.org/wiki/Rogue_(video_game) https://en.wikipedia.org/wiki/Rogue_(video_game)
NonNefarious 4y ago
A "Rogue-Like?" Come on.
- NonNefarious 4y ago

327 points by wsc981 4y ago

graboid 4y ago

Holy cow, that's amazing. And it is so extensive. Thanks a lot for the link.

fredrikholm 4y ago

I used this to learn Rust (after `book`), highly recommended!

Winsaucerer 4y ago

I started working through this, except to make things difficult for myself I used Godot for drawing everything, via https://github.com/godot-rust/godot-rust https://github.com/godot-rust/godot-rust. I only got to about halfway through section 2, but I think it was going well.

hiyer 4y ago

Medium subscribers can read an HTML version of this book for free here - https://medium.com/pragmatic-programmers/table-of-contents-197f27b96b7b https://medium.com/pragmatic-programmers/table-of-contents-1...

deleted 4y ago
[deleted]

CGamesPlay 4y ago

Man, this Specs [0] library is so strange to me, coming from a Unity background. Is there some sort of comparison as to why one way is better than the other? [0] https://docs.rs/specs https://docs.rs/specs

nextaccountic 4y ago
Maybe you would like Bevy's ECS more? https://bevyengine.org/learn/book/getting-started/ecs/ https://bevyengine.org/learn/book/getting-started/ecs/ (it's a later design that incorporated some improvements, like, you don't need to define a struct and impl a trait to define a system)
- dymk 4y ago
  Bevy's ECS is incredibly ergonomic and makes writing ECS code fun. You give Bevy a function and it automagically turns it into a system by doing dependency injection. No need to write an impl for it, the system takes care of that for you. It makes prototyping very fun, as it's cheap to experiment with different system configurations.
jakkos 4y ago
If you mean a comparison between SPECS' paradigm, ECS, and Unity's mix of OOP/composition, the main benefit of ECS is performance. The way ECS loops over arrays of data means that the memory accesses it makes are nearly always already in cache. Games spend a surprisingly large amount of time just waiting to receive values from memory. In the right circumstances, normally when dealing with huge numbers of objects (think simulation games), ECS can be entire orders of magnitude faster. Other than that some people just prefer coding in ECS. Unity has been developing its own separate ECS framework for a while now.
pornel 4y ago
It is a very different and seemingly weird approach. It's almost like writing SQL queries for your game world (e.g. "find all entities with a Flying component and attach them a WooshSound component). A clever memory layout makes these queries super fast. It makes separation of concerns very natural. Different parts/layers of the game, like inputs, AI, sounds, graphics, effects and animations can be coded separately. You don't end up with "god class" for player's object that does a bit of everything. You have player entity that has components attached, and each system operates on its own set of components. I can't really do it justice in a comment. It's a quite different approach, so it's not directly comparable. It's like OOP vs Rust's traits. ECS happens to match Rust's memory model and traits incredibly well. Here's a more in-depth talk about this: https://www.youtube.com/watch?v=aKLntZcp27M https://www.youtube.com/watch?v=aKLntZcp27M
- wdroz 4y ago
  Even the Data-oriented design[0] is eyes opening (which is part of the ECS). The classic example is[1]: Instead of having a list of structs, where each struct get some types (int, float, ...), you use one struct, where the fields are list of types (array of int, array of floats, ...) [0] -- https://en.wikipedia.org/wiki/Data-oriented_design https://en.wikipedia.org/wiki/Data-oriented_design [1] -- https://en.wikipedia.org/wiki/AoS_and_SoA https://en.wikipedia.org/wiki/AoS_and_SoA
  - kramerger 4y ago
    Unity uses ECS, just in a more visual way.
    - wdroz 4y ago
      I did some Unity3d back in 2013, I don't remember using ECS (intentionally?). After a quick search, it's seem that the MonoBehaviour are the old way and ECS the new ways? That's nice.
      - kramerger 4y ago
bodge5000 4y ago
ECS is an absolute pain to work with and makes everything so much slower...until it clicks. In the past I've compared it to learning programming all over again. The SQL reply summed it up quite nicely, basically you perform queries for anything with a class attached and then perform your operations on all of those. It sounds really inefficient, but in terms of raw performance the results usually speak for themselves. A good example I encountered with Bevy, another Rust ECS framework, is imagine you want your camera to follow your player. Rather than having a script on your camera and a different one on your player, you could just attach a generic class to both, query through anything with that class and update the position of it based on the input.

suby 4y ago

75 comment discussion here from 2020 https://news.ycombinator.com/item?id=22020229 https://news.ycombinator.com/item?id=22020229

sanjayts 4y ago

What's the relation between this tutorial and the "hands on rust" book? Overlapping content or contains bits and pieces from the book?

m4nu3l 4y ago

I'm currently using Godot 3 for my solo indie project. It's a six-degrees of freedom space shooter. I use rigid bodies and physics very extensively, but what have proved to be very hard-to-remove bottlenecks were the scene tree and scripts. At some point the game was spending more time on those things that on the physics simulation. I have rewritten some code in C++ over time and parallelized as much as I can. However I'm starting to think that scripting languages are a false economy. There is no intrinsic reason you can't have a concise and easy to use language that can be quickly (in debug mode) compiled to the metal and dynamically linked to the project. I might look at godot-rust at some point although It's a bit late considering the amount of code I have written already.

medo-bear 4y ago
> However I'm starting to think that scripting languages are a false economy. There is no intrinsic reason you can't have a concise and easy to use language that can be quickly (in debug mode) compiled to the metal and dynamically linked to the project. This might interest you: * https://reader.tymoon.eu/article/413 https://reader.tymoon.eu/article/413 * https://github.com/Shinmera/talks/blob/master/gic2021-highly-dynamic/paper.pdf https://github.com/Shinmera/talks/blob/master/gic2021-highly... and the very recent still front-page discussion on hn: * https://news.ycombinator.com/item?id=32043026 https://news.ycombinator.com/item?id=32043026
krapp 4y ago
>However I'm starting to think that scripting languages are a false economy. This is likely more an indictment of Godot's 3D capabilities or GDScript than scripting languages as a whole.
- m4nu3l 4y ago
  No, not really. It's not about the 3D capabilities (I have different types of issues there) or about GDScript per se (other scripting languages have even worse issues like the GIL in Python), but the issue I had is that a lot of time was spent doing these: - Counting references. - Variant related conversions. - Resolving methods. - Interpreting the bytecode. - Sorting nodes before calling update functions. - Triggering callbacks etc. All of these would amount to a good percentage of the time spent in the main thread. I managed to optimize by a combination of parallelism (gladly GDScript has no GIL!) and by rewriting somethings in C++. I still have some bottlenecks with the rendering but that should be easier to scale back.

bodge5000 4y ago

Maybe a good place to ask, does anyone have any recommendations for game dev frameworks? Preferably something performant, stable and not too much of a pain to work with. Been using Godot for a year or two and loving it, but I do want to try out the code only workflow, I feel like it'd suit me better being freed of the constraints of an engine, but I'd at very least like to try so I can be sure. I tried Bevy before and it was fantastic, but its just not production ready. Also tried Raylib, the main problem with that being the sheer number of bindings somewhat segments the community and makes it harder to figure out how to start off with, but it might be worth another go. Might also consider going without a framework and just finding libraries to fill in what I need, but that might not play nice with "not too much of a pain to work with"

krapp 4y ago
May be more lower level than what you're looking for but my current drug of choice when I want to write all the code is SDL2 and LuaJIT in Visual Studio.
- bodge5000 4y ago
  SDL2 I've been heavily tempted by, but it has a similar problem as Raylib where everyones writing it in a different language. Great when you know what your doing, but a bit more difficult to get up and started with. But maybe it is worth that extra time investment just for how popular and battle-tested it is
pizza234 4y ago
In Rust, there is none; they're just not ready, and not used either (there are very few full games written in Rust). The Bevy maintainers in particular give very low priority to foundational functionalities (see 1 frame lag and the unusable stages+states), and focus on advanced ones instead. There aren't so many alternatives actually (SDL is a very valid framework, but it isn't a game engine), and the choice depends on what's your real goal (experiment or develop a real game). In my opinion, if the goal is to produce a real game, for somebody who doesn't have significant experience, documentation (including: availability of books) is the top priority.

0xRusty 4y ago

Absolutely incredible depth covered here. Very generous of the OP to provide such a detailed tutorial and reference! I'm going to try and go through this in a lot more detail when I get some time.

chungus 4y ago

This is what I used to learn Rust, in tandem with The Book. I would read a chapter of The Book, then do a chapter of Herbert's Roguelike Tutorial. Very well written and fun material, that guides you deep into a tricky space with very little previous knowledge required. The maintainer is also very responsive to questions and pull requests. And has done an interesting talk[0] on procedural map generation at the annual 'Roguelike Celebration' conference[1] which is happening in October. (and for which the Call For Papers is still open) [0] https://youtu.be/TlLIOgWYVpI https://youtu.be/TlLIOgWYVpI [1] https://www.roguelike.club/ https://www.roguelike.club/

drivers99 4y ago
What’s “The Book”? Someone else mentioned `book` in backticks as well so I’m guessing there’s one canonical book that Rust people are referring to.
- dhagz 4y ago
  They're referring to this[1]. [1]: https://doc.rust-lang.org/stable/book/ https://doc.rust-lang.org/stable/book/
  - SnowHill9902 4y ago
    I found it quite shallow. Am I alone in this? What’s a better resource for learning Rust from a C++ background?
    - lr1970 4y ago
      I found that the following book is much better suited for programmers with C/C++ experience: "Programming Rust, 2-nd edition" by Jim Blandy, Jason Orendorff, Leonora F. S. Tindall [1] [1] https://www.oreilly.com/library/view/programming-rust-2nd/9781492052586/ https://www.oreilly.com/library/view/programming-rust-2nd/97...
thealienthing 4y ago
Amazing how powerful the concept of building a game is in teaching someone to program. The combination of graphics and learning some technical chops helps the user really get seasoned quickly in any language while also giving them something they can show their friends and family. Having someone cool to show off really helps maintain that excitement in the learning process.

wcarss 4y ago

Maybe a few years out of date, another tutorial bringing you through implementing a roguelike in rust: https://tomassedovic.github.io/roguelike-tutorial/ https://tomassedovic.github.io/roguelike-tutorial/ I followed this one in 2018 and really enjoyed it, and it made a playable and impressive little roguelike! Though I didn't end up learning rust very deeply from the effort, it was a worthwhile experience and I are least gained some familiarity.

lordleft 4y ago

One of the great blessings of the roguelike genre, especially in its purer-ASCII expressions, is that the barrier to create a complete and gripping game was considerably lower than games that required lots of art assets, animations, etc. It's a genre born out of the constraints of early computing.

zasdffaa 4y ago
Hard to call it gripping when I'm trying to find out how to do X in the interface. I suppose like emacs it comes with time. I admit on the few times I played it and managed not to get frustrated I do start to perceive it at least partly in 3 dimensions with immersion, like an interactive cinema in my head, bit like when I played AD&D as a kid (which I admit I miss).
- kadoban 4y ago
  That is the big downside, it takes a while to get invested in it, especially these days when there's a thousand other things optimized to pull your attention. Once you get into them though, they're some of my favorite games. NetHack might be the most absorbing game I've ever played, and there's a few others with that art style that came close.
jaunkst 4y ago
That is one of the reasons why I got into programming. Not exactly because of roguelikes but MUDs. After playing muds, and wanting to make my own I started with Diku, and then started building them from scratch in many other languages. The ECS pattern became something really interesting to me just because of the highly serializable state. One of the MUDs my community was involved in had a great developer behind it. It was just so amazing how fast new features were added to the system. The idea that you don't need assets, animations, etc is critical. I would love for a book series that would cover something like this in multiple languages.

greybox 4y ago

It's wonderful that someone took it upon themselves to write this and release it open source, thank you!

GuB-42 4y ago

There are orcs, dragons, spiders, gelatinous cubes but no rust monsters. Disappointed. No seriously, that's great, and maybe rust monsters will be included eventually. Technically, it has an interesting effect (damages metal items) which may have a place in a tutorial like this.

kramerger 4y ago

I don't get it, how can people use this to learn rust? Sure, game development can be fun. But this looks more like a tutorial for rltk. It quickly gets pretty confusing if you don't already know some rust, gamedev and rougelike. (I recommend beginners to look at rust by examples instead)

stu2b50 4y ago
I consider this kind of tutorial to be about the middle area of learning. It's probably too much for a beginner to rust, but it's great at turning someone who merely knows rust to someone proficient in rust.
otikik 4y ago
If you are a beginner to Rust and gamedev and roguelikes, it might be too much for you, yes. Different tools for different people. Absolutely. That said, the Venn Diagram of "roguelike enthusiasts" and "game developers" approaches a circle.

throwaway894345 4y ago

I'm a little embarrassed to say that I've heard "roguelike" mentioned frequently, but I still have no idea what it means. What are some popular roguelike games that I might have played or could easily play to get an idea?

cupofpython 4y ago
Dead Cells is a popular recent one. Hades classifies as well I believe. A ~roguelike~ rogue-lite is something where you start from the beginning repeatedly, and each "run" or playthrough you change the game state somehow (varies by game) so that the next run is easier / you have more in-game options for progression. Almost always with randomized game features available each run. It's worth noting that "rogue-like" is a description for the Game Play Loop, not the look / feel of the game. A roguelike can be top-down, side scroller, 2d, 3D, etc.
- fknorangesite 4y ago
  > Hades classifies as well I believe. ... each "run" or playthrough you change the game state somehow (varies by game) so that the next run is easier / you have more in-game options for progression. Usually this is how the community differentiates between "roguelikes" (i.e., like the original Rogue[1] - with no persistence between runs), and "roguelites" where there is some amount of carryover, like in Hades. Of course, like any time you have a bunch of dorks arguing about nomenclature, there are a bunch of grey-area examples that people fight over as if it matters more than it actually does. Anyway, tangent: Hades fucking rules. [1] https://en.wikipedia.org/wiki/Rogue_(video_game) https://en.wikipedia.org/wiki/Rogue_(video_game)
  - cupofpython 4y ago
    Oh cool, I wasn't aware of that distinction
- hypertele-Xii 4y ago
  > each "run" or playthrough you change the game state somehow (varies by game) so that the next run is easier / you have more in-game options for progression. You've fallen for the hostile takeover. Roguelike used to mean the exact opposite of that: Each run starts from scratch, independent of all previous runs. Some roguelikes, that is, games like Rogue [0], implemented "player ghosts", monsters based on previously dead player characters, but that's the only persistent progression in a roguelike. It saddens me that the term has been hijacked by modern indie developers to pretend to mean just about any game that has any amount of randomness in it. Dead Cells is not a roguelike. Hades is not a roguelike. They are action RPGs more like Diablo. Diablo, by the way, is also not a roguelike. WHAT IS A ROGUELIKE? As the name suggests, it is a game like Rogue. The genre hasn't evolved a better name yet, kind of how first-person shooters were originally called "Doom clones". So what was Rogue like? First and foremost it was a turn-based tactics game, where you had an unbounded amount of time to ponder your next move. It had highly randomized content, you'd have to make do with what you found. It was a dungeon crawling, exploration, turn-based tactical combat game with permadeath and no persistence of progression. You lose, you start all over. [0] https://en.wikipedia.org/wiki/Rogue_(video_game) https://en.wikipedia.org/wiki/Rogue_(video_game)

NonNefarious 4y ago

A "Rogue-Like?" Come on.

NonNefarious 4y ago