some of those companies that are at the bottom of this letter, are one of the worst i've ever seen. many of them are known to just copy other indie games, and just heavily monetize them.
Funny, because Google denied my Hole genre game that was real multiplayer. Their reason was that it was too similar to Hole.io, which was single player.
I looked at hole.io vs donut county. I have played neither. From app store descriptions, hole.io looks like a casual mobile game and donut county seems a polished and complex product, with storyline and quality art.
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.
The interesting part is who is not on the list e.g. HoYoverse.
It has been speculated by many that this is all about Unity Technologies wanting a much larger share of the billion dollar profits of the gatcha games based on Unity.
If all indie devs quit Unity, but HoYoverse (the company behind the money printing press "Genshin Impact") does not, it would still massively increase the profits of Unity Technologies.
Of course because we are literally talking about billions of dollars on the table here HoYoverse & Co will probably all try sueing first.
Considering that as paid games, none of them have ads in them, I'm not sure what point you're trying to make since they can't meaningfully join in to a boycott of IronSource and Unity ads by virtue of not using them in the first place?
I updated the list. I’m sorry - Stardew Valley is not unity, and “Nintendo” wasn’t specific enough to referring to some of their Pokémon projects. (I also added everything after “Pokémon” in the list after this comment and they all use Unity.)
Nintendo has used Unity for certain titles. Off the top of my head I can think of the Pokemon Sinnoh remakes, Super Mario Run, I think the fire emblem mobile game too?
tell you when the (relatively speaking) peanut gallery joins in?
You may not have heard of them but each of these companies have a billion downloads in their portfolio minimum. This is massive that they all rejected this.
> We are the collective voice of the game development industry—developers, game designers, artists, and business minds. Passionate about our craft, we've invested years in shaping an industry that touches the lives of millions worldwide.
Clearly the "our craft" is "business minds" and the problem with increased Unity fees is that their add business is at risk despite all these "business minds" invested years to shape their model.
I am wondering at what point will governments step up and regulate social media, loot boxing, and other such digital-based addictive things just as they regulate other addictive things like drugs, alcohol, and gambling?
When the current generation of politicians are dead or when something sufficiently drastic happens. It took EA being incredibly abusive with lootboxes in a game from a series as popular as Star Wars and the resulting backlash on Reddit going viral for some politicians to consider some investigations. Actually getting them to work on it seriously would take something even more drastic than that.
it's been in argument for years. I don't think the US will ever step in given its culture.
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.
Yeah, doesn’t seem they bring much the community, Id be surprised if content produced isn’t mindless addictive clicker of some kind. I agree it’s just a business model to leech off open source
I’m feeling some sort of fatigue related to community hostile actions and campaigns against them. Twitter, reddit, unity, I’m sure there were others too.
On the bright side, issues like this bring more attention and appreciation to open platforms.
That's a little tone deaf considering how the whole crux of this is that they have altered the terms of "what you have paid for" post transaction.
And for a product that studios invest in over years, leaving many with no recourse
I've learned that when it comes to contract law, the answer to any question seeking a "can they do that?" is: depends how much they want to spend in court.
Can they write a retroactive clause into a contract? Yes. They can write _anything_ into a contract.
Is it enforceable? Maybe. And the more they're willing to spend, the more it will cost for that answer to be resolved as "no." (and even after all that spending, maybe the answer is "yes.")
Did they write this into the contracts that game devs have already signed? Dunno. Will have to ask the game devs.
This is the US, the only way you find out is by spending millions in a legal battle, during which they might very well disable your game remotely (and get fined for that too after, if you still exist then).
Its like fighting Amazon. They kick you off the affiliate program and to fight you start with arbitration ($2000). And lose your ability for Prime shipping, movies, music and stuff. It's like impossible to fight these big dogs
Well, they cannot really disabled it remotely (it's not like that functionality exists in the current code base atm, maybe in future Unity version).
But they could kill your license so you won't be able to build your game using their tool anymore (however you could also just grab a new license under a different name).
What I wonder tho is if they are going to go to the length of asking platform holder like Apple / Google to delist your game and would they actually comply with Unity on this?
Definitely but Unity itself isn't really doing something "legal" here with their extortions, but I guess time will tell with the eventual legal battles.
In EU it's indeed illegal and in 90% of EU countries it won't even go to court. But they can probably force you to not upgrade anything cause of licensing of the new software or if you upgrade they'll make you pay fees from that moment onwards.
But in US im pretty sure it is open for the legal battle that will cost tons of cash for both sides.
Not to be that guy, but do you have a source for this? As scummy as what they're doing is, it's also completely typical for damned near 100% of companies to reserve the right to be scummy. They all have a clause in their terms that states, 'We can do whatever we want, whenever we want, for any reason we want. If you don't like it, your only recourse is to stop using the software.'
I'd love for this to be true, but I've never seen as exclusion or other sort of work-around for EU customers in any sort of terms for this exact condition, so I'd be extremely surprised to find out it's really not allowed in the EU.
"Unfair contract terms" its pretty easy in most cases especially if its something as blant as changing price backward without acceptance of other site.
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.
Probably dependant on country interpretation, but you can try make it to EU level institutions for proper help.
It seems to be pretty easy to get your contract to terminate here in Poland even in case of non-competition clausule so it would be even easier for something like retroactive price change.
they explicitly said in the contract that the terms that apply are those that were in effect at point you shipped your game
> if the Updated Terms adversely impact your rights, you may elect to continue to use any current-year versions of the Unity Software (e.g., 2018.x and 2018.y and any Long Term Supported (LTS) versions for that current-year release) according to the terms that applied just prior to the Updated Terms (the “Prior Terms”). The Updated Terms will then not apply to your use of those current-year versions unless and until you update to a subsequent year version of the Unity Software (e.g. from 2019.4 to 2020.1).
My understanding is that Unity does not issue a perpetual license. They change their license on Jan 1 and you auto-accept the new license by continuing to use the product. If you don't want to agree then you stop using it by then.
Unreal is a perpetual license which isn't able to be affected the same.
their license was apparently perpetual until April of this year, so you can go back to last year’s build.
> Unity may update these Unity Software Additional Terms at any time for any reason and without notice (the “Updated Terms”) and those Updated Terms will apply to the most recent current-year version of the Unity Software, provided that, if the Updated Terms adversely impact your rights, you may elect to continue to use any current-year versions of the Unity Software (e.g., 2018.x and 2018.y and any Long Term Supported (LTS) versions for that current-year release) according to the terms that applied just prior to the Updated Terms (the “Prior Terms”). The Updated Terms will then not apply to your use of those current-year versions unless and until you update to a subsequent year version of the Unity Software (e.g. from 2019.4 to 2020.1).
April 2023 is in calendar year 2023, so that pretty clearly implies you can keep updating until Jan 1 2024 (unless they change their version numbering scheme).
Yes and no. They can't make retroactive alterations to the contract without your consent, but retroactive is more narrowly defined than you would perhaps like (it would apply only to things you've sold, not new sales of games on old engines).
Everything else on top of that requires deeper understanding of the contract law rules of the specific jurisdiction that applies and the very specific wordings of all relevant terms of service, and this is definitely an area of law where if you forget to execute the right magic steps, you can permanently foreclose opportunities for recourse. What opportunities you actually do have, I'm not sure--this is definitely an area where the answer is "talk to a lawyer", not get legal advice from randos on the internet.
I know nearly nothing about law. But I would guess that most courts in world would find this type of change unconscionable. Thus unenforceable. Now not yet released games get much harder. And projects started after the date it was released are likely different.
They are much more moral than you'd think. I've had a judge push my claim to the very end to ensure there were as few people in the court room, then totally rail on the plaintive suing me for wasting everyone's time with absolute bullshit.
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.
If you’ve ever had to be a parent and judge between two siblings, you’d recognize how silly your comment is. All judgements are borne of three choices: to do what is right, to teach a lesson, or some combination of the two. Any judge can say “fuck you, you deserve it” and only a higher judge can overturn it (when there isn’t a jury). Any jury can, interestingly, do the exact same thing. Human rules made for humans can have all kinds of results when judged by humans.
I'd recommend trying to make a game "from scratch", using only libraries, instead of an "engine", if you haven't done it before, and have only used fully-featured game engines. it's good to learn how to solve problems using structs and pointers and memory, instead of thinking only in high-level primitives like Entities and Components and Prefabs and Scenes and Nodes. not only will you level up your knowledge of how computers work, but you might be surprised at how much easier it can be to structure your code and reason about it.
spend a weekend making a simple 2D platformer with something like C and SDL. include support for multiple levels, a title screen, and maybe a pause screen. if you've never done this before, you might be shocked at how easy it is.
you don't need a scene graph. you don't need a component system. you don't need garbage collection. if you're used to having all of these things by default, it's the only paradigm you'll ever know how to work within.
once you've done this, feel free to return to using full-featured engines if you wish—but you may start to see the value in doing more things yourself, instead of trying to fit your ideas into complex, overly-generic, overengineered systems and abstractions you yourself didn't design.
this is all assuming, of course, that your goal is, at least in part, to be able to honestly call yourself a "game developer" in general, as opposed to merely an expert user of a specific piece of software. if instead your goal is to just make something you want to make, without care for improving your knowledge and skills and craft, then by all means jump from one full-featured engine to the next, replacing your mental schema for "how games are made" with the high-level abstractions and systems of one complex piece of software with that of another.
(if any downvoters could explain why they find this post to be disagreeable, I'd love to hear it.)
Just more gatekeeping and elitism. Same reason that "C" devs sneeze on Javascript devs and for some reason act like JS devs "aren't smart enough to write C" as if that's the real reason.
Bruh, write a game from scratch including engine? Why don't you write your own network stack and display drivers from scratch while you're at it? Hell, you won't truly know how the graphics are rendered until you build your own DirectX/OGL clone.
There's a reason we do the work; so that other people can use it and build upon it. Everyone starting from scratch again is only a learning exercise _if that's what they trying to learn_.
Just because the industry is used to creating a piece of art with just a stamp book (and stamp books are the hot thing right now), doesn't mean its the only way to create art. If you truly think that "we've done it, we've come up with everything we need to make games using these engines!" you lack serious creativity! If you want to LEAD the industry and not just follow it, you're going to have to step out of that comfort zone.
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.
With that mindset, I'm really curious on how you view the industry trend in AI tools. Obviously its hit the art industry sooner, but there's more and more tools for game developers coming out now too.
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.
some gates need to be kept. if you use an LLM to generate a game for you, are you still a "game developer"? where does one draw the line? it's has to be somewhere, and
"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 any downvoters could explain why they find this post to be disagreeable, I'd love to hear it.)
Making it from scratch takes enormous amount of (expensive) more to make any graphically competitive game.
Sure, you can make 2D games even with vector graphics, but when you need anything more realistic without making every asset or 3d animations with collision checks manually yourself, you are in trouble and never deliver your game without AAA budget.
There is a reason why game engines exists. They solve very difficult problems, in tested, reusable scenarios, providing cross-platform support out of the box.
If your libraries calculate collisions, velocities etc. all or even add ray tracing, they are already engines.
> There is a reason why game engines exists. They solve very difficult problems, in tested, reusable scenarios, providing cross-platform support out of the box. If your libraries calculate collisions, velocities etc. all or even add ray tracing, they are already engines.
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.
Writing rendering and collision code honestly is pretty easy compared to coding a game. Difference is that rendering, collision, etc shenigans is "solved problem", theres lots of papers. Game is the creative part, and there is no solution.
I'm not advocating for the average aspiring game developer to create a game project actually from scratch—even though, as you say, rendering, collision detection, etc. is in theory "easy" because it's such well-trodden territory. it's definitely useful to go down that route as well, but, still you get plenty of benefit from doing things in a more low-level way than you're used to, coming from something like Unity.
rarely if ever are video games created by someone having an idea, then typing some things into the computer to make that idea manifest itself in the form of an executable, and that's the whole process. the special thing about game development is that you flesh out the design of the game by actually working on it. you play around with things, explore the conceptual space of what you've created, and see what direction to take things in next. if you've only ever made games with Unity, then you only know how to think about problems within the conceptual schema of the way Unity does things (or worse: the way you ended up learning to use Unity so as to make Unity's annoyances maximally get out of the way of making your game).
when you sit down to make a game "from scratch (using libraries)", you're forced to completely rethink just about every aspect of game development that you take for granted. you don't have GameObjects and Components and Prefabs and Scenes—you have nothing, and you have to figure out how to make it into something. sure, you could just pull in some ECS library and try to continue living in that world, but there's so much benefit to be gained from making a genuine effort to not use such crutches—to figure out how to do things in a way that produces code that is reasonably efficient (not micro-optimized—just broadly "ok", efficiency-wise, is good enough for small projects running on modern computers).
you start to make observations like, woah: you don't need garbage collection/RAII/etc. at all, because, most of what you're doing that would require garbage collection/RAII/etc. is stuff that happens each frame, so you can just use a bump/arena temporary allocator that resets at the end of the frame, and, bam, that's 98% of what you were using GC/RAII for in the first place. the rest is either stuff you want to keep around for the entire duration of the executable's run, or stuff that's like per-level or per-map, that you unload and swap out when you transition between levels/maps. when you see things put into these terms, video game memory management doesn't seem all that scary, does it?
but if you've never tried to make a game "from scratch (with libraries)" on your own before, you might never encounter this. you might forever be tethered to the idea that video game logic can basically only be programmed using some kind of extremely high-level organizing principle/abstraction, like Unity's Scenes/Prefabs/GameObjects/Components, or Godot's Nodes. even if you continue using Unity or Godot (or whatever), you one day might want your game to do something complicated, and the only tool you have is a Node-hammer, so everything looks like a Node-nail, so you never consider the fundamental reality that really what you want is probably some combination of structs, arrays, and pointers, in order to make computers execute the vision of the game design idea you had in your head. and learning to be able to think about things in this way might even empower you to have the freedom to not just implement the idea you had in your head, but even do something crazier and more complex and cool, because you thought of how you could do it in the process of implementing the other idea you had!
"this is all assuming, of course, that your goal is, at least in part, to be able to honestly call yourself a "game developer" in general"
This is some Wagnerian level of gatekeeping snobbery right here. A game developer.... develops games by definition. They don't develop engines, they don't develop rigid body collision systems, they don't develop 3D renderers, they develop (aka make) games. If you find a suitable tool to facilitate the creation of your vision, you'd be a fool not to avail yourself of it.
> They don't develop engines, they don't develop rigid body collision systems, they don't develop 3D renderers,
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.
Ah damn bruh, I guess my artist friends aren't really artists since they don't know how to program photoshop from scratch. I'll let 'em know that they're just "expert users of certain software".
if a sarcastic, defensive metaphor is what you were looking for, you could've spent a few more minutes coming up with a more logically-sound one. or you could've just engaged with my points directly, without the sarcasm.
if you can ONLY make art with Photoshop and completely lack any ability whatsoever to draw/paint/etc. without it, then yeah, you might not be an artist, but rather, a Photoshop-user.
hopefully we agree at least that LLM users are not artists, right? just because one uses a tool and art comes out the other end does not make one an artist.
An artist starts with PS, they master it can can make beautiful art with it. Then they need to use another product, or work traditionally - there'll be another learning curve but a lot of what they already learned can be reapplied. They're still an artist, even if they exclusively use PS & don't understand the minutiae of traditional art/techniques to smear charcoal until they decide to try it.
A game dev starts with Unity, same thing. They're still a game developer even if they only know how to use Unity - a lot of their knowledge is applicable to game development in general. If they switch to Unreal there'll be a learning curve, but not as steep as when they first started.
The same logic could be applied to cooking: we don't refuse to call someone a chef because they specialise in Asian cuisine, they're still a chef. A physics major is as much a scientist as a chemistry major is.
And as to your last point, it's pretty baity but maybe you have a very narrow definition of art? What is art? Is taping a banana to a wall art? If so then the person who did it is an artist. Personally, though I think you definitely disagree with it, I think using an LLM does make someone an artist as they're using a tool to produce something with aligns with their vision - if they just pressed a button without any input at all, I'm not sure I'd call that art unless it's something performative. But otherwise I put LLM users into the same category as people using PS tools - there's plenty going on under the hood, but the artist is still feeding it with input.
Let's say an artist uses a coloured pencil for some traditional art, are they now not an artist because they don't understand the chemical composition of the pencil that the company worked on so that it leaves a mark just-so? The pencil is a tool that the artist inputs into, but the artist doesn't have to understand the workings of the pencil from an atomic or quantum level to be considered an artist.
I guess I don't understand this strong desire to refer to oneself as a "game developer" completely regardless of one's level of knowledge or experience. I started off making games with RPG Maker 2000 and then later Game Maker when I was in middle school. I was most certainly developing games, but I would not have referred to myself as a "game developer", because I knew that I was using high-level tools to develop games, and I knew that I didn't know the first thing about Actual Game Development, really. later on, in high school, when I tried to use C# and libcairo to make a vector-graphics video game, I was confused as to why the game would run fine at 720p, but chug at 1080p. turns out I didn't know the first thing about what I was doing, and was doing all rendering on the CPU. embarrassing! but definitely the work of someone who was an aspiring game developer, but whom certainly would not consider himself to be a "game developer", unqualified, if asked.
why does the title matter so much to you? and why go to all these lengths to justify not learning the tiniest bit more about the craft of which you claim the title of craftsman, especially when I've gone the lengths I have to lay out exactly how straightforward it would be, and exactly what you have to gain from it?
this insistence over titles and outright refusal to learn basic principles is the sort of thing that makes me think that independent game development has become more of a fashion than a craft taken seriously.
I post this as someone who in fact is an engine developer, To my chagrin, most people don't want to actually work on engines.
>this is all assuming, of course, that your goal is, at least in part, to be able to honestly call yourself a "game developer" in general, as opposed to merely an expert user of a specific piece of software.
this gatekeeping doesn't help much either. there are multiple successes made on GameMaker from people who barely know more than the rudimentary sctipting/programming basics. I don't think many would argue with them being "game developers", even if they wouldn't necessarily get jobs at Naughty Dog or Blizzard.
There's a lot about proper game design to learn that you can pick up without ever touching a line of code. Or even a computer if you want to go super old school. I'd only recommend your path to current computer science students hoping to work in industry after graduation, not someone who wants to ship an actual full game
look at all the comments in this thread acting as though making a single-threaded 2D platformer "from scratch (with libraries)" in C (or similar) is some herculean task, when you and I know how simple and straightforward it is. specifically, those saying, "you mean, make my own engine?!", showing a complete lack of understanding of basic principles.
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.
Why is it not possible for a company to keep doing what they were doing when they became successful. In case of Unity a cross platform game toolkit. But no. They wanted to add all kinds of shitty functionality. I dont really get it. It must be all the non gaming people taking over the company looking at Excel sheets and other graphs to find new income streams by implementing the crappiest features ever. They need to put those people on a public shame list so they wont be hired ever again. I hope these kind of companies die quickly.
It’s pretty common to use ad network mediators, which try multiple ad networks for an ad, to optimize for using high earning ones first, and falling back to others in case the first network didn’t have an ad to show.
I think it also affects legitimate gamedev studios. But yeah, I couldn't care less for the signees on this letter. Good riddance, boys; if your product can only run on ads because people won't pay for it, you know you have a shitty product. We need higher quality games in the market, not higher quantity of your chaff.
If anyone ever wonders why premium games on mobile died out, there's your answer.
But to give a TL;DR for those who don't click through: Piracy on Android in the 2010's was especially rampant, due to the nature of how you APKs are packaged and distributed (and how hard Google makes to add DRM). 70% piracy rates were common on Android compared to 30% on IOS, and it wasn't unusual to hear of 90+% in some games, to the point where a few games went f2p simply because they could not get users to pay a single dollar for their game.
in a particular instance, the hit game Monument Valley, a 2014 game that had 26m downloads on IOS alone in 2016, was reporting 95% piracy rates on Android. It is (or was, back in 2018) $3 on IOS, and now f2p on Android for that reason.
if you want a frame of reference for how absurd this is (not that you should to understand how 19/20 of your "customers" aren't buying your game): PC piracy has stayed around 33-40% throughout the decades. I cannnot blame developers for switching or abandoning the platform given those piracy rates. It would legitimately be better to offer a demo on Android (a properly isolated demo, not "part of the full game" demo) and point them to console/PC than it would to spend resources porting to Android.\
-----
Gabe Newell is oft-quoted saying "Piracy is a service problem". Well, this shows that services can simply get around this by turning the pirated content into a thin client and store all the value on the server. It simply took until "always online" was no longer a lofty assumption to perform.
Nobody has abandoned PC. PC games are still around despite piracy. And for some, they are still around because of piracy. I understand your point, but I still don't buy that ads and DRM is the solution here. How come GOG even exists, according to your theory? The only games I buy are DRM-free and they're on GOG.
Of course not. Let me know when PC market gets 70+% piracy. Which mind you does happen in some regions and has caused indies some trouble.
Even then, the PC market resorts to DRM for this exact reason, so that cited 40% is still too much for some larger studios. But the difference between almost half your sales potentially going away, and a scale where 19 out of every 20 players never paid for your game is orders of magnitudes.
>How come GOG even exists, according to your theory?
Because GOG doesn't have 90% market share, and because AAA studios do in fact bypass GOG for DRM issues (until very recent times IIRC where GOG has made exceptions. Have to look that up again).
And to bring it all around: think about how Unity would affect this under it's original "plan". They can't track piracy so you will get dinged on 200k sales, even if 190k never purchased your game. At 90% piracy you'd need 2M "sales" and you'd be charged 400k dollars in runtime fees despite say, making 600k on a $3 app.
Google/Apple comes in and takes 180k and you're left 20k on your "successful" premium indie mobile game. Because piracy cost you $300k instead of maybe potentially being "free advertising" like how some people try to frame it.it was already bad but Unity showed how much worse it could be.
Those companies would rebuild their games from scratch before they truly disappearing. They have literal billions of dollars each, and they will long outlive Unity at this rate.
The other way to look at it is that browser settings are the perfect way to express lack of consent for non-allow listed entities and get rid of the ridiculous piecemeal approach we have now.
Indeed - what I'm suggesting is not that we have some opt-in standard that people may or may not follow. Browsers should go nuclear on tracking, and remove any feature that permits it.
The problem is, it's very hard to define what tracking is. That's why GDPR is General Data Protection Regulation. As it places the onus not on the tools to try and implement some ways to evade tracking, but on the companies who pretend that tracking is their god-given right.
Because tracking is significantly larger than just placing third-party cookies on the users' machines.
TLDR: Don't bet on Unity's success. Bet on their collapse. The place has zero integrity in management. I've never worked at a worse managed place, and I hope I never do again.
(Disclaimer: two of my three engineering managers were actually very good skilled engineers and managers (the one bad one was the "people manager", who "always knew he wanted to be a manager" and was put in charge of an engineering team... he had followed an engineering director from app dynamics). It's the business management steering the ship that I think is the problem)
I used to work at Unity. I left quickly after what I saw.
The biggest problem at Unity: Internal Distractions. Slack channels are filled with political discussions (As you might venture to guess: It's a race to the bottom of the Oppression Olympics-- lots of "no my group is more marginalized!" "no mine is!" type of people).
Me, as a Software Engineer-- I was working while other employees were arguing about political issues (as if they could change each others minds-- unlikely, and a waste of time.)
I thought "How is HR allowing people to NOT work yet instead spend that time arguing politics in so many slack channels? Who is doing the real work here?"
Then there was the main problem (For me) of being hired into a bait-and-switch role (after the 7 or 8 interviews... Lord have mercy...)
I was told:
- You'll be fully remote, you can work from anywhere. (My manager soon told me: No, we hired head count in <Your City> and we expect you to stay there. Because I like to visit for 1-2 days every quarter, and I want to see the whole team.)
- You'll be a NodeJS developer. (Turns out... you'll be a low-code Mulesoft developer, and maybe if you're lucky you'll work with NodeJS)
- We hire you on Salary. (Turns out... you'll be treated like an hourly employee. I took a 2 hour lunch break one day because I expected to be judged on my impact & contributions, not the time my rear-end is in a chair. "Yeah... I'm going to need you to keep your lunches to one hour only". It was then that I decided to resign.)
- They offered $110k base salary. I countered with $140k. I accepted $120k base, plus some stock. Had they paid me more, perhaps the BS I experienced would have been tolerable. But they didn't pay me the "Oh, and accept all of our BS" rate I asked for (looking back, I should have asked for much more, given what I saw internally).
After leaving Unity, I arrived at a company and it was such a breathe of fresh air to find that nowhere in Slack did anyone mention anything about their political opinions-- all the people actually worked. Unlike at Unity, where many people spend time arguing about irrelevant non-work topics.
I'm telling you-- I have never seen the amount of meaningless distracting politically argumentative conversations at a company as I did at Unity
Sounds like you got a particularly bad part of Unity (and I have heard about those parts, even if they were far from my line of work). I had a wonderful team/project at Unity and while there were some who would talk politics I can't imagine any of them spending hours arguing about it on the company hour. I can't definitely say no one did, because Unity had literal thousands of public channels to grok through (there was literally a channel dedicated to asking what channel to post a question in. It's that saturated).
But that might have been because my director shielded the team from a lot of the BS up top. Come 2022, I and quite a few others of my team were laid off, and within 12 months said director was also out of the company. I don't think it helped that Johacim took a silent leave within that timeframe either.
The only agreement I have with your experience is that you do have tons of interviews. But mine were all fit into one full-time day, and it was mostly to see if any of the teams in that office wanted me. So less "5 interviews for a single position" and more "5 interviews with 5 teams, and 1-2 with directors to ask about the company".
It least your Slack channels didn't include employees pasting in porn GIFs to comment on the clients who were currently in meetings with the commenter.
Various things. I am sure it is used by dozens if not hundreds of teams of engineers there for relevant projects, such as data integrations with REST or XML API systems.
If you need a Web page, to protest being at the mercy some company because of dependencies out of your control... why would you gratuitously put that Web page at a Google Docs URL (which, again, you don't control)? Even three decades ago, you could pretty easily self-host this Web page and the Web form, in a way that you controlled it.
Which prompts a thought...
I'm sure there are much better reasons for dependency on a video game foundation. But -- seeing other aspects of ordinary software development practice (e.g., ridiculously unnecessary massive complexity, numerous shoddy SaaSes, and hundreds of unvetted JS or Python package dependencies casually pulled in) -- I wonder how much of the video game dependency decisions similarly have little thought put into them? Or are video game developers smarter than most other developers?
Google docs is:
1. Free.
2. Does not require any infrastructure investment.
3. Has built-in access management system.
4. Easy to collaborate in.
5. Hosted on a 3rd party that is highly unlikely to intervene.
> put that Web page at a Google Docs URL (which, again, you don't control)
What is the alternative? Bring up an AS, hook it up to a couple of dark fibers, and host it off your battery and solar panel? Because you do not control your ISP, hosting provider or power provider either. You barely control the hardware you bought.
You independence depends on benevolence of other players, and Google is most likely to remain benevolent in this case.
Reasonable degree of control. Being able to put up a Web page at a domain name registered to you is just the beginning of tablestakes in this business.
All those major studios listed have their own game engines, so unitys decisions don't affect them anyways. And Epic develops Unreal Engine, so Unitys' loss is their win.
Support for Gwent will end this year and Hearthstone is soon 10 years old and not that relevant for Blizzard. Their much more important game Diablo Immortal uses a different engine.
The big publishers only used that engine for a few offshoots and this change will guarantee that won't happen again.
> I see major development studios are fine with this change.
Even if they didn’t have their own engines, they’re all big enough that they would be paying huge amounts in license fees, and thus have enough leverage to negotiate a contract without BS terms in it.
In other news, the rental car company buying 1000 cars doesn’t do so on the same sales form used when a consumer buys 1 car.
> Honestly, it almost seems like someone is destroying the IT industry on purpose.
They're not, it's just that (unfortunately for all of us here) it's shrinking to more normal dimensions now that it's no longer being watered by a ceaseless flow of money.
They licensed Aurora engine from Bioware way back in the day of Witcher 1, then developed their own (Red Engine). I guess Red Engine has lots of Bioware DNA going on.
