5
\$\begingroup\$

How do you avoid one big data structure containing all the current world state ?

Let's pretend we're in a real-time strategy game, how would you code a skill that decrease mana of units around it ?

With a world state it would look like that :

class MySpell : ISkillWithoutTarget
{
  void Cast(Unit caster, World world)
  {
    foreach (Unit target in world.Units)
    {
      if (target.distanceWith(caster) <= N)
      {
        target.Mana -= X;
      }
    }
  }
}

So my question is : Does a good alternative to "world object" exist ? Or world object is the best way to deal with these kind of interactions ?

I'm not looking for a way to organize/optimize my big data structure, but how to avoid it. I would prefer not using this architecture because almost every piece of code can touch every game object. I'm looking for decoupling to avoid ending with bug almost untraceable.

\$\endgroup\$
  • 3
    \$\begingroup\$ An alternative could be messaging. \$\endgroup\$ – wondra Aug 9 '14 at 22:11
  • \$\begingroup\$ @wondra Maybe messaging is the solution, but the link in your article is a bit abstract regarding inter-object true interaction (not just being notified by units nearby, but actually allow an object to modify another object), do you have any example of code ? It might be worth to post it as an answer. \$\endgroup\$ – anopse Aug 10 '14 at 9:21
  • \$\begingroup\$ sadly, I dont have any implementation and I am seeking it just as well as you do. Well, technically, there IS an implementation on the website I linked (slides from some university + their engine with the system). \$\endgroup\$ – wondra Aug 10 '14 at 11:24
5
\$\begingroup\$

Because operations dealing with objects and their locations, such as collision detection and filtering nearby objects, are so heavily used in games, it is common practice to use one or more spatial data structures to describe your world. Some examples of these structures are grids, octrees, or the classic scene graph - a tree storing relative transformations in each edge. They are a perfect example of the tradeoff of using a little more memory to reduce algorithmic complexity.

These structures are useful because they allow you to exclude large numbers of objects from queries simply based on their approximate locations. For example, with an octree or a grid, you only need to be concerned with objects in the cells that intersect your query volume, and you can discard the objects in other cells, allowing you to prune lots of objects using only a few AABB checks.

However, I would refrain from having these structures actually store the objects themselves, and instead store pointers or references. If you do this, you can keep your objects tightly packed to improve iteration performance while allowing your scene graph to constantly adjust as your objects move around.


If you want to implement a messaging system, I would still use spatial data structures so that you can skip sending messages to objects that are too far away to care. In that case, you might implement a "message radius" and have the message dispatch system automatically make the query using, for example, an octree for objects within that radius, then send the message to the objects that the query returns. You'll save a lot of precious cycles that don't deserve to be wasted on sending messages to objects that don't need to receive them!

\$\endgroup\$
  • 1
    \$\begingroup\$ +1 to your reply, however, I think the OP is more interested on design patterns that can remove the necessity of directly accessing game entities or a global "world" object. Such as messaging. \$\endgroup\$ – glampert Aug 9 '14 at 22:37
  • \$\begingroup\$ No reason why a spatial data structure can't be used to cut down on the number of objects to send messages to. I'll actually add that to my post. \$\endgroup\$ – jmegaffin Aug 9 '14 at 22:39
  • \$\begingroup\$ I'm not interested in the world object architecture itself, but in a way to avoid having access to every game object from everywhere, the goal is to avoid ending with access from almost everywhere to everything. (and so having bug almost untraceable) (Is my question not clear enough about that ?) \$\endgroup\$ – anopse Aug 10 '14 at 9:18
  • \$\begingroup\$ I suggest editing your question so that it's clear that you're looking to decouple. \$\endgroup\$ – jmegaffin Aug 10 '14 at 12:20
  • \$\begingroup\$ +1 this is a really good answer about spatial partitioning and messaging. \$\endgroup\$ – ashes999 Aug 10 '14 at 16:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.