Скачать или смотреть Best Practices for Building Apple iOS Games (SpriteKit)

Sprite Kit provides a graphics rendering and animation infrastructure that you can use to animate arbitrary textured images, or sprites. Sprite Kit uses a traditional rendering loop where the contents of each frame are processed before the frame is rendered. Your game determines the contents of the scene and how those contents change in each frame. Sprite Kit does the work to render frames of animation efficiently using the graphics hardware. Sprite Kit is optimized so that the positions of sprites can be changed arbitrarily in each frame of animation.

Transcripts:

Best Practices for Building Apple iOS Games (SpriteKit)
@jtantwtr · Created 7/10/2014
Copyleft -- All Rights Reversed
Scalability
What are bad?

1. Changing art assets means changing code

2. Visual feedback is not available to designers, as they are not programmers

3. Codes as data is not efficient

4. Hard to change

Tips
Do not hardcode everything in one scene

Do not encode positions, hit points, states etc

Solution
1. Separate game content from game logic

2. Separate scene structure from assets

3. Separate data from code

4. Visualize in the tool (in this case obviously Xcode)

How?
Logic code in MyScene.m (default SpriteKit template as example)

Scene structure in MyScene.sks

Scene assets in separate .sks files

Keep the data in .plist files

Game Structure
Get your game running on the first day - yes, you need to play it yourself

Make sure it is done without sacraficing the scalability

Processes Involved
1. Make your generic level

2. Add placeholder content

3. Hook up interactions

4. Get the game logic working

5. Finish the game

Enumerate and Cache
Once you enumerate your game objects, choose to cache them instead of enumerating again if your logic allow

Scene Graph Search
In SpriteKit, one can perform a search against the scene graph based on the following:

1. Search by name

2. Search by class

3. Search with wildcard

Finish the Game
The process generally involved the following:

1. Add artwork - set the textures on your "red boxes"

2. Add levels

3. Add effects - Shaders as .fsh files, CoreImage filters

4. Play-test-iterate

Performance Best Practices
Drawing performance

Actions and constraints

Physics

Shapes

Effects

Lighting

Drawing Performance
Two factors:

1. Drawing order - how they are submitted to the graphics engine

2. Sharing of resource to accomplish the drawing

Tips #1
For drawing order, use sibling order to reduce the number of drawing submitted i.e. view.ignoreSiblingOrder = YES; and use z-depth to control the draw

In short, use depth order as the rules to batch them together and use texture map to optimize batching further

Share shaders, textures and procedural textures

Reference shaders from files, not strings

Put blend modes (e.g. SKBlendModeAdd) on the same z layer

Tips #2
Profile your game: Turn on performance metrics:

HUD flags on the view like

showsFPS (60 is great)

showsDrawCount (how many batches, 12 is a good one)

showsNodeCount (how many SKNode, 12 maybe)

showsQuadCount (good ones is like around 3450)

Actions and Constraints
Group your actions if you have to e.g. with SKGroup

Eliminate custom animation code from the update() and apply actions and constraints (like followpath in SKAction, OrientToNode in SKConstraints) to do the job

Tips
Build once and reuse the action(s)

Physics
Dynamic objects cost more than static objects, static objects are cheap even if the shape is complex

So if possible, set physicsBody.dynamic = NO

Circle is the cheapest, followed by rect, polygon, compound and alpha mask bodies in the order of increasing costs

Tips
Use collision masks to group objects for performance

You can use Force Fields to replace game logic

Turn on Field debug drawing if you have to

Shapes
Polygon Fill is the cheapest in term of performance cost, followed by Filled Curves, Linear Stroke, Stroked Curve and Stroked & Filled Curve in the order of increasing costs

Effects
SKEffectNodes are expensive and used it for offscreen rendering

Use SKShaders when no offscreen pass is needed

Rasterize complex effects only if they don't change too much

Lighting
Lighting costs proportional to lit pixels

Ambient light is free

Shadows cost proportional to the number of lights - keep them low!

References
https://developer.apple.com/videos/ww...

Thank you !