The existence of individual vehicles with very high mileage doesn't feel like a good signal for overall reliability or maintenance req's over a lifespan. I did some brief searches and it seems there's a lot of "record-holding" gas vehicles with several million miles on them, some even claiming to be using original engines. Again though, I'm not sure this is a good representation of how reliable the vehicles are in aggregate.
I've used Colemak primarily for the past 5 or so years. However, the benefit is primarily in typing comfort and hand strain, not quite as much in speed, although it is probably marginally faster at its limits. I'm still fluent in QWERTY (I'm typing this message with qwerty to make sure it still works :)), so I can switch if needed, or if I'm using an unfamiliar computer (or a phone, etc). Moving to Colemak completely solved the frequent wrist and hand pain I got while typing using QWERTY. Others have had the same experience.
This is ignoring the fundamentally-different issue that was raised, which is that the service boundary introduces a new failure point that doesn't exist in a function call. What you're describing could just as easily happen in a service call, IN ADDITION to the service just not being reachable.
> For the probably best known example, Unity used to have an IMGUI [1] but they've actively moved away from it. It's still there in vestigial form, the API is not removed, but game developers don't really use it.
It's true that the newer retained mode GUI has supplanted the older IMGUI for "game UI" (e.g. what users interact with when playing an actual game built with Unity). On the other hand, the Unity editor itself is still built entirely with their immediate-mode GUI library, and I haven't heard of any plan to move away from that. Building "editor-like" tools (including custom user tools) is still significantly easier to accomplish using immediate-mode libraries.
In Unity you're still forced to use the IMGUI for making editor tools. In fact their new xml layout prototype still uses the IMGUI to draw an instantiated layout! What a mess...
> OpenAI has a list of something like 7 restrictions.
Some of those are very major, though, and I think the word "restriction" is a bit misleading. Having 5 invulnerable couriers is not really a "restriction" in that it limits or simplifies parts of the game -- it's just a fundamentally different mechanic that changes the way the game can be played.
> DotA players are probably the worst to ask, because the AI is already stronger than they are at a subset of the game and they have no insight into how quickly that subset could be generalised into other aspects.
I think that's a little unfair. Most folks have been pointing out that OpenAI's current momentum-based "deathball" strategy seems to fall apart without infinite regen and a limited hero pool, both facilitated by the current set of restrictions.
I'd agree that nobody really knows how well OpenAI will adapt to the full game, but I disagree that the criticisms I've seen are meritless. OpenAI's current level of play is definitely impressive, but I think there's still room for skepticism given the current restrictions. I (and I think a lot of others) would be pretty disappointed if the TI showmatch happened with the turbo mode couriers still enabled.
> I think that's a little unfair. Most folks have been pointing out that OpenAI's current momentum-based "deathball" strategy seems to fall apart without infinite regen and a limited hero pool, both facilitated by the current set of restrictions.
People said similar things about Go AIs and ko fights. And in the end it turned out that neural networks handled kos fine but ladders were a challenge.
On the deathball strategy in particular, consider that we expect a superhuman DotA AI to change the DotA metagame, so playing off-meta doesn't tell us anything. AlphaGo would invade 3-3 point a lot more enthusiastically than a human player. This was considered a classic beginner mistake for many years; now the theory has been readjusted to cope with the fact that AlphaGo stuck with it and just considered it a good move.
We can safely say that the courier change has made a deathball strategy more powerful and it seems quite likely it is not an optimum strategy. But we can't be sure until OpenAI tests it, and we absolutely can't be sure that OpenAI won't just learn a new style when the conditions change.
The criticisms have merit, but nobody has enough data predict anything about the future. Particularly a professional DotA player.
>I (and I think a lot of others) would be pretty disappointed if the TI showmatch happened with the turbo mode couriers still enabled.
Totally agree. This one change alone is _so central_ to both the bots laning strategies and meta-game team strategies. They can't just leave heroes in lanes forever no matter what, and have all 5 heroes literally never go back to the well if there aren't 5 couriers. Not to mention their initial item builds, stats-only-4-man-the-lane-for-first-blood bullshit wouldn't work at all without constant ferrying of regen on the couriers.
Indeed. And to explain further: not all hero combinations are equal. Meaning: you cannot select any arbitrary set of 5 heroes and expect them to perform well. Different heroes have different strengths and synergies that make them stronger or weaker depending on the specific teammates and opponents that are present. This is why drafting is considered such an important (and difficult) portion of the game. In match 3, a purposefully-bad team was selected. It would have been VERY impressive if it was able to win.
> Meaning: you cannot select any arbitrary set of 5 heroes and expect them to perform well.
When I think of AI, I think of something crawling its way out of purposefully adversarial situations such as this one. I would have loved to see optimal play from 5 wacky heroes.
I just have this suspicion that that wasn't optimal for that team comp.
I would disagree with that, especially with regards to Metal. It's a very approachable and well-designed API. It might not have the volume of resources that OpenGL does, but the docs themselves are good, and I have seen plenty of intro-level tutorials that are decent enough. Debuggability is also much better than OpenGL, which I think is important for newcomers. Debugging OpenGL issues is very, very painful, especially with macOS's lack of debug extensions. Metal is described as "low-level", but it's not quite at the level of Vulkan -- things are simpler and more "streamlined".
There's also the problem that a large chunk of OpenGL learning materials out there are hopelessly outdated, and IMO actively detrimental to learning modern graphics techniques. Judging from the types of questions I see around various forums, it seems to be VERY hard for newcomers to distinguish between "bad" and "good" OpenGL tutorials. In general, there's too much cruft for learners to focus in on the stuff that is actually part of "good OpenGL".
