Думаю идеальная симуляция это то, что игрок создает самостоятельно, допустим берем 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!» — смерть, во всем ее многообразии, учит игрока на его ошибках и собственно порождает этот самый фан от игры.
Вроде как можно обойти смерть и перейти в следующий мир без нее, но довольно сложно, сейчас не вспомню что там надо построить…
Когда увидел это, то понял чего мне не хватало в авиасимуляторах, возможности крутить головой. Если это запилят в ВарТундре или Варплане, это будет сильным геймплейным преимуществом.
Вообще то, учитывая подход сисипи к выпуску новых продуктов (анонс даста был в 2006, кажется), сомневаюсь что мы увидим нечто подобное на транквилити в ближайшие годы
Может это и к лучшему, качество связи и железо как раз дорастут до возможности нормальной реализации.
Вообще то, учитывая подход сисипи к выпуску новых продуктов (анонс даста был в 2006, кажется), сомневаюсь что мы увидим нечто подобное на транквилити в ближайшие годы. Это скорее забавный эксперимент, которым будут заниматься в свободное время.
Как по мне, больше всего вредят костыли которые вбили в игру, чтобы игрок не разломал систему нафиг. Те же последние базы которые нельзя взять. Или очень-очень сложно, что аж нельзя. Или оно ни с того ни с сего ресается. Или еще каким-то нелепым образом материализуется восстанавливая баланс. Который мы так заботливо ломали.
Спасибо за статью.
Создание 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. Плюс не поставил только потому, что нахожусь в режиме экономии энергии :)