HN user
This one is actually not too bad - there is only a very slight difference between "due" (which can mean both something like "shall be done" and "bound to happen") and "fällig" (which means only "shall be done"). Grammatically and semantically, this almost never matters, it only misses the much higher cultural context of it being slightly weird to refer to a baby as a "task".
But if you're already using message passing, this transition will be much more natural!
Exactly, and messages are divided into buckets which contain only one kind of (type of message, type of receiver)-combination. If you then iterate over that, you are going to execute very similar code repetitively.
I guess my epiphany was that exactly because actors are isolated, I could manage them like this and do some very primitive fast array iteration, while still using a nice high-level pattern to implement the actual game logic.
(author) I made the mistake of writing a blog post targeted towards non-programmers, leaving away a lot of essential detail. For example that buckets only contain one kind of actor or message and because of indirect references can be deallocated by a simple swap-with-last, so no free-lists are needed
That and that I really want to avoid having to debug GPGPU code for the main simulation. But I'm not saying it won't become GPGPU at some point!
(author here) others already addressed the point of premature optimization. It's about getting it kinda right from the start.
Procedural building generation is indeed one of the other huge topics of the project and believable, unique street-level looks a main goal.
Improvement suggestion: Interpolate between the transmitted positions for a smoother animation. It's really difficult for me to detect movement directions at something like 3Hz.
You said what I thought much more eloquently. I found the business models and example emails really spammy if not even scammy.
If what you offer is so vague that you have to do those silly engagement tricks, maybe it doesn't have real value.