In January 2024, Unity will introduce a new Unity Runtime Fee based on game installs. Prior to this, Unity subscription plans will add cloud-based asset storage, Unity DevOps tools, and AI at runtime at no additional cost.
So today Unity announced changes in how they are going to monetize their game engine, and it is, rightfully might I add, poorlyrecieved
Here is how much youtuber Dani would have to pay unity if they consider his games to gain over $200k in revenue
Now I don’t know how much tracking crackers and re-packers remove from the games getting cracked, but if unity were to count cracked games as a valid install (and they will count every install of a game they are aware of), thn piracy could seriously bankrupt indie devs. Like, not just losing them revenue, but actively losing them money. While piracy is already in an ethical grey area, I think that is just a bit too much.
So, I want to raise awareness of this, and with it I have 2 questions to ask:
Do the people that crack games make sure to remove the ability of unity tracking cracked installs?
If the answer to the previous question is “no”, how do we make them aware of the fact that it is probably for the better if they do this?
I hope game developers can shift to different game engines! Can’t imagine how difficult that could be since I don’t even know more than some basic python.
It’s pretty much a “develop from zero” situation. You can import assets, but will probably have to at least fix them up. If you are lucky, the two engines use the same language, but probably not. For example Unity uses C# while UE5 uses C++. And then you didn’t even get to the parts where you actually use use the engine. Everything that touches the capabilities of the specific game engine need to be rewritten. That is off the top of my head: interaction, physics engine usage, collision engine usage, AI stuff etc.
It’s usually quite difficult, since most other engines use C++, which is pretty different from C# in many aspects. My engine (PixelPerfectEngine - 2D game engine primarily aimed at retro pixelart games, link: https://github.com/ZILtoid1991/pixelperfectengine ) is written in D, which is much closer to C# in a lot of aspects, however my engine is far less capable than Unity, still needs a lot of development, and also has it’s own quirks that make some features inconveinent to implement or add.
Mine is quite minimalistic, and relies for the D runtime and standard library (or other D libraries) for many things. Also my engine is primarily geared towards retro pixelart games, and works as such. Currently, the CPU renders to a low-res texture (as seen in emulators), which is then stretched to a higher resolution, later on it’ll replaced by custom shaders that do color lookup and render directly to a texture (which is quite complicated, simpler methods would cause easily misalignable pixels, thus defeating the engine’s purpose, even if some likes the “smooth” scaling from other engines).
Probably difficult difficult limes difficult. Like rebuilding a wood frame house into a concrete block house.
You can reuse parts (doors, windows, etc) but not everything comes apart easily, and it’s still a lot of work reassembling things. Even the parts you should be able to reuse, you may end up replacing since they don’t “disassemble” easily.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !piracy@lemmy.dbzer0.com
⚓ Dedicated to the discussion of digital piracy, including ethical problems and legal advancements.
I hope game developers can shift to different game engines! Can’t imagine how difficult that could be since I don’t even know more than some basic python.
It’s pretty much a “develop from zero” situation. You can import assets, but will probably have to at least fix them up. If you are lucky, the two engines use the same language, but probably not. For example Unity uses C# while UE5 uses C++. And then you didn’t even get to the parts where you actually use use the engine. Everything that touches the capabilities of the specific game engine need to be rewritten. That is off the top of my head: interaction, physics engine usage, collision engine usage, AI stuff etc.
Godot also supports c# but 90% of the functions would be editor calls (maybe someone could make a translator)
It’s usually quite difficult, since most other engines use C++, which is pretty different from C# in many aspects. My engine (PixelPerfectEngine - 2D game engine primarily aimed at retro pixelart games, link: https://github.com/ZILtoid1991/pixelperfectengine ) is written in D, which is much closer to C# in a lot of aspects, however my engine is far less capable than Unity, still needs a lot of development, and also has it’s own quirks that make some features inconveinent to implement or add.
How does your engine compare to MonoGame?
Mine is quite minimalistic, and relies for the D runtime and standard library (or other D libraries) for many things. Also my engine is primarily geared towards retro pixelart games, and works as such. Currently, the CPU renders to a low-res texture (as seen in emulators), which is then stretched to a higher resolution, later on it’ll replaced by custom shaders that do color lookup and render directly to a texture (which is quite complicated, simpler methods would cause easily misalignable pixels, thus defeating the engine’s purpose, even if some likes the “smooth” scaling from other engines).
Probably difficult difficult limes difficult. Like rebuilding a wood frame house into a concrete block house.
You can reuse parts (doors, windows, etc) but not everything comes apart easily, and it’s still a lot of work reassembling things. Even the parts you should be able to reuse, you may end up replacing since they don’t “disassemble” easily.
Maybe not for their current games, but for their future games.
Still sucks if you’ve got a team that’s really good at Unity, but yeah