Tough to hear. At a time it was the only company keeping Epic in check (after the horrors of UE3), probably the reason they had such an open and lax license for UE4.
From there it either plays out one of two ways depending on how competent the management of the incumbent is.
1. They underestimate and continually disregard the startup. This generally leads to AMD vs Intel situation. Don't do this.
2. Understand the threat they pose and systematically match all of their advantages, smothering them with investment they can't afford to keep up with. This is essentially what Epic did here and generally what you should always do if you have a dominant market position and can afford it.
Unity is left in a bad situation because accessibility to their engine was it's key draw. A few years ago people also felt it was an easier engine to develop games on but that viewpoint has been shifting back to UE4 as of late because of the difficulty studios have had "actually shipping" Unity based titles, let along long-term maintenance issues. In terms of pure quality Unreal has generally (but not always) been on top and definitely in terms of capability and performance.
Doesn't help that Epic has an enormous cash-cow in the form of Fortnite while Unity has next to no income outside of it's in-game advertising business. They also bet heavily on VR and that hasn't panned out to be as profitable as people thought it would be with the majority of revenue in the VR/AR space being heavily skewed into the enterprise, government and military verticals which aren't where Unity performs well.
Which situation is that? The one where the major player uses its power illegally to stifle its competition?
[1] for x86, went from 17.8% on Q4 2017 to 39.7% on Q3 2021 as per https://www.statista.com/statistics/735904/worldwide-x86-int...
Isn't Genshin Impact really, really, really massively profitable? It would be really sad if Unity takes a constant revenue instead of percentage-based off of that lol
Unity also generally seems to be terribly run whereas epic seems very solid, in no smal part due to having a huge cash cow with fortnite.
It may have been true a long time ago but I would reckon it’s epic leading the charge these days for what we would want to see from an engine company.
Mostly waiting for Godot 4 and hoping a lot of those pains will be solved, both 2D and 3D.
I am not a pro, but it feels like there are a few rough edges in Godot that will trip up someone used to unity. E.g. the script editor UI is weird (it has reasonable actual code editing, but the layout and how you select files is weird and really unintuitive IMO - no tabs, shows you all scripts and not just the ones in the scene you are editing etc), you cannot easily "view"/"find" a node in the scene by double-clicking, you can easily dig into an instanced scene to edit it but there is no intuitive way of going "back up" so it is easy to get lost in the embedded scenes-within-scenes, you can't move the panes around in the editor how you'd like, you cannot pause the game and "view" the scene in the editor (making debug for collisions etc difficult).
It is taking some getting used-to. I hope v4 sorts some of these niggles out.
Do you mean actually pausing the game (play using the editor, then pause) and then checking the remote tree? You can check the remote tree while the game is paused. I have noticed breakpoints (in C#) tend to freeze updates on the remote tree though. Additionally, you can show collision shapes during gameplay by toggling it.
>E.g. the script editor UI is weird (it has reasonable actual code editing, but the layout and how you select files is weird and really unintuitive IMO)
Big reason I use VS Code to edit. Unfortunately shaders are still best written in-engine and the shader window has a really, really annoying tendency of removing itself once selecting a different node without selecting a different shader. Funny since animation and audio tabs don't show the same behavior (the animation tab stays locked until you select another animation tree, audio behaves similarly).
>so it is easy to get lost in the embedded scenes-within-scenes
My biggest problem with scenes, I can get used to scenes-within-scenes by keeping things on a code level, but nodes tend to be fairly expensive and making things like components isn't the most intuitive in Godot coming from Unity, Unreal or anything similar. If the community was a bit more mature and bigger, someone would've probably figured out best practices to avoid these things rather it looking like a flaw in the system itself.
E.g. imagine I am creating a platformer (for a totally hypothetical example) with a moving platform. There is a bug in the game where the player sometimes drops through the moving platform. In unity I can pause the game when the bug happens and then in the editor I can visually see all of the colliders and so on and quickly work out what is happening (e.g. perhaps the collider for the platform is too short or something and so the player misses it). In Godot it seems there is no way of doing this. Yes I can use the inspector on the remote tree, but this is not easy to visualise the colliders and their overlapping. Add in 3D and it gets even harder. Perhaps I am just missing some button somewhere? Debugging collision issues in Godot is proving to be a real pain in the backside without this feature.
I guess that for Godot it just shells out a new process to run the game and the game is not running in the editor as it appears to be in unity, and that makes it hard to visualise the state in the editor.
The main benefit of Godot 2D is that it is strictly 2D, 2D and 3D are split. If you do things without needing 2D, it will edge out over Unity (UI tends to be better, pains with window sizing etc. tend to be better than Unity). The moment you want any 3D feature, you either do a shoddy hackjob retroactively fitting it into your 2D game, or you rewrite a lot of things to get 3D. Unity's main benefit is everything essentially being a 3D game, and 2D games being hamfisted in a 3D scene, making it so adding the slightest 3D feature is far easier. Simple example, if you wanted to spin sprites a la Paper Mario, you can't just do that in Godot 2D, but you can easily do it in Unity '2D'.
On top, Godot's general lack of community and features still means going beyond a certain level of polish, even in 2D, becomes a bit more annoying. Support for 3rd party plug-ins are limited*. VFX examples are extremely limited. Particles are still fairly barebones in features compared to Unity (Godot 4 is bringing updates to this), and Unity has the added benefit of having a far larger community. In general you'll find similar issues you'd find in Unity, with less history or support to get you out of a bind.
Godot does particularly well in fairly simple games and styles, but the moment you go beyond that scope it's basically a toss-up whether you're better or worse off using Unity right now. That should be changing in the future as more people adopt Godot, but it isn't as cut-and-dry as "2D for Godot is better". Anyone saying that may as well vouch for GameMaker, Ren'py, RPGMaker or something else based on their requirements.
*: Especially art. There are tons of art workflows being popularized now to make art production easier for artists, many coming from Japan. Their support in Unity is already fairly minimal, in Godot it is practically non-existent. I imagine having good plugins for say, Spine 2D, Live2D etc. would help bring over the mobile crowd in particular and cross over to the PC/console markets as indies start trying more than just pixel art.
This sounds really interesting. Could you elaborate?
Unity is big in the mobile market, which in turn has more addons and plugins to support these workflows. Godot can support it without rendering the animation to frame-by-frame, but it doesn't have a universally known plugin yet. Most artists don't look forward to doing the exact same thing in Godot with worse tooling.
When I first clicked over to Spine 2D I assumed it was skeletons for sprites. But it actually looks like skeletons for 3D meshes, which are then exported for use in 2D applications.
This sort of workflow implies to me - a layman - that the 3D modelling part is less onerous than creating a whole bunch of sprite art. Which is surprising.
I used Unity daily for 4 years, both at work (at Hololens and Oculus) and for a few personal projects and indie games, one of which was much more complex than anything I ever did at work. When I first started, I remember this feeling of being unchained and my productivity as a game developer going through the roof. (For the prior 15 years I'd been building directly on top of DirectX.)
When I switched to UE5, I had that same feeling again. Of being let loose or given superpowers. I would not go back for anything. Among many other factors, access to the source code is game-changing and should not by any means be underestimated.
It is great of you know c++, but if you aren’t, Unreal neither offers a scripting language, nor does access to the source code offer any benefit. I’m hopefully waiting the scripting language they announced last year. (Verse?)
But Blueprints are pretty darn amazing. They have subclasses, inheritance, composition, interfaces, public and private variables, functions, enums, events, user-defined structs, network replication, server-only functions, broadcast functions, user interface interaction. You might say to yourself "Yes, but I have a table of 5000 datapoints in Excel I need to work with"; you can put those into a datatable and work with them just fine from Blueprints. You can use the tools to visually edit curves of data, for example for tweaking the effectiveness of some gameplay system like armor or experience or energy consumption. You can write GPU shaders in Blueprints, too, astonishingly easily.
Also the unreal editor is more likely to set my fan spinning in a distressing manner - I appreciate how light unity's editor by comparison in terms of not using many system resources - easy to run on my laptop.
(I worked with UE engine professionally back in the old times, but have never released any personal projects with it, despite having played around with every year or so).
About the engine features, yeah unity has as many ridiculous corners as unreal nowadays - I miss some of the simpler pipelines (the old animation one is better for simple 3D stuff for instance vs the giant state machine...)
Agreed that source code access is great. Unity's tech support used to be pathologically unresponsive. Having source access would've saved me a lot of stress and tears :/ (Thankfully the last time I was working on a unity project they were helpful about reporting status of bug fixes and the like, and actually getting things fixed. So props to unity for fixing that).
That said, most of the documentation and guides assume you're using GDScript or sometimes maybe C#.
Also I would hesitate to call GDScript a weird Python. It shares some of Python's syntax, like significant whitespace, but beyond that it's a completely different beast.
There is an actual Python for Godot project[1] but I don't know how close it is to ready for prime time.
Its a massive, completely unacceptable bug and it was in the engine for years. I lost all faith the the Godot team and will never go back.
https://github.com/godotengine/godot/issues/32383
The thread is a bit messy, but it was eventually fixed in 3.4 it seems.
It's a serious engine problem, and I can understand getting frustrated/put off by it if you have a bad personal experience (and in general I find deleting nodes in Godot to be surprisingly footgun-ish) but from my PoV it did eventually get solved, so that speaks to something. If not in a timely fashion (but given that I've let bug reports on some of my open source projects, including pull requests, dangle for 5/6 years, I'm inclined to be forgiving ).
There were a lot of other issues that made it clear that the developers were not building the engine so they could ship games, they were building the engine for the engines sake.
There is a proposal[0] but it seems to be on hold.
[0]https://github.com/godotengine/godot-proposals/issues/3370
In comparison, Godot was SO much easier to get started with, the UI feels drastically more streamlined and user-friendly.
I'm interested in o3de, but the website needs to list games that have actually shipped on it. As far as I can see, nothing ever has.