0
\$\begingroup\$

I'm working on a turn-based strategy game for iOS, (picture Civilization 2 as an example), and I'm considering using a UICollectionView as my game map. Each cell would be a tile, and I could use the "didSelectCell" method to handle player interaction with each tile.

Here's my question: I know that UICollectionViewCells are dequeued and reused by the OS, so does that mean that the map could support an effectively infinitely-large map, so long as only a few cells are onscreen at a time? However many cells were onscreen would be held in memory, and obviously the data source would take up some memory, but would my offscreen map be limited to a certain size or could it be enormous so long as the number of cells visible at any one time wasn't too much for the device to handle? Basically, is there any memory weight to offscreen cells, or do only visible cells have any impact?

\$\endgroup\$
  • 1
    \$\begingroup\$ Your secondary question about "is this a good idea" is probably too discussion-oriented for the site (but the Game Development Chat might be interested in talking about it). It's also possible you would get a more-detailed answer about the memory implications of the collection view on SO itself. If you want, I could migrate the question there. \$\endgroup\$ – Josh Aug 19 '14 at 23:03
  • \$\begingroup\$ If that's where you think it ought to be, then transfer away! :) I just put it here because SO seems to get twitchy about theoretical questions where there's no code to look at... \$\endgroup\$ – Nerrolken Aug 19 '14 at 23:53
2
\$\begingroup\$

Interesting idea. It's a bit "square peg, round hole," but it could work. The biggest problem I foresee is in dealing with the animation of any sort of sprite that needs to transition from one cell to another smoothly. You'll probably have to do some hoop-jumping to make that work well, especially in the context of a scroll operation (which you'll also need to handle or disable if you don't want the user to be able to scroll around the view as they normally would).

The purpose of the reusable cell mechanism in UICollectionView and UITableView is to minimize the memory footprint of view-related "stuff" while displaying the collection. To that end, yes, if you use the mechanism correctly you will have a more-or-less constant memory footprint for the map view (based on size of your cells, which naturally define how many will be on-screen simultaneously). The API will reuse cell views as efficiently as it can.

However that does not mean you can have an effectively-infinite map just by relying on UICollectionView. It just means you don't have to deal with the paging/view reuse yourself. You do need to deal with paging the actual map data (in practical terms, the stuff reported by the UICollectionViewDataSource, in your case the actual tile properties).

But, yes, you can scale the amount of loaded map data independently from the number of visible cells.

\$\endgroup\$

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.