SpriteKit game map architecture

Question

I’m pretty new to SpritKit, and am trying to figure out the best direction to take when creating the maps for a game I’ve started.

The maps are track-like... sometimes a road sometimes a tunnel, etc. I‘ve creates two levels so far, and they work great. They are currently giant 5000x5000 pixel images with a matching 5000x5000 pixel mask image overplayed and hidden for the collision detection. Performance is great, works like a charm. However, app size is my concern. The PNGs are pushing 8-10MB, and I fear the game will quickly turn into a needlessly large download as soon as I get a small handful of levels in there. They are very cartoonish and hopefully Xcode compression routines will go a long ways... however, would a tile based setup be better vs. a single monolithic image?

Some if these maps have an extreme amount of trees. The level that sparked my concern is a road going through a forest (top down and cartoony 2D). I know that I‘d save tons of space, and have a much smaller app package if I pieced the map together reusing a small handful of tree sprites all over the map vs. one giant 5000x5000 pixel image with the trees drawn on... but how will that perform? We’re talking 1000+ tree sprites vs. a single giant SKSpriteNode.

The giant image route is quick and easy to create levels, but not at the cost of my app being 2GB in the App Store 😟. Or will the PNG compression processing during the publishing step be extremely significant? If I go the individual sprites route I will likely need to take s step back and create a level editor and my own “map file” format... cause from what I’ve seen so far, the scene editor is not going to handle what I need to throw at it to do this.

Thanks!

Xcode

1.3k

Posted by

clayosborn

Reply

Add a Comment

Answer 1

If each level has only a couple of 5K x 5K images, then you can probably continue using this approach. Since you can control what's loaded for the current level, you can prevent memory use from ballooning. If you're going to have dozens or hundreds of levels, I suggest you look into ODR (on demand resources) to avoid big downloads.

Or, switch to using a Sprite Kit tile map. But in that case, your trees are going to be laid out in a grid. (You can vary this by having multiple tree tiles, but there's still going to be a gridded look to the game.) Note that Xcode has a built in terrain editor.

Also, look at GameplayKit to see if there's anything useful for you there (quad trees, obstacles, path detection). No need to reinvent stuff if you don't need to.

Ultimately, if you want to have complete creative control of the appearance of your game, you might want to get into Metal. Big learning curve, but you can do what you want.

Posted by

QuinceyMorris

Add a Comment

Answer 2

If each level has only a couple of 5K x 5K images, then you can probably continue using this approach. Since you can control what's loaded for the current level, you can prevent memory use from ballooning. If you're going to have dozens or hundreds of levels, I suggest you look into ODR (on demand resources) to avoid big downloads.

Or, switch to using a Sprite Kit tile map. But in that case, your trees are going to be laid out in a grid. (You can vary this by having multiple tree tiles, but there's still going to be a gridded look to the game.) Note that Xcode has a built in terrain editor.

Also, look at GameplayKit to see if there's anything useful for you there (quad trees, obstacles, path detection). No need to reinvent stuff if you don't need to.

Ultimately, if you want to have complete creative control of the appearance of your game, you might want to get into Metal. Big learning curve, but you can do what you want.

Posted by

QuinceyMorris

Add a Comment

Answer 3

Thanks for the input, this helps a ton.

ODR looks pretty promising and exciting 🙂 When I first read that I initially thought "I can't afford to host anything", but Apple hosts it, so that's down right sweet.

I will most definatly be getting into Metal at some point for additional games in the future. I am coming from a huge background of OpenGL and Direct3D work in the past, and have a vast set of OpenGL ES libraries and engine work I had written and utilized already in iOS. Unfortunately, I am going to have to disappointingly abandon all of that due to Apple's recent decision to deprecate OpenGL. It will be easy for me to pick up Metal fast... but I need to get something quick out the door now in the meantime, so I've taken this step backwards into a much simpler 2D model before redoing all of my much more complicated 3D projects.

Again, thanks.

Posted by

clayosborn

Add a Comment

SpriteKit game map architecture

Accepted Reply

Replies