It's far worse than that. Take-Two bought Squad and KSP along with it. Soon after they took Squad's original IP from them and gave it to Private Division to develop KSP 2. Then they poached staff from Squad. It's not like KSP 2 is developed in some innovative way, I was expecting that game like KSP 2 should have been developed in it's own engine since it's so unique among other games. But nooo. KSP 2 still uses Unity, and in worse way. You are better off installing better graphics mods on KSP.
* The GAME (KSP) and the IP was purchased by Take-Two, not the company itself.
* The IP was then given to Star theory (MNC/SMNC/Planetary Annihilation guys) to develop KSP2
* Star theory failed once to deliver on the budget they promised, they got extra money
* ST failed second time,T2 didn't wanted to give them more money, so ST wanted to sell out to T2
* T2 went "fuck it", took IP from them
* Take-Two was one to poach developers from Star Theory (not Squad!) to make new studio to make KSP2. IIRC they basically made blanked statement "if you want to work on KSP we will hire you" to their devs, a lot of them came over.
I assume the last part happened because T2 went "hold on, you failed to deliver then want us to buy you ? Why would we buy company with incompetent management in the first place ? Poaching devs is cheaper".
> You are better off installing better graphics mods on KSP.
You got it wrong. Star Theory didn't want to sell out to Take2. They realized Star Theory couldn't fulfill the totally-not-abusive-and-predatory deadline they wanted to release the game, so they said "ok" and tried to purchase the studio. They rejected the purchase, so they poached like 60% of their developers and employees instead, to a point that ST had to close doors because Take2 poached almost their entire work force.
> should have been developed in it's own engine since it's so unique among other games
with my limited technical knowledge about game programming and much less limited technical knowledge about software development in general this seems quite wrong
because while the game is somewhat unique in some point, in many many(1) other technical points it's not, so by using a game engine you can save a lot of time/problems with all the points it's not unique in and just either replace or adapt the parts where it is
so while Unity might very well have been a bad choice
the general idea of using an existing game engine was not
(1): Like window handling, input handling, asset loading/packing/bundling/compression, parts of game saving, most parts related to the rendering pipeline, menus, statistics/crash reporting, installers, and probably more.
Through this is also how game engines rot: By not maintaining many of the build in components leading to any non very simple game needing to replace them all the time.
I think Unity had been going into that direction.
KSP is a game that routinely runs into floating point related problems and a game that needs deterministic physics simulations to be accurate and glitch free at all simulation speeds in the vacuum of space and inside the atmosphere of a planet.
The "some point" is the main selling point of KSP. The "many other" technical points are beside the point. If you get the small things right but fail at the most important part, you fail overall.
if you can use a existing engine and not wast resources on all the things which are not the main selling point and in turn spend more resources on getting the main selling point right, why should you not do so?
AFIK few, probably non of the more successful established game engine force you to use their physics engine
Not sure, but isn’t unity in this case covering your need for some tools, like rendering, assets management and so on, but maybe not all - i.e deferring to them the physic. Or so would I say assume ?
I heard from someone who actually works in the industry (as engine developer) that companies usually don't use Unity out-of-the-box and write their own tools and extensions (e.g. memory management) and change parts of the engine as the needs vary greatly depending on the game they are making. Not sure how common that really is though.
You may be referring to Unreal in this instance. Unreal is open source* but you pay to license the engine, so you can make core changes I.e. memory management or tweak underlying net code. Unity is closed source and so you can only really extend very core parts of the engine.
FWIW my experience in gaming has been that Unity is exceptionally powerful and allows game developers to create games that would otherwise require an entirely separate dev team to support the engine. When I first learned game dev, the code sections were almost entirely devoted to interacting with the underlying graphics libraries (OpenGL or DirectX) and hardly any to creating powerful features in a game. Now, using something like Unreal or Unity is akin to using a web framework like Ruby on Rails or Laravel.
I think you might mean that unreal is "source available" which doesn't confer any of the rights of open source, but does allow you to view and modify the source code subject to a commercial license (which might be free for personal, small scale use. I don't know unreal's pricing structure).
Unreal is not open source (cf. the Open Source Definition: https://opensource.org/osd/). It's just that the licencee is allowed to view and modify the source code within the limits of the licence.
BTW, unity does offer a full source of the engine to companies that are willing to pay enough for it. So you can effectively modify it as much as unreal.
Although, I don't even know if the KSP2 studio is big enough to afford it, let alone if they are actually doing it
My limited experience with Unity was that, if you are planning to do something the Unity way, its very easy to bootstrap and start just coding cool features. Which is why theres a proliferation of Unity store assets + cheap gameplay on steam.
But if you want to do something a bit more complex, like modifying 3d objects in flight based on unit interaction, not only are you fighting an uphill battle, but the documentation is all out of date and mostly wrong. Because Unity isnt just an engine, its a set of default addons to that engine, and each of those addons was written to be just generic enough, but mostly just enable people to start making FPS and RTS games really quick. If you want to step outside that paradigm you are basically just engine coding again.
Plenty of companies have source access to Unity and write their own custom portions of it. It's just not accessible at the hobbyist or indie budget level. It's one of those "call us for pricing" situations.
Common patterns from non-indies using Unity is something like that: write your game with the idea that Unity handles the rendering and media stuff, everything else you write/manage yourself with a proper C# codebase.
> write their own tools and extensions (e.g. memory management)
I've been using Unity since 2009, and have been a lead developer and CTO in several different companies. I have never heard anyone writing their own memory management for Unity. May be you're talking about object pooling?
It's kinda what ECS is, depending on how loose you want to get with the term memory management. And studios have implemented their own ECS in Unity long before Unity's official ECS framework.
