Saboteur

Как в приложении реализована защита от абьюза?

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

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

Слишком общий вопрос, на который непонятно как отвечать.

Создание современной игры включает в себя множество аспектов, включая визуализацию и озвучивание на приемлимом уровне, который обычно не может обеспечить студент.
Реализовать минимальную логику можно да как угодно, RPG игра это просто игра, где у персонажа могут быть разные начальные характеристики и разные варианты развития. Но это все можно упростить до каких-нить воин-вор-маг, где базовые характеристики будут расти с разным коэффициентом и все. А можно усложнить до ветвлений, ограничений на ношение предметов, изучение навыков и так далее.
Ваш же вопрос вообще неясен.
Игра ничем не отличается от другой обычной программы. Характеристики персонажа, его инвентарь, и игровой мир также как и все остальное хранится в числовых или строковых переменных, а те могут храниться в файликах или базах данных.

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

Слишком общий вопрос.
В общем случае, raycast, raytracing и другое - это просто различные рализации алгоритм рендеринга для 3d сцен.
Есть готовые движки и библиотеки. Какие-то платные, какие-то бесплатные. Какие-то жрут больше ресурсов, но дают более качественную картинку (достаточную для создания CGI сцен для фильмов на большой экран), какие-то после шлифования напильником достаточны для игры в HD разрешении.

Та же идея рейкастинга может использоваться в несколько проходов, чтобы, например кинуть лучи с определенной частотой, построить упрощенный буфер видимой области. Потом выполнить второй проход более подробный, вычислить расстояние и масштаб для текстур. Потом выполнить еще один проход и сгладить края (одна из основных проблем, как сгладить края на hi res и при этом сэкономить ресурсы). И все эти штуки - отдельные алгоритмы рендеринга, которые использут принцип рейкастинга, и могут иметь внутренние названия в движке, а в другом движке те же самые алгоритмы могут называться чуть иначе, или схоже.

Рейкастинг и Рейтрейсинг считай две стороны одной медали, могут работать вместе, просто разные задачи. Например рейкастингом построил видимые объекты, сделал сцену, рейтрейсингом сгладил и добавил реалистичные затенения от разных источников освещения.

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

Таким образом оба термина не устарели и активно применяются, но это слишком общие слова, а не конкретная реализация. Под капотом там куча дополнительной терминологии.

А для современных игроделов есть просто несколько готовых фреймворков/движков - тот же юнити, XRay, Unreal, Godot, которые используют несколько алгоритмов рендеринга, разработчик может выбрать как пользоваться рендерингом, какие алгоритмы для какой сцены/действия использовать. Конечно желательно разбираться глубже, чтобы понимать как дизайнить игру, ибо алгоритм, который хорошо работает на открытых пространствах может хуже работать в тесном помещении, где требуется множество объектов с высокой детализацией. И наоборот.

То есть современные игроделы редко занимаются непосредственно ковыряниями с деталями реализации, скорее уже оптимизируют их микс для своего проекта

И возможно ли оттуда транслировать видеострим? смысл в том чтобы просчитать все на сервере и отдать клиенту видеострим.

Предлагаешь, чтобы на сервере стояла графическая карточка для каждого юзера?
Ну возьмем сервер,где играет 100-200 человек. Нужно 100-200 видеокарточек на сервере.
Хочешь 1000? 1000 карточек? Тут тупо на электричестве сервер разорится.

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

Главное чтобы интернет был норм

Давай посчитаем как отдавать видеострим.
Берем например ну хотя бы hd 1920x1080x4 (2 млн цветов). Получаем 8294400 байт один кадр ( 8 мегабайт). Ты же хочешь нормальный фпс, ну хотя бы 50 в секунду, 400 мегабайт в секунду. на одного юзера.

Хочешь поговорить о крутом сжатии? Так вот, оно не работает на кадрах. Оно работает на стримах, когда можно проанализировать некоторое количество кадров и уже работать от них. Тогда надо решить вопрос сколько кадров мы будем удерживать для анализа и сжатия, перед тем как куда-то передавать. Игры типа контерстрайка, где 5-10 мс имеют значение сразу улетают в трубу. Сжатие может быть разным, в зависимости от того как резко меняется картинка, а неравномерность лагов хуже чем постоянный лаг. То есть надо решить еще и этот вопрос

То есть сжимать стрим на уровне кадров, если мы не можем их полноценно анализировать.
Нормальные современные кодеки умеют и в А-фреймы и Б-фреймы, то есть жмут в обе стороны. Плюс не ограничены во времени. А у нас и время поджимает, и генерация ограничена количеством кадров которые мы можем вместе использовать. В итоге сжатие будет не 90% как в современных видеокодеках, а хорошо если сожмет треть, и качество будет теряться. И трафик уменьшитсья ну до 50-100 мб/сек.
Теперь подумаем что у клиента отличный инет. А у сервера будет 50-100 мб/сек на КАЖДОГО игрока? Это какой канал должен быть у сервера для поддержания 100-200 игроков? А 1000?

В итоге твоя идея технически совершенно не рабочая.

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

название сперва ввести а потом уже жать плюс?

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

Свой сервер для Lineage 2 писали несколько лет множество команд добровольцев. Он смог покрыть примерно 60-70% основного функционала. Потому что на сервере и 3д геодата мира, и АИ для монстров и обработка всех событий, заклинаний, навыков с их формулами, и квесты и так далее.
Свой сервер Battlenet для starcraft/diablo писали за месяц, потому что там в общем только авторизация и лобби для старта игры.

В зависимости от того, что делает сервер Мафии (не играл), может быть что угодно. Ну и реверсинг, если сейчас сервер уже нерабочий - КРАЙНЕ затруднен.

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

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

JS и кучи библиотек/фреймворков на JS/HTML5/CSS
там в принципе все что угодно можно написать.
А если взять еще и webassembly, То можно и посложнее.

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

В РПГ шлются действия типа "игрок кастанул заклинание", "игрок нажал бежать на X и Y", после чего сервер просчитывает что происходит и шлет назад уже координаты видимых объектов с их статусом.

Это становится понятно из управления - в условном контр-страйке для передвижения ты нажимаешь и отпускаешь стрелки. В условном MMORPG ты так не можешь, ты кликаешь мышкой в нужное место, и персонаж туда бежит по логике сервера (учитывая препятствия), но микроменеджментом ты не занимаешься.

https://github.com/sfkulyk/fdungeon

Заказываешь работу на фрилансе, потому что именно против таких пользователей как ты и был сделан античит механизм при помощи хеширования.

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

1 млн байт, это например всего лишь 1 мегабайт, что для современного компьютера немного.
Ты точно в КАЖДОЙ клетке хочешь разместить нечто активное?

public float maxVelocityChange = 10f;

У вас скорость меняется на это значение.
Просто придумайте алгоритм, чтобы менять значение переменной. Например если направление не изменилось, увеличиваете на 0.5, если изменилось, то сбрасываем на 10f.
Плюс может быть какой-то лимит добавить.

Странный вопрос.
А где сейчас хранишь информацию об одном боссе?
Там же храни и про нескольких.

восстанавливай без слипа.

А если хочешь больше конкретики в ответе, добавь конкретики в вопрос.

Советую почитать о том, что такое NKRO
Не факт что даже если будет верным код, найдешь клавиатуру где все будет работать

Тебе же прямо сказали. Нужно изучить язык программирования.
Не на уровне "почитал книжку". Не на уровне интерн/джуниор. А на уровне уверенного разработчика.

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

Поэтому правильный путь - это потратить МНОГО времени и МНОГО усилий.
Ты же сам сказал, что все что ты изучил - там давали базовое понимание что это такое.

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