There's still something to be said about the addictive nature of microtransactions, but loot boxes haven't been relevant to the discussion as far as fortnite goes for a few years.
Fair enough. If you're working on smaller projects I totally understand where you're coming from. Unreal's workflows are very much built with an eye towards large teams/AAA where there's a very hard division between engineering/design/art, and having a simpler language (blueprint) that doesn't require much training and that engineering teams can use to expose just what's necessary is a benefit rather than a detriment.
Unfortunately Unreal doesn't really have a middle ground - something between the complexity of C++ and the simplicity of Blueprint. There's been rumblings of a new text-based scripting language (Verse - https://twitter.com/saji8k/status/1339709691564179464) but it hasn't been officially commented on by Epic outside of a single presentation where it was shown in relation to Fortnite.
Because they aren't meant for you (assuming you're an engineer). They're meant for level scripting, simple prototyping, stringing together systems written in lower level (C++) code, and beginners.
They absolutely don't suck when used in the intended way. I'm not a fan of writing code in visual languages either (worse information density, slower to write the code, harder to debug) but if all you're doing is wiring up some triggers in a level? Hell yeah, it's great. Need to fire a bunch of events over time, maybe do some super simple code-drive animation? Timelines and latent actions are way easier than the textual equivalents. And extending it is dead simple which makes it easy to write something in C++ to be used from Blueprint.
It's also worth noting that Unreal's C++ has many of the niceties of C#. I won't say it's as easy to use (it isn't) or that Unreal gets rid of some of the eccentricities of the language or build system (it doesn't, and Unreal's build system - while nice - is incredibly under documented), but Unreal does provide garbage collection (and even reflection) which takes a big part of the burden of C++ away.
There's a question of whether newer generations of consoles count as having different app stores, which would change those numbers. Does having a different store platform make it count separately? Does having a new generation of device count separately? Or is it any user of any store platform owned by a single company?
For example, the Xbox One and Xbox Series X use the same store but they're different generations of Xbox. Do you count those users together or not? If those aren't counted together, what about mid-generation refreshes like the Xbox One S or Xbox One X?
If generations are counted separately, what about iPhone generations? Or the fact that Android isn't even based around generations since there are multiple manufacturers?
And there's the question of what counts as a user for the purpose of this bill - would anyone who has ever bought into the ecosystem count? Or would it be something like monthly active users?
The intention here is obviously to go after Apple/Google, but the wording of the user count just seems way too open as to make it unclear if markets outside of the mobile space are affected.
Full disclosure, I work for Microsoft and Xbox. I have feelings about how this would affect Xbox (which would obviously be biased), but even without getting to them it's unclear whether this bill would even be relevant.
I was mistaken - you're right that you can't keep app data. It still doesn't matter because they already have easier ways of running whatever code they want on phones with Google play.
> Not sure how what's unclear about "legal mandate". If the law says, Google complies.
I mean that I don't understand what your original statement was. Is it that governments can force google to hand over your signing keys? I agree that it is a concern, it just isn't the issue I was commenting on. I didn't mean to bring that into this - I just didn't understand your meaning.
> Google doesn't control every vendor
They don't need to. They already have system apps on every phone running Google play, which is the exact same list of devices that will be affected by this change. You're right that they don't control every (or even most) OS vendors for Android, but they don't need to.
> Are YouTube's forced midroll ads "reaching" as well? There's no fundamental difference, they monetized someone else's content.
I'm not debating whether midroll ads are right or wrong, I'm debating the technical merits of this incredibly roundabout method.
"Patching ads in" on an app-by-app basis is nonsense - why not just add it to some hooks in Google play services? Not to mention they'd have to make sure it doesn't break the apps themselves. Why waste the time and money? Hell, force app developers to insert code into their own apps by changing the policies on the store. I bet it's result in a lesser outcry than if they did it secretly. Signing keys as a conspiracy to show more ads is ridiculous when they have better vectors elsewhere.
I believe it's possible to keep an app's data on uninstall. It's not the default behavior, but that doesn't really matter in this case.
> Much harder for Google (or anyone legally mandating them) to get caught with AABs though.
Not really. And what does "legally mandating them" even mean? This is a policy change for the play store, it has nothing to do with legality.
> ... in addition to a bunch of security issues. Also makes it possible to do forced monetization, like YouTube has done.
The "security issues" exist regardless of this policy change - as I've already said, Google could easily do whatever they want with your phone anyway due to control over system apps and the OS. I have security concerns with Google being the sole owner of the signing keys, but that's not related to Google themselves acting maliciously.
As for "forced monetization", that's just reaching - if they were going to force monetization on apps that weren't their own then they just need to require it of developers on the play store. How does the ability to ship modified bundles make this any easier for them?
Re: 1 - Sure they can. The play store has the ability to both uninstall and install apps without direct user input. Even if the OS itself blocks updating an app with a different key, it doesn't block uninstalling and then reinstalling with a different key to my knowledge.
AABs are hardly required for Google to inject their own code into apps. And honestly, why would you even be concerned about them injecting code into third party apps? If they really wanted to be malicious they could use system apps that they fully control anyway.
I do have concerns with Google removing the ability for developers to sign apps but Google themselves acting maliciously isn't why.
> consoles make no such guarantee. Some years after the next gen becomes current gen, they will leave no option to submit previous generation titles. Both in a physical (stop accepting submissions) and marketing sense (less updates to older consoles, usually just security patches).
No, but the maintained lifetime of a game is usually shorter than a full console cycle (within which you absolutely do have that guarantee) so this doesn't affect those games. It's also worth noting that games that came out in 2013 for the X1/PS4 should still run on their newer counterparts with no changes (though this degree of back compat is at least somewhat unusual, so I'll give you that). On the other hand, the mobile space sees many apps get entirely redesigned multiple times in a decade.
> It should also be noted that consoles are 1-2 systems specs, and some games highly, highly optimize for that spec.
First of all, games tend to be optimized for specific hardware features, with "notches" to turn on additional features in the game for each main target spec. Most games these days ship on multiple platforms including PC so the idea that they're optimized for a specific platform isn't really true anymore. Second of all, the previous and current generations added new specs (X1X and PS4 Pro, PS4 -> PS5 and X1 -> XS back compat, XSS/XSX hardware differences) without breaking any compatibility by keeping general architectures the same with some extra support in the OS to smooth over the places that it differs.
> So mimgration [sic] is naturally harder because consoles generally give devs almost a full memory block to work with
This only complicates migrating to platforms that don't use a unified memory architecture and dedicated system resources, it has nothing to do with updating for new console generations.
The problem with this line of reasoning is that said companies might not have even thought about trying to do something with those platforms because it was assumed impossible, and they didn't want to go through the effort of a court case to make it so. It's hard to say what would happen if consoles opened up without it actually happening.
> Point #2: ephemerality.
With how much mobile OSs change I'm not sure it's relevant. Apps that aren't kept up to date (esp. when it comes to changes in how the system manages privacy settings) tend to be delisted, and the rate at which those changes happen is much faster than the 7-10 year console cycles where backwards compatibility is a requirement even when major parts of the OS change (see: Win8 -> Win10 kernel transition in the early days of the X1). Admittedly, keeping up with mobile OS changes doesn't usually require a full rewrite of the app, but neither did anything moving from X1/PS4 to XSX/PS5.
There's still something to be said about the addictive nature of microtransactions, but loot boxes haven't been relevant to the discussion as far as fortnite goes for a few years.