Brian Bucklew Porting Caves of Qud from Unity to Godot
twitter.com
twitter.com
They also use the particles system for candelabras. Could be reproduced in many engines.
I don't develop in Unity nor Android, so I am rather curious why is every component useless long term.
God damn it Elon. Twitter is so fucking annoying to deal with now.
When this happens, substitute .nl or .cz
Nitter crawls twitter in order to function as an (unofficial) mirror for the site. I appreciate the effort although it is not guaranteed to stick around forever given it undermines Twitter's business model.
Your confusion is understandable... I was simply replying to a nitter link to vent my frustrations about Twitter as many use the Nitter to get around Twitter's many new limitations since Elon took over.
Also, for 2D, it is sooooo much easier to implement. No messing around with orthographical cameras, no tilemaps appearing with random lines, colours, etc. And 2D performance exceeds Unity's.
I haven't seen any true 2d vector graphic engine suitable for games after flash beside the software made to be alternative flash players. Yes there are a bunch of games that still use that art style but in many cases they might be drawn as vector graphics, but then converted to bitmap for the game engine, maybe with some runtime shaders on top for sharper look. SVG is just way too different from how game graphic APIs works. Just making a non real time SVG renderer is hard enough already. Even programs like Inkscape whose only task is drawing and manipulating are sometimes struggling with it. Open a more complex SVG and zoom in/out move around and you will see as Inkscape tries to keep up updating and caching the rendered image in chunks.
It might be possible to do something using browser svg support although I am not how good the performance would be with the kind of dynamic content games need.
There are also a couple of UI frameworks which support SVG. For something like that it can be acceptable to use slower but higher quality svg renderer and then caching result. For the most part UI elements are either static or at most move around due to scroll views and zoom rarely changing so caching works very well.
Any non-trivial feature that Unity has where Godot lacks is usually re-implemented by bigger developers anyway. For Indie developers, these features are almost never necessary.
When developing tools, Godot is far superior. Any support guarantee that Unity provides is easily bested by the ability to inspect the Godot source code without signing an NDA. With the changes in Godot 4, developing add-on tools is easier than ever.
The Godot project is well managed, with pull requests being merged in a timely manner without a loss of overall project quality.
The mass exodus to Godot is perfectly timed. Godot 4 just released with many changes and improvements, addressing almost all the usual pain points between the two engines (especially in 3D).
But perhaps the existing unity ecosystem sellers will look towards porting their stuff over, since their customers are in mass exodus mode.
Godot needs to prepare a good marketplace solution to accept the oncoming ecosystem developers, so that they can take advantage of this. Could even have a potential to use revenue from the marketplace to fund godot development!
- Relative ease of use for us (especially when working with juniors/intern who often only studied game engine and don't have framework experience)
- Performances ok/good (seriously it may depend the platform but a native game engine often have far better performance than a browser on input latency/rendering, wich is logical, it's the point AND they do a lot less than browser on other features)
- You can go really wild on design/feedback with low effort, especially if you have a mobile game ui on yours work folders
The pain points (some may be alleviated with dedicated libraries, I used none) were :
- On complex UI (multi tabbing/multiple modal screen ) the lack of native support you have in dedicated web framework was a pain
- You have to add yourself complex features natively offered on forms. Especially history, complex filtering.
- On complex I/O (network/files manipulation) the engine was (naturally) lacking.
- Unity and probably Godot assume by default they are the main windows on screen, you can encounter problems about that if you use it as a 320x200 windows between 4 other windows.(that said if you considered electron you won't be in unknown territory ^^)
I think an engine today is about a lot more than rendering performance and quality. It is about the development pipeline, the tools it comes with and the interfaces to integrate assets and loading those. In that regard Unity offers a lot by now.
They also feature their asset store and whatnot. Of course it will take some time to develop such features for any new engine and it won't come to pass until it reaches a critical mass.
A game engine is much more - it includes systems like physics, game object representations (like unity's sort-of-ECS), save/load, animations etc.
using game engine's builtins for the things you don't want to abstract yourself makes complete sense, keep the game to "game logic"
Astonishing, inspirational work.
Zero game logic was trapped behind unity, so it was mostly just replacing a few idiosyncrasies between Unity and Godot (X vs x in coordinates and colors being floats vs ints)
This social policing of technology is sad to see. Anyone can join and use it. Stop pushing a future you want to see for some reason.