I actually wrote both versions of this tutorial during such events! First tutorial was written during the first event (2017 I think?) and the most recent version was done in 2020. Many others have done something similar since. It's a bit hectic trying to write ahead of the event, but I find having a deadline to get the "parts" done is a fantastic motivator.
There are also a lot of frameworks out there which may be useful without a tutorial. For example Valkyrie for the Free Pascal Compiler, which integrates Lua and was used to create DoomRL.
It looks like it's unfinished. At the bottom of the last existing chapter, it says "We now have the second-to-last section done!" and mentions something about building "the Abyss." I wonder if the author(s) meant to finish it but never returned from the depths...
I really, really like the "diff" style for code fragments - it makes the tutorial so much nicer to read, and I don't see any significant downsides. This should be the standard for all tutorials where you progressively modify a non-trivial body of code.
Author here; the idea came from frustrations with the original Python roguelike tutorial on Roguebasin. Since the entire thing was written in one file, it was difficult sometimes (for me anyway) to tell what was going on.
While I'm happy with the way the diff style turned out, I will say there is one big downside for me: It's a huge pain to write. Not only did I do a "git diff" every time I made changes and documented it, but if you end up changing something later down the line, then I basically had to go back to the very beginning of the chapter, follow the tutorial along, and double check everything. Maybe there's a more efficient way to do this, but it was a bit tedious and time consuming.
Still worth the effort in the end though, I think.
Thank you for making the effort to experiment with the diff style. Now that people are seeing this documentation and appreciating the output, maybe someone else will come up with a way to automate it for future authors.
https://craftinginterpreters.com/ is a bigger project with automated tests at each stage making sure the diffs line up. I'm not sure it's open sourced though.
My book Crafting Interpreters has a similar snippet style where it shows you the surrounding context for inserted code so you can see where it goes. It doesn't show the deleted code (because that would probably get too noisy in most cases), but I could if I wanted to.
I ended up writing a whole little custom build system to automatically generate the snippets and their surrounding context based on comments in the source code [1]. It was a fairly complex program to write, but it makes it completely automatic and error-free. I can't imagine trying to maintain it all manually.
Yeah it's nice - I'm tinkering with a game in similar style to roguelike at the moment and considered doing the graphics ascii-style for rapid development instead of making 3d placeholder art. It ended up being quicker to learn the basics of blender and go 3d immediately, than to do text first and 3d later.
I did a bit of a double take seeing this on HN. Seeing something I helped to create on here is... a strange feeling, to say the least.
While I'm not completely satisfied with the way this tutorial stands right now, I certainly hope that it has given a few people some ideas and motivation for their own roguelike projects.
Feel free to shoot any issues with the site or tutorial text over to the Github page: https://github.com/TStand90/roguelike-tutorials-website (fair warning: I'm pretty bad at responding to issues, and I sincerely apologize for that)
I did a speed run through the tutorial after discovering it here on HN. I have been itching to write a rougelike for a few months, and I happened to have the time to spare.
Overall, it was a lot of fun, and I enjoyed the process. I have not played with Python for a while, so this was a nice refresher. Your tutorial also brought me up to speed on the modern static typing support.
As for my process, I copy and pasted each set of changes, working through each part in turn. Overall, I stuck fairly close to the tutorial code, though every part received some amount of custom changes to keep things interesting. Very easy to follow.
I created a custom Dockerfile to encapsulate all of the required dependencies, using a Makefile to test/check the code inside a container. I used `mypy` for checking types, which helped find track down the bugs introduced by my custom changes.
It would be nice to see a new version that eliminates the refactoring steps that prefix Parts 6 and 8. Those unexpected grinds took a little bit of wind out of the sails, but the changes were ultimately worthwhile.
Another suggestion would be to encapsulate all of the game parameters into their own class from the start, such that you can pass an instance of that around rather than a half dozen individual variables.
But really, those are relative nits to pick. I would recommend this tutorial to anyone familiar with Python as a way to learn the internals of roguelikes built using TCOD.
I would have absolutely loved this book as a student, and I’m writing a similar book for JS and gamedev, I’m really liking the diff style and I might adopt it myself.
If you're looking specifically for roguelike tutorials, the roguesharp link provided above is good. Also, SadConsole[0] is a great library and has a friendly and helpful Discord community.
If it's general gamedev resources for C#, then I would suggest Cynthia McMahon's Eyes of the Dragon series[1], for C# / Monogame. It goes through topics like input handling, drawing, tooling, etc. A thing I like about this as well is that it's not "perfect" off the bat -- an entry later will return to code written previously and talk about its benefits and drawbacks, and then refactor that code for a new goal or sometimes to just make it better. If you're new to C#, development, or game development, it offers a good perspective into what doing this "for real" looks like.
Unity (the popular game engine) use C# as the programming language. Search “unity tutorials” and you will find a wealth of info about not just unity but game development in general.
33 comments
[ 3.0 ms ] story [ 77.3 ms ] thread[0]:https://hexworks.org/posts/tutorials/2018/12/04/how-to-make-...
https://github.com/marukrap/RoguelikeDevResources (Tutorials section)
There are also a lot of frameworks out there which may be useful without a tutorial. For example Valkyrie for the Free Pascal Compiler, which integrates Lua and was used to create DoomRL.
The copyright looks old on that page but if you view the source code for that chapter it was modified last month.
While I'm happy with the way the diff style turned out, I will say there is one big downside for me: It's a huge pain to write. Not only did I do a "git diff" every time I made changes and documented it, but if you end up changing something later down the line, then I basically had to go back to the very beginning of the chapter, follow the tutorial along, and double check everything. Maybe there's a more efficient way to do this, but it was a bit tedious and time consuming.
Still worth the effort in the end though, I think.
https://github.com/munificent/craftinginterpreters
I ended up writing a whole little custom build system to automatically generate the snippets and their surrounding context based on comments in the source code [1]. It was a fairly complex program to write, but it makes it completely automatic and error-free. I can't imagine trying to maintain it all manually.
[1]: http://journal.stuffwithstuff.com/2020/04/05/crafting-crafti...
IF you did it with the terminal it would be tall and narrow.
While I'm not completely satisfied with the way this tutorial stands right now, I certainly hope that it has given a few people some ideas and motivation for their own roguelike projects.
Feel free to shoot any issues with the site or tutorial text over to the Github page: https://github.com/TStand90/roguelike-tutorials-website (fair warning: I'm pretty bad at responding to issues, and I sincerely apologize for that)
Overall, it was a lot of fun, and I enjoyed the process. I have not played with Python for a while, so this was a nice refresher. Your tutorial also brought me up to speed on the modern static typing support.
As for my process, I copy and pasted each set of changes, working through each part in turn. Overall, I stuck fairly close to the tutorial code, though every part received some amount of custom changes to keep things interesting. Very easy to follow.
I created a custom Dockerfile to encapsulate all of the required dependencies, using a Makefile to test/check the code inside a container. I used `mypy` for checking types, which helped find track down the bugs introduced by my custom changes.
It would be nice to see a new version that eliminates the refactoring steps that prefix Parts 6 and 8. Those unexpected grinds took a little bit of wind out of the sails, but the changes were ultimately worthwhile.
Another suggestion would be to encapsulate all of the game parameters into their own class from the start, such that you can pass an instance of that around rather than a half dozen individual variables.
But really, those are relative nits to pick. I would recommend this tutorial to anyone familiar with Python as a way to learn the internals of roguelikes built using TCOD.
https://suldashi.github.io/gamebook
If it's general gamedev resources for C#, then I would suggest Cynthia McMahon's Eyes of the Dragon series[1], for C# / Monogame. It goes through topics like input handling, drawing, tooling, etc. A thing I like about this as well is that it's not "perfect" off the bat -- an entry later will return to code written previously and talk about its benefits and drawbacks, and then refactor that code for a new goal or sometimes to just make it better. If you're new to C#, development, or game development, it offers a good perspective into what doing this "for real" looks like.
[0]: http://sadconsole.com/v8/articles/tutorials/get-started/draw...
[1]: https://cynthiamcmahon.ca/blog/category/eyes-of-the-dragon/
It's a bunch of OOP with a bunch of Composition with a bunch of ECS
It's asking for trouble and confusion
I am definitly not a fan of that decision, it started properly, then they messed up after making Entity -> Actor, shame