Сохранился скриншот с того момента, когда пользователи массово создавали ишью
Некоторые можно найти закрытыми, например про пепси и кока-колу, некоторые были удалены
Реалтайм игры и так работают по UDP, так что быстрее всё-равно не получится
Обычная игра:
1) приходит стейт по сети
2) кадр рендерится и отображается для игрока
3) игрок нажимает кнопку — действие уходит на сервер
4) на сервере происходит «магия» с предсказанием и прочим
Игра на Stadia (предположительно):
1) сервер рендерит кадр и отправляет на комп игрока
2) кадр отображается
3) игрок нажимает кнопку
4) ??? (по идее та же магия)
Условный стейт получить и декодировать быстрее чем кадр из 4К видео, отсюда вывод — задержка будет больше
Стало интересно в чём проблема запаздывания короновского таймера. Сам код таймера есть на Github, как видно это просто обёртка над enterFrame, из этого следует что максимальная частота таймера равна частоте кадров (fps)
По сути вся проблема описанная в статье заключена в неправильном расчёте времени для следующего триггера:
if iterations > 0 then
entry._iterations = iterations - 1
end
local fireTime = currentTime + entry._delay
entry._time = fireTime
Если заменить строку local fireTime… на:
local fireTime = entry._time + entry._delay
И опробовать пример с модифицированной версией библиотеки, то оба таймера из примера будут работать одинаково.
P.S. Пулл реквест в репозиторий сделан, надеюсь в следующей версии короны это будет пофикшено и можно будет без проблем использовать долгие таймеры
Мне кажется тут вопрос мотивации и знания программирования в целом.
Если человек начинает делать игры не имея опыта в программировании, то «складывание кубиков» как раз таки поможет освоить движок и язык. Так же как изучение программирования начинают с простых алгоритмов и программ, а не с большого проекта.
Сужу в том числе по своему опыту: я уже около 5 лет работаю как .Net разработчик, уже год делаю свою игру (как хобби проект) и очень ограничиваю свою фантазию, чтобы наконец его закончить. Например: пошаговый бой (облегчает обработку команд игрока и ИИ), боевой ИИ просто выбирает действие по скриптованым приоритетам, перемещения в бою опять же нет.
И опыт промышленной разработки очень помогает в структурировании кода, в моём представлении человек который с нуля хочет стать инди и начинает сразу с ммо просто запутается в своём коде и игра так и не получится.
Возможно вы путаете network.request с библиотекой socket входящей в состав Corona? Код с использованием этой библиотеки выполняет синхронный (блокирующий) запрос:
local http = require( "socket.http" )
http.request{ ... }
Единственная моя претензия: текущий пример thread не показывает преимущество корутины (если вы не используете coroutine.yield то весь код функции всё-равно выполнится за один раз и заблокирует обновление экрана до конца выполнения).
Насколько я понимаю в Corona SDK нет ничего нового для корутин и resume блокирует основной поток (и отрисовку экрана). Соответственно приложение будет зависать на время выполнения resume. (Небольшой пример)
При использовании есть один существенный минус, если в коде перенесенном в нить возникнет ошибка вы об этом не узнаете
Resume возвращает boolean флаг указывающий произошла ли ошибка. Если флаг установлен в false то вторым возвращаемым значением будет сообщение с деталями ошибки.
Некоторые можно найти закрытыми, например про пепси и кока-колу, некоторые были удалены
Не подскажете, есть ли интервью в открытом доступе?
Обычная игра:
1) приходит стейт по сети
2) кадр рендерится и отображается для игрока
3) игрок нажимает кнопку — действие уходит на сервер
4) на сервере происходит «магия» с предсказанием и прочим
Игра на Stadia (предположительно):
1) сервер рендерит кадр и отправляет на комп игрока
2) кадр отображается
3) игрок нажимает кнопку
4) ??? (по идее та же магия)
Условный стейт получить и декодировать быстрее чем кадр из 4К видео, отсюда вывод — задержка будет больше
Стало интересно в чём проблема запаздывания короновского таймера. Сам код таймера есть на Github, как видно это просто обёртка над enterFrame, из этого следует что максимальная частота таймера равна частоте кадров (fps)
По сути вся проблема описанная в статье заключена в неправильном расчёте времени для следующего триггера:
Если заменить строку local fireTime… на:
И опробовать пример с модифицированной версией библиотеки, то оба таймера из примера будут работать одинаково.
P.S. Пулл реквест в репозиторий сделан, надеюсь в следующей версии короны это будет пофикшено и можно будет без проблем использовать долгие таймеры
Согласно таблице из официальной документации формат .caf работает только на iOS/macOS, не сталкивались ли вы с этим в реальном проекте?
Как я понимаю нужно держать музыку в двух форматах для разных систем (или использовать mp3)
Если человек начинает делать игры не имея опыта в программировании, то «складывание кубиков» как раз таки поможет освоить движок и язык. Так же как изучение программирования начинают с простых алгоритмов и программ, а не с большого проекта.
Сужу в том числе по своему опыту: я уже около 5 лет работаю как .Net разработчик, уже год делаю свою игру (как хобби проект) и очень ограничиваю свою фантазию, чтобы наконец его закончить. Например: пошаговый бой (облегчает обработку команд игрока и ИИ), боевой ИИ просто выбирает действие по скриптованым приоритетам, перемещения в бою опять же нет.
И опыт промышленной разработки очень помогает в структурировании кода, в моём представлении человек который с нуля хочет стать инди и начинает сразу с ммо просто запутается в своём коде и игра так и не получится.
Единственная моя претензия: текущий пример thread не показывает преимущество корутины (если вы не используете coroutine.yield то весь код функции всё-равно выполнится за один раз и заблокирует обновление экрана до конца выполнения).
Resume возвращает boolean флаг указывающий произошла ли ошибка. Если флаг установлен в false то вторым возвращаемым значением будет сообщение с деталями ошибки.
Согласно документации network.request уже является асинхронной функцией и смысла выносить её в отдельный поток я не вижу.