🔒 Unity's Capabilities and Limits

1 Guest is here.
66409041d3df9
HikariQuote
I dunno, tribes vengeance ran pretty decent on my box before I got the GT720, but that was basically the best it could do and even then there were issues. Mostly it was the fact integraded only had 1.1 shaders instead of the 2.0 most things expect and or 3.0 some things are starting to need.
66409041d3f64
ZylonBaneQuote
Given that the original System Shock's environments were designed to be within the capabilities of a slow, primitive software renderer, I don't think Unity will have much trouble with it. It's not like we'll be looking down on a city from the top of a mountain or anything.
66409041d41a2
JosiahJackQuote
Unity is actually very capable.  It simply has many pitfalls in use as would any engine.  Unity's strength is it's immense flexibility.  Because of that you are flexible to the point of doing things in a way that might be slow, poor performance, etc. but only at the developer's fault for not considering how Unity handles garbage collection, GetComponent calls, deferred vs forward rendering, etc.

As an example of a good FPS game that has a complex UI and inventory system, please take a look at 7 Days to Die.  It uses a voxel based world, which has thousands of gameobjects comprising the world blocks, not to mention the hundreds of trees, buildings, zombies, etc.

I for one have had plenty of issues with Unity as a learning experience after switching to it for Citadel.  I tried treating it like the Source engine, expecting to have a lot of builtin functionality out of the box, but because of Unity's flexibility it unfortunately expects you to do everything from scratch or buy prefabs from the asset store.  I actually prefer doing it from scratch as I can have complete control over things like player physics, friction to stop player walking vs running, etc.--plus I can learn how Unity works.

All in all, it has a difficult learning curve, but is actually not so bad once you figure out its quirks, ins and outs, and what best practices to follow.  I highly recommend Night Dive to NOT switch engines.  I know firsthand what the impact is.
66409041d4335
Producer_chrisQuote
so no idea what engine we would be using.
But, we did pick Unity for Underworld for a reason. Doing the kind of gameplay we speicalize in it just made far more sense. Making something 'real' in Unity --i.e. not scripted..is far easier than say Unreal. With the new lighting engine in 5 they are getting close to Unreal in looks. But its not about the looks is it.

Here is an example of what we like about Unity. Tim builds a trap. It uses 'springs'. It has gears. Now, in other games you would have to add scripting for diabling the trap, it can get complicated...and frankly developers then say screw it and stop placing traps because they are a pain in the ass.
Our trap is just a prefab, it works. You can disarm it, bash it with a rock, stop the gears somehow exc. Because it has all those properties already. Since it is part of the physical world, all our physical rules automagically apply. Honestly the first time we did this with a trap we all had that look of..why doesn't everyone do it this way? Now you can do all of the above in any engine. But the simplicity of doing it in unity compared to a blueprint in Unreal or worse diving under the covers into C like the old days is far more time consuming. So for us, living with the limitations that Unity has- and it does have them, was worth it for the modularity of the systems design.
66409041d4908
RocketManQuote

Quote by Producer_chris:
Making something 'real' in Unity --i.e. not scripted..is far easier than say Unreal.

Har har har ....  :awesome:

Legal stuff

Privacy Policy & Terms of Service Contact