https://nitter.net/OSSInsight/status/1703087927763542305
Which just links onwards to https://ossinsight.io/collections/game-engine with a screenshot: https://nitter.net/pic/orig/media%2FF6KVDQPb0AAi4Lj.jpg
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.
Missteps implies accidents. This was not accidental, it was an attempt at extracting rent - retroactively.
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 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.
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.
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.
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.
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.
Why would they even IPO if they are bleeding money as fast as they were? Was it one of those SPAC pyramid scams just to get fresh money from people?
"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.
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.
Milk dry, or try to start making money?
the missteps was thinking they could get away without so much trouble
How is it retroactively? Publishers are only charged for new installs from next year on.
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.
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 https://europa.eu/youreurope/business/dealing-with-customers...
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:
https://forum.unity.com/threads/unity-plan-pricing-and-packa...
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.
It isn't retroactive -- that would mean that they could charge you more for games you sold previously. I'm not sure I would call it retrospective either, as it doesn't change the conditions for existing licences, because you already agreed to their ability to change the price when you first agreed to the licence. Many people were unwise in agreeing to this contract.
You would be able to argue that their various statements over the years have applied constraints on what those changes could be, but I think it is clear they could increase the price. Changing the transition from $0 to non-$0 probably wouldn't stand in many jurisdictions, and they seem to already been walking that back.
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.
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)
Unless your licence says otherwise, each sale is newly licencing the Unity runtime.
The plus side from this will hopefully be people reading contracts more closely before basing their income stream on it.
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.
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.
Unreal is a viable option for most people. Epic is the devil we know.
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.
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.
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.
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.
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.
Blender seems like a good example of gaining traction + keeping honest.
Hopefully Godot follows in their footsteps more than those other ones.
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.
Why is heaps.io never in those lists? It’s not event in the wikipedia page.
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.
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.
This rather dampened by enthusiasm for Godot: https://sampruden.github.io/posts/godot-is-not-the-new-unity...
It's carrying a lot of performance baggage and there seems to be no sense of urgency in fixing it.
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.
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.
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.
It's something that is known and a work in progress: https://www.reddit.com/r/godot/comments/16lti15/comment/k169...
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.
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.
> 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).
> 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.
> 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.
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).
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.
Stars are not feature parity.
Who is saying that they are?
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
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
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#.
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.
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.
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.
I'm actually kinda excited to start learning some of these. How nice of Unity to force me out of my comfort zone!
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.
Godot seems to be the clear winner in all this.
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.
Thanks.
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 https://threadreaderapp.com/thread/1703163364229161236.html
Note: That is not the "normal" way to use a game engine.
Holy porting Batman.
Caves of Qud is definitely going on my watchlist now.
That is glorious. I would recommend that you post it as its own thread.
It was posted recently.
That's absolutely incredible. I agree this would make its own great post.
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").
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 :)
> 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: https://news.ycombinator.com/item?id=37548720
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:https://news.ycombinator.com/item?id=31588018
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!
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.
Ease of porting and platform support.
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.
>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.
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.
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++.)
More than port, I would call it conversion.
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.
> 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.
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.
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.
> 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.
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.
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.
Yes, it is possible, but you need to use a game framework not a game engine.
Example of a game framework: http://www.monogame.net.
Still, if you don't map everything all the time, common value types will propagate through the codebase.
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.
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.