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.
They had to do that legally. But that was only in the unpopular save the world stuff, I think the break out battle royale mode or later creative modes never had them.
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.
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.
Exactly, blueprints might be OK for opening a trigger when you open a door, but there are huge chunks or game logic that needs to be written by game designers.
Magic Armour gives you +15 health and Orcs spawn in the Forest after the Spider Queen is defeated.
You don't want to have to go to the programmers when the behavior of magic amour changes or when Orcs have some other prerequisite.
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.
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.
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?
> 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.
It's not and it does matter.
> And what does "legally mandating them" even mean?
Not sure how what's unclear about "legal mandate". If the law says, Google complies.
> The "security issues" exist regardless of this policy change - as I've already said.
They don't exist to the same extent, you repeating them doesn't make them more universal or true. Other vendors and forks exist, the simple existence of Google Play didn't mean every app is compromised by Google, now it will.
> Google could easily do whatever they want with your phone anyway due to control over system apps and the OS
Google doesn't control every vendor, controlling all signing keys is much easier than quite literally backdooring the OS for simply Google. There's a large difference in how visible any such malicious actions would be.
> As for "forced monetization", that's just reaching
Are YouTube's forced midroll ads "reaching" as well? There's no fundamental difference, they monetized someone else's content.
Controlling signing keys allows to simply patch the ads in. I'm not entirely sure why you don't see how it makes it easier for them.
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.
So? Presumably you are going to continue to interact with the app.
> .. in addition to a bunch of security issues.
What security issues?
> Also makes it possible to do forced monetization, like YouTube has done.
Forced monetization is an even stupider conspiracy than NSA spying since it would require wide use rather than targeted changes. This would be plainly obvious since there are loads of people who decompile apps and the signature on the code section would be broken.
> 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.
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 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. I also can’t sell any game I want on their platform. I have to follow their rules, get approval? Etc.
Not to mention video game exclusives. Why do I have to download Fortnite through the Epic Game Store and have an Epic account? Shouldn’t I be able to sign in with another provider? I should be able to download, install, and play Fortnite with my Steam account and buy and sell in game content via Steam or other providers. It seems like they are limiting competition by forcing me to use their login system and micro transaction platform.
I just don’t find the anger at the Apple App Store compelling. The only reason we are talking about it is because it’s a popular platform.
> 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.
> Obviously if the platform wasn't popular then no one would care and this case never would have happened.
Which I think strikes right at the point here. This is practiced throughout the world and throughout industries, but for some reason we think it should be different for mobile phones. I don't see why it should be, especially given that in the overall market, Epic can publish their game across multiple competing platforms: Android, Windows, macOS, Linux, Xbox, PlayStation, Switch, etc. and iOS until recently.
In fact, as you mentioned, if you don't like the Apple Store you can go to: Steam, itch.io, GOG, or host a website yourself. If I can't create an arbitrary game and have access to Epic's user base, I don't see how it's different. Can I use Epic accounts on my own indy game?
I think you are narrowly defining the marketplace as being only iOS, when in fact it's much larger, and you're not taking into account that this is all about access to users. In both of these areas, it's hard to find compelling activity for Epic. They can and do publish Fortnite on multiple platforms, and they also arbitrarily restrict access to their own user-base.
Epic just wants to have their cake and eat it too and I have yet to see compelling evidence to the contrary, myself.
>This is practiced throughout the world and throughout industries, but for some reason we think it should be different for mobile phones
uhh, no? Antitrust arises out of the core factor that "this platform is popular and people care". If people didn't care about Windows it wouldn't have gotten an antitrust in the 1990's. If people didn't care about Steel then the Rockerfellers wouldn't have gotten antitrust in 19th century.
Is very much is not different for phones. The only difference is that data doesn't take up physical space. But I hope we've progressed past the web 1.0 arguments on how data isn't powerful.
>n fact, as you mentioned, if you don't like the Apple Store you can go to: Steam, itch.io, GOG, or host a website yourself. If I can't create an arbitrary game and have access to Epic's user base, I don't see how it's different. Can I use Epic accounts on my own indy game?
Itch.io, Steam, Gog are not hosted on IOS. IOS has a marketplace of 10 billion and offers to host general applications, much like a PC (which has been hit by a case like this). Comparing this to selling fortnite skins is very dishonest and telling of your faith in this conversation.
>I have yet to see compelling evidence to the contrary, myself.
Lead a horse to water...
This is why I'm glad that this cases isn't being run by people who are just frustrated at not playing Hades a year earlier on steam.
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 see the argument as convicting for the same reason the person above is being dismissive: do people care?
If Facebook, Adobe, Twitter, and Discord care about hosting their apps on PSN, then there can be a case that this is a general purpose usage that should be allowed. In reality, I imagine they don't and even if Sony/Microsoft were forced to open up that their competing stores would be as thriving as those Custom Firmware homebrew stores.
Point #2: ephemerality. There's a 99.999% chance that the PS5 and XSX will be succeeded in a decade by the PS6 and the Xbox Whatever. Would Adobe want to spend all that development time releasing photoshop for PS5, only to need to re-develop it for PS6 6 years later? For what is likely to be an entierly new OS?
in contrast, there's good odds that an app made in 2010 would still work just fine today, barring some outdated Api calls that Google/Apple made great strides to ease the migration on. So that security on not needing to change OS's every generation would incentivize development.
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.
> said companies might not have even thought about trying to do something with those platforms because it was assumed impossible
We know now that Epic (obviously) wanted to open negotiaions with Nintendo on EGS deals, even if they haven't started yet and are considered a shot to the moon. I'd be surprised if other companies never put even a bit of thought into the alternate platforms. That is partially was why the court subpeona'd the entire industry for questions and arguments.
>With how much mobile OSs change I'm not sure it's relevant.
I say it's relevant because part of the marketing of app versions is how (relatively) easy it is to migrate, often including automated tools for the job. I highly dought Nintendo and Sony offer similar things (maybe Microsoft). As such they want to encourage that longevity as long as the dev in intersted in maintaining. So it again comes from "do they care"? Google and Apple do.
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).
It should also be noted that consoles are 1-2 systems specs, and some games highly, highly optimize for that spec. So mimgration is naturally harder because consoles generally give devs almost a full memory block to work with, compared to, say, Window's non-guarantee of memory layout.
> 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.
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.
The fact that it works with any iPhone /is/ the innovation. I would imagine less than 0,5% of iPhone users has the Tile app installed. A worldwide network of connected iPhones will make this technology finally worth using.
Tile charges for that feature, and harasses you in app until you pay the sub. Tiles only works with phones, any apple device supporting the “find my” protocol can report the position of a tag.
Integration into the Apple ecosystem is another huge one that Tile refused.
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.
True but all it takes to fix this is to add if on the reference count of the object. You only need a full scan to handle circular references. You could have a gc.collect(obj) which will collect this object and all of its dependencies provided their reference count has gone to zero. And otherwise do nothing until the next full garbage collection.
There are GCs that take this approach (refcount + sweeps to break cycles). It has tradeoffs however.
- Extra space for every object to have a refcount
- Extra refcount bookkeeping every time you (re)assign a reference (possibly triggering cache thrashing/false sharing in some multithreaded scenarios), xchgs instead of movs, etc.
- Pointless if you're using bump allocators (they can't reuse the 'freed' memory until the next GC cycle compacts memory anyways), so you're forced to use more complicated allocator designs if you're to reuse said memory.
Cycles mean it still doesn't give you 100% deterministic object destruction either, so you want extra mechanisms for disposing unmanaged resources at controlled times ala IDisposable anyways.
They don't define which algorithms are to be used, and at least in what concerns Java, there are some implementations that experimented with reference counting based GCs.
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.
I'm not disputing that IronPython can be useful (although one also has to consider https://github.com/pythonnet/pythonnet, which wraps CPython into an IronPython-like projection). But if it can't share the library ecosystem, it might as well be a different language for all practical purposes. And it turned out that there aren't enough people who were interested in a Python/.NET combo for its own sake, so it remained niche. Any new implementation of Python on top of .NET VM would likely get similar reception for all the same reasons.
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.
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.