Дневники разработки №1. Население и работы


На мой взгляд, это самый сложный с точки зрения баланса и геймплея элемент. И поэтому именно его я вынес на первое место. Думаю, если правильно реализовать его, своего рода костяк, то остальные механики будет делать намного... проще не то слово. Скорее понятнее.

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

Численность группы
Мы знаем, что размеры групп в те времена были относительно небольшой. 10-20 человек: это средний размер. Максимум 30-40, но это предел. Почему подобная цифра является пределом?

Во-первых, группу бОльшего размера элементарно трудно прокормить. Еды в каменном веке хоть и было очень много, но распределена она была неравномерно. Область, в которой жили люди (условный квадрат 30х30км) обладает значительными ресурсами, но нужно уметь их добыть. Зверь в лесу живёт не на одном месте. Стада подвержены миграции, а значит нужно знать: когда и какой зверь будет в нужном месте в нужное время. Растения сезонны, и опять же надо знать где и когда. Птицы перелетают в дальние страны, а яйца откладывают в определённое время. Даже рыба в реке подчиняется своим циклам. Поэтому ритм жизни охотника-собирателя в палеолите – это такая слегка ленивая погоня за пищей где она находится в данный момент времени. И ходить за ней огромной толпой в 100 человек – мягко говоря неразумно. Компактные сообщества с этой задачей справляются куда эффективнее.

Во-вторых, группой такого размера просто можно управлять в «ручном режиме». Община в 20-30 человек представляет собой в первую очередь семью. Семья с многими коленами, роднёй, где каждый друг другу родственник в каком-то поколении. Но всё же это семейная группа, выживающая в большом и опасном мире. Группа же бОльшего размера – это уже несколько семей, связанных пусть и кровными узами, но куда более слабыми. Всё же между группами: отец и мать, у которых 4 взрослых сына, у сыновей есть жёны и совокупно у них всех 10 детей и группа 4 семьи, у каждой из которых был общий предок два поколения назад – это очень сильная разница. Особенно психологически. Поэтому условно в такой группе какая-то часть людей решила, что сегодня мы пойдём не яйца птичьи собирать, а в другую сторону грибы собирать. И так они отдрейфовали постепенно в новую группу.

О чём нам это говорит, если хочется сделать и интересную и реалистичную механику?
Это значит, что в первой части игры, посвящённой именно раннему первобытному обществу до организации в большую группу, необходимо создать такой лимит в 30 человек. Сделать это можно разными способами:
1. Жёстко поставить ограничитель, связанный с текущим «политическим строем»
2. Сделать механику, создающую по триггеру отток людей после достижения определённого лимита.
3. Ограничить хозяйство таким образом, чтобы они физически не могли развиться дальше.

Первый вариант я отмёл сразу, как слишком упрощённый. А вот оставшиеся два реалиям отвечают оба. Как же их реализовать?

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

С третьим пунктом сложнее. Так как выправить его можно только после реализации игрового баланса. Но кое-какие выводы о механике сделать можно. Мне видится реализации этого процесса в механике примерно так: на каждом квадрате есть определённый ограничитель на число вакансий. Но ограничение не строгое, просто с превышением лимита игрок может получить событие, резко осаживающее хозяйственную деятельность в данной клетке. Например, от слишком интенсивной охоты клетка просто получит модификатор «Животные истреблены». И всё, дамы и господа палеолитические, покушали оленинки. Теперь или в другой квадрат валите или меняйте источник пищи. Ну или склеивайте ласты, куда же без этого.

Состав группы
На заре истории, традиционные роли в социальной жизни ещё не были определены. В целом, в любом обществе могли сформироваться любые, даже самые фантастические варианты устройства.
Однако, есть некоторые группы населения, которые для реализации механики нужно выводить в разные показатели. Это три возрастные и две гендерных группы: мужчины и женщины, а также деление на детей, взрослых и стариков (спойлер, к старикам относятся и invalid жители, например, получившие увечья и не способные выполнять ряд работ).

К каждой группе применяются свои методики пересчёта численности. Дети могут появиться только если есть женщины, способные их рожать, при чём в зависимости от физиологии и образа жизни, меняются и показатели, применяемые для пересчёта. Например, в кочевом обществе охотников женщины будут рожать детей реже, чем у осёдлых земледельцев просто потому что это сложно. Дети могут умереть в детстве, женщины могут умирать во время родов. Дети растут (при чём возраст совершеннолетия может сдвигаться в генетике, что повлияет на формулу пересчёта числа повзрослевших за ход). Ну и старость, вероятность дожить до которой определяется по средней продолжительности жизни.

Дневники разработки №1. Население и работы

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

В чём же суть проблемы:
1. У нас есть игровая карта с 81 зоной, в каждой из которых доступны различные работы.
2. У нас есть шесть групп населения, которым доступны разные вакансии и разрешения на них (я считаю это важным, так как за распределением разрешений на работы следует и разное положение полов в обществе. Развитие полового равенства или неравенства найдёт отражение как в культуре, так и в религии, так что ИМХО игроку нужно оставить возможность экспериментировать с этим аспектом развития общества)
3. Вопреки распространённому мнению, общество древних людей было обществом изобилия. Современная аналитика показывает, что охотники-собиратели тратили на добычу пропитания порядка 2-3 часов в день (чаще всего это был 1-2 дня «интенсивной» добычи с перерывами «на перекуры», а затем 2 дня отдыха). А один человек за трудодень вполне успешно добывал количество пищи, необходимое для пропитания ещё 4х человек. Это показатель, который экономика аграрная добилась только в 19 веке! А значит, в игровой механике нельзя делать однозначную ставку на трудность добычи пищи
4. В то же время, многие непрофильные вещи добываются и делаются легко и быстро, хотя их нужно реализовывать в механике для развития других, смежных с ними отраслей науки и культуры. Жители каменного века умели делать каменные орудия, делали одежду, строили свои скромные жилища и много чего ещё. Но они не тратили на это своё регулярное время, так сказать не работали фулл-тайм. Сделать каменные инструменты? Потратили совокупно неделю в году. Починить шалаш? Полдня ненапряжной работы. Сшить одежду? Неделя неспешного труда и вот тебе одежда, которую будешь носить следующие 10 лет, а через 10 лет починим и будешь носить ещё 10 лет.
5. Ход игры составляет 10 реальных лет. То есть мы не просто должны назначить человечка на работы, мы прописываем ему занятие на 10 реальных лет вперёд.
И из этих предпосылок нужно собрать играбельное решение.
Как вообще можно решать проблему назначения на работы? Рассматриваются только методы, которые позволяют масштабировать решение на численность населения от 10 до 10 тысяч.

Самое простое и очевидное решение – один человек = один работник. Назначаем его на вакансию и получаем в конце хода результат.
Плюсы:
Позволяет легко распределять людей на работы в разных клетках, на разные гендерно-возрастные должности.
Легко считается (что важно при отлавливании багов и дисбаланса в механике)
Минусы:
Крайне сложно назначать людей на небольшие работы, отличные от добычи пропитания. Только в самой начальной фазе существует много предметов, которые племя так или иначе должно производить: одежда, заготовка дров, добыча и обработка камня, создание копий и т.д. И на всё это всего 15-20 человек, половина из которых дети. С ростом населения эффект нивелируется, оставляя чувство условности, что мы не на 10 лет человека отправляем собирать камни на берегу реки, а так сказать показываем сколько в целом времени от общих человеко-часов племя тратит на эту деятельность, но как говорится… это было уже весной и он отнёс ёлку обратно.
Геймплей подразумевает постоянное изменение условий окружающей среды. И население племени тоже может изменяться скачкообразно (впрочем, в обществе из 20-30 человек, где каждый на счету, любое изменение кажется скачком). Значит если у нас произошёл резкое сокращение популяции, то мы должны часть назначенных людей снять с работ. Как это сделать и кого снимать? Нужен или понятный алгоритм или система приоритетов. Иначе окажется, что каждый ход когда у игрока вымирает часть племени, приходится искать, где игра срезала «лишних» работников. Можно, конечно, как-то это сгладить, например, убирать людей сначала самых дальних от центрального поселения, но всё же это не решает проблемы глобально.
С ростом населения, которое по идее может достичь нескольких тысяч в эндшпиле игровой партии (привет Чатал-Хююку!) как бы это ежеходное назначение людей не превратилось в адовый геморрой игрока и источник бесконечных проклятий в сторону разработчиков.

Второй вариант – это установка лимитов на вакансии и их приоритеты. А дальше, пусть людишки сами себя назначают (читай – компьютер посчитает сам куда сколько запихать). Вариант похожий на Banished или Tropico (там, правда, вакансии создавались постройкой определённых строений, но не суть)
Плюсы:
Нивелируется проблема «снятия людей». Компьютер обладает алгоритмом, который сам, не тревожа игрока этим займётся в соответствие с приоритетами. И если игрок сказал, что охотится будут 10 человек несмотря ни на что, значит от голода племя не умрёт, компьютер послушно забьёт на другие отрасли хозяйства.
На больших цифрах населения, гораздо проще назначать людей. Вопрос только зачем?
Всё ещё легко считается. Если не считать алгоритма приоритезации, усложняющий общую математику.
Минусы:
Непонятно как распределять людей территориально. Добавлять вакансии с регионов в общий стек? Но тогда как игроку заниматься микроконтролем каждой клетки отдельно. Например, игрок считает, что на клетке нужно держать минимум 4х охотников. Но как это посчитать если все вакансии в одном стеке? А если нет, то что же, нам делать 81 стек охоты на каждую клетку?
С поло-возрастным распределением тоже непонятно как работать.
Не решается проблема с небольшими работами.

Третий вариант – это пропорциональное распределение населения. То есть мы не занимаемся назначением каждого человечка, но имеем некий общий пул рабочей силы на каждой из групп. В этом пуле мы можем по вакансиям распределить, что 20% времени взрослые мужчины посветят охоте, 15% рыбалке. А вот старики 5% времени будут делать инструменты, а ещё 20% времени рассказывать сказки молодому поколению про то что раньше была травка зеленее.
Плюсы:
Забиваем на микроменеджмент большой болт.
Легко накладывается на механику поло-возрастного распределения
Позволяет не только реализовать распределение и на небольшие задачи (отдайте им 2% времени и людишки сами этим займутся), но и давать задачи более абстрактные (отдых, занятия культурные и духовные, образование, общение с другими племенами и т.д.)
Рост населения нам пофигу, что 10 человек, что 10 тысяч – мы управляем процентом времени
Минусы:
Не совсем минус, но примера реализации такой механики в подобных стратегиях я вспомнить не смог. Какие-то отдельные элементы (типа распределения очков исследования в разные разделы) встречались, но вообще механика ближе к каким-то симуляторам жизни.
Психологически тяжело прослеживается зависимость между усилиями одного человека и его вкладом в общее дело (частично нивелируется информативным интерфейсом).
Сложно считать. А значит высока вероятность багов и дисбаланса.
Непонятно как завязать на эту систему клетки территорий. Либо присутствие на них ваших соплеменников увязывать с другой механикой, но опять же непонятно как их скрестить. Например, мы ставим 4х охотников в лес. Как это отобразить в пропорции? Как жёсткое закрепление определённого процента? Или выводить таких людей из системы подсчёта? Но как тогда быть с ресурсами. В общем, та ещё задачка.
Непонятно как реализовать лимиты на работы. А без этого теряется весь геймплей каменного века. Ведь мы должны вешать на клетки депрессантный модификатор если игрок слишком интенсивно её юзает. Без этого ничто не помешает ему и в палеолите довести население до любого значения.

Четвёртый вариант – это распределение не людей, а неких единиц работы. Давайте представим, что взрослый мужчина – это 5 единиц работы. Старик – 3 единицы. А ребёнок 2 единицы. А дальше распределяем их.
Плюсы:
Мы решаем проблему микрозадач.
Легко используем распределение по возрастам и клеткам
Минусы:
По сути все те же, что у первого варианта – постоянно приходится перераспределять эти человеко-часы, что с ростом населения (и любым изменением) превращается в адЪ.

Какие есть выводы:
Поло-возрастное распределение в целом тянут все способы. Разве что в втором и третьем есть нюансы.
Камнями же преткновения становятся:
Распределение по территориям (решается назначением отдельных человечков, не решается пропорциональностью)
Лимиты (решается назначением отдельных человечков, не решается пропорциональностью)
Масштабируемость (решается пропорциональностью, но не решается отдельными человечками)
Микрозадачи (решается пропорциональностью, но не решается отдельными человечками)

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

А как вы считаете, какая механика лучше? И может я упустил какой-то способ, который позволит решить вопрос с назначением на работы?