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, ...


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 ...


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 ...


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 ...


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

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() { ...


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

"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

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 ...


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

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 ...


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

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

Using decorators is not a good idea in this case, because you also want to un-equip items. When you wrap decorators in decorators in decorators and then want to remove a specific one inside that stack, it's a quite messy operation (especially because an object shouldn't be aware that an object it uses is just a decorator wrapping something else). What you ...


2

Your idea of using a static method is probably the way to go. Give Enemy a constructor with all the values as parameters, then use static methods to make it easy to call it. Generally, you extend a class so you can override its methods. Suppose Enemy has a goToPoint method that moves the object in a straight line at a constant speed. You want a Ninja to ...


2

If you want to see all the objects that are using a specific script, there are a few ways you can do that. Iterate through all the game objects and return a list at will. You can find all the objects of a certain type with: (Where myComponent is the type of component you're interested in: myComponent[] myComponents = ...


1

If you want to create an array of this gameobject, you can do this as follows: int Size = 10; //Number of objects GameObject[] Tiles = new GameObject[Size]; Let's assume you have created a prefab, called "Tile". If we want to initialize the array's gameobjects, we could do it like this: //Loop for the entire size of the array, 10 in this case for ...


1

It seems to me that your is like a graphs manipulation problem. So using graphs to model your neighborhood will probably give you more satisfaction both in terms of game dynamics expressivity and performance. In this modelling scenario, your residential entities are associated to a node in the graph, so the entity does not need to store any topological ...


1

Working from the framework you have now, can GamePlayState simply expose a public getPlayerCharacter() method? Then you can cast your IGameObject to a GamePlayState and call it. Something a bit like... GamePlayState currentState = stateSystem.getGameObject("Gameplay") as GamePlayState; if(currentState != null) PlayerCharacter playerCharacter = ...


1

Rigidbodies awake when any force is applied to them. If you had a pool game and all the balls are sleeping and you would hit them with another ball, they would all wake up. I guess there is some minimal jittering going on that keeps your rigidbodies alive. There are a lot of parameters that can have an impact on this, but personally I would first and ...


1

What you can do is use multiple vertex buffers for the chunks. When you call the map function, you deny gpu access to that resource, so the gpu must wait for you to be done with the buffer before it can use it again (see link). If you have multiple vertex buffers, say one for filling and one for rendering, the gpu does not have to wait and this might reduce ...


1

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 ...


1

Like Hatberg said I used to hear them called "Props" when I was younger but after I took a few game development classes in college (ironically taught by the founder for Iron Lore Entertainment (Brian Sullivan) who made/designed Titan Quest) I heard purely decorative game objects being called "Set Dressing". I guess it's just a synonym for Prop but I find ...


1

If you destroy your gameObject you need to re-instantiate it at some point. If you access something that's been destroyed, you'll get the access error you're seeing. You don't show how or when you're first instantiating gameObject. I see you're using static references to GameObject, and setting g and f to instances of a GameObject, but never gameObject. ...


1

Well, I've solved it. I'm not very sure what was happening, but due to the fact that I've created and erased an then re-created the terrain multiple times in the scene (each time adding it to some scripts, etc), at some point something got jumbled up in Unity, probably because of this. Long story short, I created a new Unity project, copied in all my scripts ...


1

Classes and objects are just bundled functionality, nothing more. And that way you should work with them. Ideally you should build your classes around composition. The more advanced object should consist out of multiple smaller objects, and do all the communication needed between the smaller objects. The smaller objects should do nothing on their own and ...


1

A common way to deal with the problem you're describing is to do this: class Transform { public int x; public int y; public float rotation; } class Actor { public Sprite s; public Transform t; } class Sprite { public Transform t; } Now your data is encapsulated in one class ref'd by both Actor and Sprite. As for that separation, yes I ...


1

What about making clones or factories? For clones, you could just call object.clone(). This would make another instance of this object type. Though I'm not sure if they will share references, so may not be the best way. Thinking a little more, I think you could use Java Reflection library. Assuming you just have one constructor with no parameters, this ...



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