Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags
(2 edits) (+1)

I didn't say anything about Ironsource.  You wrote that the engines you linked are better than Unity and are trivial to migrate to, so I was just asking you to support that.  The documentation available for them does not give me that impression.  I looked at Flax, too, for good measure, and felt the same.  Even migrating my existing framework appears to be non-trivial, let alone all of my existing content.

you can't add a framework onto another framework, i'm mostly thought everyone would have to either find a way to copy and paste their code to other engines or almost redo their project to fit the new game engine. Each engine runs in different rules to set up games so i dont know the problem when the problem is starting over in a new engine.

(5 edits) (+1)

That's the problem.  By framework, I mean all of the scripts, prefabs, mechanics, UI, workflow, environment templates, etc. that I have built up within Unity that support creating content for this game.  I first developed this for my previous game, refined and expanded it for my current one, and intend to continue using it in the next one.  By content, I mean all of the monsters, items, map data and so on that are specific to this game.  At this point, I am mostly in drag-and-drop mode for creating content, except for the occasional small feature that I need to code.

Moving all of that to a new engine would be a huge effort and setback, much more than a few days.  To give one concrete example, none of them seem to have a clear equivalent to scriptable objects as far as I can tell, which I use very heavily for a variety of purposes (custom assets in Flax might get part of the way there, but not all of the way, I think).  I would have to find an alternative implementation for each specific use case.  Most would probably have to be converted to JSON files, so I would have to convert the corresponding classes and my content management code to populate from JSON instead of just referencing a scriptable object in the editor.  Then I would have to migrate hundreds of scriptable objects specific to this project into JSON files, some of which would reference other JSON files that in turn reference still other JSON files.  Then even once it's working, I now have to deal with editing and referencing a few hundred JSON files, instead of working with that data natively in the inspector like I do now.

So that's one example of what would be involved.  I have a number of issues with Unity and this merger is one of them, so I am not opposed to finding alternatives, but the alternatives don't seem to be ready yet, and I don't think uprooting my current project is worth the effort and risk.  I am more likely to look at other options for my next project, but even then, there is still a lot that I would need to rewrite to make it work.  Right now I have a fully-functional, mostly-easy-to-work-with RPG model built in Unity that I am hesitant to throw away without a good solid alternative, and I don't really need the latest versions of Unity anyway.  I can stick with 2020 for as long as it's viable, if I need to.

you cant move scripts and other unity exclusive files to other programs, unity script developers made it only for unity, it was never designed  to work elsewhere. This may also go with unity store assets as well, they were build only for unity.

Yes, I know.  That is why the statement

there are better open sourced engines available to easy redo your project in a few days with C# Programming. 

is completely untrue.

it's true if you didn't exclusively use unity engine and every asset you got was from unity. No one controls how they worked,  the developers who rely too much on unity are now facing problem because of exclusivity not game problems.

Nope.  I do not use Unity store assets, and you do not know what you're talking about.  This is a waste of time.

if you cant move anything outside of unity then it's never meant to work anyway. C# code and other stuff should have been  able to move because the assets are not locked but if they are locked like your stuff then it is only created to be for unity. As i said scuptis are a unity thing just like blueprints are a UE4 thing, you cant make these work on other engines.

Deleted post

he wants to bring something from Unity like scripts, nodes, models,  etc to another game engine when in reality that none of those things work without Unity.  A programmer should not rely only in one program, if anything it sounds like he has something that allows him to build the game without coding which is only something many "programmers" do to make a game.

Plus no this is not Hysteric, remamber when Unity sucked being a browser and it took years for Unity to do something. That is the same fate your game engine spyware is going, into the list of block programs. Your time to build games in Unity will be wasted, your money will never return and many people will give up game development because of your crazy theory of Unity not becoming spyware when Unity itself knowledge the companies bad reputation.

Deleted post