Дневник разработки - "Ice & Flora" (Hale_32bit)

Уже пора бы выложить свой проэкт. Но я не успеваю как и все, просто я делаю вид что у меня всё хорошо. Вот например я смирился с тем что в игре не будет никаких звуков.

К сегодняшнему дню сделал графику для игры, катинки всех уровней (всего их 5), таблицу рекордов.

На завтра осталась работа по настройке уровней, тэстированию и баллансировке, а также улучшение графического интерфейса и хэлп.

[img_assist|nid=910|title=Графика в игре|desc=|link=popup|align=left|width=100|height=72]

[img_assist|nid=911|title=Таблица рекордов|desc=|link=popup|align=left|width=100|height=74]

Последняя правка: пт, 28/01/2011 - 22:18
Submitted by Hale_32bit on

Комментарии

Первый день конкурса.

Итак я ввязался в эту авантюру под влиянием мимолётной идеи. Идея заключается в том, чтобы сделать арканоид в котором разрушения происходят по типу как в Worms2D. Вторая фича - это слой льда постоянно намерзающий на поверхностях. Т.е. чтобы отколоть кусочек нужно сначала разбить лёд, а потом непосредственно твердь (пока новый лёд не намёрз). Я не люблю придумывать название игры заранее т.к. считаю, что должно быть имя сформированное(заслуженное) игрой, а не игра сформированная именем. Но того требовали правила регистрации. И когда я перебирал варианты то, наткнувшись на пафосное "Ice & Flora", понял, что круче я придумать уже не смогу. Причём тут Flora? Незнаю, но надеюсь я смогу придумать куда её привинтить. Похоже я сам себя загнал в ловушку с этой флорой и вообще выбрав жанр, в котором, если и дашь что-то оригинальное, всё равно игра будет скучной и однообразной. Игроку всегда нелегко долбиться в ближние преграды, а потом забросить мячик высоко и скучать, ждать когда же он упадёт. Всётки у меня появилось несколько идей как можно выкарабкаться из этой ямы, пока не буду их оглашать.

Разрабатываю на XNA 4.0. Начну с интерфейса, меню, а потом графический вывод игровых объектов.

Submitted by Hale_32bit on

С удовольствия поиграю в игру темболее на XNA

Submitted by EXpert on

Третий день конкурса.

За эти три дня сделал:

1) Меню

2) Простенькую визуализацию объектов.

3) Написал шэйдер который рисует в текстуру границу изображения (это понадобиться для того чтобы намораживать лёд на границу, к тому же надеюсь поможет с попиксельной коллизией, когда буду её реализовывать).

4) Загруку конфигурации уровней из XML файла. (В принципе можно будет полностью редактировать уровни если вы умеете сохранять изображения в формате xnb)

5) Начал делать физику. Сделал столкновения мячика со стенками.

Submitted by Hale_32bit on

Четвёртый день.

Потратил кучу времени на реализацию попиксельной коллизии. В итоге сделал.Теперь прдстоит возможно самая сложная часть. Нужно реализовать разрушения. Если Вы играли в Worms то наверное помните зависающие в воздухе кусочки уровня размером в несколько пикселей, оставшиеся после разрушений. Думаю в арканойде такая проблема встаёт более остро т.к. разрушить нужно всё. Даже в обычном арканойде бывает сложно попасть в последний кирпичек, а что говорить про последний пиксель :)

И так я собираюсь создать такую систему разрушений, которая бы подбирала размер размер и форму отдельных разрушений таким образом чтобы не оставалось слишком маленьких частей.

[img_assist|nid=828|title=Ice&Flora первый скрин|desc=На изображении можно видеть кнопку "Exit", фиолетовый мячик, зелёную биту, жёлтое бесформенное пятно которое играет роль разрушаемго объекта арканойда.|link=popup|align=left|width=100|height=60]

Графики у меня особо нет. Может и не будет т.к. я не из тех программистов, которые учатся рисовать и таким образом становятся универсальными проффессионалами. Я считаю, что нужно быть мастером в чём то одном(или нескольких) во всяком случае не в том что мне не нравиться делать. А рисовать и моделить мне не нравиться. А игры они должны быть хорошими и без графики (взять хотя бы "Dwarf Fortress").

На данном скрине нет ничего особенного. Я его загрузил, чтобы не отставать от других участников :)

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

Submitted by Hale_32bit on

День пятый.

Сделал разрушения.

[img_assist|nid=833|title=Разрушения 1|desc=|link=popup|align=left|width=100|height=68]

Покачто без того о чём я говорил.

Submitted by Hale_32bit on

Классный прогресс. А как реализован отскок шарика? Зеркально относительно касательных, или относительно вертикалей/горизонталей?

Submitted by Nikron on
Всмысле отскок шарика от биты?

Пока просто зеркально. Думаю как вариант сделать возможность крутить биту таким образом меняя угол отклонения так буде более спортивно Smile но возможно получится неиграбельно

Submitted by Hale_32bit on

Я имел ввиду отскок ото льда. Его поверхность ведь неровная. И скользкая, наверное)

Submitted by Nikron on

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

И кстати это не лёд - это тип земля. А лёд по задумке будет со временем намерзать тонким слоем на поверхности земли.

И кстати если говорить о реальной физике то закон равенства угла падения и угла отражения хорошо соблюдается именно когда мяч отскакивает от скользкой поверхности чем от шероховатой.

Submitted by Hale_32bit on

А просто выгнутую платформу Вы не рассматриваете?) И кстати имхо очень круто смотрелся бы бонус, когда шарик, объятый пламенем пробивает всю эту (не знаю как назвать Lol штуку насквозь xD

Submitted by Mad Rabbit on

Выгнутую платформу тоже рассматриваю. И бонус пробивания насквозь тоже. Я рассматриваю много чего. Т.е. я вообще ещё ничего не решил и решаю по ходу дела.

Submitted by Hale_32bit on

День шестой.

Я сделал таки систему разрушения которая не допускает маленьких огрызков.

Расскажу как она работает.

1) рассматривается небольшая область карты вокруг точки коллизии.

2) все точки карты, достижимые из точки коллизии по непрозрачным точкам карты, помечаются как "достижимые" (алгоритм поиска в глубину)

3) Все точки карты, не попадющие в большой круг радиуса R с центром в точке коллизии, помечаются как "часть чего-то б'ольшего"

4) Все точки, достижимые из точек "часть чего-то б'ольшего" по пути из непрозрачных точек, не находящихся в маленьком круге радиуса r с центром в точке коллизии, тоже помечаются как "часть чего-то б'ольшего".

ПОСЛЕДНИЙ ПУНКТ ОБЪЯСНЯЕТ ВСЁ:

5)Прозрачными становятся все "достижимые" точки в малом круге, а также не находящиеся в малом круге, но находящиеся в большом "достижимые" и не "являющиеся частью чего-то б'ольшего" точки.

Иными словами разрушаются все достижимые точки в малом круге, а точки в большом круге анализируются и принимается решение о том захватить некоторые из них или нет. Подбирая радиус большого круга, получаем разные размеры минимального огрызка. Когда R = r минимальный огрызок - один пиксель. Но даже если поставить большой охват данный алгоритм может оставлять очень тонкие но вытянутые в длинну огрызки.

К тому же я решил ещё одну проблемму: разрушение не связных пикселей. Если вспомнить Worms то там всегда просто уничтожались все пиксели в некотором круге порой задевая одновременно два объекта никак не прикасающихся друг к другу, что не всегда было к месту.

Раз уж у меня происходит такой сложный анализ при каждом столкновении то несложно в него добавить также проверку на материалы. Например неразрушаемые пиксели и пиксели разрушаемые определённым типом мячика и пиксели перекрашиваемые после первого удара но разрушаемые после второго. Возможно этим я и займусь далее. Smile

Я сделал чтобы не было мелких огрызков и не могу выложить об этом скрин. Я ведь не могу показывать то чего нет :)

Поэтому я решил выложить пару красивых скринов процесса отладки.

[img_assist|nid=834|title=Отладка|desc=Я наглядности я подсвечивал красным проанализированные пиксели из большого круга.|link=popup|align=left|width=100|height=70]

[img_assist|nid=835|title=Отладка 2|desc=Это карта границ, о которой я говорил ранее.|link=popup|align=left|width=100|height=67]

Submitted by Hale_32bit on

День седьмой.

Сегодня ко мне в гости приезжала двоюродная сестра. Ей пять лет, она кричала и требовала внимания, поэтому несмотря на выходной я не смог нормально поработать. Только вечером накидал черновую систему намерзания льда и осознал проблемы:

Во-первых легко сделать намерзание корки льда толщиной в один пиксель и концептуально этого достаточно, но его трудно увидеть на экране. Нужно как-то размазывать его, использовать одну-две дополнительные промежуточные текстуры, и или пиксельный эффект в реальном времени. Кстати я не уверен, но действительно ли пиксельный шэйдер должен требовать много или просто у меня не поддерживается аппаратное ускорение? Почему-то если я выделяю границу картинки в реальном времени у меня FPS падает с 60ти до 40. А что уж говорить о размытии. Кто разбирается в этом ответе пожалуйста.

Во-вторых нужно придумать как лёд будет появляться. Мгновенное появление не пойдёт. Сначала появляется точка льда и потом распространяется по участку поверхности. Или лёд возникает сразу на всём участке, выходя из прозрачного состояния. Оба способа проблемные возможно придумаю что-нибудь другое.

В-третьих система разрушения должна быть адаптированна таким образом чтобы не оставлять в висячие в воздухе корки льда.
Submitted by Hale_32bit on
Quote:
Hale_32bit писал(а):
Кстати я не уверен, но действительно ли пиксельный шэйдер должен требовать много или просто у меня не поддерживается аппаратное ускорение? Почему-то если я выделяю границу картинки в реальном времени у меня FPS падает с 60ти до 40. А что уж говорить о размытии. Кто разбирается в этом ответе пожалуйста.
Я думаю, что твоя видео карта на данный момент как минимум поддерживает аппаратное ускорение пик.шейдеров версии 2 это точно (вобще, если используешь DX, то жто можно в капасах запросить у устройства). Что конкретно делаешь, так и не понял, так что просидания в 20 фпс твои могу пока только объяснить сложным алгоритмом и совсем не оптимизированным.
Submitted by MaxImuS on

Алгоритм простой

если данный пиксель прозрачный то

проверяются 8 соседних пикселей и если среди них есть непрозрачный

то данный пиксель будет белый

иначе чёрный.

Submitted by Hale_32bit on

Я конечно ничего не понимаю в шейдерах, но по-моему здесь дохрена проверок. Посчитай, сколько у тебя прозрачных пикселей и домножь на 8 (да, я кэп Smile )

Submitted by Nort on
Да для процессора это много. Но шэйдеры выполняютсяна видеокартой, а там архитектура векторная и хорошо распараллеленная.

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

Submitted by Hale_32bit on
Quote:
Hale_32bit писал(а):
Поэтому то мне и кажется, что у меня что-то не ускоряется.
Так может ты и выбрал software режим Smile проверь в настройках устройства своего проекта.
Submitted by MaxImuS on
Quote:
Hale_32bit писал(а):
Короче я не знаю сам насколько это тяжело. Но знаю, что есть подобные эффекты например блюр, антиаллиасинг, анизатропная фильрация и.т.п. которые намного тяжелее и при этом выполняются в реальном времени.
Подобные эффекты быстрее, потому что под них заточена аппаратура видеокарты, ибо достаточно часто используемые вещы.

ИМХО, использовать для подобных вещей шейдеры это конечно круто, но не думаю что оправдано.

Submitted by Otinagi on
Выделение границы с помощью шэйдера - это оправданно потому как написать более оптимальный алгоритм пожалуй невозможно, в любом случае нужно пробегать по пикселям и проверять соседей. А уж GPU с такой задачей справиться быстрее.

Пока у меня нет нужды применять этот шэйдер в реальном времени я обновляю карту границ только когда происходит разрушение. В такие моменты FPS падает с 61 до 59.

Submitted by Hale_32bit on

Хм. Сейчас снова пробовал в реальном времени. и снова было падение FPS на 20. Но когда я попробовал изменить количество проверяемых соседей с восьми на четырёх падение FPS стало 0-2. Может это связанно с ограничением на колличество инструкций?

Submitted by Hale_32bit on
Quote:
Hale_32bit писал(а):
Графики у меня особо нет. Может и не будет т.к. я не из тех программистов, которые учатся рисовать и таким образом становятся универсальными проффессионалами. Я считаю, что нужно быть мастером в чём то одном(или нескольких) во всяком случае не в том что мне не нравиться делать. А рисовать и моделить мне не нравиться. А игры они должны быть хорошими и без графики.
Как мне кажется все таки разукрасить игру надо, хотя бы в стиле Wormux или Hedgewars, где есть красивый задник, передник который представляет из себя поле битвы(в вашем случае это желтую массу) и частицы (снег, дождь, листья).

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

P.S.

Один из моих знакомых болеет за Вас Smile

Submitted by noTformaT on
Спасибо.

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

Я не знаю насколько я впереди, но мне кажеться, что я не успеваю. Я уже больше года увлекаюсь геймдэйвом, но до сих пор не смог закончить ни одной игры. Прошлой зимой я учавствовал в одном конкурсе. собралось пять-шесть участников но в итоге я один ПОЧТИ закончил игру, а остальные заглохли и конкурс заглох. Здесь конечно конкурс помощнее стартовал. Я надеюсь новички смогут довести свои проэкты до конца. Ну и себе желаю того же ведь я сам ещё новичок :)

Кстати в январе сессия, поэтому нужно сделать большую часть в декабре.

Submitted by Hale_32bit on
Quote:
Hale_32bit писал(а):
Кстати в январе сессия, поэтому нужно сделать большую часть в декабре.
Год в геймдеве во всяком случае больше чем мои 2 месяца Smile

Сесия жесть, у меня в начале декабря сесия, а мне еще надо написать транслятор ассемблера Sad

Submitted by noTformaT on

День восьмой.

Пытаюсь сделать визуализацию льда. Как я уже говорил оригинальный лёд имеет толщину один пиксель. Чтобы сделать его хоть чуть-чуть видимым я наращиваю его при помощи шэйдера. Сначала один проход в промежуточную текстуру, а потом ещё один в финальную текстуру а потом вывод финальной текстуры на экран. Получаться неплохо, но на высоком разрешении всё равно мелковато к тому же мне приходиться жертвовать FPS, которая теперь ~58.

Только что меня осенила гениальная мысль! Почему бы не использовать для визуализации льда текстуры с более крупными пикселями.

Submitted by Hale_32bit on
Вот меня интересует вопрос: насколько сильно вышку можно использовать в шейдерах?

(она в таких случаях http://pluspi.org/wiki/index.php/Задача_Кузнецов_Аналитическая_геометрия_13-25 меня очень радует Smile )

Submitted by Nort on
Не думаю, что можно научить шэйдер работать аналитическ4и как MatLab или Maple :)Но вообще-то это сегодня модно выполнять математические рассчёты с помощью шэйдеров. Слышал что бывает игровая физика на шэйдерах.

Я и сам начал данный проэкт с идеей использовать шэйдеры не для вывода графики.

Короче не знаю какая вышка нужна, но в HLSL доступны разные функции типа cos, arccos...

Смотри Википедия

Submitted by Hale_32bit on
Quote:
Hale_32bit писал(а):
Хм. Сейчас снова пробовал в реальном времени. и снова было падение FPS на 20. Но когда я попробовал изменить количество проверяемых соседей с восьми на четырёх падение FPS стало 0-2. Может это связанно с ограничением на колличество инструкций?
Я не большой специалист в шейдерах, но предполагаю, что там тоже есть свои грабли с такими вещами как кэш-промахи, предсказатели перехода в ветвлениях и т.д.
Submitted by Victor on
Quote:
Hale_32bit писал(а):
Не думаю, что можно научить шэйдер работать аналитическ4и как MatLab или Maple. Но вообще-то это сегодня модно выполнять математические рассчёты с помощью шэйдеров.
Для реализации математических алгоритмов и прочих расчетов на шейдерах не связанных на прямую с графикой, я бы все таки рекомендовал использовать более специализированные врайперы над ними - хотя бы тот же OpenCL.
Submitted by Victor on
Quote:
Victor писал(а):
Quote:
Hale_32bit писал(а):
Хм. Сейчас снова пробовал в реальном времени. и снова было падение FPS на 20. Но когда я попробовал изменить количество проверяемых соседей с восьми на четырёх падение FPS стало 0-2. Может это связанно с ограничением на колличество инструкций?
Я не большой специалист в шейдерах, но предполагаю, что там тоже есть свои грабли с такими вещами как кэш-промахи, предсказатели перехода в ветвлениях и т.д.
Мне надавно рассказали, что всегда выполняются обе ветви условия а потом применяется та, которая удовлетворяет условию. Так что алгоритм предсказания тут не причём.

Я тут написал ещё один подобный шэйдер который обходит соседей. Так вот оптимальным оказалось 9 соседей (цикл 9 иттераций) если больше или меньше то FPS резко падает. Короче очень странная архитектура. Wacko

Submitted by Hale_32bit on

GameDev.by