Thursday, 14 February 2019

Updating Rust Nightly

So Rust has a pretty usable nightly build. Actually it has an extremely usable nightly build that also keeps a huge set of powerful features siloed off from the stable branch (behind feature gates so you can turn on just the stuff you want to play with rather than being dumped into a thousand things that have been deemed to not actually be ready for prime-time yet). That attracts a lot of users to keep on nightly rather than stable (or the beta that is one update ahead of stable but also lacks nightly's features and so is the mid-ground no one uses unless they really believe in helping test the next stable for the public good). However, nightly isn't perfect(ly stable) and right now is a great example of where the update tools feel like they come up short vs the usability that is visible everywhere else for the Rust language ecosystem.

>rustup update

"error: some components unavailable for download: 'clippy', 'rls', 'rustfmt'".

As primarily a user of VSCode for Rust (also sometimes a JetBrains IDE, although the Community Edition plugin lacks any debugging feature so I'll revert to VSCode to debug) then the RLS isn't really optional. It is good that the updater tells me after finding that some of the components I have installed in the toolchain I asked to update are missing from last night's build. However, it does not then go on to give me any information about how I can get from however old my last installed version was to the last good nightly build.

As best I can work out, I have to browse to a site tracking the nightly builds by component and then tell rustup to update to the date last shown to have built correctly. But that's not actually the end of this story (which would be a bit of lack of useful info but not totally weird to not get that added info directly on the command line).

The behaviour of rustup update <dated nightly version> is not to update the nightly toolchain install already on your system but to install a second toolchain (the help does make it clear that you are effectively just running rustup toolchain install when you provide a toolchain argument). So now I've got a second toolchain installed with the last dated good build I took from that tracking site, except it's a default install so those optional components that I needed and weren't available in last night's nightly? Those didn't automatically get added to my new toolchain install (and for my use, they are not optional - if I could live without them then I could just force the update and it would wipe over the old stuff with the partially working current nightly). So now I have to go through the process of requesting those components be added.

None of this is the end of the world. Many other toolchain ecosystems are no better (and some are worse) when it comes to updating. But there is clearly room for improvement here and this is one of those pain points where a new Rust dev who is not used to any of this may not even really understand what's going on (after someone told them nightly was totally fine and just install that). Either they can't update or, worse, they end up with a VSCode IDE that has no RLS (and no way to get a corresponding RLS as that part of the nightly build is broken right now) which means it's not behaving like they expect it to.

A typical dev who is asking to update their nightly build probably wants to get the latest nightly that has all the components working that they have installed. That seems like a safe default to assume, maybe with a Y/N prompt after the error message rather than silently updating (if we are to be cautious). Leaving them with a potentially weeks or months old nightly (where they're potentially behind stable - not that hard for sporadic Rust users with the 6 week cadence of new stable versions and reasons to prefer nightly) because last night's build didn't work (and no easy way to update without just starting to install a totally new toolchain from scratch) does not seem like a suitable behaviour.

Thursday, 7 February 2019

Shooting into February 2019

There sure are a lot of AAA shooter titles landing this month. Many of them have had a very long and public development process with much of their team's (or even entire studio's) future being weighed on if they find success. Quite a few public betas have been going on, because almost everything (even the solo-able experience) is a multiplayer co-operative game today. And then EA went and made it even more of a month of riches by not only announcing Respawn's Battle Royale entry but also releasing it onto PCs and console the same day they announced it.

I'm actually going to start be rewinding into the final days of last month for the first game getting some quick commentary. Resident Evil 2 was a project that could have fallen apart extremely easily. Remaking a 21 year old title in a genre whose popularity has been up and down, bringing back most of the story beats and even design decisions while completely remaking the visuals and how the game controls (goodbye fixed cameras). And yet, what has arrived is both a great recollection of what has always worked for horror games along with enough new to feel modern and accessible. This should end up in classrooms as an example of how to refresh old games while retaining their identity.

The big title from EA, the one you'd actually expect them to make space for and not throw out an online competitive shooter merely weeks before launch, is Anthem. BioWare have been having a hard time recently, with various teams being given their branding and releasing things of questionable quality (and some extremely short deadlines seemingly responsible for those quality control issues - the way so many PC RPG studios have died before) but this is the big hope: a brand new IP that carves a living world around the upward swing to how shooting felt in the most recent Mass Effect games.

Unfortunately, if the demos are anything to go by, that shooting doesn't feel any more inspired here than it has done in those RPGs (where the narrative was the main point of playing). A light affair, lacking in feedback from the bullet sponge enemies or in terms of interface reactivity; I found almost nothing to keep me engaged in the combat scenarios (which seem to be stock wave-based exercises just as each of the weapons feels like well-worn archetypes). The visuals show off Frostbite but also leave you wondering how much world there is to explore, as does the lack of narrative content on display. It feels like this could easily be forgotten in a month, not even managing to equal something like a Destiny (2) in keeping players engaged through a diverse selection of skyboxes as the campaign story gave a reason to enjoy the excellent feeling shooting. That comparison feels like an area where Anthem could end up coming up short in every way.

And loading up EA's Origin right now, there is a much better feeling shooter they just released. Respawn's Apex Legends is doing just about enough new for Battle Royale games, while keeping it F2P to avoid there being a barrier to entry. It's great timing for anyone falling off Call of Duty's mode but unwilling to jump to the construction combat of the market leader. It's fun, bright, feels good to aim and shoot, and hopefully will slowly expand over time as long as the players continue to engage with it. That Titanfall heritage is clearly there, even without the wall-running mobility.

Jumping forward in time, The Division 2 is not releasing until March but that means the Ubisoft betas are all over this month. One of the things that the move to DC in the summer makes clear is that Manhattan under a ton of snow really made the last game. This has every sign of being more of the same, only with some slightly rearranged progression that better leads into an end-game situation (rather than keeping a treadmill for the campaign and falling off the end outside of PvP in the Dark Zones). I've found myself having a hard time going back three years later and the always-connected stuff will probably keep me away (as a server disconnect wipes out half an hour of progress and dumps my avatar at the entry lobby to a mission rather than saving any of the checkpoints I'd progressed through). There's just so much else I could be doing for putting up with stuff like this in 2019. One final aside: remember when Massive Entertainment were pulled off supporting that first game and put onto a James Cameron's Avatar project? I wonder if that went sideways because it sure feels like it's been a while.

Before The Division 2 comes out, Ubisoft are also throwing out Far Cry: New Dawn. I can't say that reskinning the Far Cry 5 map for a post apocalyptic cash-in is getting me in any way excited for even more Far Cry. Everything about the branding for this makes me think it'll be completely forgotten in a few months when Rage 2 comes out, even if that game doesn't turn out particularly well. I wonder who asked for this, or if it was just a pivot when Far Cry 5 didn't do that well for the team that was planning on making DLC.

Returning to games which have gone through extremely long and public development cycles, Crackdown 3 is coming soon. Yes, "cloud physics" multiplayer and all. My expectations are in the gutter at this point so time to wait for reviews on this one.

Finally for this compilation of thoughts, Metro Exodus is yet another shooter coming this month and everything they've put out about that more open world makes me think this'll be where I find something special this month. It's interesting that it's courted more controversy for the PC digital store it's on (Epic Store, after being pre-sold on Steam for a while - where it will apparently get distributed to those customers) than the contents of the actual game. As a solo game without a constant server connection, I'm not sure where you get it from really matters that much (as long as the CDN server continues to exist to serve the download files at high speed in the future). A more open game world with light survival elements and a lot of nods to HL2-style storytelling? I think I just accidentally described about half of this list of games to various degrees.

What a lot of shooters!

Sunday, 13 January 2019

A New Console Generation

So I've engaged in mild speculation on new console specs in the past. We're getting to the point where there should be some new consoles coming. It lines up pretty well with (large chip) mass production 7nm in the coming year or two so everyone will be ready to offer powerful SoCs with high power efficiency for console enclosures. A 2020 release is 7 years on from the current high fidelity consoles - very normal for the console upgrade cadence. Even the half-generation updates would be getting on by the end of 2020: four years after the PS4 Pro was released.

Phil Spencer was at CES talking up their continuing partnership with AMD, which certainly sounds like an ongoing use of their IP (makes a lot of sense - AMD have all the IP under one roof and a track record; Jaguar cores are going to get a substantial update with a Zen derivative; and the MCP design AMD are working with could be a good match for a console that will live through at least a couple of die shrinks while uncertain about how much of a monolithic SoC would benefit from that). Vega (and even lower end Polaris) are not leading the power efficiency war but at this point everyone is experienced in making GCN work well and there are still a few bad memories around nVidia. Everyone hopes that the next Vega is going to bring that power efficiency to where nVidia are at on 12nm (if they can't when a generation ahead at 7nm and not wasting any transistors on speculative features, something will be going very wrong). There is also the deep in development Navi so even without turning it around next month, the future may be bright. The only wildcard would be Intel trying to sell their 2020 GPU design to Sony or MS (or even offering an AMD GPU: did not see that coming a year ago) - very long odds in my book but worth mentioning as Intel make a big move to compete on high end GPUs to avoid seeing server farms filled with expensive nVidia chips (getting a foot in the door with Tensor etc specialised silicon to expand their use cases). [Those with a long memory will remember that nVidia were paid by Intel to relinquish any claim to be able to provide x86 chips and so can't offer a complete package that would enable a rolling window of compatibility.]

I'm going to say that odds are good for something like a CCX cluster (4 Zen cores) or two with a pretty large Navi GPU block. What I'm curious about: what if the next Xbox is two new Xboxes? Rather than releasing one console then doing a major redesign when the power requirements are lower, what if there is a constant pair of consoles, like we have now. The next Xbox as a high end system with at least 8 Zen cores and a big Navi block. $500 at the end of 2020 with enough fast RAM to avoid the issues that plagued the original XB1 [forced to waste die space on extra cache to make up for slow RAM] and hopefully at least a PCI-E SSD cache (128GB? 256GB? Big SSD premium SKU?) to avoid the loading times getting even worse (even if most downloads and game installs would live on a large platter drive for cost reasons, even with NAND getting cheaper - 500GB is floating around $100 right now so maybe prices can drop to make an SSD-only next gen happen with support for archiving to external storage via USB).

But the XB1X isn't that old and isn't a terrible target for an entry-level spec for games going forward from 2020. There would probably be a way to make a reasonably good approximation of that system using a smaller Zen cluster and much smaller Navi block (cheaper/less RAM and no SSD cache). Something that would run existing games just like an XB1X, with minimal shims to catch edge cases (in the low level API calls). Something that would effectively be sold as both the cheap entry to the next generation and the "Slim" edition of the XB1X. Something to ensure developers continue to make sure their new games work for existing XB1X customers (with whatever compromises were required for performance) while dropping support for new games on the anaemic XB1/XB1S system. The fact that the XB1S isn't identical to the original XB1 shows that the ecosystem is already built around supporting two low end specs that are only approximately the same.

When the next high end Xbox is ready for a slim-down, it might be time to look at another step forward (an "XB2X") and which devices get guaranteed access to 100% of new releases going forward (and which platforms are something a developer could optionally support in a "cross-buy" style system). Have two or three models always "current" that cycle out every three to five years until they can no longer continue to offer the right shims to ensure compatibility with their API choices. It would certainly be something not totally out of step with the current MS talk of slowly expanding their cloud gaming offerings (on TVs, tablets, and laptops) and making games work anywhere (Windows PCs and Xbox devices). It's the realisation of much of the "what if more like annual tablet/phone updates" talk from about five years ago.