Драмы, с которыми я столкнулся за год соло-разработки, чтобы довести игру до релиза
Бодания с Valve, страдания на ровном месте, непредвиденные переделывания, дурной воркэраунд и лучшие анекдоты в мире..
Бодания с Valve, страдания на ровном месте, непредвиденные переделывания, дурной воркэраунд и лучшие анекдоты в мире..
Было бы очень интересно почитать статью про оптимизацию игр.
Поясню.
Для меня, как для человека который в игры только играет, а не разрабатывает, очень странно встречать в статье про игру которая визуально выглядит довольно просто, хоть какое-то упоминание оптимизации, и что самое главное необходимости в оптимизации т.к. есть просадки.
В голове не укладывается, как могут в одном мире существовать современные AAA игры которые выглядят лучше чем жизнь и проблемы просадки фпс в играх как в статье.
Хотелось бы почитать, откуда берутся проблемы и больше конкретики по железу, т.к. если просадки появляются на железе уровня калькулятора то как бы и ладно, а если нет - см. прошлый абзац)
Мысль понятна.
Вряд ли буду писать отдельную статью об этом, но пару моментов в общих чертах тут отмечу.
- Да, я действительно ориентировался на более слабые машины, чем обычно ориентируются трипл-А. И если бы я многие оптимизационные действа не делал - комп, что стабильно тянет трипл-А - мою бы игру точно потянул бы. Но мне желательно, чтобы на простеньких конфигурациях тоже игралось комфортно, ради чего оптимизации и есть.
- "игра выглядит просто, но проблемы просадки как в ААА". Скажем, по хорошему, практически любая маломальская игра независимо от графония и кол. процессов в миллисекунду требует определённые решения, чтобы она работала более оптимизированно. Чисто в силу её уникальных особенностей надо подбирать алгоритмы подходящим образом, чтобы конкретно твоя игра выполняла задачу наиболее быстрым способом. Другое дело, что часть разработчиков могут себе позволить не заниматься некоторыми такими штуками, если посчитают, что потенциально затраченные ресурсы будут выше требуемого результата. Например, пусть такой-то алгоритм работает медленнее, чем мог бы, но зато сэкономим месяц работы, всё равно современные машины и так справляются. Я мог бы поступить также и просто чутка поднять системные требования. Решил делать иначе.
- Конкретно у меня ещё актуальна проблема с тем, что игра может подхватить встроенную видеокарту вместо дискретной. Это весьма серьезная проблема, которую у меня не выходит решить. Потому я дополнительно замотивирован стараться как можно сильнее оптимизировать игру для той части игроков, у кого игра подцепит встроенную, чтобы уменьшить вероятность риска просадок.
...
Всё это в целом.
Если вкратце. Графика – не единственное, что съедает производительность в играх. Нагружать систему могут и другие вещи:
1. Физические взаимодействия. Расчет физики – это затратный процесс. К примеру, если на игровую сцену добавить 100 обычных кубов без текстур и заставить их постоянно соприкасаться и отталкиваться друг от друга по физической модели, нагрузка на слабую систему будет огромная, хоть и выглядит сцена очень примитивно.
2. Плохой код. Например, в Unity стандартный метод спавна и уничтожения объектов довольно тяжелый. Это не проблема, если он используется всего пару раз на сцене. Но при быстром создании-уничтожении большого числа сущностей (классический пример: пули) нагрузка становится ощутимой.
Для решения этой проблемы используется трюк: при загрузке сцены создается архив с уже готовыми объектами. Их не нужно спавнить, достаточно только изменить состояние на "вкл". Но и тут есть тонкости. Большие архивы тоже влияют на производительность, потому что потребляют много памяти компьютера. Приходится постоянно балансировать и искать, какой из вариантов оптимальнее в конкретном случае.
Ну, вот спеки.
Это калькулятор или нет? )