0

I'm not really sure this question really is about containers, please bear with me.

A game has 'turns' that are incremented, there is no Timer that fires at a certain time.

Now there is also a large bucket of objects, where some of them need updating somtimes. What will happen is that object o1 needs to be updated in n1 turns, object o2 in n2 etc.

The simple solution would:

for (object* o : objectVector) {
   o->ctr--;
   if (o->ctr == 0) { o->update(); };
}

Now I feel this is terribly inefficient, if I crawl through 1000 objects counters each turn, just to update maybe 10 of them. I'm sure this problem has come up before somewhere!

Also, I can probably allow objects to sometimes update at +/- a few turns around their expected update.

I was thinking I could have many vectors, one for the next 5, one for the 5-10, one for 10-15 turns in the future and so forth. But then I have too many vectors, should some objects only need to be updated in say, 100 turns..

Bersaelor
  • 2,517
  • 34
  • 58
  • 3
    I would be more concerned by the fact that the code is modifying copies of the objects, not the ones that are in the container. – juanchopanza Oct 15 '14 at 09:16
  • Sorry, it was just pseudo-code to illustrate the idea, so I will make it more like the actual code in my program. – Bersaelor Oct 15 '14 at 09:17
  • 1
    "But then I have too many vectors" - "too" many? why? seems perfectly ok to me. you could even have one for each turn. – Karoly Horvath Oct 15 '14 at 09:19
  • You say you "feel" this is terribly inefficient. It's an optimization concern. First thing to do: you should measure this. – JBL Oct 15 '14 at 09:20
  • No, it is usually touching a lot of other things & doing some calculations. At the end it might set ctr back to some number in [10,100] or take the object o out of the loop entirely (don't comment on not taking objects out of vectors while looping please, I know how that works). – Bersaelor Oct 15 '14 at 09:21
  • @KarolyHorvath you are right, do you wanna write down the answer or should I? Like having 10 vectors that are looped through in turn, and if one needs an update in 47 turns the object is put in vector 7. (Where one can play with the parameter n=10) – Bersaelor Oct 15 '14 at 09:23
  • 1
    nah I'm lazy. since it's about optimization, you have to measure it, otherwise it's just guessing... and I wouldn't consider that an answer. My bet (fastest first): 100 vectors, 10 vectors, no vectors. and if the objects are really small, the no vectors solution might be the fastest. also note, that with 100 vectors, you might be able to remove `ctr` from the object. – Karoly Horvath Oct 15 '14 at 09:30
  • @KarolyHorvath will do! – Bersaelor Oct 15 '14 at 09:33
  • related: http://gameprogrammingpatterns.com/data-locality.html – Karoly Horvath Oct 15 '14 at 09:36

1 Answers1

1

If this is really an issue, you could group them by their object::ctr value. For example in such a container (assuming object::ctr has type size_t)

::Std::unordered_map<size_t, ::std::vector<object*>>

This requires a bit of maintenance, as you have to make sure to get rid of empty vectors once one particular bucket runs empty. But in case you don't require the ctr member abywhere else, you can completely remove it and save iteration over the entire collection (you just move vectors from one bucket to the next smaller one).

bitmask
  • 32,434
  • 14
  • 99
  • 159
  • I think this approach would still mean cycling through all containers each turn, moving objects into the next smaller one. Don't really see how this is better then the algorithm above. – Bersaelor Oct 15 '14 at 09:33
  • No, as I tried to explain, you don't have to touch every single `object`, you merely move the vectors which *can* be implemented in constant time for each vector-move. Of course, if you get really sparse vectors it will degenerate. This will require you to either a) remove the `ctr` member from `object` or b) pool `ctr` objects and share them across all `objects` in the same vector, so you only have to decrement them once. – bitmask Oct 15 '14 at 09:36