I'm pretty floored by Unity's decision. Even after their partial walkback (saying devs will only be charged for the first game install, not EVERY game install) it's still a crazy way to monetize instead of profit sharing.
Unity appeals way more to hobbyist devs getting into game dev, and from what I've seen has significantly more resources and tutorials online than Unreal. Hopefully we see the same resources start to be published en-masse for Godot.
I suspect the potential for abuse is the reason they’ve walked back. The problem is that data will be private and the gatekeepers are the ones who stand to profit. So you’ll have another situation like those ad companies who underplay bot impressions
Which is literally _next quarter_ and retroactively applies to all current games. That's _really soon_, and is going to cause headaches for any publisher/developer looking to release soon.
Eh, yeah. Once had a service provider promise their new API would “easily” handle our needs (I still remember the tone the sales rep used every time he said easily; it so reliably came out sounding the same every time, it seemed practiced).
3 months of integration dev later, we start load testing, the external API fails spectacularly. They tell us to redesign to use their old batch API 35 days before our deadline. We tried, failed, ate shit with our customers. Provider was too big to pick a fight with. Startup failed.
The language is insanely familiar to anyone whose done Python, but that is fair. My understanding is that it does not deploy officially to those platforms due to NDAs or something like that. If you look you will find Godot versions maintained by maintainers that do in fact run on all the missing mainstream gaming console platforms (the switch, etc).
It's actually free, the license is MIT for the editor, so you can download the code, and change just about anything. You can also code native plugins in any other language. It has a build that supports C# and unlike Unity (idk if they ever fixed it) it supports modern C#, which Unity at the time did not support.
I would argue if your only concern is GDScript, you're asking for the C# build, but really GDScript is mostly Python-esque, I would be shocked to hear that anyone who knows basic Python cannot use GDScript.
They got creative and should have provided a calculator for that fee scheme. Even so they can't really measure installs per user without deep data gathering which could be illegal.
If anyone's looking for a quick intro to Godot 4, you can take a look at our video series: https://quiver.dev/tutorials/create-your-first-godot-4-game/. Disclaimer: this is offered by my company, but the tutorial is free and the code and assets are liberally licensed.
This move by Unity isn't completely unexpected if you've studied their financials. Smaller devs are basically dead weight for Unity, so it seemed like them putting the squeeze on them was just a matter of time. Bottom line: don't count on a public company to do the right thing if you're not helping their bottom line.
if anyone uses godot, an example i'd like to see is raindrops falling into a puddle, viewed from the top, like the old screensavers. I tried using GPT to do it in 2 engines, pygame and unity. The pygame version kinda worked, but everything felt and looked slightly off.
I have a mighty need for something that can quickly render frames of arbitrary pixels. Ideally a line at a time for smoothness. I also had this working - kinda - in pygame, but after 2.5 screens worth of lines being drawn it gives up.
Looking at the godot documentation, it would be nice to see something non-trivial and arbitrary expressed as code.
Do you have an example of that screensaver? Is it something like this? [0] That's the only thing I could find online. You'd probably just want to use a fragment shader. [1]
>I have a mighty need for something that can quickly render frames of arbitrary pixels. Ideally a line at a time for smoothness.
Dependent on the complexity of your application and how comfortable you are working in C++, you could give CImg [1] a go. I've used it for a handful of projects with a similar requirement. It can be lightning quick, but a pain to get started with.
I wanted to make something that used pixel drawing in Godot and ended up creating a Image, manipulating the pixels of the image then copying the image to a texture and setting a sprite2d to that texture.
Have you checked out processing or p5js? They both seem like they'd be well suited to something simple like this, they're not game engines they're graphics libraries but they're very approachable and easy to use, with great documentation.
Depends on the asset, most code or UI tools would probably be a no without a good amount of effort to port, 2D and particle assets you can most likely rip the image files and recreate in another engine with some work. 3D assets usually come with an FBX file (If they were made using Probuilder or something inside Unity you can use Unity's FBX exporter to get an FBX file) that you can easily transfer to another engine, there may be some edge cases where you'd have to re-rig the assets depending on the engine you're moving to. For animation assets they'll either be an FBX file that you can transfer over or an Unity Animation Clip that you can also convert to an FBX using the FBX exporter. Shaders are a little bit vendor locked if they were made with Shader Graph, you can get the generated source for the shaders, but it is generated which can make it hard to read (single letter variables/function names). There's a ton of edge cases you could run into depending on the engine you're moving too, like Z being up vs Y being up or engines using a different normal map tangent basis, but there's tools that can fix those issues when you come up against them.
If I recall correctly there were 2 tools on github that made this possible i.e. unity assets to godot, but I don't remember their names. you can search on youtube and find them tho
the new fees Unity introduced will be their downfall. I would never use Unity for game development again, even if they completely reverted their recent decisions.
I'm happy I always kept an eye on Godot and tinkered with it - switching to it fully makes perfect sense now.
Physically based rendering support is already pretty robust. The bigger things holding Godot back were more game centric, like screen space occlusion object culling to help with rendering large scenes. However lots of those sorts of features have been added in recent releases.
Unity appeals way more to hobbyist devs getting into game dev, and from what I've seen has significantly more resources and tutorials online than Unreal. Hopefully we see the same resources start to be published en-masse for Godot.