Now if only CDPR would eliminate their crunch work environment, and release games when the DEVS say it’s ready.
If you can’t afford advertising the game prior to launch, just don’t. That’s where for example Bethesda saved a ton of money. Released “complete” games within 1-3 months of the first announcement. (Do mind I’ve lost all hope in Bethesda)
In other hand, over-promising in terms of what’s actually currently out is fine. The issue is when you …
Don’t have the devtime. (Board releasing the game way before it’s ready, because marketing is so damn expensive, and the stockholders want it now not later)
Don’t have the skill. (Which means re-training all your employees constantly)
Don’t have the work morale. (Which leads to talent bleed, further exaggerating point 2.)
Protip: “It gets better later” isn’t a good way to promote a game.
It has to be good from the start.
If it isn’t and it can’t hook a player, you’ve just lost a customer, who likely just refunded the game as well.
Now personally: I like terraria from start to end. It got a bit boring in the middle. I used to not be able to play it at all because /something/ about the game really triggered my migraines. It doesn’t anymore, and I can play it.
Not untrue, but it helps to adapt your future projects if done in such a way.
It does require more expertise, and it takes more time, thus it’d have to be the first thing done for the project, not something you do after everything’s done already.
If you ask me engines should be free for most indies (UE, Godot?), because they’re not making millions. But yeah. I get it’s not feasible for most new devs especially, and senior devs have better things to focus on.
This is true, and I vouch for gamedevs to first test other engines to see the differences.
Calculating for the future is extremely important in pretty much everything.
Also I wouldn’t say there would be performance issues, unless you somehow completely screw up coding and compiling said code.
Projects should work on top of a bottom layer, or translation layer as it’s sometimes called; game logic calls for functions from there, instead of directly from the engine. This is also important for code security.
_move_entity might be calling the proprietary unity_move_object with a different reg stack, but when compiled the performance should be +/- 0.
As I said, it depends on how it’s built. And how proprietqry the engine is.
Unity from what I know supports universal code/mesh/texture formats, but if the devs opted for the “easier to use” proprietary systems- well, that’s a problem.
Now what I don’t know is how easy are scenes to export in Unity. They’re probably built with Blender or something else though in most cases, unless Unity has drastically changed.
I mean it’s easy to reimplement entire games if you’ve built it modularly. Just swap your core game logic to run on another library and the game works the same it did before.
Edit: 'course, exceptions exist like if you wrote everything using their proprietary coding language, instead of using something universal.
Edit 2: It MAY still be possible that a translation/compiler exists that’ll run as a plugin in a proprietary engine, and converts it into something universal.