0

I have a custom struct for a world tile in an iOS game. I want to store multiple WorldTiles in an array but am not sure what the most efficient way is. It's an infinite-map style game and I'm loading only chunks around the player, so I want the fastest way of storing the data.

I could store this in a c-based multidimensional array (WorldTile tiles[16][16]) but I don't see a way to make it an @property for easier access outside the class, or I could wrap this using NSValue and store in an NSArray but that seems like overhead I don't need.

typedef struct {
    b2Vec2 coord;
    float height;
    float temperature;
} WorldTile;

How can I either store the multi-dimensional array as an @property, or is the performance cost of wrapping it with an NSValue not a big deal?

Community
  • 1
  • 1
helion3
  • 34,737
  • 15
  • 57
  • 100
  • What's wrong with using a class instead of a struct? – CrimsonChris Jul 22 '14 at 20:08
  • Nothing's wrong with that, and it's how I had this originally - it just seems like overhead I don't need. All I need is a way to store these values together - no need for additional methods, NSOBject, etc. I have no idea what performance difference there is, but it seems like a struct is faster. I'll research that though – helion3 Jul 22 '14 at 20:10
  • Do you have a performance problem? Have you confirmed that this is the cause of it? Don't try to optimize for a problem you don't have. Classes are more extensible than structs. – CrimsonChris Jul 22 '14 at 20:18
  • No performance problem, no but this information is looped a lot and I want to avoid any overhead if possible. It would also be beneficial to store the tile by the internal x/y of the tile in the multidimensional array - we can then access a tile at a specific coord with tiles[x][y] rather than iterating an NSArray looking for a match. – helion3 Jul 22 '14 at 20:24
  • You don't have to iterate through an NSArray to access an object at a specific index. To get your tile you'd just use `tiles[x][y]`. – duci9y Jul 22 '14 at 20:45

1 Answers1

2

I think the issue is with "overhead I don't need". Try using objects first, determine performance issues empirically, then tune your objects, then resort to C (then become surprised that the object overhead you were concerned about is not nearly as big of a deal as one would have thought in the last century).

The OO way is that the World is singular, but has a collection of things in it. That's an NSArray of Things. Those things in turn probably consist of a collection of other things, so Thing has an NSArray property of OtherThings. Multidimensionality achieved, but more importantly, object orientation achieved.

Is the world huge? It should only be built based on proximity to the player? That's fine. Things can be designed to be just stub-Things, which only know location, but initialize themselves when the user becomes proximal. You'll be much more able to understand and therefore optimize this code. In this way, the object oriented system is going to be faster because it allows you the expressive power to make a faster design without doing mental gymnastics.

danh
  • 62,181
  • 10
  • 95
  • 136