Искусство ограничений: когда меньше означает больше

Чтобы креативно что-то создавать, нужно заводить себя в рамки. Если разработчику предоставить ресурсы современного компьютера, их будет очень сложно потратить кроме как сделать детализированные модели с миллионом полигонов, использовать самые тяжёлые алгоритмы, реалистичную симуляцию воды, и т.д. Но это отстой...

На случай если вы хотите быстро-производительную крутую симуляцию воды: вот

Сами по себе алгоритмы это не плохо, но не нужно пытаться собрать перчатку Таноса из всех самых реалистичных алгоритмов. У компьютера есть всего 16 миллисекунд чтобы просчитать логику игры и отрисовать кадр. Это необходимое условие для стандарта 60 фпс. С современным уровнем стандартов ограничение становится ещё жёстче: есть лишь 7-8 миллисекунд. Иногда быстрое лучше реалистичного, – позволяет больше уместить в игру.

Но даже если мы все купим себе суперкомпьютеры, это не означает что стоит пихать в игры всё самое тяжёлое. Детализированные текстуры сверхвысокого качества с анимациями 2007 года – это выглядит просто смешно, даже жалко. Жалко что художники тратят своё время на все эти качественные текстуры ради какой-то поделки которая просто смешно и неуклюже выглядит.

  • Heroes of Might and Magic III до сих пор многие играют и даже стримят и смотрят, настолько лаконичная получилась игра, до сих пор живёт
  • Warcraft 3 в настройках переключают на минималистичную стилизованную графику вместо современных высоко-детализированных
  • GTA 5 стилизованная графика тоже как будто не стареет, в неё продолжают играть

Механически эти игры тоже получились более интересными чем то что делали десятилетие после них, потому в них продолжают играть. Хотя сейчас компьютеры стали мощнее, казалось бы – можно сделать больше и лучше. Но не нужно. Будет также жалко как сверх-текстуры с анимациями 2007 года. Игры должны обрастать мясом равномерно.

Для максимизации креатива, нужно ограничивать себя там где реальность даёт слишком много свободы, и стараться пробиться через ограничения в остальном. Тогда получается настоящее произведение искусства.

Сферы где нужно накладывать на себя ограничения, сегодня – это в первую очередь работа художников, в частности 3D моделлеров. Стилизованная графика нередко выглядит лучше любой реалистичной графики.

2D художники в пиксель-арте тоже имеют частую проблему, выбирают слишком высокое разрешение текстуры с которым потом не справляются – слишком долго и сложно рисовать такую детализацию, на выходе получается чересчур мало контента, мало «самой игры», вечный ранний доступ. Поэтому художникам нужно себя ограничивать, чтобы сделать больше и лучше.

Кто первый скажет что в статье слишком много воды? Красивой стилизованной воды

Игровому разработчику тоже нужно себя ограничивать, но чуть по-другому. Нужно не быстро делать, нужно делать то что ты делаешь – быстрым, и оригинальным. Вместо миллиона скриптов сделать парочку крутых систем взаимодействующих друг с другом, делать свои движки, оптимизированные под конкретные задачи игры а не просто «для всего». А также нужна работа с нетворкингом, изучение особых паттернов, бесшовных загрузок.

«The Day Before» (TDB) фактически закрылся из-за того что люди не умели в нетворкинг. Слишком много денег жрали сервера – но откуда растут ноги?

Первая более очевидная причина-нога, TDB – это чёртова игра на ассетах, для мультиплеера используется какой-то плагин который работает на дефолтных настройках и шлёт кучу всего что не нужно слать. Что опять же нас отсылает к искусству ограничений: не использовать монструозный плагин который адаптирован на любой случай, а делать свой движок и своё networking решение, считать каждый UDP-пакетик и слать только необходимое. Меньше нагрузка на север означает что нужно меньше серверов. Прямая экономия.

Вторая причина менее очевидная, это может заслуживать отдельной статьи, но я постараюсь коротенько разобрать:

*Годовой контракт на сервера – один миллион долларов
*Годовой контракт на сервера – один миллион долларов

Когда обнаружилось что активность на серверах упала, что делать со всеми этими серверами которые не используются? Досрочно закрывать контракт в виду процедуры банкротства, видимо – подумали авторы.

Но если всё делать правильно, аренда серверов должна динамически регулироваться в зависимости от онлайна. Видимо авторы TDB не только не умели в геймдев, но и не умели в сервера, поэтому им приходилось платить даже когда сервера стали не нужны, оставшись связанными контрактом.

Если платить сразу на год-два вперёд, можно получить приличную скидку, в районе 30%, поэтому всегда имеет смысл взять парочку серверов в долгосрок. Но не надо брать наперёд целый ангар серверов сразу.

В реальном мире есть все необходимые средства автоматизации чтобы регулировать нагрузку, – есть такие гиганты как Amazon, Microsoft, Google, в российских реалиях такой компанией может выступить Яндекс. Все они позволяют платить только за используемые мощности. Упал онлайн? Удалил ненужные сервера с аккаунта – теперь они не твои и платить за них не нужно. Разумеется, звучит это проще на словах чем на деле, потому что есть свои технические трудности, и нужны соответствующие специалисты.

«Боже, какие сервера, прекрати! Я всего лишь кот»
«Боже, какие сервера, прекрати! Я всего лишь кот»

В день перед объявлением о закрытии, в The Day Before было 8 тысяч игроков. PUBG тоже была допотопной поделкой на ассетах и плагинах, и она тоже в первый месяц жизни имела в среднем 17 тысяч онлайна. Потом ещё 50 тысяч, ещё, и ещё. Спустя год – три миллиона онлайна. А ведь казалось бы, обе эти игры – это поделки из ассет-стора. Авторы не сдавались, делали патчи, и были чуть лучше готовы с точки зрения серверов, и с подручными средствами для расширения, арендовали только необходимое. Уважаю, хоть игра не по мне.

Так что даже 8 тысяч онлайна это вполне рабочая цифра, и вместо того чтобы объявлять о закрытии, можно продолжать делать патчи, хотя бы исправить отсутствие зомби и вечную сигнализацию – но всё это имеет смысл если платить за те сервера которые используешь, а не за ангар пустых серверов.

Начинать с малого, и расширяешься динамически – таково искусство ограничений в организации серверов. Но видимо разработчики TDB такую правду о серверах не знали, либо слишком сильно верили в тотальный успех.

Искусство ограничений: когда меньше означает больше

Есть и сферы, где разработчику надо пробиться через ограничения: ИИ, процедурные анимации, методы генерации, системы, системы, системы. На мой взгляд, здесь как раз игры используют меньше чем могли бы, хотя инструменты есть. Идеальные условия для проявления креативности.

Например, Шум Перлина позволяет добиться красивых генераций, но использует много ресурсов, а ещё алгоритм весьма неизменяем в виду своей сложности. Фактически, креативных генераций добиться алгоритмом Перлина сложнее, чем более простым алгоритмом «клеточного автомата».

Подведём итоги: не бойтесь использовать более простые технологии. Стилизацию вместо реализма, пиксель-арт, 2D вместо 3D, клеточный автомат вместо шума Перлина, использовать более простой и лёгкий Godot вместо UE, или вовсе делать свой движок – если это «меньше» позволит вам делать «больше», быть более оригинальным .

2727
61 комментарий

Для максимизации креатива, нужно ограничивать себя там где реальность даёт слишком много свободы, и стараться пробиться через ограничения в остальном. Тогда получается настоящее произведение искусства

Процитирую великих: Илья Репин
Сначала художник рисует плохо и просто.
Потом рисует плохо и сложно.
Затем сложно и хорошо
И лишь затем просто и хорошо.

В каком то роде перебесится и пройти через этап когда все переусложняешь - это нормально.
Не нормально это застревать в этом этапе навсегда.

12

Так жизни не хватит Репиным стать. Мы активно работаю лет 50 (с 20 до 70), а многие и того меньше.

2

Комментарий удалён модератором

Комментарий недоступен

2

Вообще-то есть такой, и даже что-то типа своего движка тоже делал – чтобы не такой громоздкий как UE, и скорее больше похоже на лёгкий ECSY от Мозиллы. Я вдохновился их движком и начал свой с нуля делать. Получилось даже лучше чем у Mozilla. На их же собственных примерах показатели получились лучше, просто потому что не использовал классы где не надо, а простые объекты. Скриншоты сравнений включены.

https://jerrygreen.vercel.app/blog/making-custom-game-engine

2

Комментарий недоступен

3