Unless you've worked in games, it's really hard to understand just how massively tied to the engine a game is. Imagine you have a web app written in Ruby using

Unless you've worked in games, it's really hard to understand just how massively tied to the engine a game is. Imagine you have a web app written in Ruby using Rails with data stored in Postgres. You have a few hundred tables, millions of rows. Millions of lines of Ruby, CSS, and HTML. Thousands of images carefully exported as JPEG, GIF, or PNG depending on what they contain. Now imagine being told you need to simultaneously port that to: - Not run on the web. Instead be a native application using the OS's rendering. - Not be written in Ruby. Instead using a different language. - Not use Rails. Instead, use a different application framework. - Not use Postgres. In fact, don't use a relational database at all. Use an entirely different paradigm for storing data. - Not use CSS, HTML, and raster images. Instead, everything needs to be, I don't know, vector images and Processing code. That's about the scale of what moving from one game engine to another can be like. Depending on the game, it's isn't always that Herculean of a task, but if often is. A mature game engine like Unity is a programming language, build system, database, asset pipeline, application framework, IDE, debugger, and set of core libraries all rolled into one. Once you've picked one, moving to another may as well just be creating a whole new game from scratch.