Can you really create any game in Unity without source access?

This is not the question you might be thinking.

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".

--Eric

 

You can still delete the entire engine and write your own from scratch. You can also choose to ignore most built in subsystems and write your own.

99.9 % of games would not benefit from having engine source code access.

 

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?

 

Lol. If a triangle was a circle would it still have three sides?

I see no value in this discussion. But @Tomnnn might have valuable insights.

 

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.

 

How many developers are going to be capable of fixing a bug in a complex game engine?

 

No, not really. (practically speaking)

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.

--Eric

 

There, fixed it for you.

 

Thanks for the invite. I don't have much to contribute here except to say eat your strings and vegetables!

Depends on how far you can go with C#. I've used Unity for nothing more than its cross platform 3D rendering before.

 

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.

But we shouldn't also get used to stacking workarounds because I only assumed it was broken after reading the previous 'undocumented workaround' and assuming we had reached the amount of workarounds limit :
http://forum.unity3d.com/threads/undocumented-things-about-physic-materials.63728/

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:

1) Fixing bugs in the engine you created by modifying
2) Support from the engine vendor, i guess you are by your self if you touch the engine code
3) 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..

 

Wouldn't be the first time.

I agree, check out my third post.

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.

 

Once a community member finds a fix for a bug, they can let others know how to fix it right away. So you don't need to be the most knowledgeable developer to benefit from open source.

 

Yeah, we've talked about this idea before. The general consensus from anyone that's worked on an open source project is community fixes get tangled up into a mess of both code and features. Blender is a commonly cited examples. The project is free, its open source, its got a lot of community fixes and engagement. That hasn't made it objectively better then other proprietary software that does the same job.

 

I would also add that while Unity is a general purpose engine, different folks have different needs and uses. While I may want more mobile optimizations, someone else may want more things related to more graphic capabilities on high end video cards. Would my changes limit theirs? Would theirs break my builds? Unity as the gatekeeper balances those things for the user base as a whole. That is both the good and bad with Unity. It could be better on any individual platform in isolation , but instead it is a universal engine. It's trade off, but also a great value.

I think that community modifications would just lead to frustration for people who make changes that aren't accepted into the base. And also for those who get deep into it and have to constantly merge into official releases. My guess is that it would lead to a lot of noise, and be a time suck on the part of unity. I doubt contributions will be much in the way of bug fixes, and more about tailoring to specific needs.

Though again, I do like the more focused opening of source like the ui. It is narrow in scope and doesn't require compiling of the whole engine.

 

Well, I didn't claim that open source alternatives are better than proprietary ones. My point still stands that you don't have to know the source code to benefit from it being open source.

 

And my point is that open source isn't actually that much of a benefit, and may be a hindrance.

If open source was the cure all for software that many people make it out to be, proprietary software would have died out years ago.

That said, you are always welcome to try an open source game engine if it meets your needs better then Unity.

 

This. Even though we can do it, we're always hesitant to modify the source of any library that's still actively maintained. It's not just a question of "can we make this change now?", but also "are we willing to pay the cost of maintaining this change for every future update as long as we're still using this library?"

 

@zombiegorilla what's the heaviest part of the unity engine that you have if you don't make use of it? In a blank project, would the only big killer be the game loop? I mention sometimes that I like unity for being a cross platform 3D rendering engine that makes it easy to interact with things... is that a valid use for it without being overkill?

 

Edit: Let me try to make more sense .

I don't believe Unity is a good fit for 95% of games, far from. It's a good fit for small indies, targeting smaller games, which there are of course far more of those than pretty much anything else. For teams (whether big or small) aiming for fiscal return outside of the mobile segment then not so much.. Which is a massive market fiscally, but in terms of companies aiming in that segment it's a bit of a niche..

Graphics is one thing, performance is another. I don't really class "mobile" games in the graphics segment, whilst they can look good it's a market that still won't require top tier stuff for a long time to come. Some basic modern day PC / Console use cases aren't included in Unity as of the moment. Ironic we talk about graphics and Disney, as they pretty much paved the way in a lot of cases in how it should be done ..

Vet's using unity to add specific resources or toolsets would be able to do it much cleaner in source. Secondly, it's not about AAA.. Before the days of pre-built powerhouses we used XNA frameworks and libs to build our own frameworks, it was a common thing even for single developers. Sure it was a massive time suck and now it's a waste of time, but the point being most could and still can..

Sure engines are far more complicated today, but the core concepts remain the same and you only need to know what you need to know to achieve tasks for your specific game. It's pretty much impossible to learn how the engine works end to end, but that doesn't stop modification.

A lot of it comes down to how the engine is designed, UE4 was being drafted out nearly a decade ago by good old Tim to be a modular designed network with minimal dependency. To get around a lot of common issues..

I've never seen Unity source code, but from what I've heard Unity isn't a candidate for open source due to the way it is. Not necessarily a bad thing, but source is a handy toolset to have just like any other.

Thing is, I'm not sure what the limitations of Unity actually are in all areas and it'd take a long time to find out and hitting walls (potentially). So it's easier and less time consuming, just not to try it.

@angrypenguin

As said, committing fixes and updates to a vendor approved master branch helps remove this issue.