What kind of games would not be best for Unity?

I'm looking at some modern games and usually I can guess which ones have definitely not been made in Unity. These are usually these are procedural ones like:

Minecraft
No Man's Sky

Or games with infinite landscapes. I'm sure games like Fez and lots of indie games can be made with it. They might run slightly faster in their own game engine, but with the power of computers today that isn't a issue. I was surprised that Broforce was made in Unity since that it has a destructible landscape but I guess that's just a simple 2D game.

A game like Doom or Quake would run faster in its own game engine since the culling is optimized for tunnel based games. But could be made in Unity because computers are faster these days so they don't have to be overly optimized.

Also ones with strange landscapes that go beyond Unity's terrain features probably have their own game engine.

 

All of what you named can be easily made in Unity. In fact, a partner and I made Minecraft in Unity a few years back as a hobby project. No fighting against Unity, just didn't use a ton of it.

 

I think your definition of "easy" may be different from everyone elses!
Also, was your version of Minecraft as fast as could be done with doing it from scratch?

 

That's all hypothetical really. If developer A uses unity and makes a fantastic game, with very high quality, efficient code, it'll probably be all good and well.

If said developer A also decides to recreate said game using nothing but original code, as in a renderer, physics engine, sound engine, lighting system, so on and so forth... that game might just suck. It might not be nearly as fast because it doesn't have a huge team of experts writing those systems, and even though developer A rocks when he uses unity, he might not be so good at developing a game engine...

Consider the flip side as well... if developer B did the opposite, and wrote from scratch a game engine specifically tailored to his game idea, and did it efficiently and knew what he was doing, it might be a great game. Then when it becomes somewhat successful perhaps he wants to target more platforms, and decides to recreate it within unity. Then some of the techniques that he used to make things more efficient might not work so well within unity, or just plain won't work without access to source code. In this case maybe the unity version would suck.

What I'm saying is, you can paint on the tried and true canvas many people use, or you could get better at working with wood and glue and create your very own canvas - but how good of an artist are you? Do you think you can make a quality canvas? Sure you could make it the exact dimensions you need, use the exact type of material for the surface to help your paint stay good and not drip... but ultimately it is about having not only the canvas and the paint, whether you made it or not, it's about whether or not you approach painting right. How refined is your technique?

Ok so bearing that in mind, unity is right for a lot of game types, and custom built engines could be right for lots of game types too, so choose the tool that fits you best, and meets your needs and expectations, but perhaps most importantly also fits your ability!

 

Yes, an engine designed *perfectly suited* for the job would in theory be faster. Minecraft runs in its own engine, but was considerably slower than the version we built two years ago in Unity. Not sure what that says about Mojang. Luckily for us, Unity is moduralized enough to have an extremely low overhead on bit you don't need. So really, Unity did the low level work we needed, and we turned everything else off. Did our own lighting, some form of "culling", manually handled all the voxel and chunk data, and only used Unity as a glorified platform rendering interface.

 

Unity can do all these games including no man's sky and minecraft, and frequently has done games like those. Look at kerbal or rust.

So yeah, Unity can do it fine. At what quality level is an entirely new question though.

 

I heard No Man's Sky used a modified version of Unity. Not quite sure though.
But yeah, pretty much any of those game can be done in Unity if you don't abuse drawcalls.

 

Actually, unity is quite suitable for making minecraft clone and procedural geometry games.

While Fez would be the best using custom engine.

Doom and Quake are not "Tunnel based".
For example:
http://vignette2.wikia.nocookie.net/doom/images/2/2e/E1M7dots.png/revision/latest?cb=20070128082129

However, unity in general is not suitable for a game with high visual fidelity or where you get to see object close. It is a bad fit for realistic 1st/3rd person games due to the lack of proper mixed mode lighting (which unity stubbornly keeps ignoring).

The engine is most suitable for cartoon, stylyzed, low-poly or 2d games.

 

Don't attempt an MMO.

I'm lookin at you, noobies.

 

Minecraft was reverse engineered and duplicated quite easily in Unity.

http://forum.unity3d.com/threads/after-playing-minecraft.63149/

There are even assets you can purchase to handle the more difficult aspects for you like IronVoxel.

http://www.ironvoxel.com/

Worlds Adrift is Unity with SpatialOS for the backend. It's supposedly endless too.

https://www.worldsadrift.com/
http://www.wired.co.uk/news/archive/2015-11/12/improbable-spatialos-simulated-cities

 

Hmm... OK. I submit.

 

No Man's Sky would be a nice piece for Unity's portfolio.

 

Unity allows easy modification of geometry at runtime, it has object layers, spawning stuff is easy. Also, you can easily insert something like raytraced or procedural primitives via shader system.

So it is a good fit for procedural games. (even thought it might not be the most performant option).

For "realistic" and high-fidelity graphics, though, you'll have mixed-mode lighting problem.

 

I guess if you wanted to make the ultimate cereal simulator.

 

Coming to Unity in a decade.

 

There are some games that fall out of Unity's scope. It would suck for tabletop games. It also sucks for sports.

Really anything that requires physically touching playing pieces or other players is out of Unity's league.

This may change with future generations of VR tech.

 

There's nothing in Fez that couldn't be easily replicated in Unity.

 

Collision and movement.
You would need to ditch unity's built in system and write your own.

In fez 2 dimensional shape of 3 dimensional object is used for collision detection and depth component is ignored.

Code (csharp):

1.  
2. |....
3. |.A..
4. |....
5. |.BC.
6. +----
7.  

^^^ This is a level view from above. "." designate empty space.
Player is standing at "A".
While the game is rotated to see "A. B", player cannot walk from A to B.
However if you turn the scene (so you see "BC"), then player can walk from A to C in one step.
Because A and B are treated as the same space.

Yeah, I can write that.

But "easily" is something that a newbie can write in a half of a day. And ye average newbie is very likely to have trouble with this.

 

When the perspective changes in Fez, the player is locked in space and the world rotates around them. Because of this, we can disregard 3D collisions entirely and instead have everything take place in a 2D collision system. Assume each block is located in a 3D grid and pre-generate 2D colliders that you switch between when you change perspective. There are a few outlier situations you'd need to solve for (climbing vines and switching perspective/other situations where you rotate to be behind an object) but it's a lot less complicated than it seems at first.

 

One series of games that I've wondered if Unity could handle is the Total War franchise. I could imagine a lot of low-level optimizations in those games to get them as performant as possible, that may not necessarily be available to Unity. Even with the native interface, and the lowest possible level of shader programming in Unity. If anyone thinks it would be possible, I'd like to read details on how to do those optimizations.

 

https://unity3d.com/showcase/case-stories/creative-assembly-total-war

While not quite the same scale, you did ask

 

Golem Arcana would beg to differ!

 

Might be the best use case for unity.

Isn't tabletop simulator unity?

 

Nope. This is not how FEZ worked. Try the game and pay a bit more attention to it.

It is a fairly simple thing for me, but it is not simple enough to put it into "easily" category.

 

Table top simulator is a pretty poor substitute for the real thing.

There are always exceptions. I haven't yet played the game myself, its on my to try list. But all of the other digitally enhanced board games I've played have fallen fairly flat.

 

Hey! I did this as a tech demo also! I was able to get it running by using SkinnedMeshs as regiments. Each unit(a sub mesh) was animated by my own very elementary implementation of a custom lightweight animation system. It worked pretty damn well. All AI logic ran in a separate thread to free up the main thread as a simple interface to Unity(this was still the bottleneck). If I approached it now, I'd probably work more with Compute shaders to run the bones and try to keep as much as possible on the GPU.

My unit count was comparable with total wars, and the AI wasn't a complete baboon. So I'd say that Unity *could* do it. But I'm not convinced you *should*. I did these projects back when I got into this "let's push Unity and find its breaking point" fad.

In other words, soon.

 

I've enjoyed a few different games on tabletop simulator so far. I guess I'm super biased when tech is involved in something as simple as board games.

 

It's at least a custom animation system and PhysX is probably not going to have many uses. That is a case where the shear volume of data being continuously pushed around probably benefits a lot from a custom engine.

Otherwise, you could probably convince me that Unity isn't a good fit for games involving a lot of asset streaming (either because of loading spikes or not freeing memory well enough). It's the only thing I can think of where you're at the mercy of Unity to handle.

 

What? Where did you read that?

 

I dunno. There is absolutely no mention of it on the wiki page. https://en.wikipedia.org/wiki/No_Man's_Sky#Development

Like everything else, there is no reason why you couldn't use Unity as a renderer only for this type of game.

 

I read it somewhere, but like I said, don't remember and I'm not even quite sure about it.

 

They are using their custom in house engine created from scratch. Not sure how could they use just part of Unity, or modified Unity You cannot cut unity to pieces.

 

You can if you add a few zeros after a 1.

 

??? Unity 5 introduced a ton of modularity just so you could cut the engine up.

 

Just ask someone who gets the game to browse the file directory for the common signs of a unity project. Files with unity in their name, managed mono resources, the folder structure, etc.

 

It's also possible that the team signed on for a Unity source license. With that, you can cut Unity to pieces.

 

Sounds like a big expense for a large scale walking simulator

 

But you could get quite a bit done if it was a single C# file of 4k...

 

I'm out of the loop, lets talk large OpenWorld games..

Dynamic Navmesh? AI systems? Enlighten any good for it? Physics issues? Performance / streaming issues?

 

You really should. Minecraft was originally made using Java, of all things. Not a terrible starting point, but hardly the most performance-focused approach. While it is possible to dig into Java and take a little more control of lower-level functions, this isn't the approach that Java encourages. It's every bit as memory-managed as C#.

Procedural generation is almost never limited by game engines. It's simply a way of handling data dynamically to generate content on the fly. You're probably focusing on scene-size limitations within Unity. This is a mistake. Any developer worth their salt would disconnect their procedurally generated world from the scene that contains the player object.

It's a mistake to ever try to say that Unity isn't built for specific games or game types. Of course it isn't. Unity is a generalized engine. It's designed to be flexible enough to make any game. That's kind of the point. It won't ever be ideally suited for any one title. But it will be flexible enough to cover just about any title. You sacrifice some level of performance or convenience in order to get more flexibility. That's just the nature of the beast. If that isn't your bag, then look elsewhere.

 

If the first thing app does is "launch browser"....

 

How about separating their game from unity entirely and using a client for just rendering, input, physics etc?

 

Possible, but why bother? You disconnect the world data from an individual scene to make it easier to load the world data into the current scene dynamically. If you want a world with virtually no boundaries this would be the de-factor approach. There's no need to remove Unity from the equation entirely.

You could scrap Unity and go with a from-scratch solution. But then you'd be abandoning all of the functionality that Unity provides by default. It's your choice, but it comes down to weighing your options. I have still not run across a situation that would convince me to switch over to a different engine.

 

Maybe if you wanted to go back to ogre3d, and use physx or whatever and then you wouldnt have to deal with the garbage collection. Prototype in unity

 

If you wouldn't mind staying on this tangent for a second, could you list the things unity is appropriate for? I'm trying an experiment of having a majority of the game logic on an external server. I'm making it in the style of diablo 3 where the server does basically everything except gather input and do special effects.

 

Here's a short list of issues I've had to deeply compromise on with our medium-sized open world game including some things Unity does quite well to help. So it's possible but have to realise the pitfalls.

1. Unity doesn't use depth buffer to full potential. It should be reversed-z so there's more precision where it counts. This is for visuals and shadows, although in a later version they plan to address shadows at least.

2. Lack of instancing pretty much destroyed any plan of populating an open world space. Thankfully this is being addressed now, starting with 5.4. It's a good start, not finished.

3. Lack of texture loading/unloading progressively, something that UE3 and 4 have natively and pretty much every game ever has but Unity doesn't. Texture streaming is much more important than anything else, because these bad boys are what eat your ram the most. This still holds us back, so we have to aggressively work around it because I lack the time and energy and resources to add it myself. I'm already floored by how much work I have to do.

4. Culling groups are a wonderful thing. But robust native octree support for spatial stuff would be a massive boon. ie dump lines, points, get back data.

5. Navmesh can work in open world, but you need to be really picky where you need navigation. We used little rotated boxes to hint where we wanted navigation baked, and pulled the geo out within those bounds for navmesh to bake against. Was a lot of needless work.

6. Generally-better performance and streaming is needed.

7. Why the hell is terrain collider still dependant on unity terrains? It's a native physx heightmap collider. Please call it that and open it up. Tired of having to keep a shadow unity terrain around when this thing is optimal for non terrain too.

 

We are having the same exact issues with our upcoming Forgotten Memories game which is a bit semi-open.
A lot of those things can be fixed with source code assess. Exposing more the Terrain API should take little to no effort.

PS: Unity depth buffer is a standard [0...1] linear depth buffer. It's also the fastest depth encoding/decoding. Logarithmic depth buffer takes more time to encode/decode and also have issues with close range precisions. A combination of both will be tricky to implement due to the openness nature of the Unity rendering system and won't be faster than linear depth.

 

It's slower, but it won't be the thing that anyone bothers optimising on a halfway decent desktop. Mobile ES3 maybe? I'd like to have the option.

 

Check out

One Night Ultimate Werewolf Board Game
http://www.amazon.com/Night-Ultimate-Werewolf-Board-Game/dp/B00HS7GG5G

Friend brought this over the other day and it was pretty damn fun, and the iphone narrator and rulemaster fit the game perfectly.