Ниже для кого-то может быть спойлер. Не читайте, если играете в первый раз.
Помню, как меня убило большое дерево дне на 6-7 и я начал всё заново. Подумал: «Ну теперь-то я знаю как сразу скрафтить кострище, сейчас буду развиваться быстрее». Начал уже строить каменный забор и делать дорогу от дома до сгенерированной брусчатки, как наступила зима. Для меня это был шок. Ни запасов еды, ни запасов топлива для кострища, ни теплой одежды. Следующая игра была в подготовке к зиме. Соломенный загон с 30 пойманными кроликами, 2 стака семечек, куча заячьих наушников и т.д. Хорошо… Но в последний день лета в мой загон попадает молния и все мои 30 кроликов превратились в быстропортящееся мясо и игра опять стала выживанием. Таких эмоций давно от игр не получал.
Тот же майнкрафт был бы намного интереснее и глубже, если бы имел своей целью именно выживание, а не являлся конструктором с необходимостью добычи кубиков. Для того вида, в котором майнкрафт существует сейчас, противопоказана перманентная смерть. Вот там она убивает интерес. Точно так же можно делать очень сложную сцену в 3д-макс и абсолютно не сохраняться, а потом получить синий экран и все труды исчезли.
Смысл есть, для исследователей это огромный механизм в котором можно долго разбираться, для достигателей это инструмент влияния. Сложная модель окружения выведет ПвЕ на новый уровень. Взаимоотношение с окружающей средой может создать новые типы геймплея, профессии егеря или эколога. Приемы непрямого воздействия, например продажа винтовок племенам гоблинов, живущих вокруг поселения враждебных игроков, усложнит последним ПвЕ. Ну и много чего еще =)
Согласись, что концепция живого окружающего мира, какой-то действительно живой флоры и фауны, это очень интересно. Моделировать поведение людей и события, связанные с ними, можно в однопользовательских играх (любимый Tropico), но нет смысла в MMO.
Думаю идеальная симуляция это то, что игрок создает самостоятельно, допустим берем KSP — изначально это абсолютно чистый мир с вращающимися телами. Но выведите корабль на орбиту и у вас появится космический мусор, кто то застрянет на дальней орбите, кого то придется спасать с муна потому что у него кончилось топливо, от мусора придется избавляться. А если поставить пару модов еще придется наращивать связь. И т.д. и т.п. Т.е. игроку(или игрокам) должны быть даны инструменты с помощью которых они заставят двигаться и развиваться статичную картинку, тогда им не придется вникать в сложные и неинтересные системы, поскольку они сами будут их создавать. Другими словами, не надо селить игрока в заготовленный мир, пусть он создает его самостоятельно.
«Идеальный сталкер» вспомнился, ну или то к чему приблизилась франшиза в чистом небе.
Как по мне, больше всего вредят костыли которые вбили в игру, чтобы игрок не разломал систему нафиг. Те же последние базы которые нельзя взять. Или очень-очень сложно, что аж нельзя. Или оно ни с того ни с сего ресается. Или еще каким-то нелепым образом материализуется восстанавливая баланс. Который мы так заботливо ломали.
В любом случае, даже с технической точки зрения позволить истребителям в реальном времени летать между ив-капиталами. Это практически не реально, это потребовало бы полностью переписать движок игры, плюс во много раз улучшить отклик от сервера.
Учитывая прирост производительности, стабилизировавшийся на уровне «10-15% в поколение в оптимизированных приложениях» и продолжающуюся переориентацию чипмейкеров на мобильный рынок — на серьезный рост я бы не расчитывал. Разве что «вдруг» произойдет какой-то прорыв. Но рынком он, кажется, не востребован.
По поводу Симсов… Хитрый план — катить колесо! =)) Что мешало цинично охмурить и переспать с рыженькой, пока сосед на работе? На правах доктора зло! Муа-ха-ха!!! =)))))))))))))
О, отлично. :) Мне просто показалось, что я и без того выхожу за всякие мыслимые форматы, как по времени, так и по объему, поэтому решил срезать этот угол. :)
Как и в случае апофении, источник игровой насыщенности сложно разглядеть. Но у меня есть несколько примеров. Главный принцип: создавать больше интересных событий и избегать неинтересных.
Выбирайте минимальную модель для поддержки историй и событий, которые хотите видеть в игре.
Это сложный совет, и я постараюсь объяснить.
Представьте, что мы делаем игру и думаем над моделью еды. Насколько она должна быть сложной? Сколько видов пищи нам создавать? У нас есть выбор:
— Много видов пищи! Сыр, оленина, говядина, птица, брокколи, ячмень, кукуруза, пиво, вода, соки и т.д. Сотни вариантов, каждый со своими свойствами.
— Категории пищи по типам: Мясо, овощи, напитки.
— Категории по качеству: высоко- средне- и низкокачественная еда.
— Одна сущность: еда есть еда.
— Ничего: пища не моделируется и никто не ест.
Что же выбрать?
Выбирайте минимальную модель, которая поддержит те виды историй и событий, которые вы хотите видеть в игре.
Подумайте, насколько игровые истории связаны с едой? Если вы делаете симуляцию колонизации Нового Света в 1550-м году, еда — важный элемент, ведь голод — это ключевой движитель событий и историй в таком сеттинге. Угроза голода тем или иным образом является частью большинства игровых историй. Таким образом, тут нужна подробная модель еды. В такой игре разница между тюленьим жиром и овощами существенна, поскольку диета из одного жира зимой ведет к цинге, которая в свою очередь — к смерти. На кону человеческие жизни!
Однако, если ваша игра — симулятор тюрьмы, возможно, вам стоит вообще отказаться от моделирования пищи, либо сделать её максимально просто. Потому что тюремные истории в общем-то не про пищу. Сложная система еды просто добавит “шума”, который никак не относится к историям и событиям, которые волнуют игроков. В этом случае лучше добавить глубины системам дружбы, банд или драк.
В общем, склоняйтесь к простейшим вариантам. Вам не нужно симулировать всё. Игра — это соавтор, а не автор. Вам надо лишь дать намёк — и апофения игроков дополнит детали.
Используйте волосяной принцип для придания колорита с минимумом затрат.
“Принцип волос” — это мой термин для тех частей симуляции, которые ни на что не влияют. Я называю это так потому, что они произрастают от ядра игры, не привнося ничего назад, как волосы на голове. Эти “волоски” могут вообще игнорироваться игроками, которым они не интересны, а любопытные получат дополнительные впечатления.
Примеры:
— В Dwarf Fortress у каждого гнома есть описание внешности. Оно ни на что не влияет, но помогает игроку представить каждого конкретного гнома.
— В Prison Architect у заключённых есть криминальное прошлое. Пока оно ни на что не влияет, но добавляет деталей, если вы следите за конкретным персонажем.
— В The Sims, когда симы болтают, темы разговоров отображатся символами в диалоговых пузырьках. В целом, эти темы ни на что не влияют. Во время разговора в любом случае растёт их показатель взаимотношений. Но игрок может, если хочет, следить за темами разговоров и тем как они переходят от денег к машинам, а потом к общим знакомым, например.
Такие “волоски” легко и просто создавать с точки зрения дизайна. Они никак не влияют на ядро системы и не усложняют её — зато добавляют глубины для пытливых игроков.
Пример разработки: рост растений в Eclipse Colony.
Давайте перейдём к практике и посмотрим на простую проблему, с которой я столкнулся при разработке игры Eclipse Colony совсем недавно, в мае 2013-го. Приготовьтесь напрячь мозги — будет подробный анализ того, что казалось маленькой сложностью.
Задача: Растения растут по таймеру. Их можно собирать, когда таймер истёк. Однако, урожай не зависит от того, в вакууме они или нет. Кроме того, хочется добавить возможность ухаживать за растущими побегами и получать больше урожая.
Я проработал несколько вариантов для этой проблемы перед тем, как решить окончательно. Вот они:
Вариант 0 – Ничего не трогать.
— Ничего не делать, пусть растения растут по таймеру везде одинаково.
Анализ: вариант 0 всегда должен рассматриваться. В симуляторе всегда есть над чем поработать. Можно сделать получше систему дружбы и взаимоотношений. Можно добавить новых зверей, дикие растения или оружие. Улучшить генерацию мира, и т.д., и т.п. Надо быть уверенным, что возникшая задача находится в первых строках списка приоритетов. В этом случае я был уверен, что проблема важная, ведь угроза голода — важная часть жизни космической колонии.
Вариант 1 — ввести переменную урожая.
— Каждое растение получит новую переменную — урожайность.
— При сборе количество пищи зависит от этой урожайности
— Каждый раз, когда фермер обрабатывает растение, урожайность растет. Новая обработка возможна по истечении соответствующего таймера.
— Повреждение растений снижает урожайность.
— Нахождение в вакууме снижает урожайность.
Анализ: поначалу мне всё нравилось, но штука в том, что вводится новая переменная и нежелательная сложность. Как урожайность будет работать для диких растений? Как она реагирует на “обычные” повреждения типа огня или взрывов? Надо ли дать растением параметр “здоровье”? Всё это сделало вариант 1 не слишком привлекательным.
Вариант 2 — использовать таймер роста.
Помните, что у растений уже есть таймер созревания?
— Каждая обработка ускоряет созревание растений
— Повреждение обращает таймер времени созревания
— Растения в вакууме замедляют рост
Анализ: простота — это хорошо. не нужно новых переменных. Но эта модель далека от реальности — растения не растут медленнее от недостатка ухода. У них может быть плохой урожай, но они цветут и плодоносят примерно в одинаковое время. В этой модели возможны глупые ситуации вроде постоянного небольшого повреждения растений, ведущего к тому, что они никогда не созреют или наоборот — абсурдно быстрому созреванию при частом уходе.
Вариант 3 – использовать переменную здоровья.
— У растений будет стандартная, существующая в игре переменная здоровья.
— Урожай пропорционален здоровью растения в момент сбора.
— Здоровье понемногу постоянно уменьшается (вредители и т.п.)
— Растения повреждаются в вакууме или “обычными” источниками урона типа огня.
— Обработка растений по сути восстанавливает их здоровье.
Анализ: здесь нет новых переменных или нового интерфейса, что прекрасно. Этот вариант отражает идею роста растений достаточно хорошо и даже поддерживает идею гниения — созревшие плоды теряют здоровье со временем! Это похоже на минимальную модель, отражающую значимые вещи и поддерживающую истории, которые я хочу видеть в игре как в соавторе игрока.
Я решил использовать такой вариант. Но и он не окончателен и может поменяться по мере тестирования.
Нет — тут смерть является частью геймплея и развития. Именно после смерти вы получаете баллы, позволяющие открыть новых персоонажей.
Смерть скорее является философией игры, тут как в Dwarf Fortress — «Loosing is fun!» — смерть, во всем ее многообразии, учит игрока на его ошибках и собственно порождает этот самый фан от игры.
Вроде как можно обойти смерть и перейти в следующий мир без нее, но довольно сложно, сейчас не вспомню что там надо построить…
www.dfwk.ru/%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B0%D1%8F_%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D1%8F_Dwarf_Fortress
Ниже для кого-то может быть спойлер. Не читайте, если играете в первый раз.
Помню, как меня убило большое дерево дне на 6-7 и я начал всё заново. Подумал: «Ну теперь-то я знаю как сразу скрафтить кострище, сейчас буду развиваться быстрее». Начал уже строить каменный забор и делать дорогу от дома до сгенерированной брусчатки, как наступила зима. Для меня это был шок. Ни запасов еды, ни запасов топлива для кострища, ни теплой одежды. Следующая игра была в подготовке к зиме. Соломенный загон с 30 пойманными кроликами, 2 стака семечек, куча заячьих наушников и т.д. Хорошо… Но в последний день лета в мой загон попадает молния и все мои 30 кроликов превратились в быстропортящееся мясо и игра опять стала выживанием. Таких эмоций давно от игр не получал.
Тот же майнкрафт был бы намного интереснее и глубже, если бы имел своей целью именно выживание, а не являлся конструктором с необходимостью добычи кубиков. Для того вида, в котором майнкрафт существует сейчас, противопоказана перманентная смерть. Вот там она убивает интерес. Точно так же можно делать очень сложную сцену в 3д-макс и абсолютно не сохраняться, а потом получить синий экран и все труды исчезли.
Как по мне, больше всего вредят костыли которые вбили в игру, чтобы игрок не разломал систему нафиг. Те же последние базы которые нельзя взять. Или очень-очень сложно, что аж нельзя. Или оно ни с того ни с сего ресается. Или еще каким-то нелепым образом материализуется восстанавливая баланс. Который мы так заботливо ломали.
Спасибо за статью.
Создание 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!» — смерть, во всем ее многообразии, учит игрока на его ошибках и собственно порождает этот самый фан от игры.
Вроде как можно обойти смерть и перейти в следующий мир без нее, но довольно сложно, сейчас не вспомню что там надо построить…