The world and the entities that call it home... Who owns who? [Game Code Design]

Started by
1 comment, last by leiavoia 18 years, 10 months ago
Hey all, The (2D) engine I'm writing is currently being refactored, and as a by-product so is the basic logic of the game itself. The main goal of the engine's design is to abstract logic enough to allow any sort of game to be constructed with it. For the most part, this goal has been accomplished in my latest outlining. I'm now stuck on another part of design though: the game itself. Specifically, entity ownership. In my previous game design, the entities belonged to an entity manager and they were responsible for entity-to-entity collision, rendering and updates (AI, movement, etc.). As my thoughts became grander though, I realized that world partioning would become extremely difficult to do. If an entity required information on it's surroundings, this would also be difficult. However - If the world kept the list of entities, my problems would be solved. You'd be able to partioning the entities into separate partition lists as well as provide entities with the necessary information they need on the world. This design is a little sketchy though. If the world class was responsible for the map and it's residences, you end up with a class that "does more than one thing" and this (as I have found out) is rarely an advantage. So my question is - how do you handle your entities, their partioning in the world and their ability to react to their environment?
Advertisement
Generally, an object that acts on a sub-object, I'd think should be just that.

For example, your world acts on the things it contains. I'd move world partitioning "up" one level, so some object like 'game' or 'universe' acts on the world, partitioning it as needed.

For my current project, I've focused on ownership via the term "is carried by".

entities are carred by tiles, which are carried by maps, which are carried by worlds, which are carried by games, which are carried by my app.

It forms into a neat little tree, which propogates effects and deletion accordingly. Entities can look "up" and see progressively larger chunks of the game as needed.
I have a gamestate manager that creates states. Each state has as member objects a few things (depending on the state of course): key game elements like the player (in action mode), possibly GUI HUD widgets, etc. But they also contain the object processor that "owns" the other game objects (enemies, collectables, special effects) and the "GameSpace". The game space is responsible for loading the world area.

As for partitioning, i actually have a quadtree contained by the CollisionObjects that do that. Since partitioning mostly pertains to collision detection (in my design), i simply made the world partitioning the job of the collision objects. That way, it's all selfcontained. You just need the world dimensions. I used to have it contained by the GameSpace but for my design it created too many interdepencies. If you [artitioning also factors in more than just collision detection, it makes sense for the "World" class to do this ("GameSpace" in my example)

I hope that made a shred of sense.

This topic is closed to new replies.

Advertisement