I want to use LOD groups in my(mobile) game, because I have problems with performance. The thing is that I have seen it used on objects that are not in big amount(like cars in racing game), but I think that my game would most benefit from using it on terrain(not unity terrain system, just some terrain parts like rocks etc.). The problem is that I don't know if it is meant to be used on this many objects(I have a lot of them in the scene). The other thing is how would baked lightmaps work on these(is it even possible)?
Related
For my exam project in coding class I have to recreate a game in Unity where I can also show off my OOP knowledge. Some of the requirements of the project are encapsylation, inheritance and polymorphism.
What are some good ideas for a game that can show all these things? The ideas I had was Candy Crush, Street Fighter, Hearthstone or some tower defense, though I'm not sure if I'll be able to make good use of OOP in these games.
All games you're listing aren't really fit for an exam project. I don't know how much time you have to finish this project, but I'd go with something a lot easier, especially if you're going to do it youself. If the main objective is to use your OOP knowledge, any simple game with maybe different kind of enemies or items will do.
For instance, asteorid, but with other kind of objects and weapons beside the asteroids and the main gun themeselves. Asteorids, bombs, fire balls, you name them. All of them must have some degree of common behavior and that's where OOP can be used. Weapons too. Rayguns, double barrels, radial shots, shockwaves...
This is just an idea. You can do something different like Pac-Man and implement diver kinds of ghosts, for instance. Or different main characters with different abilities.
Although, be aware that Unity (and most other game engines) although built on topo of OO languages prefer a Component-driven approach and true OOP is used in very little quantities in very specific parts of the game. Usually data structures more than game objects.
I had a client ask me to build a Tamagotchi type of game and characters are a place where you can use a lot of inheritance to build some base character types then branch off into specific character types. The classic base "animal" and then "bear"/"wolf" etc or biped/quadruped etc some lay eggs, others are mammals you could come up with some good inheritance trees.
In Unity, the different types would need to implement their different ways of triggering animations via the Animator controllers possibly. Most of the systems in Unity won't need any inheritance though, your plain C# classes would implement these and I don't recommend that you build off of Monobehavior. Instead, you have a ScriptableObject and it will instantiance the necessary C# class possibly based on an enum you have that represents all the different types.
Basically it was a 3D Unity Project (nothing used 2D components) and had a simple plane as the ground, and then the camera was above - pointing down at the "ground". The character had 2D art that was perpendicular to the overhead camera, but they were correctly upright with the normal Z world direction so their "feet" were on the ground plane and normal physics/rigidbody can be turned on. This way you can add a Navmesh to the ground and Nav Agents to your characters making movement really simple. They move around like normal, but their art is facing upwards towards the camera. You can give them colliders and rigidbodies. Setting this up took barely any time and saves you from having to work in pure 2D mode with all the problems it comes with for implementing your own movement and control systems, collision detection, etc. If you go pure 2D you lose a lot of systems and it's not necessary. This way you can just use simple 2D art assets.
Your tower defense is also not a bad idea because towers can have inheritance too. Again, design your own classes and you shouldn't be inheriting from Monobehavior in your base class. You aren't expanding on Monobehavior, you are building your own classes.
A while ago I started practising in Unity. I made a football stadium that consists entirely of the 'normal cubes' (each seat consists of 2 cubes). Everything you see is made of cubes, no other assets have been used. In the picture it may still look reasonable, but when I walk into it, it is incredibly slow and jittery, of course because of the many (tens of thousands) of cubes that the view contains. I also experienced this in the normal scene, when I didn't even start the game.
Now I want to start over, and use assets instead of cubes, to make it all a bit nicer. The stadium will again have to contain tens of thousands of seats. My question: How do I avoid getting such a faltering image when I walk in it? Is there a trick to merge many seats into 1 grandstand, to reduce the number of objects, so that Unity/the computer can handle it better? I know the parent/child idea, but then you end up with tens of thousands of children, and thus tens of thousands of game objects. And then it is still faltering.
In the past I have only used cubes in Unity. This time I want to start in a way that will not allow me to run into this same problem again when the stadium is finished.
First, you have to reduce the number of meshes by combining them into larger simpler to handle meshes. There are a lot of tools, but you can do a lot with simple solutions like Mesh Combiner.
Also, make sure that you mark all non-moving objects as "static" so Unity can optimize better (this does not remove the need to combine the meshes as already mentioned).
Be careful so you don't add too many different materials.
If you have good 3D tools (Blender is free) you can use LOD (level of detail) groups. Unity LOD Tutorial.
Finally, if you really want to have a living arena, and have some cash, why not add some animated meshes as in this asset Mesh Animator. I am sure there are other similar solutions, maybe even open source - anyone?
I'm currently making a 2d platformer game with unity. I'm going to build game world with rooms (like in Hollow Knight and many other metroidvania games). So, my first idea is to have each room as a separate prefab with virtual camera and exits linked to other rooms on scene. And to have several scenes (smth like each scene contains a set of "thematic" rooms).
I have another idea but i'm not sure if it gonna work properly in terms of perfomance. The idea is simple - to have single game scene and instantiate\destroy game rooms dynamically and seamless. So the game will have current room and all adjacent rooms loaded (with some depth maybe, i.e. all adjacent rooms with depth R), when player changes room - some new rooms are instanciated and others destroyed. This feels like a good idea, cause after creating dynamic room system you can just concentrate on creating and linking rooms. But i'm afraid it can lead to some perfomance problems (i.e. game freezes when player moves from one room to another if there is a big enough room nearby). And i guess there can be a lot more unexpected problems.
So it's kind of open-type question. What do you think about this "dynamic" approach? Is it worth trying? If you have expirience building similar games, what design approach did you use?
Typically, creating and destroying objects in-game is a no due to performance issues.
From my high school game dev teacher, a better way to do it is to preload everything outside the camera, and just move needed resources into view as needed for a randomly generated scene.
If you're looking for a static scene, I would just preload everything that I need for that specific scene.
Imagine a large free-roam game in Unity,
The yellow size indicates about the largest you can make a typical Terrain in Unity.
Art dept. will completely build, meter by meter, the entire scene.
Please note, this has absolutely no connection to repeating scenery (as in runners) or procedural scenery (as in say some race games).
Really, what is the correct and good way to do this in Unity?
use say 50 or so terrains, each perhaps 100m x 100m ?
can you even have or use that many terrains?
or what?
For anyone googling here.
The correct solution is indeed
Terrain stitching
that's it.
In practice you must use one of the tools available to do this (eg, TerrainFormer) or, your team will write from scratch a terrain stitcher.
Yes, you just use "many terrains".
The best approach to the exact problem posed,
is in fact to just:
"use lots of Terrains".
It seems to be perfectly viable in Unity to have many (dozens) of Terrain units, basically "sitting next to each other".
In practice, you'll need TerrainFormer
https://assetstore.unity.com/packages/tools/terrain/terrain-former-20052
or one of the similar tools.
(Or, I suppose, from scratch write your own tool to stitch terrains, and allow you manipulate them all at once, join the edge-heights perfectly, etc etc.)
It's not realistically possible to just perfectly sit many Terrains together (by hand), matching all the edges, etc etc. So you're going to need a "stitcher" package for putting many Terrain squares together.
So, this huge area ..
has about 12 Terrain.
So that's the answer, you can indeed have "many, many" Terrain in a Unity project, you do indeed essentially just "sit them next to each other". In practice it's not achievable unless you use one of the editor tools such as TerrainFormer.
The proper way to do this would have been with procedural mesh generation with MeshFilter and Mesh API but you mentioned that this not at all random or generative so that one is eliminated.
It's just simply a very long, thin, hand-made environment
The best way in this case would be a Modular Level Design. You need to create Modular Assets. With this you can have a long road in pieces which can be tileable. A good modeling artist should be able to create and texture modular assets with 3D modeling packages like Blender, Maya or 3ds Max.
All the programmer has to do is make each asset a prefab then use the Instantiate function to instantiate them to create any distance of environment. You can also create a static environment in the scene from the Editor. Almost anything can be made into a modular Asset especially buildings and roads.
After assembling them in Unity, you can do static batch on all the instantiated modular parts with Unity's StaticBatchingUtility.Combine to improve performance of the game since they are not being moved.
Below is an example of a modular road asset that can be used to create almost any amount of road:
You already answered your question
in this case would it be better to not bother with Unity's otherwise excellent Terrain, and the modellers would just outright build the long course/scenery? (Obviously you'd have to chunk it so it all occludes fine)
I think it's the way to go. If the performance is an issue, try putting each chunk in different scenes and then have a master scene to load them async and additively. And of course you want to unload each scene as it becomes invisible in the camera.
I personally go with your own solution which is letting the Unity Occlusion Culling system to take care of the hiding and showing chunks. I only go with the separate scenes approach if I'm not getting enough performance this way.
I recently had the same problem. We build a tilebased infinite runner with road crossings. The camera was positioned behind and over the car looking down on the street and the player car. So the setup is quite comparable.
We used Curvy from the Asset store to create paths for moving the player and also for creating the geometry of the streets and the surroundings among the streets.
https://assetstore.unity.com/packages/tools/level-design/curvy-splines-7038
It is also easy to spawn tiles with curvy paths and combine them at runtime. So you can separate long distances into smaller segments and spawn them randomly.
We also used QuickBrush from ProCore to quickly paint environment detail to the geometry like trees, bushes or stones. I think procore tools are now implemented in the new Unity 2018 version.
Worked quite well.
I'm using Unity3D for a networked multiplayer online game where I have a very large complex 3D terrain scene like a forest, with trees, cliff, hills, mountains, bounders, etc.
Players can also build structures sort of like minecraft, and put them anywhere in the scene, or even move them around anytime.
Aside from the human controlled players, there are automated AI players and objects like animals roaming around the scene following a path.
The problem is how to make these automated AI players and animals, able to navigate around the static and dynamic player created structures, because the path they follow can easily get blocked by player created structures, or even by other players and other AI objects, cliffs etc. So they have to find away around them or get themselves back on track if they tumble down off a high cliff for example.
So I made a navMesh and used NavAgents, but that just takes care of the static, non moving objects, but how do I make the AI players navigate around each other and also the dynamic structures created by the players which can number in the hundreds?
I thought of adding a NavMeshObstacle to everything, but this would result in it being attached to hundreds of objects since the user created structures are built using little pieces like blocks or little tiles to create a larger object.
Here are my questions:
Would attaching a NavMeshObstacle to hundreds of little objects slow down the game?
Is there another way to navigate of dynamic objects other than using NavMeshObstable without slowing down the networked game?
Thanks
Based on the documentation for NavMeshObstacle, one could reasonably assume that if carving (an obstacle "carving" a piece out of the nav mesh) is disabled, obstacles will only affect agent performance when they are in the agent's way. They won't affect pathfinding. The agent will just go around them when it's close. Note that this will not work for you if there are so many dynamic obstacles that the agents need a very different path. You can also set them to re-carve a piece out of the nav mesh only when they've moved a certain amount. You should test the performance, but that sounds like it might work well for you.
http://docs.unity3d.com/ScriptReference/NavMeshObstacle.html
If you don't want to spend much time on making your own "sensor and navigation" system extending unity's navigation then I think your way is through NavMeshObstacles. If you build your obstacles with blocks like minecraft to avoid add NavMeshObstacle on each block you have a huge range of choices on how to limit/approach on your building system.
There is also good AI systems free as RAIN, for example, that implements some extensible and consistent way to do what you want, take a look on unity market if anything there fits your needs.