Как стать автором
Обновить

Комментарии 17

  1. Где полный код?
  2. Вместо setInterval нужно использовать requestAnimationFrame
  3. Код нужно разделить на небольшие отдельные логические блоки и вынести в отдельные функции, чтобы не было лапши.
1.1. А еще лучше — демка на CodePen.
4. Говорящие сами за себя имена переменных предпочтительнее, чем имена из одной буквы + куча комментариев, поясняющих то, что было бы очевидно при нормальном именовании.
Вместо setInterval нужно использовать requestAnimationFrame

Меня всегда забавлял этот совет от людей, которые повторяют эту мантру, не понимая основного недостатка rAF и искренне считающих, что rAF — это какой-то вид оптимизации и вообще серебрянная пуля.

Ну так и расскажи. О чем комментарий-то?

Несмотря на то, что по ссылке сказано: «ее частота может быть снижена для вкладок невидимых.» — обычно выполнение функции rAF в фоновой вкладке полностью отключается, что допустимо для всяких жквери-анимаций, но недопустимо для более менее серьезных игр.
Понижение до 1 выполнения в секунду — значительно более удачное решение.

Да и какую реальную выгоду вы ожидаете от rAF в сравнении с sT?
но недопустимо для более менее серьезных игр

Из-за инкрементальной отрисовки? Тут этого нет.


Да и какую реальную выгоду вы ожидаете от rAF в сравнении с sT?

Плавность анимации и разгрузка браузера за счет плановых перерисовок.


И вот тут еще про это написано:


The problem with using setTmeout/setInterval for executing code that changes something on the screen is twofold.

What we specify as the delay (ie: 50 milliseconds) inside these functions are often times not honoured due to changes in user system resources at the time, leading to inconsistent delay intervals between animation frames.

Even worse, using setTimeout() or setInterval() to continuously make changes to the user's screen often induces "layout thrashing", the browser version of cardiac arrest where it is forced to perform unnecessary reflows of the page before the user's screen is physically able to display the changes. This is bad -very bad- due to the taxing nature of page reflows, especially on mobile devices where the problem is most apparent, with janky page loads and battery drains

Понижение до 1 выполнения в секунду — значительно более удачное решение.

А мне нравится, когда оно плавно от клетки к клетке переходит.

Из-за инкрементальной отрисовки? Тут этого нет.

В цикле игры есть не только рендер, но и логика. Если же разбивать их не отдельные запускающие функции, то будет обратная проблема (логика запускается чаще или реже, чем рендер).

Плавность анимации и разгрузка браузера за счет плановых перерисовок.

Увы, практика показала, что это миф.

unnecessary reflows

Не про canvas.

А мне нравится, когда оно плавно от клетки к клетке переходит.

Я про неактивную вкладку.
Играть в неактивной вкладке в серьезные игры это конечно нужно еще уметь =)
Жаль вас расстраивать, но все онлайн игры «играют» в момент неактивности, даже если вы не отдаете приказы. И если есть необходимость, к примеру, проиграть какой-то звук на определенный евент, то остановленная логика вкладки может этому помешать.
"Больше функций! Больше классов!" — стандартная мантра людей, после всяких школ/курсов/универов/<вписать своё>… людей, которые пришли к этому не из собственного опыта.

Как по мне все достаточно логично, поделено на отдельные блоки и понятно.
А самое главное — работает.
Остальное — на усмотрение автора.

На счёт именования переменных, тоже довольно спорный вопрос.
Исходя из опыта — да, правильно именованные переменные помогают понять код, когда ты возвращаешься к нему через время.

Но судя по всей этой затее — это просто «проба пера» и чрезмерное усложнение, ровно как и повторное использование кода, не про этот случай.
Так же, неплохо было бы дать переменным понятные имена.
Пример

if (d == 1)  f.x = l.x + s, f.y = Math.round(l.y / s) * s;

или

  if (d == 1) if (pob.x > Math.round(gP.width / s) * s) pob.x = 0;


Что такое pob, например? И как расшифровывается gP?
Сделать понятные имена и раскидать код по отдельным функциям, как предложено выше — и все комменты из кода можно будет убрать.
Сейчас комменты несут в себе расшифровку кода, а не пояснение действительно сложных алгоритмов/решений/паттернов и т.д.
sBody.splice(0,1); //Удаляем хвост.

почему не pop / unshift (в зависимости от того, где у змеи голова)?

ps: можно же и не перерисовывать всю змейку (или весь экран) каждый раз, достаточно очистить хвост и дорисовать голову ;-)

Спасибо за совет.

С читаемостью кода надо бы поработать

d = 1, //Направление змейки 1 — dправо, 2 — вниз 3 — влево, 4 — вверх.

ИМХО, куда удобней тут использовать текстовое значение «right», «down», ''left", «up», да и d ничего не говорящая буква, когда ее встретишь в коде, в отличии от «direction», например.

Согласен, код давно писал, для себя. Конечно, надо бы исправить.

Вопрос из чистого любопытства: я понимаю, что это javascript, что возможно в такой реализации есть некоторые неприятные особенности, но неужели сегодня такую простую игрушку все еще нужно оптимизировать, не считая очевидных вещей типа "стереть хвост, нарисовать новое положение головы, остальное не трогать"?


Ну т.е. я к чему это — я подобную штуку впервые писал кажется на ДВК-2, на бейсике, и даже тогда это не было нужно.

На бейсике у вас скорее всего появились бы тормоза, если бы вы попытались перерисовывать картинку на каждое движение змеи.

PS В глубоком детстве пытался делать динамичные игры на бейсике ZX Spectrum :) И до освоения ассемблера не очень клеилось.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории