Флейм
GameDev.ru / Флейм / Форум / Матричная разработка. Размышления о новой парадигме игровых движков

Матричная разработка. Размышления о новой парадигме игровых движков

Поделиться
Advanced: Тема повышенной сложности или важная.
Страницы: 1 2 Следующая »
VirtexПостоялецwww17 июля 201719:04#0
Представьте, что вся разработка игры сводилась бы к заполнению 2D матрицы. Т.е. вся структура игры - у вас на экране, одним листом. (Конечно, его можно масштабировать. Также, наверное, каждая ячейка матрицы тоже может быть матрицей.)

Что тогда должны представлять собой ячейки этой матрицы? И какие возможны связи между ячейками?

Можно ли из такого представления структуры игры получить какие-то преимущества перед традиционными способами (Unity и т.п., а также игровые конструкторы)?

Для простоты можете рассмотреть случай, когда движок ориентирован лишь на какой-то определенный тип игр.

slatazanПостоялецwww17 июля 201719:22#1
Virtex
Матрицы не помнимаю. Я верю в кубики, и анкеты для кубиков. Выставил галочки и числа - кубики нашли друг-друга.
kvakvsПостоялецwww17 июля 201719:40#2
Пытаемся подогнать задачу под структуру данных?
Ну в матрице можно хранить граф. А в графе можно хранить квесты например, таланты рпг, карту мира, поведение монстров.
VirtexПостоялецwww17 июля 201719:51#3
kvakvs
> Пытаемся подогнать задачу под структуру данных?

Да. Мне нравится играть в игру Towers:
Изображение

Прошел ее даже на максимальной сложности.

И подумал: а можно ли и делать игры так же...

VirtexПостоялецwww17 июля 201719:52#4
Как минимум, в матричной форме можно решать задачу балансировки геймплея. Как и в игре Towers - подбираем значения, зная граничные условия.
lookidПостоялецwww17 июля 201719:58#5
Нету никакой новой или старой пагадигмы. Есть просто ряд вещей, который должен быть реализован достаточно эффективно по перфомансу:
1) менеджер ресурсов
2) менеджер объектов/Entity Component System/SceneGraph
3) локальность данных
4) события
5) Всякие layouts типа сеть, UI, AI
6) апдейты сети, скриптов
7) рендер
Скриптеру достаточно знать всего-лишь паттерн State Machine и порождающий типа Factory.
VirtexПостоялецwww17 июля 201720:32#6
lookid
> Есть просто ряд вещей, который должен быть реализован достаточно эффективно
> по перфомансу

Ну это понятно. Предположим, всё это уже есть (например, матричный двиг делается как надстройка над традиционным). Куда двигаться дальше и есть ли смысл? Вот в чем вопрос.

gudleifrПостоялецwww17 июля 201720:36#7
Virtex
> Представьте, что вся разработка игры сводилась бы к заполнению 2D матрицы. Т.е.
> вся структура игры - у вас на экране, одним листом.

Курите Джефф Раскин Интерфейс: новые направления в проектировании компьютерных систем.

VirtexПостоялецwww18 июля 20171:39#8
gudleifr, на какой там странице про матричные движки? :)
VirtexПостоялецwww18 июля 20171:40#9
slatazan
> Я верю в кубики, и анкеты для кубиков.

Хм. Ну, кубики можно расставлять в ячейки матрицы...

А что за кубики-то?

gudleifrПостоялецwww18 июля 20178:33#10
Virtex
> gudleifr, на какой там странице про матричные движки? :)
Читать от начала до конца. Это не справочник. Это книга.

emptiness_rainУчастникwww18 июля 201711:53#11
Virtex
В чем польза такого подхода?
ZegalurПостоялецwww18 июля 201713:05#12
VirtexПостоялецwww18 июля 201713:40#13
Мне ночью снились эти матрицы. :)

В виде 2D матриц можно представить многие игровые сущности, и этого достаточно для создания многих игр!

  • локация для 2D-игр (вид сверху, изометрия, платформеры...);
  • 2D navmesh (дискретный, на основе регулярной сетки);
  • карта высот для 3D ландшафта;
  • ИИ персонажей - в виде клеточных автоматов;
  • диалоги - сводятся к клеточным автоматам;
  • квесты - сводятся к клеточным автоматам.

Дальше появляется вот какая фишка: и navmesh, и клеточные автоматы можно конвертировать в код на Прологе (т.к. Пролог именно этим и занимается - вычисляет логические состояния со сложными условиями). А это означает возможность объединить всё вышеперечисленное в единую базу знаний. Что дает возможности:

  • проводить программные тесты на достижимость тех или иных ветвей игрового сценария (т.е. отлавливать баги, которые допустили геймдиз, левелдиз и сценарист);
  • создавать сложный ИИ - где персонажу тоже потенциально будет доступна вся информация о мире, причем не только как о статичной системе, но и о доступных персонажу возможностях (куда пойти, с кем поговорить, чтобы получить желаемое);
  • генерировать некоторый контент (квесты, диалоги, NPC, куски локаций) прямо по ходу игры, исходя из доступных ГГ на текущий момент путей достижения игровых целей.

VirtexПостоялецwww18 июля 201715:07#14
Остался один важный нерешенный вопрос:

Кодинг

Какие преимущества дает "матричный кодинг", как он вообще может выглядеть, какие геймдев-задачи легко на нем решать?..

Подходы к такому кодингу могут быть разными:

    1) в ячейке матрицы может храниться скрипт на каком-нибудь популярном языке, дополненном операторами для взаимодействия с содержимым соседних ячеек (как с кодом, так и с данными в них);

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


Zegalur
> https://esolangs.org/wiki/Piet

Прикольная штука. :) Подходит для п. 2 выше.

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

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

* * *

По п. 1 выше, в качестве кандидата обязательно стоит рассмотреть Пролог. Т.к. ранее был сделан вывод, что на Прологе можно естественным образом достичь тесной интеграции с матричными игровыми данными.

Страницы: 1 2 Следующая »

/ Форум / Флейм / Разработка игр

2001—2017 © GameDev.ru — Разработка игр