Приветствую всех аллодеров. Предлагаю вашему вниманию игру в жанре пошаговая RPG (с элементами рогулика), основанную на ресурсах наших любимых А2. Рабочее название - ROM Roguelike. Версия для браузера доступна здесь. Под хромом скорее всего не пойдет. Под Оперой работает 100%, только плагин UnityWebPlayer надо поставить. Ваял в одиночку, в свободное время, на голом энтузиазме, поэтому строго не судите. Естественно, проект бесплатный. Ну и, как водится, проект еще не завершен, требуется помощь энтузиастов. Технические подробности можно найти тут. Спасибо за внимание, жду отзывов. Немного скринов:
а возможно ли (технически) на этом плагине сделать а2 в реальном времени? Заменить вечно вылетающий продукт новым?
Это действительно трудоёмко, тем более когда делаешь это один и без каких-то технических знаний об механике а2 в целом. Потому что насколько я понимаю, эта пошаговая игруля к механике а2 никакого отношения не имеет в принципе. Мне бы конечно самому было бы интересно взглянуть на код, насколько хорош или плох для данного проекта движок Unity, т.к. всеми любимый ZZYZX уже несколько раз начинал писать клиент с нуля, но пока так и не пришёл к чему-то близкому хотя бы к этой стадии разработки.
Почитал технические подробности. Во-первых Анотом тут нагло врёт. Я пришёл к чему-то близкому к этой стадии разработки и Анотом в это играл, ёпт, по мультиплееру. Но уже видимо благополучно забыл, ну или для него возможностьдамажить юнитов перевешивает мультиплеер... Ты думаешь что под юнити писать быстрее чем с нуля? В случае с А2 — как минимум так же быстро. Только с нуля будет C++, а из-под юнити лагающая фигня из-за наличия виртуальной машины. Но сейчас не об этом. У меня возникла пара вопросов. 1) Спрайшиты. Какого размера получаются спрайтшиты от тролля или дракона? (хотя если честно я не вижу смысла в использовании спрайтшитов совсем... всё равно переключать текстуру постоянно для рендера мобов, а спрайтшит ещё и огромная текстура на пределе видеокарты будет...) 2) Формат ALM. http://archive.allods2.eu/homeunix/article_alm_format.php.htm Единственное что, там у Лэнда через жопу описаны координаты юнитов и флаг моста. Флаг моста не 10 00 00 00, а 01 00 00 00, а координаты юнитов (и зданий) это не "+ 0x80", а fixed point short, указывающий на центр клетки. "80 40" необходимо понимать как "64 и 0.5". Я не пробовал ставить юнитов на значения отдельные от центра, но вполне уверен что именно на это "80" и указывает. 3) С туманом войны я тоже использовал текстуру 256х256, только я туда пихал не альфу, а цвет. Полутёмный — в тумане, чёрный — не видно. И соответственно не рендерил то что в чёрном находится. 4) Ты там уже до палитр юнитов дошёл? Реализовывать собираешься? Я в своё время именно из-за этого отказался от конвертирования картинок, поскольку один спрайт моба запиханный в память это примерно 5-6-8мб в RGBA, а если картинки конвертировать, то это число умножается на 5 (разумеется если на карте присутствуют мобы нескольких уровней, но не выгружать же мне при выходе с карты всё что успело загрузиться? а за несколько карт может и накопиться...); поэтому у меня в спрайтах (256, 16a) был вариант с текстурой Luminance/Alpha (кажется) двухбайтовой, первое значение из которой я использовал как индекс палитры, и использовал совместно с нужной палитрой через шейдер. Таким образом размер не только не увеличивается по сравнению с RGBA, но и уменьшается! 5) Щас я тебе скину код по рассчёту области видимости. Вообще он уже есть в архиве, но там в недопиленном виде, а у меня готовый класс. http://pastebin.com/QUC0ajfW http://pastebin.com/VXk6mRNi Оно правда на C++, но всё лучше чем ничего. 6) Могу поделиться загрузкой 16a, 256, 16 на C#. Надо? Так, что ещё. Тень рассчитывается от центра юнита. Центр юнита указан в units.reg в локальных координатах (RealCenterX=CenterX/Width*реальная_ширина_спрайта, аналогично для Y, аналогично высчитывается размер Selection*) Центр тени, должен накладываться на центр юнита с таким рассчётом, что самое большое смещение тени в сторону это приблизительно треть высоты спрайта, а остальные смещения где-то между этим значением и центром. Единственное исключение это летающие юниты, для летающих юнитов без искажений вешается спрайт куда-то в сторонку. Возможно на основании высоты полёта, если такой параметр используется (он есть в любом случае). У меня этот код выглядел примерно так: http://pastebin.com/dgvHtgeu (centerx, centery уже заранее были умножены на что надо).
1. Тролль - 2016х1920 (565 кб весит png-файл). Но его можно еще ужать, потому что пустого места много остается. Летающих юнитов пока не делал. Использование спрайтшитов- это особенность работы с Unity. Чем меньше количество спрайтшитов - тем быстрее отрисовывает картинку движок. 2. Вот спасибо за линк. Правда многое сам уже допёр, но "7, иногда 5 (что это?)" это улыбнуло ))) 3. С туманом у меня есть недочет - не учитываются дробные значения обзора, а по идее должны. 4. Сейчас у меня они сделаны колхозно на скорую руку. Просто добавляю оттенок поверх спрайта. Совсем не тот эффект. Палитры делать надо на шейдерах, однозначно. А где лежит информация о переходе цветов? 5. Спасибо, попробую разобраться. С плюсами почти не работал. 6. В Unity нет такой свободы по преобразованию спрайтов как в С++. Хотя, может я учел не все возможные техники. Опять же, спасибо за линк. А где можно прототип посмотреть твой?
У меня этих прототипов очень много. Штук 10. Потому что в определённый момент я проект откладываю, а потом независимо от него через пару месяцев узнаю что-нибудь новое и начинаю с начала. Вот, например, на CS: http://www.mediafire.com/download/e3cwyiysyoangei/zallods.zip У меня вроде был более адекватный вариант (там ещё модели из шрифтов генерились), но я не помню где он лежит. Загрузка 16/256/16a впрочем и здесь есть. Конкретно тот из которого я процитировал отрисовку теней на плюсах и очень замороченный, я его сам уже плохо понимаю (он 2012 года примерно). Хотя конечно если хочешь могу скинуть и его ) В .pal файлах по смещению 0x36 (или 0x34... не помню) находится палитра. А2 используют эту палитру вместо встроенной палитры .256 (смотри разбор формата в C# коде). А вообще .pal файл это 8битный BMP, видимо нивалу так проще было наглядно редактировать палитры. Ещё бывают отдельно палитры для хуманов, тут используется просто файл... ну я не помню где он. Суть в том что там просто лежит список палитр на 17 цветов хуманов вместо BMP (16 + кп). Кажется где-то в graphics/units/humans?.. update: я откопал тот самый "более адекватный проект". Вообще, прикол в том что на данный момент самый продвинутый движок (C#/OpenTK, юзает VBO, шейдеры и всячески прикидывается OpenGL 3.x) выглядит так: Собственно поэтому Анотом и говорит, что я ни хрена не сделал. Содержит: 1) чтение res 2) чтение reg 3) чтение картинок, 16a, 256, 16 4) шейдеры 5) модели (mesh) — фактически интерфейс к VBO 6) Texture — интерфейс к GL_TEXTURE_RECTANGLE_ARB 7) шрифты — вот это единственное место где я использую спрайтшиты, чтобы можно было делать VBO надписи на основе одной текстуры (в частности на скрине в консоли все надписи используют одну текстуру со списком вершин) 8) самая базовая загрузка ALM (потом планирую допилить), просчёт освещения (я никогда не делал никаких объектов для освещения, считаю вручную, рендерю в текстуру, отображаю поверх карты с интерполяцией шейдером, которому отдельно юниформом указываю координаты клетки в текстуре) 9) система гуя; Дерево виджетов, на котором строится почти весь движок. Корневые виджеты (меню, магаз, карта и подобные) сделаны специальным подклассом LoadableWidget, в котором перед непосредственно отображением происходит подгрузка ресурсов в отдельном потоке. Остальные виджеты становятся дочерними по отношению к корневым. Например, при активной карте это выглядит так: сначала RootWidget, потом MapView (основной виджет для карты), а потом по отдельному виджету на каждый компонент карты (миникарта, книга заклинаний, картинка текущего юнита и всё такое). Данная система нагло содрана с Аллодов, там используется буквально такой же подход. Обычно у меня в проектах после написания консоли уже можно делать карту и переключаться к ней командой map, благополучно скипая разработку GUI (хотя начало там тоже заложено для гуя). Так что может потом что-то и покажу ещё.
Жесть! Да вы маньяк, батенька! ))) В литературе по геймдеву приводятся такие итеративные ситуации, их надо избегать. Советуют не бросать и доводить проекты до конца. На мой взгляд изначально подход неверный выбран был - переписать аллоды, используя технологии прошлого столетия. Потом пришло понимание, что многое изменилось, стало проще, новые инструменты, библиотеки.. и да, надо начинать сначала)) А если бы сразу взял Unity для разработки - уже бы сделал годную версию, думаю. Заодно прокачал бы скилов и можно в геймдев идти смело работать (если есть такое желание). Спасибо за исходники и за информацию (хоть я многое и не понял, потому как даже аббревиатуры (OpenTK, VBO) были мне незнакомы). Я сейчас на перепутье: либо пытаться кооперироваться с вами и делать серьёзный римейк А2, либо оставлять этот проект как есть и мутить свой проект (в другом жанре). Надо пообщаться с вашей "могучей кучкой" ))
Итеративных ситуаций нужно избегать если есть цель сделать продукт. У меня нет цели сделать продукт, мне сам процесс интересен. Когда процесс перестаёт интересовать, я забиваю. Между прочим в этом самом процессе я узнал кучу вещей как по программированию в общем, так и по графике в частности. Да, о каких технологиях прошлого столетия ты говоришь? Понимание было не совсем такое. Просто в определённый момент я например обнаруживал что движок жутко лагает... естественно где-то в этот момент я забивал если не мог решить проблему. И обычно находящееся потом решение противоречило изначальному способу разработки. В геймдев я и так могу пойти. Поскольку я достаточно сильно вник в техчасть и существующие движки особой сложности не представляют. OpenTK это библиотека для прямой работы с OpenGL для .NET. VBO это технология загрузки вершин в видеопамять, в противовес более старому методу отрисовки "напрямую" (aka Immediate Mode). По сути VBO-объект это и есть модель — список вершин, текстурных координат, цветов... Там ещё есть дополнительные фичи, но я их никогда не использовал. Напиши в скайп jewalky. (напишет кто-то другой — игнор сразу. фуллы не восстанавливаю, не криэйчу, не продаю, и так далее). Вот кстати гитхаб сделал: https://github.com/jewalky/SharpAllods Для работы нужно в рабочую папку (в папку с проектом, если запускать через ctrl+F5) положить .res-файлы от А2.
