Unity to Godot Docs | Hacker News Reader

Unity to Godot Docs

docs.godotengine.org

110 pointsstuckinhell29 comments

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.

> devs will only be charged for the first game install, not EVERY game install)

I wonder how they will figure that out. It is not trivial. And if they don't disclose how they are doing it, it has a large potential for abuse.

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

The obvious way is hardware ID, which can work okay for 80% of cases.

Unity merged with a "your flash player is out of date" adware company, I'm sure device identification is nothing new to them

Nothing changes until January 1, 2024.

Would not surprise me if it was a heavy handed management decision dumped on engineers laps last minute, and is barely implemented at this point.

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.

Welcome to software engineering.

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.

>charged for the first game install, not EVERY game install

While still terrible, is this an enormous walkback or was it always going to work this way and their initial communication was enormously incompetent?

I've been telling people Godot is better and requires zero loyalties. I'm hoping this makes Godot explode with the attention it deserves.

What’s better about it? It seems to ship to fewer platforms and requires you to learn a language that isn’t used anywhere else.

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.

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.

There's quite literally no point in switching unless you're a bandwagoner that just likes to sit on technology.

The majority of these amateurs are never going to surpass $200,000 in sales; plus it's quite literally just incentive to buy pro

(Which anyone making substantial money should be doing anyway)

I love how Godot supports the web like this, they are bleeding edge

https://editor.godotengine.org/releases/4.2.dev4/

i see a lot of future for it in webxr and spatial computing, excited for its full release

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.

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

[1] https://www.cimg.eu/

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.

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.

img = Image.create(width, height, false, Image.FORMAT_RGBA8)

img.set_pixel(x, y, col)

tex: ImageTexture = ImageTexture.create_from_image(img)

spr.set_texture(tex)

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]

[0] https://www.fullscreensavers.com/sea-raindrops-screensaver/

[1] https://godotshaders.com/shader/ripple-shader/

Is it possible to export unity store assets into other engines?

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

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.

There are a couple of projects working on this. These are two of the best ones that I know of:

* Unidot: https://github.com/V-Sekai/unidot_importer

* UnityPackage For Godot: https://github.com/barcoderdev/unitypackage_godot/

This is such a vague question.

Yes, you can obviously export raw texture & mesh files into another engine.

Will the code work? No, probably not.

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.

What's the state of physically based rendering in Godot?

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.

https://docs.godotengine.org/en/stable/about/list_of_feature...

Reply on news.ycombinator.com