OSS Game Engines are increasing their stars on GitHub due to Unity's missteps

136 points6
lucb1e5 hours ago

Which just links onwards to with a screenshot:

If you click through to pull requests or issues created, the trend is between modest and potentially not statistically significant (there's also a lot of red digits).

The stars graph from godot is vertical since last month though, especially given that they already had the most stars by far (67k in August, compared to 43k for the runner-up pixijs) and an account has only one star to give so that's a lot of new interest.

Snafuh2 hours ago

Godot actually has a bit of an issue with too many PRs. Lots of them are just small changes, usability or documentation changes, but they still have to be reviewed.

They need steady funding to have a team of capable full time devs. Their fund seems a step into this direction.

gmerc4 hours ago

Missteps implies accidents. This was not accidental, it was an attempt at extracting rent - retroactively.

courseofaction4 hours ago

Purely conjecture, but somehow I suspect that private equity has crunched the numbers and decided it's time to milk this one dry.

xbmcuser4 hours ago

They are making a billion dollars loss a year. So with no vc cash available they need to get profitable if they want to survive. You can argue this is wrong way to go about it but they do need to get profitable.

gmerc2 hours ago

They miscalculated, which is a risk with investments. Miscalculated badly and executed worse. They bet on ads and ads is not the growth market it used to be. They bought IronSource and their main competitor, AppLovin is kicking their ass.

The neglected the core product and have the gall to justify their retroactive change of terms (after sneakingly deleting assurances to the contrary from the TOS and deleting the github repro that tracked transparency after their last PR disaster) with rising costs of maintaining the runtime that’s been falling into disrepair.

Investments carry risk. Investors may dream that it’s ok to get made whole by the game industry they tried to take over using VC money to build a dominating position and then changing terms and extracting rent but this is such an open and shut case of corporate mismanagement, deceit and hubris, no point in even trying to justify that.

If they want to survive, they fire the CEO, claw back bonuses and shares from executives and shrink the company to a size that’s warranted.

Unity can die in a fire, anyone with a choice will know better than to get into a relationship with them now. There’s enough landlords in the industry already with platforms, there’s no room for another extracting value of the hard work of creatives.

Accepting their terms requires broad changes to the industry business models - back to old EAs dream of charging by the download. And it requires open eyes walking into a relationship with a company that every time their CEO makes a shitty gamble will extract the losses from developers.

Burn it with fire.

raincole1 hour ago

Unity had 7000+ employees before layoff.

Valve maintains one of the biggest platforms, and their own game engine. Valve also developed CSGO, TF2, and Dota, all popular online games that need constant maintenance (and even big content updates sometimes). Valve also invested in VR and sells hardware.

Valve has 1200 employees.

To me it's easy to see why Unity lose money.

teamonkey16 minutes ago

Unity are currently asking for 4% of revenue over $1M for developing the engine and toolchain that game developers will use all day every day. Valve skim 30% of the retail price of the game for the priveledge of hosting a game on their storefront. This is why Valve makes money.

qwytw4 hours ago

Massive over hiring and random acquisitions are there main reasons why are they here. If they hadn't increased their headcount by 5k and continued focusing on their core products the company would already be profitable (even if revenue would be lower).

At this point it's too late to significantly cut costs, so yeah seems like they pushed themselves into a corner.

The sad part is that it was already perfectly obvious where were they heading after they IPO'ed.

usrusr3 hours ago
HFguy59 minutes ago

"Purely conjecture, but somehow I suspect that private equity has crunched the numbers and decided it's time to milk this one dry."

They are a public company at this point. Not a fan of PE but no need to blame them for everything.

qwytw4 hours ago

They can only get anything from it if the stock price goes up though. So far this isn't helping. Also it won't be several quarters until the additional revenue kicks in, by the time they might already be losing significant numbers of customers which the market won't like even if the financial start looking a bit better.

RockRobotRock4 hours ago

Milk dry, or try to start making money?

poulpy1233 hours ago

the missteps was thinking they could get away without so much trouble

master-lincoln3 hours ago

How is it retroactively? Publishers are only charged for new installs from next year on.

langsoul-com3 hours ago

It's retroactive because the publishers originally signed a contract that didn't have any per install fees for that version of unity they're using.

Now, they will be charged, despite not changing the unity version, as if next year. Retroactively applying the new contract terms to the old one.

master-lincoln1 hour ago

I don't think what you describe is the case. My company works with Unity and is not worried about any change until the license runs out. Only then will we form a new contract and accept the new terms and conditions. Changing a contract one-sided is not really legal in the EU

breezeTrowel38 minutes ago

What they described is exactly the case. Hence the controversy. Your company should be worried because these ToS changes have been applied retroactively. I agree with you that this is not legal but that is what's happening. Check Unity's own FAQ:

Q: Are these fees going to apply to games that have been out for years already? If you met the threshold 2 years ago, you'll start owing for any installs monthly from January, no? (in theory). It says they'll use previous installs to determine threshold eligibility & then you'll start owing them for the new ones.

A: Yes, assuming the game is eligible and distributing the Unity Runtime then runtime fees will apply. We look at a game's lifetime installs to determine eligibility for the runtime fee. Then we bill the runtime fee based on all new installs that occur after January 1, 2024.

justinclift41 minutes ago
Drakim3 hours ago

They used to have a clause that you could use the old terms of service from when you published your game. But it was removed in favor of even games developed under those terms of services needing to pay. That is very much a retroactive change.

master-lincoln1 hour ago

I still don't see how that is retroactive. The TOS changed, but I only accepted the TOS how they were when I paid my license. So the new TOS do not apply until my contract ends. That is the law (at least here in Europe)

RHSeeger28 minutes ago
breezeTrowel34 minutes ago

Yes, it's illegal. They are still doing it. Make sure they don't have your payment information when they start the first wave of billing in February.

chess_horse_L2 hours ago

Yeah, and everyone will be back to Unity in a month. People need to make a living, y'know. They need to make games/assets NOW, not in 3 years once those engines are ready.

For example, I see my Twitter timeline full of people slowly realizing that Godot is not Unity 2, and complaining about the UX, GDScript, C# and performance problems.

So, they either have to live on that hill and contribute to Godot (And sometimes these problems are by design! Godot is made to be slow so it can have more usability, just check out the creator's Twitter),

or, y'know, they can (And will) just go back to Unity and keep making stuff, even if they at any moment they'll put a knife on your throat.

gmerc2 hours ago

Unreal is a viable option for most people. Epic is the devil we know.

chess_horse_L2 hours ago

It's not. Most of Unity games are mobile games, or indie games that don't require the GPU usage bloat Unreal has in order to achieve better graphics.

If Unreal was ever an option, developers would've been using it instead of Unity in the first place.

catapart50 minutes ago

In case anyone cares, this commenter is absolutely incorrect; Unreal does support mobile development, and it obviously uses a more lithe package than its full GPU stack. Using only the UI objects, 2D is pretty simple and I haven't had any major package size issues. Using a 3D context to render 2D as planes in the scene, I can still get a package down around 70MB with optimizations left on the table. It's harder to work with 3D-as-2D, but that's why I use the UI system. It's robust.

I certainly like Unreal, myself, but I can't say it's an easy move from Unity to Unreal. That aside, one of the very first options you see is whether to scope your game for mobile or for "desktop", so I'm not sure why this commenter thinks that Unreal would not be an option for mobile development. It sucked before UE5, so maybe that's the hang up, but so did a lot of things.

chess_horse_L33 minutes ago

Jesus christ. You say I'm absolutely incorrect, yet you're happy with a default package of 70MB?

Unfortunately, I know what I'm talking about. I've even modified the Unreal source to get a package size of 20mb, for a full game. I've digged through configurations to enable a simple forward renderer. I've faked all lights since a simple lit material would destroy performance.

That was on Unreal 4.20, I don't know how much has changed ever since, but probably not much since I don't see any low-end mobile improvements on the roadmap, they're all focused on high end.

Still, Unreal sucks for mobile, compared to Unity. It's unperformant to run on a mobile, and unpleasant to work with. It supports mobile? Yeah. Should it be used for mobile? Nope.

Also, you've just mentioned that you're using a hacky workflow to work with 2D. You're already sacrificing too much, for something that would work better in Unity.

Source: Worked on a company that had a mobile Unreal game. It ended up being ported to Unity.

softwaredoug58 minutes ago

If the OSS game engines want to monetize their work, won’t there be a pressure to switch to a pseudo-open source license, then push for some kind of licensing structure ala Mongo, Terraform, and Elastic?

I just wonder if they become popular, either the companies that use them organize into a foundation to maintain the code. Or the grunt work has to be paid for somehow.

Macha44 minutes ago

It's not clear that they are out to monetise, or they may not have made a FOSS engine to start with. Some (Godot, for example) have deliberately set up their ownership and governance structures to make such a source-available/open core pivot if not impossible, then very difficult.

justinclift47 minutes ago

Blender seems like a good example of gaining traction + keeping honest.

Hopefully Godot follows in their footsteps more than those other ones.

benabbottnz5 hours ago

I’ve been enjoying all the new discussions, comparisons, and content surrounding open source game engines.

Even if it’s clickbait or shallow content, it still raises the awareness of these tools.

d--b27 minutes ago

Why is never in those lists? It’s not event in the wikipedia page.

zerr4 hours ago

Freedom-wise, Unity is a Delphi/PowerBuilder/Clarion/ColdFusion of game development. The "free as in beer" licensing was the main reason it stayed relevant until now.

TulliusCicero5 hours ago

Sad for Unity devs' predicament here, but happy to see Godot gaining increased interest. It's still not as mature as Unity, of course, but they're making steady progress, it definitely seems to be headed in the right direction.

andybak4 hours ago

This rather dampened by enthusiasm for Godot:

It's carrying a lot of performance baggage and there seems to be no sense of urgency in fixing it.

badsectoracula2 hours ago

FWIW from the comments i've seen on Reddit it seems that some of the reasons he brought up for wanting to do so many raycasts are already covered by Godot's functionality (in C++).

Also IMO unless you want to share C++ plugins with others (via GDExtension), if you are making a game with it you'd want to modify the engine itself for any non-trivial functionality anyway. Again, the situation he describes sounds like it would be much better done by writing the reusable controller itself as a node written in C++ inside the engine itself (not via GDExtension) that uses the fast physics API directly.

Basically what he describes is an issue only in specific situations and not something that would really stop someone from making their game.

andybak25 minutes ago

I read that thread too and he just seems like a bunch of people denying there's a problem. The sibling reply here rather contradicts your point as do several others replies in the Reddit thread.

TulliusCicero4 hours ago

Yeah, it's true that raw performance doesn't seem like a major priority for the Godot community. If it was, GDScript probably wouldn't be the default language. There also seems to be a lot of defensiveness around GDScript's weaknesses.

Personally, I found that signals were very slow for communicating node to node, was dropping information because it could take longer than a frame.

Winsaucerer2 hours ago

It's something that is known and a work in progress:

andybak28 minutes ago

This subthread is new since I read through and it is much more encouraging. Shame it got lost among all the people claiming there wasn't a problem.

drones3 hours ago

Had an audible chuckle the other day when I saw humble bundle's current massive Godot sale. Hopefully with this increased attention we can draw new programmers to gamedev with an approachable language like python.

qwytw3 hours ago

> approachable language like python

Python doesn't really scale though and it's fine only for simple games/scripting (on top of a game mainly built with another language). If you're serious about game development you'll have to switch to C# or C++ eventually.

Also I don't see how C# is not "approachable" (C++ is another manner). If you're serious about programming you'll have to figure out static typing at some point anyway (and types is something you have to understand anyway when working in Python even if you can avoid that for some time).

keb_36 minutes ago

> If you're serious about game development you'll have to switch to C# or C++ eventually.

Were the creators of Undertale, Hyper Light Drifter, and Hotline Miami not "serious" because they chose to use GameMaker? I understand the pitfalls of using lightweight scripting languages, but not everyone is trying to create Doom Eternal.

badsectoracula2 hours ago

> Python doesn't really scale though and it's fine only for simple games/scripting

IMO GDScript (and any scripting language in games) should be treated exactly as a language only for that (scripting) and anything non-trivial should be done in C++ anyway.

thelastparadise2 hours ago

This is often said, but is it really true?

Im thinking of libraries like torch, tensor flow, or pandas.

I'm not sure rewriting torch client code from python to c++ would typically be that much faster as most of the work is already being done on the GPU and is highly optimized (much like a game).

jillesvangurp1 hour ago

It's true right now though there are a lot of people working on different ways to get python to have near native performance. I'd say it could be a fixable problem.

I was listening Lex Friedman's podcast featuring Chris Lattner a few months ago. He's is working on Mojo, which is basically a fast superset of python that can be fast (if you opt in to a few things) and worst case just falls back to being as fast as regular python. The intention is to give people enough means that they can optimize such code to be actually fast or just run it as is.

I'm not much of a python developer myself, even though I do have to deal with it occasionally. I liked the point that he made that, for whatever reason, there are just a lot of people using python and getting access to that community of people is a good way to get traction for your tool or technology. He was talking about machine learning specifically. A lot of the experts in that field are using python. Of course all the difficult bits and bobs are outsourced to native libraries. His vision is that a lot of that stuff should be written in mojo/python and that there are no good reasons why that should be any slower.

Probably removing the gil will help (everything blocking is not cool). And the language could use some better primitives for dealing with things like co-routines. They are kind of nice to have in asynchronous code bases like games or UIs. But those are things that could be fixable and might benefit the rest of the ecosystem.

pjmlp4 hours ago

Stars are not feature parity.

mijoharas2 hours ago

Who is saying that they are?

dzonga4 hours ago

quick qn for game dev's ?

why was C# adopted for game dev ? compared to java given that they're both similar langauges which use a vm.

I do understand that C# has a better native interop story. than java.

and probably the only notable jvm based game was minecraft

Kipters4 hours ago

I'm not a gamedev, but my hypotesis is that one of the reasons is that Mono license at the time was way friendlier than risking having Oracle on your neck.

Modern C# also has more features that help avoid allocations, which in turns reduce GC pauses, which are the biggest enemy of a game

Maken4 hours ago

I think its adoption was mostly influenced by XNA. A lot of small (and big) games used the XNA libraries, and by extension the .Net framework and C#.

pjmlp2 hours ago

Java is also adopted by game devs, even if to lesser extent, many mobile games, J2ME and Android, Minecraft, game tools.

However CLR has support for AOT and C++ since day one (even if NGEN isn't that great and only covers specific cases.

C# has thus access to the CLR features needed for C++, while exposing them in a more developer friendly way, and since C# 7 many of those features that required direct MSIL manipulation are being exposed as language features, making it even more easier to use.

orthoxerox2 hours ago

Unity and XNA, but mostly Unity.

Unity used Xamarin to target iOS and Android, so this meant using C#. As Unity's popularity grew, so did the use of C# in gamedev.

XNA was a very well-designed game framework (not engine) that allowed many people to get into indie gamedev without learning C/C++ and SDL or OpenGL. Java had nothing comparable, libGDX was released only in 2014. If you followed one of the indie stars and tried to emulate them, you were quite likely to learn XNA or one of its reimplementations.

qwytw3 hours ago

IIRC they were using Python initially. Turned out it was way too slow (also it was the mid 2000s).

They hired the guy who created Boo (a python like programming language) and switched to Mono (I'm not sure why they picked it instead of JVM I guess it was possible related to licensing but because they just had people who were experienced with it).

Also C# wasn't even their primarily programming language until 2012-2014. It was UnityScript (JS like syntax running on Mono). The idea was that C#/static typing was too scary/complex for most of their uses.

throwuxiytayq5 hours ago

I'm actually kinda excited to start learning some of these. How nice of Unity to force me out of my comfort zone!

TulliusCicero5 hours ago

Godot is quite easy to learn as far as general purpose game engines go. Lots of material around too, I know a lot of people like GDQuest and HeartBeast. Their subreddit and discord are also popular.

thelastparadise2 hours ago

Godot seems to be the clear winner in all this.

peremptor5 hours ago

Im not well versed in game programming, however I have some knowledge on how to properly structure your software architecture in other domains.

In regards to third party dependencies I agree with what Uncle Bob says, which is to keep them as far away from your stuff as possible. Only introduce a hard dependency if you have to. In my current project I have been doing that and I enjoy the flexibility that this gives me.

For example I can exchange the DI framework for the whole project in a matter of days if need be.

Which leads me to my question with the Unity debacle.

Is it not possible in game development to also structure your architecture that way ? Is the extra work not justified if you have deadlines ? Or is there just a lack of common interfaces that can serve as proper abstraction ?

I am really interested if someone with more insight on game development could shed some light on that.


maushu4 hours ago

The problem is that Unity is a game engine, not a game framework. That means that any code you do will be following their architecture and using their features. The game logic gets really tight to the engine.

...unless you are Brian Bucklew

Note: That is not the "normal" way to use a game engine.

baq4 hours ago

Holy porting Batman.

Caves of Qud is definitely going on my watchlist now.

rishav_sharan2 hours ago

That is glorious. I would recommend that you post it as its own thread.

istjohn54 minutes ago

It was posted recently.

thelastparadise2 hours ago

That's absolutely incredible. I agree this would make its own great post.

otikik3 hours ago

There's 3 kinds of dependencies. The best way to describe them that I have found is a metaphor with the Terminator movies.

* Libraries are tools that your app uses. For example, the JSON parsing library. They are relatively easy to switch from, as they are (usually) used for very specific tasks. For the terminator, a library would be a shotgun.

* Frameworks are pieces of software your app embeds into. They have a set of conventions and procedures that condition the shape of your app. In exchange, they provide a lot of baked-in functionality, which is usable by your app right away. Ruby on Rails is an example of a framework for web development. They are more difficult to switch from, because your code is "shaped" in a certain way and it relies on the framework to several tasks for them. For the terminator, a framework would be a motorbike. It's difficult to jump from a running motorbike to motorbike, if there's a T1000 chasing you on a truck (that would be a deadline). It can be done, though. Much easier to do if you prepare in advance.

* Game engines are similar to frameworks, except the dependency goes deeper. Your game is not embedded into the engine. Instead, it is made of the engine. Unity is a game engine. It's very difficult to switch from one game engine to another one. The engine would be the terminator's endoskeleton - the metal skull, torso, arms and legs, plus the initial "bios". Your game would be the living tissue put on top of that metallic frame, as well as the directives programmed in the brain ("Protect John Connor").

zadokshi4 hours ago

Can you abstract away your website so it can run on node.js or angular?

Game development is typically very tightly linked to a mess of proprietary tools and products and platforms. It is the game engine itself that abstracts away for example) the payment/subscription api.

If you were to write your own game abstraction layer we would call what you did a game engine.

Secondly, performance (frames per second) is key in game software. Imagine if you wrote a lightweight abstraction layer for a physics/gravity engine. You’re effectively writing code to slow down your game FPS.

Thirdly, game development is often done by young beginner programmers, who often don’t even know programming yet. They get into game programming by following online YouTube tutorials in a specific game engine. If you know the importance of abstraction your already too high paid to work in a game development position :)

KronisLV4 hours ago

> Can you abstract away your website so it can run on node.js or angular?

This is an excellent point. At that point you'd need so much abstraction that you'd basically be building something as complex as the underlying engines.

In rare cases that works out, like for Caves of Qud, but mostly because of the nature of the game:

The best most folks can dream of is decoupling some of their game logic or mechanisms from the engine somewhat, like what Captain of Industry did:

That said, I'm surprised that engines like Stride or NeoAxis don't try to imitate the Unity API more - making porting from another engine easier, or being able to reuse some of your existing skills would surely be a good selling point!

pests3 hours ago

I read the Caves of Qud post. What exactly is he using a game engine for in the first place? If it can be completely swapped out like that then maybe it wasn't that important in the first place.

krapp2 hours ago

Ease of porting and platform support.

zadokshi3 hours ago

Yea, to be fair, you can abstract away some parts of games to be sure. You can usually put non graphics related game logic, data persistence, networking into a shared library in your preferred programming language as long as that language can expose its api using a c layer or some sort.

salawat4 hours ago

>If you know the importance of abstraction your already too high paid to work in a game development position :)

Way to tacitly admit the gamedev space is a fundamentally exploitive industrial vertical.

heavypixels4 hours ago

It's not really possible because a game engine works differently from a library.

A library is a component that you add to your application. While it might be opinionated in the way it presents its interface, you can typically build some kind of abstraction layer on top of it and swap it out with something else in the future.

A game engine basically is the application, and your game builds on top of it, filling in the game logic, assets, level design, etc. The earliest game engines like Unreal Engine 1 were basically just the game Unreal with all the game-specific bits stripped out.

An engine is more than just opinionated. It determines the general application flow and structure, how each component is conceptualized in the architecture and how things connect. It even determines which programming language you can use. You also just use a lot of components from the engine: rendering, input handling, physics, animation, networking, parallelism, asset processing, etc. Things of that scale would probably be separate libraries for most other types of applications.

Beyond programming, much of your work will be in engine-specific formats that simply cannot be automatically converted to another engine: project files, level design, component connections and settings, graphical programming and shaders, animation state machines. You could design all of this in your own custom formats and build it programmatically, but why would you take that development overhead when engine's editor already does it so well?

That's not to say that porting from one engine to another is impossible. Assets like graphics and audio can be moved with no or minimal adjustment. Game design is still the same, and typically most concepts are similar enough between engines that you can do a line-by-line conversion for most of your code. And some games really do use Unity more like a rendering and input library, Caves of Qud is one example. But those are rare and most games will simply require a lot of elbow grease to shift engines.

nine_k3 hours ago

In other words, game engines are frameworks. Porting from Unity to Unreal may feel like porting from Rails to Django: not an impossible task, and you can keep some key bits, but you have to rewrite and rethink a lot. (Ruby and Python are even closer than C# and C++.)

reidrac1 hour ago

More than port, I would call it conversion.

courseofaction4 hours ago

I don't feel like an expert, but I'm a full time Unity dev with experience on non-Unity AAA projects.

There are the obvious advantages of having a pre-built editor, standard environment, fantastic build tools, and generally handling a lot of the complexity of managing a project, particularly in the early stages.

It's possible to limit your use of the engine to these time-savers, and essentially use it as a front-end for your game, however many workflows within the Unity projects make heavy use of engine-specific features which become an integral part of the game over time.

Rewriting scripts to not make use of the Unity engine's C# features isn't necessarily major challenge, depending on how reliant you are on engine-specific features. But when you've set up dozens of entities and items using Unity's animation state machine UI, laid out your levels in Unity's editor, and saved hundreds of different reusable assets as Unity-specific "prefabs", setting up all the relationships in your project which aren't determined by code would be a massive time sink.

thelastparadise2 hours ago

> when you've set up dozens of entities and items using Unity's animation state machine UI, laid out your levels in Unity's editor, and saved hundreds of different reusable assets as Unity-specific "prefabs"

Perhaps this was a mistake.

reidrac1 hour ago

Or may be not. People commit to use a tool, so why not doing it fully so you get the most benefit from it?

It makes everything harder if you want to use a tool without really using it so you can move to a different one if needed.

andybak4 hours ago

1. Unity projects mainy use C#. So that automatically limits the frameworks you can switch to unless you want to port to a new language.

2. A fair chunk of your code will be calling in to the Unity runtime to use functionality provided for you. This may not exist in other engines or exist in very different form

3. Unity controls the gameloop and the renderer. Other engines might have very different architectures and constraints.

4. Abstractions cost performance. You're usually trying to hit a very tight millisecond budget per frame so adding extra layers of abstraction is not good practice.

raincole1 hour ago

> Is it not possible in game development to also structure your architecture that way ? Is the extra work not justified if you have deadlines ? Or is there just a lack of common interfaces that can serve as proper abstraction ?

The simple answer is:

Yes, you 100% can, if you code it like that from the very begninning.

No, most people don't, because most game engines are not desiged for this so it's extra man-hours with no visible value.

PlunderBunny4 hours ago

My very limited understanding (speaking only as a professional software developer but not a game developer) is that there’s very rarely an abstraction that’s common across multiple libraries in the same domain, or that, in order to make an abstraction that could be adapted to different libraries, you would have to give up a significant amount of performance.

kristov2 hours ago

I'd say a big part of it (aside from the valid "framework" comments) is that game engines abstract over a large and complex mess related to graphics card APIs on different platforms. That abstraction is of the type that basically forces game engines to be frameworks, as opposed to libraries. If you want your game engine to run games on Mac, Linux, Windows, Android, iOS and the web, the game engine needs to "wrap" the game. Or at least this "wrapping" makes both game engine and the games simpler to write. But as mentioned, it means switching a game between game engines isn't really realistic - you write a unity game.

Dudester2306024 hours ago

Yes, it is possible, but you need to use a game framework not a game engine.

Example of a game framework:

Still, if you don't map everything all the time, common value types will propagate through the codebase.

orthoxerox52 minutes ago

Even if you code against MonoGame/XNA or a similar framework, migrating to another framework is not a trivial task unless you have written an abstraction layer beforehand, cf. Player.cs from Celeste.