I think this game uses almost entirely its own engine and Unity is just used as a HAL and porting harness, so this is sort of a best case scenario for ease of porting. There's a surprisingly large number of games like this, though they're not representative of most Unity titles of course.
Yes, in some interview he mentioned that Qud at the time was running as if it were a console app inside Unity. I don't know if that is still true after their UI overhaul, but if so it always seemed odd not to port it to MonoGame instead and save paying the fees.
Scanlines and vignette are simple to implement and the main stylistic shaders they use. They also use a grayscale one if you trigger a specific situation. There might be others, but again, simple to write.
They also use the particles system for candelabras. Could be reproduced in many engines.
Its the result of almost every component of unity out of the box, being useless longterm. Its a similar thing with android. The operating system is just whats used to load librarys to replace all the things - camera detection, crypto etc. And one day you realize, that the operating system is just that thin metal layer and the bootloader.
Sorry, I was complaining about Twitter not Nitter. Twitter isn't involved with Nitter.
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.
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).
The one aspect that godot lacks currently is the store and marketplace ecosystem.
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!
I don't know where I read that bit, but the maintainers are very aware of the lack of marketplace and I think it was the first point for the "how can we accommodate the new devs" list. So it's likely to happen relatively soon.
I never tried with Godot specifically, but i (and fellow varied developers) did it a lot in Unity and "it worked". The main points were :
- 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've done it a few times at my current job and it worked great for some simple UIs. Would probably work great for more complex stuff too but I haven't needed anything like that, I use it with C# as well.
That has once been true for Unity as well. People laughed about it being for gimmicky games that weren't too serious.
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.
> Godot is much less featured but extremely easy to learn imo.
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.
Does Unity have a true 2-D vector graphic engine or system of some kind? That seems like the main thing that doesn't look obvious to me as a total non-expert looking at Godot. (Mostly curious. I don't make games, but I hate the pixel-art 2-D style.)
Unity has an svg package which has been stuck in experimental state for years like many other unity features. I wouldn't call it true vector graphic engine. It can be configured to either generate bitmap sprite at build time (minor convenience over converting svg to bitmap manually) or it can generate triangle mesh (from what I understand also done at build time). In the second case once you start zooming it doesn't necessarily look very great either. Once you zoom out lines look bad since they are formed by thin strip of triangles which doesn't work too good for few pixel thin lines . And when you zoom in you start to see that its made from triangles instead of round curves since the generated triangle mesh is fixed. With both approaches svg benefits are largely lost compared to true vector graphic rendering engines.
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.
It seems like because there's so much custom code, rather than editor features, the author might as well use a rendering library instead of the engine.
When you want to build games for many platforms at once, dealing with platform-specific rendering, sound, and input code just becomes tiring. Having an engine at the base gives you these for free (or at a cost, with Unity).
no, a rendering engine just handles rendering, they listed multiple other things. don't conflate your definition to mean more than it actually literally does.
using game engine's builtins for the things you don't want to abstract yourself makes complete sense, keep the game to "game logic"
This reminds me of the recent DHH TypeScript kerfuffle. Imagine doing a port like this without static types. Every change you make you have to build, launch, look for a crash. Times like this you are so happy you built things in a more refactorable language and used a good architecture.
Astonishing and inspirational is the fact that the game has been in development for 15+ years and still is very well architected and designed to the point that it can be ported with such ease.
They did the smart thing and all of the game core is a separate C# package and they were using Unity mostly for the display bit.
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)
The only people joining X in 2023 are right-wingers, trolls, and bots. The chance of someone creating an account on X to learn something new is effectively zero.
> The only people joining X in 2023 are right-wingers, trolls, and bots. The chance of someone creating an account on X to learn something new is effectively zero.
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.
Leftists appear to have gone to Mastodon and then dissipated. Mastodon has many architectural and incentive issues that make it an unfit platform and unsustainable at scale. Fitting that leftists were unable to identify these issues!
