Some geographic regions have gloomy light blue Novembers. December at this location would be a lot more hazy and white.

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.

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.

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.

From what I’ve seen and heard, AI seems to do well for test-driven development. That doesn’t necessarily translate into good code, but it does translate into tested code.

At the very least it can translate the documentation of an API into the appropriate tests to verify the documentation is correct, and I’m being quite humbled by that.

The important part is that the tests track regressions and they’re helpful for that. After that, it’s okay if tests are mostly write-only.

I’ve noticed that AI commentary tends to describe what the code is doing verbatim which is better for naming tests and functions rather than writing code comments, docstrings, or change notes. I usually have to fix this public-facing documentation to not talk about library internals which no user of the library would ever care about.

So far I feel that AI assists are good when you have the time and effort to push back on them, but that isn’t an option for all projects, it works well for my own projects which have very few contributors in the first place. For the most part I can treat them with the same scrutiny as human written code. When the person submitting the code is obviously not checking their own code then that’s a problem.

As an open source project maintainer I can always tell whenever a pull request is AI assisted because no human would ever write full tests for all their pull requests.