dollar

Вы считаете новые координаты от начальных, а нужно считать новые координаты от предыдущих.

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

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

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

Поиск пути и обход препятствий - алгоритм A* (AStar) и его модификации. При этом мир предполагается разбить на зоны.

Что касается карты, то однозначно ответить нельзя.

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

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

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

Такое лучше делать в самой игре.

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

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

На примере Террарии: сделали браузер модов внутри самой игры. Именно такое решение.

Ну а так разработчик может и без магазинов выложить своё детище на каком-нибудь itch.io например. Платно или бесплатно, по желанию. Там и обновлять может, и юзеры могут скачивать апдейты без доплаты и т.д.

Обычно делают "кучу склеенных в один файл кадров" на полотне 1024х1024 или 2048х2048.
Ещё больше размер - плохо.

Соответственно, в самом спрайтере лучше экпортировать в виде "кучи отдельных кадров". Но! При этом нужно сделать свою небольшую софтину, которая будет конвертировать удобочитаемый XML (или JSON) от спрайтера и отдельные изображения в свой собственный формат анимаций, удобный вам.

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

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

Основных направлений в геймдеве я бы выделил всего четыре:
1) Программирование
2) Дизайн
3) Менеджмент (сюда же включу маркетинг, и всяких КМ, биздевов, секретарш и пр.)
4) Геймдизайн

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

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

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

P.S. А ответ на предыдущий вопрос вас не устроил? Спрашиваю, потому что правильные ответы принято помечать решениями.

Верхний предел заработка не ограничен. Игра может принести даже миллионы (если не миллиард) долларов. Так что ответ - много.

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

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

В простой реализации всё просто. Сорри за тавтологию, но это реально так. Клиент посылает свою позицию серверу (абсолютные координаты) сразу послед изменения. Сервер посылает эти координаты остальным.

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

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

P.S. tcp не советую. Если данных мало (т.е. 4 игрока и 0 других объектов), то без разницы. Но на большом трафике даже 0.5% потерь пакетов приведет к лагам. Так что если планируете расти, лучше сразу выбрать udp (хотя вторым соединением по tcp можно административные задачи решать - поиск игроков, создание сессии и т.д.)

P.P.S. Здесь неплохо иллюстрируется проблема синхронизации.

готов потратить годы своей жизни

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

Сделать такую игру небольшой командой - сложно, заработать на ней ещё сложнее, а делать игру в одиночку - невозможно.

Я не программист, знаний ноль

на UE4

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

Чем мне вскрывать игровые ресурсы с расширением dat?

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

MrM4x1m1807, я лишь спросил про город в комментариях к самому вопросу) Это основное уточнение.

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

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

Я бы сделал так. Рандомизировал все характеристики для 100000 колобков, дальше запустил бы каждого в 100 случайных ситуаций с волками и лисами, и посмотрел бы, выживут они или нет. Потом оставил бы только тех, у кого 90% выживаемость. Характеры этих живчиков занёс бы в базу, и во время игры спавнил бы из базы случайного колобка.

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

В системном программировании больше упор на совместимость, баги не допустимы, особенно критические, потому что ставят под удар персональные данные, номера карт и т.д. В геймдеве же упор на скорость, если игра "крутая", как говорится, с переизбытком графики, отдельных объектов и мозгов у npc. Баги считаются нормой (к сожалению) и просто фиксятся по мере накопления жалоб, а порой на них даже забивают.

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

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

Насчёт Си в целом я бы усомнился на самом деле. В наши дни очевидны некоторые недостатки Си и С++. Эти языки будут ещё долго существовать, потому что за ними тянется большой багаж, и нужно много чего старого поддерживать. Главная фича С\С++ - это скорость работы готовой программы. Но нынче новые языки метят в лидеры по простоте, удобству, защищенности и скорости компиляции. И некоторым уже несколько лет. То ли еще будет. Думаю, однажды Си даже в НАСА отдаст пальму первенства другому языку.

Fiddler, например.

Wireshark вроде не позволяет менять трафик.

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