The Unity Games That Could be Impacted Most by Controversial Fees, From Silksong to Cult of the Lamb - IGN
The Unity Games That Could be Impacted Most by Controversial Fees, From Silksong to Cult of the Lamb - IGN
Probably not but the good news is a lot of the pains of developing a game is that unlike most projects you need 10 artists for every one programmer
So, while core logic will likely change, all the other assets and planning is done. It shouldn’t be as bad as remaking it from scratch
Fair enough, but it’s still a massive time and resource sink. You also can’t really implement new features during the re-write lest project creep gets out of control, and even after the rewrite the product will be less stable than the original for quite a while until it’s had sufficient time to mature.
It might be worth the investment to ditch proprietary software from a predatory company and jump to open source though, which can’t really pull shit like this in its future.
Not necessarily since different toolsets have different logic operators and transformers and the logic isn’t always 1-1. I’ve moved enough code from even the same language but different implementations, nothing to say of entirely different system and languages.
Speedruns show how much of a bodge jobs a lot of games are and how much they could be broken.
It depends.
I’m working on a game with Unity and the software design has been done in a way that keeps most the game itself as data, and uses the Unity stuff mainly as a display a multiple views on the state of the data (a 3D view of the game space, multiple UI elements diving into slices of the data an so on) - basically a Model-View-Controller Architecture, so moving from Unity to something else doesn’t require a rewrite (in fact such structure makes it possible to with some ease change the game’s visuals from 3D to 2D), though it would still be quite a lot of work.
However my game is survival-management in space (within one or more generated star-systems, so it was simplified down to a 2D plane) which doesn’t relly on Unity things like terrain, navigation meshes or even colliders to constrain the movement of objects in the game, so “what happens next” (say, the movement of planets or the guidance of ships going from planet to planet) gets decided using Maths at the data level without going through the Unity layer, and Unity is mainly the stuff from which user input comes and into which the state of the data gets reflected (i.e. game objects get moved around) for rendering.
Other games which are not reliant on Unity to do the heavy lifting for objects interactiong with other objects on a 3D space, such as 2D platformers, can probably use a similar architecture, but for example something like Valheim or Planet Crafter (were the players is a humanoid avatar on a 3D world which is mainly terrain) is probably much harder to move out from Unity,
Third-party tools might or not be a problem depending on whether those tools also support other frameworks or there being equivalent tools for other frameworks.
Again, it depends how tightly coupled the game is to the framework (directly or via 3rd party tools), but yeah, the more work you’ve sunk into the Unity-specific side of things and the more tightly coupled your game is to it (i.e. doing everything via Unity rather than, as I did, make the game run as a data model which then dictates how the visual layer - which is where Unity mainly is - is updated) the harder it will be to move.
I don’t think one can say “it will be a problem” because there are so many different ways to do a game (do you really think “terrain tools” matter in something like Terraria???!), all one can say is that “it might be a problem”, which is what I’m saying, and judging from my experience with it it will be more of a problem for people doing 3D worlds with terrain, pathing and so on.
Whilst I’m currently on vacations, next week I’ll have to start evaluating both Godot and Unreal for my project - which, as I said, whilst it does show things in a 3D view, is architectured so that the game essentially runs in data space with user-input coming from the framework (and it’s pretty easy to change that because it’s centralized) and on the other side the framework rendering visual views of the data.
My plans to upgrate to the latest Unity are now shelved and I’ve already planned how I’ll remove the last pieces of Unity influence (basically Vector2) from my data layer and make sure it’s totally separate.
You can port over a lot of C# code into Godot, but there are things that are engine specific. However, they are similar enough that you can just work on refactoring without sgarting from scratch.
I’ve ported a few of my projects from Unity and it’s not impossible, it’s just a lot of copy and pasting and making a few changes