What are you going on about.

These games are closed source with IPs owned by multi-billion dollar corporations.

The engine being closed or open is of literally 0 consequence. Any 3rd party reverse engineering these games to run on a new platform would already be breaking licenses and trademark laws.

How much of the Steam cataöog is owned by big publishers? 10%? These generate most of the revenue. Bit there is this incredibly long tail of smaller games ownes by small publishers and indies who self-publish. These are virtually exclusively Unity engine titles. And there is no way any of thesw could afford the 6 or 7 digits for a source license. And unless thungs changed, you won't even considered eligible without an exceptional track record.

Which just goes back to my original point, if these small titles had been interested making open source games they wouldn’t use Unity.

It doesn’t matter how big the owner is anyways, you don’t own the IP.

So Unity being open sourced wouldn’t matter for a 3rd party trying to port it, and the majority of these small titles that initially willingly built on a closed sourced platform are not going clamoring to port their own games to new platforms decades from now.

Do you have any experience in game development? Unity is an affordable engine that saves small developers a tremendous amount of time by being a well rounded powerful and easy to use package. It has absolutely no open source alternative and not using either it or Unreal is economic suicide.

Most of the Unity titles might be forgotten in a decade. But some (which peobably means a few hundred) will not. Their devs might have trapped themselves by being locked in by the engine.

> Do you have any experience in game development?

Yes I do, which is why I handily spotted your attempt to bury the lede

>not using either it or Unreal is economic suicide.

Unreal is source-available, and while you owe them royalties (fairly enough for all the work they've done), you can port it to a new platform.

And how is using Godot, libGDX, cocos2d, or dozens of other engines and frameworks people used for decades "economic suicide"?

The notion that starting from a framework that includes the kitchen sink and more is magically a requirement to make a successful game is silly.

The words of the creator of Braid, one of the most successful indie games of the decade:

> I don't have any desire to use a different engine for many reasons, and it's unclear which are the most important reasons, so let's start with the least usual one. Which is: when I'm making these games, they're not just commercial products. They're expressive works that we're working very hard to make, and we want them to have as long of a lifetime as possible. So I would like this game to be relevant 20 years from now, 40 years from now. How do you do that? Well, you don't necessarily do that by building it on top of a very complicated system, that you don't own, that somebody else will cease to support at some point in the future. Once future consoles happen or current PC operating systems no longer work, we at least have the source code to the whole system so we can make it work in the future. If Unity ceases to support something in the future, you basically have to rewrite it on a different system, and depending on how much of your gameplay depends on the core of how that worked, it may be very difficult or impossible to reproduce the same thing."

Don't confuse the fact that Unity lets you churn out content quickly with the idea you need it to succeed.

Unity's ubiquity is as much from good indie games as it is metric tons of soulless chaff clogging up every major software store on ever platform

And besides, on one hand this thread is talking about archiving games by porting them to hypothetical systems that somehow can't run a Windows executable (laughable in itself honestly), but the know-how and effort to make a game without Unity is "economic suicide"?

>Their devs might have trapped themselves by being locked in by the engine.

This is not Unity's fault or problem. Unity made the huge step of making the C# portion of their engine source-available, which already tells me they're headed in the right direction, but trying to wave the "archival" flag in their face is silly.

Archival isn't a problem on Unity's side. If we ever reach a place where you can't run a Unity game on a Windows PC, the work people will do will not be to try and run Unity games on Windows 2095, it will be to get Windows 10 running on the machines of the future.

I am taking serious offense to your statement that I intended to bury the lede. Do you think that I want a free ticket to their tech and I am constructing straw men to support that?

I respect creators. I am not pirating any games. The games in my Steam account set me back thousands of dollars.

If you think that I am only tying to make copying games easier, you are dead wrong. In another post I was proposing a source escrow scheme for the runtime. This doesn't square with a desire to pirate anything.

I am trying to find a reasonable stance here:

- The true stength of any major game engine offering today is the integrated toolset, not the runtime. The Unity Editor is an amazing piece of software in that regard. I am explicitly not calling for that to be opened up because (a) its job is done once you hit the export button, (b) it is very extensible through scripting and (c) it is how Unity as a company earns money.

- I only called for the runtime to be be made available for future maintainance. That in itself won't make existimg Unity games magically available on future platforms. There are multiple reasons for that. The most obvious one is that games may contain contain other native code components. They would need to be updated or replaced by someone with access to the game source code. Im the vast majority of cases, I do not expect such a task to be particularly hard or time consuming.

- Essentially, I want a world where games are no longer transient experiences. This is why I am singling out Unity because it has the potential to be either the one big enabler of that or the largest roadblock. The way the engine architecture enforces most game code to be platform independent could give games a much longer life than ever before. Yet the risk that the engine is eventually fading away without a meams to keep it updated could rob the platform of that very greatness.

- Windows is extremely complex and emulating it is hard. Wine is only a thing because it "only" needs to act as a system call translator. No hardware emulation is required. And getting that right has taken decades of work and it is still shakey. I don't see this as a viable way forward.