First you clone the API of the winner, because you want to siphon users from its install-base and offer de-risked switch over cost.

Now that you’re winning, others start cloning your API to siphon your users.

Now that you’re losing, you start cloning the current winner, who is probably a clone of your clone.

Highly competitive markets tend to normalize, because lock-in is a cost you can’t charge and remain competitive. The customer holds power here, not the supplier.

Thats also why everyone is trying to build into the less competitive spaces, where they could potentially moat. Tooling, certs, specialized training data, etc

If it’s their only value proposition, then every other element is just plain worse. This is the only aspect that makes them not worthless.

more specifically, the bug is due to a buffer overflow during paused chat, and presumably deviant undefined behavior between the original execution and the replayed execution.

and most importantly, it has nothing to do with the non-deterministic nature of the game -- non-determinism is trivial to account for, because PCRNGs are not actually non-deterministic; they're (pseudo)random, and deterministically so. They're just random enough to be equivalent to non-deterministic to the user.

As long as seeds are synced, it's trivially managed. But this kind of cause-for-desync is the reason deterministic engines are such a PITA to actually write. Any source of actual non-determinism wrecks everything, and there's always some miserably rare cases.

StarCraft Brood War replays would desync due to version issues, too. Any gameplay adjustments in a patch would affect the replay, often in subtle ways that would sometimes result in a valid and interesting game, just different outcome.

the notion of using time directly in gamedev has always confused me; it feels like the correct answer should be to simply have a notion of turns, and a real-time game simply iterates over turns automatically. And then so many turns are executed per second

It's a simulation; why should clock time be involved to begin with? The only things that should care about clock time are those that exist outside the sim, e.g audio

Simulation can proceed in logical time but animation is necessarily tied to wall clock time in order to be perceived as smooth and consistent by a human viewer.

In that case, animation belongs to the same category as audio — it exists outside the simulation state.

But I’m not 100% that’s even true; in the context of replay, I imagine it’d be more appropriately part of the sim for it to scrub properly.

In the context of networked games with client-side prediction, I think it’d probably be key frames tied to logical time and intermediate frames tied to wallclock

if its deterministic lockstep, then all you need to do is record inputs and replay the inputs, since the engine itself is guaranteed to behave the same. If it's client/server and non-deterministic, then you need to record the entire state of the system at every step (which you'll naturally receive from the server) to replay. The main difference would be in how large a replay file would get; and more dynamism naturally implies more information to record. Large unit quantities in e.g. an RTS behaves more sanely with deterministic replay.

the other negative with deterministic input-based replay is what you've said -- if the engine deviates in any manner, the replay becomes invalidated. You'd have to probably ship with every version of the engine, and the replay just runs on the relevant release. Just replaying and re-recording the inputs on the new version wouldn't do anything, because the outcome behavior would inevitably out of sync with the original.

I'm also not sure how one would support scrubbing, except by also having inverse operations defined for every action or by fully-capturing state at various snapshots and replaying forward at like 10x speed.

By making the roads single-direction and roads owning the movement, I think it’s been made equivalent to a conveyer belt… which means factorio’s conveyor belt optimizations might be relevant.

Eg storing the delta between items rather than tracking position directly, because the distance between cars is static for the length of the road, except during compression, insertion or removal of a car

https://www.factorio.com/blog/post/fff-176

Factorio is such a great example of how different the visuals can be from the underlying datastructure. Conveyor belts look hugely complex / heavyweight - if you consider them as individual items each with an x/y position that needs to be updated every tick. But if you see them as a linked list with only a distance and it becomes a lot simpler.

This post also explains why compressed belts are better for performance on very large bases. But despite 1000+ hours in the game I never reached a point where performance was an issue.

The distance is not static because of cars stopping for one another.

That’s the compression, same story in factorio. Before/after compression it’s static, so you can avoid having to update any value.

The main difference from factorio belts I think is actually in the insertion — if there’s no room in the belt, insertion is blocked; whereas I’d expect a car to “slip in”.

But I think you can still say that maintains the property that a compressed belt will always be compressed, excepting insert/removal; and insertion/removal just requires updating a static number of deltas (2, in the middle of the line, 1 at the end of it)

And Factorio belts can have stuff added or removed, also.

The thing is a belt is modeled in terms of deltas rather than positions--there is no need to move each object each cycle. An object has a distance from the object in front. When the belt moves forward this relationship does not change--no need to update every pointer (and there can be a *lot* of belts in the game!) If the head of a belt can't move you only need to update one delta--the gap between the first free item and the stuck item in front of it and that value can already be known, no need to search. If you move the free item up against the stuck item you walk down the belt to find the new first free item.

You only need to modify the belt model if something is either added or removed from the belt. Objects get removed only by inserters, inserters examine only one cell of the belt, grabbing anything in that cell that matches what they are willing to grab (if they are feeding a machine they will only grab what the machine wants, otherwise they'll respect the filter list assigned to them.) When something gets added to a belt you add it to the list and update the delta of the object behind. No general update of the belt is needed in any situation, any more than you need to do anything to the items in a queue as you add and remove items.

Factorio is a game about optimization and the developers did a very good job of applying that idea to the game math. That is, until the masses of asteroids in the Space Age DLC.

> further disincentives to having more than 2 kids.

I feel like it’d push for the return of station wagons over SUVs/Minivans, over fewer kids outright

> further inceitive for rich people to buy bigger cars, as they will be bigger status symbols for those with the write offs.

That seems to me quite negligible

I don’t know if it anyone was really making bets around it… it’s just kind of individually meaningless to implement support for until it’s already popular, because you still have to support IPv4 in full until the day you can remove it entirely

Per the article, it’s new to browsers, not compression generally, due to the lack of standardization. the future is already here, just not evenly distributed.

Isn’t that also like having two watches? You’ll never know the time

If you're on a desert island and you have 2 watches instead of 1, the probability of failure (defined as "don't know the time") within T years goes from p to p^2 + epsilon (where epsilon encapsulates things like correlated manufacturing defects).

So in a way, yes.

The main difference is that "don't know the time" is a trivial consequence, but "crash into a white truck at 70mph" is non-trivial.

But it's the same statistical reasoning.

It's different because the challenge with self-driving is not to know the exact time. You win for simply noticing the discrepancy and stopping.

Imagine if the watch simply tells you if it is safe to jump into the pool (depending on the time it may or may not have water). If watches conflict, you still win by not jumping.