It depends. Если проект — мультиплеерный шутер, например, с активным использованием физики — да, однозначно придётся поднимать инстансы на сервере. Ну или иметь головняк с подключением сторонней физ. библиотеки к юнити (типа Bullet), но такое часто не стоит свеч.
Из минусов — некоторое усложнение серверной архитектуры, т.к. поднять инстанс game сервера и заставить его корректно общаться с клиентами и другими серверами — это не то же самое, что запустить логику игры из dll в отдельном потоке.
Вообще, это довольно частый кейс, когда бизнес-логику выносят в отдельный проект. Особенно это актуально для игр с мультиплеерной составляющей, когда надо синхронизировать состояния игры. Одна и та же логика крутится и на клиенте и на сервере. Не тащить же весь юнити проект в сервер, верно?
Такой подход удобен, например, в Unity3D, где нельзя (не рекомендуется) объявлять конструктор для классов, наследованных от MonoBehaviour. Приходится делать инъекцию в метод.
Раньше не сталкивался с понятием interface injection, но некоторые IoC фреймворки поддерживают такую фичу как инъекция в метод. Получается что-то типа такого:
public class Foo
{
IBar _bar;
Qux _qux;
[Inject]
public Init(IBar bar, Qux qux)
{
_bar = bar;
_qux = qux;
}
}
В данном примере нет необходимости объявлять интерфейс, но приходится помечать метод атрибутом, чтобы фреймворк понял, куда требуется внедрить зависимости.
Скажите, а как быть с физическими нагрузками после операции? Я имею в виду не сразу после, а по прошествии, скажем, полугода-года и далее. Есть ли какие-то ограничения, риски? Под физ. нагрузками я подразумеваю спортзал, например.
Интересно, как картинка улучшается с каждым скриншотом =)
Единственное, что мне не давало покоя — слишком массивные прямоугольники границ уровня. Перебор цветов не помогал и я добавил на них простые геометрические узоры, которые немного разнообразили длинные участки. Мелочь, но с ней все стало на свои места. Правда, на маппинг текстур ушла не одна неделя. Все делалось вручную в Maya. Модели каждого уровня бились на полигоны и в uv-editor подгонялись под заготовку текстуры.
Можно же было декалями наложить детали. Меньше возни с uv маппингом. Правда производительность может пострадать.
И сколько тогда по Вашему программист должен в среднем уделять времени работе в рабочий день?
Видите ли, тут речь скорее не о том, сколько должен и сколько работает «на самом деле». А о порочности самого подхода с баллами, т.к. он провоцирует работников направлять свои усилия не на решение задач, а на эффективное получение баллов. Каким способом будут получены баллы — уже не важно. Отсюда растут всякие неувязки, типа «зачем брать большую сложную задачу, если я возьму 5 мелких, решу их и получу то же количество условных единиц эффективности».
Подобные подходы к стимулированию довольно часто встречаются в играх, если грубо, «регулярно нажимай на кнопку, чтобы получать награды». В играх такой подход работает, потому что там цель — удержание игрока и его возврат в игру, т.е. цель — чтобы игрок нажимал на кнопку.
С точки зрения работодателя же целью является конечный продукт, который можно продать. А у него программисты целыми днями баллы зарабатывают, т.е. «жмут на кнопку» вместо того чтобы работать.
Всё вышесказанное не претензия к конкретной системе, а к непродуманности измерения эффективности умственного труда в целом.
Резюмируя, работодателю что нужно, чтобы программисты баллы зарабатывали или продукт делали? Поверьте, эффективные и неэффективные сотрудники и без всяких баллов довольно неплохо видны, если работаешь непосредственно с ними, а не с табличками в трелло.
Я сам никогда не работал с «балльными» системами и учётом производительности, но так, чисто умозрительно, предположу, что введение подобных систем приводит к повышению эффективности работника в действиях, которые направлены на получение максимального количества баллов, а не на повышение качества или скорости работы.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Из минусов — некоторое усложнение серверной архитектуры, т.к. поднять инстанс game сервера и заставить его корректно общаться с клиентами и другими серверами — это не то же самое, что запустить логику игры из dll в отдельном потоке.
В данном примере нет необходимости объявлять интерфейс, но приходится помечать метод атрибутом, чтобы фреймворк понял, куда требуется внедрить зависимости.
700 draw calls это, пожалуй, многовато, учитывая большое количество статики. Как будто почти ничего не батчится.
Для игровой индустрии 10 лет — это не «всего десять лет», а скорее «целых десять лет».
Можно же было декалями наложить детали. Меньше возни с uv маппингом. Правда производительность может пострадать.
Видите ли, тут речь скорее не о том, сколько должен и сколько работает «на самом деле». А о порочности самого подхода с баллами, т.к. он провоцирует работников направлять свои усилия не на решение задач, а на эффективное получение баллов. Каким способом будут получены баллы — уже не важно. Отсюда растут всякие неувязки, типа «зачем брать большую сложную задачу, если я возьму 5 мелких, решу их и получу то же количество условных единиц эффективности».
Подобные подходы к стимулированию довольно часто встречаются в играх, если грубо, «регулярно нажимай на кнопку, чтобы получать награды». В играх такой подход работает, потому что там цель — удержание игрока и его возврат в игру, т.е. цель — чтобы игрок нажимал на кнопку.
С точки зрения работодателя же целью является конечный продукт, который можно продать. А у него программисты целыми днями баллы зарабатывают, т.е. «жмут на кнопку» вместо того чтобы работать.
Всё вышесказанное не претензия к конкретной системе, а к непродуманности измерения эффективности умственного труда в целом.
Резюмируя, работодателю что нужно, чтобы программисты баллы зарабатывали или продукт делали? Поверьте, эффективные и неэффективные сотрудники и без всяких баллов довольно неплохо видны, если работаешь непосредственно с ними, а не с табличками в трелло.