Добавлен , опубликован

Коротко о проекте

Язык разработки: Java.
Используемый движок: JMonkeyEngine 3.
Классификация и камера: сайд-скроллер, 2д-платформер.
Жанр: РПГ с элементами сандбокса и стратегии с непрямым управлением.
Статус: проект опять заморожен.
Начало работ по этому проекту удивительным образом совпало с конкурсом Game Boom #2: Sandbox, так что сама судьба велела быть этому проекту еще и конкурсной работой, но не сложилось - завал на работе привел к тому, что заявка на участие в конкурсе была отозвана, а проект временно заморожен.

Предыстория

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

Геймплей

Играть предстоит одним из упомянутых выше героев, заброшенных шаманом в другой мир.
Что касается РПГ-составляющей, то здесь все как обычно - бегаем, убиваем монстров, ищем клады, качаемся.
Возможно, будут реализованы местные поселения и возможность выполнять генерируемые на лету квесты.
До тех пор, пока не будут реализованы местные квесты, единственным источником каких-либо заданий будет оставшийся на том конце портала шаман, рассматривающий игрока в качестве ресурсодобывающей экспедиции.
Отдельного внимания заслуживает полностью разрушаемый мир и, соответственно, возможность строительства с точностью до отдельного пикселя. Это и есть те самые пресловутые элементы сандбокса - возможность полностью преобразить игровую карту под свой вкус, будь то бездонная яма на пол мира или архитектурный шедевр, проработанный до мельчайших деталей.
Когда надоедает убийство монстров ради убийства и строительство ради строительства, можно отдохнуть и поиграть в самодержца - достаточно найти местных жителей, естественно, если они еще остались в живых, после чего убедить их переселиться на базу к игроку чтобы основать свое собственное небольшое поселение. И пусть все наблюдающие с той стороны удавятся от зависти.
Жителей, естественно, предстоит всячески обхаживать чтобы они не разбежались, размечая им места под строительство и предоставляя материалы, да и обеспечение безопасности поселения на ранних этапах дорогого стоит, не говоря уже о поставках провианта и удовлетворении эстетических потребностей.

Статус разработки

Проект находится на ранней стадии разработки и кроме рабочей демки с бесконечной генерацией пустого мира, рано или поздно выпадающей от переполнения памяти, предъявить мне пока нечего. Возможность попиксельного редактирования мира реализована, но на данный момент используется только при генерации.
upd: Выпадения от нехватки памяти устранены путем реализации выгрузки неиспользуемых фрагментов карты на диск, но этот механизм получился довольно тормознутым и требует оптимизации.
upd: разработка заморожена по причине наличия более перспективного проекта в разработке, после его релиза или провала вернусь к этому проекту.

Скриншоты

Ранние этапы

Первые эффекты постобработки

Полезные ссылки

`
ОЖИДАНИЕ РЕКЛАМЫ...

Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
0
24
10 лет назад
0
nvc123, в описании указано какой движок юзается. Да, действительно, используется 3D движок в режиме ортогональной камеры плюс некоторые другие приемы, помогающие работать с 2D графикой. Одна из основных причин - я не нашел ни одного достаточно гибкого 2д движка, где была бы внятная поддержка шейдеров (думаю не нужно объяснять почему), а мне позарез была нужна возможность выгрузить часть вычислений на GPU.
0
10
10 лет назад
0
prog:
nvc123, в описании указано какой движок юзается. Да, действительно, используется 3D движок в режиме ортогональной камеры плюс некоторые другие приемы, помогающие работать с 2D графикой. Одна из основных причин - я не нашел ни одного достаточно гибкого 2д движка, где была бы внятная поддержка шейдеров (думаю не нужно объяснять почему), а мне позарез была нужна возможность выгрузить часть вычислений на GPU.
Вообще посмотри этот список: lwjgl.org/wiki/index.php?title=Game_Engines_and_Libraries_Using_...
1
24
10 лет назад
1
ZLOI_DED, прошу прощения, но во-первых это был ответ на вопрос другому человеку, а во-вторых я не спрашивал совета по движкам.
Slick, насколько мне известно, не поддерживает необходимые мне функции, а может и поддерживает, но тогда там слишком туго с онлайн документацией.
Libgdx это вообще фреймворк общего назначения для работы с OpenGL и работа с 2д графикой в нем мало отличается от того, как это происходит в JMonkeyEngine, может чуть меньше костылей.
0
10
10 лет назад
Отредактирован ZLOI_DED
0
prog:
ZLOI_DED, прошу прощения, но во-первых это был ответ на вопрос другому человеку, а во-вторых я не спрашивал совета по движкам.
Slick, насколько мне известно, не поддерживает необходимые мне функции, а может и поддерживает, но тогда там слишком туго с онлайн документацией.
Libgdx это вообще фреймворк общего назначения для работы с OpenGL и работа с 2д графикой в нем мало отличается от того, как это происходит в JMonkeyEngine, может чуть меньше костылей.
Я лишь прокомментировал. Или если другой человек спросил, то отвечать на твой ответ может только он? Если так, тогда прошу в ЛС. А здесь по-моему обсуждение проекта.
Хорошо, С другой стороны может ты и прав. Сейчас у jMonkeyEngine 3 преимущество над всеми аналогами. Пусть даже и заточенными под 2D.
Прости, действительно влез, не посмотрев положение вещей. Просто сразу бросилось в глаза то, что пилить 2D игру на 3D движке, особенно на яве, будет затратно для юзера. Хотя... гораздо легче тебе с эффектами будет и с шейдерами, тут ты прав. Думал что есть более заточенные под 2D аналоги на яве то...
На скрине "непонятная фигня" у тебя это камни? Или пни? И если это пни, почему они повёрнуты срезом к нам? :D
0
24
10 лет назад
Отредактирован prog
0
На скрине "непонятная фигня" у тебя это камни? Или пни? И если это пни, почему они повёрнуты срезом к нам? :D
Это просто тестовая текстура для проверки функционала правильной покраски частей поверхности, вставленных со смещением. Если честно, я не знаю что это было изначально, до того как я вырезал этот фрагмент, кажется каменный пол с куском колонны - текстуры то по большей части из числа свободно распространяемых. Кстати, надо будет указать этот момент при следующем обновлении главной.
Что касается заточенных под 2д движков - все дело в том, что у меня довольно специфичные требования за счет того, что поверхность состоит не из тайлов, а из отдельных пикселей, которые потом красятся текстурой и заточенные под работу со спрайтами движки мне здесь мало чем помогут.
0
10
10 лет назад
Отредактирован ZLOI_DED
0
prog:
На скрине "непонятная фигня" у тебя это камни? Или пни? И если это пни, почему они повёрнуты срезом к нам? :D
Это просто тестовая текстура для проверки функционала правильной покраски частей поверхности, вставленных со смещением. Если честно, я не знаю что это было изначально, до того как я вырезал этот фрагмент, кажется каменный пол с куском колонны - текстуры то по большей части из числа свободно распространяемых. Кстати, надо будет указать этот момент при следующем обновлении главной.
Что касается заточенных под 2д движков - все дело в том, что у меня довольно специфичные требования за счет того, что поверхность состоит не из тайлов, а из отдельных пикселей, которые потом красятся текстурой и заточенные под работу со спрайтами движки мне здесь мало чем помогут.
Из пикселей? Т.е. суть технологии как воксели только в 2D?
Ты получается работаешь с LWJGL напрямую или создал кастом меш (квадратик - 2 полигона) и на него мат цвет наносишь и составляешь композицию из них? Или как вообще? Если я угадал, то лучше делать их как можно ниже, чтобы не лагало... А то знавал я ребят, которые пытались воксели из моделей вылепить. Брали блендер, лепили там пирамиду (воксели хотели не кубиками, а пирамидками прям как чайные пакетики :D ) и вставляли в гейм... Вот я ржал-то)))
0
24
10 лет назад
0
ZLOI_DED, общая идея в том, что каждый пиксель задан одним байтом - id матерала, эти данные запекаются в одноканальную текстуру размером 128*128, затем текстура натягивается на простой меш такого-же размера. Соответственно, карта разбивается на фрагменты, каждому из которых соответствует меш с текстурой. Ну и следующим шагом шейдер разбирает пришедшую ему текстуру и по материалу и координатам назначает пикселям цвета из общего атласа.
Меш, естественно, реализован не моделью, а программно. Еще я пробовал всякие извращения вроде того, чтобы задавать каждый пиксель на экране вершиной в модели без полигонов или считать цвета пикселей на CPU - и то и другое довольно болезненно.
Потом пришлось немного усложнить систему, добавив по два байта на пиксель и, соответственно, переключившись на трехканальную текстуру для передачи данных. Эти два байта используются для хранения смещения по текстуре, за счет чего и реализованы те самые "пни", о которых ты спрашивал. В перспективе возможен переход на четырехканальную текстуру и, соответственно, добавление еще одного байта на пиксель, но это уже для красивостей, без которых вполне можно обойтись.
Естественно, сцена клипается по вьюпорту камеры, плюс текстуры для передачи данных реюзаются, а не хранятся постоянно. Ну и находящиеся слишком далеко фрагменты карты нужно выгружать на диск т.к. память не резиновая.
С одноканальной текстурой для передачи данных это вообще самолет, а вот с трехканальной уже тяжелее, хотя тяжелее всего генерация мира, конечно, даже такая простая, как в тестовом варианте.
0
10
10 лет назад
0
prog:
ZLOI_DED, общая идея в том, что каждый пиксель задан одним байтом - id матерала, эти данные запекаются в одноканальную текстуру размером 128*128, затем текстура натягивается на простой меш такого-же размера. Соответственно, карта разбивается на фрагменты, каждому из которых соответствует меш с текстурой. Ну и следующим шагом шейдер разбирает пришедшую ему текстуру и по материалу и координатам назначает пикселям цвета из общего атласа.
Меш, естественно, реализован не моделью, а программно. Еще я пробовал всякие извращения вроде того, чтобы задавать каждый пиксель на экране вершиной в модели без полигонов или считать цвета пикселей на CPU - и то и другое довольно болезненно.
Потом пришлось немного усложнить систему, добавив по два байта на пиксель и, соответственно, переключившись на трехканальную текстуру для передачи данных. Эти два байта используются для хранения смещения по текстуре, за счет чего и реализованы те самые "пни", о которых ты спрашивал. В перспективе возможен переход на четырехканальную текстуру и, соответственно, добавление еще одного байта на пиксель, но это уже для красивостей, без которых вполне можно обойтись.
Естественно, сцена клипается по вьюпорту камеры, плюс текстуры для передачи данных реюзаются, а не хранятся постоянно. Ну и находящиеся слишком далеко фрагменты карты нужно выгружать на диск т.к. память не резиновая.
С одноканальной текстурой для передачи данных это вообще самолет, а вот с трехканальной уже тяжелее, хотя тяжелее всего генерация мира, конечно, даже такая простая, как в тестовом варианте.
Велосипеды...)
У меня есть более простое предложение:
Всё пространство делится на чанки, в каждом из которых n-ное число треугольных полигонов (или квадратиков - 2х полигонов, ибо насколько я знаю в модерн опен гл режим дрова квадратами убрали). Именно полигонов, а не пикселей. С пикселями могут возникнуть проблемы при ресайзе окна и на разных разрешениях, если важен вид. (Хотя я честно немного не понял как это ты привязываешь это дело к пикселям 0_0)
Так вот. Там есть такая тема, называется батчинг. Можно много маленьких мешей в большие перегонять, с общей текстурой. Примерно как в майнкрафте делается. Так вот, делать как обычный воксельный двиг и не париться. Материалы задавать либо текстурами, если полигоны большие, либо, скорее всего в твоём случае - просто цветом, желательно без всяких этих материалов, если можно, а напрямую через LwGJL в VBO закидывать вертексы и цвета.
Надеюсь помог хоть чем-то)
0
24
10 лет назад
0
ZLOI_DED, ты наверно удивишься, но я уже прошел через предложенный тобой велосипед и отбросил его как слишком ресурсоемкий.
Более того, есть более эффективная реализация этого метода, которую я упоминал - процедурно генерируется модель из N*N вершин, где каждая вершина соответствует желаемому пикселю, затем с этой моделью можно работать напрямую через вершинный буфер. Настройки рендеринга для этой геометрии выставляются так, чтобы каждая вершина отрисовывалась как точка. И последний штрих - применяется 2д-проекция, которая в обычных условиях используется для GUI, превращающая 1 единицу расстояния на сцене в 1 пиксель.
Получаем поверхность, цвет которой мы можем редактировать напрямую. Получается довольно неплохо, если не считать того, что перекраска каждой вершины ложится полностью на CPU. Хуже всего, что при желании покрасить такую поверхность текстурой, текстуру придется парсить на CPU попиксельно, после чего повершинно применять цвет к вершине. Такие затраты CPU позволительны когда вся поверхность может быть загружена в память, а изменения поверхности происходят довольно редко, но когда речь идет о бесконечной карте, которая загружается и выгружается по мере необходимости, начинается настоящий ад.
0
37
10 лет назад
0
prog, порадуй нас новыми ресурсами - только со скринами. Если будет норм выглядеть - добавим на главную.
0
24
10 лет назад
0
Эльрат, завал на работе он такой - вечно возникает в самый неподходящий момент. По плану у меня уже должна была быть готова базовая генерация мира, нормальный чанк-менеджмент, выгрузка карты на диск, кисти для редактирования мира, один игровой персонаж и физика столкновений. Вот когда будет работать хотя бы это - будут и скриншоты.
Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.