Unity3D Open World Game
Hello
My name is Smith and I am a Unity developer. After learning and playing around with Unity3D for about a year I am finally thinking about creating my own 3D open world game. Is this possible in Unity3D or should I switch to something like CryEngine?
My name is Smith and I am a Unity developer. After learning and playing around with Unity3D for about a year I am finally thinking about creating my own 3D open world game. Is this possible in Unity3D or should I switch to something like CryEngine?
Comments
CryEngine, to my knowledge, pretty much no longer gets any support after Crytek went through some financial troubles. I haven't used it myself, but my understanding is that it's a much more difficult engine to get into, with relatively sparse documentation and a community far smaller than most of the other game engines. Amazon helped them out some in return for rebranding it as an Amazon product, Lumberyard, in case you want to check that out. I believe it's free, but requires that you use Amazon's various web services or something, but, again, I think this would be game dev on hard mode, and I don't really see any point in making making games more difficult than it already is.
A) I did not have the manpower, since I am basically working alone.
B) I do not have the required hardware to pursue my dream project.
However, to answer your question, YES, it is very possible to create your own open-world survival game in Unity3D. The most important things you will need are:
A) A lot of self-discipline.
B) Know how to research, understand information and apply it.
From a technical point of view you will most likely need to know the following:
A) Geometry Instancing - Basically, it is rendering multiple copies of the same mesh in order to reduce draw calls (can also work if the meshes are the same, but have different textures). This works well for things like crowds. Unfortunately, it is only available in DirectX 11 API.
B) LOD - You will most likely notice that Unity's implementation of LOD will not be enough and you would be required to roll out your own implementation. LOD will basically render a mesh with fewer polygons as the camera moves further away from an object.
C) Imposters Technique - Basically an advanced implementation of LOD (if the above method does not scale well).
D) Skinning mesh animations.
E) AI - If your games has lots of characters (1000+) with intelligence, you would most likely want to ditch Unity's AI and roll out your own in C/C++. I have been following the works of the Continuum Crowds solution very closely. Basically, it models crowds as potential fields for global pathfinding and local collision avoidance. This would require some knowledge of physics.
There is a lot more that goes into making a game of this scale. Just following a few tutorials and playing around with Unity will not be enough. I have accepted the fact that 3D open world games requires a large team and have instead been working on a 3D isometric version, though, I constantly go back to my original 3D version (I have not given up on it as yet). Start small and check if people are willing to buy your idea.
You can have a look at a game called Ultimate Epic Battle Simulator. If I remember correctly, it can render 60000+ agents on the screen at any one time.
I hope this helps anyone else who are thinking of starting their open world 3D game.
You are right though, I've taken a look and it is definitely a . lot trickier than other engines.
So smith0 - You can do pretty much anything you want in pretty much any engine you choose. Some engines do some things better/faster/easier than others but I think the engine is down to personal preference in the end.
What's more important is to have a firm grasp on what you want to build and what kind of effort it will be...
In terms of open world 3D games as an example (The only numbers I could readily get) - The Witcher 3:
It cost about 81 MILLION US Dollar to make, and was built over 3.5 years with a team of about 240 in-house staff and approximately 1500 people in total.
So the way I see it, is that (my budget / 81 000 000 )% is the comparative quality I can achieve compared to the Witcher 3, or it will take me (3.5 / (my team size / 240)) years to build the same quality game. (My team is 6 and assuming we worked full time which we don't, making the Witcher 3 would take us +- 140 years).
I know that's not how scaling works, and the numbers are very harsh, but what this approach helps me do , is to properly estimate what I can do in what amount of time. Sometimes I get more done, but a worst case calculation like this helps to not try and take on projects that are definitely outside of my scope.
I don't mean to be discouraging - You can honestly do anything you put your mind to. We look forward to seeing what you end up building!
You don't necessarily have to not make an open world game, but an open world only really says that the space is very large (and therefore probably expensive); it doesn't say anything about what you actually do there. Exploring some of the much smaller interactions could get you a feel for what your possibilities are. Like cooking, or chasing animals, or shooting, or building, or whatever. All of these are things that can form their own, smaller mini-games, without needing to be open world. (Of course, with the right world, they might enrich each other too.) When you make an individual interaction, you might find that it's not fun (in which case you've learnt your lesson, and move on to try another interaction), or that it's fun, and you follow that, and it takes you in another direction, and that you might find that having an open world isn't even important at that point, because you've already got a tight little game that works great on its own. Or maybe it does fit an open world, but now you know what you're designing around, so you have a better idea of what you need in this world to improve the interactions you've got!
I'm just saying that if you're very inspired by something, you can still run with it, but structure it in a way that allows a bunch of space to pivot in case (or, more realistically, when) things don't work out the way you expected.
I think that one of the massive advantages you have as a solo/small developer over giant studios, is that you can afford to be flexible, pivot quickly, and let the project take you where it seems most fun/interesting, rather than deciding at the start with some board of investors that it has to be a particular genre of game because that type of genre is likely to be super hot in the next 6 months or whatever, and then being locked into the decision because it'd be too embarrassing to say that 60 people had wasted 3 months of paid work. The world is full of possibility! :D
Now Orange Pixel is a one-man team but, he is incredibly experienced and prolific. He has been shipping mobile games for the last 15 odd years and knows his tools and his limits incredibly well. Even he has said he underestimated the work involved in AshWorld, and ended up having to switch to a smaller game to get some additional funding in before continuing with AshWorld.
The best place I would suggest to learn about Unity is through their Manual. It's something that is always overlooked by many beginners.
When I see people talk about it there is often the worry that it could be shut down in future, but it seems like right now they are still doing fine.
Also, it supports C#.
Although not "open world", Cities: Skylines" is made in Unity, and manages to do a ton of super impressive stuff.
Also, in VALA, although it is a far way from being an open-world game, we do have technical bits that are similar to open-world games. In VALA, there is never any loading, and blocks of the world (including lighting for objects) is streamed in around you. Note that this was hard, and getting it to not stutter on things like the XboxOne (with slow CPU and HDD) is a real challenge. Along with that, stuff like lighting and pathfinding in Unity is built around having static scenes, and it required a lot of experimentation to work around the limitations.
I'm sure there are technical challenges around this in any engine though.
Something I haven't seen mentioned here is IL2CPP in Unity. At the most basic level, it takes your C# and converts it to "fast" C++ at build time https://docs.unity3d.com/Manual/IL2CPP.html
It is currently supported on:
Android
AppleTV
iOS*
Nintendo 3DS
Nintendo Switch
Playstation 4
Playstation Vita
WebGL*
Windows Store
Xbox One
Along with better perf, it also makes it much harder to decompile your code (which right now takes about 3 seconds).
But note that currently desktop builds are not supported.
The "unity look" thing is so widespread that even when I post stuff about VALA (which isn't like these AAA examples), people on Reddit have been surprised that it is Unity.