Thanks to the magic of Google, I've learned that Mexican scorpion antivenom was in fact developed in Mexico, by a Mexican company, and now you did too.
Weird, I have a friend who's a hardcore DA fan, and he liked it, but told me it's very different.
Tbh, I think the issue is that old RPG designers understood players have very different values and goals, hell they even wrote some academic articles on it:
The devs of today played the games of yesterday, and felt that the game catered to them, and then sought out making a game like that, but they didn't put in the effort or consideration to appeal to other kinds of players.
And turns out there's economics involved - while people playing shooters want to shoot people in general, RPG players are a diverse bunch with different needs, and if you don't scratch the itch of a certain subgroup, that's part of the audience gone.
Which results in a bomb - a game made for 20% of the playerbase will sell 20% of the copies, and will be a flop.
I think it is also that DA intentionally had a very complex story tapestry, mostly tried to avoid resets between games, and Veilguard went very deep in Elf and Mage storylines at something of a cost of other storylines. If you were very invested in Elf and Mage storylines (say you had been playing and/or romancing Elves and Mages and Elf Mages since DA:O) then Veilguard was extremely personal and culminated a lot of deep lore things and personal stakes things. On the other hand if you didn't side that way/play that way, I could see it feeling a lot less memorable/important.
I disagree. This is the strategy taken by AAA games and is the reason why the AAA games are in such rough shape.
A game that tries to appeal to 100% of people will, at best, be a lowest-common-denominator mess, and very likely manage to turn off everyone because it includes something that they actively don't want in their game.
A game that targets a specific niche while not caring about others does not have that problem. Because the target audience is smaller, it can't support enormous budgets, but enormous budgets don't usually mean the difference between a good and bad game. And a game targeting a niche takes less money to develop, anyway.
I'm not sure it's the niche or targeting problem. I think we're getting games with flat out fewer features and smaller scope than earlier entries in the series because _so_ much energy is disproportionately put into graphics. DA:VG was trimmed and had vastly less complexity and depth than any previous DA.
I'm not certain if that's time/budget versus "simplifying the game for everyone".
It's easier to balance a game with 10 "sets" of armor + weapon - as opposed to having a myriad options of armor per body part and weapon combos/etc. DA:VG was the most beautiful but shallow Dragon Age game.
Graphics is part of the problem, certainly, but at least it's moderately independent of the rest. You can scale the quality up and down without affecting the rest (within limits: having many armor variants, etc. are more costly with greater graphic fidelity). As far as the rest: all of these different gameplay mechanics have a complexity cost. You can try to add everything, but then you run into balance problems and/or it just feels too complex for most people, not to mention having a high development cost. So something needs to be simplified, and that means either reducing the depth or reducing the mechanics. But if you've already decided to include something for everyone, that necessarily means that everything is shallow.
Halo went from <200 people making a game from scratch to >2k people making the same game on an engine (without multiplayer) - so the design scope is even smaller now.
I don't get how you can lower the scope, have 10x the staff, and still overwork yourself - I mean, I certainly think it's possible, but that speaks of colossal mismanagement.
I mean the graphics got better (not that anyone cares, people still play old games, if graphics were a true differentiator, people would say new games are better because they look better, but they don't).
This is very hard to explain - and so expensive it's actively killing the industry.
> market for small, portable nuclear reactors is exclusively limited to submarines and aircraft carriers
SMRs are being commercialized. Likewise nuclear cargo ships have been seriously studies. Nuclear reactor powered (not just RTG) satellites have been built.
I know this is beside your point, but I think if we figured out how to commercialize this, demand would come.
It is, because just like you mentioned, there's no exponential physics to back up growth. LLMs have to stop scaling up compute, because there's only so much resources.
But even if we think back to the previous decade or two (sans AI), most of tech has been a a red queen's race - developing and improving stuff, without any real substantial results.
Microservices and orchestration are not better than old monoliths. Electron apps are not better than native. Most programs people actually use have decades-old codebases.
Video games of today don't look substantially better or play different than ones from 15 years ago.
This is an entirely different toolchain from the official .NET one, which is kind of the point of the post. It is experimental, but intended to for production, not for beating benchmarks.
Rust also builds a pretty small binary, which is cool. This isn't really meant to be a 'C# is better than Rust' post, but more pointing out that Blazor (which is the official MS implementation) builds huge binaries; often >10MB, which is a real problem. This fixes that.
That's because Blazor runs on top of Mono not .NET proper if you're using WASM for Blazor, but you can also do server-rendered Blazor and all of that becomes moot.
Not really. Anthropic’s headcount isn’t huge, and only a subset of their employees are working on the frontier. It’s also easier when you’re a follower.
Reading the claroty article mentioning nginx, I think it's more likely that their decompiler is just setup to use windows semantics since that's probably a majority of what they analyze.
Iirc LPCTSTR is just an alias for const char* , lp being an anachromism of "long pointer" held over from the days when needing to do a distinction for "flat" 32bit pointers since there already was "near" and "far" pointers during the x86 16bit era.
https://synapse.patsnap.com/article/what-is-serum-antiscorpi...
reply