Hot answers tagged gameobject
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 ...
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
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 ...
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 ...
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
