I feel like, realistically, for a lot of the people that feel might be affected by this change they could probably do their games in an engine like Godot without much trouble.
Though as it says in the article, Godot does lack proper support for consoles.
interesting, but I can't imagine someone battle-testing a proper unity scene porter that would be faster than simply re-importing your assets (easy?), re-writing game scripts (easy-ish, since Godot has c# support. but annoying and time consuming), and re-doing your shaders/materials (basically a complete re-write, unfortunately).
Assuming C# support is rolled out to all platforms soon, its still a massive undertaking to port over scripts from Unity's lifecycle and libraries to Godots. I assume shaders are actually much much easier to port in an automated way. But also many assets are custom to Unity, like their animation system.
Yeah, anyone who hasn’t had to rewrite and/or port will think it’s easy. Not knowing Unity has its own lifecycle for scripts and has its own APIs for doing things the “Unity” way. Want to create an instance of something? No, it’s not just new Thing()…
I say "easy" in a relative sense, since we're talking about leveraging the use of automation here (and we know how that ends: https://xkcd.com/1319/). And I'm assuming you have a decent engineer assisting in moving the scripts. they can learn the differences in the game loop and port over a lot of the high level scripts with a bit of thought. But not in a way that is easily automated.
And to be honest, I don't know how easy asset migration is (hence the question mark). it's a surprising pain point when moving from Unity to Unreal even if you keep everything as the industry standard FBX. I don't know if it "just works" in Godot or can be its own undertaking. Histoically it does mess up a lot of texturing and animations, even if you manage to get the base model in intact.
Yeah, even a seasoned engineer would take as long. The issue with porting C# code from Unity to <engine> is the different ABI. It’s like trying to port Win32 C++ code to MacOS with the minimal cocoa obj-c required. In the end, they are two completely separate ABIs that have to be targeted. There is no such MonoBehavior API in Godot. They have different lifecycle management APIs, so creating, destroying, and triggering code has different signatures and different calling conventions. You simply can’t transpile code from one engine to another simply because you’re using the same language.
> Though as it says in the article, Godot does lack proper support for consoles.
None of the open source engines do, or ever will as publishing to consoles requires that you sign an NDA. If you're a godot dev and want to publish on console look towards https://lonewolftechnology.com/
There are commercial companies offering Godot-based games a path to consoles, so it isn't technical at all. It is entirely a matter of licensing with the console makers not wanting to allow open source support. But they don't mind 3rd parties developing proprietary extensions to support consoles and following their licensing restrictions.
mostly Political. Console dev kits from the Big Three are all under NDA, and you need to apply to get them. So we're talking about access to closed sourced code with use in an open source engine.
Godot created W4 Games to get around this. So while Godot is open source, W4 can work on a fork that implements console-specific code that cannot exist on an open source repo.
Didn't find this article especially helpful. Author admits to having no special knowledge so literally polls Twitter and shares the results. Doesn't really add much to the discussion.
I'd really like to see how alternatives handle stuff such as:
- Editor tools for non-artists
- Editor API for customization/automation
- Profiling CPU/memory
- Integration with things like FMOD, Spine, whatever else
- Tools for debugging
- How does level editing work, what tools are present to assist with visualization, organization, construction
Casey is a seasoned dev in the scene, with a decent resume of games and an even more impressive resume on knowledge in engine tech. Most notably, he's working on a new programming language called Jai that is tailored for game development.
So he may not be the most appropriate person to ask for game engine advice (since he says in the article, he makes and rolls a lot of his own tech), but he will inevitably be asked for his thoughts and advice on the situation regardless.
Yes, you are correct, I was mixing engine programmers that both worked on "The Witness". Casey is known (among many other tools and research) for Handmade Hero[0], an engine he uses to teach very low level game programming concepts. Which he is using to release a full game with (and you can "pre-order" the game on the website which gives you access to the source code)
I'm not really into this industry, but I've dabbled with Unity over the last month for some fun/expanding knowledge...
I've seen 2 articles in the last day about this topic with clickbait misinformation from sites I would expect to be more accurate... Including talking about how a "free game" was going to cost a developer millions... and how "independent developers" will be bankrupt...
But how? The fee page and FAQ [1] state "will apply to games made with Unity Personal and Unity Plus that have made $200,000 USD or more in the last 12 months".. If you are distributing a free game, by definition, you made no revenue for the game and you pay nothing to Unity. Key point: the metric is PER game... so it's not like your $5 game with 200k revenue and 200k installs will trigger your separate FREE game to cost 5 million in damages.
If you are an "independent" developer, or even a team of 5, then the $2k/seat-year Pro license means the threshold is now $1million... pay 2-10k/year upfront to pocket an extra 800k? These seem like a no-brainer...
Now, I can see this being an issue for studios that invested heavily in Unity with dozens or hundreds of developers.. and I appreciate discussion on this topic... I'd love to see more realistic reactions and discussions... and less "abandon ship" (like this article) and I-didn't-read-the-memo knee-jerk reaction stories for attention out there right now.
(And I know some of the early concern was download-bombing, but they have addressed that, and most of the articles I read didn't cover that explicitly)
"Free" games don't really exist any more on the mainstream platforms. "Ad supported" games though... and guess what? Unity is an ad company, not a tech company, at heart.
I'm not sure that's true, their Ads business(es) is made up of other companies which they acquired over the years and is/was somewhat isolated from the engine/tech part of the company.
I think the concern is that Unity is failing. Charging royalties is not going to save them, and is going to drive more devs away from the platform (as this article shows), so they are going to have to do more drastic things to raise revenue, which will drive more devs away, and so on into the familiar death-spiral. If they can't cut costs enough to get profitable (and history shows this is very difficult) then they're doomed to go through a series of increasingly more disastrous acquisitions (see Yahoo for details).
Given this, then the details of this particular royalty structure don't matter. Yes, a freebie game may not have to pay any royalties now. But as Unity enters the death-spiral that will probably change. Or there will be mandatory malware shipped with the engine. Or some other craptastic revenue-generating idea will mess with the game. We can expect relatively frequent, drastic changes to Unity's licensing as it tries to escape its fate.
Plenty of games are free to play, but come with micro-transactions and/or ad revenue. If anyone can pick up your game and play without spending money, it is generally accepted to be a free-to-play game.
Part of the change (unless it has since been walked back) was getting rid of Unity Plus licensing, leaving just Unity Personal and Unity Pro.
Also assuming the per-game stipulation was not something Unity made clear after out-cry (like the multi-installs on the same PC or game-update), they have previously gone to great lengths to prevent studios from spinning up a new company per game. It is reasonable to assume that there is nothing stopping them from later tightening the noose and applying this fee on a company basis instead of a game basis.
> And I know some of the early concern was download-bombing, but they have addressed that, and most of the articles I read didn't cover that explicitly
Given that history I would not put much trust in one vague answer in FAQ without at least consulting lawyer first (including asking how much it would cost to defend if Unity lawyers disagree with your lawyer's take).
And even in the current FAQ answer it's essentially fully up to them to determine what is fraudulent installation or if the install was part of install bombing.
I agree with all those points... It certainly concerns me as a new-to-unity developer... but most articles (like this one) are not talking about fraudulent installs.. they jump to "we're bankrupt" and "abandon ship" without much details, context, or supporting statements... and that's what bothers me...
I'd love to hear WHY.. not knee-jerk reactions...
Someone else mentioned that some people use "Free" to also mean ad-supported or micro-transaction... That wouldn't be my definition, but I suppose that is a fair concern at-a-glance for an article that says a "free" game can bankrupt them... That's a lot better than most of the comments I've seen on this topic.
If you have a free game with upsells or paid DLC - not an uncommon model now as a way to get people in the door - the new pricing model is toxic because every user in the door costs you money. If before you were okay with only 5% of your players giving you money, that's not okay anymore - now you have to aggressively upsell, shove ads in there, do ANYTHING you can to get average revenue per user to far above 20 cents so you can afford to pay the Unity Tax in addition to the other taxes you already have to pay (Valve/Apple/Google's 30%, your actual taxes, etc.)
With the model I described you could easily bring in 200k worth of revenue off DLC but then owe a significant % of that in install fees if you're only managing to sell DLC to say 10% of your players.
Unreal-style revshare where you just give them a small % is super reasonable in comparison. It just works and you decide whether the percentage is acceptable.
> Unreal-style revshare where you just give them a small % is super reasonable in comparison
The per install fee is still going to be significantly lower for everyone making > $2 per user than what Unreal charges. And I assume Unity's best paying customers are doing that. A rev share model would have been much more likely to scare them off. It almost feels that killing the low revenue per user F2P developer user-base might have been a conscious calculated choice (I'm probably giving too much credit to their upper management though).
So the royalties are going to be negligible for large succesfull projects, while potentially an unbreakable barrier for small projects (ie growing free installs first and monetizing later is not viable). This is going to harm their ecosystem, from which the large succesfull projects grow. Why dont they use same principle license as Unreal?
> Why dont they use same principle license as Unreal?
Their largest customers will probably push back against that more than the install fees.
You're losing most of you revenue from China (and some other countries). Companies there will cheat and underreport their revenue (Unity historically had issues even having them to pay for licenses, studios would just buy 1 license per 10-20 developers etc.)
It's interesting that Source doesn't get a mention here, when it used to be a rather popular engine. Given unreal is second, it's clearly not an objection to closed source engines
I follow indie games news and I don't remember seeing any recent indie release using Source. My guess is that it's no longer as popular as it used to be.
Actually Source was never a popular engine among developers. If you exclude valve we’re talking dozens maybe? And when 250+ games are released on every week on Steam it’s a very rarely used engine
The only time period I can even think of that _might, maybe_ qualify would be the Source mod era, but that came and went over a decade ago. And of course they were free mods, not standalone games with purchases or licenses.
Some of these mods turned into games later (Chivalry, Black Mesa, Insurgency come to mind) but without investigating I'm not sure they even use Source anymore.
This blog post points out something really interesting:
> Less than half their revenue comes from game engines. Over half comes from advertising.
That is to say, Unity makes most of its money from people PLAYING games made with Unity. The sales to the developers are secondary. Unity had to change their model, and that meant either making the engine cheaper to acquire more games to get more ads, or it meant raising the price of the engine at the likely cost of ads, and for some reason they chose option 2, which seems like a dumb idea.
The best explanation for that I can think of is that almost all of the advertising money should be coming from smaller mobile games, and so this is a move to try and make more money from the desktop games and the mobile games that don't use Unity's ad networks, which probably look like big, untapped sources of income to dumber product managers.
But now imagine that they did the opposite: they raise the maximum revenue requirements and "must show splash screen" requirements and generally make Unity more available for less. Engine revenue goes down a bit, but ad revenue goes up, which probably works out even better in the long run, but also solidifies the user base, garners good will, and generally leaves everybody feeling great about Unity.
I don't think there's anyone not using unity today that would use it tomorrow because of a pricing change (well, at least, for values of today and tomorrow from last week)
And we are switching to Unreal. The price is not why we were using Unity in the first place. I don't like Blueprints and I don't like C++. Verse looks like it's going to be super weird.
Unity is more versatile, smaller, easier to use. Faster to iterate.
I've worked with both engines for many years, on the Bioshock games in Unreal and Void Bastards in Unity.
But Unity has shown time and time again that they have no respect for us, so we really can't continue to do business with them.
If I use Unreal, if my game generates 2M$ revenue, I know exactly what I'll need to pay Epic. With Unity's model it's a coin toss. Are lots of people going to reinstall my games ? Am I going to get install bombed ? I have no idea.
Kingdom Hearts 3, Hellblade, Gears, FF7R, Borderlands, Sea of Thieves, Fallen Order, and countless others all use Unreal, in all likelihood made over a million dollars, and many made sequels using Unreal as well. Its also absolutely necessary to clarify that Unreal's revenue share is 5% over $1M, not 15% (and, weirdly; its 5% over $5M for games distributed on the Oculus Store, believe it or not).
a big jump but not unheard of. remember that the biggest store platforms take 30% already; Apple, Google, Sony, Valve, Microft, and Nintendo. In a vacuum it's not unthinkable to suggest that the engine you make your game on and leverage many features for (networking, porting, collaboration, etc) is at least half as valuable as the store you're hosting the game on.
Personally I think it's the store takeaways that are way too high. And in some cases overstep their boundaries in what they allow an app to do or how to sell it. But that's a big tangent.
It's not at the expense of advertisers, the advertising is staying the same. It's only at the expense of the advertiser in the sense that Unity is the advertiser and they've shot themselves in the foot.
Just because Unity’s revenue from ads is greater than from the engine doesn’t mean they need to change their model. It’s ok for one part of their business to make more, especially when the engine is still making lots of money too.
Inconvenient opinion in the adware-fueled tech world, but ad income isn't a stable or safe source of income, and it's likely they're feeling that, and therefore jacking up the price for the engine. The big tech companies themselves feel it and spend a lot of money on "Other Bets".
Noob consumers may click ads, but after a while they program their brain to filter them out automatically. Or occasionally filter them out using technological measures. I bet that most ad clicks are by mistake or similar (especially ads in Unity games (which AFAIK are interstitial video ads)), or the user wasn't realizing what they were clicking on was an ad (noob users, or e.g. ads at the top of Google results, which used to be much easier to distinguish from actual results).
Most of my ad clicks are by mistake (due to bad page layout, or there just happened to be an ad where I happened to click), some (a handful of times per year at best) are to satisfy curiosity. And maybe a single one in my lifetime actually led to a purchase.
Google ads started out text-only, now they're pretty jarring on average. Guess why. However, there's a limit to how jarring you can make ads before consumers say bye-bye. Unity ads are probably way over the limit, Google are sort of tip-toeing along the line (or let's say they're over the line for a minority, and not quite for the rest).
> Noob consumers may click ads, but after a while they program their brain to filter them out automatically.
Ads are not just about clicks. Half of all spending is brand advertising.
Noobs don’t click random SMB ads, and yet that’s like 40% of spending on mobile.
There are people who are “superclickers” and also super buyers. They’re just a really expensive audience to target, obviously.
Anyway, you’re extrapolating from your sole experience with ads. It is a super big ecosystem with a lot of rationality, as ridiculous as that sounds. It is growing a lot still, digital ad spending grows like $130b a year around now, which is the highest it’s ever been. So I don’t know, you’re not saying stuff that is substantiated in truth.
>Inconvenient opinion in the adware-fueled tech world, but ad income isn't a stable or safe source of income, and it's likely they're feeling that, and therefore jacking up the price for the engine
You're right, but to expand: Apple's privacy changes at the beginning of 2022 screwed over a lot of adtech, and now the rise of AI is making ad providers even more speculative of certain types of content. I think Adtech is recovering now but for a company like Unity who relies on ads, it dealt them a huge blow for the last 18 months. That's probably what promtpted the merger/aquisition and started its plans into how it can extract more from its devs.
The ad market is more competitive and very crowded there is no reason to use Unity for your ads if someone else offers a better deal.
Also Unity did try focusing on increasing ad revenue over the last several years, it didn’t work out that well.
> leaves everybody feeling great about Unity.
Making their engine entirely free would make most people feel even better.
> untapped sources of income to dumber product managers.
Why? Most Unity’s client’s don’t make much if anything at all a few make massive amounts. Due to the fixed licensing model the latter barely pay anything to Unity (e.g. compared to how much they pay storefronts/platform owners/ad networks). If they want to continue growing their revenue Unity has to get more from these customers, there aren’t that many other options.
I feel like any piece of software that's widely applicable to a whole industry of users (3d modelling, image editing, game engines, etc) is destined to eventually solidify on an fully production quality open source solution that everyone contributes to.
It's already happened for 3d modelling (Blender) and digital painting (Krita), and it feels like gamedev is an even better market for this to happen in than those because all the users are also going to be capable of contributing to development of the engine.
From the outside Godot looks like it's the closest to ready for building proper AAA quality 3d games.
I've also actually used Bevy and if you're a fan of rust and ECS based development it's really nice for building procedurally generated stuff that doesn't need a level editor, or for building 2d games and relying on a 3rd party editor like Tiled or LDtk. However there's plenty of places where it's still a bit rough around the edges, like dealing with more complex multi stage asset loading pipelines.
Yeah I'm not saying Godot looks AAA ready, just that it's much closer than every other option.
Although I would love to see how far a code only engine core + separate third party level editor tooling model could go, it appeals to my intuitive feel of what the "right" way to build software is.
I have casually evaluated Godot so I am moderately aware of its capabilities. The thing I did not evaluate well though is how well structured its data and asset pipelines are. The big thing a AAA engine needs (aside from rendering, console support, and perf and all that) is the ability to scale production to hundreds or thousands of programmers and artists. The ability of an engine to scale in this way is generally learned painfully by doing, and I'm looking forward to see how Godot fares on larger scale projects over time.
There's hardly any AAA titles that use Unity, the most well known ones are games like Hearthstone, Cuphead, Beat Saber. These are great games but they're not exactly GTA 6 or Call if Duty.
Yeah it's a historical difference, and Unity literally kicked out its best chance to compete in that space with DOTS.
But on mobile it is king, and mobile is starting to get games that can rival AAA studios in presentation. Genshin Impact and the rest of Hoyoverse's games are all in Unity, and while not confirmed I wouldn't be surprised if Project Mugen is also running Unity (given that most of NetEase's portfolio relies on it). So it has the capability to handle AAA games, even if no one in the west is utilizing it.
As someone in the industry, those games don't actually fit my traditional mental model of what "AAA" means. AAA doesn't directly correlate with revenue for example. The general rule of thumb I kind of go by is that a game is likely to be "AAA" if it uses motion captured skeletal and facial animation sequences.
I don't think it's true, Blender happened to work and is now used by professionals, but some tools like PhotoShop or Adobe Premiere, Ableton, or even Word/Excel for that matter, don't have an equivalent that could replace them anytime soon.
The 3D modelling industry is bifurcated. The "low-end" of town (like hobbyists or indie studios) uses blender, and the high-end of town (like the sfx shops that do hollywood movies) uses things like maya.
In games Blender is used at all levels. From indie to AAA. At most studios as a 3d artist you are able to use any package you want and for newer artists Blender is increasingly what they know. Sometimes there are custom toolchains that require Max or Maya but often then artist still use Blender for most of the work, export fbx and import that into another soft just for final steps.
I'm now at AA level studio and for this category Blender is eating competition super fast!
fair enough. Blender's penetration in game development has been very high in the past decade. There's even a nice game engine called Armory3D which is in fact a blender "plugin" (it's quite a good engine i hear - never really used it properly in anger to know fore sure tho).
Photoshop is an interesting one. I used to be a power user for years, but have since mostly moved to Krita. For a "I don't know what I want or need" type of manipulating images, Photoshop is great. For painting, it's not even close to being the best (I agree with the parent comment that Krita is much better).
The reason it's so popular is because there wasn't anything else for a long time, and also probably because it's still lobbied to unis.
Windows has Linux and Photoshop has Krita. the open source equivalents aren't neck and neck competitors, but they grew to a point of influence where you can't ignore them. They have sizeable communites, and various professional usage.
Office is the rough one, though. There's LibreOffice, but it never seemed to improve on its UX. and in the meantime Google docs came and became the big competitor.
Games development is very hit based and most games make nothing. You might think, "oh if most games make nothing, then thos won't make an impact", but if you're removing the profit from the relatively few hits there are, it wrecks the incentives to take the risk of developing a game to begin with. If Unity wants a piece of the profits, they need to be investing.
Godot is the most obvious answer from a long term non-profit perspective, but it's not without it's caveats. Rewriting is obviously difficult, starting new projects is somewhat easier. The main issue I see is the Unity asset store ecosystem is completely different and provides massive amounts of functionality for current games, which Godot doesn't yet have much of.
I've tried Godot a few times and basic stuff like export to web didn't work at all out of the box, and it felt like alpha quality stuff. I would however like it to succeed.
Unity also has extensive documentation and training and it's an established tool for game devs who then migrate to industry jobs like industrial process/environment simulations. I have a feeling Godot is barely aware of these scenarios as it's rarely the engine of choice.
To put this very directly, Godot is a meme in the commercial games industry. Most of companies with above AA cash would rather write their own engines than use Godot, as the maintenance effort would probably exceed the effort to write the own engine to spec.
Maybe Godot is more seriously considered by indies and open source fans. But then, Unreal Engine is also practically open source for any licensee, including ones that won’t ever pay a cent to Epic. So even in indies, it’s rare to see Godot.
I champion all development in games. So I wish good luck to Godot. I’ve actually been thinking about contributing, too. I think in some ways, the ethics of Godot are a breath of fresh air. But contributing to UE looks much better on a resume.
There are a lot of forces working agains Godot: inertia, economics, instability, lack of talent, lack of appeal to talent. No marketplace actually is the least of its concerns as we don’t use marketplace stuff much in AAA/AA. The engine makes a lot more sense on paper than in reality.
I hope Godot/Bevy do well but there's a kernel of truth there as well. It was not uncommon for us to make significant changes to licensed engines to meet the needs of the game style/design. UE3 for instance was pretty awful for open world titles(gears was quite a rails shooter and the engine reflected that), there's a number of titles that took the renderer and re-did many of the major game systems.
Once you make changes like that upleveling is a serious challenge. We had one dev who's responsibility was to pull latest, spend about a month getting to to compile, another 1-2 months fixing all the issues, checking it in only to them spend another 2 months fixing all the cases that weren't tested. With a ~6mo uplevel cadence it was just enough time to finish it in order to start the next uplevel. Once you've gone through that internal engines start to look appealing(although they have their own pitfalls, I.E. heavy dependency on MAX/Maya for editor support and other "fun" bits).
> To put this very directly, Godot is a meme in the commercial games industry. Most of companies with above AA cash would rather write their own engines than use Godot
I find this an odd statement because from my perspective there aren't any AAA titles written in Unity either. They are all proprietary engines or Unreal nowadays.
So the question isn't if Godot can take over the AA, AAA games, it's can it take over the market currently served by Unity.
It probably can't right now, but probably not as far off as it seems either
> There are a lot of forces working agains Godot: inertia, economics, instability, lack of talent, lack of appeal to talent.
Other than "instability" none of this is a criticism of the engine itself... so why is it a meme?
Edit: I'm actually really struggling to think of a game I would consider AAA that I know of made in Unity. Please help me out if you know of some I'm not aware of.
Unity is used more widely than you might think, though maybe it's just your definition of AAA here.
Mihoyo's titles all use Unity AFAIK and have massive AAA-level budgets along with massive AAA-level revenues. Most of the big publishers have teams using Unity, you can kind of pick and choose whether those individual titles are "AAA" or not but like, Blizzard ships Unity games, etc. It's become a go-to choice for stuff that you want to cheaply ship across many platforms and have run on low spec devices.
This take seems pretty wild to me, considering that freemium multi-player games have kinda dominated top-grossing for the last decade. Fortnite, League of Legends, Genshin, PUBG all follow this model.
Oh ok, then I guess we just have a different definitions. I would define AAA titles almost purely by budget/resources.
So for example, I would say that Fortnite and Genshin were AAA games from the start, and that LOL and Pubg became and have been AAA titles for years now.
> I find this an odd statement because from my perspective there aren't any AAA titles written in Unity either. They are all proprietary engines or Unreal nowadays.
I dunno what your definition of AAA is but Cities: Skyline, Hearthstone, Genshin Impact?
I’d say that AAA are the rough equivalent of major Hollywood productions. Looking at Wikipedia for budgets and box office for a few high profile films:
Everything Everywhere All At Once had a budget in the $14M to $25M range, for a $141M box office. The Batman made $771M from a $185M-$200M budget, and Multiverse of Madness made $959M off a $294M budget.
EEAAO is a AA, maybe an A film where Batman and MoM are AAA, you couldn’t even produce The Batman or MoM with all the revenue from EEAAO. Nonetheless, EEAAO was by far the most successful of the three, both in terms of critical acclaim and in terms of return on investment.
Likewise, Hearthstone is definitely not a AAA game. It’s deliberately a much smaller product than Blizzard’s other games. Cities Skyline is the product of a tiny 30ish person company, published by a publisher famous for lower profile, lower production value games.
Paradox as a publisher is about the same tier as A24: Very successful in their respective niches, but not their industries’ 800-pound gorillas.
It’s worthwhile remembering that in the AAA/AA space that Unity was “a meme” for far longer than it should have been. I remember first seeing it mentoring student teams in Dare to be Digital whilst working on an AAA title and thinking WTF is that!?
I’d also note that the ‘commercial games industry’ is much broader than AAA/AA, includes indie game developers and ships games making looooots of money on all sorts of weird tech stacks.
That's not true. Wild Rift, Hearthstone, Genshin Impact, and more are made in Unity. Asset flip and low quality games are a meme, which used to be synonymous with Unity games, but the few AAA games made in Unity have been wildly successful.
That’s exactly the point. If you can list the number of ‘AAA’ games on one hand, then the meme holds true. I work on AAA games on in-house engines, and I’m yet to meet someone at work that would consider using Unity for anything other than a mobile, or small ‘indie’ game.
That’s sad it’s still a prevailing attitude because it’s not really true. I definitely wouldn’t choose Unity for a AAA title for workflow issues alone but it’s way more capable than that summation grants.
> To put this very directly, Godot is a meme in the commercial games industry.
Godot might be a meme in terms of AAA games, but "Commercial games" is a lot more than AAA, both by revenue and just total games developed.
> Most of companies with above AA cash would rather write their own engines than use Godot
See previous statement. When did we start talking at "above AA" companies? Also most companies with "above AA" money aren't using Unity.
> So even in indies, it’s rare to see Godot.
This has more to do with age though. You see less people driving 2024 cars than 2020 cars.
> There are a lot of forces working agains Godot: inertia, economics, instability, lack of talent, lack of appeal to talent. No marketplace actually is the least of its concerns as we don’t use marketplace stuff much in AAA/AA. The engine makes a lot more sense on paper than in reality.
Yeah again, it really feels like your perspective on game development is purely from the AAA BigCo game dev side. Which is a real perspective, but is certainly not even close to all encompassing with regard to game development.
> To put this very directly, Godot is a meme in the commercial games industry.
Yes! I feel the same. As soon as you go beyond toy examples, working in Godot becomes very hard.
And the lack of an asset store is killing it. Sure you can get assets from other sources, but I found you have to do a lot of messing around to get it working properly. While with Unity, all assets work out the box.
Worth noting people running Godot have mentioned the Asset store priority is climbing. I didn't save the tweet when I saw it but they are aware that is a huge area that would help people transition off of Unity.
I've been enjoying Construct 3. Not the visual scripting but the Javascript portion. It's a really good Javascript engine at its core. For some reason people don't know this? DragonRuby has also been pretty fun and hot reload is nice. Godot is the main answer for Unity but web support is just better with Construct, obviously since it's built on web technologies.
My main issue with Unity and why I never picked it up is, I have poor vision and the editor doesn't scale on Mac. You basically have to have perfect vision to see anything that's going on. A scalable editor is a must. Godot / Construct fit these. Game Maker looks so poor on 4k that it hurts my eyes.
Construct 3 moved away to a subscription model (I was a huge fan of C2 back in the day) and annual fee. I'd recommend checking out GDevelop, an open source 2d visual game engine which also exports for HTML5/mobile, and is completely free.
This feels like blogspam trying to bring traffic to computerenhance.com.
Casey has never shipped a video game of his own. It's not just an "I haven't used off-the-shelf engines" situation, he hasn't developed a game start to finish with any engine.
AFAIK Handmade Hero is the furthest he's ever gone in shipping a game, which is a far cry from finished. He's not really qualified to speak to the matter of which engines are best for delivering and supporting polished, fun, finished video games.
Please correct me if I'm wrong; what titles has he put out there with his own engine?
I know a lot of people recommend Godot because it's super good but if you want a more code oriented and batteries included engine I recommend Panda3D [0] it's open source, super mature (it's actually one of the oldest continously developed game engines), and can be used form Python and C++. Not sure why it's not more popular it's flexible and super fun to use.
10 years ago everyone believed Blender would become the new Unity, but it didn't, it's too difficult to make games with Blender, no one even mentions the idea or recommends it anymore, although its 3D editor is highly used and improved during the years. For Godot to become the favorite indie game engine they must focus on making its workflow straightfoward and simple. On the tech aspect Godot seems like Unity 5.
10 years ago Unity wasn’t trying to shoot every developer that uses them in every organ that matters.
That’s changed. Unity won’t be able to last this because it’s impossible to make the economics of it work. So even if the alternatives aren’t as good, people are going to have to use it. It’s not really optional.
This is true, but it's not like Godot is the "best alternative". for a medium-large sized team, it's only the best alternative if you have overly rigid reasons to not use Unreal Engine or your 3d game (if you have a 2D game, you are probably better off using GameMaker. Or perhaps going back to Monogame).
Sure, but at the time they showed real interest in becoming a mainstream game engine, showed some cool advanced projects, and had a few years to try out, why did the give up if there was hype?
I'm not sure what "cool advanced projects" you're thinking of, but to my recollection, there was very little in the way of finished work created with the original Blender Game Engine. There were two game efforts associated with the Open Movie Projects: Yo Frankie! (associated with Big Buck Bunny) and Sintel The Game (associated with Sintel.) The former had something like a proper release, but the latter only ever got a few alpha releases before being abandoned: neither was terribly impressive except inasmuch as a demo of the technology, and to my recollection, neither inspired much hype. (The Wikipedia page for Yo Frankie! says dryly, "The game was noted by the gaming press," without any further elaboration, which does not speak to massive amounts of excitement or hype.)
Since then, aside from some interesting bits of work that didn't actually make shipping games easier, the engine really languished. My understanding is that a big part of the reason the engine was removed was that it made work on other parts of Blender more difficult, and that dispensing with the (little-used) engine in favor of the (increasingly popular) modeling tool was clearly a net benefit to being able to develop Blender, especially since the mantle of "open source game engine" had been taken up by other competent projects like Godot.
So yes, they may have at some point aspired to becoming a "mainstream game engine", but there's more to that effort than just aspirations and demos. (And at the same time, the fact that the BGE faltered doesn't mean that other open source game engine efforts would necessarily face the same fate.)
It's probably also worth saying that people have forked the game engine and you can still use it: the forked version is called UPBGE, and there are people out there trying to make it work. By and large, though, the Blender project seems to point people at projects like Godot, with the idea that a focused game engine is probably better suited to modern games than something that strapped a game engine onto a piece of modeling software.
If I had to take a guess without any proper research:
1) Godot didn't want to chase two rabbits at once. Making an engine is hard, and making a modeling program is hard. If they split attention between the two, they may have ended up with a half-assed engine/modeling program instead of a professional grade modeling program and an abandoned engine.
2) much simpler, but the game engine team fell out. So there was no one to properly maintain the Blender Game Engine. No malicious reason: it's an open source initiative and this would be 5+ years before Godot got major funding. They may have changed life perspectives, may have gotten poached, or simply lost interest (and ofc there's other office politic conspiracy theories)
but these are 2 of many reasons, and I'm sure if you tracked down the right person in Blender you can simply ask for the real reason (and then maybe make close friends for the real gossip lol).
Selfishly, this will be a minor win for me. I occasionally like to try indie games from itch. For safety reasons, these are obviously run inside a VM. Unity games have always run like garbage on this setup, so the more developers migrating off the platform, the better for me.
I was once pulled on to a small unity mobile game that was being released by a small studio in the iPhone 4 days to help fix performance issues. After looking at the frame capture, I could see that the entire scene was being rendered about 5 times per frame from different angles. Turns out the team had a bunch of cameras enabled, but because they only saw the rendering from the last camera, they just edited that one.
I sometimes think Unity makes making games TOO easy, and you end up with people that have no technical knowledge of the way games work so they can’t fix/diagnose the most basic things. Obviously the game runs slower when you render the scene 5 times, but they didn’t even think to open a frame capture tool.
The fix for the issue that plagued them for months, was to uncheck the ‘enabled’ box for these unused cameras. Probably took 30mins to diagnose and fix.
IMO Unreal Engine is the best deal available and fits >90% of use cases for game developers. Unless you are building something for the web or low powered mobile VR I wouldn't even consider anything else. For PC and console games UE5 provides incredible amount of tools and flexibility. It's also great for building 2D/3D mobile games. People who say complexity of Unreal has stopped them from using it have gotten it wrong. UE5 provides you with a lot of tools, you don't have to use them all. But if you are thinking of building something more complex than a hello world example, you'd realize that the additional tools that UE5 provides you greatly save your time.
If you are a total beginner you can use Blueprints to write the game logic and use the existing out-of-the box tools. If you are a more experienced programmer you can use C++ to build custom components/plugins to get more customization.
I remember a time that game engines were these precious secret tools that you had to pay millions of dollars to get a license for. Now you can get the full source of UE5 on Github for free. And you pay something like 5% after 1 million dollars of revenue. This is just a no-brainer folks. IMO 5% is totally deserved and justified. In fact it's a bargain and you save money by paying Epic 5% compared to anything else out there. Use UE5 unless you have a really really really good reason not to.
> IMO Unreal Engine is the best deal available and fits >90% of use cases for game developers.
The only place Unity really shines (both IME and in industry) is mobile games. Unreal IIRC doesn't really have even close to comparable support for mobile platforms. Mobile games by revenue make up more than 10% of the games industry, so I would say the ">90% of use cases" thing is just untrue.
> And you pay something like 5% after 1 million dollars of revenue.
> IMO 5% is totally deserved and justified.
Again, for mobile games, that's 5% after 1m in revenue, which also includes Apple and Google's 30% cut. So again, no, it's really not a good deal _at all_.
In retrospect this comment feels like some form of advertisement for UE5 more than actual discussion.
> Mobile games by revenue make up more than 10% of the games industry
I've said this already in another recent thread but mobile games and pc/console games are two entirely separate markets, with different potential customer pools.
Conflating them together makes about as much sense as conflating console/pc games with accounting software.
> I've said this already in another recent thread but Mobile games and PC/Console games are two entirely separate markets, with different potential customer pools.
Yes, agreed. But again, as I've already said, the reason to point out mobile games specifically is because that's where much of Unity's success has come from. There's really no point in discussing Unity's monetization efforts without also discussing the mobile games industry. PC and Console games just aren't written in Unity at the frequency or scale that it would matter.
> Conflating them together makes about as much sense as conflating console/pc games with accounting software.
Yes, which is why I pointed out the above post combining them when the ought not be.
30% for distribution is fine, 5% for more than half the cost of development is not?
Fortnite is also a top selling mobile game developed with UE5. You can make great mobile games with UE5 now. Mobile hardware right now is comparable to last gen consoles.
> 30% for distribution is fine, 5% for more than half the cost of development is not?
Quote me where I said the 30% tax was "fine" please.
> Fortnite is also a top selling mobile game developed with UE5.
Yep! So we've gotten to the exception that proves the rule. Aside from Fortnite, which is written by Epic, Unreal Engine hasn't had even close to the success or adoption on mobile platforms as it has elsewhere.
> You can make great mobile games with UE5 now.
You can make great mobile games in javascript. This isn't really about "can".
>Unreal Engine hasn't had even close to the success or adoption on mobile platforms as it has elsewhere.
not sure if that's a fair comparison. UE existed for 15 years before smartphone applications existed. Unity's first public release was mac only and focused a lot on making web and IOS apps. No surprise that Epic's decade long dynasty wasn't surpassed when they never put a strong emphasis on mobile to begin with.
IIRC Unreal Engine has 15% mobile marketshare, so it's not an unviable option. Especially in times where even mobile games are starting to come into the open world action frenzy.
It isn't though, in the context of a f2p mobile game. Under one model, only paying customers cost you. In the other you're paying for every drive by (re)download.
Yeah, certainly. This feels like such a weird model. Many developers will end up paying much less than 1% maybe even closer 0.1% while for others it could be much higher than 5%.
And the worst thing is that they’ll apply it retroactively so that your only choice will be take down the game or pay up whatever Unity asks..
>Again, for mobile games, that's 5% after 1m in revenue, which also includes Apple and Google's 30% cut. So again, no, it's really not a good deal _at all_.
Not necessarily, let's do the math:
for 1m downloads, UE depends on how much money you make. But regardless of how much money you made, Unity's new plan on Enterprise (in the worst case, because they have not specified if the charges start after 1m installs or applies to the first million as well) will cost you $46,500, on top of the per seat pricing of enterprise. in this case, the cutoff point for when Epic costs more is if you made more than $930k in revenue. But since Epic waives the first million, this actually means you need to make $1.93m in revenue before it cancels out.
and if we go further along (where Unity's prices for enterprise start to stabilize at $0.01 per install), if you hit 5m downloads you are charged a total of $106k, the breakpoint here for UE is if you made $3.1m in revenue (again, waiving the first million).
----
By the looks of things, for a mid-revenue game UE looks better, but higher revenues mean Unity start to win out. In particular, mobile games tend to utilize whales that can make the attach rate MUCH higher than $2/user (you may not have 99 users paying anything, but a whale dropping $1000 balances the arithmetic mean to $10/user), so Unity will win out. Funnily enough, the less ethical f2p games may still prefer Unity over unreal.
For games that rely on ads or subscriptions, though? Absolutely fucked over. Drastically. You simply cannot make an ethical mobile app with Unity anymore as every user that visits and leaves in 10 minutes after a certain threshold is costing you money. If you had a bad launch with lots of users but barely any revenue, you can legitimately end up in the red for using Unity. As it would be better to shut down your app and relaunch under a different name than to try and recoup the costs with the current app.
----
I won't ramble on too much longer, but I do want to add one more tidbit to keep in mind. Gamepass and Apple Arcade are also factors, and Unity said they would charge the distributors for this. In the worst case, this can mean that Microsoft/Apple can remove your existing games from these services and disallow Unity games to be hosted. So if you want to one day utilize these kinds of subscription services, you may not even have such a choice to begin with.
> Again, for mobile games, that's 5% after 1m in revenue, which also includes Apple and Google's 30% cut. So again, no, it's really not a good deal _at all_.
5% of 70%? Or 30% + 5%?
Regardless, price your game in a way that makes you money.
I by and large loathe how commonplace big do-it-all game engines have become in indie game development, with unity at the forefront of this movement.
Even if everybody and their mom used the same awesome product, I'd still be upset because because of the market stranglehold that eventually creates - Unity in this case is worse because it isn't even an awesome product. It's a mediocre product with an actively hostile business strategy.
I admit this is entirely emotional, but when I learned that Hollow Knight[0] was made in Unity, it broke my heart. A 2D game with a consistent art style (read: write the shaders once and forget it), made up entirely of flat surfaces with only a handful of different methods of movement, no physics to speak of, and only a couple hundred different types of enemies, most with large overlaps in AI save for bosses. Gorgeous game, strong art direction, thoughtful lore and story, but any game developer could probably write the engine for such a game in a couple weeks.
But every indie developer I've talked to about game engine development acts like it's a dark art. That it's just impossible for mere mortals to do such a thing, and if you do, then you'll never ever release a game, or you'll spend literal years on the engine. Again, I predict a couple weeks.
Back to the article, I dislike that 'game development post-unity' just means 'picking out a new engine'. Everybody's jumping ship to Godot or Unreal or whatever else because we all need a game engine. But why? Why is this song and dance necessary? I feel like since the author is a game engine programmer himself, this option should have come up higher on the list along with the non-engine libraries and frameworks.
> But why? Why is this song and dance necessary? I feel like since the author is a game engine programmer himself, this option should have come up higher on the list along with the non-engine libraries and frameworks.
I’ve done a little bit of this casually; imo it’s because I don’t want to write the engine. I want to be making features for the game, not making a bespoke custom engine and fixing issues with it as well as my game.
Just to give some perspective: Without prior graphics programming experience, I was able to write a simplistic 3D engine (VERY simple, but enough for my purposes) in a week or two. I somehow assumed that it was just an impossible thing to do and so I've never tried, until recently. It turned out to be much easier to get something going than I could've imagined.
It's true that Unity and other engines offer tons of features, but most indie developers probably won't need them, and by the time they do need more than the basics they'll have so much experience that they can easily implement what's missing in their own "engine".
We're also seeing some interesting developments in this space with WebGPU, which is what prompted me to finally give it a try in the first place. I've never used OpenGL before and I was still able to get by (more or less), after failing miserably to complete the Vulkan tutorial...
If nothing else, I can only recommend people at least think about whether they really need Unity/Unreal and consider that there are disadvantages as well as advantages when using them.
Also, for even things like physics there are many simple ways to do things. Take Towerfall's arcade physics for example[1]. In under 100 lines you can create the basis for your platformer game. Sure, it's not just pluggable into other pre-existing solutions, ie tile maps, but at least you aren't endlessly hacking all over the place to tweak Unity's physics into submission to get the controls feeling right for your simple 2d game. There is a massive wealth of gamedev knowledge that doesn't seem utilised to its potential because existing engines want sell their pre-canned solutions. I think what the gamedev scene needs are more tools like LDTK[2], with more thought given to how such tools could interop, and a better selection of low level rendering libraries (like Monogame and Raylib) with very robust cross platform support and dead simple build systems (or none at all).
I use a very obscure library called Kha[3] and it has by far and away the best performance for 2d rendering that I have encountered. It is amazing what you can do with just a very basic immediate mode ui library called Zui[4]. I think it is shitty advice to say that you are either building an engine or game. This advice would be applicable if you are building a general purpose game engine, not the highly specific and bespoke engine used for you own game. Your game and your engine are basically the same thing and you take many shortcuts, make many compromises, and build out a rough and minimalistic "editor" used just by your small teams (or yourself) to get the job done.
When people say to build a game not an engine they mean “don’t copy the patterns of general-purpose game engines and build something specific to your needs”. There’s not game that doesn’t have bits you can point at as “the engine”. Lots of people get stuck “making the engine” to make their game rather than making the specific engine bits they need as they go.
That said this was the status quo before Unity and whilst it shipped games the asset pipelines and editors in engines like Unity and Unreal are much more productive for the non-programming portion of the team. As well as providing a shared framework that makes it easier to hire and train developers. Not to mention easier porting and so on.
I do think the solution to part of this is an open-source scene editor/flexible tool that has some defined interface that any engine can implement like a language server or similar.
I’ve made similar predictions in the past… these days, I predict that a couple years actually makes a lot more sense. Especially if you’re not familiar with game engines, and especially if you have to figure out: physics, input mapping, window systems, graphics pipelines, audio systems, game logic component systems (basically the game loop), level systems, transitions, platform support (switch, PC, PS5, Xbox, …), level editors, serialization, animation systems, particle systems, and more!
I have a big fat book sitting on my bookshelf called Game Engine Architecture by some of the developers at Naughty Dog. That bad boy is 1,000 pages and just gives a high level overview. It does not teach you how to set up a graphics pipeline, open a window or write a shader. I have other big fat 1,000 page books for those. Those do not teach you the mathematics needed to fully grasp linear algebra. I have yet more big fat 1,000 page books for that. Those books do not teach you C++, I don’t believe any book is sufficient for that big fat language, but I have a few anyways.
It’s cool if you enjoy tinkering on engine stuff, but boy am I glad that the Hollow Knight devs (I believe there were only 2 people) just used an engine. It’s an amazing game, and I could care less how it was made. I’m just glad that it was made.
Edit: I forgot to mention game HUDs, UI systems, font rendering in general, and asset management pipelines to the list of things that come with an engine but you’d have to either code it yourself or just not have it if you don’t want to use an engine. All of these subdomains can have years of effort poured into them (speaking from experience). The rabbit hole never ends haha.
Those big fat books are, from my experience with math books, definitely not written in a way to teach well.
Programming languages can be broken down to their syntax. For experienced programmers, I recommend starting by reviewing a language's reserved keywords then skim over any core lib, for example: https://en.cppreference.com/w/cpp/keyword
There are similar shorter paths for people. However, I'd note that most people who went to school for CS have already taken math classes through at least linear algebra, and because of interest, many also took game development classes. At least, I did. I actually wrote a game myself from scratch in C++ in high school in the days before youtube, when there was very little guidance on the internet. It was bad, but if I could do it as a child, others can certainly do better today.
Rabbit holes never end. Professionally, I learn in sort of random directions, at least learning what I need for my next task. But it's impossible and completely unnecessary to have complete knowledge of anything. YAGNI.
Math books can be a hit or a miss, but Game Engine Architecture is an amazing overview of all the major systems in a game engine. You’d also be doing yourself a disservice if you didn’t read something like OpenGL Superbible (that book filled in so many gaps in my knowledge and made graphics development so much easier).
As for the rest of your comment I absolutely agree. I wouldn’t discourage anybody from trying to write a game from scratch, but if you want to focus on art style, level design, game mechanics, and being able to easily ship to almost every platform, then I would definitely encourage you to use an engine like Unreal or Unity.
OP made it sound like Hollow Knight could’ve been a great game if only they didn’t use Unity, but I don’t believe that. It is a great game, full stop. It’s like people that complain about electron (which I also tend to agree with) irregardless of whether the final product is any good or not. VSCode is great, in spite of the fact that it was written in Electron. And ultimately, the people buying your games really won’t care how it was made, they’ll just care about how it plays.
"But every indie developer I've talked to about game engine development acts like it's a dark art. That it's just impossible for mere mortals to do such a thing, and if you do, then you'll never ever release a game, or you'll spend literal years on the engine. Again, I predict a couple weeks."
It's a can of worms to make a game engine for multiple platforms.
> Everybody's jumping ship to Godot or Unreal or whatever else because we all need a game engine. But why?
I'm assuming we're talking about 2D games so I won't dwell on the "because they want to make a 3D game". See musings below
1) not everyone has that technical prowess, they may not even want to code to begin with. I may be able to whip something up in a few weeks for a 2D game, but someone new will simply be learning how to code first and then finagle with libraries they can't full piece together. So engines that can heavy lift and let a user do simple scripts (if that) to do their movements is a big demand.
2) engines differentiate from frameworks by offering different suites for other parts of development. Designers would love a level editor and that is annoying to make (even in 2D). Artists may want to tweak the lighting or even do some light procedural generation, so the ability to get feedback of how it looks in-game helps a lot more than guessing in their artist suite. even other programmers may want conveniences for front-end annoying stuff like UI, where the correctness isn't based on the code
3) Familiarity. Just because you CAN work on your own engine doesn't mean you want to. I'm sure the Hollow Knight devs simply followed up on their game jam project in Unity because they knew Unity. You can't spend all your waking hours thinking about how your tools may go to shit in 10 years. You'd never get anything done.
I'm all for encouraging more engines, but I can understand reasons to seek out something rather than prioritize ownership.
-----------
>But every indie developer I've talked to about game engine development acts like it's a dark art. That it's just impossible for mere mortals to do such a thing, and if you do, then you'll never ever release a game, or you'll spend literal years on the engine. Again, I predict a couple weeks.
As someone who's gone down that rabbit hole: it is black magic combined with pixie dust when working on a 3D game. There is just so many edge cases to resolve and techniques to implement to make a 3d scene look good. And now you need to build something that lets non-devs be productive on op of that (or accept that you will have an artist backseat driving you, losing efficiency). You will spend years and end up with a much worse product, likely very buggy (no pun intended). There's just too much to learn before you even start making the game. Make games, not engines (I say as an engine programmer).
For a 2d engine, sure. Hollow Knight probably could have been made in Gamemaker with no technical hiccups. And if you know what you're doing you can utilize a couple of libraries and whip up a decent 2D engine that is all yours. You'll still have issues, but it isn't insurmountable if you're making a simple game that moves around a few hundred sprites on screen.
You can definitely stand up the basics of a 2D game engine really quickly… if you’ve done it before. If you haven’t it’s an unexplored problem and is significantly more challenging.
But it doesn’t end there because once you’re done standing up the engine you need to improve and maintain it. Then port it to different platforms, you did remember to abstract things nicely when you stood it up right?
And that’s without mentioning all the extra time you’ll be putting into higher level systems like localisation and UI. And the combo of those two is fearsome!
Plus you have to make a game.
Or you can use Unity or another off-the-shelf engine and ignore most of these issues.
Which isn’t to say you can’t make an engine but if you are running a business you need a compelling reason why that becomes an advantage. I doubt Hollow Knight would have found it’s success as easily if they had to worry about all of that.
Anybody know of something good and simple in Python? I'm more interested in agent-based machine learning in 3d simulation than making games. I'm familiar with Ursina on top of Panda3d. Is there anything new on the horizon?
Panda3D is probably the best proper game engine in Python, unfortunately. Python as an interpreted language tends to have large performance costs for games, and python hasn't been too popular as a scripting language buit on top of engine code (studios love to use python for tools, though).
I'd second taking a look at Godot, since its GDScript is meant to closely mimic Python.
157 comments
[ 3.2 ms ] story [ 209 ms ] threadThough as it says in the article, Godot does lack proper support for consoles.
Ports will be pretty brutal unless the outrage remains high and someone makes some kind of porting toolkit.
And to be honest, I don't know how easy asset migration is (hence the question mark). it's a surprising pain point when moving from Unity to Unreal even if you keep everything as the industry standard FBX. I don't know if it "just works" in Godot or can be its own undertaking. Histoically it does mess up a lot of texturing and animations, even if you manage to get the base model in intact.
None of the open source engines do, or ever will as publishing to consoles requires that you sign an NDA. If you're a godot dev and want to publish on console look towards https://lonewolftechnology.com/
Edit:
This is the only one I could find, but looks more like a contract to port:
https://lonewolftechnology.com
Godot created W4 Games to get around this. So while Godot is open source, W4 can work on a fork that implements console-specific code that cannot exist on an open source repo.
https://w4games.com/2023/08/06/w4-games-unveils-w4-consoles-...
Sonic Colors: Ultimate for the Nintendo Switch was made in Godot[1].
From what I read elsewhere, console support code is usually protected by NDA, so the Godot devs setup a commercial entity to support consoles[2].
1: https://www.destructoid.com/first-sonic-colors-switch-patch-...
2: https://w4games.com/2023/02/28/godot-support-for-consoles-is...
I'd really like to see how alternatives handle stuff such as:
- Editor tools for non-artists
- Editor API for customization/automation
- Profiling CPU/memory
- Integration with things like FMOD, Spine, whatever else
- Tools for debugging
- How does level editing work, what tools are present to assist with visualization, organization, construction
So he may not be the most appropriate person to ask for game engine advice (since he says in the article, he makes and rolls a lot of his own tech), but he will inevitably be asked for his thoughts and advice on the situation regardless.
0: https://handmadehero.org/
I've seen 2 articles in the last day about this topic with clickbait misinformation from sites I would expect to be more accurate... Including talking about how a "free game" was going to cost a developer millions... and how "independent developers" will be bankrupt...
But how? The fee page and FAQ [1] state "will apply to games made with Unity Personal and Unity Plus that have made $200,000 USD or more in the last 12 months".. If you are distributing a free game, by definition, you made no revenue for the game and you pay nothing to Unity. Key point: the metric is PER game... so it's not like your $5 game with 200k revenue and 200k installs will trigger your separate FREE game to cost 5 million in damages.
If you are an "independent" developer, or even a team of 5, then the $2k/seat-year Pro license means the threshold is now $1million... pay 2-10k/year upfront to pocket an extra 800k? These seem like a no-brainer...
Now, I can see this being an issue for studios that invested heavily in Unity with dozens or hundreds of developers.. and I appreciate discussion on this topic... I'd love to see more realistic reactions and discussions... and less "abandon ship" (like this article) and I-didn't-read-the-memo knee-jerk reaction stories for attention out there right now.
(And I know some of the early concern was download-bombing, but they have addressed that, and most of the articles I read didn't cover that explicitly)
[1] https://unity.com/pricing-updates
I'm not sure that's true, their Ads business(es) is made up of other companies which they acquired over the years and is/was somewhat isolated from the engine/tech part of the company.
Given this, then the details of this particular royalty structure don't matter. Yes, a freebie game may not have to pay any royalties now. But as Unity enters the death-spiral that will probably change. Or there will be mandatory malware shipped with the engine. Or some other craptastic revenue-generating idea will mess with the game. We can expect relatively frequent, drastic changes to Unity's licensing as it tries to escape its fate.
Part of the change (unless it has since been walked back) was getting rid of Unity Plus licensing, leaving just Unity Personal and Unity Pro.
Also assuming the per-game stipulation was not something Unity made clear after out-cry (like the multi-installs on the same PC or game-update), they have previously gone to great lengths to prevent studios from spinning up a new company per game. It is reasonable to assume that there is nothing stopping them from later tightening the noose and applying this fee on a company basis instead of a game basis.
They addressed that in FAQ update. They have also previously committed to not retroactively change ToS for the version you downloaded (https://old.reddit.com/r/Unity3D/comments/16hjic6/unitys_sta...) but they changed their mind.
Given that history I would not put much trust in one vague answer in FAQ without at least consulting lawyer first (including asking how much it would cost to defend if Unity lawyers disagree with your lawyer's take).
And even in the current FAQ answer it's essentially fully up to them to determine what is fraudulent installation or if the install was part of install bombing.
I'd love to hear WHY.. not knee-jerk reactions...
Someone else mentioned that some people use "Free" to also mean ad-supported or micro-transaction... That wouldn't be my definition, but I suppose that is a fair concern at-a-glance for an article that says a "free" game can bankrupt them... That's a lot better than most of the comments I've seen on this topic.
With the model I described you could easily bring in 200k worth of revenue off DLC but then owe a significant % of that in install fees if you're only managing to sell DLC to say 10% of your players.
Unreal-style revshare where you just give them a small % is super reasonable in comparison. It just works and you decide whether the percentage is acceptable.
The per install fee is still going to be significantly lower for everyone making > $2 per user than what Unreal charges. And I assume Unity's best paying customers are doing that. A rev share model would have been much more likely to scare them off. It almost feels that killing the low revenue per user F2P developer user-base might have been a conscious calculated choice (I'm probably giving too much credit to their upper management though).
Their largest customers will probably push back against that more than the install fees.
You're losing most of you revenue from China (and some other countries). Companies there will cheat and underreport their revenue (Unity historically had issues even having them to pay for licenses, studios would just buy 1 license per 10-20 developers etc.)
Some of these mods turned into games later (Chivalry, Black Mesa, Insurgency come to mind) but without investigating I'm not sure they even use Source anymore.
> Less than half their revenue comes from game engines. Over half comes from advertising.
That is to say, Unity makes most of its money from people PLAYING games made with Unity. The sales to the developers are secondary. Unity had to change their model, and that meant either making the engine cheaper to acquire more games to get more ads, or it meant raising the price of the engine at the likely cost of ads, and for some reason they chose option 2, which seems like a dumb idea.
The best explanation for that I can think of is that almost all of the advertising money should be coming from smaller mobile games, and so this is a move to try and make more money from the desktop games and the mobile games that don't use Unity's ad networks, which probably look like big, untapped sources of income to dumber product managers.
But now imagine that they did the opposite: they raise the maximum revenue requirements and "must show splash screen" requirements and generally make Unity more available for less. Engine revenue goes down a bit, but ad revenue goes up, which probably works out even better in the long run, but also solidifies the user base, garners good will, and generally leaves everybody feeling great about Unity.
And we are switching to Unreal. The price is not why we were using Unity in the first place. I don't like Blueprints and I don't like C++. Verse looks like it's going to be super weird.
Unity is more versatile, smaller, easier to use. Faster to iterate.
I've worked with both engines for many years, on the Bioshock games in Unreal and Void Bastards in Unity.
But Unity has shown time and time again that they have no respect for us, so we really can't continue to do business with them.
If I use Unreal, if my game generates 2M$ revenue, I know exactly what I'll need to pay Epic. With Unity's model it's a coin toss. Are lots of people going to reinstall my games ? Am I going to get install bombed ? I have no idea.
Personally I think it's the store takeaways that are way too high. And in some cases overstep their boundaries in what they allow an app to do or how to sell it. But that's a big tangent.
Noob consumers may click ads, but after a while they program their brain to filter them out automatically. Or occasionally filter them out using technological measures. I bet that most ad clicks are by mistake or similar (especially ads in Unity games (which AFAIK are interstitial video ads)), or the user wasn't realizing what they were clicking on was an ad (noob users, or e.g. ads at the top of Google results, which used to be much easier to distinguish from actual results).
Most of my ad clicks are by mistake (due to bad page layout, or there just happened to be an ad where I happened to click), some (a handful of times per year at best) are to satisfy curiosity. And maybe a single one in my lifetime actually led to a purchase.
Google ads started out text-only, now they're pretty jarring on average. Guess why. However, there's a limit to how jarring you can make ads before consumers say bye-bye. Unity ads are probably way over the limit, Google are sort of tip-toeing along the line (or let's say they're over the line for a minority, and not quite for the rest).
True, and it’s not even just about the ads being annoying even.
Regulators are catching on to the privacy problems tied to online advertising.
Perhaps Unity is seeing this too, and have concluded that regulators might come for their ad revenue one day.
Ads are not just about clicks. Half of all spending is brand advertising.
Noobs don’t click random SMB ads, and yet that’s like 40% of spending on mobile.
There are people who are “superclickers” and also super buyers. They’re just a really expensive audience to target, obviously.
Anyway, you’re extrapolating from your sole experience with ads. It is a super big ecosystem with a lot of rationality, as ridiculous as that sounds. It is growing a lot still, digital ad spending grows like $130b a year around now, which is the highest it’s ever been. So I don’t know, you’re not saying stuff that is substantiated in truth.
You're right, but to expand: Apple's privacy changes at the beginning of 2022 screwed over a lot of adtech, and now the rise of AI is making ad providers even more speculative of certain types of content. I think Adtech is recovering now but for a company like Unity who relies on ads, it dealt them a huge blow for the last 18 months. That's probably what promtpted the merger/aquisition and started its plans into how it can extract more from its devs.
The ad market is more competitive and very crowded there is no reason to use Unity for your ads if someone else offers a better deal.
Also Unity did try focusing on increasing ad revenue over the last several years, it didn’t work out that well.
> leaves everybody feeling great about Unity.
Making their engine entirely free would make most people feel even better.
> untapped sources of income to dumber product managers.
Why? Most Unity’s client’s don’t make much if anything at all a few make massive amounts. Due to the fixed licensing model the latter barely pay anything to Unity (e.g. compared to how much they pay storefronts/platform owners/ad networks). If they want to continue growing their revenue Unity has to get more from these customers, there aren’t that many other options.
It's already happened for 3d modelling (Blender) and digital painting (Krita), and it feels like gamedev is an even better market for this to happen in than those because all the users are also going to be capable of contributing to development of the engine.
From the outside Godot looks like it's the closest to ready for building proper AAA quality 3d games.
I've also actually used Bevy and if you're a fan of rust and ECS based development it's really nice for building procedurally generated stuff that doesn't need a level editor, or for building 2d games and relying on a 3rd party editor like Tiled or LDtk. However there's plenty of places where it's still a bit rough around the edges, like dealing with more complex multi stage asset loading pipelines.
Although I would love to see how far a code only engine core + separate third party level editor tooling model could go, it appeals to my intuitive feel of what the "right" way to build software is.
But on mobile it is king, and mobile is starting to get games that can rival AAA studios in presentation. Genshin Impact and the rest of Hoyoverse's games are all in Unity, and while not confirmed I wouldn't be surprised if Project Mugen is also running Unity (given that most of NetEase's portfolio relies on it). So it has the capability to handle AAA games, even if no one in the west is utilizing it.
I'm now at AA level studio and for this category Blender is eating competition super fast!
Blender has really come a long long way!
The reason it's so popular is because there wasn't anything else for a long time, and also probably because it's still lobbied to unis.
Office is the rough one, though. There's LibreOffice, but it never seemed to improve on its UX. and in the meantime Google docs came and became the big competitor.
I've tried Godot a few times and basic stuff like export to web didn't work at all out of the box, and it felt like alpha quality stuff. I would however like it to succeed.
Unity also has extensive documentation and training and it's an established tool for game devs who then migrate to industry jobs like industrial process/environment simulations. I have a feeling Godot is barely aware of these scenarios as it's rarely the engine of choice.
Maybe Godot is more seriously considered by indies and open source fans. But then, Unreal Engine is also practically open source for any licensee, including ones that won’t ever pay a cent to Epic. So even in indies, it’s rare to see Godot.
I champion all development in games. So I wish good luck to Godot. I’ve actually been thinking about contributing, too. I think in some ways, the ethics of Godot are a breath of fresh air. But contributing to UE looks much better on a resume.
There are a lot of forces working agains Godot: inertia, economics, instability, lack of talent, lack of appeal to talent. No marketplace actually is the least of its concerns as we don’t use marketplace stuff much in AAA/AA. The engine makes a lot more sense on paper than in reality.
Once you make changes like that upleveling is a serious challenge. We had one dev who's responsibility was to pull latest, spend about a month getting to to compile, another 1-2 months fixing all the issues, checking it in only to them spend another 2 months fixing all the cases that weren't tested. With a ~6mo uplevel cadence it was just enough time to finish it in order to start the next uplevel. Once you've gone through that internal engines start to look appealing(although they have their own pitfalls, I.E. heavy dependency on MAX/Maya for editor support and other "fun" bits).
I find this an odd statement because from my perspective there aren't any AAA titles written in Unity either. They are all proprietary engines or Unreal nowadays.
So the question isn't if Godot can take over the AA, AAA games, it's can it take over the market currently served by Unity.
It probably can't right now, but probably not as far off as it seems either
> There are a lot of forces working agains Godot: inertia, economics, instability, lack of talent, lack of appeal to talent.
Other than "instability" none of this is a criticism of the engine itself... so why is it a meme?
Edit: I'm actually really struggling to think of a game I would consider AAA that I know of made in Unity. Please help me out if you know of some I'm not aware of.
Mihoyo's titles all use Unity AFAIK and have massive AAA-level budgets along with massive AAA-level revenues. Most of the big publishers have teams using Unity, you can kind of pick and choose whether those individual titles are "AAA" or not but like, Blizzard ships Unity games, etc. It's become a go-to choice for stuff that you want to cheaply ship across many platforms and have run on low spec devices.
League of Legends is a massive success but AAA? Not really. It's basically a Warcraft 3 mod.
And Pubg actually was a mod wasn't it?
I'm not questioning the success.
AAA implies a certain type of quality to me, and being a freemium content mill online service game is absolutely not it.
So for example, I would say that Fortnite and Genshin were AAA games from the start, and that LOL and Pubg became and have been AAA titles for years now.
I dunno what your definition of AAA is but Cities: Skyline, Hearthstone, Genshin Impact?
Everything Everywhere All At Once had a budget in the $14M to $25M range, for a $141M box office. The Batman made $771M from a $185M-$200M budget, and Multiverse of Madness made $959M off a $294M budget.
EEAAO is a AA, maybe an A film where Batman and MoM are AAA, you couldn’t even produce The Batman or MoM with all the revenue from EEAAO. Nonetheless, EEAAO was by far the most successful of the three, both in terms of critical acclaim and in terms of return on investment.
Likewise, Hearthstone is definitely not a AAA game. It’s deliberately a much smaller product than Blizzard’s other games. Cities Skyline is the product of a tiny 30ish person company, published by a publisher famous for lower profile, lower production value games.
Paradox as a publisher is about the same tier as A24: Very successful in their respective niches, but not their industries’ 800-pound gorillas.
Genshin impact though is definitely in the AAA category, it pulls in billions and had an initial budget (they put out constant updates) of $100M
I’d also note that the ‘commercial games industry’ is much broader than AAA/AA, includes indie game developers and ships games making looooots of money on all sorts of weird tech stacks.
Godot might be a meme in terms of AAA games, but "Commercial games" is a lot more than AAA, both by revenue and just total games developed.
> Most of companies with above AA cash would rather write their own engines than use Godot
See previous statement. When did we start talking at "above AA" companies? Also most companies with "above AA" money aren't using Unity.
> So even in indies, it’s rare to see Godot.
This has more to do with age though. You see less people driving 2024 cars than 2020 cars.
> There are a lot of forces working agains Godot: inertia, economics, instability, lack of talent, lack of appeal to talent. No marketplace actually is the least of its concerns as we don’t use marketplace stuff much in AAA/AA. The engine makes a lot more sense on paper than in reality.
Yeah again, it really feels like your perspective on game development is purely from the AAA BigCo game dev side. Which is a real perspective, but is certainly not even close to all encompassing with regard to game development.
That not so obvious. Ad infested shovelware does make a lot of money.
Yes! I feel the same. As soon as you go beyond toy examples, working in Godot becomes very hard.
And the lack of an asset store is killing it. Sure you can get assets from other sources, but I found you have to do a lot of messing around to get it working properly. While with Unity, all assets work out the box.
Would be nice if Godot can access Unity assets. Someone posted a demo of a Unity loader few months back:
https://www.reddit.com/r/godot/comments/13io0bx/load_unitypa...
The sentiment of that thread appears to be that it's technically feasible and would be quite useful, but the legal issues are unclear.
Imports *.unitypackage files into Godot, supporting a smattering of Unity asset-types.
My main issue with Unity and why I never picked it up is, I have poor vision and the editor doesn't scale on Mac. You basically have to have perfect vision to see anything that's going on. A scalable editor is a must. Godot / Construct fit these. Game Maker looks so poor on 4k that it hurts my eyes.
https://en.wikipedia.org/wiki/GDevelop
Casey has never shipped a video game of his own. It's not just an "I haven't used off-the-shelf engines" situation, he hasn't developed a game start to finish with any engine.
AFAIK Handmade Hero is the furthest he's ever gone in shipping a game, which is a far cry from finished. He's not really qualified to speak to the matter of which engines are best for delivering and supporting polished, fun, finished video games.
Please correct me if I'm wrong; what titles has he put out there with his own engine?
[0] https://www.panda3d.org/
That’s changed. Unity won’t be able to last this because it’s impossible to make the economics of it work. So even if the alternatives aren’t as good, people are going to have to use it. It’s not really optional.
Since then, aside from some interesting bits of work that didn't actually make shipping games easier, the engine really languished. My understanding is that a big part of the reason the engine was removed was that it made work on other parts of Blender more difficult, and that dispensing with the (little-used) engine in favor of the (increasingly popular) modeling tool was clearly a net benefit to being able to develop Blender, especially since the mantle of "open source game engine" had been taken up by other competent projects like Godot.
So yes, they may have at some point aspired to becoming a "mainstream game engine", but there's more to that effort than just aspirations and demos. (And at the same time, the fact that the BGE faltered doesn't mean that other open source game engine efforts would necessarily face the same fate.)
It's probably also worth saying that people have forked the game engine and you can still use it: the forked version is called UPBGE, and there are people out there trying to make it work. By and large, though, the Blender project seems to point people at projects like Godot, with the idea that a focused game engine is probably better suited to modern games than something that strapped a game engine onto a piece of modeling software.
If I had to take a guess without any proper research:
1) Godot didn't want to chase two rabbits at once. Making an engine is hard, and making a modeling program is hard. If they split attention between the two, they may have ended up with a half-assed engine/modeling program instead of a professional grade modeling program and an abandoned engine.
2) much simpler, but the game engine team fell out. So there was no one to properly maintain the Blender Game Engine. No malicious reason: it's an open source initiative and this would be 5+ years before Godot got major funding. They may have changed life perspectives, may have gotten poached, or simply lost interest (and ofc there's other office politic conspiracy theories)
but these are 2 of many reasons, and I'm sure if you tracked down the right person in Blender you can simply ask for the real reason (and then maybe make close friends for the real gossip lol).
I sometimes think Unity makes making games TOO easy, and you end up with people that have no technical knowledge of the way games work so they can’t fix/diagnose the most basic things. Obviously the game runs slower when you render the scene 5 times, but they didn’t even think to open a frame capture tool.
The fix for the issue that plagued them for months, was to uncheck the ‘enabled’ box for these unused cameras. Probably took 30mins to diagnose and fix.
If you are a total beginner you can use Blueprints to write the game logic and use the existing out-of-the box tools. If you are a more experienced programmer you can use C++ to build custom components/plugins to get more customization.
I remember a time that game engines were these precious secret tools that you had to pay millions of dollars to get a license for. Now you can get the full source of UE5 on Github for free. And you pay something like 5% after 1 million dollars of revenue. This is just a no-brainer folks. IMO 5% is totally deserved and justified. In fact it's a bargain and you save money by paying Epic 5% compared to anything else out there. Use UE5 unless you have a really really really good reason not to.
The only place Unity really shines (both IME and in industry) is mobile games. Unreal IIRC doesn't really have even close to comparable support for mobile platforms. Mobile games by revenue make up more than 10% of the games industry, so I would say the ">90% of use cases" thing is just untrue.
> And you pay something like 5% after 1 million dollars of revenue.
> IMO 5% is totally deserved and justified.
Again, for mobile games, that's 5% after 1m in revenue, which also includes Apple and Google's 30% cut. So again, no, it's really not a good deal _at all_.
In retrospect this comment feels like some form of advertisement for UE5 more than actual discussion.
I've said this already in another recent thread but mobile games and pc/console games are two entirely separate markets, with different potential customer pools.
Conflating them together makes about as much sense as conflating console/pc games with accounting software.
Yes, agreed. But again, as I've already said, the reason to point out mobile games specifically is because that's where much of Unity's success has come from. There's really no point in discussing Unity's monetization efforts without also discussing the mobile games industry. PC and Console games just aren't written in Unity at the frequency or scale that it would matter.
> Conflating them together makes about as much sense as conflating console/pc games with accounting software.
Yes, which is why I pointed out the above post combining them when the ought not be.
Fortnite is also a top selling mobile game developed with UE5. You can make great mobile games with UE5 now. Mobile hardware right now is comparable to last gen consoles.
Quote me where I said the 30% tax was "fine" please.
> Fortnite is also a top selling mobile game developed with UE5.
Yep! So we've gotten to the exception that proves the rule. Aside from Fortnite, which is written by Epic, Unreal Engine hasn't had even close to the success or adoption on mobile platforms as it has elsewhere.
> You can make great mobile games with UE5 now.
You can make great mobile games in javascript. This isn't really about "can".
not sure if that's a fair comparison. UE existed for 15 years before smartphone applications existed. Unity's first public release was mac only and focused a lot on making web and IOS apps. No surprise that Epic's decade long dynasty wasn't surpassed when they never put a strong emphasis on mobile to begin with.
IIRC Unreal Engine has 15% mobile marketshare, so it's not an unviable option. Especially in times where even mobile games are starting to come into the open world action frenzy.
The same can be said about Unity asking you to pay $0.05 per install (which is massively cheaper than Unreal for any non F2P game)
And the worst thing is that they’ll apply it retroactively so that your only choice will be take down the game or pay up whatever Unity asks..
Not necessarily, let's do the math:
for 1m downloads, UE depends on how much money you make. But regardless of how much money you made, Unity's new plan on Enterprise (in the worst case, because they have not specified if the charges start after 1m installs or applies to the first million as well) will cost you $46,500, on top of the per seat pricing of enterprise. in this case, the cutoff point for when Epic costs more is if you made more than $930k in revenue. But since Epic waives the first million, this actually means you need to make $1.93m in revenue before it cancels out.
and if we go further along (where Unity's prices for enterprise start to stabilize at $0.01 per install), if you hit 5m downloads you are charged a total of $106k, the breakpoint here for UE is if you made $3.1m in revenue (again, waiving the first million).
----
By the looks of things, for a mid-revenue game UE looks better, but higher revenues mean Unity start to win out. In particular, mobile games tend to utilize whales that can make the attach rate MUCH higher than $2/user (you may not have 99 users paying anything, but a whale dropping $1000 balances the arithmetic mean to $10/user), so Unity will win out. Funnily enough, the less ethical f2p games may still prefer Unity over unreal.
For games that rely on ads or subscriptions, though? Absolutely fucked over. Drastically. You simply cannot make an ethical mobile app with Unity anymore as every user that visits and leaves in 10 minutes after a certain threshold is costing you money. If you had a bad launch with lots of users but barely any revenue, you can legitimately end up in the red for using Unity. As it would be better to shut down your app and relaunch under a different name than to try and recoup the costs with the current app.
----
I won't ramble on too much longer, but I do want to add one more tidbit to keep in mind. Gamepass and Apple Arcade are also factors, and Unity said they would charge the distributors for this. In the worst case, this can mean that Microsoft/Apple can remove your existing games from these services and disallow Unity games to be hosted. So if you want to one day utilize these kinds of subscription services, you may not even have such a choice to begin with.
5% of 70%? Or 30% + 5%?
Regardless, price your game in a way that makes you money.
How? That’s significantly more expensive that Unity if you make more than $2 per user or so.
I admit this is entirely emotional, but when I learned that Hollow Knight[0] was made in Unity, it broke my heart. A 2D game with a consistent art style (read: write the shaders once and forget it), made up entirely of flat surfaces with only a handful of different methods of movement, no physics to speak of, and only a couple hundred different types of enemies, most with large overlaps in AI save for bosses. Gorgeous game, strong art direction, thoughtful lore and story, but any game developer could probably write the engine for such a game in a couple weeks.
But every indie developer I've talked to about game engine development acts like it's a dark art. That it's just impossible for mere mortals to do such a thing, and if you do, then you'll never ever release a game, or you'll spend literal years on the engine. Again, I predict a couple weeks.
Back to the article, I dislike that 'game development post-unity' just means 'picking out a new engine'. Everybody's jumping ship to Godot or Unreal or whatever else because we all need a game engine. But why? Why is this song and dance necessary? I feel like since the author is a game engine programmer himself, this option should have come up higher on the list along with the non-engine libraries and frameworks.
0. https://www.hollowknight.com/
I’ve done a little bit of this casually; imo it’s because I don’t want to write the engine. I want to be making features for the game, not making a bespoke custom engine and fixing issues with it as well as my game.
It's true that Unity and other engines offer tons of features, but most indie developers probably won't need them, and by the time they do need more than the basics they'll have so much experience that they can easily implement what's missing in their own "engine".
We're also seeing some interesting developments in this space with WebGPU, which is what prompted me to finally give it a try in the first place. I've never used OpenGL before and I was still able to get by (more or less), after failing miserably to complete the Vulkan tutorial...
If nothing else, I can only recommend people at least think about whether they really need Unity/Unreal and consider that there are disadvantages as well as advantages when using them.
I use a very obscure library called Kha[3] and it has by far and away the best performance for 2d rendering that I have encountered. It is amazing what you can do with just a very basic immediate mode ui library called Zui[4]. I think it is shitty advice to say that you are either building an engine or game. This advice would be applicable if you are building a general purpose game engine, not the highly specific and bespoke engine used for you own game. Your game and your engine are basically the same thing and you take many shortcuts, make many compromises, and build out a rough and minimalistic "editor" used just by your small teams (or yourself) to get the job done.
[1] https://maddymakesgames.com/articles/celeste_and_towerfall_p... [2] https://ldtk.io/ [3] https://github.com/Kode/Kha [4] https://github.com/armory3d/zui
That said this was the status quo before Unity and whilst it shipped games the asset pipelines and editors in engines like Unity and Unreal are much more productive for the non-programming portion of the team. As well as providing a shared framework that makes it easier to hire and train developers. Not to mention easier porting and so on.
I do think the solution to part of this is an open-source scene editor/flexible tool that has some defined interface that any engine can implement like a language server or similar.
I’ve made similar predictions in the past… these days, I predict that a couple years actually makes a lot more sense. Especially if you’re not familiar with game engines, and especially if you have to figure out: physics, input mapping, window systems, graphics pipelines, audio systems, game logic component systems (basically the game loop), level systems, transitions, platform support (switch, PC, PS5, Xbox, …), level editors, serialization, animation systems, particle systems, and more!
I have a big fat book sitting on my bookshelf called Game Engine Architecture by some of the developers at Naughty Dog. That bad boy is 1,000 pages and just gives a high level overview. It does not teach you how to set up a graphics pipeline, open a window or write a shader. I have other big fat 1,000 page books for those. Those do not teach you the mathematics needed to fully grasp linear algebra. I have yet more big fat 1,000 page books for that. Those books do not teach you C++, I don’t believe any book is sufficient for that big fat language, but I have a few anyways.
It’s cool if you enjoy tinkering on engine stuff, but boy am I glad that the Hollow Knight devs (I believe there were only 2 people) just used an engine. It’s an amazing game, and I could care less how it was made. I’m just glad that it was made.
Edit: I forgot to mention game HUDs, UI systems, font rendering in general, and asset management pipelines to the list of things that come with an engine but you’d have to either code it yourself or just not have it if you don’t want to use an engine. All of these subdomains can have years of effort poured into them (speaking from experience). The rabbit hole never ends haha.
Programming languages can be broken down to their syntax. For experienced programmers, I recommend starting by reviewing a language's reserved keywords then skim over any core lib, for example: https://en.cppreference.com/w/cpp/keyword
There are similar shorter paths for people. However, I'd note that most people who went to school for CS have already taken math classes through at least linear algebra, and because of interest, many also took game development classes. At least, I did. I actually wrote a game myself from scratch in C++ in high school in the days before youtube, when there was very little guidance on the internet. It was bad, but if I could do it as a child, others can certainly do better today.
Rabbit holes never end. Professionally, I learn in sort of random directions, at least learning what I need for my next task. But it's impossible and completely unnecessary to have complete knowledge of anything. YAGNI.
As for the rest of your comment I absolutely agree. I wouldn’t discourage anybody from trying to write a game from scratch, but if you want to focus on art style, level design, game mechanics, and being able to easily ship to almost every platform, then I would definitely encourage you to use an engine like Unreal or Unity.
OP made it sound like Hollow Knight could’ve been a great game if only they didn’t use Unity, but I don’t believe that. It is a great game, full stop. It’s like people that complain about electron (which I also tend to agree with) irregardless of whether the final product is any good or not. VSCode is great, in spite of the fact that it was written in Electron. And ultimately, the people buying your games really won’t care how it was made, they’ll just care about how it plays.
It's a can of worms to make a game engine for multiple platforms.
I'm assuming we're talking about 2D games so I won't dwell on the "because they want to make a 3D game". See musings below
1) not everyone has that technical prowess, they may not even want to code to begin with. I may be able to whip something up in a few weeks for a 2D game, but someone new will simply be learning how to code first and then finagle with libraries they can't full piece together. So engines that can heavy lift and let a user do simple scripts (if that) to do their movements is a big demand.
2) engines differentiate from frameworks by offering different suites for other parts of development. Designers would love a level editor and that is annoying to make (even in 2D). Artists may want to tweak the lighting or even do some light procedural generation, so the ability to get feedback of how it looks in-game helps a lot more than guessing in their artist suite. even other programmers may want conveniences for front-end annoying stuff like UI, where the correctness isn't based on the code
3) Familiarity. Just because you CAN work on your own engine doesn't mean you want to. I'm sure the Hollow Knight devs simply followed up on their game jam project in Unity because they knew Unity. You can't spend all your waking hours thinking about how your tools may go to shit in 10 years. You'd never get anything done.
I'm all for encouraging more engines, but I can understand reasons to seek out something rather than prioritize ownership.
-----------
>But every indie developer I've talked to about game engine development acts like it's a dark art. That it's just impossible for mere mortals to do such a thing, and if you do, then you'll never ever release a game, or you'll spend literal years on the engine. Again, I predict a couple weeks.
As someone who's gone down that rabbit hole: it is black magic combined with pixie dust when working on a 3D game. There is just so many edge cases to resolve and techniques to implement to make a 3d scene look good. And now you need to build something that lets non-devs be productive on op of that (or accept that you will have an artist backseat driving you, losing efficiency). You will spend years and end up with a much worse product, likely very buggy (no pun intended). There's just too much to learn before you even start making the game. Make games, not engines (I say as an engine programmer).
For a 2d engine, sure. Hollow Knight probably could have been made in Gamemaker with no technical hiccups. And if you know what you're doing you can utilize a couple of libraries and whip up a decent 2D engine that is all yours. You'll still have issues, but it isn't insurmountable if you're making a simple game that moves around a few hundred sprites on screen.
But it doesn’t end there because once you’re done standing up the engine you need to improve and maintain it. Then port it to different platforms, you did remember to abstract things nicely when you stood it up right?
And that’s without mentioning all the extra time you’ll be putting into higher level systems like localisation and UI. And the combo of those two is fearsome!
Plus you have to make a game.
Or you can use Unity or another off-the-shelf engine and ignore most of these issues.
Which isn’t to say you can’t make an engine but if you are running a business you need a compelling reason why that becomes an advantage. I doubt Hollow Knight would have found it’s success as easily if they had to worry about all of that.
I'd second taking a look at Godot, since its GDScript is meant to closely mimic Python.