RoboGame Blog

2009-08-09T11:18:00.000-07:00

Т.к. этот блог всё равно никто не читает, больше кросс-постить сюда я не буду. Будущий ход разработки будет описываться только здесь

http://www.gamedev.ru/community/robo_game_blog/

Demo04

2009-08-08T03:56:00.001-07:00

Программирование и арт: XIRMAC
Наброски звука для демки: Евгений Ярмош (TCVMusic@gmail.сom)
Саундтрек: PitchShifter – «Genius”
Ссылка: http://www.anegmetex.com/RoboDev/RobogeddonDemo04.rar (18 Мб)

Для запуска требуются установленные дрова физикса не менее 2.7.2 версии.
Убедится в его наличии можно проверив существование папки C:\Program Files\AGEIA Technologies\v2.7.2

Управление:
WASD - перемещение
Mышь – наведение и стрельба
ENTER – добавить ещё врага

Основные настройки которые можно поменять в Settings.xml:
ScreenX и ScreenY – разрешение экрана FullScreen – использовать ли полный экран
GetUserRes – получить разрешение экрана. ScreenX и ScreenY игнорируются.
RobotsOnArena – сколько одновременно роботов находится на уровне.
PlayerLife – сколько жизней у игрока. Влияет на сложность игры.
MusicVol – громкость музыки. Если 0 – отключить совсем музыку.

Ожидаемая обратная связь:
- запускаемость
- вашу конфигурацию и фпс (+ желательно разрешение экрана и кол-во заспавненых роботов).
- баги\глюки

опционально:
- Критика
- Слова поддержки
- Плевки
- Тухлые помидоры
- Караваны

скрины:

youtube:

Доработанная модель босса

2009-08-04T09:24:00.001-07:00

Вообщем, я решил что действительно както низ с верхом не стыкуется, поэтому сделал из этих заготовок два робота :)
Фиолетовыми формами показанно место будущих шасси )

Вот это старый няшка но уже с нормальной большой базой:

А вот это его маленький колёсный друг :)

В целом в каждом из них сейчас около 2500 треугольников.. следовательно с оружием и финальными шасси будет не больше 4000-4500 что вообщем то соответствует плану.

Боевая система, скрипты, бонусы

2009-07-27T13:41:00.000-07:00

Вообщем, мои немногочисленные читатели, работа над проектом всё ж таки идёт :)
За последнее время я прикрутил к игре скрипт-движок на lua, доработал боевую систему: теперь роботы стреляют реально разными оружиями с разными параметрами и эффектами, а не как было до этого… :)

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

Насчёт внешнего вида бонусов: я сначала хотел их сделать объектами… но потом подумал что они будут теряться в куче ошмётков от роботов и плохо читаться среди прочего хлама, поэтому сделал эдакие олд-скулл стайл бонусы :) Если сильно народ их ругать не будет, то думаю такие и оставлю.

Боевая система: первое подобие геймплея

2009-07-12T02:19:00.000-07:00

Работаю над боевой системой роботов. Собственно на ниже приводимом видео можно увидеть некоторое подобие геймплея: вражеские роботы обруливают препятствия, перемещаются по action points и ведут огонь по игроку. При записи видео был включён режим бессмертия ибо без него игрока уж очень быстро зарубают :)

Сейчас геймплей вырисовывается уж очень какой-то зверски-хардкорный чтоли 8) Надо будет ещё работать над балансом параметров оружия, поведением роботов и тому подобное… а вообще всё выглядит довольно не плохо, думаю в конечном счёте неплохая игруля должна получиться :)

Модель одного из боссов

2009-07-08T03:58:00.000-07:00

Вот на днях наваял ещё одного робота (не на ходу он пока правда). По идее будет одним из боссов. Вообще по концепту был более брутальным чем получился.. даже решётка радиатора выглядит не как оскал а как милая улыбка )))
А вот нижняя часть получилась как то мелковато по сравнению с верхней массивной башней. Возможно стоит нижнюю базу заменить на другую...

Поиск пути

2009-07-05T03:06:00.000-07:00

Приделал к редактору генератор карты препятствий, а к самой игре – поиск пути по ней. Собственно реализовано это было как и задумывалось – карта строится в редакторе по специальным лимитерам. Которые кстати можно сгенерировать по AABB выделенных статичных объектов (что несомненно удобно и сохраняет дофига времени).

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

Ещё одна очень не приятная проблема, которая уже давно нарисовалась в проекте – это роботы сталкивающиеся с другими роботами при движении. Собственно можно конечно попробовать приделать какое-то динамическое обруливание по AABB (я уже что-то подобное пытался реализовать в игре Technozes), но мне кажется всё это кардинально не решит проблему :(

Скринцы нового дизайна свалки

2009-06-26T12:21:00.000-07:00

Провёл некоторый редизайн свалки. Предыдущий вариант мне показался какимто тёмным и фактура свалки совсем не читалась. Надеюсь сейчас стало гораздо лучше :)

Лимитеры

2009-06-22T08:28:00.000-07:00

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

Кстати если у лимитера стоит только этот флаг – то он грузится только в редакторе, а в самой игре просто не добавляется (что вполне логично, т.к. карта препятствий обсчитывается заранее в редакторе, а в самой игре лимитер только с этим флагом не будет никак воздействовать на геймплей).

Да я решил идти проверенным путём и использовать старый добрый алгоритм А* а не пути или навмеш. Ибо для двух последних очень не очевидно как быстро рассчитывать в каком поинте\треугольнике находится бот, при его смещении например взрывом или при таране другим ботом.

Собсна в редакторе они выглядят пока вот так (цветом показываются разные установленные флаги):

Работа ссылок и картинок востановлена

2009-06-06T05:54:00.001-07:00

Всё, наконец-то переехал на новый хостинг. Теперь все ссылки снова будут работать, а картинки - отображаться :)

Набросок кусочка уровня "Junkyard"

2009-05-23T02:31:00.000-07:00

На днях решил проверить на что способен мой редактор. Закинул в движок несколько моделей и собрал из них небольшой участок уровня "Свалка". Ниже можно увидеть пару видео с результата. Собственно этот прототип позволил выделить несколько проблем:
1) Робот часто задевает углы и спотыкается о неровности пола. С этим придётся чтото делать, т.к. раздражает ужасно.
2) Необходимо ввести в движок дополнительную физ геометрию, которая будет реагировать только на игрока и врагов. Ей нужно будет обтягивать все участки с которых игрок может упасть в пропасть, а также участки куда по идее игрок заезжать не должен.
3) поиск пути для роботов скорее всего надо будeт делать с помощью Paths а не AStar. Это позволит ввести более интеллектуальных врагов по средством добавление дополнительной информации о уровне в Path Points.

Видео с геймплея движка:

Видео с редактора уровней:

К сожалению показать физ геометрию уровня получилось плохо (из-за низкого разрешения видео), поэтому покажу отдельным скриншотом:

Сериализация мира

2009-05-21T04:51:00.000-07:00

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

Вообщем поставил я бинарный доступ - и сразу всё заработало как надо.

Такие дела, господа. Не делайте глупых ошибок :)

Модели: тайлы уровней

2009-05-13T03:29:00.000-07:00

Мир в игре будет тайловый. Т.е. собираться из отдельных мелких (и не очень) объектов в редакторе. Плюсов из этого подхода довольно таки много – большое разнообразие уровней, большая детализация. Также считаю огромным плюсом возможность управлять детализацией – в зависимости от настроек не загружать объекты, помеченные как «только для высокой детализации» (ну например дополнительный мусор, второстепенные элементы уровня и т.д.). Минусы конечно тоже есть- большее количество DIP. Но учитывая наклон камеры и деферред шейдинг я не думаю что это будет сильно влиять на производительность )

Ещё конечно придётся сделать в редакторе функции выравнивания объектов, подгонки друг к другу и убирания зазоров между ними, иначе зашьёшься выравнивать всё в ручную…

Начал работать над тайлами первых уровней – «катакомбы» и «район старой свалки».

Довольно долго подбирал тектуру поверхностей свалки, такую, чтобы на ней не терялись активные объекты. Вроде не плохо смотрится:

Подводные камни физикса

2009-04-23T04:16:00.000-07:00

Занимаюсь своим редактором. Реализовываю перемещение и поворот объектов. Перемещение работает отлично а вот поворот начал давать на статических объектах интересный глюк – после большого количества поворотов шейпы статического объекта начали не совпадать с их матрицей поворота (та что возвращается функцией getGlobalOrientation).

Вот в исходном состоянии (оранжевыми линиями показано положение физической оболочки):

А вот после большого количества поворотов:

Что примечательно – при единичных поворотах – всё нормально. При простом перемещении такого глюка вообще замечено не было. Сначала я думал что это из-за накоплении ошибки в матрице - ортонормировал её, но проблема не исчезала… тем более было странно что на динамических объектах такого глюка не возникало! Начал курить доки и вот что я заметил:

Вы видите маленькое неприметное слово «dynamic»? Вот и я его заметил только после шестой зачитки документации. Начал гуглить проблему – оказывается у многих такие глюки замечены – на официальном сайте нвидии заметил 3 подобные темы. К слову которые остались без ответа. Вообщем после на официальном сайте нашёл мелким шрифтом надпись в FAQ что статические объекты НЕЛЬЗЯ двигать после их создания, т.к. они там очень хитро оптимизируются и при их передвижении придётся много чего перерасчитывать.
Решение проблемы было простое – при создании NxActor в редакторе все статические объекты создаются как динамические с флагом NX_BF_KINEMATIC. После этого глюки волшебном образом исчезли! Объекты можно вертеть сколько хочешь и они не рассинхронизируются со своими физическими оболочками :)

А теперь несколько риторических вопросов:

Почему в документации нет никаких Warling! крупным красным шрифтом насчёт всего этого?
Почему вообще библиотека физикса позволяет мне двигать и вращать статические объекты если это приводит к глюкам? Сэкономили на одной проверке if-ом?
Почему мне не дают возможности «перерасчитывать чегото там» или отключать всю эту оптимизацию статических объектов по моему желанию? Ведь передвижение статических объектов в редакторе уровня – думаю обычная и часто встречающаяся задача.

Редактор уровней

2009-04-19T14:24:00.000-07:00

Пару недель назад начал неспешно работать над редактором уровней. Вспоминая редакторы от прошлых моих игр, я твёрдо решил, что в этот раз он будет более-менее адекватным и по стилю управления\редактирования объектами будет похож на обычный 3d редактор (читай – 3д макс).

В былые то годы, мои тулузы для клепания уровней отличались замысловатым функционалом, причудливыми Ынженерными решениями типа 3d курсора и убийственным количеством горячих клавиш. Но даже в них я умудрялся как то клепать вполне сносные уровни ))

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

Что же касается интерфейса редактора – то тут я сохраняю трогательную верность традициям. Схема интерфейса «Вьюпорт-главнаяПанель-инфоПанели» выработанная на редакторе от Scary Nightmare показала себя в боевых условиях весьма не плохо, поэтому я решил её кардинально не менять.

Выкладываю ниже скрины трёх редакторов, расположенные в хронологическом порядке, эволюция так сказать… сложно сейчас поверить, но редактор для Technozes целиком обходился только горячими клавишами :)

Technozes (2007):

Scary Nightmare (2008):

Robogeddon (2009):

Патч для Демки03. Добавление звука

2009-04-02T15:56:00.000-07:00

Патч для добавления звуков: http://www.anegmetex.com/RoboDev/Demo03_SoundPatch.rar (1.8 Мб)

Ставить поверх демки с заменой файлов.

Отпишите пожалуйста работает ли у вас нормально звук.

Если самой демки03 у вас нет, то вот ссылка: http://www.anegmetex.com/RoboDev/Demo03.rar (14.8 Мб)

Превьюшка на youtube:

Звуковой модуль. Девять кругов ада.

2009-04-01T14:41:00.001-07:00

Собственно две последних недели были потрачены не зря. За это время я пришил к движку поддержку звука на основе библиотечки Audiere. И скажу я вам это было весьма не лёгким занятием :) Траблов было не много, а очень много.

Ну для начала после приделывания звуковых эффектов приложения начало самопроизвольно падать во внутренней audiere.dll. Разматывая стек в дебаг-режиме я обнаружил что эти падения связаны с тем, что звуковой буфер самостоятельно может приравняться к NULL. От чего это происходит – понять так и не удалось, проблему же решил просто – при обнаружении NULL звуковой буфер перебиндивается к нужному sound source, тем самым восстанавливая указатель.

Далее я случайно заметил что память у меня подтекает. И сурово так – 1-2 метра на 10 свежедобавленных роботов. Начал гуглить проблему – конечно весь интернет был усеян об течках памяти в аудиере. Решения проблемы не было. И вот когда я уже начал подумывать об смене саунд-движка – я наткнулся на одинокий пост на каком то буржуйском форуме, где какойто умелец пересобрал dll аудиера и вроде как пофиксел проблему с утечками. Я конечно её сразу скачал и начал тестировать – и, о чудо! Эти кошмарные утечки действительно прекратились :)

Но это было только начало мучений. Потом я начал прикручивать Sounds Streams – это новая сущность моего движка, позволяющие эмулировать 3d звук с помощью изменения Volume, Pan и Pitch (сам audiere 3д звук не умеет). Особенность их в том что они ПОСТОЯННО должны менять pitch. И вот тут началась жесть :)

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

Вообщем что в итоге за эти две недели:
1) Прикрутил поддержку как управляемых звуков (Sound Streams) так и нет (Sound Effects). Различие между ними в том, что стримы можно контролировать на всём протяжении их работы, а на эффекты после их запуска уже повлиять никак нельзя. Вот такой оптимизейшн.
2) Сделал самопальную поддержку 3D звука.
3) Сделал наконец то Collision Report физики с поддержкой проталкивания информации по всех иерархии объектов от agePhysicsObject до высокоуровневых ageDynObject и ageActor. Это всё надо для того что когда например бочка падает – проигрывался звук падения бочки )
4) Сделал архиудобную систему загрузки и проигрывания звуков - Sound Mapper. (правда надо её будет помониторить в VTunes на предмет оверхеда производительности… но на глаз с фпс пока всё вроде в полном порядке, никаких проседаний не замечено)

Вообще надо сказать API у Audiere весьма приятный. Если бы он не был таким удобным я бы уже на середине своих страданий забил бы на него :)

Видео же со звуком пока НЕ будет. На днях выпущу звуковой патч для демки03, тогда и видео выложу.

Offtopic
В последнее время стал замечать, что во время отладки игры, я пока не завалю 3-4 волны роботов не отключаю игру, хотя это и не требовалось для отладки фичи… странно, к чему бы это…

Demo03. Разрушение роботов.

2009-03-22T14:16:00.000-07:00

Ну вот. Вроде подшлифовал я систему повреждений, жизни объектов и снаряды. Теперь можна нормально кромсать роботов :)

АИ правда пока нет. Займусь им в скором времени. А пока – только жестокое убийство невинных роботов )

Ссылка: http://www.anegmetex.com/RoboDev/Demo03.rar (14.8 Мб)

Для запуска требуются установленные дрова физикса не менее 2.7.2 версии.
Убедится в его наличии можно проверив существование папки C:\Program Files\AGEIA Technologies\v2.7.2
Управление:
WASD - перемещение
Mышь – наведение и стрельба
ENTER – добавить ещё 5 врагов

Ожидаемая обратная связь:
- запускаемость
- вашу конфигурацию и фпс (+ желательно разрешение экрана и кол-во заспавненых роботов).
- баги\глюки

опционально:
- Критика
- Слова поддержки
- Плевки
- Тухлые помидоры
- Караваны

скрин:

youtube:

Православный редактор объектов, созданный всего за 3 часа

2009-03-17T12:35:00.000-07:00

Инди-разработка требует креативных решений. У меня нет времени и сил изобретать велосипеды и делать всё так, как принято в индустрии. Поэтому часто приходится выкручиваться :)
Вот взять например редактор объектов. Нужен ли он? В проекте сложней крестиков-ноликов – обязательно. В слепую править сотни параметров, потом грузить игру и смотреть что получилось – это не достойно настоящих джедаев. Однако при ближайшем рассмотрении его создание должно было бы затянутся на месяцы: ведь в нём будет куча диалогов, в них дофига контролов, связанных с параметрами объектов. И это всё богатство придётся держать в актуальном состоянии на всём протяжении разработки! Ведь создаётся он не под готовый движок, и новые параметры у объектов будут появляться с завидной регулярностью.

Ясно дело что такой путь не для меня, разработчика-одиночки. А теперь давайте подумаем: а что собственно требуется от движка игры? Правильно, только отображать изменения в реальном времени. А теперь внимание вопрос: “Накой фиг нам создавать тучи диалогов с параметрами если все данные в игре лежат в православном формате XML и править его очень удобно с помощью программы XMLNotepad??”. Вот тут то ко мне пришла конгениальная мысль – пусть мы будем править все данные в удобном редакторе
XMLNotepad, а наша программка пусть отслеживает все изменения ресурсов для редактируемого объекта и если время изменения файла поменялась – перегрузить изменённые ресурсы. Достаточно просто сохранить файл (нажать CTRL+S), и результат изменений сразу отобразится во вьюпорте!

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

Вообщем этот метод даёт огромный функционал инди-разработчику, требуя затратить минимум времени для его реализации.

Вот полноразмерное видео такого редактора (20mb в разрешении 1680x1050):
http://depositfiles.com/files/6qz6z31gf

Превьюшка на youtube:

Новые модели

2009-03-15T17:42:00.000-07:00

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

Вот некоторые из новых моделек:

Некий усилитель… странные сарайчики с трубами и электричеством

Вагон для перевозки мусора для локации «свалка»

Погрузчик мусора для локации «свалка»

Геймплей: боевая система

2009-03-11T11:47:00.000-07:00

Насчёт геймплейной стороны битв пока ещё не очень ясно, но я провожу тесты, смотрю как лучше сделать. Очень часто то что хорошо выглядит на бумаге в реале вообще получается шлаком… и наоборот. Вообщем работа идёт ;-)

Вот заснял расправу над роботами:

Патч для Демки02

2009-03-01T15:35:00.001-08:00

Скачайте патч(~500 kb): http://www.anegmetex.com/RoboDev/Demo02_Patch.rar

Исправлено (вроде как):

- нестабильность подвески при низких ФПС

- вылет асcерта с agePointerArray

- вылет при зажатом CTRL (PhysXCore.dll Access violation)

- задний ход прикручен снова

Добавлено:

- постоянное слежение за роботом (ака CTRL). Поставте в настройках единицу у параметра CameraTracking. Если будет сильно трясти камеру можно ещё поставить единицу у параметра CameraPosInterpolation

- Можна нажать на пробел и поджечь всех роботов 8-)

Демка 02. Наведение, огонь и движение роботов по вейпоинтам

2009-02-28T06:24:00.000-08:00

Всем привет! Вот и добрался я до второй демки. Хотелось бы от вас услышать следующий фидбек:

- запускаемость

- вашу конфигурацию и фпс (+ разрешение экрана на котором запускалось).

- удобство управления роботом (оно было существенно переработано с прошлой демы)

- удобство прицеливания по движущимся роботам (чтобы боты начали двигаться жмите M)

- устойчивость роботов. Они не должны переворачиваться. Я провёл дофига времени добиваясь того, чтобы роботы в любом случае вставали на колёса.

- критика :)

Разрешение экрана и другие настройки можно подправить в Settings.xml

Что изменилось с предыдущей версии:

- много графических улучшений (тени, DOF, Bloom, Reflections, Soft Particles...)

- переработано управление роботом, добавлено прицеливание и огонь (пока к сожалению убивать низзя)

- добавлена устойчивость роботам

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

- партиклы

- много внутренней работы, которая не видна снаружи :)

Демка (13.4 мб): http://www.anegmetex.com/RoboDev/Demo02_AimFireAndBotMove.rar

Для запуска требуются установленные дрова физикса не менее 2.7.2 версии.

Убедится в его наличии можно проверив существование папки C:\Program Files\AGEIA Technologies\v2.7.2

Также желательно наличие третьих шейдеров. Если таковых нет – скачайте патч (http://www.anegmetex.com/RoboDev/ShaderModel_2.0_patch.rar) и распакуйте в папку Data\Shaders\.

Управление в демке:

A-D – разворот робота

W-S – передний и задний ход робота (задний ход чёто в последний момент отвалился...)

Мышка – управление прицелом

Левый Ctrl – установить камеру в позади робота

M – добавить 10 точек вейпоинтов каждому боту

L – Разфигачить всех роботов

Название проекта

2009-02-17T12:11:00.000-08:00

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

Физика: разрушение роботов

2009-02-17T11:51:00.000-08:00

Вот снял маленький ролик, показывающий разрушение роботов. Хоть пока спец-эффектов и нету, но какое-никакое представление даёт:

ИИ: Езда по сложной местности

2009-02-10T10:24:00.000-08:00

Вот надоумил меня давеча товарисЧ DEN 3D попробовать робота на холмисто\бугристой местности (http://www.gamedev.ru/community/robo_game_blog/forum/?id=91289)
Собсна как я и ожидал появились проблемы - робот стал переворачиваться и тупить на горках. Однако чуть подправив физическую модель удалось свести эти нежелательные последствия к минимуму.
Вот как он гоняет теперь по неровной (мягко сказано) поверхности. Надеюсь с этим траблов больше не будет:

ИИ: Езда по контрольным точкам

2009-02-07T16:48:00.000-08:00

Начал работать над перемещением ботов. Pеализовал два типа перемещения - танковый стиль езды, и колёсный стиль езды. Различаются они в основном способом разворота. Например танковый может на месте разворачиваться, а колёсный - нет. Ну и ещё парой-тройкой коэффициентов.

Вот многие говорят - чего сложного, настроишь как в жизни физику и всё. А вот фиг - или мордой начинает вилять, или опрокидывается или ещё чего... А ведь сейчас он ездит всего лишь по ровной гладкой плоскости ) К тому же для удобства потребовались определённые константные значения для параметров робота (как то максимальная скорость, максимальный крутящий момент), не зависящие от суммарной массы робота.

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

Зато теперь робот ездит прямо, не виляет, не переворачивается… и в тоже время выглядит весьма правдоподобно: его заносит на поворотах, если на полном ходу врезается в препятствие (бочка) – его закручивает, однако он выравнивает направление и продолжает ехать в нужную сторону. Вообщем для ботов сгодится :)

А вот для игрока не знаю… возможно для более комфортного управления, придётся написать другой код…

Танковый стиль езды:

Колёсный стиль езды:

Рендер: система частиц

2009-01-30T12:00:00.000-08:00

Работаю над системой частиц. Она и раньше вообщем была, но надо было внедрить её в новый рендер. Кроме того начал проектировать спец-шейдеры для неё. Сделал пробный огонь. Вроде выглядит весьма не плохо, особенно с блумом :)

В планах добавить партиклам возможность проигрывать анимационные текстуры (через волюм текстуру), текстуры с нормалом (для эффекта объёмного дыма) и, возможно, использование физичных партиклов от PhysX. Последнее правда под большим вопросом, ибо довольно сильно грузит систему. Наверно будет использоваться лишь в локальных местах в качестве Wow-фактора :)

Рендер: отражения

2009-01-24T07:58:00.000-08:00

Прикрутил я давеча к движку отражения. Конечно фейковые – кубамапа предрасчитана заранее и хранится с файлами уровня. Но так как материалы у меня далеко не зеркальные её фейковость не сильно заметна. А визуальная часть слегка улучшилась. Теперь надеюсь ни кто не будет говорить что всё из пластилина :)

Рефлекшн в движке можно настраивать очень гибко. Для него выделено аж две карты коэффициентов (одна для Color составляющей, а вторая для Spec составляющей отражения). На производительности шейдера это не сказалось, т.к. спек ведь у меня шёл отдельной текстурой, в его альфе канале хранился коэффициент мощности отражения. Соответственно оставалось ещё два не использованных канала, которые я под рефлекшн и заюзал. Настоящее раздолье для художников по текстурам ))

Вот примерно такая картина по каналам спек текстуры (power константная, ибо пока менять её не было смысла):

Записал видео с рефлекшеном. Чесно говоря плоховато видно из-за сжатия, но на полу отражения рассмотреть можно:

Постэффекты: DOF & Bloom

2009-01-17T07:11:00.000-08:00

В перерывах между опиливанием игровых объектов прикрутил пару постэффектов. А именно Depth-of-Field и Bloom. Хотя эстетическое восприятие первого эффекта весьма спорно (см скриншот). Ешё ну очччень хочется добавить и SSAO. Очень надеюсь что фреймрейт не умрёт. (а ведь ещё мягкие частицы запланированы…)

Также сделал наконец то отладочную визуализацию камеры. Сделал через функцию D3DXVec3Unproject, т.к. почему то умножение на обратную матрицу WorldViewProj давало неверный результат (почемуто не учитывался fov).

Демка управления роботом

2009-01-10T08:41:00.000-08:00

А вот собственно и демка :)
Потестите пожалуйста на запускаемость и удобство управления роботом. Также было бы не плохо вашу конфигурацию и фпс.

Разрешение экрана и другие настройки можно подправить в Settings.xml
Параметр CameraPosInterpolation – определяет сглаженность изменения позиции камеры. При включении почемуто появляются рывки… поэтому по дефолту пока отключено.

Демка (6.7 мб):

http://www.anegmetex.com/RoboDev/Demo01_RobotControl.rar

Для запуска требуются установленные дрова физикса не менее 2.7.2 версии.
Также желательно наличие третьих шейдеров.
Если таковых нет – скачайте патч (http://www.anegmetex.com/RoboDev/ShaderModel_2.0_patch.rar) и распакуйте в папку Data\Shaders\.

Управление в демке:
A-D – разворот робота
W-S – передний и задний ход робота
Мышка – управление прицелом
Левый Ctrl – установить камеру в позади робота
P – поднять вверх робота
Пробел – добавить бочку в уровень
F1 – вывод отладочной информации физ движка

Это вам не ВАЛЛ-И!

2009-01-08T12:53:00.000-08:00

Провожу тесты подвески и гусеничного хода робота. По сути подбираю набор хаков физ двига :)

Вот так балванчик умеет гонять:

Он скоро заработает ...

2009-01-04T12:01:00.000-08:00

Lights & shadows test

2008-12-30T04:15:00.000-08:00

Реализую классы сцены, по принципу, рассказанному в предыдущей серии :)

Не всё оказалось гладким. Точнее всё оказалось грубым и с зазубринами. Для начала неожиданно для себя узнал что стандартный вектор STL переалоцирует всю память, при резервировании. Далее оказалось что этот самый вектор требует ещё и конструктор копии для сложных агрегатных классов. В итоге – два дня на исправление моего ageDynArray (основанного на STL векторе) плюс нудное подписывание конструкторов копий для всех сложных агрегатных классов (коих у меня оказалось 12 штук). Раньше я ничего не замечал ибо клал в свой ageDynArray только относительно простые классы, для которых компилятор генерирует конструктор копии автоматически.

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

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

Вот:

Иерархия игровых объектов

2008-12-22T10:33:00.000-08:00

Работаю над иерархией и общей структурой объектов. Сначала в движке планировал разбить иерархию объектов на два класса – сцена и игровой уровень. Предполагалось, что в сцене мы храним сами пулы простых объектов, а в классе уровня – глобальные ссылки на них и пулы сложных объектов, собирающие несколько ссылок на простые объекты. Кроме того, логически, уровнь будет содержать классы конкретной игры, а сцена – более общие классы.

Вот такая была схема:

class Scene

 Lights

 Particles

 Decals

 SceneObjects

class GameObject

 LightsID

 ParticlesID

 DecalsID

 SceneObjectsID

class GameLevel

 ParticlesType

 DecalsType

 ActorsType

 StaticsType

 DynamicsType

 LightsID

 ParticlesID

 DecalsID

 Actors:GameObject;

 Static:GameObject;

 Dynamic:GameObject;

Однако, при ближайшем рассмотрении всё пошло пи… короче такая схемка не покатит. И вот почему. Во-первых, отсечение по ок-трии в целях оптимизации надо будет делать в классе уровня, ибо отсечь один GameObject быстрее чем кучу SceneObjects, Particles и других его составляющих. Во-вторых, сомнительная радость размазывать хранение параметров для типов объекта по двум классам (например партиклы, декалы). В третьих же сериализация опять таки достаётся классу уровня.

Вот таким макаром класс Сцены становится всё худее и худее, а его значимость – всё меньше и меньше.

Вообщем волевым решением я всё перенёс в мега-класс GameScene:

class ageGameScene: public ageSingleton

 ageResourseManager  ActorsType;

 ageResourseManager  DynObjectsType;

 ageResourseManager  StatObjectsType;

 ageResourseManager  StatParticlesType;

 ageResourseManager  StatDecalsType;

 ageCDynArray        SceneObjects;

 ageCDynArray          Cameras;

 ageCDynArray          Lights;

 ageCDynArray          Decals;

 ageCDynArray      Particles;

 ageCDynArray          Actors;

 ageCDynArray        DynObjects;

 ageCDynArray        StatObjects;

 //world objects

 ageSimpleArray<int>      ActorsID;

 ageSimpleArray<int>      DynObjectsID;

 ageSimpleArray<int>      StatObjectsID;

 ageSimpleArray<int>      LightsID;

 ageSimpleArray<int>      ParticlesID;

 ageSimpleArray<int>      DecalsID;

 int               CameraID;

};

Вот такой жирдяй-класс. В нём же практически вся игра будет :-D

-----
К слову о проектировании. В голове эти все объекты у меня выглядят таким образом :-D

Физика: первые тесты

2008-12-19T07:17:00.000-08:00

Чтож пока с рендером я решил завязать. На очереди – иерархия объектов.

class ageRenderObject

};

class agePhysicsObject

};

class ageSceneObject

 class ageRenderObject;

 class agePhysicsObject;

};

Вот, поднимаясь по иерархии вверх я создал класс ageSceneObject который включает в себя отрисовочный объект ageRenderObject (с которым я работал ранее) а также объект физического движка agePhysicsObject. В нём (ageSceneObject) происходит их синхронизация. Новонаписанный класс agePhysicsObject является просто обёрткой над классом физикса NxActor, и имеет специфический для моего движка функционал. Как например загрузка физической оболочки из файла.

Естественно вручную задавать оболочки это очень плохая идея. Поэтому я потратил пару дней на изучение плагинов и программ для их визуального создания и остановился бесплатном редакторе Scythe (http://www.physicseditor.com/)

Что я могу про него сказать? Хороший, интуитивно понятный редактор и прозрачный формат выходного файла. Конечно для загрузки оболочек можно использовать и их API, однако там очень много лишнего, поэтому я написал свой загрузчик их формата (благо его описание присутствует на их сайте в разделе downloads)

Вот видео того, что получилось:

И тоже самое но с отладочной информацией:

Рендер: да будут тени!

2008-12-17T01:27:00.001-08:00

Ну вот, прикрутил я наконец тени. Не обошлось конечно без проблем (http://www.gamedev.ru/code/forum/?id=88870), но спасибо форумчанам геймдева, помогли найти кое-какие опечатки в коде :)

Вообще в деферреде оказался один такой жирный минус – большая нагрузка на пиксельные шейдеры. Вот из-за этого и получилось так, что PCF размытие тени ни в какую не влезает по количеству инструкций в шейдеры версии 2.0, так что пока пришлось для тенюшек компилировать пиксельные шейдеры в версию 3.0. Это конечно совсем не айс, так как я всё таки решил поддерживать и 2.0, поэтому в будущем постараюсь как-нибудь упихать, хоть простенькие PCF2x2, в версию 2.0.

Также сделал поддержку объектов с альфа-дырками (см. на рисунке ветхий край ржавого заборчика) и рендинг от них теней.

Рендер: освещение закончено... вроде

2008-12-07T15:00:00.000-08:00

Освещение закончено. Все типы источников отлажены и работают. Хотя я пока не сделал оптимизации со стенсел-буфером, но думаю это подождёт. Теперь буду прикручивать обратно тени в движок :)

Точечный:

Направленный:

Конический:

Принцип модульной конструкции роботов

2008-11-24T16:15:00.000-08:00

Все роботы в игре будут состоять из следующих частей:

Корпус
Двигательный модуль
Шасси
Навесное оборудование

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

Художник Grizo (aka Snake) сделал рисунок, объясняющий принцип сборки роботов из составных частей.

Рендер: deferred освещение

2008-11-24T16:02:00.000-08:00

Начал делать освещение на деферред. Сделал пока освещение от направленных и точечных источников. Освещение естественно полностью bump-specular. При написании шейдера ГБуфера появилась идея использовать дополнительные карты нормалей для повреждённых деталей и увеличение контрасности бампа (normalFromMap.z/=damage_factor;) соразмерно величине этих повреждений. Вообщем идея интересная и вроде не особо сложная в реализации... покрайней мере пока так кажется :)

Ещё хочу сказать спасибо тов. Zeux за лекцию R.E.N.D.E.R. (http://www.gamedev.ru/community/gamedev_lecture/articles/r_e_n_de_r) о том, как реализован деферред рендер в Сталкере. Много интересной и полезной информации которой я сразу и воспользовался :)

Привожу скрины с текущего билда движка. В сцене действует один направленый источник (белый) и один точечный (красный).

Рендер: Deferred shading

2008-11-17T09:07:00.000-08:00

Да, я делаю именно это :)
Я переписываю рендер на деферед шейдинг. Решение такое было принято отнюдь не из-за желания следовать модным тенденциям, а сугубо суровой необходимостью.
Эта технология я считаю даст большую производительность рендеру, чем если бы я продолжал писать на форварде.
Итак, почему же именно деферед?

В игре будет унифицированная модель освещения (Фонг)
В кадре будет приличное кол-во DIP-ов
Много точечных (и не очень) источников света
В кадре отсутствуют полупрозрачные объекты aka стёкла
Будут пост-эффекты типа SSAO которым всё равно нужны нормали )

Ну и так, без пункта ещё добавлю, что мороки с дефередом гораздо меньше чем с форвардом: не надо делать списки освещаемых этой лампочкой объектов, нет кучи разных шейдеров...
И лампочки новые добавлять - одно удовольствие :)

Движок: загрузка объектов

2008-10-30T06:50:00.001-07:00

Работаю над загрузчиком объектов. Переписал кое-какие части и сделал многое по нормальному. Дополнил формат объектов (использую для всех данных XML формат).
Вот плоды моих экспериментов (всё-таки мои тени смотрятся очень даже ничего):

Набросок кусочка уровня

2008-10-20T13:31:00.000-07:00

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

Модели: ветхий забор, платформы, опора

2008-10-20T13:17:00.000-07:00

дряхлый поломаный заборчик для уровня "свалка":

платформы для уровня "завод":

опора металлических ферм для уровня "завод":

Рендер: освещение (переделан пайплайн)

2008-10-05T15:17:00.000-07:00

А вот не всё так радостно оказалось, как планировалось :)
Т.к. нам при наложении теней (и освещения собсна тоже) от нескольких источников надо различать какая тень от какого источника рендится. Ибо сложение освещения идёт по формуле:

Light1*Shadow1+Light2*Shadow2+...+LightN*ShadowN

А по технике складывания в один буфер получается что

Light1*(Shadow1*Shadow2*...*ShadowN) + Light2*(Shadow1*Shadow2*...*ShadowN) +... + LightN*(Shadow1*Shadow2*...*ShadowN)

Короче нифига неправильно затенялось :( (http://www.gamedev.ru/code/forum/?id=85226)

Вообщем переколдовал я рендер и решил проблему через MRT. При освещении в RT1 рендится бамп и освещение, в RT2 – только тени с освещением. Потом RT2 фильтруется и накладывается на RT1. Таким образом получаем чёткий бамп с наложенным на него освещением и подразмытыми тенями. Проверка на растекание тени через края объектов также присутствует. Реализованы все виды освещения Directional, Omni, Spot.

Теперь займусь наверно общей архитектурой игры – иерархия объектов, отсечения и всё такое.

Модели: тех-блок, бочка

2008-09-15T03:35:00.000-07:00

Технический блок, напичканой разной фигнёй - кнопками, проводами, переключателями...

Просто бочка

Модели: Насосная станция

2008-09-08T04:11:00.000-07:00

Первые наброски зданий. Насосная станция. Текстуры пока WIP, не везде довёл до ума.

Первый свет. Пайплайн рендера

2008-09-05T14:33:00.000-07:00

Освещение

Освещение – очень важная деталь в современном рендинге. Думаю гдето 30% визуальной привлекательности картинки – хороший свет и тени. Оно придаёт объём и делает картинку более выразительной.

В проекте будем использовать попиксельное освещение, для теней – шадоумапы, простейший бамп, спекуляр, возможно SSAO.

В игре будут следующие типы источников:

Глобальное освещение. Глобальное освещение представлено виде одного направленного источника плюс небольшой амбиент. Резмер теневой карты – 1280x1280 пикселей. Возможно будет также реализовано SSAO.

Подсветка участков уровня. Предположительно только конусные источники (Фонари, прожекторы). Освещают существенную часть уровня (до 2/3 игрового экрана) Размер теневых карт (в зависимости от размера источника) – 512, 256, 128. Также сюда входят споты и с анимированным прожектором – это крутящиеся винты вентиляции и т.п.

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

Пайплайн рендера

Пайплайн рендера на данный момент таков:

Z-проход. Заполняем Z-буфер. Получаем Z-текстуру. Если используется SSAO – рендерим буферы нормалей и позиции.
Рендер теней в буфер теней. Для каждого источника рендим Z-текстуру и после переключаем камеру и рендим наши тени для этого источника в буфер теней. Повторяем операцию для всех лампочек, имеющих тени. На этом этапе НЕ ИСПОЛЬЗУЕМ вообще никакого сглаживания. Даже ПЦФ.
Размываем двумя проходами гаусс-фильтра наш буфер теней. Подтёки теней устраняем при помощи Z-Текстуры (которую получили в пункте 1).
Далее рендим освещение от каждой из лампочек в буфер цвета. Используем простой бамп (это всё пока без диффузной составляющей)
Вот теперь рендим диффузную составляющую.
Ну и наконец COMBINE! Всё собираем и выводим на экран.

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

Частицы, PhysX, Модели

2008-08-28T11:21:00.000-07:00

Движок. Частицы

Как я уже говорил, я переписываю свой старый движок на новый лад. Стараясь исправлять все прошлые косяки в архитектуре. Вот сейчас дошёл до системы частиц. То что было в старом движке было довольно косячное, не было многих нужных параметров (масса, гравитация, ветер). Поэтому я решил полностью переделать этот модуль… на основе примера с codeproject. (Мы против велосипедов) Процесс портирования занял около 4 часов, больше связанный с изменением семантики и перешиванием рендера (в примере были поинт спрайты, а я юзаю квады. Кроме того было сделано разделение на ParticleEmitter и ParticleSystem). Логика движения частиц осталась нетронутой. Пока так сгодится. В итоге первый костёрчик в проекте заработал к вечеру :)

PhysX

Вчера изучал утилиту PhysXViewer. Довольно полезная штука, обтягивает геометрию физическими примитивами и\или строит упрощенную физ. модель. Думаю её стоит заюзать в проекте. Однако не понравился интерфейс, и, что более важно, то что она на выходе генерит. А генерит она XML набитый до отказа всякими установками сцены, флажки и т.д. Короче среди этого безобразия лежат нужные данные по созданным примитивам. Поэтому возможно придётся написать утилитку-чистильщик, которая удалит всю не нужную белиберду

Модели

Апдейт. Мелочёвка для уровня.

Электронагнетатель. Наверху эмиттер который будет искрится системой частиц

Просто железные блоки для локации "свалка"

Башня. Предположительно наверху будет вращающаяся турель

Наброски в Максе

2008-08-26T11:41:00.000-07:00

и сразу публикую наброски, чтоб понятно было про что вообще речь идёт:

А в игре будут они в таком масштабе:

Вот примерно такой аляповатый арт планируется в игре. Если я конечно моделить лучше не научусь... что сильно врятли

Начало проекта

2008-08-26T11:35:00.000-07:00

Вот и пришло время нового проекта. Отдохнув от очередного провала(http://www.gamedev.ru/projects/forum/?id=73077) и полностью разочаровавшись в командах энтузиастов, я с чистой совестью решил делать что-то новое. Поразмыслив немного пришёл к выводу что проект принесёт больше пользы, если я буду описывать его разработку в блоге (всегда хотел попробовать вести блог), ну а так как мой хостинг только HTML держит, то...

Итак. Поинты проекта на данный момент такие:

Игра про роботов (Не, ну а чё? :)
Фишка игры в том, что роботов можно собирать из отдельных частей
Механика как в старичке Scary Nightmare (вид сверху, управление аля алиен шутер). Возможно будет введены некоторые РПГ элементы
Сюжет ну о-о-очень секретный :)

Техническая сторона вопроса:

Третья ипостась моего недодвижка
DirectX9\C++\Шейдеры 2.0
Мидлваре – PhysX,pugiXML,Lua,OggVorbis
Предположительно пока всё делаю сам. Арт\Звуки\код

Почему такой выбор:

Анимировать не умею, поэтому роботы не человекоподобные
Вид сверху – проще движок, нет лода, оклюжена и прочего геморроя
Геймплей знаком. Многое прорабатывалось мной в Scary Nightmare
Техногенный арт проще делать, чем для скажем средневековья. И не надо соблюдать реальные пропорции\вид\цвет и т.д.

Вот с этим на борту и выступаем. Проект делается “Фор Фан”(TM) и в свободное от работы время. Поэтому частых обновлений не ждите.