SpriteKit模板中GameScene.swift和GameScene.sks文件之间的关系是什么

时间:2022-03-18 11:14:21

I've been playing around with SpriteKit, and am getting a pretty decent feel about how to drive it from code, but am pretty baffled by the level editor included in Xcode 6.

我一直在玩SpriteKit,并且对于如何从代码中驱动它感觉非常体面,但我对Xcode 6中包含的关卡编辑器感到非常困惑。

I've watched the wwdc videos ("platforms state of union" and "what's new in spriteKit"), and scrounged around the web, but haven't been able to find much description about the level editor, and what it's really doing.

我已经观看了wwdc视频(“平台状态​​联盟”和“spriteKit中的新内容”),并在网络上徘徊,但未能找到关于关卡编辑器的更多描述,以及它真正在做什么。

What I don't understand, is how are the two files that the template sets up related? Is the .sks file an expression of the GameScene.swift file, or perhaps the GameScene class it contains?

我不明白的是,模板设置的两个文件是如何相关的? .sks文件是GameScene.swift文件的表达式,还是它包含的GameScene类?

OR do they both just hold separate objects/nodes that are going to play together in the same scene?

或者它们是否只是在同一场景中保持将要一起播放的单独对象/节点?

Or (this is my best explanation) is the .sks file and the editor basically for making the environment that responsive characters are going to "live" in? If that's true, how can my code in the .swift file relate to what's in the .sks file?

或者(这是我最好的解释)是.sks文件和编辑器基本上是为了使响应角色能够“生活”的环境?如果这是真的,.swift文件中的代码如何与.sks文件中的代码相关?

1 个解决方案

#1


24  

The .sks file is a static archive of your scene's content. If you've used Interface Builder to set up UI apps before, it's much the same idea, if rather different in implementation.

.sks文件是场景内容的静态存档。如果您以前使用Interface Builder来设置UI应用程序,那么它的想法就差不多了,如果实现方式不同的话。

In a UI app, you could do everything in code:

在UI应用程序中,您可以在代码中执行所有操作:

override func viewDidLoad() {
    let someText = UITextField(...)
    let aButton = UIButton(...)
    // ... position everything
    // ... style everything
    // ... etc ...
}

Or you could do all the static content setup in IB (a xib or storyboard), and use code only for setting up the dynamic behavior of your app — the things that happen when somebody starts touching those buttons. When you do that, the view controller you write code for exists as a proxy object in the xib/storyboard, making a bridge between what you set up in IB and what you set up in code.

或者你可以在IB(xib或故事板)中进行所有静态内容设置,并仅使用代码来设置应用程序的动态行为 - 当有人开始触摸这些按钮时发生的事情。当您这样做时,您编写代码的视图控制器作为xib / storyboard中的代理对象存在,从而在您在IB中设置的内容与您在代码中设置的内容之间架起了一座桥梁。

In SpriteKit, you have the same choice. Before Xcode 6, many SK games took the all-code approach:

在SpriteKit中,您有相同的选择。在Xcode 6之前,许多SK游戏采用了全代码方法:

override func didMoveToView(view: SKView) {
    let player = PlumberSprite(color: .Red)
    player.position = // ...
    player.physicsBody = // ...
    self.addChild(player)
    let ground = SKSpriteNode(...)
    ground.position = // ...
    ground.physicsBody = // ...
    self.addChild(ground)
    let block = QuestionBlockSprite()
    block.position = // ...
    block.physicsBody = // ...
    block.contents = CoinSprite()
    self.addChild(block)
    // ... etc etc etc ...
}

That's a lot of code for what's ultimately a graphical, static scene — even before you start adding code to make it into a game (input handling, enemy behavior, physics callbacks that increment the score or go to game over, etc). And it doesn't lend itself well to designs where you split out the general game logic from the content, so it's harder to add multiple levels to your game.

即使在你开始添加代码以使其成为一个游戏(输入处理,敌人行为,增加分数或游戏结束的物理回调等)之前,这仍然是很多代码,最终是一个图形化的静态场景。并且它不适合于从内容中分离出一般游戏逻辑的设计,因此在游戏中添加多个级别会更加困难。

Instead, you can use the SpriteKit editor in Xcode to build your static content (levels), and stick to code for dynamic behavior and game logic. Just like how, in IB, the view controller is a bridge between your storyboard and your code, your scene class (GameScene.swift in the template) is the bridge between the editor and code. When you load an .sks file at run time (the code for this is in GameViewController.swift in the template), it becomes an instance of your GameScene class, and anything you set up in the editor is accessible as child nodes of the scene.

相反,您可以使用Xcode中的SpriteKit编辑器来构建静态内容(级别),并坚持使用动态行为和游戏逻辑的代码。就像在IB中,视图控制器是故事板和代码之间的桥梁一样,场景类(模板中的GameScene.swift)是编辑器和代码之间的桥梁。当您在运行时加载.sks文件(此代码在模板中的GameViewController.swift中)时,它将成为您的GameScene类的实例,并且您在编辑器中设置的任何内容都可以作为场景的子节点访问。

Checking out WWDC talks is a good idea, but you missed the one that covers this: see session 608: Best Practices for Building SpriteKit Games for more on the motivation behind the SpriteKit editor, how to use it, and how to work with the scene contents loaded from an .sks file in your scene code.

查看WWDC会谈是一个好主意,但是您错过了涵盖此内容的那个:请参阅会话608:构建SpriteKit游戏的最佳实践,了解更多关于SpriteKit编辑器背后的动机,如何使用它以及如何使用场景从场景代码中的.sks文件加载的内容。

#1


24  

The .sks file is a static archive of your scene's content. If you've used Interface Builder to set up UI apps before, it's much the same idea, if rather different in implementation.

.sks文件是场景内容的静态存档。如果您以前使用Interface Builder来设置UI应用程序,那么它的想法就差不多了,如果实现方式不同的话。

In a UI app, you could do everything in code:

在UI应用程序中,您可以在代码中执行所有操作:

override func viewDidLoad() {
    let someText = UITextField(...)
    let aButton = UIButton(...)
    // ... position everything
    // ... style everything
    // ... etc ...
}

Or you could do all the static content setup in IB (a xib or storyboard), and use code only for setting up the dynamic behavior of your app — the things that happen when somebody starts touching those buttons. When you do that, the view controller you write code for exists as a proxy object in the xib/storyboard, making a bridge between what you set up in IB and what you set up in code.

或者你可以在IB(xib或故事板)中进行所有静态内容设置,并仅使用代码来设置应用程序的动态行为 - 当有人开始触摸这些按钮时发生的事情。当您这样做时,您编写代码的视图控制器作为xib / storyboard中的代理对象存在,从而在您在IB中设置的内容与您在代码中设置的内容之间架起了一座桥梁。

In SpriteKit, you have the same choice. Before Xcode 6, many SK games took the all-code approach:

在SpriteKit中,您有相同的选择。在Xcode 6之前,许多SK游戏采用了全代码方法:

override func didMoveToView(view: SKView) {
    let player = PlumberSprite(color: .Red)
    player.position = // ...
    player.physicsBody = // ...
    self.addChild(player)
    let ground = SKSpriteNode(...)
    ground.position = // ...
    ground.physicsBody = // ...
    self.addChild(ground)
    let block = QuestionBlockSprite()
    block.position = // ...
    block.physicsBody = // ...
    block.contents = CoinSprite()
    self.addChild(block)
    // ... etc etc etc ...
}

That's a lot of code for what's ultimately a graphical, static scene — even before you start adding code to make it into a game (input handling, enemy behavior, physics callbacks that increment the score or go to game over, etc). And it doesn't lend itself well to designs where you split out the general game logic from the content, so it's harder to add multiple levels to your game.

即使在你开始添加代码以使其成为一个游戏(输入处理,敌人行为,增加分数或游戏结束的物理回调等)之前,这仍然是很多代码,最终是一个图形化的静态场景。并且它不适合于从内容中分离出一般游戏逻辑的设计,因此在游戏中添加多个级别会更加困难。

Instead, you can use the SpriteKit editor in Xcode to build your static content (levels), and stick to code for dynamic behavior and game logic. Just like how, in IB, the view controller is a bridge between your storyboard and your code, your scene class (GameScene.swift in the template) is the bridge between the editor and code. When you load an .sks file at run time (the code for this is in GameViewController.swift in the template), it becomes an instance of your GameScene class, and anything you set up in the editor is accessible as child nodes of the scene.

相反,您可以使用Xcode中的SpriteKit编辑器来构建静态内容(级别),并坚持使用动态行为和游戏逻辑的代码。就像在IB中,视图控制器是故事板和代码之间的桥梁一样,场景类(模板中的GameScene.swift)是编辑器和代码之间的桥梁。当您在运行时加载.sks文件(此代码在模板中的GameViewController.swift中)时,它将成为您的GameScene类的实例,并且您在编辑器中设置的任何内容都可以作为场景的子节点访问。

Checking out WWDC talks is a good idea, but you missed the one that covers this: see session 608: Best Practices for Building SpriteKit Games for more on the motivation behind the SpriteKit editor, how to use it, and how to work with the scene contents loaded from an .sks file in your scene code.

查看WWDC会谈是一个好主意,但是您错过了涵盖此内容的那个:请参阅会话608:构建SpriteKit游戏的最佳实践,了解更多关于SpriteKit编辑器背后的动机,如何使用它以及如何使用场景从场景代码中的.sks文件加载的内容。