【问题标题】:SpriteKit Networking Physics (Various Devices)SpriteKit 网络物理(各种设备)
【发布时间】:2015-07-31 04:09:45
【问题描述】:

我正在开发一款可联网的 SpriteKit 游戏。我遇到的问题是物理在不同的设备和屏幕尺寸上有所不同。iPhone 5s、iPhone 6+、iPad Mini 2 Retina、iPad 2、MBP 17 和 Air 11。

玩家在这样定义的场景中玩耍:self an SKScene, gameScene.m.

出于各种原因,我将 gameScene.sks 的大小设置为 414x414 并使用 createSceneContents:

self.scaleMode = SKSceneScaleModeAspectFit;
self.anchorPoint = CGPointMake(0.5,0.5);
self.size = CGSizeMake(self.size.width*4, self.size.height*4);

我做 *4 是因为我要添加放大到 1x 2x 4x。

开始的基础是两个对峙的生物。 我使用以下方法设置它们的质量和密度:

char.physicsBody.density = 1.0;
char.physicsBody.mass = 1.0;

我读到更改它们会解决不同的设备/屏幕问题(错误)。

当一个人向另一个人移动时,当它们发生碰撞时,我会得到不同的结果。 在 Mac 上,当撞击另一个(iOS)生物时,Mac 生物会停止并且不能让另一个。 iOS char 可以撞击 Mac 生物并将其推向四周。

我进去改变了质量和密度,基于:

场景占据了设备中间的一个正方形,因此边界宽度就是设备的宽度。我需要在这里输入什么黄金数字才能使 iOS 设备与 Mac 设备相等。

// CGFloat result = [[UIScreen mainScreen] bounds].size.width //maybe later :)
CGFloat ratio = 414/3000;

char.physicsBody.density = 1.0*ratio;
char.physicsBody.mass = 1.0*ratio;

这只是我开始的基本起点。原因是我相信 SpriteKit 使对象在屏幕之间成比例(边界到边界,设备到设备)。但主要是 Mac 到 iOS 还差得很远。 Mac 到 Mac 甚至是头对头竞争,我不需要改变质量/密度。

代码在我的 Xcode.project 文件中,它们共享源代码,并从中编译。

这个块是用来来回的:

#ifdef IOS_BLOCK
    CGFloat ratio1 = (414.0/3000);
    CGFloat ratio2 = 1;
    _playerChar.physicsBody.mass = _playerChar.physicsBody.mass*ratio1;
    _playerChar.mainThrust = 160*ratio1;
    _playerChar.reverseThrust = 80*ratio1;
    _playerChar.lateralThrust = 0.4*ratio1;

    _opposeChar.physicsBody.mass = _opposeChar.physicsBody.mass*ratio2;
    _opposeChar.mainThrust = 160*ratio2;
    _opposeChar.reverseThrust = 80*ratio2;
    _opposeChar.lateralThrust = 0.4*ratio2;
#else
    CGFloat ratio1 = 1;
    CGFloat ratio2 = (414.0/3000);
    _playerChar.physicsBody.mass = _playerChar.physicsBody.mass*ratio1;
    _playerChar.mainThrust = 160*ratio1;
    _playerChar.reverseThrust = 80*ratio1;
    _playerChar.lateralThrust = 0.4*ratio1;

    _opposeChar.physicsBody.mass = _opposeChar.physicsBody.mass*ratio2;
    _opposeChar.mainThrust = 160*ratio2;
    _opposeChar.reverseThrust = 80*ratio2;
    _opposeChar.lateralThrust = 0.4*ratio2;
#endif

注意:我在 Mac 与 Mac 或 iOS 与 iOS 中将其更改为 1:1

这个 3000 的值似乎在使用操纵杆、键盘和 UIButtons 等的头撞比赛中阻止了事情。

但我的问题是这个比率的“权重”基于什么? 414/3000 我的意思是它可能是 500/3000、1/6,这也会使事情变得相当接近。

但是对于比率的需求是什么?为什么 iOS 与 iOS 和 Mac 与 Mac 在 1:1 时工作,而当 iOS 与 Mac 为 6:1 时?我必须除以比率。

我希望在所有使用 SpriteKit 的设备上都获得 EQUALIZED。 顺便说一句,精灵大小是: 102/204/306 (iOS) 和 120/240(苹果机) 提前感谢您的帮助。

【问题讨论】:

  • 好吧,我做了更多的测试,414/3000 头在 iPhone 6 模拟器和 Mac 上是一样的,但在较小的设备 iPhone 4s/5s 甚至更大的 iPad Air 2(模拟器)上,Mac 胜出头撞。我一直在来回寻找一些在线信息,但我要重新开始阅读而不是敲打......
  • 我正在添加此评论,因为我有点发疯了,因为我试图总结这一点,这是我总结这个问题的最佳方式。我在不同的设备上得到了不同的结果,但总的来说,Mac 与 iOS 的比例大约为 1:6,物体更重,即更难移动。当我调整因素时:推力和质量我可以得到相当平等的东西,但有什么关系呢?他们共享相同的源代码嗯...
  • 我从苹果文档中读到:在真实硬件和具有不同特性的设备上测试您的游戏。在很多情况下,每台 Mac 或 iOS 设备上 CPU 资源和 GPU 资源的平衡是不同的。在多个设备上进行测试可帮助您确定您的游戏是否在大多数设备上运行良好。 WOW OK :( 真可惜,也许这已经回答了,但是,我需要第二个意见?

标签: ios objective-c macos sprite-kit skphysicsbody


【解决方案1】:

一切都是关于物理低点! 您必须注意到,当您更改设备屏幕尺寸时,物理点视图中的某些内容正在发生变化。 例如:

假设你想对一个半径为 20、密度为 1 的球施加 100 个脉冲。

您在 5s 模拟器中看到球比 6s 或 iPad 模拟器跑得更快。 为什么?

因为物理学!

让我们看看:

在物理低点中,冲动的关系是

p = mv

其中p是动量,m是质量,v是速度。

现在让我们进行一些简单的物理计算:

密度 = m/A(m:质量,A:面积)

我们假设密度 = 1 所以

m = A = pi*(r)^2 (r: 半径)

我们提到了动量:

p = mv => v = p/m => v = p/(pi*(r)^2)

你施加了 100 次冲动,所以

(p = 100) => v = 100/(pi*(r)^2)

我再次提醒 v 是速度,r 是半径。 你看

v ∼ 1/(r^2)

这意味着 v 以 1/(r^2) 增长

这意味着如果你扩大你的球的物理半径,屏幕尺寸和恒定动量速度会减小!

恒定半径呢?

例如,您将球的物理半径设置为 20,并且它不会随屏幕大小而改变。

所以:

v = 100/(pi*(20)^2)

想象速度为 50(这只是假设而不是真实的!)

表示你的球以每秒 50 点的速度在 5s 中移动,由于 5s 的宽度为 568 点,因此球每秒移动约 (5sWidth)*1/10。

对于 iPad Air,宽度为 1024,因此以相同的速度,球的速度约为 (iPadAirWidth)*1/20/秒。

这意味着速度正在降低。

你看,谜题解决了!

因此,在 spriteKit 中使用物理时,您必须适合您的物理属性和屏幕尺寸。

【讨论】:

  • 这是真的......我们只能照顾这么多......:D
  • @rezwits 所以如果你觉得有帮助,请接受我的回答
【解决方案2】:

答案是 Apple 的文档说明:在真实硬件和具有不同特征的设备上测试您的游戏。在很多情况下,每台 Mac 或 iOS 设备上 CPU 资源和 GPU 资源的平衡是不同的。在多台设备上进行测试可帮助您确定您的游戏是否在大多数设备上运行良好。

我认为 sprite kit 会在不同设备之间保持统一,这在一定程度上是一致的,但会有细微的变化。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-05-28
    • 1970-01-01
    • 2013-11-22
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多