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.
They need steady funding to have a team of capable full time devs. Their fund seems a step into this direction.
Unity is publicly traded: https://finance.yahoo.com/quote/U
Can’t blame private equity for this one.
> crunched the numbers and decided it's time to milk this one dry.
More realistically, they crunched the numbers and saw that they aren’t making enough money to keep the company going forever. It’s not a secret, because it’s a public company: They need to make more money to survive.
More monetization was inevitable. I know it’s unpopular public opinion, but Unity as it is today cannot exist forever on the monetization model they had in the past. The numbers didn’t add up. They had to change something.
According to their SEC fillings their staff almost tripled in just 4 years
> Dec 31, 2022 7,703
> Dec 31, 2021 5,245
> Dec 31, 2020 4,001
> Dec 31, 2019 2,715
Development of game engine is costly and take a lot of resources, but they already had a successful product back in 2019 and long before that. With all that hiring quality of their software was more or less constant (and not too high as always) which means all recent growth was not in their core business.
Sure people wouldn't have been happy with higher fees, but current clusterfuck is an order of magnitude worse.
This seems likely, but from what I've been hearing from game devs, the issue isn't the increased fees so much as the fact that they retroactively changed licensing. That they did this (again, after promising not to the last time) indicates that regardless of what the fees actually are, you'd be a fool to enter into a business relationship with them.
This behavior is not only destructive of their legacy, the promises they kept, but of course of their own reputation as a game company... I don't see any independent developer choosing Unity from now on (without a radical change for the company) in their right minds.
I'm pretty sure this wasn't the only solution to the situation. If they're going to ruin the company anyway... might as well make it open source. Start charging a large amount for a license. Cut the company size (maybe competition for other open source software is too great, and they couldn't survive at that size!). We have the choice to do the right thing, although many times that isn't the easy thing to do.
This goes even to society at large. No social or economic system can exist without ethics -- to believe so is delusional. Not communism, capitalism, social democracy, or something else(and I think we need some other ideas in the mix... but that's another story!) can function well when individuals don't have a good grasp of ethics. Governments are made of people making decisions, and companies likewise. No matter how much structure you impose on top, if people don't generally cooperate, a good outcome is impossible (garbage in, garbage out). So, like a friend says, "Be excellent to each other, or else..." :)
Unity’s value was previously in the hype and now is possibly in the voting rights by shareholders. With enough voting rights, I bet you could vote for a 0% commission for your video game company and offer to vote out the CEO/COO/ECT or anyone overpaid if they don’t concede to your demands.
Yup, it's Epic which is the private equity rollup. They're innocent, unless there are some Stephen Elop-style shenanigans going on.
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.
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.
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.
They are a public company at this point. Not a fan of PE but no need to blame them for everything.
Instead, look at their EPS. They have been negative since they IPO and never posted a profit.
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.
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.
This is the reason people were already fed up with it, this license change just pushed some over the top.
The trajectory of this project is not good at the moment and that is as much of a problem for users as the recent events.
I started a project 3 years ago and none of the features I based it on shipped with production quality in the meanwhile (and that was the assumption when going in back then, that this will eventually be fixed while development of the game was going on).
Godot is certainly not optimal, that is what people are discussing. The C# and expert userbase was missing. But the fact that people are raising these points meens that they see it worth to comment on. If Godot leadership takes the hint, they might bring their project to a trajectory which allows serious projects to give it a shot. So this time now will be critical. For both, Unity and their competitors.
I think none of the conversations and comments put out there are surprising. But I would argue that if people already had the motivation to switch, they might just go to Unreal if Godot gives them not enough performance. Or stay with Godot if their project is simple enough to be not effected.
If Unreal was ever an option, developers would've been using it instead of Unity in the first place.
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.
https://sampruden.github.io/posts/godot-is-not-the-new-unity...
Even if it’s clickbait or shallow content, it still raises the awareness of these tools.
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).
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.
However, you will run into limits that have nothing to do with AAA graphics, and most people are going to eventually want to expand beyond those limits. Clearly not everyone, because there are plenty of people who’d be happy making pico8 games till they day they die. But most people in my experience.
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.
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).
Python isn't really performant enough, or at least hasn't been in the past. Performance still matters, even for a scripting language.
In general, if your engine does what you want right out of the box with no modifications, you can go a long way to writing a game in the scripting language and - if you're not pushing it hard - not suffer any real performance issues. But as soon as you want to chase framerates, or do something unique or time-critical or computationally difficult, which is often, you 100% need that low-level language.
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.
Well the overhead doesen't really matter that much, who cares if you have to wait 10ms or 100ms etc. So yeah rewriting the Python bits is not worth it.
It's an entirely different use case though. In game dev you need fit your frame into 16ms or 32ms and you calling the methods hundreds or thousands of times every second etc. it all adds up.
C# is powerful and performant. I wouldn’t call it approachable though unless your background is Java or C++
It suffers from the same problem as Java: verbosity with endless choices for syntax. Why is this a problem? The “paradox of choice” is debilitating for most people. Also, since there’s no universal consensus over style, you’re going to inevitably have convention wars.
Python has many problems, but it’s easy to see how it became so popular with its one way to do one thing
Only if you choose to. Most developers use whatever convention they personally prefer when working on their own code. When you're working on other people's code, you use whatever convention was already in use. If you're working for someone else, you follow the convention of your employer. Simples. No fighting necessary.
It's carrying a lot of performance baggage and there seems to be no sense of urgency in fixing it.
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.
Personally, I found that signals were very slow for communicating node to node, was dropping information because it could take longer than a frame.
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
Modern C# also has more features that help avoid allocations, which in turns reduce GC pauses, which are the biggest enemy of a game
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.
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.
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.
The JVM isn't/wasn't the greatest to embed and it's kind of a lumbering beast even today.
Also you aren't embedding C#, but dotnet, with which you open yourself up to an entire ecosystem of languages (if you really want to write plugins in VB.NET or F# or IronPython), and a ecosystem of libraries and even Microsoft tooling that's way more polished than Oracle/Sun ever put out.
Unity uses C# for historical reasons - when Unity started, Mono was one of the few options that fit their needs. Outside Unity, C# mindshare isn't that big I think.
Java has been used a fair bit for Android games for obvious reasons, but game programmers are rarely Java fans.
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.
Hopefully Godot follows in their footsteps more than those other ones.
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.
...unless you are Brian Bucklew https://threadreaderapp.com/thread/1703163364229161236.html
Note: That is not the "normal" way to use a game engine.
Caves of Qud is definitely going on my watchlist now.
How is it today? I'm not sure what uses it and what doesn't any more. That's a good thing, i guess.
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 :)
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!
Way to tacitly admit the gamedev space is a fundamentally exploitive industrial vertical.
* 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").
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.
Then in order to move between one engine and another it is a far bigger task than just switching programming languages and frameworks (which in web development are very similar). You will need to do things like:
Re-import all of the external assets that you have created in external editors. Things like meshes, rigs, animations, textures, sounds, music, etc. These may require changes to adapt them to the new engine, and it assumes that you still have the original data for all of these (which is often binary and very large in size).
Then re-create all of the specific in-engine assets that you don't have external sources for. These are things that game designers often create and describe the elements in the game, like character, vehicle, item definitions, loot tables, experience curves, etc. In addition to these being engine specific they're also fairly manual to create.
This of course assumes that you can easily bring over the world/level data from one engine to the other. At best it will require sufficiently skilled programmers to write an exporter for the old engine and an importer for the new engine. At worst it will require designers and artists to recreate the levels by hand.
Then the last thing mentioned would be changing all of the automated processes to the new engine and educating everyone in the studio on how things are meant to work.
The web based analogy for all this would be rewriting the code in both a new language and framework, changing the frontend from HTML/CSS/JS to Latex (or something), moving the data in the database to another style of data storage, and converting all the images from PNG to JPG.
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.
Perhaps this was a mistake.
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.
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.
Game engines aside, this is a very late 90s/early 00s philosophy that has really not stood the test of time. The code that strictly follows this principle ends up looking like Enterprise FizzBuzz[0]. Trying to do this results usually in a lot of time spent building an abstraction layer around one thing, and that one thing not actually being replaceable because it was only ever built or tested with that one thing, so trying to replace Thing One with Thing Two is even more work as you now have to rip out both Thing One and adjust or remove the abstraction layer around it.
Abstractions aren't free, and the more complex the library you're trying to abstract, the more expensive they are.
There's nuances to this of course -- it's a lot easier to write a custom wrapper around a logging library than a DI framework, for example. But in general if you're using a third party library, things end up cleaner if you just commit to it rather than write an abstraction layer.
[0] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
The only things I have thought of, or seen others do, is to separate the game into a native library, or even a separate server process, that handles the game-world part of the game, and then use Godot as the front-end (client) gui only. But you will miss out on many of the engine's features since a lot of it is built around mixing on-screen objects with game-world objects. There isn't really any separation at all between what happens "in the game" and what is rendered to the screen.
But building the game from the ground up using Godot nodes, with a bit of GDScript here and there to tie things together, is definitely easy and very tempting to do. It pushes you towards that easy way of doing things.
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.
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.
Now we will make purposeful engines, eventually one genre will lead the way into what companies call metaverse.
VR might be too complex.
Only persistent multiplayer is interesting long term.
The licenses will have to be "source available" until eventually when money has dissappeared and copyright has been abolished; everyone can finally work on the same game.
I predict novelty games (Minecraft, Slay the Spire, Project Zomboid, etc.) made with Java will increase until X86 becomes too expensive to run.
Risc-V is the outlier.
harvard business school has ruined this country with their elitist graduates.
Game engines for modern AAA games are too big and complex to be just one person these days.
> Now innovation in game engines seems to be stalled, as big ones are just looking how to push more ads, instead of more polygons
This is just nonsense. Unreal 5 shipped with Nanite and Lumen for 'more polygons', and have been adding features to it over the last 3 releases. Unity shipped a bunch of features (I'm not as familiar with unity) related to raytracing in their most recent release.
Do you have to fight against the scene graph or whatever they use high level to do that?
The flat pricing model will disproportionately effect cheap mobile games, which I suspect was on purpose. Even then, I hardly see this as a problem. Just scrolling through the top games on any mobile store, most of it looks like low quality crap produced by large companies that figured out a successful formula for virile games. The only empathetic party I can figure in this mess is indie mobile game developers, which seems like a pretty small category of Unity users, certainly not commensurate to all the huff people are making.
This isn't the first time unity made drastic changes without warning. Sure, people are upset above the new pricing but they're really also very upset about the rug pull.
Sure many people love free stuff. However, 1) Unity isn't free 2) People understand that businesses need to make money. If Unity instead explained that they're losing money hand over first and need to change things up and here's a bunch of ideas I bet Unity could've landed a run-time fee without all this complaining.
Unity doesn’t provide any value for the marginal install that it is charging for.
A better comparison would be to Unreal which charges a royalty after $1M of revenue. Kind of sucks that it is percentage based but seems more sane to tie it to revenue than installs.
The install tracking will be borderline malware based on Ironsource's reputation. All they needed to do was take a cut of revenue.
Without that, people wouldn't be as mad.
Maybe. Although the per install stuff is beyond idiotic.
However, starting last week, no one can trust them to not change their minds at any time and retroactively.
The point was for unity to make money off hugely profitable free-to-play games (like falls guys, among us, genshin impact, and pokemon go). Unity is not aiming to make the quality of games go up.
I do recall Heaps initially not having a huge focus on beginner-friendly documentation (and lots of warnings about stability in general). I'm not sure if this is still the case. Other than Nicolas, there aren't many other devs working on it that I've seen.
Some of them, yeah!
Godot has almost doubled how much money it gets from the community: https://fund.godotengine.org/ (though that sum should probably be much, much higher)
Here's their stats from a week ago: https://web.archive.org/web/20230912192257/https://fund.godo...
Sadly, those figures are for perhaps the most popular open source engine that's friendly to indie developers, which means that other engine developers really can't count on much funding at all being there. Reminds me of: https://staltz.com/software-below-the-poverty-line.html
