dollar

Просто следишь, что такой-то процесс всё ещё запущен и находится в памяти.
В Стиме сделано так, что эта инфа периодически отсылается на сервер, и там уже происходит подсчет времени.

Если игры сами делать будете, то дальше учить геймдизайн. Можно по книгам, которые можно найти в гугле. А если гуглить не получается, то нужно учить, как гуглить и вообще работать с информацией.

Для "прикола" достаточно завершить explorer.exe. Это уберёт панель задач и рабочий стол.

Так сделайте отладку.
Вставьте в нужные места console.log() или хотя бы alert(), и смотрите, где какие промежуточные значения.

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

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

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

Хорошая мысль. А зачем менять спрайт? Так даже лучше, потому что вместо спрайта верёвки вам теперь нужен спрайт лишь одного звена, который можно просто размножить.

Если это не для вашего удобства, а для удобства пользователей, то лучше Lua, а именно MoonSharp. Язык простой, учится легко, и пользователю не нужно глубокого понимания C#.

private void Jump() {
        rigidbody.AddForce(transform.up * jumpForce, ForceMode2D.Impulse);
}

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

Сложность сортировки в общем случае будет O(N*log(N)).

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

Вот пример для вашего случая.

Привет, товарищ!
Хотел сказать, что мне ник твой не понравился. Стремный какой-то.
Всё остальное на высоте. Реально, классный вопрос задал.
Я подписался на тебя.

Код:

isGrounded = Physics2D.OverlapCircle(groundCheck.position, checkRadius, whatIsGround);

Не работает, потому что сразу же после этого вызывается функция CheckGround(), в которой переменная isGrounded снова перезаписывается:

Collider2D[] colliders = Physics2D.OverlapCircleAll(transform.position, 0.6F);
isGrounded = colliders.Length > 1;

Поэтому первую строчку вообще не будем рассматривать, эта пустышка, которая ничего не делает, только процессор нагружает лишний раз. Разберем, что же происходит в последних строках.
Вы считаете количество коллайдеров в круговой области. И если оно больше 1, то isGrounded будет true.
Видимо, около стены вы также считаете стену. Поэтому наличие стены делает isGrounded = true.
В чем здесь логика, вам виднее.
Исправляйте. :)

Поэкспериментируйте с функцией ScreenToWorldPoint().
Также есть ScreenPointToRay().
Далее, имея координату в 3D пространстве, можно уже легко считать поворот персонажа в сторону этой точки.

Учтите, что координаты - вещественные числа.

Возможно, у вас высота персонажа 0.00000000138456827364. То есть выше нуля. И если вы проверяете тупо сравнением (a > 0), то персонаж получается висит в воздухе. Нужно либо округлять, либо вносить поправку на погрешность, хотя бы до 4-5-го знака:
(a - 0.0001 > 0)

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

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

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

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

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

Если вопрос про то, как боты будут ходить в произвольном графе, то это всевозможные алгоритмы поиска пути, из которых наиболее классическим (и основой для других) является A* (Astar).

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

Засунуть его в другую ветку?
Общий Родитель -> в нём Бар и Перс.
Координаты меняем общего родителя.
Флипаем перса.
Как-то так.

А при чем здесь исходники боев? Вам нужно изучать геймдизайн и создание ИИ.