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.
The argument is that things should be different for a platform that isn't easily substituted. EGS is easily substituted for Steam because there are no barriers to which store you use on PC aside from installing a new one, and using multiple at a time isn't even much of a burden. The App Store is not easily substituted for anything because there are no major alternatives in the mobile space that don't have the same restrictions, and even ignoring that there's an argument to be made about the cost (monetary and otherwise) to switch platforms that is _much_ higher than switching storefronts on PC.
The one segment you've mentioned that actually works similarly is consoles - Xbox/PlayStation/Switch. These operate much the same way as the App Store and are the reason I myself am torn on whether I agree with Epic. Their argument for why consoles do _not_ apply here is that they are not intended as "general purpose" devices the way a PC or phone is. I don't know if I believe that argument to be convincing, but I absolutely see where they are coming from with everything else.
> I think you are narrowly defining the marketplace as being only iOS, when in fact it's much larger
For the record, a big part of the court case has been (and likely will continue to be) about this point - does it make sense to segment the market in this way?
> I can’t sell my own Fortnite skins, for example. If I wanted to access the Fortnite user base I have to use the Epic Game Store.
You're right - and Epic isn't arguing that they have to be let on to the App Store, except in the case where there's no alternative. Ignoring the fact that Fortnite isn't actually a platform that allows you to submit skins to Epic (and as such isn't really comparable), you absolutely can make your own skins and 3d models and content and sell them somewhere else, you just can't in Fortnite.
And before you say "oh but they can just go to Android" - no, they can't, because Google Play has similar restrictions and while making a separate store is possible it isn't practical due to technical restrictions Google imposes on the OS.
> I also can’t sell any game I want on their platform. I have to follow their rules, get approval? Etc.
I've already addressed this. On iOS it is impossible to sell an app outside of the app store. If you're denied from EGS you can just go to Steam, itch.io, GOG, or host a website yourself.
> Not to mention video game exclusives.
This is a completely unrelated issue. The court case is about the rights of a developer and their relationship to the app store. This argument is about the rights of a consumer and I do not see it as even remotely relevant.
> The only reason we are talking about it is because it’s a popular platform.
You're right - the platform being popular is what gives Epic's argument merit. It makes Epic less able to ignore the app store if they want to go after the mobile market. Obviously if the platform wasn't popular then no one would care and this case never would have happened.
Because EGS isn't the only store on the platform - if you can't sell through their store you can go elsewhere (or DIY it). They aren't obligated to sell your products, but you also aren't obligated to sell via their store.
On iOS it's outright impossible to have a native app that isn't distributed through the app store (testflight/enterprise apps aside). With Google Play it's technically possible but you're at a massive disadvantage not just due to Google Play's reach (which is fine) but due to technical and contractual limitations imposed by Google themselves (which is arguably not fine).
> I'm not following. You can literally just go to a Best Buy and gaze at lots of different phone models to see for yourself. It's very realistic.
I agree with you here - this is a bad comparison, it's incredibly easy to just go buy something that isn't iOS-based - but that doesn't actually help much, at least from Epic's perspective. In fact, Epic is suing Google over how they treat Android as well:
* Google Play has similar restrictions to the iOS App Store, therefore neither Fortnite (assuming they want their own payment processing) nor EGS can exist on it.
* Sideloading is possible (and was/is (?) used for Fortnite) so that at least is fine, however...
* Sideloaded apps lose out on some important features - namely that they can't auto-update. Technically, this isn't a sideloading restriction but a restriction on non-system apps but the result is the same. System apps cannot be installed except via an OS flash (with a custom ROM)/root which is not something you can expect the average consumer to do.
* Additionally, Epic cannot make deals with manufacturers to get EGS installed as a system app due to Google blocking them from making those deals.
I have mixed feelings overall on whether we should be giving more opportunities for manufacturers to install possible bloatware on phones (something that plagued the early days of Android and still does to some degree) and whether it's a good idea to open up sideloading system apps. But even so, you have to admit that you can't "just" buy another phone to be able to do what Epic wants. Whether that's worthy of antitrust action... I really don't know.
I don't have one so I can't conclusively say either way, but it seems like the only "innovation" Apple can probably claim over Tile is that every iPhone should support the network out of the box (I assume) rather than having to rely only on people who already have the app.
There's an inherent issue with doing that while still being safe: what if there's still a reference to your "big object" somewhere? The only way for the runtime to know for certain it's safe to delete the object is to effectively run the GC anyway. The alternative is that the object gets deleted without any checks and any references to it will now (probably) cause a crash - and it'll be a hard native crash rather than a .net exception since it's outright accessing invalid memory rather than just a "managed" null pointer.
There's probably something to be said for allowing such a thing in explicitly "unsafe" code, but not in the normal runtime. In fact, it might even be possible now by leveraging some of the existing unsafe bits in .net.
If you're using IronPython then you're probably just trying to embed a familiar scripting language into something, not trying to adopt the Python ecosystem.
Besides, while you lose out on Python's native ecosystem you gain access to all of .net's.
From what I can tell Epic has two (three, depending on how you count) main arguments against Google. The first is what you mentioned - that they _do_ have the option of sideloading an app like Fortnite. The problem being that they lose out on a massive market because they don't want to use Google's IAPs. This is made worse by the fact that Android gives "scary" warnings when trying to install an app from an untrusted source - which is arguably a good thing for safety/security, but at the same time questionable when Google also benefits from it.
The other issue is that Google actively makes it harder for an alternative storefront to operate on Android by forcing OEMs to only include the Play Store (though I think OEM's own stores might also be acceptable? not sure) if they want Google Play Services (which most apps require). Which means Epic can't go out and make a deal with an OEM to add the Epic Store (or possibly even just a single app like Fortnite that doesn't use Google's IAPs, not sure) to an Android device because said OEM would have to drop Google Play Services.
And they can't just tell you to download the store - there are limitations that you cannot bypass without being a system app (i.e. something preinstalled). The most notable one for a store being that it can't auto-update other applications.
The team that works on the mainline Elder Scrolls games hasn't so much as touched MMO or GAAS games - they've been working on Starfield which we know next to nothing about, but there's been no indication it's an online game. Even before that they made Fallout 4 which was a traditional singleplayer game.
ESO is by ZeniMax Online Studios and FO76 is by a separate studio inside Bethesda Game Studios. Nothing to do with the team that works on mainline TES and FO games.
Browsers largely aren't taking advantage of native UI frameworks (aside maybe from the window chrome and basic controls). Aside from the minimum required to get an OpenGL context (or whatever graphics tech) onto the screen they don't need to build on native UI.
Sure, they're technically building on top of the native UI frameworks, but only by completely ignoring all of their functionality.
It's not evidence of anything because it's possible Facebook's ability to subvert elections could have been even more damaging if it were controlled directly by a foreign power.
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.