Дизайн игры: проверка пересечения объектов или получение значений из акселерометра

Question

В настоящее время я разрабатываю игру для iPhone, в которой игрок должен наклонить устройство, чтобы что-то сделать.Игра является чем-то вроде игры в память с четырьмя углами экрана, являющимися возможными целями.Цель игры - запомнить порядок, а затем переместить устройство в нужное место.

Мой вопрос больше касается дизайна движущейся механики.Два варианта, о которых я думал, заключались в том, чтобы получить значения от акселерометра напрямую, и когда они превышают определенное значение, возвращают, было ли это правильное место (то есть правильный угол для данной инструкции).Моя вторая идея состоит в том, что каждый угол будет иметь свой собственный CGrect, и акселерометр будет перемещать другой CGrect, и когда эти два пересекаются, он возвращается, было ли движение правильным или неправильным.?Я думаю, что данные акселерометра будут быстрее, но на них могут повлиять внезапные движения, в то время как другой путь может быть медленнее, но более точным.Дайте мне знать, что вы думаете.

Answer 1

Я думаю, вам стоит попробовать оба варианта, протестировать каждого из них на игроках и посмотреть, какие из них работают лучше. Принимайте решения о дизайне игры, когда это возможно, из пользовательского тестирования.

Мое предположение состоит в том, что вам нужно каким-то образом затухать или накапливать данные акселерометра, поскольку они шумные; и если вы интегрируете эти данные в скользящее среднее, то вы должны показать, где это скользящее среднее с , например, экранным спрайтом.

Возможно, вам даже не нужно использовать пересечение CGRect - если вы просто пытаетесь определить, находится ли 0 , y ₀ > в пределах r единиц 1 , y ₁ > тогда вы можете сделать это через простое пифагорейское расстояние . Но важно то, что если в алгоритме есть какое-то внутреннее состояние, вычисляющее, во что интегрированы данные акселерометра, то вам нужно показать это состояние на экране, чтобы чувствовать себя отзывчивым.