Крайне доставляющий симулятор орка. Стоит копейки и обновы довольно регулярны.
10.02.2015, 14:54
разве?
Ах, если бы смешное.
В КСП скрафтил межпланетарный тягач с 90 отстреливаемыми наибольшими (белыми) баками, 24-ю атомными движками и 6-ю на 1500, направленными в обратную сторону(для резкого торможения при необходимости).
Для этого пришлось стыковать корабли на орбите Кербала 7 раз для переливки топлива (саму махину с пустыми баками вывел за один раз).
Однако, жуткие тормоза и глюки в физике ускорения (разваливается при форсе времени) поставили крест на попытках выгнать эту махину к Jool'у.
*хотел где-то выговорится по поводу этой печали.
В КСП скрафтил межпланетарный тягач с 90 отстреливаемыми наибольшими (белыми) баками, 24-ю атомными движками и 6-ю на 1500, направленными в обратную сторону(для резкого торможения при необходимости).
Для этого пришлось стыковать корабли на орбите Кербала 7 раз для переливки топлива (саму махину с пустыми баками вывел за один раз).
Однако, жуткие тормоза и глюки в физике ускорения (разваливается при форсе времени) поставили крест на попытках выгнать эту махину к Jool'у.
*хотел где-то выговорится по поводу этой печали.
КСП уже и так сильно упростили, хорошо что не на столько, чтобы ставить несколько тонн двигателей для торможения, когда можно просто развернуть сам корабль в антивектор. Проблемы с тормозами и вылетами поборол выставив настройки на среднее, убрав сглаживание и прочею ненужную (в данной игре) лабуду.
во первых оптимизацию патчами правили и правили, и со временем аппараты с кучей деталей перестали так сильно просаживать фпс. сейчас ну очень огромный аппарат нужно состряпать, чтобы лагало. правда у меня и комп выше среднего.
во вторых здесь проблема не в производительности, а в том что у тебя тягач был очень и очень нерационально собран. разве что ты планировал луну Кербала до Джула растолкать. XD в общем чисто конструкторская проблема. я на спутик Джула Лайет расталкивал колонизационный модуль, довольно большой: передвижной, с лабораторией, 5ю жилыми модулями и двумя электро-баггиками и для этого использовал всего два ракетоносителя. первый атмосферный, который колонизаторов отрывал от земли и выводил на орбиту и второй уже беспилотный, ваккумный, который стартовал следом, садился на орбиту модуля, стыковался и тащил дальше до самого джула. так вот, с таким принципом отправки межпланетных аппаратов было легко дотолкать (кстати даже не пользовался аэродинамическим торможением. вроде бы.) эту махину до Джула, маневрировать и прицельно ебнуться на островок который присмотрел (раза с третьего правда попал). так что главное тяговооруженность а не количество движков. :)
во вторых здесь проблема не в производительности, а в том что у тебя тягач был очень и очень нерационально собран. разве что ты планировал луну Кербала до Джула растолкать. XD в общем чисто конструкторская проблема. я на спутик Джула Лайет расталкивал колонизационный модуль, довольно большой: передвижной, с лабораторией, 5ю жилыми модулями и двумя электро-баггиками и для этого использовал всего два ракетоносителя. первый атмосферный, который колонизаторов отрывал от земли и выводил на орбиту и второй уже беспилотный, ваккумный, который стартовал следом, садился на орбиту модуля, стыковался и тащил дальше до самого джула. так вот, с таким принципом отправки межпланетных аппаратов было легко дотолкать (кстати даже не пользовался аэродинамическим торможением. вроде бы.) эту махину до Джула, маневрировать и прицельно ебнуться на островок который присмотрел (раза с третьего правда попал). так что главное тяговооруженность а не количество движков. :)
Мне хотелось создать модуль, чтобы можно было сесть на обе Луны Джула с гравитацией около 0,8 Земной (если не ошибаюсь). Проблема была с посадкой на ту, что без атмосферы - кучу топлива на торможения нужно сжечь, а потом еще и взлететь. Честно говоря, я этого так и не сделал.
Созданный для этого лендер был огромным, и даже 2-ступенчатым (так, что первая ступень давала торможение для посадки, а вторая - уже для взлета) Для посадки на другие луны первая ступень была уже лишней. Проверить его нигде не мог (не долетев до самого Джула), поэтому построил "с запасом".
90 баков и вправду не нужно было. Я успешно садился на атмосферную луну Джула и с гораздо меньшим кол-вом топлива, в том числе и на кораблях с оранжевыми баками, но I DID IT BECAUSE I COULD!
Мой тягач был создан идеально. Деталей был максимально возможный минимум - почти без укрепляющих труб, но с кучей декаплеров (по одному на бак) и топливных труб (чтобы как только один бак становился пустым - его можно было выбросить). При этом, чтобы баки опустошались последовательно, без ручного вмешательства с переливанием. Подобная конструкция, но раза в 3-4 меньше сработала на ура.
Вес одного лишь тягача был около 2,5 тыс тонн и имел около 600-800 деталей. С посадочным модулем эта сумма доросла чуть ли не до 3 тыс и 1100-1200 деталей.
Я писал только о вакуумном ракетоносителе, разумеется, он нигде садиться не должен был. К нему пристыковывался уже посадочный модуль. Разумеется, я понимаю, как что строить. Увы, не могу скинуть фото. Всё на другом компе.
Созданный для этого лендер был огромным, и даже 2-ступенчатым (так, что первая ступень давала торможение для посадки, а вторая - уже для взлета) Для посадки на другие луны первая ступень была уже лишней. Проверить его нигде не мог (не долетев до самого Джула), поэтому построил "с запасом".
90 баков и вправду не нужно было. Я успешно садился на атмосферную луну Джула и с гораздо меньшим кол-вом топлива, в том числе и на кораблях с оранжевыми баками, но I DID IT BECAUSE I COULD!
Мой тягач был создан идеально. Деталей был максимально возможный минимум - почти без укрепляющих труб, но с кучей декаплеров (по одному на бак) и топливных труб (чтобы как только один бак становился пустым - его можно было выбросить). При этом, чтобы баки опустошались последовательно, без ручного вмешательства с переливанием. Подобная конструкция, но раза в 3-4 меньше сработала на ура.
Вес одного лишь тягача был около 2,5 тыс тонн и имел около 600-800 деталей. С посадочным модулем эта сумма доросла чуть ли не до 3 тыс и 1100-1200 деталей.
Я писал только о вакуумном ракетоносителе, разумеется, он нигде садиться не должен был. К нему пристыковывался уже посадочный модуль. Разумеется, я понимаю, как что строить. Увы, не могу скинуть фото. Всё на другом компе.
ну сейчас еще супер-мега-движки и баки добавили и они тоже здорово сказались на количестве деталей. свой до Лайета я строил давно, когда еще оранжевые были предельным размером. а сейчас, с большим размером вообще легко стало не представляю себе удачный посадочный модуль, который требует такое количество тяги для транспортировки. :)
Я же и говорю, он был столь огромным для фана, а не с прикладного смысла.
Представь, если 24 атомных движка могли сжигать всё это топливо (если не ошибаюсь, от 7 до 13 часов) на полной тяге.
Этого бы хватило, чтобы долететь до джула и назад несколько раз.
Данная махина должна была стать кульминацией до тех пор, пока не будут введены другие звезды - тогда бы можно было использовать ее для полета к ним. Стыковочных портов на тягаче было 2, так что присоединить нужный модуль - пустяковое дело.
Она и сейчас летает по орбите, но едва ли будет использована.
Представь, если 24 атомных движка могли сжигать всё это топливо (если не ошибаюсь, от 7 до 13 часов) на полной тяге.
Этого бы хватило, чтобы долететь до джула и назад несколько раз.
Данная махина должна была стать кульминацией до тех пор, пока не будут введены другие звезды - тогда бы можно было использовать ее для полета к ним. Стыковочных портов на тягаче было 2, так что присоединить нужный модуль - пустяковое дело.
Она и сейчас летает по орбите, но едва ли будет использована.
Вот тут-то и возникает дилемма: разработчикам приходится выбирать между производительностью и простотой разработки. В юнити реализована компонентная система, где мы на основной объект просто вешаем компоненты, где при событии в каждый компонент рассылается сообщение о событии и т.д. Это очень удобно для разработчика и позволяет сделать код более детерминированным, но, как следствие, требует дополнительных 20-30% мощностей. Также это является плюсом для разнообразных мододелов, которые получают в свои руки известную платформу с известными возможностями.
Как контрпример можно рассмотреть такую игру как Factorio. Она исповедует диаметрально-противоположную идеологию, то есть упор на производительность. Им приходится самостоятельно разрабатывать как физику, которая наиболее эффективно будет работать в их сеттинге, так и API для мододелов, поддерживать к нему документацию, делать совершенно другую систему отрисовки и обновления. Как итог - хорошая производительность, но увеличенное время разработки и необходимость постоянной поддержки различных элементов игры.
Как контрпример можно рассмотреть такую игру как Factorio. Она исповедует диаметрально-противоположную идеологию, то есть упор на производительность. Им приходится самостоятельно разрабатывать как физику, которая наиболее эффективно будет работать в их сеттинге, так и API для мододелов, поддерживать к нему документацию, делать совершенно другую систему отрисовки и обновления. Как итог - хорошая производительность, но увеличенное время разработки и необходимость постоянной поддержки различных элементов игры.
по моему опыту программирования и геймдева: разработчики выбирают между "разбираться в этом движке и сделать всё в 2 раза быстрее" или "да они тупые! мы всё сделаем круче!". Есть такой синдром Not invented here. Многие начинающие (и не очень) им болеют.
В движке есть куча элементов, которые всё равно придётся делать. И в unity они уже есть. Factorio могли реализовать свою кастомную физику парой компонентов юнити. Но захотели вместо того, чтобы разобраться как это сделать, переписать остальные 95% кода unity по-своему.
Предубеждение "на юнити всё тормозно" происходит как раз потому, что даже очень глупый разработчик может сделать на нём игру. Но "защиты от дурака" в юнити нет. Если разработчик включит кучу эффектов без понимания, как их использовать и оптимизировать, то всё будет тормозить. На самописном движке, он бы просто не смог написать код для таких фичей =).
При этом конечный потребитель может даже не заметить что в этой игре "полностью динамическое освещение!111", ибо сейчас качество картинки процентов на 10 зависит от технологий, а на остальные 90 - от настроек, моделей и т.д. Если художник - говно, то технологии не спасут. Если художник - крут, то он на элементарных технологиях сможет сделать конфетку.
В движке есть куча элементов, которые всё равно придётся делать. И в unity они уже есть. Factorio могли реализовать свою кастомную физику парой компонентов юнити. Но захотели вместо того, чтобы разобраться как это сделать, переписать остальные 95% кода unity по-своему.
Предубеждение "на юнити всё тормозно" происходит как раз потому, что даже очень глупый разработчик может сделать на нём игру. Но "защиты от дурака" в юнити нет. Если разработчик включит кучу эффектов без понимания, как их использовать и оптимизировать, то всё будет тормозить. На самописном движке, он бы просто не смог написать код для таких фичей =).
При этом конечный потребитель может даже не заметить что в этой игре "полностью динамическое освещение!111", ибо сейчас качество картинки процентов на 10 зависит от технологий, а на остальные 90 - от настроек, моделей и т.д. Если художник - говно, то технологии не спасут. Если художник - крут, то он на элементарных технологиях сможет сделать конфетку.
Не спорю, на Юнити можно быстро сделать конфетку, а если умеешь делать, то с высокой производительностью. Я же говорил про конкретный шаблон программирования.
Факторио, как я считаю, слишком специфична для юнити, так как 2Д там ещё не слишком хорошо обкатан, все тени нарисованы вручную или как минимум сгенерированы до самого игрового цикла, а сама игра, с учётом её масштабности, чрезвычайно чувствительная к производительности. Если у тебя одних только инстансов конвееров да манипуляторов более пяти тысяч, которые должны обновляться каждый тик, а ещё множество прочих элементов, само собой если и не откажешься от компонентной системы, то как минимум начнёшь вносить в неё серьёзные изменения ради оптимизации, с Юнити же в плане изменения структуры взаимодействия объектов ака компонентной системы немного сложнее.
Честно говоря, не знаю насчёт использования ими стороннего API, но для действительно девиантных игр Юнити не очень подходит из-за своей заточенности под "среднюю" игру. Несомненно, сделать всё равно можно, но вложить в это сил придётся много больше. Как-то я потерял нить рассуждения и отошёл от темы.
Я пытался донести, что при должном планировании и знании особенностей своей системы(игры) выигрыш в производительности будет достаточно крупным. Главное ответить на вопрос: а нужен ли он тебе.
Факторио, как я считаю, слишком специфична для юнити, так как 2Д там ещё не слишком хорошо обкатан, все тени нарисованы вручную или как минимум сгенерированы до самого игрового цикла, а сама игра, с учётом её масштабности, чрезвычайно чувствительная к производительности. Если у тебя одних только инстансов конвееров да манипуляторов более пяти тысяч, которые должны обновляться каждый тик, а ещё множество прочих элементов, само собой если и не откажешься от компонентной системы, то как минимум начнёшь вносить в неё серьёзные изменения ради оптимизации, с Юнити же в плане изменения структуры взаимодействия объектов ака компонентной системы немного сложнее.
Честно говоря, не знаю насчёт использования ими стороннего API, но для действительно девиантных игр Юнити не очень подходит из-за своей заточенности под "среднюю" игру. Несомненно, сделать всё равно можно, но вложить в это сил придётся много больше. Как-то я потерял нить рассуждения и отошёл от темы.
Я пытался донести, что при должном планировании и знании особенностей своей системы(игры) выигрыш в производительности будет достаточно крупным. Главное ответить на вопрос: а нужен ли он тебе.
А за ссылку спасибо, теперь я знаю свой диагноз.
Именно. :3
Честно - случайно. Тыкнул в никуда и открыл.
попади в песочницу
А я уже сделал. И таки взорвалось.
Чтобы написать коммент, необходимо залогиниться
