It’s not entirely about the %. The problem is that there’s no alternative. I have no real problem with someone like Google with the Play Store or Valve with Steam giving developers the option of shipping on their platforms for a commission like 30%, because you don’t need the Play Store to install apps nor Steam to install video games. In those cases it can actually be a decision about whether or not the hosting/visibility/platform is _worth_ the cut. But in Apple’s case there is no decision to be made. You can’t opt out. That’s why you see so much more flak thrown at Apple for this commission than you do other platform providers.
If they open it up, market forces (via competition) will determine what is fair. That equilibrium would probably be below 30% if serious competition occurs.
But yes, it would be fair for Apple to ask for 30% because others are free to offer the same service for less, and you as a consumer of that service have a choice between them - which will eventually force Apple to bring its commission down.
Of course, I think most money comes from IAPs, not app downloads. The issue then is whether Apple would be forced to open the payment APIs, or if apps would need to implement a separate solution.
An alternative would be to open up the payment provider api to different processors.
For example if my bank implements the payment provider API, then let me use that. All the other apps need to care about is a payment request method which can be satisfied with whatever payment provider I have picked.
Apps would be able to ask the provider how much they’re gonna get after the payment processes etc, and decide if they want to reject it or not.
That's not how corporate commercial agreements work.. apple would better immediately bogged down in multiple, endless negotiations and trial periods. As a developer, I don't think you should want apple involved in your processor choice at all
I think so. If apps could do their own payment processing and still decide to use the apple one, it means it was a fair deal. Rather than it being forced on them.
The problem is large companies bundle too much market power together. If you want to avoid paying App Store fees currently you have to pull off a Herculean effort no company in existence is capable of.
By this are you saying your “app” project is the one that actually transpiles the TS from your shared packages?
Wouldn’t that mean the shared packages tsconfigs aren’t respected if you changed something like strict options? And also that a clean build of the whole monorepo is going to recompile each shared file for every app project rather than just once?
Oof I’m in exactly the same spot at work for a project I’m running. It seems so close but every step forward seems to be uncovering one more step before the finish line.
Regardless of Deno, I've been leaning more and more towards dprint over Prettier recently given how fast and configurable it is.
I get Prettier's whole shtick about not being configurable so that your team can't fight over a style guide, but as a team that already had an internal style guide that predates Prettier, I just want a tool that can match what we have already decided on, which is where dprint has fit in nicely.
You can give Simple Rockets 2 a try in the meantime. It uses fully customizable procedural parts (wings, fuel tanks, even engines) instead of premade parts like KSP, it looks a bit nicer and it includes a visual programming environment for your spacecraft (e.g. you can build a SpaceX-like autoland routine).
I've never tried Simple Rocket, could you compare it to KSP? At a glance, it seems more serious than KSP while KSP has a "fun" edge, but besides that they seem more similar than not.
SR2 is a little bit more serious than KSP, I'd say, but it's no Orbiter either. They use a smaller-size solar system (bigger than KSP though) by default (you can swap it out for a community created realistic system in-game), so you can still brute-force to orbit or build a SSTO and it will kinda work.
What I love about SR2 is the aerodynamics and the procedural parts. You can create an airplane and design its wings and control surfaces by hand, you can play with the center of gravity, custom fit it with a jet engine (by tweaking the compression and bypass ratios, adding or omitting an afterburner) and just fly some aerobatics.
You can use electric powered rotators and hinges, powered procedural wheels for cars and other cool stuff. And if everything else fails, your rocket is saved is a plain and simple XML file, so it's easy to just dig in and tweak some more.
On the other hand, there is no campaign yet and only a bunch of tutorial-like-tasks to get you started (take off, reach speed X, achieve orbit, hit the Moon with your spaceship etc).
I wouldn't say that either game is better, SR2 is just different and provides you with some more freedom and options than vanilla KSP.
Also KSP is Windows + Mac + Linux + consoles, while SR2 is Windows + Mac + iOS + Android, and the mobile versions are surprisingly playable (especially on tablets or larger phones).
That's great, sounds interesting, especially the airplane parts, always one of the best parts in KSP for me to build space-planes. Thanks for taking the time to write such a elaborate reply!
Sounds like you don't know a diverse set of devs. Mac/Linux may be the hot stuff for people you see at bootcamps and conferences, but there are tons of devs whose primary dev box is Windows.
I've got both a Mac Pro and a beefy PC at my desk but 99% of my time is spent on the PC. And yes, I do have admin rights over my setup.
If I use a stolen credit card to buy a code for your game, eventually there is likely to be a chargeback/refund processed when the credit card owner/company realizes that it was fraudulent. Chargebacks/refunds can sometimes be things that have real penalties associated with them and that can require time investment from you the developer to deal with.
Another, less concrete cost is that of incentivizing bad behavior. If I cannot sufficiently move a certain type of stolen goods, I'm less likely to attempt to steal that type of good again in the future. However, if people choose to pirate a game instead, the bad actor is not rewarded and might realize that he can no longer move that type of product.
Yeah true but the problem with chargeback happens regardless of whether somebody bought the codes or not - unless they bought the codes with stolen credit card, and then the store selling it, not the developer, gets the chargeback. So I don't think this scenario applies here. Developers usually have publishers to deal with things like credit card charges.
