Вы несколько отошли от темы, но я попробую ответить.
WindowsPhone теперь основан на полном ядре Win10, и Microsoft разрабатывает и активно выпускает обновления для поддержки Continuum — подключение устройства в док и использование вместо основной платформы с монитором и перифирией, что для офиса и браузера более чем актуально.
Все ждут SurfacePhone и такого устройства действительно стоит ждать, но как мне кажется это будет намного больше чем просто телефон, опять же это все только мое представление будущего. Только после понимания компанией, что же за устройство они хотят выпустить, появятся и девайсы от сторонних компаний. Кто-то даже уже выдвигал название SurfaceBook или SurfaceNote, и все это достаточно логичное развитие платформы.
Насчет Skype вы правы, но как раз в тот переломный момент решалась судьба компании, которую выкупили Microsoft, которые приняли решение ее переделать. UWP это надолго, и выпуск Win10S, которая кроме UWP вообще ничего не поддерживает — для школ и базовой работы, также логичный шаг. Большинству родственников я бы поставил именно эту версию, без опаски, что все станет работать медленно через год работы.
ScreenClipping как я понимаю после CreatorsUpdate это встроенная функция системы, которую можно найти панели задач под WindowsInk. Там есть ScreenSketch которым я сам часто пользуюсь, после всех нужных пометок копирую и вставляю в OneNote.
Судя по прошлым конференциям — это именно 3D реализация с честной перспективой. Ранее уже были представлены инструменты для создания расслоения элементов в пространстве, однако для создания красивого эффекта требовалось огромное количество тщательно настроенной иерархии элементов, теперь же все объединено в один. Учитывая AR составляющую — возможно к полным 3D интерфейсам это также имеет отношение, однако они хотят сохранить совместимость и уложить все в какие-то разумные ограничения.
Понимать стоит буквально — не зря в ролике мы видим отсылки к реальному миру и множеству объектов в разных слоях. Цель глубины — разрушить привычный плоский интерфейс и собрать его заново множеством слоев, тем самым дать элементам больше пространства в тех же рамках дисплея.
Насчет шейдеров — не забывайте, что нам будут выдавать по одному встроенному «одобренному» шейдеру. Возможно, что в будущем появится возможность самим создавать их, но, как мне кажется, это разведет ненужный зоопарк на экране, и компания на это не пойдет. В остальном — верно освещение и эффекты будут «из коробки».
Свет, для пользователей тач устройств не будет работать в режиме подсветки курсора, однако это не отменяет добавление света во время интеракции — в зависимости от жестов и места нажатия мы получаем различное освещение и разливы света, что приводит к более динамичному и визуально глубокому взаимодействию, в отличие от существующих статичных «состояний» элементов.
Насчет взгляда на другие системы — верно, однако теперь это официальные решения, и не говорите, что конкуренты всегда были уникальны и неповторимы.
Последнее — многое из перечисленного можно реализовать уже сейчас, и я это упоминал в статье, однако теперь все будет работать «из коробки» с минимальной настройкой.
Не хотелось вдаваться в детали, учитывая, что данная картинка также является упрощением, также как и эта. Если интересны технические моменты, то да — документация начинает появляться, однако в самом начале каждой из статей огромное предупреждение:
This article describes functionality that hasn’t been released yet and may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
Попробовать это все можно на последних Insider сборках, хотя учитывая вышесказанное — больше пользы на данный момент дизайнеру (если кому интересно Adobe выпустили бету AdobeXD под Win10).
Пробежал по нескольким интересующим меня категориям (мышки, M2-SSD, объективы) и, к сожалению, так и не увидел простоты выбора. Берите «это» и «это» должно разделяться на цели которые хочет получить покупатель — конечно, бывают случаи, когда из пушки можно палить и заложиться на топовый вариант, но зачастую пользователю непонятно зачем и что он берет. Однако в статьях этого нет, местами все упирается в горы абсолютно неинтересной начинающему пользователю информации.
Больше конкретики — «Nikon: стартовый набор» — сейчас бывают такие «новички», которым/которые купили или им подарили сразу фуллфрейм, и тогда можно сразу смазывать все советы по DX объективам — да, они будут работать, но чтобы на фуллфрейме брать DX объектив, надо точно знать в чем его полный аналог хуже, и зачем обрезать свою полную матрицу. Только через несколько абзацев мы получаем в скобках " будь у вас полноразмерный сенсор, вы вряд ли бы читали этот текст" — вынесли бы это в самое начало. Местами пытаетесь «просто» рассказать что-то, но при этом используете неизвестные «новичку» термины, будто он уже все должен знать и до этого. Только в самом конце понимаем посыл статьи, что вы хотели дать старт с фиксов, а уже затем фотограф должен решить к чему он пойдет — стоило также с самого начала разъяснить, что же вы пытаетесь рассказать. Получилось по чуть-чуть всего и в итоге слишком размыто.
В статье по М2 — огромные, но уже несколько устаревшие таблицы на несколько экранов. При этом совет один — берите 850EVO и все. Нет намеков на то, что есть конкуренты и Pro серия, да и у самсунга уже были 950, а сейчас 960, и даже сравнивать 950 и 960 сложно, и часть уже исчезает с продажи. Учитывая, что в последнее время конкуренция в этой сфере все больше, и даже самые мелкие фирмы выкатывают свои M2 накопители — статья должна быть актуальней и обновляться чаще — согласен, что не во всех категориях это надо, но некоторые вещи развиваются очень стремительно, и то, что рекомендовалось пол-года/год назад уже утратило всю актуальность.
По мне, сайт с рекомендациями по железу должен быть мини гайдом который в различных устройствах говорит, что есть топ/миддл/лоу по производительности среди актуального поколения с примерным порядком цен. И на что в данной технике смотреть, если хочется потратить чуть больше. В камерах все по-другому, там устройства практически не устаревают, но с теми же объективами — стоило сказать, если вы хотите стоите на берегу и хотите сфотографировать чайку на камнях вдалеке, шмеля под ногами, портрет друзей, небольшую зарисовку пейзажа или охватить панораму, то в каждой из категорий вам понадобится конкретный объектив, часть из них можно совместить универсальными, к сожалению с потерей качества, но опять же в каждой из категорий есть разный уровень цен и надо понимать за что мы переплачиваем.
Я не критикую начинание, оно полезно и посыл ясен, но хотелось бы, чтобы новичок зашел и действительно смог выбрать себе то, что он хочет и понимал за что он платит. Тогда я смог бы кинуть ваш сайт родителям и они больше ко мне не обращались каждый раз при апгрейде или необходимой покупке. Пока я так сделать, увы, не могу.
Корпус неплох только внешне. По внутреннему расположению первый же вопрос — изоляция материнки от GPU где сейчас зияет дыра, там будет очень неприятная температура, особенно если еще и M2 накопитель сзади на материнку добавить — страшновато за него. Хотелось бы более значительную изоляцию секций.
Посмотрите на внутреннее расположение в корпусах NCASE M1, Ghost S1, и рекордсмен по объему в виде DAN A4. Недостаток такого расположения — значительные ограничения на высоту CPU кулера. С другой же стороны буквально недавно смотрел насчет более традиционных вариантов, без райзера для GPU, и, похоже, что не составит большого труда сделать 7-литровый корпус рассчитаный на 100-110мм CPU кулер и ITX GPU — полноценная видеокарта в таком виде увеличит объем примерно до 8.5 литров. На подобии Silverstone SG13, но и из него еще есть где выжать лишний объем.
Если кто хочет посмотрите на текущий рынок
Сам давно присматриваюсь к Node202, но хотелось бы все же до 7-8 литров объем на начинку с SFX БП. Есть конечно Sentry — но там тоже резкое ограничение на высоту CPU охлаждения.
Качественный пиксель-арт требует очень больших временных затрат, редко он выдерживается на высоком уровне. Хорошему художнику зачастую проще нарисовать нормальную арт-иллюстрацию, чем возиться и выверять каждый пиксель. Однако и в таком виде, одной из главных причин пиксель-арта в современном инди банальная популярность. Мода на него не пройдет никогда, людей которые его не любят, также меньше не станет. Опять же если человек не умеет рисовать и не может нанять художника, то пиксель-арт, пусть и крупный и кривоватый это его выход из положения, к сожалению, на таких плохих примерах мы и начинаем ругать очередную пиксельную игру, даже не взглянув на механику.
одноклеточные игры
Они далеко не всегда примитивны, и объективно хуже прошлых частей после очередной штамповки. Новички, которые только знакомятся с серией, с удовольствием засядут за новую часть, даже не посмотрев на все предыдущие, и не поймут откуда все эти разговоры о конвейерах. Проблема лишь в том, что как раз у крупных платформ новых пользователей не так много как бы им хотелось, и большинство из купивших очередную часть уже знакомы с серией. Спрос же падает слабо, потому как любой, кому понравилась хотя бы одна игра в серии, даст ей еще один шанс.
Статья показывает взгляд на рынок с точки зрения ремесленника — для него игры это не искусство. Инди сцена, как раз и положила начало большим экспериментам в механиках и дизайне. Гиганты игростроя просто не готовы взять на себя такие риски и все реже выпускают совершенно новые продукты, уповая на конвейер. Они этим также себя загоняют в тупик. Обрекая все такие серии на перезапуски, ведь без притока новых идей, игроки зачастую разочарованы «бездушными» новыми частами.
Открывая технологии для более широкой аудитории, рынок позволит еще больше увеличить вариативность экспериментов. Конечно, это также влечет за собой то, что каждая сколь-либо популяризованная идея растекается множеством клонов, но большинство из них как раз и являются попыткой нажиться на взлетевшей идее.
Автор печалится, что рынки насыщены множеством игр, среди которых новичок уже не может конкурировать. Если же это ему удастся, то он все равно потеряет свою идентичность, разорится, или будет поглощен. Я же считаю, что каждый такой инди разработчик представляет только себя как профессиональную единицу. И его личный путь дальнейшего развития не так уж и важен, если в нем есть задатки реального творчества, то они не будут забыты и проявят себя вновь. Если вы пришли в эту сферу «срубить» денег в первую очередь, то у меня для вас плохие новости — бросайте сейчас же! Без вас и рынку и потребителям будет легче. И уж если речь зашла о другом творчестве — в любом из них целью должно быть желание привнести что-то новое. Не побоюсь вставить любимые строки одного талантливого музыканта: If you must work, work to leave some part of you on this earth.
Ансель, Дэвид Кейдж, Дженова Чен, Ивински и Кичински — этот список можно пополнять дальше многими именами — все они начинали с малого, и если бы у них были сегодняшние инструменты, им бы было просто легче, однако никто из них не создал сразу идеальный AAA блокбастер. Это сейчас после многих лет мы смотрим на них как на богов индустрии, но мало кто посмотрит на путь этих людей с самого начала.
Если у вас есть интересные идеи, и вы готовы поделиться ими с миром — никогда не поздно начать! Не смотрите на тех людей, которые к вам относятся слишком скептично — не отчаивайтесь, у настоящего инди все только впереди!
Решение здравое, но оно не во всех случаях применимо. Для FPS — согласен, а вот таймер времени, который имеет точность в тысячные секунды, как в TrackMania, только запутает игрока, если цифры там не будут верно обновляться в реальном времени, и никакая дополнительная логика оптимизации не поможет именно этой точности.
Обидно на самом деле видеть столько негатива (и не только от вас, но и других пользователей), и попытке всех научить всему и вся. Я не сомневаюсь, что за вашими словами есть выводы, которые пришли из практического опыта. Если вы сможете помочь вывести истину, добавить полезных советов тем, кто зайдет впервые со своими проблемами — я буду только благодарен. Если ваших мыслей наберется на статью — я ее обязательно прочту!
Мои слова отражают непосредственно мой опыт, и если внимательно читать статью, то я пишу о том, что все оптимизации необходимо применять только в проблемных местах. Думаете, что я на 100% последовал своим советам во всем проекте по доведению до производительного кода? Отнюдь — только там, где указал профайлер. И об этом также указано в статье. Если вы видите совет в книге — начинаете применять его везде? Сомневаюсь. Относитесь критически, у вас своя голова на плечах, и вы можете обработать поступившую информацию, попробовать что-то на практике, и для себя понять — стоит оно того или нет.
Это в принципе мой первый проект под Unity, и я рассказал о том, через какие основные этапы пришлось проводить оптимизацию. И ведь мне тоже нужна помощь, и я озвучил в статье очень неприятное поведение плеера при запуске. Однако я не пошел во все статьи по Unity писать недовольные комментарии о том, что вы бы лучше про это написали, а не расписывали очевидные вещи, которые даже не всегда применимы, а в моей команде мы на такое не пойдем никогда — вы все делаете не так.
Я рад, если у вас в копилке столько опыта. Делитесь и дополняйте, помогайте другим — критика тоже полезна, но аргументируйте верно, подкрепляйте своими результатами, но не пытайтесь задавить тем, что вы с таким не сталкивались, и принятые меры слишком чрезмерны. Иногда нужно знать к чему мы стремимся. В моем случае, я запустил на мобильном устройстве и получил абсолютно неприемлемый результат. Возможно, у меня все неправильно, но я попытался это исправить. К сожалению, я сейчас не вижу каких-то «золотых» решений в коде применительно к моему проекту, которые бы обеспечили запуск на мобильных платформах.
1. Не поленился и создал тестовую сцену в которую добавил 50 тысяч объектов, каждый из которых в своем Update вызывает get и set на всех возможных вариантах: свойство с явно указанным полем, автосвойство, отдельно методы, и только поле.
Результат профайлера (мс):
AutoProperty 19.2
BackProperty 18.03
Methods 17.98
Field 2.86
До этого проводил похожее исследование циклом на 10 миллионов запросов к get и set, что привело к средним значениям в тиках:
AutoProperty ~2605162
BackProperty ~2535456
Methods ~2525719
Field ~777295
Из которых около 500000 это чистое время цикла, что в целом соответствует распределению значений выше.
Согласен — напрямую реализованные Свойства с явными геттерами и сеттерами практически равны по производительности явным Методам, и паритет тут в пределах погрешности. Однако всегда автосвойство проигрывает достаточно ощутимо, а поле по скорости вырывается с огромным преимуществом.
Я в своем проекте использовал почти везде автосвойства именно для инкапсуляции, однако увидев такую существенную разницу с полями — пришлось переходить на них.
2. GetComponent — да, быстрее будет складывать объекты напрямую, но в некоторых случаях, когда пишешь более общую логику, которую будешь развешивать на множество существующих объектов, есть большой соблазн забрать компонент именно через эту функцию. Однако речь в этом пункте шла не только об этой функции, но и стандартных компонентах вроде transform и rigidbody.
4. Опасно, но многие скрипты работы с математикой это здорово ускоряет. Если хочется в каждом из классов хранить по объекту одинакового вектора, то пожалуйста, но как-то привык чтобы кода было как можно меньше.
5. StringBuilder — это стандартное решение, и в данном случае оно все равно не спасает. В итоге необходимо все равно обращаться к ToString, что и вызовет дополнительную аллокацию. Есть грязные хаки для переиспользования памяти внутри StringBuilder, но меня даже это не спасло. Если интересно — советую поискать garbage-free-string, но для себя я не нашел среди этой информации приемлемого решения или даже намека на него.
Насчет читабельности — несколько утрированно, однако доля правды в этом есть, потому как я много посвящаю времени для вычистки грязного кода, и практически любая оптимизация, которая вроде бы и не требуется вне Unity, заставляет меня каждый раз вспоминать, что это только ради производительности, иначе я бы такого кода просто не написал.
Насчет комментариев у меня также свое мнение — удаляйте их отовсюду! Средства языка программирования достаточно выразительны, чтобы обойтись без них. Код не должен содержать магии ни под каким предлогом, кроме случая, когда это единственно возможное решение, и этот кусок каждый раз правит какой-то «добросовестный» коллега. Только для такого случая можно навесить комментарий с призывом не трогать, но если он протухнет, лично вы виноваты, в оставленном среди важных строк кода неверном мусорном комментарии.
У меня есть один ответ — Mono. Свойства, внезапно, используются не очень оптимально, и нет инлайна простых свойств при использовании JIT, что в итоге значительно просаживает производительность. Без Mono, большая часть из того, что я написал, никого не интересует и не является проблемой.
Я сам всегда поражался на всех туториалах от Unity, всегда используют поля вместо свойств, и я был против этого, т. к. чистый код на C# подразумевает эти самые свойства! Лишь перенеся часть свойств в поля и увидев значительный прирост производительности, я категорично указал, что в Unity не место свойствам — хотя они у меня остались в конфиге и сохранениях, где к ним идет очень редкое обращение.
Также работа со строками — в моем случае я лишь избавился от постоянной аллокации текста, снизив нагрузку на GC(опять же кастомный под Unity), сгенерировав все строки изначально — да я держу их в памяти, но не аллоцирую каждый кадр. Забыл, кстати, среди CPU оптимизаций упомянуть лямбда выражения, каждый вызов которых также выливается в дополнительные аллокации в памяти. Меня спасло использование прямых делегатов.
Unity постоянно стремится к все новым оптимизациям, но пока — все что было описано, критично било по производительности — именно это моя основная причина. Ни один из описанных пунктов бы не появился здесь, если бы я лично не увидел положительного эффекта от каждого из них.
Я думал про это, но, к сожалению, не с чего снять скриншот. Исходники уже не вернуть, да и что это покажет — просто как доказательство того, что время в профайлере уменьшилось? В вашем конкретном случае все может быть иначе в профайлере — я иногда наблюдаю, что у разработчиков бывает и CPU время доходит до тысячи FPS, хотя я только недавно добрался до стабильных 30-60 с проявляющимися иногда 120 на графике. Мне все-таки кажется, что абстрактные и применимые к конкретному проекту графики из профайлера слабо кого-либо воодушевят.
Конечно — гринд ачивок это совсем другое, обычно за стандартное прохождение открывается около 50-60% всех ачивок.
Однако всех играх есть конкретная ачивка за завершение сюжетной линии с определенной концовкой. Давайте возьмем к примеру недавние DarkSouls3 — игра конечно сложная, но целевая аудитория знает за что берет, и я очень удивлюсь, если новичок начнет именно с этой части знакомство с серией. Смотрим официальные данные: первую коновку получили 27.5%, вторую 19.7% и третью 15.8%, однако эти проценты нельзя суммировать, я очень удивлюсь, что кто-то на первом прохождении пошел сразу не за первой концовкой, потому как их достаточно нетривиально открывать. И это успешная игра с отличными оценками критиков. Не дотягивает до 30% прохождения.
DeusEx:Human Revolution: тоже есть ачивка за прохождение, и таких игроков 37%
Portal — 46%
Skyrim — 28%
GTA V — 22.5%
This War of Mine — 19%
Inside — 15.7%
Эти данные легко доступны, и они четко отражают завершил ли человек сюжетную часть, или нет.
Насчет затянутых книг и фильмов — это только ваше мнение, однако найдутся люди, которым и эта затянутость нравится — тогда для них будет мукой появление конца. Мне, например, очень нравится фильм «Пленницы» Вильнева, однако все мои знакомые сказали, что все слишком затянуто, хотя мне было даже этого мало, и размеренность повествования в данном случае атмосфере фильма только на руку.
Насчет игр со множеством концовок, я не вижу противоречий, чтобы каждая из концовок, как и промежуточные события могли эмоционально вовлекать игрока.
Однако я ни в коей мере не затрагивал несюжетные игры, в шахматах, например, если подумать, то принцип эмоционального вовлечения в процесс применим и к ним. Я легко могу представить вариант в котором мы анимируем реальных персонажей, которые сидят за столом, и в зависимости от ваших действий они с разным эмоциональным тоном — в проигрыше более раздражительно, или как боги, твердо передвигать фигуры. Каждый ход будет важен, а какие-то переломные моменты вроде очевидных ошибок, или перевеса игры в одну сторону, показывать заранее под такой момент подготовленные кат-сцены. К сожалению, как мне видится — это сгодится только на несколько раз, и дальше будет только раздражать, т. к. длина игровой сессии слишком мала, и концентрация таких моментов будет просто зашкаливать. Хотя кто-то возьмется и за это и будет безумно доволен. И я скорее черпал вдохновение из фильмов, где сценаристы обычно вписывают дополнительный не очень связанный с игрой сюжет, но при этом очень серьезно стараются развлекать и вовлекать зрителя в процесс самой игры. Поэтому вовлечь можно во все. Даже в набор очков ради очков!
Оно не полностью противоположно мнению Ванденберга, т. к. изначально и у меня все нутро как раз было против его слов. Однако, оформив мысли на бумаге, стало ясно, что это взгляд несколько под другим углом.
Слова Кодзимы тоже можно интерпретировать по-разному. Но в моей интерпретации здесь — действительно противоположно. С другой стороны, если подумать, что его слова имели эффект скорее сбавить пыл и не вкладываться только в концовку — тут я только за, главное чтобы все было на высоком уровне, и дальше по статье. Хотя, опять же, я не могу припомнить, чтобы культовые японские игры не вовлекали в процессе прохождения. Концовка просто всегда была квинтэссенцией произведения, при этом оставляя множество отличных моментов и по мере прогресса. Так что, может, это я надумываю, а Кодзима действительно неправ.
Спасибо.
Насчет UI, практически все указывают, что с ним что-то не то, но никто не может сказать — что же именно. У меня осталась основная идея, как его можно полностью переделать, но это будет позже.
Запекание как раз дает большой эффект, иначе разрешение теней просто стремится к нулю.
К концу разработки и я намного быстрее лепил модели, и даже переделывал их с нуля (учитывая, что основных моделей около 50, не считая кучи вспомогательных, то получаемое количество часов — это тоже немало, хотя я, конечно, тратил больше), но взять готовые как-то рука не поднялась. Буду совершенствоваться.
WindowsPhone теперь основан на полном ядре Win10, и Microsoft разрабатывает и активно выпускает обновления для поддержки Continuum — подключение устройства в док и использование вместо основной платформы с монитором и перифирией, что для офиса и браузера более чем актуально.
Все ждут SurfacePhone и такого устройства действительно стоит ждать, но как мне кажется это будет намного больше чем просто телефон, опять же это все только мое представление будущего. Только после понимания компанией, что же за устройство они хотят выпустить, появятся и девайсы от сторонних компаний. Кто-то даже уже выдвигал название SurfaceBook или SurfaceNote, и все это достаточно логичное развитие платформы.
Насчет Skype вы правы, но как раз в тот переломный момент решалась судьба компании, которую выкупили Microsoft, которые приняли решение ее переделать. UWP это надолго, и выпуск Win10S, которая кроме UWP вообще ничего не поддерживает — для школ и базовой работы, также логичный шаг. Большинству родственников я бы поставил именно эту версию, без опаски, что все станет работать медленно через год работы.
ScreenClipping как я понимаю после CreatorsUpdate это встроенная функция системы, которую можно найти панели задач под WindowsInk. Там есть ScreenSketch которым я сам часто пользуюсь, после всех нужных пометок копирую и вставляю в OneNote.
Понимать стоит буквально — не зря в ролике мы видим отсылки к реальному миру и множеству объектов в разных слоях. Цель глубины — разрушить привычный плоский интерфейс и собрать его заново множеством слоев, тем самым дать элементам больше пространства в тех же рамках дисплея.
Насчет взгляда на другие системы — верно, однако теперь это официальные решения, и не говорите, что конкуренты всегда были уникальны и неповторимы.
Последнее — многое из перечисленного можно реализовать уже сейчас, и я это упоминал в статье, однако теперь все будет работать «из коробки» с минимальной настройкой.
Попробовать это все можно на последних Insider сборках, хотя учитывая вышесказанное — больше пользы на данный момент дизайнеру (если кому интересно Adobe выпустили бету AdobeXD под Win10).
Больше конкретики — «Nikon: стартовый набор» — сейчас бывают такие «новички», которым/которые купили или им подарили сразу фуллфрейм, и тогда можно сразу смазывать все советы по DX объективам — да, они будут работать, но чтобы на фуллфрейме брать DX объектив, надо точно знать в чем его полный аналог хуже, и зачем обрезать свою полную матрицу. Только через несколько абзацев мы получаем в скобках " будь у вас полноразмерный сенсор, вы вряд ли бы читали этот текст" — вынесли бы это в самое начало. Местами пытаетесь «просто» рассказать что-то, но при этом используете неизвестные «новичку» термины, будто он уже все должен знать и до этого. Только в самом конце понимаем посыл статьи, что вы хотели дать старт с фиксов, а уже затем фотограф должен решить к чему он пойдет — стоило также с самого начала разъяснить, что же вы пытаетесь рассказать. Получилось по чуть-чуть всего и в итоге слишком размыто.
В статье по М2 — огромные, но уже несколько устаревшие таблицы на несколько экранов. При этом совет один — берите 850EVO и все. Нет намеков на то, что есть конкуренты и Pro серия, да и у самсунга уже были 950, а сейчас 960, и даже сравнивать 950 и 960 сложно, и часть уже исчезает с продажи. Учитывая, что в последнее время конкуренция в этой сфере все больше, и даже самые мелкие фирмы выкатывают свои M2 накопители — статья должна быть актуальней и обновляться чаще — согласен, что не во всех категориях это надо, но некоторые вещи развиваются очень стремительно, и то, что рекомендовалось пол-года/год назад уже утратило всю актуальность.
По мне, сайт с рекомендациями по железу должен быть мини гайдом который в различных устройствах говорит, что есть топ/миддл/лоу по производительности среди актуального поколения с примерным порядком цен. И на что в данной технике смотреть, если хочется потратить чуть больше. В камерах все по-другому, там устройства практически не устаревают, но с теми же объективами — стоило сказать, если вы хотите стоите на берегу и хотите сфотографировать чайку на камнях вдалеке, шмеля под ногами, портрет друзей, небольшую зарисовку пейзажа или охватить панораму, то в каждой из категорий вам понадобится конкретный объектив, часть из них можно совместить универсальными, к сожалению с потерей качества, но опять же в каждой из категорий есть разный уровень цен и надо понимать за что мы переплачиваем.
Я не критикую начинание, оно полезно и посыл ясен, но хотелось бы, чтобы новичок зашел и действительно смог выбрать себе то, что он хочет и понимал за что он платит. Тогда я смог бы кинуть ваш сайт родителям и они больше ко мне не обращались каждый раз при апгрейде или необходимой покупке. Пока я так сделать, увы, не могу.
Посмотрите на внутреннее расположение в корпусах NCASE M1, Ghost S1, и рекордсмен по объему в виде DAN A4. Недостаток такого расположения — значительные ограничения на высоту CPU кулера. С другой же стороны буквально недавно смотрел насчет более традиционных вариантов, без райзера для GPU, и, похоже, что не составит большого труда сделать 7-литровый корпус рассчитаный на 100-110мм CPU кулер и ITX GPU — полноценная видеокарта в таком виде увеличит объем примерно до 8.5 литров. На подобии Silverstone SG13, но и из него еще есть где выжать лишний объем.
Если кто хочет посмотрите на текущий рынок
Сам давно присматриваюсь к Node202, но хотелось бы все же до 7-8 литров объем на начинку с SFX БП. Есть конечно Sentry — но там тоже резкое ограничение на высоту CPU охлаждения.
Они далеко не всегда примитивны, и объективно хуже прошлых частей после очередной штамповки. Новички, которые только знакомятся с серией, с удовольствием засядут за новую часть, даже не посмотрев на все предыдущие, и не поймут откуда все эти разговоры о конвейерах. Проблема лишь в том, что как раз у крупных платформ новых пользователей не так много как бы им хотелось, и большинство из купивших очередную часть уже знакомы с серией. Спрос же падает слабо, потому как любой, кому понравилась хотя бы одна игра в серии, даст ей еще один шанс.
Открывая технологии для более широкой аудитории, рынок позволит еще больше увеличить вариативность экспериментов. Конечно, это также влечет за собой то, что каждая сколь-либо популяризованная идея растекается множеством клонов, но большинство из них как раз и являются попыткой нажиться на взлетевшей идее.
Автор печалится, что рынки насыщены множеством игр, среди которых новичок уже не может конкурировать. Если же это ему удастся, то он все равно потеряет свою идентичность, разорится, или будет поглощен. Я же считаю, что каждый такой инди разработчик представляет только себя как профессиональную единицу. И его личный путь дальнейшего развития не так уж и важен, если в нем есть задатки реального творчества, то они не будут забыты и проявят себя вновь. Если вы пришли в эту сферу «срубить» денег в первую очередь, то у меня для вас плохие новости — бросайте сейчас же! Без вас и рынку и потребителям будет легче. И уж если речь зашла о другом творчестве — в любом из них целью должно быть желание привнести что-то новое. Не побоюсь вставить любимые строки одного талантливого музыканта: If you must work, work to leave some part of you on this earth.
Ансель, Дэвид Кейдж, Дженова Чен, Ивински и Кичински — этот список можно пополнять дальше многими именами — все они начинали с малого, и если бы у них были сегодняшние инструменты, им бы было просто легче, однако никто из них не создал сразу идеальный AAA блокбастер. Это сейчас после многих лет мы смотрим на них как на богов индустрии, но мало кто посмотрит на путь этих людей с самого начала.
Если у вас есть интересные идеи, и вы готовы поделиться ими с миром — никогда не поздно начать! Не смотрите на тех людей, которые к вам относятся слишком скептично — не отчаивайтесь, у настоящего инди все только впереди!
Мои слова отражают непосредственно мой опыт, и если внимательно читать статью, то я пишу о том, что все оптимизации необходимо применять только в проблемных местах. Думаете, что я на 100% последовал своим советам во всем проекте по доведению до производительного кода? Отнюдь — только там, где указал профайлер. И об этом также указано в статье. Если вы видите совет в книге — начинаете применять его везде? Сомневаюсь. Относитесь критически, у вас своя голова на плечах, и вы можете обработать поступившую информацию, попробовать что-то на практике, и для себя понять — стоит оно того или нет.
Это в принципе мой первый проект под Unity, и я рассказал о том, через какие основные этапы пришлось проводить оптимизацию. И ведь мне тоже нужна помощь, и я озвучил в статье очень неприятное поведение плеера при запуске. Однако я не пошел во все статьи по Unity писать недовольные комментарии о том, что вы бы лучше про это написали, а не расписывали очевидные вещи, которые даже не всегда применимы, а в моей команде мы на такое не пойдем никогда — вы все делаете не так.
Я рад, если у вас в копилке столько опыта. Делитесь и дополняйте, помогайте другим — критика тоже полезна, но аргументируйте верно, подкрепляйте своими результатами, но не пытайтесь задавить тем, что вы с таким не сталкивались, и принятые меры слишком чрезмерны. Иногда нужно знать к чему мы стремимся. В моем случае, я запустил на мобильном устройстве и получил абсолютно неприемлемый результат. Возможно, у меня все неправильно, но я попытался это исправить. К сожалению, я сейчас не вижу каких-то «золотых» решений в коде применительно к моему проекту, которые бы обеспечили запуск на мобильных платформах.
Результат профайлера (мс):
AutoProperty 19.2
BackProperty 18.03
Methods 17.98
Field 2.86
До этого проводил похожее исследование циклом на 10 миллионов запросов к get и set, что привело к средним значениям в тиках:
AutoProperty ~2605162
BackProperty ~2535456
Methods ~2525719
Field ~777295
Из которых около 500000 это чистое время цикла, что в целом соответствует распределению значений выше.
Согласен — напрямую реализованные Свойства с явными геттерами и сеттерами практически равны по производительности явным Методам, и паритет тут в пределах погрешности. Однако всегда автосвойство проигрывает достаточно ощутимо, а поле по скорости вырывается с огромным преимуществом.
Я в своем проекте использовал почти везде автосвойства именно для инкапсуляции, однако увидев такую существенную разницу с полями — пришлось переходить на них.
2. GetComponent — да, быстрее будет складывать объекты напрямую, но в некоторых случаях, когда пишешь более общую логику, которую будешь развешивать на множество существующих объектов, есть большой соблазн забрать компонент именно через эту функцию. Однако речь в этом пункте шла не только об этой функции, но и стандартных компонентах вроде transform и rigidbody.
4. Опасно, но многие скрипты работы с математикой это здорово ускоряет. Если хочется в каждом из классов хранить по объекту одинакового вектора, то пожалуйста, но как-то привык чтобы кода было как можно меньше.
5. StringBuilder — это стандартное решение, и в данном случае оно все равно не спасает. В итоге необходимо все равно обращаться к ToString, что и вызовет дополнительную аллокацию. Есть грязные хаки для переиспользования памяти внутри StringBuilder, но меня даже это не спасло. Если интересно — советую поискать garbage-free-string, но для себя я не нашел среди этой информации приемлемого решения или даже намека на него.
Насчет читабельности — несколько утрированно, однако доля правды в этом есть, потому как я много посвящаю времени для вычистки грязного кода, и практически любая оптимизация, которая вроде бы и не требуется вне Unity, заставляет меня каждый раз вспоминать, что это только ради производительности, иначе я бы такого кода просто не написал.
Насчет комментариев у меня также свое мнение — удаляйте их отовсюду! Средства языка программирования достаточно выразительны, чтобы обойтись без них. Код не должен содержать магии ни под каким предлогом, кроме случая, когда это единственно возможное решение, и этот кусок каждый раз правит какой-то «добросовестный» коллега. Только для такого случая можно навесить комментарий с призывом не трогать, но если он протухнет, лично вы виноваты, в оставленном среди важных строк кода неверном мусорном комментарии.
Я сам всегда поражался на всех туториалах от Unity, всегда используют поля вместо свойств, и я был против этого, т. к. чистый код на C# подразумевает эти самые свойства! Лишь перенеся часть свойств в поля и увидев значительный прирост производительности, я категорично указал, что в Unity не место свойствам — хотя они у меня остались в конфиге и сохранениях, где к ним идет очень редкое обращение.
Также работа со строками — в моем случае я лишь избавился от постоянной аллокации текста, снизив нагрузку на GC(опять же кастомный под Unity), сгенерировав все строки изначально — да я держу их в памяти, но не аллоцирую каждый кадр. Забыл, кстати, среди CPU оптимизаций упомянуть лямбда выражения, каждый вызов которых также выливается в дополнительные аллокации в памяти. Меня спасло использование прямых делегатов.
Unity постоянно стремится к все новым оптимизациям, но пока — все что было описано, критично било по производительности — именно это моя основная причина. Ни один из описанных пунктов бы не появился здесь, если бы я лично не увидел положительного эффекта от каждого из них.
Однако всех играх есть конкретная ачивка за завершение сюжетной линии с определенной концовкой. Давайте возьмем к примеру недавние DarkSouls3 — игра конечно сложная, но целевая аудитория знает за что берет, и я очень удивлюсь, если новичок начнет именно с этой части знакомство с серией. Смотрим официальные данные: первую коновку получили 27.5%, вторую 19.7% и третью 15.8%, однако эти проценты нельзя суммировать, я очень удивлюсь, что кто-то на первом прохождении пошел сразу не за первой концовкой, потому как их достаточно нетривиально открывать. И это успешная игра с отличными оценками критиков. Не дотягивает до 30% прохождения.
DeusEx:Human Revolution: тоже есть ачивка за прохождение, и таких игроков 37%
Portal — 46%
Skyrim — 28%
GTA V — 22.5%
This War of Mine — 19%
Inside — 15.7%
Эти данные легко доступны, и они четко отражают завершил ли человек сюжетную часть, или нет.
Насчет игр со множеством концовок, я не вижу противоречий, чтобы каждая из концовок, как и промежуточные события могли эмоционально вовлекать игрока.
Однако я ни в коей мере не затрагивал несюжетные игры, в шахматах, например, если подумать, то принцип эмоционального вовлечения в процесс применим и к ним. Я легко могу представить вариант в котором мы анимируем реальных персонажей, которые сидят за столом, и в зависимости от ваших действий они с разным эмоциональным тоном — в проигрыше более раздражительно, или как боги, твердо передвигать фигуры. Каждый ход будет важен, а какие-то переломные моменты вроде очевидных ошибок, или перевеса игры в одну сторону, показывать заранее под такой момент подготовленные кат-сцены. К сожалению, как мне видится — это сгодится только на несколько раз, и дальше будет только раздражать, т. к. длина игровой сессии слишком мала, и концентрация таких моментов будет просто зашкаливать. Хотя кто-то возьмется и за это и будет безумно доволен. И я скорее черпал вдохновение из фильмов, где сценаристы обычно вписывают дополнительный не очень связанный с игрой сюжет, но при этом очень серьезно стараются развлекать и вовлекать зрителя в процесс самой игры. Поэтому вовлечь можно во все. Даже в набор очков ради очков!
Слова Кодзимы тоже можно интерпретировать по-разному. Но в моей интерпретации здесь — действительно противоположно. С другой стороны, если подумать, что его слова имели эффект скорее сбавить пыл и не вкладываться только в концовку — тут я только за, главное чтобы все было на высоком уровне, и дальше по статье. Хотя, опять же, я не могу припомнить, чтобы культовые японские игры не вовлекали в процессе прохождения. Концовка просто всегда была квинтэссенцией произведения, при этом оставляя множество отличных моментов и по мере прогресса. Так что, может, это я надумываю, а Кодзима действительно неправ.
Насчет UI, практически все указывают, что с ним что-то не то, но никто не может сказать — что же именно. У меня осталась основная идея, как его можно полностью переделать, но это будет позже.
Запекание как раз дает большой эффект, иначе разрешение теней просто стремится к нулю.
К концу разработки и я намного быстрее лепил модели, и даже переделывал их с нуля (учитывая, что основных моделей около 50, не считая кучи вспомогательных, то получаемое количество часов — это тоже немало, хотя я, конечно, тратил больше), но взять готовые как-то рука не поднялась. Буду совершенствоваться.