Я работаю над игрой в автомобильные гонки и только что реализовал призрачный спрайт для воспроизведения прошлых гонок. Я использую физический движок, и после долгих чтений я пришел к выводу, что лучший способ сохранить данные-призраки для воспроизведения - это записать положение и поворот автомобиля в заданные моменты времени, как, например, описано здесь: https: // gamedev. stackexchange.com/a/8380/26261 .
Но что было бы хорошим способом найти эти моменты во время воспроизведения? Примером может служить запись с этими данными:
time: +3.19932 (seconds since race start)
position: 180,40 (position at that time)
rotation: 30.4 (rotation at that time)
Но у меня есть несколько проблем с этим:
Когда я повторяю, маловероятно, что я снова достигну точного момента времени в 3.19932 - более вероятно, что у меня будет момент времени около 3.1 и мне нужно будет найти ближайшую соответствующую запись. При интерполяции даже самое близкое совпадение сверху и снизу. Это звучит очень неэффективно и отнимает много времени?
В какой структуре списка я могу хранить эти записи для последующего воспроизведения? Массив? Не означает ли это, что время поиска записей, соответствующих определенному времени, увеличится, чем дольше будет гонка?
Какую частоту я должен использовать для временных точек? Каждый кадр был бы, я думаю, излишним, скорее я должен сохранять, т.е. каждый n-й кадр и интерполировать между ними, что делает вопросы хранения в 2. еще более трудными.
Так эта идея даже правильный подход? Если да, как я могу эффективно хранить и извлекать данные? Обратите внимание, что я, как правило, хотел бы использовать приведенную выше структуру данных, а не детерминированные игровые состояния, запись пользовательского ввода и т. Д.
Спасибо за любую помощь!
РЕДАКТИРОВАТЬ: я понимаю, что я должен описать среду, которую я использую: Cocos2D для iPhone. Есть способ update:(ccTime)delta
. В идеале этот метод вызывается каждые 1/60 секунды, но нет никакой гарантии - delta
это фактическое время, прошедшее с момента последней игры, и оно может быть намного больше или меньше 1/60. Именно в этом методе я хотел бы сохранить текущее состояние игры.