The context: I'm writing my own blog software for various reasons [1], including my desire to post less to social media. As much as possible I'm trying to reuse the build system for the rest of the site, including the template. I have worked on and off on this for the past two months and I expect to keep adding features for another month or two. I'm currently adding categories not only for the blog but to the whole site. After that I'll work on archives by month. And I want to import the 21 years of old blog content [2] which is stored on blogger.com, and put it on the new blog, which is just a folder [3] on my existing site.
I'm writing some blog posts to test out the workflow (integrating into emacs, my build script, an internal status page) and also various content types (images, video, source code, figures, links). Each time I post I find some more things to tweak.
This post to HN made me realize that it's not labeled as a blog post. Oops. I guess that's one of the downsides of reusing the exact same template! So another tweak coming…
[1] https://www.redblobgames.com/blog/2024-03-08-new-blog/
After I finished Crafting Interpreters, I took the build system I wrote for that and wrote a static site generator for my blog using it. It's so much better than what I was using before (Jekyll). The performance is literally 100x faster. It produces exactly the output I want.
I realize "write your own static site generator" isn't the right answer for lots of people, but given how much existing technology you already have for your main site, Amit, I bet it's definitely the right answer for you.
I'm a big believer in crafting whatever you personally need, whether interpreters or generators.
As "make" is intended to track changes and only update when dependencies have changed, it was very fast on the computers at that time (that we'd call slow now).
One can only presume his forebears in the Napoleonic era lived near a dike.
https://www.redblobgames.com/grids/hexagons/
An excellent example of their more interactive posts and great for those interested in hex-grid rendering and navigating.
edit: wow, over 10 years ago and the content has been updated but the look and feel is much as I remember it. This was before reactive systems took over the web, too, so the 'toggle selection here, see updates everywhere' was quite notable for the time.
On the actual topic of the post.. I think flow fields easily get overshadowed by waypoints and other hierarchical approaches. Or, folded into the heuristic function for A*.
[1] https://simblob.blogspot.com/2007/07/interactive-illustratio...
The interactive diagrams are exceptional even by current standards, they must have been mind-blowing a decade ago. They're smooth and lightweight, and very informative without detracting from the rest of the content.
In SimAirport they're used in a hierarchical way, primarily & specifically for "one level" of the game's overall hierarchical pathfinding systems (longer-distance paths), and they're critical to the game's ability to handle lots of agents.
Always love seeing your content here, Amit! :)
I feel like by the time the Titans expansion shipped it was a pretty good system. I occasionally see comments complaining about pathfinding being bad, but I’ve never seen specifics.
Seeing a mass of tanks stream into a stargate teleporter will never not be cool.
I also really liked your writeup on the Chrono Cam system that PA used. Just know if you ever decide to do another writeup on the tech of PA there will be one person that will eagerly read it :)
The backend of my game is written in Elixir. And the world grid used for path-finding is represented as a global shared ETS table (distributed data store) with 1 writer (world server) + multiple readers (ai unit controllers). It works so well, and I can even have sub processes that evict cached paths when dynamic "obstructions" like resources spawn into the world. The ETS table structure also can partition cells/grids/paths by "level/map" and server instance. And you can profile it in real-time and see how much memory the ETS table is using, time-to-pathfind, and other metrics.
I was quite young then (just joined my first "real job"), and was very impressed by the elegance of the solution, as it made the AI players always find the goal in the game, even when you are bouncing around. Even with the limitations of the time, almost 20 years ago! (64kb JAR files including all the game and resources, crappy java implementations on crappy phones, etc.)
I think I've heard of similar method used to emulate fluid dynamics, when full on simulation is a total overkill.
Total shame that it got trashed for being a sequel, instead of the spiritual successor it probably should've been. In terms of "time to legions of giant robots slinging world-destroying explosives", SupCom2 takes the cake. It's an incredible beer-and-pretzels game.