I've been diving into the engine development scene this week. Lots of cool activity going on.
There is a PR shaping up to produce "libgodot"; Godot as a shared lib for embedding in other code. Users reporting use cases and what they are currently doing with that:
* embedding in .net to flip that script
* embedding in Blender so assets can be viewed in engine and a tighter integration created
* VR applications
* Miguel de Icaza's(yes that one!) SwiftGodotKit
* Image export, a UI system, 3d viewport, asset conversion automation, etc.
Looks like it lost a little momentum in the past few weeks but it's working for people and there is a path forward to getting accepted by maintainers. It's also on the DotNet contributors meeting agenda for tomorrow..
I don't know about C# but I do know Java can use C code through the Java Native Interface. I wouldn't be surprised if .NET and Mono have something similar.
Oooh I wonder if this libgodot would also allow me to work with Kotlin/Native. I've tried getting into Godot, but C# felt a bit... dated compared to Kotlin.
I imagine so. Should also be possible to generate bindings from the ClassDb json in a similar way to how it's done in C#. I'm not super familiar with it but it's all moving to the GDExtension stuff.
In a few places. Author has communicated with the devs and they seem receptive to addressing the issues with the usual caveats that it doesn't break anything.
They also donate 1000 USD each month to each project moving forward.
I still wonder how the discussions at Unity went, thinking that a per-install fee for already released games would be a great idea. Sounds like the result of a compromise.
These are the kind of decisions that I (almost) can’t imagine happening at a private company. When the developer of a product you use goes public, you can expect with absolute certainty that it will become measurably worse over time. It might not happen quickly, but it will happen.
It's rarer though. These MBA beancounter types get attracted to public companies like flies to a pile of bull dung because it's far easier to get compensation tied to stock prices/valuation there, and it's easy to direct a stock's price upward (headcount reduction is the most common thing that will send it upwards).
Exactly. I agree. I also find it surprising when people talk negatively about certain companies or capitalism in general, but then continue to spend a lot on various products including the companies they criticize. Companies are not making money up (apart from some fraud cases like Enron).
In the '90s, a friend of mine was in the pharma industry. During a training session, the question came up: "Is it possible to market a useless drug as a panacea?" The straightforward answer, according to the trainer, was "Yes—if the projected profits surpass the potential liability costs." All of the outcry was likely anticipated when they made that decision.
The "percentage of global revenue for the whole parent corporation" was the genius bit in GDPR.
Otherwise Facebook could've just founded Privacy Violation Inc and done all the bad shit there. There's just one employee, Frank, and he's paid minimum wage.
Now if, for example, Youtube fucks up the GDPR fines are calculated on the global annual revenue of all of Alphabet Inc.
I can't fathom the logic. Why not do a slice of revenue like Unreal does, and calibrate the percentage so you make the same amount of money as you would have otherwise made had you done it per-install? Happier customers and identical revenue.
Their USP was that they had no revenue share. Somehow they thought that the current retroactive per-install model would go over better than reneging on that promise.
But how little can you know about your own product and your customers, by suddenly treating an AAA game that is sold for a fixed big price, where a fee per install might make sense or is affordable, the same as all those little games, where many are free to play (add financed, or as a free demo with full version unlockable)?
I mean, how can you not see that? Or was the thinking, screw that market, we are only catering for AAA games now? Even then it makes little sense as the revenue share like Unreal does, would make more money.
It likeley was something along the lines of: "they need us, they will have to find a way to pay us, if they want to continue existing."
Not AAA games - the real target here is mobile games. Those far exceed any profits the AAA industry generates.
Indies are a necessary casualty in the eyes of Unity (or more accurately: they're just not considered).
Unity is the engine behind some of the most popular mobile gacha games. MiHoYo (Genshin/Honkai Impact) uses it for everything, so does Type/Moon (Fate Grand Order). They want a slice of that pie. That's where the real money is. Those games rake in hundreds of millions of dollars every month.
Hence also why the charge is by install and can be waived if you use Unity's adtech offerings.
I worked as a community manager for a free-to-play mobile gaming company in the US about 10+ years ago.
The gacha mechanic just absolutely ruined games for normal, everyday users. You had random moms and grandmas write in with the sweetest messages asking for features or reporting a bug.
For the most part, their feedback and requests went right into the garbage can.
Meanwhile, we had people from Qatar, Saudi Arabia, and Singapore spending $40K USD per week on in app purchases.
Gacha is effectively gambling and exploiting users' propensities for addictive behavior. We would jokingly call it the "Gotch Ya!" mechanic.
Feature roadmaps, bug fixes and A/B tests were all about "optimizing the funnel" -- i.e., how do we get these whales to spend more money or more parts of the app.
For most indies prices shouldn’t really go up that much and for some others this is actually a discount (the 200k limit is now per game and not company and you already had to upgrade to pro after that).
For 90-95% if not more of their users the financial aspect is not such a big deal. The way they announced it and planning to implement (retroactively and how do they even track “installs”) is a way bigger issue.
China (and some other countries). They won’t declare their full revenue and you won’t be able to find it out, it’s expensive to admin and there is hardly any legal recourse anyway.
Also their biggest clients would probably hate rev. share even more than this.
Nearly all worthless trash games on steam, those that need more resources than anything else, those where you easily get stuck, those with generally no gameplay. Shine a very bad light at unity.
A unity splash screen is and always was a sign that the game might won't work on my setup.
Maybe this will drive away all these shitty games. That's definitely mostly just good for the brand, but IMO kinda necessary as the brand stands for shitty games for some.
the ability to make "worthless trash games" is the only reason that the indie industry can exist at all. there are huge communities around sharing small lower-effort projects (which countless well-received games started out as) and gatekeeping an engine to enterprise customers only would be a far far worse decision than what they've already done
besides, the rates only kick in after your profit reaches 200k so it wouldn't do anything
I think it's great to see increased support for open source engines.
Those engines might not be at the same technical level as Unity (yet), which shouldn't be a surprise given the way lower budget and man-power behind them. But they are getting better - and they do have some massive advantages over proprietary engines. One example for such an advantage would be that you can just fork the code, if they do something you don't like. They can't hold your game hostage to force changes on you.
IMO this is not the technical level that matter, it's the UX, if we leave aside the super duper AAA games, which would use Unreal, then it's about putting a whole lot of different assets together, and hold them with code glue. Unity has some nice things that are not there yet in godot (from the top of my mind: better font support, in term of UX once again), and C# is way better than thw half-assed language that is Godotscript.
That being said I'm pretty sure that Godot is about to close this gap before 2025, given the recent boost in popularity.
Yes it's the second of the two first-class scripting language options.
My initial impressions are pretty positive. They moved to .Net 6 from mono with Godot 4. Support for deployment to Android with c# is coming in 4.2. There also seems to be interest and discussions around how AOT can be used in the future.
The engine is super easy to build and I think I actually built it with .Net 7 haha. Others are already using .Net 8.
It is an excellent language, and a joy to develop in. Works on linux, linq to objects is nice, it has good reflection and decent pattern matching and good ide support. But the library ecosystem is terrible. Imagine starting out web development by looking for alternatives to Entity framework and asp.net core or whatever they have now. ML is sparse, financial libraries are sparse, dataframes, vectorized arithmetic, very hard to find something that works in all .net versions.
I gave it a try for a while - I really like the syntax and some of its capability. But somehow my head was just spinning. I can't explain it, it was horrible to use. The moment I switched back to C++, Python and similar, I felt relief. I genuinely gave C# a chance but it just didn't work. There's nothing specific, it has all the "right" things, but it forces you to work in a way that's just so unusual. I never experienced this with another language. It feels like a language that's intentionally aimed at bloating headcount in development teams where everyone works on that "little" thing that somehow becomes a project in itself.
C# has certainly accumulated a lot of history. From being OOP heavy, Windows centric, closed-source, with mostly enterprisey frameworks/libs to more multi-paradigm, cross-plaform, open-source, with iteratively more sane frameworks/libs. A lot has changed (and is still changing).
Modern C# is getting more streamlined, but there are limitations to this due to backwards compatibility, and old boilerplate-heavy syntax is still supported, which leads to having multiple ways of doing the same thing.
While I really like the direction the language is taking now, the official documentation of the new stuff is often sparse or scattered all over the place and a lot of answers on Stack Overflow are dated. Diving into an ecosystem like that, which is in a middle of a big transition, can certainty be overwhelming.
The only tip I can provide is that if you ever try it again, try it in combination with a good IDE like Rider. C# is designed to be used in combination with an IDE. Rider can automate lots of things and analyzers can offer helpful guidance.
Why do I feel like those useful changes in the forks will never make it upstream? It's not GPL I suppose? I guess I just don't really understand how people can be ok with companies like EA freeloading their work, which they almost certainly will if they can.
Most open source projects have realized that GPL has unfortunate parallels with a foot gun.
Forcing people to contribute sounds like a great idea, until nobody wants to be forced and everybody prefers the other project that doesn't force them, and then they all go ahead and contribute to that other project anyway because they want to, not because they were forced to (in large part because the practical benefits of getting your changes into the upstream vastly outstrip any theoretical "my code is better" fantasies).
Faster adoption of non-GPL projects leads to faster growth of those projects in the form of more contributions as well. Other than a group of mostly quite old GPL projects the momentum and activity and success is clearly with more MIT-like licenses than GPL-like licenses, again in large part because the benefits to you of getting your patches into the upstream proves to be a powerful motivator that is not also a demotivator the way the threat of being forced to contribute is.
Yes, one can point out a newish successful GPL project here or there and a couple of pro-GPL ecosystems but the vast majority of recently successful project starters are using MIT-ish licenses for good reasons.
you do realize the GPL is completely incompatible with games right?
if a developer sells a game they must then provide the code to build the game, then the person can distribute that code to everyone else, bypassing the need to pay for a game.
It literally makes the need for cracking unnecessary, which I agree with, but I'm not going to pretend like any game company is going to release their source code in the year 2023... intentionally
Is GPL practical for a game engine ? Doesn't it mean that all code produced with this engine would be also open source ? Seems pretty much like a no-go, and nobody would use the engine. Please correct me if I didn't understand it right.
Honestly, credit where credit is due. These are substantial donations that will hopefully be put to good use. On top of recurring 1k per project per month.
The Godot project recently launched their own foundation to avoid Patreon fees and VAT while putting a larger percentage of donations directly to work. I just moved my monthly contribution to the foundation yesterday. This is great news to complement that!
FNA is a reimplementation of the old Microsoft XNA framework. I think the appeal of FNA is mostly to keep old games alive, rather than as a platform for new ones, so it feels a bit strange to see it get as much funding as Godot here. Terraria itself is developed in XNA (and presumably uses FNA now) though, so it could be pure self-interest (which isn't a bad thing).
Yes, it would be odd for Terraria to fund solely something they don't use even if it's more relevant for replacing Unity.
I was actually involved in an engineering software package that used XNA. It was resurrected a few years ago after close to a decade on ice. We were sure glad that FNA existed because Microsoft had dropped XNA like a hot potato. Yeah, I wouldn't trust them again either.
It functioned (barely, but still functioned), had a lot of support, and had a lot of answers around the inevitable jank. For a game engine, these put it above 90% of other engines.
Having console support alone puts it in the top 1%.
Dragon Ruby, Haxe (Heaps, OpenFL, ...), Game Maker and I am sure thousands of other smaller engines most never heard of have native console support. The first 2 examples even without huge extra costs.
that's a lot narrower than you think, I wouldn't even put it in the dozens. Maybe a few dozen if we include all the in-house proprietary engines. Being easy to port to console =/= native console support.
But yes, a few dozen out of hundreds of engines is the 99th percentile.
Unfortunately, Unity tends to break things often, so many of these tutorials are obsolete. But yes, it's a lot of tutorials and it's always possible to find the one you need.
For most indie games I feel like three.js + css + JavaScript would be so much better for both developer and user (no steam install just go to a website)
Meaning, those graphic API are able to deliver at least PS 3 graphics, yet due to browser support, specially the way browsers blacklist drivers, download sizes, and lack of tooling on par with native, very few professional developers bother, hence streaming.
I am talking about things like puzzle games, board games, etc. There was one digital board game I used to play with my friends, it was such a simple game I probably could have built it in 2 days in JavaScript, but they developed it in unity…one ~60 minute game would heat up my laptop like I had put it in the microwave and completely drain the battery from 100%. For a board game with no fancy graphics. My friends all had the same problem. If someone were traveling, we couldn’t play because that person wouldn’t want to drain their whole battery for it. I have no idea if that was specific to the developer of that one game but my friend who plays a lot more games than I do said it’s just the unity engine doing that.
It is a ton easier to make a game in unity than in these (having done both multiple times). And a lot easier to get artists and designers to work inside unity than with three.js.
It is such a better developer experience. My unfinished Three.js game[0] was on Unity a few years ago, but that became unbearable. The modern web platform is too new, it hasn't proven itself to big money, so it's going to be indie games first.
To answer sibling comments: Graphics aren't a limiting factor for indie games. And a Three.js game can be put onto Steam, I'm pretty sure.
Unity has always been an excellent engine in its ideation. Easy to understand, easy to get started with, truly a great onboarding experience. Additionally the ability to use C# can't be understated as, IMO, it's a fantastic match for game scripting... until you start to hit performance problems.
Which has kind of always been the problem with Unity. Once you start getting into the meat of it there's always some issue. Most recently their obsession with DOTS and the fragmented rendering pipelines were really off-putting and enough to get me to switch to Unreal. I also found a lot of the features barebones for a very long time, like 2D tilesets, landscape editing tools, nav mesh, animation tooling, etc. None of this matters to companies with actual teams, but for indie development I've found Unreal to be a much better match for me than Unity.
That being said Unity has come a very long way in the recent years and the engine can be a joy to work with (as long as it's not crashing and misbehaving, which it does). But that's history at this point. There is no way I'll ever attempt to create a game in Unity again.
It's daunting with how many tools it gives you but it doesn't force very much onto you and gives you a ton of flexibility.
I'm as happy as as everyone else about this momentum away from Unity since their business leaders clearly hate developers, but I really like the Unity game engine. From a software design standpoint, I didn't understand how powerful composition can be (versus inheritance) until I started working with Unity GameObjects.
> I found unity to be so unbelievably bloated and confusing that I am seriously shocked people are actually using it
Bloated compared to what other game engine that does the equivalent exactly? Some of the biggest games today are made with Unity, for instance, Genshin Impact.
Unity isn't bloated, quite the contrary. It's fairly modular for a game engine and authoring tool.
Yeah, my thoughts too. It took 5 minutes to fully load, and then just moving around a scene with more than 2 objects felt very clunky. I uninstalled it and never thought to use it again. This was maybe 10 years ago, so i assumed it had improved since then...?
....What other big games engines have you used? I've used unreal as well as some proprietary ones(Anvil and Snowdrop) and they all take more than 5 minutes to load, in case of Snowdrop it could easily be 20+ minutes if you were loading in with the game world present.
Unity is famously capable of running on nearly anything. Until recently I used to take my 2013 Macbook Air out with me so I could do some work without lugging a gaming PC. It's always felt pretty lightweight to me. The exception is creating a new project where it has to download or import a lot of packages (especially if you're using URP or HDRP)
But loading an existing project with a valid Library folder and working interactively in the editor should feel pretty snappy.
It’s enabled thousands of indie devs and small studios to release games every year for the last decade. I think that’s pretty awesome. Unity, the game engine, has undoubtedly been a net positive, and now that torch is being passed onto others.
The company management just totally sullied all that goodwill in a week however.
if any of you folks want to support Terraria, they have versions available on Android Play Store and ios App Store (published by 505 Games) - https://terraria.org/
Bevy is almost the spiritual opposite of Unity in terms of its design goals.
Hopefully it gets some more funding and attention, but if you enjoyed Unity and are looking for a replacement then Bevy just isn’t it - it would be like swapping Microsoft Word for a html editor.
There is a PR shaping up to produce "libgodot"; Godot as a shared lib for embedding in other code. Users reporting use cases and what they are currently doing with that:
* embedding in .net to flip that script
* embedding in Blender so assets can be viewed in engine and a tighter integration created
* VR applications
* Miguel de Icaza's(yes that one!) SwiftGodotKit
* Image export, a UI system, 3d viewport, asset conversion automation, etc.
Really cool stuff!