О, отлично. :) Мне просто показалось, что я и без того выхожу за всякие мыслимые форматы, как по времени, так и по объему, поэтому решил срезать этот угол. :)
Как и в случае апофении, источник игровой насыщенности сложно разглядеть. Но у меня есть несколько примеров. Главный принцип: создавать больше интересных событий и избегать неинтересных.
Выбирайте минимальную модель для поддержки историй и событий, которые хотите видеть в игре.
Это сложный совет, и я постараюсь объяснить.
Представьте, что мы делаем игру и думаем над моделью еды. Насколько она должна быть сложной? Сколько видов пищи нам создавать? У нас есть выбор:
— Много видов пищи! Сыр, оленина, говядина, птица, брокколи, ячмень, кукуруза, пиво, вода, соки и т.д. Сотни вариантов, каждый со своими свойствами.
— Категории пищи по типам: Мясо, овощи, напитки.
— Категории по качеству: высоко- средне- и низкокачественная еда.
— Одна сущность: еда есть еда.
— Ничего: пища не моделируется и никто не ест.
Что же выбрать?
Выбирайте минимальную модель, которая поддержит те виды историй и событий, которые вы хотите видеть в игре.
Подумайте, насколько игровые истории связаны с едой? Если вы делаете симуляцию колонизации Нового Света в 1550-м году, еда — важный элемент, ведь голод — это ключевой движитель событий и историй в таком сеттинге. Угроза голода тем или иным образом является частью большинства игровых историй. Таким образом, тут нужна подробная модель еды. В такой игре разница между тюленьим жиром и овощами существенна, поскольку диета из одного жира зимой ведет к цинге, которая в свою очередь — к смерти. На кону человеческие жизни!
Однако, если ваша игра — симулятор тюрьмы, возможно, вам стоит вообще отказаться от моделирования пищи, либо сделать её максимально просто. Потому что тюремные истории в общем-то не про пищу. Сложная система еды просто добавит “шума”, который никак не относится к историям и событиям, которые волнуют игроков. В этом случае лучше добавить глубины системам дружбы, банд или драк.
В общем, склоняйтесь к простейшим вариантам. Вам не нужно симулировать всё. Игра — это соавтор, а не автор. Вам надо лишь дать намёк — и апофения игроков дополнит детали.
Используйте волосяной принцип для придания колорита с минимумом затрат.
“Принцип волос” — это мой термин для тех частей симуляции, которые ни на что не влияют. Я называю это так потому, что они произрастают от ядра игры, не привнося ничего назад, как волосы на голове. Эти “волоски” могут вообще игнорироваться игроками, которым они не интересны, а любопытные получат дополнительные впечатления.
Примеры:
— В Dwarf Fortress у каждого гнома есть описание внешности. Оно ни на что не влияет, но помогает игроку представить каждого конкретного гнома.
— В Prison Architect у заключённых есть криминальное прошлое. Пока оно ни на что не влияет, но добавляет деталей, если вы следите за конкретным персонажем.
— В The Sims, когда симы болтают, темы разговоров отображатся символами в диалоговых пузырьках. В целом, эти темы ни на что не влияют. Во время разговора в любом случае растёт их показатель взаимотношений. Но игрок может, если хочет, следить за темами разговоров и тем как они переходят от денег к машинам, а потом к общим знакомым, например.
Такие “волоски” легко и просто создавать с точки зрения дизайна. Они никак не влияют на ядро системы и не усложняют её — зато добавляют глубины для пытливых игроков.
Пример разработки: рост растений в Eclipse Colony.
Давайте перейдём к практике и посмотрим на простую проблему, с которой я столкнулся при разработке игры Eclipse Colony совсем недавно, в мае 2013-го. Приготовьтесь напрячь мозги — будет подробный анализ того, что казалось маленькой сложностью.
Задача: Растения растут по таймеру. Их можно собирать, когда таймер истёк. Однако, урожай не зависит от того, в вакууме они или нет. Кроме того, хочется добавить возможность ухаживать за растущими побегами и получать больше урожая.
Я проработал несколько вариантов для этой проблемы перед тем, как решить окончательно. Вот они:
Вариант 0 – Ничего не трогать.
— Ничего не делать, пусть растения растут по таймеру везде одинаково.
Анализ: вариант 0 всегда должен рассматриваться. В симуляторе всегда есть над чем поработать. Можно сделать получше систему дружбы и взаимоотношений. Можно добавить новых зверей, дикие растения или оружие. Улучшить генерацию мира, и т.д., и т.п. Надо быть уверенным, что возникшая задача находится в первых строках списка приоритетов. В этом случае я был уверен, что проблема важная, ведь угроза голода — важная часть жизни космической колонии.
Вариант 1 — ввести переменную урожая.
— Каждое растение получит новую переменную — урожайность.
— При сборе количество пищи зависит от этой урожайности
— Каждый раз, когда фермер обрабатывает растение, урожайность растет. Новая обработка возможна по истечении соответствующего таймера.
— Повреждение растений снижает урожайность.
— Нахождение в вакууме снижает урожайность.
Анализ: поначалу мне всё нравилось, но штука в том, что вводится новая переменная и нежелательная сложность. Как урожайность будет работать для диких растений? Как она реагирует на “обычные” повреждения типа огня или взрывов? Надо ли дать растением параметр “здоровье”? Всё это сделало вариант 1 не слишком привлекательным.
Вариант 2 — использовать таймер роста.
Помните, что у растений уже есть таймер созревания?
— Каждая обработка ускоряет созревание растений
— Повреждение обращает таймер времени созревания
— Растения в вакууме замедляют рост
Анализ: простота — это хорошо. не нужно новых переменных. Но эта модель далека от реальности — растения не растут медленнее от недостатка ухода. У них может быть плохой урожай, но они цветут и плодоносят примерно в одинаковое время. В этой модели возможны глупые ситуации вроде постоянного небольшого повреждения растений, ведущего к тому, что они никогда не созреют или наоборот — абсурдно быстрому созреванию при частом уходе.
Вариант 3 – использовать переменную здоровья.
— У растений будет стандартная, существующая в игре переменная здоровья.
— Урожай пропорционален здоровью растения в момент сбора.
— Здоровье понемногу постоянно уменьшается (вредители и т.п.)
— Растения повреждаются в вакууме или “обычными” источниками урона типа огня.
— Обработка растений по сути восстанавливает их здоровье.
Анализ: здесь нет новых переменных или нового интерфейса, что прекрасно. Этот вариант отражает идею роста растений достаточно хорошо и даже поддерживает идею гниения — созревшие плоды теряют здоровье со временем! Это похоже на минимальную модель, отражающую значимые вещи и поддерживающую истории, которые я хочу видеть в игре как в соавторе игрока.
Я решил использовать такой вариант. Но и он не окончателен и может поменяться по мере тестирования.
Нет — тут смерть является частью геймплея и развития. Именно после смерти вы получаете баллы, позволяющие открыть новых персоонажей.
Смерть скорее является философией игры, тут как в Dwarf Fortress — «Loosing is fun!» — смерть, во всем ее многообразии, учит игрока на его ошибках и собственно порождает этот самый фан от игры.
Вроде как можно обойти смерть и перейти в следующий мир без нее, но довольно сложно, сейчас не вспомню что там надо построить…
Когда увидел это, то понял чего мне не хватало в авиасимуляторах, возможности крутить головой. Если это запилят в ВарТундре или Варплане, это будет сильным геймплейным преимуществом.
Вообще то, учитывая подход сисипи к выпуску новых продуктов (анонс даста был в 2006, кажется), сомневаюсь что мы увидим нечто подобное на транквилити в ближайшие годы
Может это и к лучшему, качество связи и железо как раз дорастут до возможности нормальной реализации.
Вообще то, учитывая подход сисипи к выпуску новых продуктов (анонс даста был в 2006, кажется), сомневаюсь что мы увидим нечто подобное на транквилити в ближайшие годы. Это скорее забавный эксперимент, которым будут заниматься в свободное время.
Игра замечательна своей хардкорностью, и была бы лучше, если б сейвилась автоматом хотя бы раз 5-10 игровых дней. Череда воскрешений с необходимостью снова насобирать тонну травок, камней и бревен для создания нужного для выживания набора удобств убивает весь интерес, превращая игру в рутину. Раз за разом ты проходишь эти стадии, надеясь пожить чуть дольше, а потом вновь умираешь, теряя нажитое. В этом плане смерть в майнкрафте куда как удобнее — позволяет не прекращать развитие своего жилища, но в то же время не является безболезненной (частенько теряются собранные ресурсы, доспех и, конечно же, опыт, да и сам персонаж может потеряться в бесконечном мире)
Базовые 5 скафандров даются сразу. Эти пресловутые десять фишек на продвинутую модель набираются совсем не сложно. Если играть, конечно. Но возможно, ты хотел легко открыть все 10 продвинутых костюмов? Тогда да, без «доната» никак. :)
Игра хороша. Покупал еще месяца за три до релиза, игра довольно сильно изменилась за это время и продолжает развиваться (пещеры недавно начали вводить).
Мне показалась простой — не в смысле простой в прохождении, а скорее не хватает глубины HnH и отчасти того, о чем сказал Атрон.
Но попробовать определенно стоит.
А тем временем войнушка, о которой, вот уже полгода, талдычат большевики, началась. Сегодня сварм задеплоился в фонтейн. Как сказал любимый наш Варежка «Дело не в том, что кто то плохой или хороший. Просто нам нужны деньги, а в фонтейне они есть».
Хм, видимо с первой закрытой беты они сделали много шагов в направлении монетаризации. Костюмы раньше открывались как-то походя. Дорого, довольно долго, но вливаний не требовалось.
Спасибо за статью.
Создание Story-Richness
Как и в случае апофении, источник игровой насыщенности сложно разглядеть. Но у меня есть несколько примеров. Главный принцип: создавать больше интересных событий и избегать неинтересных.
Выбирайте минимальную модель для поддержки историй и событий, которые хотите видеть в игре.
Это сложный совет, и я постараюсь объяснить.
Представьте, что мы делаем игру и думаем над моделью еды. Насколько она должна быть сложной? Сколько видов пищи нам создавать? У нас есть выбор:
— Много видов пищи! Сыр, оленина, говядина, птица, брокколи, ячмень, кукуруза, пиво, вода, соки и т.д. Сотни вариантов, каждый со своими свойствами.
— Категории пищи по типам: Мясо, овощи, напитки.
— Категории по качеству: высоко- средне- и низкокачественная еда.
— Одна сущность: еда есть еда.
— Ничего: пища не моделируется и никто не ест.
Что же выбрать?
Выбирайте минимальную модель, которая поддержит те виды историй и событий, которые вы хотите видеть в игре.
Подумайте, насколько игровые истории связаны с едой? Если вы делаете симуляцию колонизации Нового Света в 1550-м году, еда — важный элемент, ведь голод — это ключевой движитель событий и историй в таком сеттинге. Угроза голода тем или иным образом является частью большинства игровых историй. Таким образом, тут нужна подробная модель еды. В такой игре разница между тюленьим жиром и овощами существенна, поскольку диета из одного жира зимой ведет к цинге, которая в свою очередь — к смерти. На кону человеческие жизни!
Однако, если ваша игра — симулятор тюрьмы, возможно, вам стоит вообще отказаться от моделирования пищи, либо сделать её максимально просто. Потому что тюремные истории в общем-то не про пищу. Сложная система еды просто добавит “шума”, который никак не относится к историям и событиям, которые волнуют игроков. В этом случае лучше добавить глубины системам дружбы, банд или драк.
В общем, склоняйтесь к простейшим вариантам. Вам не нужно симулировать всё. Игра — это соавтор, а не автор. Вам надо лишь дать намёк — и апофения игроков дополнит детали.
Используйте волосяной принцип для придания колорита с минимумом затрат.
“Принцип волос” — это мой термин для тех частей симуляции, которые ни на что не влияют. Я называю это так потому, что они произрастают от ядра игры, не привнося ничего назад, как волосы на голове. Эти “волоски” могут вообще игнорироваться игроками, которым они не интересны, а любопытные получат дополнительные впечатления.
Примеры:
— В Dwarf Fortress у каждого гнома есть описание внешности. Оно ни на что не влияет, но помогает игроку представить каждого конкретного гнома.
— В Prison Architect у заключённых есть криминальное прошлое. Пока оно ни на что не влияет, но добавляет деталей, если вы следите за конкретным персонажем.
— В The Sims, когда симы болтают, темы разговоров отображатся символами в диалоговых пузырьках. В целом, эти темы ни на что не влияют. Во время разговора в любом случае растёт их показатель взаимотношений. Но игрок может, если хочет, следить за темами разговоров и тем как они переходят от денег к машинам, а потом к общим знакомым, например.
Такие “волоски” легко и просто создавать с точки зрения дизайна. Они никак не влияют на ядро системы и не усложняют её — зато добавляют глубины для пытливых игроков.
Пример разработки: рост растений в Eclipse Colony.
Давайте перейдём к практике и посмотрим на простую проблему, с которой я столкнулся при разработке игры Eclipse Colony совсем недавно, в мае 2013-го. Приготовьтесь напрячь мозги — будет подробный анализ того, что казалось маленькой сложностью.
Задача: Растения растут по таймеру. Их можно собирать, когда таймер истёк. Однако, урожай не зависит от того, в вакууме они или нет. Кроме того, хочется добавить возможность ухаживать за растущими побегами и получать больше урожая.
Я проработал несколько вариантов для этой проблемы перед тем, как решить окончательно. Вот они:
Вариант 0 – Ничего не трогать.
— Ничего не делать, пусть растения растут по таймеру везде одинаково.
Анализ: вариант 0 всегда должен рассматриваться. В симуляторе всегда есть над чем поработать. Можно сделать получше систему дружбы и взаимоотношений. Можно добавить новых зверей, дикие растения или оружие. Улучшить генерацию мира, и т.д., и т.п. Надо быть уверенным, что возникшая задача находится в первых строках списка приоритетов. В этом случае я был уверен, что проблема важная, ведь угроза голода — важная часть жизни космической колонии.
Вариант 1 — ввести переменную урожая.
— Каждое растение получит новую переменную — урожайность.
— При сборе количество пищи зависит от этой урожайности
— Каждый раз, когда фермер обрабатывает растение, урожайность растет. Новая обработка возможна по истечении соответствующего таймера.
— Повреждение растений снижает урожайность.
— Нахождение в вакууме снижает урожайность.
Анализ: поначалу мне всё нравилось, но штука в том, что вводится новая переменная и нежелательная сложность. Как урожайность будет работать для диких растений? Как она реагирует на “обычные” повреждения типа огня или взрывов? Надо ли дать растением параметр “здоровье”? Всё это сделало вариант 1 не слишком привлекательным.
Вариант 2 — использовать таймер роста.
Помните, что у растений уже есть таймер созревания?
— Каждая обработка ускоряет созревание растений
— Повреждение обращает таймер времени созревания
— Растения в вакууме замедляют рост
Анализ: простота — это хорошо. не нужно новых переменных. Но эта модель далека от реальности — растения не растут медленнее от недостатка ухода. У них может быть плохой урожай, но они цветут и плодоносят примерно в одинаковое время. В этой модели возможны глупые ситуации вроде постоянного небольшого повреждения растений, ведущего к тому, что они никогда не созреют или наоборот — абсурдно быстрому созреванию при частом уходе.
Вариант 3 – использовать переменную здоровья.
— У растений будет стандартная, существующая в игре переменная здоровья.
— Урожай пропорционален здоровью растения в момент сбора.
— Здоровье понемногу постоянно уменьшается (вредители и т.п.)
— Растения повреждаются в вакууме или “обычными” источниками урона типа огня.
— Обработка растений по сути восстанавливает их здоровье.
Анализ: здесь нет новых переменных или нового интерфейса, что прекрасно. Этот вариант отражает идею роста растений достаточно хорошо и даже поддерживает идею гниения — созревшие плоды теряют здоровье со временем! Это похоже на минимальную модель, отражающую значимые вещи и поддерживающую истории, которые я хочу видеть в игре как в соавторе игрока.
Я решил использовать такой вариант. Но и он не окончателен и может поменяться по мере тестирования.
Смерть скорее является философией игры, тут как в Dwarf Fortress — «Loosing is fun!» — смерть, во всем ее многообразии, учит игрока на его ошибках и собственно порождает этот самый фан от игры.
Вроде как можно обойти смерть и перейти в следующий мир без нее, но довольно сложно, сейчас не вспомню что там надо построить…
P.S. Плюс не поставил только потому, что нахожусь в режиме экономии энергии :)
Мне показалась простой — не в смысле простой в прохождении, а скорее не хватает глубины HnH и отчасти того, о чем сказал Атрон.
Но попробовать определенно стоит.