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.
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.
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.
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).
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
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.
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.
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
