Comments 3
Что же это за флаппи берд вы такой придумали, чтобы вот это вот все?
Какой спавн объектов, производительность и коллизии? В оригинальной игре можно было обойтись десятком спрайтов и проверками уровня if (x>min && x<max). Если написать все тупо в лоб, то тормозить там в принципе нечему.
https://codepen.io/ju-az/pen/eYJQwLx/ – первыя ссылка из гугла, 100 строк кондового js вместе с комментариями. И наоборот, скорости надо скрутить – большинство старых js игр работают слишком быстро в современных браузерах.
Я с одной стороны согласен, а с другой ребят тоже можно понять - писать игры не их профиль и, наверняка, были какие-нибудь факторы которые вынуждали использовать сразу то, что просто начинало работать. Считаю, что если работает и все довольны, то уже хорошо :)
Я понял ситуацию ровно наоборот: у них был стек и идея игры, которую (предполагаю) можно было попробовать запустить наивно "в лоб" на текущем стеке. С реактом не работал, но все, что нужно по минимуму: функция-апдейт, которая будет вызываться фиксированное количество раз в секунду (30–60 fps подойдет) и возможность менять координаты десятку png-шек из этой функции. Алгоритм можно было адаптировать из примера по ссылке (первая из поисковика по запросу вывалилась).
Если знать, как на текущем стеке делать эти вещи, то адаптация решения для "попробовать" должна занять от силы пару часов.
Но это решение командой было отброшено на предварительном обсуждении из-за "тормознутости реакта", а в ход пошли тяжеловесные игровые движки, муки интеграции, билды по 800 мб и прочие ужасы, от которых волосы шевелятся.
А кончилось все:
ведь мы так и не довели игру до продакшена.
Если цель была – опробовать технологии для внедрения сложных игр в приложение на реакте, то решение может и оправданное. Если же просто зашипить "флапи берд"...
Никому не советую, но мы попробовали, или Интеграция игры в React Native с помощью Unity, Game Engine и Godot