In more specific terms: Could a single and skilled user, given enough time, customize Unity 3 to be the same as the current Unity 5? Could someone have created Crysis 1 using Unity 3?
Do not bother considering performance.
For example, no matter how skilled you are, using CryEngine you canât create certain artstyles because it does not allow custom shaders.
Specific examples like custom physics engines, custom renderers and animation systems, and limitations encountered would be good too. I see Jove pushing the engine graphics all the time, but then saying âIf Unity exposed X class, it would make things betterâ.
In short words: how far can you take things with limited access.
Any engine with source code access can make anything possible, mainly because you can always delete the entire codebase and make something from scratch and still say it is the same engine. Unity with source access could even allow you to make Solidworks and Maya. But can Unity without source access allow you to create Solidworks and Maya?
You can do pretty much anything without source access. If you donât want to use the built-in physics, for example, then use something else. It will be harder, since it wouldnât be integrated into the engine, but âharderâ != âimpossibleâ.
Well, sometimes you encounter a bug and⌠you know the rest
As an example, a few months ago, changing PhysicsMaterial2D during runtime didnât work. The values wouldnât update.
If someone deleted the UnityEngine dll /namespace and accurately recreated it in C#, do you think there would be a >20% difference in performance by translating the UnityEngine namespace from C++ to C#?
And in the hypothetical case Unity was using UnrealEngine codebase, what factors would influence the performance difference between both Unity and UnrealEngine? Mono?
Try asking what you CANâT build with Unity. If there is something that you can think of, we would love to hear it. If not, then I believe you know the answer to your question.
One of the biggest parts of game development is finding solutions to limitations. Limits in your tools, game design/needs, platform target and even what you have already built. Most âbugsâ that novices encounter are not bugs, they are usually lack of understanding or simply not part of the tool.
In those cases, and even when there are legit bugs, source isnât really the answer. Most people couldnât do anything useful with the source, and mostly likely would just make things worse by adding new bugs. And more importantly, maintenance becomes a problem when doing updates.
The biggest thing is that when you encounter a bug/limitation in your tool, if you donât have the skills to work around it, or find a different way to solve for it, you definitely donât have the ability work with the engine source.
That was simple to work around though; you just had to disable the object and immediately re-enable it. Bugs that have no work-arounds at all seem pretty rare.
Guess I have to change my mindset from âGuess I have to wait for this to be fixedâ into âGotta find a workaroundâ.
I opened this thread to know how you all managed with âfeatures not yet implemented or brokenâ while I waited for 5.1.3f1 which fixes one of the bugs I am having to download.
Either way, after installing the new update, opening the project and immediately pressing play and having it work the way it was intended, gave me a huge grin.
But I shouldnât get used to that.
Well, I was referring to the bugs that simply felt like a careless overlook, but you are right. It might sound simple in my head but then you go and check and it had nothing to do with the things I was thinking.
Ideas and gameplay, I know anything can be done anything.
I was referring to how far someone that knows what is he doing could push things like the rendering, but I guess I contradicted myself the moment I said to discard performance. Unreal is still having issues matching CryEngine performance even when it can get things to look the same.
I heard someone saying it is useless to implement APEX when Unity could do it themselves at a core level. But this is like the third straight year Unity has been ignoring APEXâŚ
Well, ultimately your mindset should be âdo anything I need to do to ship my projectâ. That means taking and holding as much control of that process as you can. Waiting for other people to fix things does the opposite of that - itâs putting your success in their hands.
By all means order things to get you the best advantage. If youâre confident that thereâs a fix coming and you can re-order your tasks or milestones so that it doesnât slow you down, go for it. Otherwise re-design, re-implement or find âhacksâ to get the job done. Ship it.
Over my years with Unity Iâve rolled my own solutions or integrated 3rd party solutions for pretty much everything aside from rendering and audio playback. The question is, though, what advantages are you getting from using Unity, or any other game engine/framework/toolset? And does this approach help or hinder those advantages? At some stage you could very well reach the point where youâre getting more of the downsides of both using 3rd party tools and rolling your own, without seeing much of the benefits of either. If you need to replace too much Iâd be seriously asking âIs this the right tool for the job in the first place?â
This, this, this!
Unity (or any other tool), is not responsible for shipping my game. I am. If I encounter a legit bug, I have to assume it wonât be fixed. Unityâs priorities may not align with mine. I have solve or find another way to do it.
It is a mindset. I make games. Period. I am not a âunity developerâ or a c# programmer or anything that narrow. Iâll make games and find a way to achieve what I need irrespective of tools. When you approach it that way, it is much easier to keep on track.
Well, I am not the most experienced developer but i have never really understood the need for access to the source code for Indie developers. Isnât it so that the complexity creates a lot of challenges like:
Fixing bugs in the engine you created by modifying
Support from the engine vendor, i guess you are by your self if you touch the engine code
Adjustment to new releases of the engine. I guess when Unity 5 delivered there was some major changes that the developer have to adjust to etc.
Never the less i do understand that there is a level of excitement being able to see and modify the source code for very technical people. I also guess that there are workarounds for the majority, if not all, requirements by coding or 3d-party solutions?
So why would really an indie developer want to modify the source code rather than finding other solutions or adopt to the limitations? âŚwhat are some examples of modifications?
I will say that having discrete parts of unity source available has been useful. I added a bunch of additional functionality to parts of the ui using the source. But it also means that every time we upgrade, I have to verify and rebuild that library. It is isolated to a couple of scripts, so not a huge effort, but much more than that I wouldnât bother, do it in game code instead.
@Frpmta
Iâm sure theoretically there are games that just canât be done without source access. But such games may be so complex they probably donât intersect with the games within the skills of small game developers.
This. Thanks.
Iâm a French people, (English is not my native). Thanks for (Definitely) well writing about this existential question a conclusion that iâm TOTALLY agree with.
For once Iâm going to disagree with you :), with Unity you do get access to some engine sub-systems so you already have âpartialâ source. Plus you can integrate third party components into the engine via plugins, they are going to open source other sub-systems like input etc. as well. If you use CryEngine, you are locked out of a lot of these sub-systems (shaders (DR pipeline) included)âŚ
If youâre happy with Unity out the box then the only thing relevant is bug fixing, if youâre a larger team rolling your own lighting / certain rendering features / middleware integrations / core API extensions and general performance improvements then of course source is a must. Also it allows you to understand to some extent how the engine is put together, so if there is specific bottlenecks or bugs you can fix themâŚ
Some advanced rendering features can be implemented already, although itâs messy and not very performance efficient.
I donât believe open source as a public branch could be done in Unity because of the way it is, itâs not like you can make tons of positive changes and extend core toolsets then push it into a master branch like UE where they approve it and add / support it so itâs compatible with future releases (mainly due to middleware).
Also there isnât anything like a middleware branch (like Nvidiaâs) version thatâs updated and supported. If Nvidia could of done it with Unity Iâm pretty sure they would of doneâŚ
I believe that if you you are in the situation where you are rolling your own lighting/rendering/etc, you probably arenât using Unity in the first place. (or if you are, you should look at other options).
My take on it, in general, is that Unity is a solid solution for like 95% or more of all games. And by games I mean, for reals shipping games, not noobs who just downloaded it and are upset by lack of volumetric particles or whatever. AAA console devs have requirements and needs that donât always align with Unity, and I think that for Unity to chase that market would be a little futile. Mostly because in that space fragmentation is much larger. While engines like UE are capable of that, there isnât much dominance in that space anymore. UE is just one of the AAA engines, and not even the big dog anymore. But the bulk of games, that are driven by gameplay, Unity is a good fit.
Unity is great if you are shipping games, and less interested in breaking new tech. Though, I will say that what is visually possible with Unity is pretty amazing, even with the limitations of a mobile platform. And while I canât prove that statement and the moment, in the next few months we have 2 games coming out that will illustrate that point.
We had the source for Unity for a year or so, and we donât anymore. It was very difficult to keep in sync. We now rely heavily on support. If we need to know exactly how things are working under the hood or details like that, we just call up Unity and talk to an engineer. Much faster than dealing with the source. But our focus is on gameplay, art and shipping games, and on mobile. For our AAA console games, they are almost all in house engines, or things like Frostbite.
So, I donât disagree at all. I just believe that from a practical sense those who legitimately, realistically need full source code access for technical reasons, probably arenât using Unity. And that most of those people who claim they need it, donât really know enough to use it properly in the first place.
