Game developers turning off all IronSource and Unity Ads monetization

It reminds me of 2048 vs threes. Thing is, sometimes I prefer a casual game.

The copying is still poor taste, I agree with that. At the same time the titles can be different and respond to different market needs.

I’m not sure what to think of that or about the industry as a whole. Especially since when I searched donut county on the app store, there were more copycats.

Also, I'm unsure how you step in and "regulate social media" to begin with. The whole issue is that social media provides much of its content via users, and users take these bathroom writings as gospel. That's a societal issue. Even if you regulate the money out of social media people will just join some home spun sites or even the fediverse, and the core problem continues.

I'm pretty sure there's a term for that: fraud.

(I am not a lawyer..)

I very much doubt it

Also every country can have different interpretation (It is possible that some countries are very limited and you have to try EU level help) In some cases its even illegal to write non-competition into your contract without providing payment for the time of this being in-place ( there were tons of cases when contract was voided by that and I have even one of my contract ended on my account after single lawyer visit cause of this :] )

I would assume Unity won't even try to enforce it in EU.

But ofc. after update its over and games not yet released can most likely be forced to pay.

Then, after he said his piece and made it clear there better they needed to be quite persuasive, they did indeed lose. They tried to win on a little technicality in the law but as the judge said "that is there for X reason, this is Y. It doesn't even apply, especially with ample evidence that the defendant was attempting to work with them to resolve the issue."

Point is, civil court is usually quite different than criminal court; basically preponderance of evidence vs. reasonable doubt and a judge can say that the evidence is not preponderance enough.

it seems that people these days don't really understand what necessarily constitutes a "game engine". this is why I am advocating for people to make small weekend game projects using languages and libraries that are lower-level than what they are used to working with. instead of trying to build the game you've always wanted to make, try making a weekend platformer project like I outlined above—I cannot understate how useful this to making you a better game developer, even if you do end up continuing to use a general-purpose engine that someone else made. demystifying these concepts and seeing for yourself, in a hands-on way, that you don't need almost any of what these big general-purpose engines give you, to make a playable video game, is incredibly empowering, and has zero chance of making you a worse game developer, at any rate.

note how I never suggested doing any of those things in the post-Unity pre-Godot weekend project I suggested—except for the "engine". if you call yourself a "game developer" in general—as opposed to an expert user of a specific piece of game development software—then you should intuitively understand the level of effort it would take to create an "engine", using C and SDL (or something like those—Zig and raylib, Jai and Simp, whatever), specifically for creating a simple single-threaded 2D platformer, with multiple levels and a title screen, in a weekend's time—it's far from rocket science. some arrays of structs, some functions that loop through those arrays to simulate and render stuff (as colored squares), some code that handles input and makes it change some variables in a struct, and it all runs in an infinite loop that breaks when the player presses Esc (optionally with a frame limiter). then from there you can add an "asset system" (arrays of structs, plus an ID enum and a load function, for textures and sounds), and a "scene" system ("TITLE_SCREEN, GAME, ..." enum, switches that branch on that, and a current level integer). (stretch goal: particles.) there's a tiny bit more to it than this, but that's most of it.

for someone who calls themselves a game developer as opposed to an expert user of certain software, this should all be completely straightforward to write in a weekend, because these lower-level constructs—underpinnings to higher-level abstractions found in general-purpose game engines like Unity and Godot—arise naturally from thinking about the things the computer needs to do (functions) and keep track of (structs, arrays of structs, pointers) to make your gameplay come alive, more generally, unbound by tool-specific mental schemas. I'm not suggesting one write a game in assembly, but merely something a bit closer to that than GameObjects and Components or Nodes. proving to yourself that you don't need such abstractions to make a game is empowering, and causes "game engines" to be somewhat demystified for you, unlocking a breadth of new knowledge, understanding, and possibly even inspiration—if you've only ever thought about game development in terms of the high-level abstractions specific to a general-purpose game engine.

I haven't kept up with GameMaker: Studio, but if it's still anything like Game Maker 8, then it should be very straightforward for any seasoned GameMaker user to spend a weekend or two making the 2D platformer example I outlined, in C or similar. GameMaker (or, at least, Game Maker) does lots of things the dead-simple way: resource IDs are just integer constants. when you draw_sprite(x, y, sprPlayer), sprPlayer is just 4, or whatever. this is a pretty decent simple API that could be replicated easily!

GameMaker users who try this project out will discover how much easier it is to have most or all of your game's logic in once place, instead of split up into various Events in various Objects. they'll discover how, when you're doing things the simple straightforward way, you don't need to make an "objController" with a Code action in a Step event and a Persistent flag, and remember to stick an instance of it in your first level, just to get some logic to run every frame of every level of your game. you just write the code in your simulate()/update() function! it's that easy!

after working on this project, the GameMaker user who has never tried anything like the project before can still go back to GameMaker and continue to use it if they find it to be a useful tool in rapidly developing the kinds of games they want to create—but they'll have gained immense experience, knowledge, empowerment, and possibly inspiration from having gone outside their box and having experienced a different, simpler way of doing things. maybe they'll reconsider if they need GameMaker for their next project—maybe they'll be better off owning more of their own code, if all they're using GameMaker for is easily replicated without it.

"understands what a 'game engine' necessarily entails such that 'making a simple single-threaded 2D platformer "from scratch (using libraries)" in C or equivalent' isn't a scary thing, but rather very, very simple and straightforward"

seems about as good of a bar as any—and it's a very, very low bar, one that anyone who is offended that they don't meet this criteria, should be able to achieve in two weekends, tops. then you can go back to using whatever general-purpose engine you want, secure in your improved knowledge about how games can made without using one.

you seem to think that my 2D platformer example is some outrageously difficult task, too scary for you to make, which is exactly what I'm talking about—you should intuitively understand how little I'm actually asking for here, instead of being outraged at my suggestion.

If you think the way you do about game engines and javascript, then if someone uses AI to generate a game by typing a paragraph about their game, do you really still see them as a game developer? Maybe that term isn't as important to you, but I'm willing to bet you would agree that artists would find it highly offensive if people who generate art using AI call themselves artists with as much authority as those who have disciplined themselves in the field for countless years.

And that's avoiding the fact that with higher and higher level abstractions that people know what's even going on at all. Bro, have you tried debugging modern javascript frameworks? What a nightmare...The call stack dump alone is like 3 full pages of shit that nobody knows how it works, all built on shit that also nobody knows how it works. Absolute nightmare. Oh, but don't worry! Someone will build yet another stack of technology on top of that to give it a Band-Aid! Yikes.

Not every game needs to be ANOTHER open world adventure game with crafting, an overhead camera, dialogue scenes, and click and hold menu buttons.

In the end, creating games at lower levels might inspire you to actually create something unique.

The same problem occurs in the music industry as well. Why even compose music when garage band offers audio clips you can just re-organize and loop in cool ways? Why use mics to record sound when there are plenty of already professionally recorded midi plugins for you to use?

My answer to you is creativity. Try doing something more natural and you might just create something fascinating, something nobody expected, something actually unique. Not only that, but you will be able to more fluently communicate your ideas to your audience, tweaking things exactly as you mean them to be. Not limiting yourself to the buttons and inputs in some interface.

There's always tradeoffs. These generic tools are made generic to reach the biggest audiences. But by being generic, they sacrifice the ability to be more specific, or else they become so much more abstract that they are harder to use than just writing something yourself.

The big publishers only used that engine for a few offshoots and this change will guarantee that won't happen again.