# Game Logic - Tree Based Game Design

I'm trying to write an easy to use and extremely modifiable game engine in C++. I was thinking about using a tree to store game data. All objects would inherit a from the Node class and would have parents and children. For example to access an object you could make a request the tree for game.workspace.player or game.devices.controller. I've seen this done in other games and it seems to work well.

Is this worth implementing? Would it affect the performance of my engine? -- I'm just looking for the best way to organize game data. Any critique or insight is greatly welcomed!

• Fast - Easy - Flexible: Pick Any Two =) You will get better answers if you describe what this engine needs to support, that way people have criteria for the decisions. You may also want to link those "other games" to help your description. – Patrick Hughes May 23 '12 at 20:46
• Build a game, not an engine and the answer would become apparent. – doppelgreener May 23 '12 at 22:54
• After reading over that article, I think I've decided to take that route. Fortunately I was still in the conceptualization stage of development so what code I do have can be used in my game. Much Obliged! – Sparky May 24 '12 at 0:56
• I've posted my comment as an answer so that this question can actually receive what I'm guessing would be a correct answer. – doppelgreener May 24 '12 at 10:26

Build a game and not an engine. You're getting caught up in what you inevitably get caught up in when you're making an engine: you have no specific requirements and you have no idea what will be most useful or pleasant, or how it will impact using your engine or your game's performance. You also have no way to know.

Build a game, and the game will tell you what matters, it will tell you what your game engine requires and you will be able to see the performance impacts of what you're doing.

You'll actually have a game to play for it, too.

• I reluctantly downvoted this, because although I agree with the advice, it's not really answering his question directly. If it's a bad question, we should close it, and if it's a good question, we should answer it properly. – Kylotan May 25 '12 at 11:23
• @Kylotan Questions don't always benefit from a direct answer. There are questions about how to do something where a valid answer (and probably the best answer) is: "Don't do that at all because it's a terrible idea. Based on what you're trying to achieve, do this instead." This is a similar situation. Instead of responding to some effectively subjective and unanswerable queries into what is worth implementing or what will effect performance, I've answered how one can find these things out for yourself in one's own unique case. – doppelgreener May 25 '12 at 14:58
• I don't agree - he's suggested a plan and asked about pros and cons. It's only subjective if you answer it that way. Besides, writing a game is a pretty expensive way to learn how to structure data, and if that alone would teach you how best to do it, there would only be one way! And we know that isn't true. – Kylotan May 25 '12 at 18:21
• @Kylotan Writing an engine is also a pretty expensive way to learn how to structure data - it's also a pretty good way to waste your time creating software that will probably end up impractical and useless. This is the crux of this answer, the "don't do that at all" part: don't try to evaluate engine factors in isolation, evaluate them in terms of your game and its requirements. Don't have a game? You shouldn't be making an engine. – doppelgreener May 26 '12 at 0:00
• He's asking about the usefulness of a specific technique. It's both possible and useful to answer that in a general and truthful way without lecturing him on whether he 'should' be doing it or not. If he hadn't mentioned that he was writing an engine you wouldn't have thought to post this answer, but instead you're trying to give general advice instead of answering the question, which is not what this place is about. – Kylotan May 26 '12 at 17:40

IF using C++ I would start with an existing solution that is feature full and fast. Such as openscenegraph

In general though I think most people would agree that a tree structured hierarchy is a good way to implement the things you refer to. Except for instancing. For this (Geometry, materials, etc) you would change the Tree into a DAG or Graph of nodes. This efficiency change will unfortunately mean rewriting a lot of your tree traversal code. So once again I would say start with a well supported and debugged intial framework.