Tag Info

Hot answers tagged

24

I believe Prop ( See: http://en.wikipedia.org/wiki/Theatrical_property and https://developer.valvesoftware.com/wiki/Prop_Types_Overview ) is commonly used. There are less ambiguous alternatives, for example Blizzard uses the word Doodad.


17

I would use the word Doodad for those environmental things as it's a standard. When editing in both Titan Quest and StarCraft's Map Editor, they're referred to as Doodads. http://starcraft.wikia.com/wiki/Galaxy_Map_Editor#Terrain I usually refer to objects an Actor can interact with as Props, just as if they were on a stage. Actors use Props to do actions, ...


8

You're assigning the value of money to the print return value, not the actual int value being returned. money=print(PlayerPrefs.GetInt("Money")); Should be money=PlayerPrefs.GetInt("Money");


7

If you only have a few gameobjects it doesn't really matter. But if you are planning support for lots of gameobjects, I suggest you take at look at the following question: Game engine and data driven design And continue to read the following article (originally printed in Game Developer): Data-Oriented Design (Or Why You Might Be Shooting Yourself in The ...


7

Destroying the object gets rid of it completely. You cannot get it back. It is gone. Deactivating it just disables it; everything is still there, it just does nothing. Therefore, if you want to reuse the object, you can deactivate it, but if you will never use it again, you should destroy it (and get back its memory).


6

If anything, the first option might be better for cache misses since generally you'll be iterating through, say, all the Renderable components at once. Just copy the data you need into that component to avoid cache misses due to looking up data. But it seems like you're suffering from design paralysis. Do you actually have a working game yet? Are the ...


6

The Speed (fast to slow): cached _transform >> Component.transform >> Component.GetComponent<Transform> And If you disassemble a UnityEngine.dll C# binary, you can see transform do not call GetComponent (Component class member), just call internal mono runtime method. Here is the transform code. // UnityEngine.Component public Transform ...


5

Your question seems indeed a bit confusing. I assume you are asking about the problem, how some specific code piece (e.g. the function responsible for firing a bullet within the mob unit) should get to the information about "how to fire the bullet" and "what bullet type" and so on? Here are some solutions: Just use globals and get over it ;) In gaming ...


5

Vectors are dynamically sized (usually) random access containers. They facilitate constant time look ups to any location within the array, and better yet, their direct storage is contiguous. The biggest (and its a big one) downside to vectors is the performance hit when they need to grow. Vectors typically allocate a certain capacity, and this capacity is ...


5

As requested, one possible solution (with some flaws) is to use raycasting: Attaching a (C#) Script similar to this to the GameObject from which you want to check visibility would work: if(renderer.isVisible) //Check if Camera is turned towards the GameObject first { RaycastHit hit; // Calculate Ray direction Vector3 direction = ...


5

As Jinbom said the main difference here is speed. However it is important to note that this is only the case for the transform property of GameObject. Other properties such as camera and rigidbody are just convenience properties and call GetComponent<> under the hood so the performance is identical. It is for this reason that Unity has deprected these ...


4

Recursion and depth-first traversal are not the same thing. This is also not about the merits of scene graph versus lists of components or whatever. It's also more of a general computer science issue than it is a gamedev issue. Bummzack's comment about how wasteful it is to create a whole new list is extremely important. You need to traverse your tree ...


4

Components should register themselves with the appropriate system. You could do this in the constructor/destructor, though I'd highly recommend some explicit OnCreate() and OnDestroy() methods or some such. You'd have something like so: void Renderable::OnCreate() { g_Renderer->RegisterRenderable(this); } void Renderable::OnDestroy() { ...


4

IMHO: If you are programming some real-time application, you should avoid recursion if it's possible. Recursion has to push and pull curent context and it's slowing down your app. It's also more memory complex. Of course if you have just few objects, it's not so dramatic. But when you will add more and more objects in future, it will be slower and slower. ...


4

Your LevelCollider is attached to a Collider that is a trigger. That means it will not call OnCollisionEnter. It will call OnTriggerEnter. Try adding this to LevelCollider: void OnTriggerEnter(Collider other) { Application.LoadLevel("Level1"); } That should do ya!


4

Here are the steps for applying scripts to multiple objects. Step 1. Select all your objects from Hierarchy panel. Step 2. Then from Project panel drag & drop your script into Inspector panel.


4

You can Destroy the component. Be careful about which object you destroy, though. If you pass a GameObject to Destroy, you will destroy the entire thing. To destroy the component, you must pass a reference to that component specifically. //example: destroys the MeshRenderer attached to this GameObject var sphereMesh = GetComponent(MeshRenderer); ...


3

What's wrong with just making it a global? Making a game is significantly more important and rewarding that adhering to academic purity. Just get the job done. That said, another option is to store a pointer to the owning State in the game object. It's wasteful if you're just using it to avoid having a single global pointer but it can be a boon if you ...


3

"Decoration" has always been the name I've given to non-interactive, non-collidable elements. When using flixel I would have level data defined by three separate layers Solid, Interactive and Decoration. Solid and Decoration would then be loaded into Tilemaps, both would be rendered but collision checks would only be made against Solid.


3

I recommend your second option, adding/removing links. If option 1, using a particle system, is even possible, it is highly likely to be essentially reimplementing option 2 by twiddling the particle system from outside. You'll also likely have issues at the ends due to the particles being obviously different from the neighboring geometry. I've never seen a ...


3

Your best luck is to learn some matrix math. You should have some kind of scene graph that establishes the character as a child node of the boat. It then would store it's position relative to the boat. The boat would have a transformation matrix, you apply that to the child nodes, and the child nodes could stack some more transformations on the matrix ...


3

Collision events will only be detected under specific circumstances. Each collider can be considered to have these relevant properties: Is a RigidBody (or RigidBody2D) attached to it's GameObject, if not it is considered Static. If it has a RigidBody, is it marked Kinematic? Is the Collider marked Trigger? The circumstances under which collisions are ...


3

These are not the same. Resources.Load is going to create a new uninstantiated GameObject. This means your first example is going to create a new game object, then set that object equal to the new game object created by Resources.Load. That means two objects are going to be created, an empty game object added to the scene (from the new GameObject() call) ...


3

You seem to have rectangles that are sandwiched: You have rectangles A, B and C A directly above and is overlapping B, which is above and overlapping C. The update for A is done, pushes it a bit up. The update for B is done, pushes it a bit up because of C, and a bit down because of A. B hasStopped because it did not move because your [x|y]Shift is ...


3

You can use the OnBecameInvisible callback for that. Just implement something like: void OnBecameInvisible(){ // disable or destroy gameobject } The method will get called when the object isn't being rendered by any camera anymore. This also includes cameras from the Unity-Editor. So if you're running your game and have the Game and the Scene view ...


3

That's not using GetComponent() on the class GameObject, it's using GetComponent() on the result of GameObject.Find() GameObject.Find() is a static function, but it returns a specific object. Note that Code 2 is also using GameObject.Find() but then you store the result object in a variable. Code 1 uses the exact same functions but doesn't store the result ...


2

You can do this using plain mouseup/down tests and raycasting, and the same pattern applies to many other situations, like marquee selection. // Call this inside an Update method. void HandleDragging() { const int mouseButton = 0; // button values are 0=left,1=right,2=middle if(_isDragging) // Leading underscore denotes private member variables ...


2

Each object should own its own properties. If other objects need to know those properties, let them query for them. Your sprites probably don't have an intrinsic position, and they don't know how to get a position to be rendered because they may have to get that information from more than just Actors. So, you need a class that mediates between them. You ...


2

Go with linear, as it's easier to follow and iterate through objects than it does adding more to a stack and unwind. If the order in which the gameobjects are updated is not very crucial to the behavior and interaction between, linearly updating would be all you'd need. It all depends on how strongly coupled the objects' behaviors are on each other.


2

It sounds like you want to extend the Unity editor. Looks like you can use the Handles class to create custom handles for your objects too.



Only top voted, non community-wiki answers of a minimum length are eligible