Игровой сервер — NET приложение на фреймворке Photon, Unity в сервере не участвует.
В симуляции используем отдельную 2D физику (VolatilePhysics) и периодически туда контрибьютим, т.к. в ней есть конкретные баги. Нам повезло, что мы смогли упростить взаимодействия до столкновений неупругих примитивов + рейкастов (сферические и обычные) для расчета видимости и попаданий.
Как при игре по сети вы боретесь с задержкой результатов ввода? Клиент ждет результат от сервера или отправляет на сервер ввод и действия постфактум а сервер верит?
Лучше забыть про юнити-опыт и изучать по Э.Троелсену, тренируясь в консольных приложениях и так далее по NET. стеку. Одна из плохих особенностей юнити, это то, что вы привыкаете работать в рамках фреймворка и не прививаете себе мышление использования инверсии зависимостей.
Это не верно. Средство редактирования кода никак не влияет на его выполнение. У вас что в моноДевелоп, что в студии, что в райдере будет при сборке вызываться один и тот же компилятор.
Пока кто-то не рванул покупать чехол с отсеком для карт. Не храните банковские карты вместе с телефоном! Это настолько абсурдно в плане безопасности, что лучше подарить гранату. Просто нет слов…
Какие то враки тут. Добавил по ссылке ноут в корзину, за 592.89, ввожу промокод — цена становится = $675.24. Отпало желание заходить на ваш сайт, рекомендовать друзьям и читать новости из этого потока. Тоже самое было с jd время назад. Жалко, тут обзоры были интересные =(
Я уверен что и кроме меня есть покупатели игр, которые не играют в стиме в них, так как играли раньше в пиратские клиенты и покупают чтобы отдать должное разработчикам.
Прочитав статью, пришел в голову еще один совет:
Не нужно каждый кадр обновлять строки на экране. Юзеру это не нужно и оптимизацию нужно бы начинать с этого а не с исследования по работе срок в памяти. Решение: считать среднее за секунду в float и выводить каждую секунду строкой в UIText.
Даже не знаю каких советов больше, полезных о которых уже 100 раз писали или новых вредных. Заминусовал бы статью, да кармы недостаточно (наверное не зря).
У вас в многих тезисах нет объяснения, почему именно так нужно делать. Попробуйте написать о причинах и найдете ошибки в своих тезисах. Для затравки:
— Почему свойства на столько не производительны что стоит от них отказаться?
— При использовании типа строка в фпс у вас течет память, дело в алокации памяти типом строка, не оптимальным использованием компонента Text или постоянный ребилд кеша шрифтов? Каким образом пул строковых литералов помогает не использовать строки?
К сожалению этого будет недостаточно, будут артефакты и засветы. Все из-за того что в некоторых случаях пиксели будут подсвечиваться и прямым и отраженным светом и накладываться на освещение только с прямым светом. Если ввести ограничение на количество отражений, то можно интенсивность освещения для каждой итерации записывать в свой цветовой диапазон. Тогда можно проходить для пикселя примерно так:
— смотрим освещенность из главного диапазона, освещаем ей.
— сморим освещенность из менее приоритетного диапазона (первое отражение) и досветляем если значение больше чем в первой итерации, и не засветляем если больше.
и так до окончания диапазонов. Экономим n текстур,
Но вообще все это сложно, и не эффективно, для динамического освещения нужно исследовать в другую сторону. Данные алгоритмы пригодны только для красивой статики, лепить поддержку динамики не продуктивно. ИМХО.
Можно рассмотреть вариант:
1. Определить конкретную геометрию как динамическую (только присутствие\отсутствие).
2. Разделить результат расчета света на несколько слоев, для каждого луча или группы.
3. При пересечении лучом динамической геометрии Считать сразу 2 варианта. С учетом отражения и с учетом прохода сквозь.
4. В рантайме в зависимости от вкл\выкл динамического объекта использовать один или другой результат расчета слоев.
5. Перед самим рендером из набора необходимых для кадра слоев собрать текущую карту освещенности.
Правда при большом количестве коллизий будет задействовано очень много видеопамяти, нужно дополнительно упаковывать или обрезать результаты расчетов света для лучей\групп.
Начинать использовать DI нужно сразу с чего нибудь классического и проверенного временем, даже в юнити. http://www.ninject.org Отлично работает при компиляции с MONO. По вашей ссылке неизвестный проект с 20 коммитами в год.
Вот почему когда я читаю такие статьи мне представляется икающий Роберт Мартин?
А вот заменить монолитную архитектуру нужно было бы уже давно, если простого рефакторинга не предвидится, или вообще тяжело такого места найти, которое чисто по-фаулеровски можно было бы отрефакторить.
И самый главный критерий необходимости начать переходить на микросервисную архитектуру — когда стоимость добавления новой фичи начинает превосходить выгоду от этой самой фичи.
Это говорит лишь о сильной связанности кода и плохо спроектированном апи модулей. Микросервисы тут не причем, я считаю. Все изобретено много лет назад и решается в любом случае только рефакторингом в пользу ООП и слабой связанности. Даже при отделении модуля для вынесения его в отдельный сервис вам придется привести в порядок работающий с ним код и унифицировать вызовы + изолировать типы.
Что это за бред? У вас при такой реализации невидимая часть остаётся помеченной статичным флагом? Тогда ваше решение работает только если корабль не плывёт, правильно я понимаю?
В симуляции используем отдельную 2D физику (VolatilePhysics) и периодически туда контрибьютим, т.к. в ней есть конкретные баги. Нам повезло, что мы смогли упростить взаимодействия до столкновений неупругих примитивов + рейкастов (сферические и обычные) для расчета видимости и попаданий.
Не нужно каждый кадр обновлять строки на экране. Юзеру это не нужно и оптимизацию нужно бы начинать с этого а не с исследования по работе срок в памяти. Решение: считать среднее за секунду в float и выводить каждую секунду строкой в UIText.
У вас в многих тезисах нет объяснения, почему именно так нужно делать. Попробуйте написать о причинах и найдете ошибки в своих тезисах. Для затравки:
— Почему свойства на столько не производительны что стоит от них отказаться?
— При использовании типа строка в фпс у вас течет память, дело в алокации памяти типом строка, не оптимальным использованием компонента Text или постоянный ребилд кеша шрифтов? Каким образом пул строковых литералов помогает не использовать строки?
— смотрим освещенность из главного диапазона, освещаем ей.
— сморим освещенность из менее приоритетного диапазона (первое отражение) и досветляем если значение больше чем в первой итерации, и не засветляем если больше.
и так до окончания диапазонов. Экономим n текстур,
Но вообще все это сложно, и не эффективно, для динамического освещения нужно исследовать в другую сторону. Данные алгоритмы пригодны только для красивой статики, лепить поддержку динамики не продуктивно. ИМХО.
1. Определить конкретную геометрию как динамическую (только присутствие\отсутствие).
2. Разделить результат расчета света на несколько слоев, для каждого луча или группы.
3. При пересечении лучом динамической геометрии Считать сразу 2 варианта. С учетом отражения и с учетом прохода сквозь.
4. В рантайме в зависимости от вкл\выкл динамического объекта использовать один или другой результат расчета слоев.
5. Перед самим рендером из набора необходимых для кадра слоев собрать текущую карту освещенности.
Правда при большом количестве коллизий будет задействовано очень много видеопамяти, нужно дополнительно упаковывать или обрезать результаты расчетов света для лучей\групп.
Стоит 5-6к в Москве, не понимаю для чего мне платить на 3-4к дороже?
Это говорит лишь о сильной связанности кода и плохо спроектированном апи модулей. Микросервисы тут не причем, я считаю. Все изобретено много лет назад и решается в любом случае только рефакторингом в пользу ООП и слабой связанности. Даже при отделении модуля для вынесения его в отдельный сервис вам придется привести в порядок работающий с ним код и унифицировать вызовы + изолировать типы.
Это тоже просто фичи проекта, которые дешевле реализовывать поверх хорошего кода.