Welcome to the revival of RoguelikeDev’s FAQ Friday, now on the Fediverse!
The purpose for this event is for traditional roguelike developers to discuss design philosophy and share their technical insights and methods as well as field questions related to the topic.
This was a popular event on Reddit and with the current state of things I thought it would be a good idea to bring it here in order to better preserve these discussions.
FAQ Fridays #1: Languages and Libraries
We’ll naturally start with one of the first and most basic questions you have to consider:
What languages and libraries are you using to build your current roguelike? Why did you choose them? How have they been particularly useful, or not so useful?
Python still has some of the best onboarding for developing a roguelike from scratch, especially when combined with libtcod’s standard set of tools. After 9 years since the last time this was asked there have been more modern languages becoming mature and new game engines to work with.
You must log in or register to comment.
Hello! I’d like to see this community grow and participating is the only way to make that happen.
I wrote WildsRL in Rust with minimal use of libraries. I’m using
termionto render to the terminal in the native build, andwasm-bindgento expose JavaScript bindings in the web build. The only libraries I use for the core game logic arerandandrand_distr, for RNG. So most of the code is plain old Rust.I have mixed feelings about Rust for game development. The biggest problem is its “shared xor mutable” default. Games are all about mutable state. You often want to have a mut ref to an entity and const access to the rest of the game state (which itself refers to the entity). Languages like Java and JavaScript prove that there’s no actual reason that you can’t have that AND be memory-safe.
This post explains my issues better than I can: https://loglog.games/blog/leaving-rust-gamedev/
Why do I stick with it? Well, it’s really pleasant in other ways. I like that constructors are trivial to understand (looking at you, C++). I use union types everywhere.
cargo checkruns in ~0.02s so any errors in my code are instantly highlighted. Most importantly, I have a few years’ worth of code and I’m not going to throw it away.I haven’t used Rust yet but I’m a strong advocate for the SOLID principles so I tend to be pro having a more difficult time writing code more correctly.
I have mixed feelings about Rust for game development. The biggest problem is its “shared xor mutable” default. Games are all about mutable state.
This is true and it’s also true that most languages handle mutable state poorly which causes major issues with concurrently solved mainly by keeping all logic on a single thread.
You often want to have a mut ref to an entity and const access to the rest of the game state (which itself refers to the entity).
This statement admits it’s contradiction. A mutable access to a const global state isn’t a real thing, it’s a precarious false thing that many classic languages erroneously allow. The simple solution is to admit that the whole game state is mutable all the time and that concurrent access to it will always be unsafe.
There are solutions to this but unless you want to run multiple threads then I don’t see much reason to worry about it, otherwise it was going to be an issue no mater which concurrent language you wrote your game state in.
Mutable reference pointers have many of their own issues and I feel sorry for anyone who has to learn about reentrancy from Rust. Learning about alternatives to pointers is a good lesson to bring back to any language.
Languages like Java and JavaScript prove that there’s no actual reason that you can’t have that AND be memory-safe.
Borrow checking is more about race conditions than memory safety. JavaScript is single-threded so I’m not sure how much it compares to Rust. Rust gets its memory safety from its stricter handling of types.
I’m familiar with the arguments for Rust’s approach. It makes sense for many use cases. I’m not saying it’s wrong, just that there are tradeoffs and that for me, different ones are a better match for gamedev.
Rather than focus on difficulties, though, I can point out some code that was a really nice fit for the language. Top of mind there is my behavior trees implementation. With a few macro invocations, I can define a tree that’s easy to read in source, that statically checks that nodes fit together, that supports full “time-travel” debugging, and that compiles to fully-specialized code. Besides the regular pathfinding and shadowcasting helpers, this file is the core “library” the game is built on.
It’s a bit awkward posting the original FAQ Fridays text since it praises libtcod so highly and I’m the maintainer of libtcod and python-tcod. Previously there used to be times where I was hesitant about the quality of tcod and would suggest alternatives such as BearLibTerminal, but it seems BearLibTerm has long gone dormant while I continue to maintain and improve tcod. Lately I’m more proud of my own contributions to the library.
Still, even with libtcod available it’s not unusual to see people to use the heavily archaic Curses or write their own console emulator in SDL.
Curses has always been a weird choice for a game due to its weird API for things such as color pairs to the point where even ANSI escapes are preferable to Curses, but escapes alone don’t solve some of the unusual quirks of terminal handling. I never got a chance yet but I would’ve liked to look into Notcurses more as an alternative.
Rust is also something I’ve wanted to try but never got around to. All of my libraries are written in C and those are more easily ported to Python than Rust. So I end up using Python most of the time.
For writing a game engine from scratch, I think any Modern ECS library (not a Minimal ECS library) is ideal to work with. Any future C++ project I make will be using Flecs in spite of its harsh learning curve. For Python projects, I ended up writing tcod-ecs due to no other Python libraries supporting entity relations at the time.
Currently having issues with Federation. This post is not visible from programming.dev within 12 hours. I’m hoping I won’t need to repost this from my programming.dev account.
Edit: Seen by programming.dev after two days. This is something I’ll need to pay attention to, but also I could’ve just been unlucky with this first post.
