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

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

Страницы: 1 2 3 Следующая »
ZegalurУчастникwww18 июля 201715:21#15
галерея прикольная :)
http://www.dangermouse.net/esoteric/piet/samples.html

генератор простых чисел:
Изображение

аппроксимация пи:
Изображение

slatazanПостоялецwww19 июля 20170:38#16
Virtex
Наверно, у тебя сбой в терминах - матрицы нужны для графических нужд. А у тебя, нечто _опора_на_таблицу, где ячейка базовой таблицы, может содержать чилд-таблицу.

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

VirtexПостоялецwww7 дек. 20171:31#17
Еще вореция идеи.

Пиксель-функции

Я писал ранее, что каждая ячейка матрицы могла бы содержать некий код. Вот давайте, как вариант, представим, что это видеоматрица - т.е. каждая ячейка матрицы содержит код, вычисляющий цвет одного экранного пикселя.

Движок игры в каждом кадре вызывает функцию pixel с координатами всех пикселей поочередно.

Если не пользоваться визуальным матричным редактором (типа Excel), а описывать код для всех ячеек в одном текстовом файле, то для реализации такой схемы удобно использовать функциональные или логические ЯП - позволяющие осуществлять перегрузку функций по значению параметров. Примеры такого кода:

pixel (0, 0) :- <тут всякий код для вычисления этого пикселя>.

pixel (3, 4) :- <тут всякий код для вычисления этого пикселя>.

// Плюсы хитрой перегрузки - одной строчкой кода заливаем весь 1-й экранный столбец красным цветом
pixel (1, _) :- red.

// Заливаем нечетные ячейки во 2-м столбце синим, а четные - зеленым
pixel (2, Y) :- if odd(Y) then blue else green.

// Вычисляем пиксель через другие пиксели, как в Excel
pixel (5, 1) :- pixel (0, 0) + pixel (3, 4) + pixel (1, 1).

// Отрисовка движущегося объекта
pixel (X, Y) :- <тут код, не привязанный к конкретным координатам, и, например, сравнивающий их с координатами некоего игрового объекта - при совпадении возвращает его цвет>.

// Отрисовка другого движущегося объекта.
// Заголовок функции такой же, как у той, что выше. Они вызовутся обе.
pixel (X, Y) :- <некий код, но для другого объекта>.

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

При использовании некоторых ЯП типа Пролога возможны интересные конструкции, задействующие обратный поиск. Т.е. можно одной строчкой кода находить все пиксели с определенным цветом и проделывать над ними какие-либо действия.

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

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

* * *

Движок с такой системой визуализации - очень специфический и подходит не для всех игр. Давайте придумаем идеи игр, где такой движок было бы удобно использовать. Головоломки с цветными квадратиками/картинками и всякий галюциногенный артхаус - первое, что напрашивается. Но, возможно, применение столь нестандартного движка породит какие-то новые жанры... Инструмент ведь определяет мышление.

В качестве разминки можно подумать, как выглядел бы шутер на таком движке. :)

Правка: 7 дек. 2017 1:55

БаберЗабаненwww7 дек. 20171:44#18
Virtex
> Пиксель-функции
  Подкину тебе идею "нейро-пиксель-функция"
VirtexПостоялецwww7 дек. 20171:48#19
Бабер, и чо там? нейросети? :)

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

БаберЗабаненwww7 дек. 20171:51#20
Virtex
> Бабер, и чо там? нейросети? :)
  Да, если тебе покажется мало просто "пиксель-функций"

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

Правка: 7 дек. 2017 1:55

gamedevforПостоялецwww7 дек. 201721:48#21
Нужно добавить нейросети, блокчейн, бигдата, машинлининг.
VirtexПостоялецwww8 дек. 20170:46#22
Тыщ-пыщ-ололо, я водитель НЛО. Матрица пиксель-функций в действии:

Изображение

Я там в формулах использую время (функция tics у меня считает кадры), это позволяет динамически менять цвет пикселей, создавать эффект мерцания и иллюзию движения.

Всё, что показано в этом ролике, вся матрица функций размерностью 64x48 "свернута" в небольшой скрипт. Это на Прологе, но в данном случае формулы простые, на любом языке можно было сделать.

Матрица пиксель-функций | Матричная разработка. Размышления о новой парадигме игровых движков

Я еще подумаю, как прицепить другие фишки матричного движка, описанные в данном треде. Может, функционал Пролога там пригодится.

* * *

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

А пиксель-функции позволяют одним скриптом генерить бесконечные динамические миры налету.

Но это без геймплея пока...

MahagamПостоялецwww23 дек. 201712:45#23
Virtex
> Если создавать такую сцену в Юнити традиционными методами, то пришлось бы
> нарисовать и загрузить кучку спрайтов, накидать на сцену всяких объектов в
> визуальном редакторе, написать несколько скриптов...
я, конечно, извиняюсь за мой французский, но накуа такую сцену делать вообще?
VirtexПостоялецwww23 дек. 201719:48#24
Virtex
> Пиксель-функции

Кстати, их можно иначе назвать. Это описание/программирование графики в декларативном стиле. Ну или просто декларативная графика. По аналогии с декларативными ЯП - где нет как таковой четкой последовательной программы, есть лишь описание конечных целей и условий их достижения.

t800Забаненwww23 дек. 201721:32#25
Virtex
> Движок с такой системой визуализации - очень специфический и подходит не для
> всех игр. Давайте придумаем идеи игр, где такой движок было бы удобно
> использовать. Головоломки с цветными квадратиками/картинками и всякий
> галюциногенный артхаус - первое, что напрашивается. Но, возможно, применение
> столь нестандартного движка породит какие-то новые жанры... Инструмент ведь
> определяет мышление.
>
> В качестве разминки можно подумать, как выглядел бы шутер на таком движке. :)

А что тут думать вот есть у меня проект ИМХО как раз под Ваш движок см. http://wiki.kvkozyrev.org/forum/viewtopic.php?f=43&t=200

Правка: 23 дек. 2017 21:53

1 frag / 2 deathsУчастникwww24 дек. 20172:15#26
Virtex
> Представьте, что вся разработка игры сводилась бы к заполнению 2D матрицы. Т.е.
> вся структура игры - у вас на экране, одним листом.
Ага, 2д матрица буковок. Например:
#include <cstdio>

int main() {
  printf("%s\n", "Hello, World!");
  return 0;
}
VirtexПостоялецwww24 дек. 20175:01#27
t800
> проект ИМХО как раз под Ваш движок см.
> http://wiki.kvkozyrev.org/forum/viewtopic.php?f=43&t=200

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

КлапауцийЗабаненwww24 дек. 201711:21#28
Virtex
> Представьте, что вся разработка игры сводилась бы к заполнению 2D матрицы.
разве и правда есть смысл брать какие математические изощрения и пытаться выдувать из них модели реального мира?
Это мне напоминает попытку человека выковыривать из числа Пи структуру всей нашей Вселенной. своё имя.

Человек делающий игру на идеальном движке, ваще ничего не должен знать ни о матрицах, ни о скриптах и даже не помнить сколько будет 5х5. Но зато он должен быть сценаристом, постановщиком, режиссером.
Идеальный игровой движок должен как бы ненавязчиво и к месту спрашивать у игора-дерехтора голосом какой-нибудь Алисы: "Чего изволите?" И вот тогда и наступит Платиновый Век Игростроения.  Наконец то, школьники не будут для этого сколачиваться в банды собирать командУ, т.к. эта команда уже изначально будет присутствовать в самом движке, ну, и поэтому новая эктра-пупер парадигма будет называться Нейтрино-Командная Разработка.

+ Показать
kiparУчастникwww24 дек. 201711:54#29
Клапауций
> Это доска с клетками! Шахматы, шашки, в чапая, го, уголки... ну, да, еще много
> чего можно придумать
ну тоже вариант. Но придумывать надо исходя из возможностей компьютера и интересности игры, а не просто "чтоб было". Например, действительно, доску 1000*1000, или еще больше, фигуры по ней ходят сами по просты правилам похожим на шахматные (но больше чем по одной за ход и с ограничением на макс. дистанцию), а игрок управляет движением на более высоком уровне, отрядов и построений. Но это совсем банальный пример, не обязательно в сторону увеличения доски копать.

Virtex
> Это на Прологе, но в данном случае формулы простые, на любом языке можно было
> сделать.
собственно, такой сайт как shadertoy целиком этому посвящен. Там все эффекты рисуются с помощью формулы задающей цвет пиксела (ака фрагментный шейдер). Единственное - на другие пиксели ссылаться нельзя, т.к. все они вычисляются одновременно. Но в твоем примере и нет таких ссылок.

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

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

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