dollar

Проверьте наличие блокировок на официальном сайте:
https://blocklist.rkn.gov.ru/

Ну или поставьте себе расширение типа RKN Alert, чтобы чуть удобнее узнавать, заблокирован ли текущий сайт и каким методом.

Примерно так:

let timer_wait_4 = setInterval(e=>{
  let arr = document.querySelectorAll(".jp-playlist ul li");
  if (!arr || arr.length < 4) return;
  clearInterval(timer_wait_4);

  $('.jp-playlist ul').each(function(i, el) {
    console.log($(el).children('li'));
  });

},200);

Но учтите, что это не самое элегантное решение, своеобразное, костыльное. Зато решение.

Дело в том, что дедик, равно как и паутина дедиков, усложняют (но не предотвращают) лишь тупой анализ ip.

Вы же не думаете, что деанонимизируют исключительно по IP?

Если вы, будучи якобы 100% анонимным, зашли на VK Васи, то у него всего лишь 500 друзей, и все они живут в РФ. А потом вы зашли на VK Кати, у которой внезапно такой же город, как у Васи, и всего лишь 1 общий друг с Васей. Конечно, это еще не доказательство, но дальше к этому "другу" приезжают домой (тоже внезапно, без предупреждения) и смотрят комп. А там - опа, ваша система подключения через паутину дедиков плюс прочий компромат, который вы старательно пытались скрыть.

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

Для начала определитесь с целью. Если ваша цель - деньги, то в геймдев идти не стоит, лучше пойти в банковскую сферу, там платят гораздо больше.

Ну а если не деньги, то всё равно цель нужно четко понимать. Тогда уже можно будет предметно отвечать как, зачем, почему, стоит ли и т.д.

Не используйте GameMaker Studio, я пробовал, не понравилось, слишком много ограничений.
А синтаксис там вообще "волшебный". Присвоение значения переменной изменит переменную у всех объектов такого типа и прочие несуразности.

Лучше переходите на Unity. Это уже классика.

Насчет векторной графики, ее практически не используют. Точно не скажу, но по моим представлениям нарисовать на экране произвольный многоугольник с 10 вершинами и закрасить его будет использовать больше вычислительных ресурсов, чем скопировать готовое изображение из памяти. То есть теоретически векторная графика может дать выигрыш в размере билда и занимаемой оперативной памяти в рантайме, но увеличивает нагрузку на батарейку смартфона и повышает минимальные системные требования для игры (кроме памяти).

Зависит от того, как осуществляется авторизация. Например, если по MAC-адресу основного коммутатора, то нет, нельзя.

В любом случае это имеет мало смысла. Ведь по отдельному подключению провайдер предоставляет Интернет с определенной скоростью, а так вы делите канал пополам.

Вы - не показатель.

Чтобы делать выводы на генеральную совокупность (все люди), нужно выделить репрезентативную выборку и с некоторым приближением можно будет говорить о трендах в мире.

А то, что 50% американцев устанавливает 0 приложений в месяц, это слабый аргумент. Может быть, в прошлом месяце было 60%? Уверен, что лет 100 назад было ровно 100%. Нарисуйте график для начала, а там видно будет.

Если игра представляет из себя отдельный файл или проект в папке, то поделиться без скачивания нельзя. Когда вы даете поиграть в игру на флеше, даже если она отображается только в браузере, он всё равно скачивает её в виде файла и сохраняет где-то у себя в кеше на диске. И пользователь при желании может достать этот файл.

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

Как вариант, если вы хотите показать примерно дизайн игры и ее возможности, то можно организовать конференцию с человеком, или дать ему удаленное управление своим экраном. Это можно сделать, например, программой TeamViewer (она умеет в управление и в конференцию). Такой вариант не подойдет только в случае каких-нибудь тяжелых шутеров со сложной графиков, высоким FPS и высокими требованиями к реакции игрока. Если же ваша игра на флеше, то проблем быть не должно.

В ячейку C1 нужно подставить формулу:
=A1

А в ячейку C2 нужно подставить формулу:
=IF(A2="";C1;A2)

Затем эту формулу растянуть на всю колонку.

Не тестировал, так как вы - нехороший человек, и не оставили ссылку на пример в гугл доке, а набирать табличку со скриншота как-то не с руки. Но логика очевидна. Если слева есть дата, то берем её, а иначе берем предыдущую в колоне C, и там по цепочке будет дата копироваться. Такая типа рекурсия.

Для начала нужно определиться с целью игры.

Зачем вы делаете игру?

Если для того, чтобы потренироваться или просто пощупать геймдев, то, возможно, цель УЖЕ достигнута. Если же для того, чтобы игра принесла денег, то с изложенным вами бекграундом вам до этой цели, как до луны. В приносящей деньги мобильной игре программирования дай бог 20%.

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

1. Сделать так, чтобы игра запускалась и работала в Unity.
   
2. Опубликовать готовую игру в сторе (Google Play пока для вас проще будет).
   

Из вопроса не ясно, на каком этапе у вас затык. Начните с первого этапа. Пустой экран должен у вас запускаться из коробки. То есть нужно просто запустить пустой проект. Дальше нужно разбираться с тем, как работает Unity - что может интерфейс, что предоставляет API и т.д. Тупо копировать чужой код не нужно. Копировать можно только с понимаем, что делает каждая строчка и каждый символ этого кода. То есть чужой код можно рассматривать, как пример. А дальше на его основе делать свой код. И даже если вы вставляете чужой код в свою игру без изменений, вы должны понимать, как он работает, чтобы он заработал именно у вас и не поломал игру, и сам не поломался при интеграции в игру.

А uBlock Origin уже не работает или вы не пробовали?

Вариант 1 (тупой)
Добавить задержку в 200 мс перед тем, как герой начнет двигаться от клавиш вправо-влево. Это делается просто. В момент нажатия запоминаем текущее время с точностью до миллисекунд.
А условие движения такое: клавиша вправо зажата И время зажатия больше 200 мс

Вариант 2 (легкий)
При нажатии клавиши вверх делать прыжок даже в движении. Собственно, это даже более правильно, чем его не делать. То есть если герой идет достаточно долго вправо (несколько секунд), а потом игрок вдруг нажимает вверх, то герой должен не игнорировать нажатие, а сделать прыжок вправо+вверх. Разве не логично? Тогда проблема решится сама собой.

Вариант 3 (сложный, для комбо)
Если у вас одновременное нажатие вправо+вверх - это какое-то особое комбо, то можно аналогично первому варианту отслеживать время нажатия вправо и в пределах этой задержки разрешать пользователю совершать данное комбо.
То есть при нажатии клавиши вправо нужно запомнить текущее время.
А при нажатии клавиши вверх проверяется условие.
Условие такое: клавиша вверх нажата И клавиша вправо была нажата менее 200 мс назад

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

Вариант 5 (правильный, комбо)
Чтобы не было резких откатов, нужно скорректировать не стартовую координату прыжка, а конечную точку прыжка. Скажем, герой прыгает по параболе. Просчитываем, куда он должен был попасть, если бы прыгал из той точки, где он нажал клавишу вправо. Затем пересчитываем, какая траектория должна быть, чтобы игрок с текущих координат попал бы в ту же точку. Точнее, считаем начальную скорость и направление, чтобы попасть в эту цель.

Вариант 6 (домашнее задание)
В случае, если герой в прыжке может менять направление ускорения стрелками, то нужно подойти к геймдизайнеру и спросить, как быть в этому случае. Ведь в конечном итоге всё зависит от его задумки, какие ощущения у игрока он хотел вызвать.

Веб-сайт в данном случае тоже сервер, и для понимания введем понятия:

• Игровой сервер (или просто сервер)
  
• Веб-сервер (бекенд)
  
• Браузер пользователя или клиент или фронтенд
  

Далее задачу можно разделить на два (три) этапа:

Этап первый

Вам нужно, чтобы ваш сервер отсылал на веб-сервер информацию о начале и конце. Это делается по протоколу HTTP или HTTPS, что-то типа java.net.HttpUrlConnection, но я точно не знаю, что вам лучше подойдет для этой цели.

Соответственно, на веб-сервере у вас должен быть свой скрипт на любом языке, обычно это PHP. Этот скрипт сохраняет информацию в базу (обычно MySQL).

Чтобы хранить таймер, который всё время меняется, нужно хранить неизменные его части. А именно - начало и конец, или начало и продолжительность, или просто время окончания (timestamp) с точностью до секунды.

Этап второй
Это общение веб-сервера и браузера (клиента). И тут есть свои тонкости.

Во-первых, сразу вилка на функционал - либо у вас таймер появляется по нажатию по F5 (обновить страницу). То есть вы обновляете страницу, браузер запрашивает новые данные с веб-сервера, и после этого показывает таймер. Либо у вас страница веб-сайта открыта, и там в реальном времени вдруг появляется таймер. Сам! Это можно сделать по-разному, но самый банальный способ - чтобы веб-страница (то есть браузер) делала запрос каждые 10 секунд в фоне (ajax), и если вдруг появляются новые данные, то страница преображается.

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

В остальном всё просто. Информация из базу тупо посылается на клиент, то есть время окончания, и дальше на клиенете скрипт работает локально. Он показывает отсчет времени до старта игры. Собственно, написание этого мини скрипта на JavaScript можно считать третьим этапом.

Немного странный запрос. Вы же делаете свою игру, а не модификацию к чужой игре. То есть у вас есть полный доступ к ее внутренностям. В таком случае, почему бы не генерировать событие в момент смены текстуры в том месте кода, где эта самая смена текстуры осуществляется?

По-хорошему нужно даже событие не смены текстуры, а более осмысленное в соответствии с логикой игры. Например, если у объекта есть несколько состояний, то хорошо бы иметь переменную (свойство) с этим состоянием и соответствующее событие на смену состояния. Текстуры тогда будут вообще ни при чем.

Так написано же, что все подробности ошибки сохранены здесь:
C:\Users\User\launcher\updates\HiTech\crash-reports\crash-2019-11-17_16.29.11-client.txt

Скорее всего, какой-то мод глючит. Пробуйте отключать моды по одному. Ну или не по одному, а по 5. Или сначала одну половину отключить, потом другую половину отключить, а первую включить. В общем, нужно искать виновника методом исключения.