Well, actually, small studios and solo indie developers rarely have both resources and the knowledge to make a game engine on their own. Imagine two devs of average knowledge and same, limited resources starting off at the same point in time, with a goal to ship a game.
Guy A has 5% more money at his disposal, but has to write his own engine from scratch. From true scratch, figuring out how to draw a triangle in 3D space first, etc… Keep in mind we are assuming average knowledge and skill. So let’s be generous and give him two years to get to something you can build a game in, it likely still won’t be anywhere near UE4 in terms of graphical capabilities. By the end of those two years, Guy B is already shipping his UE4 based game while Guy A hasn’t even started with a game yet, just finishing the engine. We also considered limited resources. So if the resources covered 2 years of expenses, Guy A would be pretty much screwed.
While making your own engine as a solo indie developer or small team is not impossible, it sure as hell isn’t competitive when there are powerful engines already at your disposal. Unless you are making something extremely small and extremely specific/unique.
Also, you’ve said Unreal lacks graphically behind its competitors nowadays. Can you post any example of a production ready game engine (not just some realtime tech demo) that’s better than UE4 in terms of overall graphical capabilities? Cause Unity certainly ain’t it.
Well, actually ;)… It was at one point rather common, engines used to cost anywhere upwards of $250K+ so the only real option was tacking together libs and DIY or XNA etc. I put together a 3D framework and it was surprising how many people reached out on the Unity forums with their own projects. IF you’re not trying to be everything to everyone like most modern game engines are then it’s possible IF you have decent development experience. Still it does tack three years onto a project (at least) hence why many don’t even bother…! But that only really matters to those starting out that never developed a framework in the first place.
As I said, nobody makes things from “scratch” not even Epic or Unity, there’s plenty of open source libs and as I already said there’s plenty of MIT engines with examples of PBR shaders, global illumination examples, reflection probes, post effects etc. etc. I believe Unity’s real time area lights might have been based off an open source project. I never said you didn’t need some money to follow this approach (covering expenses etc.) but you still have an engine you know, understand, is performant etc. etc. like I already said.!!
Agree to disagree on that one and I’d love Enlighten in UE4, maybe one day they’ll do an “indie” friendly subscription.! One can only hope.
In your previous post, you were agreeing with statement that UE4 should not be marketed as a tool for indie developers and small studios. That’s why I am trying to dispute here. Unless you have at the very least half a decade of very successful game development programming experience behind you, making your own engine with serious intention is simply not an option. Same applies if you don’t possess enough resources to secure your expenses for several years in advance. These circumstances are often quite common for indie developers, small studios and beginners.
I think you may have different definition of a proper developer. Game development has been so democratized past few years, especially thanks to high level solutions like Unreal or Unity, that these days, you can easily finish a less complex game without any experience with framework development at all. Many of such people are indie developers and even form small studios. If you extend the definition of “small studios and indie developers” to contain these people as well, then the statement that “the biggest mistake Epic made was advertise UE4 as an engine that small studios or indie developers can work on” is simply a nonsense. In fact is quite contrary; When it comes to a chance for an average indie dev to get the game done, especially with limited resources, then there is nothing better on the market than UE4. It’s the most complete solution out there.
The fact it always wasn’t that way has no relevance whatsoever, since we are not talking about the past, but about the present.
And mentioning lack of realtime GI as a proof UE4 is behind its competitors does not make sense either. Realtime GI will mainly add flexibility, rather than quality. But even though UE4 lacks realtime GI solution, overall it’s still superior to any other game engines out there available to wide public. You may get Enlighten in something like Unity, but at the expense of lacking other, equally as important features, which when add up, will have a lot more significant negative impact on the resulting visual quality of your games. You have explicitly written “lacks graphically compared to it’s competitors nowadays”, so agreeing to disagree won’t cut it. I’d like to see example of those mentioned competitors. Also keep in mind you’ve formulated it in a way which implies overall graphics capabilities rather than dynamic GI specifically.
To summarize, claiming, or supporting the claim, that it is a mistake to market UE4 as suitable for indie devs and small studios does not make any sense. UE4 is, by the way it was designed, the most indie and small dev friendly engine out there, so if UE4 is not considered indie and small studio friendly, then by those standards, nothing is.
I’m not sure if you’re just being confrontational for the sake of it or you’re not reading my posts right? I said teams of less than ten (probably more) will use something like Unity.! Because it is far simpler and efficient in nearly every conceivable way for small projects, even if that involves the community (like asset store packs). It’s a waste of time for beginners I’ll agree, although one does learn a lot from the subject, handy for progressing to engines like UE4 and more intricate projects.
I expanded the scenario to include large outfits with dedicated specialists (again read my post). The original poster mentioned small indies only.!
I fully understand the skill level required to publish a game has dramatically dropped over the years but that’s made things worse, unless you’re satisfied with releasing a buggy **** shoot of a game then you’re going to have to roll up them sleeves and get dirty. I’ve got twenty years under my belt and I still find UE4 convoluted, I’ve messed around fixing so many issues it’s not funny from cooking to crashes, issues with shadows, tessellation and all the rest of the stuff they forgot whilst moving on to their next shiny feature set.
I don’t think UE4 is anywhere approaching simple (sometimes for no reason), even grasping terminology is several leaps above Unity for basic tasks. Just because UE4 is obfuscated with a game framework and blueprints it doesn’t mean projects with a bit of meat to them are straight forward comparatively to other engines. This is coming from someone who built frameworks, developed in Torque and CryEngine (which are notoriously difficult to use).
I’d agree with the analysis this engine wasn’t made for small developers or beginners, I’m not saying it’s a nightmare like CryEngine was but it does feel to me every bit like a clunky AAA engine.
That’s just your opinion and it makes perfect sense, from use and practical application of Unity I KNOW you can reach the level of their book of the dead with Enlighten and I’ve NEVER seen anything of that quality come out of UE4 bar overly specc’d lightmass examples that in real time games are NO WHERE near practical using lightmaps. Again I’ve not a clue why you think it’s the most small dev friendly engine out there? I
I can only guess you’ve engaged in tiny projects with UE? Whereas I’m an RPG and MMO down so far, I will give kudos because if it wasn’t for Unreal that MMO project would never have seen the light of day, in Unity 4 the performance was dire and without 64-bit support the editor constantly crashed but Unity has come a long way.
I’ve read your posts quite carefully, and in fact, judging from the tone (and the amount of exclamation marks), your posts seem to be more confrontational than mine
This last post kind of explains it a bit. Why would you think that lowering the skill entry barrier has made things worse? If they release “a buggy **** shoot of a game” then they are not your competition in the first place, especially with “twenty years under your belt”.
I don’t dispute that UE wasn’t originally made for small developers, but that doesn’t change anything on the fact it’s by far one of the best choices they have these days.
Furthermore, I did read your posts, again, carefully. The statement that you’d “extend that to any sized development outfit” implies that you not only think usage of UE4 is problematic for everyone making anything more complex than a Tappy Bird type of game when it comes to small and indie developers, but also for development teams of any scale. That’d pretty much mean UE4 just sucks for everyone I just can not agree with that.
Sure Unity has significant advantage when it comes to being way more of a blank slate, compared to Unreal’s relatively rigid predetermined gameplay framework, but UE4 more than makes up for it in other areas. When you get to the daily bread and butter tasks, it’s easy to appreciate essential things like being able to use material shading graphs on terrain (A thing Unity still can’t do even with HDRP).
On top of that, as I said, I don’t disagree that dynamic GI is a great advantage, but again, as I mentioned, dynamic GI won’t save you if other parts of rendering pipeline fall behind significantly. To give you a non abstract, real example, here’s a one of Homeworld: Deserts of Kharak release trailers. An AAA RTS made with Unity:
Throughout the video, on quite a few places, especially around 0:30 time mark you can see one very disturbing artifact, completely detrimental to the resulting visual realism of the game - the transparent particle sprites do not receive any shadows. Originally, I though some of their artists just sucked, but it did not take long to learn that at the time, Unity’s rendering pipeline was so primitive it could not even handle particle shadowing, and making it work was so complex that even AAA studio backed by Gearbox wasn’t up to tackling that problem. These days, SRP/HDRP in Unity solves this problem, but HDRP especially is still nowhere near the production ready state.
This is a clear example of grass not always being greener on the other side.
To your next Book of the Dead argument. Being in the CG Generalist past 9 years, I have some connections which allowed me to learn (from the sources at the studio which produced the short) that the framerate it rendered at was nowhere near interactive, let alone realtime. I also fail to see anything in that short UE4 could not handle. What I can see, on the other hand, is visually stunning Paragon running at a completely interactive framerates. Framerates you could ship the game with, not just make a nice cinematic.
Look, I really am not looking for any further confrontation. The reason I hanging to this inflammatory conversation is that I just don’t think it’s fair to said that it is a mistake to advertise UE4 to small indie developers, let alone a “biggest” one. I am one of them, and for me UE4 is actually what allowed me to get into games in the first place. If you are an elitist, then sure, there are some issues to get over, but there will always be some, regardless of the engine.
It’s also important to keep in mind that small indie developers will also usually not choose to make a game of such a technical complexity it will require “a lot of knowledge of its inner workings and a lot of dedicated staff to maintain your codebase”. It probably will, but only if you choose to do Enterprise scale game. If you want to succeed as a small indie developer, you’ll likely decide to produce a project of a small, indie scale. UE4 will work for that, so there’s nothing false about Epic’s marketing of it in this direction. I hope I am being clear now
Let’s put it this way if I thought Unity was the king of all I wouldn’t be here right now :). Sorry if I misinterpreted some of your statements, whilst I think I may be coming across a little bit harsh on Epic as I agree it is one of the top products it appears long term they need to decide whether to listen, commit or go the way of CryEngine. Unity’s strengths doesn’t lay in their blank state methodology, quite the opposite. Getting off the ground with BP’s using their game framework is soooo much more efficient than a 1000 lines of code for a character controller and camera system.
It’s when you get to all the side bits, like event management, editor toolsets, database integrations, co-routines, finite state machines etc. etc. which I’ve had to do in UE but it was breeze in Unity.! There’s rigidity in UE’s approaches and bypassing it can be very painful, also with Unity you don’t care about bugs because there’s nothing you can do about it :). Although for the most part Unity is far more stable. There’s a lot of basic things in Unity like the prefab system that just makes life that much easier, never mind the black box C++ API… For the most part you can get by with guessing in Unity due to it’s WYISWYG component scripting style for near enough any purpose.
Beginners want simplicity, I want time and flexibility which can be one and the same.
Still, again I’d be very hesitant to start a major project in it.! Umbra is static and not really applicable to decent sized projects in this day and age, it’s mesh rendering pipeline up until scriptable HDRP has been dire, the terrain system has been rubbish for years and only just got an update. The Navmesh system whilst much easier to use than Unreal’s is sporadic, heavy and not too smart. The profiler is useless in editor, it’s animation system is older than the frameworks I used a decade ago and it has to be the most bare bones “major” engine I’ve come across.! You only recently got deferred decals??!
Finally a lot of their implementations aren’t very well thought out, it seems more like a consensus of ideas rather than a battle tested implementation as a necessity when making products. Like everything it’s very project dependant, there of course has been many hit games come out of Unity. Although I did notice a lot of the issues I came across in Pillars of Eternity. It ends up with a lot of workarounds, asset store reaching and dedication… Although that’s the biggest pro for Unity, it’s massive community.
Sorry but who cares if it’s “fair or not”? It’s a toolset and whilst it’s a good toolset people are worried that Epic have lost investment and it could effect their eco-system, which is speculation but seen as minor problems are taking years to fix it’s hard to argue otherwise. Performance wise it’s just a matter of time before engine X sorts something out, Unreal used to have dire performance with foliage and translucent materials which most DR’s do but that’s not the case anymore and Unity will sort that as well (eventually).
I don’t see the issue with increasing workflow efficiency / reducing complexity or squashing bugs so we can focus on our products. Unity did this exact same thing years ago, bar it’s scripting infrastructure trying to do anything of decent scale was too much of a headache to entertain. With Sweeney asking about scripting etc. it’s possible this conversation is for naught but like any engine there’s a lot that can be improved and all I’m trying to say is in it’s current state I’d recommend Unity for small dev’s and beginners over UE and I might entertain the idea of a custom engine (probably not but we’ll see).
It’s fine to have a difference of opinion, in fact it’s great because usually we start from two perspectives and find the route issues somewhere at the end.
The graphical gap I believe is closed now between UE4 and Unity, my issues with UE4 is functionality. Right now it seems to me that UE is built with specific games in mind, if you want to move away to another direction then you will face problems. The more stylized the game goes the more troubles one seems to face in UE.
Simple issue, we are still working very hard to find ways to fake shadows in UE4 notably with Forward renderer! In unity there are ten simple plugs I could buy off the shelf that I wish I had in UE and if I can’t buy in Unity I can make one work in C# since the engine will render it. Shadows that are performant look better than the standard ones and “faked” which works best for specific games but there is no way to do it without writing your own in C++ and messing with the source code, and even then it may or may not work.
I hardly see any objective correlation with this info. Entering BBB you see lots of complaints of people who got banned accounts on Fortnite for cheating, having Fortnite account stolen, game purchases they never did… aroung 250+ complaints between millions of players, no engine related complaints, so pointless observation on that F rating.
I do have to agree that newcomer support is an issue. I compared UE4 and Unity back and forth, and decided to go with Unreal for many reasons, but many of my questions on forums rarely got answered.
I’d categorize questions into 3 groups:
1, Trivial questions about basics clear answers to which can easily be found in the documentation or Google in case they’re very frequent.
2, Common questions about relatively uncommon, not too complex problems, to which an answer can’t easily be found.
3, Very tough advanced questions about complex technical problems.
From my observation, #1 and #3 each make up about 5% of the questions, amounting to about 10% total, while #2 makes up for about 90%. And #2 questions almost never get answered. They are not complex/interesting enough for experts to waste their time on, and they are beyond the capabilities of other beginners to help with.
I’ve simply accepted that if I go the UE4 route, I will be all alone, by myself, with mostly no help from the others. UE4 is **that **good for my use case, compared to Unity, that I am willing to go that route. To scavenge bits and pieces already existing knowledge on the internet for answers, and if there are none, just keep trial and error until I found workaround or rarely even a solution.
I’d be much happier if that wasn’t the case though. Right now, as it stands, unless one does have interesting and advanced enough questions to bring to the forums, getting answers is very rare.
BBB is as much trustworthy as complaints there are legit. Again, there you can only see Fortnite complaints and not Unreal Engine complaints. You can’t judge an entire organization based on complaints for a single product. Unreal Engine is FREE to use, but if you earn money with it you should pay Epic what is due, if you want professional support from Epic as any other company out there you need to pay for it, nobody works for free.
Now if you really think Epic is somehow to blame, instead of doing it on open forums, write a complaint letter, send an e-mail to the commercial department, just do it properly. I have tracked your posts and it seem you are having issues nobody else is reporting or if there is someone having it, they properly sent crash reports, filled bug report forms, and they are waiting for an analysis and the proper hotfix to arrive, and you can also pick an engine release which is more stable like 4.17 or 4.18, unless there is any feature present in 4.20 or 4.21 you need most and those other releases more stable will not fit to you.
Fortnite is not Stylized in the sense i meant. I am speaking of cases where sometimes you don’t even use a single realtime light in the engine but still make it look like its fully lit in real time and have to fake everything similar to a 2d game while still keeping/faking visual fidelity, performance and art direction in a 3d world.
Fortnite is a skin job over whatever UE offers out of the box, the thing looks like it can run on mobile, wait it is already running on mobile… : )
What you are describing is something that will probably require to bend any PBR based realtime renderer pretty hard. But I don’t understand how Unity or any other game engine would be better in this regard? They are also converging mainly to PBR workflows, so heavy stylization will require equal amount of bending. With that being said, I feel like UE4 material editor offers you a way more tools to do that bending with, without having to write them completely from the scratch on low level, which you could again do equally as well in UE4 as in other engines, but UE4 at least gives you a choice.
Unity was built on forward rendering tech from the start and with C# it has much more control over how things are implemented low level.
UE4 material helps very little if any when the base core is not meant to run certain things in a certain way:
I will give you a small example:
Make Modulate Decals run in Forward rendering in UE4 if you can. Something similar would be taken for granted in Unity. In other words there is no way to leave decal explosions on the ground when you are developing for VR or using the Forward rendering mode or shadows or anything else for that matter unless you create a massive workaround.
That’s one small example.
PBR workflow is overrated in the real world in my humble opinion and applies to certain games but fails in others. You need to solve the TAA problem first to make it at least accessible for anything other than a third person or a first person shooter. Not even speaking of performance.
I agree that forward renderer limitations are a problem, but unless you are after a very specific heavy stylized + VR combo, deferred renderer is much better choice in terms of flexibility. That being said, lack of decals in forward renderer is an issue. I agree with that too.
Also, PBR workflow is not overrated. PBR workflow is basis for getting good looking results, stylized or not. PBR workflow transformed VFX world (of which I’ve been a part past 9 years) and it’s in the middle of transforming games world as well.
I am not sure we are talking about the same thing though, as TAA is completely unrelated to PBR. PBR is about people not doing 90’s ********, like tweaking specular highlights intensity independently of the light source intensity, faking indirect lighting with ambient light (which unfortunately game engines still have to do), mapping material with specular reflection maps rather than roughness maps, not knowing how exposure works, breaking energy conservation, like changing GI intensity multiplier, going over 0.9 or even 1.0 in albedo, etc…
TAA on the other hand is just antialiasing method. A means of reducing the obvious jagged edges due to insufficient display resolution which allows human eye to distinguish individual pixel. TAA does not affect light transport or material shading functions in any significant way. PBR, as in Physically Based Rendering, concerns mainly light transport, response of surface shading to light, response of volumetric shading to light, and to a certain degree postprocessing image transformations (filmic tone mapping for example).
It’s not about some physical/mathematical accuracy, it’s mainly about what looks natural to human eye. Vast majority of even heavily stylized games will look much better when their artists adhere to PBR standards.
I didn’t mean to mix up PBR and TAA, I understand them both very well. In regards to TAA as it stands has many issues for games other than the specific types it is intended for.
For instance having a strategy game which displays small units onscreen with far off camera viewpoint will have TAA completely blur everything out and at this point it doesn’t matter if you are using PBR or even raytracing should you wish to, the game will look bad or bizarre. Similarly t VFX and particles like small explosions etc. would lose all detail. Which is why they all resort to MSAA which means you are forced to use FR which also translates to Epic’s limited implementation of it as I mentioned above.
Regarding PBR. What I meant is that in order to take full advantage of it you also need to take into consideration the entire workflow of PBR with lighting shadows heavy material workflow and so on and do far less faking and cheating. This puts lots of limitations when it comes to certain types of games that need to run at a performance while still looking good also to be specifically well art directed. Which is why many games simply use “unlit” materials and lots of pre-baked lights and specular reflections.
To ignore this side of the workflow and move towards just PBR in an age where you still don’t have the hardware to run everything as intended is prematurely neglecting one way of doing things for another.
When PBR first came to VFX we were thrilled because it made sense and we didn’t care if we were to wait hours for a frame to render to get the result even if hardware was not fully capable. We simply do not have that luxury in video games nor do we have all the bells and whistles of an offline PBR workflow in a realtime one.
