mayton2019

Тут - сложно. Физика я имею в виду. Шаг от бега отличается тем что шагающий всегда касается земли.
А бегущий как-бы делает прыжки по воздуху.

Вообще не стоит задача менять разрешение текстур для 8К и выше моника. Обычно его вешают
подальше на стену из-за габаритов и сохранения угла поля зрения. И поэтому гнать
разрешение чтоб попадало точка-в-точку обычно не нужно. Все равно возможности
зрения ограничены. Разве что пользователь нажмет на паузу. И будет подходить
к экрану пока не уткнется носом чтобы что-то там разглядывать. Но это не игровой кейс.

Еще с 2000х разработчики знали хитрости. Bump-mapping, это когда на low-res текстуру
накладывся рельеф (повторяющиеся фактура дерева или камня) и это создавало иллюзию
высокого разрешения.

И процедуральные текстуры, которые можно рендерить для любого разрешения на заказ.
Они экономили память диска но не памяти текстур. Поэтому с ними есть нюансы.

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

Но для популярных игр эпохи 90х-2000х были готовые редакторы и просмотрщики
уровней и ресурсов (Doom, Quake, Warcraft). Можете там поискать.

Большинство игр 90-2000х использовали rendered графику в заставках. И графика эта могла делаться
на 3DStudio Max, Blender, Maya или на любом пакете который тогда существовал. Движок самой игры обычно
для какой-то детальной анимации не годился. Посмотрите на заставку к Quake3, StarCraft там от самой игры
даже моделей нет.

Физическая модель мира не должна зависеть от ФПС на экране. Если ты победишь эту проблему
то тогда никаких артифактов с отображением не будет. Для простоты ты можешь обновлять физику
хоть 10 разв в секунду хоть 120 раз это не важно. А визуальная часть игры будет делать интеполяцию.
Потому что засинхронизировать всех клиентов сетевой игры в принципе никогда невозможно.
У них и таймеры будут не синхронны и производительность разная.

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

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

В прошлом были истинно программистиские решения такие как Java Applets но они не взлетели как раз
именно по причине того что были ориентированы на программиста а не на дизайнера. Дизайнеру
и в страшном сне не присниться писать java-код.

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

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

Можно на сервер передавать твои клавиатурные нажатия. С высоким приоритетом. Сервер будет интерполировать
и создавать свою модель мира попутно проверяя тебя чтоб ты там не сильно телепортировался далеко.

И все игроки тоже должны получать координаты всех. Как-бы рассылкой.

Кстати подумай над UDP. Понятное дело что в рамках websocket у тебя диапазон возможностей будет
ограничен тем что дано. Но мне кажется что производительный игровой сервак должен делать TCP
как-бы обязательной частью протокола. И далее если клиент поддерживает (провайдер пускает)
то можно договориться (negotiation) на уровне софта о дополнительной рассылке по UDP каких
то не шибко важных событий игрового мира.

Я слегка читернул и спросил всезнающего искусственного всезнайку. Вот что он ответил кратко:

1. Open the 3DS File
2. Export as FBX or OBJ
3. Import into Blender

Как рассчитывать движение, работу двигателя и так далее?

Это - вопрос на мильон. Я думаю что если здесь собрать ракето-конструкторов - все они не сойдутся
на единой формуле расчета. Каждое конструкторское бюро конструирует их опираясь на свой
опыт. И мне кажется что там главной движущей силой расчета были ограничения чем формулы.
Например какое топливо? Как горит? Как долго горит? Насколько его хватит? Когда отделять
первую ступень? Да тут даже нет формулы. Бесконечно большое число испытаний. Наблюдения.
Привязка к ограничениям.

По игре-симулятору.

Чтоб полет был реалистичным - надо ХОТЯ-БЫ соблюсти все реальные физические свойства этого полета. Расстояния. Массы земли и луны. Скорость ракеты. Ускорение ракеты. Влияние атмосферы земли.

Это кажется пустяк но если ты хочешь делать симулятор то надо сделать его так чтоб полет хотя-бы не длился 30 секунд. Это уж будет слишком "не по лунному сценарию".

Как процедурно сгенерировать реалистичную поверхность Луны?

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

Чтоб подогнать файл под хеш надо сначала знать алгоритм хеширования.

А вообще - ты мелкий хулиган :) Найди себе нормальную работу лучше.

Нет необходимости отслеживать состояние сразу всех 2х миллионов. В старых 2д играх слешерах 90х например уровни тоже были очень богатые на количество enemies но их не нужно было обрабатывать и хранить всех сразу. По сути игрок видел view-port размером с экран и игровому движку нужно было активировать рождение объектов-персонажей почти у границы экрана. Когда персонаж покидал экран - его можно было либо удалить либо поставить на паузу. Этим пользовались почти все движки и экономили ресурсы.

Если речь идет допустим о клеточных автоматах - то там тоже есть свои оптимизации. Можно расчитывать эпохи параллельно используя опции параллелизма железа например. Или объединять близко стоящие кластеры клеток и обабатывать отдельно чтобы предотвратить расчет всего экрана. Тут нет предела совершенству. Можно брать такие индексы как Q-Tree/R-Tree для быстрого трекинга этих областей.

В некоторых играх типа Age Of Empires или Cossacks можно было рассматривать в качестве единицы расчета не каждого пехотинца или всадника а целые фаланги. Этим пользовались особенно когда боевые
единицы ходили в построении.

Вобщем игровые движки - это не симуляторы физики. Это - скорее очень хитрая иллюзия. И талант геймразработчика как раз и состоит в том чтобы игроку казалось что он видит миллион объектов а с точки
зрения игрового алгоритма - это будет просто один прямоугольник из целых чисел или каких-то других
объектов.

с каждым выбором номера идёт другой совсем ход событий то есть с каждым ответом меняется вопрос и тому подобное

Во времена DOS/RPG игрушек был создан такой себе DSL на котором можно было описывать диалоги
персонажей к квестах. Вот интересно было-бы поднять хотя-б название этого языка или имя его авторов. Информацию я эту слышал в каком-то youtube канале где такие двое болтунов любят болтать про старое легаси.

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

Здесь явно две задачи. Первое - это перевод mp3 в нотные блоки (кстати что это?).
И второе - это собственно интеграция этих блоков с приложением майнкрафт.

И лучше этот вопрос закрыть и поднять новые два в qna.

Если в игре есть 1000 взаимодействующих тел - то для их "сканирований" надо как минимум посчитать пол-миллиона взаимодействий. Каждое тело может видеть или не видеть каждое. По крайней мере прямая
реализация такого взаимодействия имеет квадратичную стоимость.

Мне вспоминается мультсериал Футурама. Там профессор построил космо-корабль. И когда его спросили как он работает - профессор ответил что не помнит. Но потом как-то вспомнил. Оказывается корабль вообще не летает. Он стоит на месте и двигает всю вселенную вокруг себя.

Пл поводу графики в играх. Я кажется знаю откуда ты эту фразу слышал. Это проеобразование world координат во view. Это идет от точки зрения алгебры матриц которые используются в 3Д графике. Чтоб показать на экране какую-то объект (куб, тор или пирамиду) надо все его координаты сначала умножить на матрицу его базовых преобразований (повроты сдвиги и масштаб) и потом еще это умножить на матрицу камеры. Здесь кстати на уровне камеры и делают всякие искажения перспективы и изометрию. И мы получаем фактические координаты экрана. Там еще идет хитрая оптимизация что две матрицы -константы и их можно взаимно перемножить и тд.

Это в теории. Как реализовано в OpenGL/Vulkano - я щас не знаю. Но думаю что основа - таже.

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

Doom - это была одна из первых игр где была реализована в полной мере техника BSP (Binary-Space-Partition). Это позволяло в реальном времени очень быстро сортировать и рендерить полигоны без привлечения Z-Buffer. (Рендеринг был чисто прогарммный. На то время еще не было ускорителей 3Д графики и видеокарточка умела только отображать память на экран. ) Игра не была по настоящему трехмерной. А только рализовывала 1 этаж. Рендерить надо было только пол и потолок. Для каждой точки где стоял персонаж. И наклонных горизонтальных поверхностей в ней не было как раз по этой причине. Ее называли 2.5-мерной игрой. Было также много идей оптимизации вычислений. Например вместо вещественных чисел - целые 32х битные с fixed point.

В скобках замечу что это был 1993 год и на дворе было царство Intel 286/386. Это были машины с тактовой частотой меньше ваших телефонов (Pentium только только релизнулся и еще ни у кого не был). И трехмерный Doom был прорывом. На моем тогда еще 386SX от подтормаживал но играть было можно. И со звуком для SoundBlaster. И конечно это было лучше чем Wolfenstein.

Аналогичное было реализовано в Duke Nukem 3d. Но Дюк был менее популярен ИМХО. Были и масса других 3д игр в жанке RPG но они были не такие динамичные. Походовые в основном.

Вобщем сегодня если вы гейм-дев то вам желательно хотя-бы ознакомиться с техниками оптимизации которые были в Doom. Можно почитать и про Quake но это просто развитие идеи BSP деревьев для полного 3D с 5 или 6 степенями свободы. Еще можно почитать про реализацию игры Esctatica. Там не на полигонах а на шариках или эллипсах реализована игровая графика. Тоже интересно.

UPD: Заменил MMORPG на RPG.

Проблема в реалтайме. Обычно когда речь идет об игре то на сцену выходит именно он.

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

Java не обеспечивает 60 fps просто в силу своей архитектуры памяти и GC. Это период цикла
в 16 милисекунд. Хотя современные GC типа G1 имеют управляемый таймаут stop-the-world,
тем не менее он не гарантируемый а скорее рекомендательный. Тоесть нельзя совсем
застраховаться от пропусков кадров и продергиваний. Можно скорее говорить о процентиле
чем о минимуме.

Java хорошо работает в обычных веб-приложениях и в back-end процессах потому-что одиночный таймаут
даже в 500 мс никто не заметит. В джобах и фоновых задачах - вообще плевать. Хоть несколько секунд.
Главное чтоб суммарная средняя скорость обработки бизнес-операций была на высоте. С этим вроде
все в порядке.

Вот. Поэтому реал-тайм игры лучше писать на С++/C/Rust. В них есть более-менее гарантируемое понятие отклика приложения. Ну а игру типа квеста или походовой стратегии на Java вполне себе можно написать.

Я не знаю как написан майнкрафт. Но я думаю что автор приложил огромное количество усилий
чтобы GC в его серверной и клиентской части почти ничем не был занят. И такой подход
годится для единичных игр но для майнстрима - скорее всего нет. Геймдев - это тоже бизнес
и он не любит рисков. Нужно так чтоб рилтайм == рилтайм.

Разработчик геймдева должен знать хорошо классическую механику. Я вот лет 15 назад пытался создать свою игру. Эдакий гибрид танчиков и майнкрафта но не вышло. У меня не хватало просто времени чтобы опробовать свои решения в части например взаимодействия твердых тел. Да и боюсь уже никогда не будет. Семья. Работа.

А в современных играх есть механикка жидкостей (флуидов) газов и таже тканей. Есть фреймворки наподобие PhyzX, Bullet но я-бы за них брался только после того как сам пойму как эта физика работает. Иначе вместо красивой игры можно сделать слайд-шоу и загрузить процессор расчетом молекул. А геймеру что надо? Ему вообще физика собсно не надо. Ему нужна эффектность. Тоесть там где не тянет CPU - надо просто добавить эффект ПОХОЖИЙ на физический.