(Original post: https://www.reddit.com/r/visualnovels/comments/prztxv/lets_talk_about_reasons_to_port_visual_novels_to/ )
It seems like companies are porting what should be a lightweight game into a heavyweight engine, so I'd like to talk a bit more about that.
Licensing cost for the engine (applicable to something with Siglus for instance).
Unity has a licensing cost too, but I can't make a conclusion on whether it is worse or better because it does not appear that the licensing method related to SiglusEngine is published.
Ability to run ports on other platforms, Switch, mobile for instance need Unity to run.
Unity is not the only option for multi platform development, despite what the general sentiment is.
For some such examples, I have ported Kirikiri, ONScripter, and Ren'Py to the Switch:
https://github.com/uyjulian/renpy-switch
https://github.com/uyjulian/onscripter-switch
https://github.com/uyjulian/krkrs
Ratalaika Games provides a commercial service for porting Ren'Py games to consoles:
https://www.ratalaikagames.com/services/renpy.php
I made a port of Kirikiri to use SDL2, which allows multi platform development on macOS, iOS, Android, Linux, HTML5 (via Emscripten):
https://github.com/krkrsdl2/krkrsdl2
Here is a game that is running in the web browser using this engine:
https://www.freem.ne.jp/win/game/26264
When you are using Unity, you are fixed to the platforms that Unity decides to support, and not all versions of Unity supports all of its platforms, such as Unity dropping support for the Playstation Vita.
Why port to something else (like krkr) only to have to port it again if we want to release on console?
It would be a lot less work to port the underlying engine instead of the game that runs on top of it to another engine.
Compared to Unity or Unreal Engine, Ren'Py, Kirikiri, and ONScripter has a much smaller API surface area (and they use SDL2) so it is much easier to port it to other platforms.
Additionally, Unity is closed source, so you may not be able to port it to a platform that Unity does not support natively in a reasonable amount of time.
Ability to implement additional features (like we did with Aokana, the music player for instance).
Ren'Py supports Python scripting.
Kirikiri supports TJS scripting.
ONScripter supports Lua scripting.
I want to use C# when programming additional features for my game
If you really wanted to use C#, I could see why you would use Unity. However, if you wanted to use C# in other engines, you could use C++/CLI (Win32 only) or libmono (Multi platform) to create a plugin/binding for that engine.
As long as you write your C# code in a way where you can easily change the runtime/rendering backend (System.Windows.Forms, MonoGame, Godot, etc.) by avoiding Unity-specific class (such as GameObject, MeshRenderer, Shader etc.), you can keep on using your C# code even if Unity Technologies goes flop.
GPU rendering
Kirikiri 2 minimal system requirement is Intel Pentium.
The latest Apple M1 and AMD Ryzen chips can run circles around that requirement with vector instructions, higher clock speed, and multiple threads, even at 4k resolutions.
You do not need the DirectX 11 minimal requirement of Unity to render visual novels. A lower requirement such as GDI or even DirectX 9 for window scaling will do the job just fine.
Asset compression/pipeline
(This relates to formats in the packaged game, not when using the Editor, in development, etc.)
Unity supports Unity Crunch for texture format and FSB5 containing Vorbis for audio format.
If you want to use other formats like Basis Universal or WebP for textures or Ogg Opus for audio, you pretty much need to add in external libraries to use those formats.
Or, if you want to use e.g. lossless PNG for the format, you need to mark it as a "streaming asset".
However, that takes additional effort and is not done most of the time, so instead you will get horrible texture and audio quality in the Unity port compared to the original game (see the World End Economica port for one such example).
Even if you use original Ogg Vorbis files in the Unity editor, it will still re-encode the file (even at quality 100), producing generation loss (unless you use my FSBToolEx utility which just does a lossless remux to FSB5).
Kirikiri and Ren'Py will not do such conversion to your PNG, Ogg, and WebP files, so you can get the same great quality from the development stage to the release stage.
Unity will block the editor while it is doing asset compression/conversion/creating derived data/compiling scripts.
With Ren'Py and Kirikiri, you can use separate tools to do those operations or even automate it. You do not need to wait on the editor.
Battery life
Unity will use more battery life than other engines, because it will constantly update the entire screen and not only the region that has been updated. The event loop is constantly running in Unity.
In Kirikiri, if nothing changed, and there are no timers or continuous handlers running, the screen won't be updated. The event loop will wait for a event such as mouse move or click before calling functions related to that event, and it will not busy loop, allowing saving battery life.
Bug fixes
If you report a bug relating to Unity, you will wait for a while for those bugs to be fixed and a new version to be released.
However, with open source engines (or even viewable source like Unreal Engine), you can report bugs and then fix the issue in your local copy of the engine so you can ship your game without needing to wait for a new version.
Stability between versions
Unity intentionally breaks backwards compatibility by removing or changing APIs between major versions.
Between minor/patch versions this is less of an issue (but you still have to wait a while for bug fixes anyways).
Ren'Py has a mechanism to enable old behavior depending on the version of the engine the project was created with.
Edit 9/12/2023: Another reason to not use Unity is because they can change the pricing model without your agreement. https://blog.unity.com/news/plan-pricing-and-packaging-updates
There are definitely some points I'm missing, so if you suggest some additional points I can go ahead and update this post with comments on those points.