I'm creating mobile racing(in space) game and it's first person so there is always big cockpit occluding big part of scene. Can I somehow use the fact that I know it to optimize rendering? I have heard that draw call order can be changed, but I don't know how exactly it would work.
The thing you are looking for is called "Occlusion Culling". Here is a guide from the Unity manual explaining how it works and how to set it up.
NOTE: This only culls static objects, if your cockpit moves with the player objects covered by the cockpit will not be culled by using this method. If you want to do occlusion culling with dynamic objects you need to get a 3rd party asset from the store like InstantOC, it even has a "Mobile Aircraft Controls" prefab (Note, I have never used InstantOC but I have heard good things about it).
Related
I've just started my first Unity experience by moving a match-3 based game to Unity, and I want to be able to attach data to each available tile type specifying how likely that tile is to be dropped onto the board (and be able to override that value for each level). There are a few match-3 tutorials floating around, but besides a tendency to not explain how to make things happen in Unity, I haven't found any leveraging the Tilemap, which seems a shame since it looks like it provides a fair bit of necessary functionality. The only problem is, I don't see anywhere to attach data or a script to a base Tile, so I've been looking into whether going the Scriptable Tile / custom editor route would get me what I need; but then I run into the lack of instructions on how to get basic functionality on the custom editor (the ability to specify the underlying sprite seems rather fundamental, but I'm not finding anything).
Anyway, is the Scriptable Tile interface my best bet to get level-specific data attached to individual tiles, or should I be looking for a different way to get this data on there? Or should I just ditch the Tilemap and the functionality it does include out of the box altogether like all the tutorials seem to be doing?
I want to implement Silhouette Highlight on MouseOver like in this picture:
Built in Unity3d user interface elements have a component called Outline and Shadow, but they only work with the user interface, not with the SpriteRenderer. The first idea was to create a second sprite with highlight at background and enable it to MouseOver, but I think that this method is not good.
As Everts (and me) mentions in a comment,
there's nothing wrong with simply making the "glow sprites" and turning them on and off. That would certainly be done in many large games: it's good.
It's true that you could write a shader that does this, but really that would be "bad engineering" - totally unnecessary for such a simple need. (And to be clear, arguably it's plain better to make custom sprites.)
Now, this brings us to an important point about Unity engineering -
it's critical to use existing assets, in Unity work.
There are a couple of stand-out examples. Like, NatCam and Edy's vehicle system. You just - literally - cannot use the camera in a game unless you use "NatCam"; the only alternative would be to completely pointlessly spend a year building NatCam yourself.
In this case, there are many good "glow shaders" available ...
https://www.assetstore.unity3d.com/en/#!/content/20166
Enjoy!
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.
I've been developing a board-style game in Unity3D. The main scene is the board, and has the data about each player and the current (randomly-generated) board stored within it.
I intend to add minigames into the game, for example when landing on a particular space on the board. Naturally, I would like to code the minigame in a separate scene. Is there a way I can do this without losing the instance of the current scene, so that the current scene's state is maintained?
Thanks in advance :)
Short answer: no, but there may be another way to do what you want.
A basic call to Application.LoadLevel call will destroy the current scene before loading the next one. This isn't what you want.
If your minigame is relatively simple, you could use Instantiate to bring in a prefab and spawn it far away from the rest of your scene. You can even use scripts to switch to another camera, toggle player controls and other interactions in the scene, and so on. Once the minigame is done, you can destroy or disable whatever you brought in, and re-enable whatever needs to be turned on in the main scene.
You could create a separate scene and call Application.LoadLevelAdditive to load that scene without destroying the current one. As above, you can then use scripts to manage which cameras and scene behaviors are active.
If you're careful, you don't really need two separate scenes. It may be enough to "fake" a scene switch.
Hard to give a complete answer without code, but you should look into the following things either with the unity documentation or youtube:
PlayerPrefs, this is one way of saving data, although i believe it isn't entirely secure i.e. being able to edit from a text file.
Serializable, this is apparently better than playerprefs.
DonDestroyOnLoad, can carry over information to multiple scenes.
Static variables, again not sure if this will help your particular problem.
I'm looking to make an RPG with Cocos2D on the iPhone. I've done a fair bit of research, and I really like the model Cocos2D uses for scenes. I can instantiate a scene, set up my characters etc. and it all works really nicely... what I have problems with is structuring a game loop and separating the code from the scenes.
For example, where do I put my code that will maintain the state of the game across multiple scenes? and do I put the code for events that get fired in a scene in that scene's class? or do I have some other class that separates the init code from the logic?
Also, I've read a lot of tutorials that mention changing scenes, but I've read none that talk about updating a scene - taking input from the user and updating the display based on that. Does that happen in the scene object, or in a separate display engine type class.
Thanks in advance!
It sounds like you might do well to read up on the Model-View-Controller pattern. You don't have to adhere slavishly to it (for example, in some contexts it makes sense to allow some overlap between Model and View), but having a good understanding of it will help you to build any program that has lots of graphical objects and logic controlling them, and the need to broadcast state or persist it to disc (game save), etc.
You also have to realize that cocos2d provides a good system for structuring the graphical scene graph and rendering it efficiently, but it doesn't provide a complete infrastructure for programming games. In that sense it's more of a graphics engine than a game engine. If you try to fit your game's architecture into the structure of cocos2d, you might not end up with the most maintainable result. Instead, you should treat cocos2d as what it is: a great tool to take care of your display and animation needs.
You should definitely have an object other than the scenes that maintain the game state, because otherwise where will all the state go when you switch between scenes? And within scenes/levels, you should simply try to use good Object Oriented design to have state distributed over objects of various classes. Each character object remembers its own state etc. Here you can see where MVC becomes useful: when you save the game to disc, you want to remember each character's health level, but probably not which exact frame index the sprite animation was showing. So you need to distinguish between the sprite and the character (model) itself. That said, as I mentioned before, for game objects that don't have a lot of logic attached to them, or which don't need to be saved, it might be ok to just fuse the Model and View together into one class (basically by subclassing CCSprite).
To pull off MVC the way it's supposed to be, you should also learn the basics of Key-Value Observing. (And you'd do well to use this replacement for Apple's interface.) In more intensely real-time games, techniques like this might be too slow, but since you're making a RPG (good choice for starting out) you could probably sacrifice performance for a more maintainable architecture.
The game scene (which is just another cocos2d sprite) plays the role of Controller, in terms of the MVC pattern. It doesn't draw anything itself, but tells everything else to draw itself based on inputs and state. It's tempting to put all kinds of logic and functionality into the game scene, but when you notice that it swells, you should ask yourself how you could separate that functionality into other classes. Analyze which type of functionality you're implementing. Is it to do with data and state (Model)? Or is it about animation and rendering (View)? Or is it about connecting logic with rendering (in which case you should try to make the View observe the Model directly)?
The game scene/Controller is basically a dispatch center, which takes input events (from the user or from sprites reporting that they've hit something, for example) and decides what to do with them: it might tell one or several of the Model objects to update themselves in some way, or it might just trigger an animation in some other sprites, for example.
In a real-time game, you'd have a "tick" or "step" method in the scene which tells all objects to update themselves. This method (the game loop) is the heart of the program and is run every time a new frame is drawn. (In modern game engines there's a lot of multi-threading but let's not think about that.) But in your case, you might want to create a module that can "play the game" completely separate from the game scene. Imagine creating a program that can play chess through the terminal, using only text input. If you create the whole game system in that manner, and then connect it to the graphics engine through a small and clean interface, you'll have a really maintainable app with lots of reusable code for future projects!
Some good rules of thumb: the model (data) shouldn't know anything about sprites or display states; the view (sprites) shouldn't contain any of the game's actual logic (the game rules) but only know how to do simple things like moving and bouncing and reporting to the scene if something complicated happens. Whenever possible, the view should react to changes in the model directly, without the controller having to interfere.