Мкропост зла. Как же меня заебали
Мкропост зла.
Как же меня заебали игроделы. Какие-то ебаные ушлёпки совсем не думая хуячат свои говноподелки. Обидно что с неплохими идеями игра отвратана технически. DmC, куча игр Nitrome, HoB...
Всё больше стал замечать в себе что когда игру играю долго из-за того что нравится и начинаю чуствовать механику на кончиках пальцев, проникнувшись состоянием флоу. Пошли уровни на челлендж, где нужен скил... И блядь начинается ебаная непредсказуемая хуета. Когда хотел сделать прыжок, но блядь кнопка не сработала хуйпойми почему. Или не зацепился за уступ хотя всегда зацеплялся. Из-за этого потом пишу гневные отзывы на игру которая на самом деле понравилась.
Огромное спасибо тем мудакам которые писали физику. И тем мудакам которые её используют. Это пиздец лагов. Это просто лагающее говно, которое ваще хуй знает как работает. То ты зацепился то нет. То тебя враг задел статическим полем пикселя, то половиной туловища через тебя прошёл и хоть бы хны. Ну или ваще пуля сквозь перса пролетела на лаге. Как такое можно играть и получать удовольствие.
Все кто использует юнити — пидоры. Те кто использует delta-time — тоже пидоры. Зачем вы это делаете? Вы что реально думаете что реалтайм с потерей десятка фреймов важнее нормального игрового опыта? Думаете что игрокам больше всего нравится сдыхать на шипах потому что момент прыжка был скипнут во фреймах, а не испытать всего лишь НЕБОЛЬШОЕ замедление игры?
В игре на челлендж ВАЖНА ПРЕДСКАЗУЕМОСТЬ. Ну потому что если я наточил свой топор и рубил им 200 лет то блядь ождаю что что он будет работать, а внезапно терять лезвие, ломать рукоять, плавиться и ещё хуйзнает что ещё. Современные физические движки этой предсказуемости не имеют.
Конечно я не призываю писать свои движки. У нас уже есть один любитель вафельных арканоидов в вакууме, игры которого пойдут разве что мэйнфрейме с 500 ядрами и миллионом ГБ оперативки.
Но головой блядь надо думать. Если движок не вывозит а мозг мелкий для придумывания оптимизаций — может быть отказаться от решения и переделать в пользу более простого?
Кучу хороших игр дропнул в последнее время из-за ебаных физических лагалищ.
- 03 июля 2018, 17:56
Напиши же, как правильно! И поподробнее!
Ок. Спасибо за напоминание.
Мат в посте намекает, что есть другие игры на винде, в которых это реализовано годно. Вопрос в том, что именно годно, как это померить и как исправить?
Прийти к Хейзеру, выгнать его из-за компа и посмотреть в профилировщике графики, чтобы понять, что он имеет в виду. Хорошо придумано.
Давай я сформулирую вопрос по-другому: как Хейзер определил (с чужой игрой), что его проблема в плавающих дельтах, а не (например) в сборке мусора? Просветите.
(И после этого как вставить фиксированные дельты в физику так, чтобы стало лучше, а не хуже)
Ну нет. Это не "обычный батхёрт", а вполне себе аргументированный батхёрт. Начаинаю сеять семя раздора, подрываю репутацию других движков. YoYo платят мне за пиар GMS.
Заебали платформеры на юнити. Когда авторов спрашиваешь "почему юнити" - начинается невнятная хуета.
Тех кто отвечал "бесплатный, большое комьюнити, хорошая документация, я знаю С#"
Охуеть критерии выбора инструмента. Это всё равно что когда ты за молотком пришёл в магаз и главными критерями для тебя чтобы он был "стильный, модный, молодёжный, с изящными формами и чтоб по нему группа была в ВК и канал в телеграмме, и фотки в инстаграмме где им салаты и супы мешают".
Мне тут кэп намекает, что критерии выбора инструмента зависят от цели которую ты с инструментом хочешь достичь.
потому что шикарный ассетстор, тонны уроков, здоровенный мануал, каждые полгода обновление восхитительное как цветок сакуры в мешке кодзимы с кучей плюшек и все халява, сотни крутейших выпущенных игор, 420 вакансий «Unity» на HH и проект уровня Kot211 даже в руках Саники не будет давать меньше 60 FPS
а почему GMS?
Зато будут решулярные провалы сквозь стены и куча эксплойтов лагов физики для спидранеров которые любят гулять за пределами карты.
Я делал как-то давно игру Megabot на юнити (когда она ещё делаилась на триал и фул). Казалось что всё круто. Но всё же проваливающиеся в пол айтемы меня доканали. И дело не в кривых руках. Я в 90% игры которые играл более 8 часов замечаю такую хуету.
Поэтому я все проверки столкновений пишу вручную. На GMS это просто делается, а вот в юнити мне кажется там Костыли будут.
Бесплатно - главная причина для меня, а так бы юзал и GMS
А чего скучать то? В GameMaker Studio даже за версией 2 такого говна как принудительный deltatime пока не завезли. Оно вроде как есть опционально, в т.ч. и для физики, но я этим не пользуюсь.
У меня есть некоторый FPS - 30 кадров в секунду. Есть чёткий pipeline отработки событий, который ГАРАНТИРУЕТ что каждому update будет соответствовать единственный refresh и наоборот. Поэтому игры которые не вывозят - немного тормозят, как было с моим Kot211. Я буду декомпозировать большой мир на небольшие локации, чтобы убрать эти тормоза. Всего-то делов.
Чет немного не понял. Ну если у тебя процессор не вывозит твои фиксированные 30 фпс, то тогда будут тормоза небольшие. А если ВДРУГ именно рендер не вывезет 30 фпс, то что тогда?
Поэтому у игрока с 25 фпс появляется преимущество над игроком с 30 фпс (для него всё медленнее, и ему проще реагировать, вот и сломали ваш "челлендж").
Поэтому многие и предпочитают аркады и простой геймплей.
По поводу лагов - Винда не однозадачная, тут еще во многом виновата операционная система, к-я не может распределить пульсирующую нагрузку между ядрами и раздать всем процессам время по необходимости.
И это-то в системе где все процессы по умолчанию с одинаковым приоритетом.
Так что сколько процессорного времени система дала процессу, столько и получилось. Ничего тут не поделаешь, можно посопротивляться, сглаживать, фильтровать, но если время между обновлениями внезапно скачет, то ни о какой стабильности обновления мира в игре (и уж тем более - физики) говорить не придется.
Можно поиграться с приоритетом процессов. Сам не пробовал. Только не ставь "реального времени", иначе вся система зависнет. В этом режиме ОС предполагает что процесс должен сам отдать ей ЦП когда захочет. Программы сейчас так уже не делают.
А если лагает сборщик мусора, а не винда? Как тебе такой вариант!
Я не совсем в курсе, но Юнити однопоточный? Тогда да, игра сама у себя отнимает время, к-е могло быть потрачено на Update.
Если не ошибаюсь, в каких-то последних версиях Юнити можно самому вызывать сборщик мусора или ограничить время работы сборщика после каждого вызова.
А вообще главное не создавать этот мусор и убирать его не придется. Тогда вызывать сборщик мусора лучше во время загрузки между уровнями.
Но подсчёт ссылок - это не сборщик мусора. При подсчёте ссылок память освобождается по достижению счётчиком нуля. При сборке мусора - когда-нибудь потом.
Нет. Одна из основных проблем сборки мусора - это его сборка в неудачный момент с полной остановкой программы (спокойно может на секунду подвиснуть). При подсчёте ссылок же память освобождается предсказуемо, в момент уменьшения счётчика до нуля.
Рефкаунтинг не сборщик мусора, потому что проблема сборки мусора - это его сборка в неудачный момент
-_- чего-то алхимия какая-то
Если ты погуглишь подсчёт ссылок, то поймёшь, там всё просто. Ясен фиг, что сборщик тоже считает ссылки, но это более сложный и непредсказуемый механизм.
там то всем понятно. Непонятно как ты обосновал что алгоритм GC "подсчет ссылок" не является GC, потому что "проблема сборки мусора в том,..."
Я не обосновывал алгоритм GC "подсчет ссылок". Я говорил про обычный подсчёт ссылок (который не отложенный).
Но ок, его, оказывается, тоже классифицируют как GC. Не знал. ;-)
Может быть медленнее, но из-за того, что момент освобождения памяти известен, это проще отлавливается у разработчика на компе.
Всё правильно, процессорный кэш и все дела, но полное отсутствие скриптинга плохо сочетается с геймдизайном, который про итерации и эксперименты.
Главное, чтобы быстро компилировалось. А проверка синтаксиса есть и в утиных языках (пример - GDScript в Godot). Наличие свойств и методов, конечно, не проверить до запуска, но это вопрос привычки.
Скриптовый язык мечты - инференция типов, JIT и отсутствие отложенной сборки мусора. :D
Винда гарантирует параллельность, но не гарантирует время исполнения. Хочешь реального времени, возьми QNX или ядро линукса пересобери с PREEMPT_RT.
Для Винды, кстати, надстройки тоже есть: codesys, twincat; но это уже не игрушки.
Сэр несет херню в массы. Не надо так. В интеграторах физики используют дельту времени.
и не пробуй - это не то, не трать время.
Имеется ввиду время между соседними обновления мира.
Причем тут интеграторы?
Сейчас как физику делают? Берут какой-нить двиг, а в нем Ньютон с упругими пружинами, а это интеграторы, которые накапливают силы-энергию. Из-за этого постоянные неоднозначности на границе объектов и пр. "проскальзывания" при взаимодействии физ. капсул/шаров/кубов. А если попиксельную физику включают, то там ваще хаос.
Для платформеров лучше подходят самописные, вручную по пиксельно выверенные физ. движки, где обязательно нужно синхронизировать покадрово картинку и ввод от пользователя. Лаги есть всегда, вопрос в том, как ты обрабатываешь эти ситуации.
Я вот в физические большие игры давно не играю, потому что знаю какой там пиздец с рассинхроном. Обидно, что в мелкие пиксельные игры, для которых написать свой двиг как два пальца обоссать - начинают приплетать юнити, или UT. НУХУЯ? Нахуя такое делать? Может быть вы ещё хлеб бензопилой режете или суп лопатой кушаете?
Ну не созданы Unity и UT для 2Д платформеров. Когда уже смиряться то все? То что разработчики костылей навтыкали- ещё не значит что оно реально пригодно для этого. На юнити отлично делать симуляторы ходьбы. Ваще заебись -там потеря десятка фреймов погоды не сделает.
На юнити отлично делать симуляторы ходьбы по старым поместьям со скримерами по КД. - FIXED
Слава Хэппи Вульфам!
Человек 2 года учился работать бензопилой. Ему придется резать хлеб бензопилой, ножом он не умеет. Или придется еще 1 год учиться работать ножом. Чтобы 2 раза в жизни порезать хлеб.
Статья понравилась, но местами тут предлогов или слов не хватает - видимо, писалось в спешке.
Это не статья, а долгосдерживаемый понос, который нужно было куда-то излить.
Мне лаги (но это сетевые, а не геймплейные) постоянно весь бокс портят. Самое плохое - когда во время лага прилетит удар, от которого ты не встанешь. Самое противное что ты его либо вообще не видел, либо увидел, но из-за лага боксер не успел среагировать на управление... вовремя.
Как перестать играть и начать делать игры:
1) Понять, наконец, зачем вселенная пытается до тебя достучаться...
2) Делать игры, сука!
Смешно, но ты меня не понял. Я про то, что судьба подталкивает хрензерга воплотить нелагающий геймплей самому.
Да уж, представляю в игре аптечки, уменьшающие здоровье. Специально чтобы повысить остроту ощущений от очередной смерти.
Надо бы игру с такой идеей сделать...
В принце персии были!
Каждый день узнаю что-то новое про Кодзиму.
Кодзима его виртуал? O_o
Это кот Лета. Кот Зима был зимой.
Пятиминутка ненависти.
Короче, все пидоры.
Держи мой меч, если ты конечно достаточно няшный.
Вот этому хотел уже плюсануть. Но строчкой позже хейз начал плевать в авторов своих движков.
Бай зе вей, скажите ему кто-нибудь: пускай поиграет в 3д от Майкла с геймдева. Дельта-тайм в физике есть, движок свой. Работает - идеально. Значит проблема НЕ в дельта-тайм и НЕ в самописнов двиге.
Типа того да. Нужна синхронность событий refresh и update. В юнити, UT и прочих движках - они асинхронны и выполняются как бог на душу положит. Помнится даже в доках юнити пишут что-то такое и что есть некий fixedUpdate с которым я особо разницу не почуствовал. А в GMS есть чёткий пайплайн обработки событий, который гарантирует что вот сейчас будет create, потом update, потом input, потом collisions, а затем draw, а потом ещё и postdraw. Поэтому я и пользуюсь GMS, как-то система более предсказуема, а значит - более управляема.
А deltatime как раз и вводится когда update не соответствует реальному fps, чтобы при "лаге" обсчёты продолжались. Но на самом деле там до смешного доходит. Например, частый приём - умножать на deltatime метрические единцы. А это значит что при должном лаге есть много рисков кривой обработки столкновений - часто касающиеся мелких объектов, которые "на лаге" на скорости пролетают сквозь стены. Все эти неточности физики часто эксплуатируются спидранерами для вылезания за пределы карты.