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?
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).
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.
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).