
Трехмерная стратежка - 2
Продолжаю ковырять стратежку.
Новости под катом.
Демка: megaswf.com/simple_serve/85531/
Скрин (снова без лайтмапов. В следующий раз точно будут).

Под напором ваших злых и бессердечных комментариев сделал сетку.
Получилось не сильно красиво, да и кружочки мне больше нравились, но поскольку даже вам, как лояльно настроенным товарищам, они пришлись не по душе, то «тупые дети с конга» точно загнали бы мне карму в минуса :)
Итак, управление.
Тыкаем на пацана, тыкаем куда идти, идем.
Тыкаем по пустому месту, чтобы снять «выделение».
Кружочки я все-таки оставил.
На дверях. В будущем, над разными объектами (двери, ящики, бочки, кнопки).
Тыкаем по кружочку, чтобы дверь открылась или закрылась.
Кружочки появляются только на соседних клетках с выбранным марином.
Нужен фидбэк.
Стало лучше? Сетка не сильно страшная?
Ну, что еще?
Сетка рисуется быстро, потому что пикселей мало. На квадрат 4*4 пиксела заполняются только два.
Рассматривал несколько вариантов:
1. Рисовать в текстуру пола.
Не пойдет, потому что будут лифты/платформы, да и вообще, мне такой подход не сильно нравится. Искать координаты ячеек в текстуре, сохранять старый кусок, рисовать новый. Можно, конечно, все это сделать, но не люблю такое.
Еще будут проблемы с тонкими линиями.
2. Рисовать в отдельную битмапу попиксельно и блендить поверх основной картинки.
Рисование прошло бы быстро, блендинг тоже быстро.
Проблема — очищать каждый кадр побочную картинку, причем очищать «руками», а не через fillRect(). Возможно к этому варианту еще вернусь.
3. Рисовать прозрачные текстурированные квады.
Почти как сейчас, только линии нарисованы в текстуре, а не отдельно.
Проблема — пропадают пиксели в линиях и ОЧЕНЬ медленно все рисуется.
Попутно поборолся с рисованием линий (была проблема с z-файтингом) и прозрачных полигонов, которые рисуются ОЧЕНЬ медленно.
Прозрачных полигонов будет мало.
Что делать с эффектами — пока с трудом представляю.
Анимации пока не трогал, но буду.
Резкий переход от открывания двери к стоячему положению меня раздражает.
Будет медленно, зато не так убого.
Много времени (день) ушло на «моделлинг», текстурирование и анимацию двери :)
Мне проще написать несколько килобайт кода, чем набросать пару боксов в 3дМаксе.
Одновременно изучать 3дмакс, пытаться сделать не сильно страшно, думать о производительности и ограничениях движка довольно тяжело.
Ассеты.
Ассетов будет много, их уже сейчас дофига.
Модельки, анимации, текстуры, всякие внутренние данные.
Привык все эмбедить кодом, у меня во всех проектах есть отдельный большой файл с кучей эмбедов. Я его генерю с помощью скрипта, так что это не сильно страшно, но в данном случае решил пойти по другому пути.
1. Все ассеты пакуются в один/несколько зипов.
2. Зипы эмбеддятся.
3. Пишутся функции получитьБитмапуПоИмени(), получитьСтрокуПоИмени() и т.д.
4. В функциях вытаскиваем файл из архива, приводим к нужному объекту, возвращаем.
Получается фактически виртуальная файловая система в режиме ридонли, с поддержкой каталогов и т.д.
Удобно, хотя и медленно.
Если будет сильно тормозить — придется писать свои функции для архивов/конвертации форматов, пока использую следующее:
1. Чтение зипов — nochump.com/blog/archives/15
2. Чтение картинок — www.zaalabs.com/2010/04/introducing-zaail-40-image-format-support-for-flash/
Пока все, работаю дальше.
Новости под катом.
Демка: megaswf.com/simple_serve/85531/
Скрин (снова без лайтмапов. В следующий раз точно будут).

Под напором ваших злых и бессердечных комментариев сделал сетку.
Получилось не сильно красиво, да и кружочки мне больше нравились, но поскольку даже вам, как лояльно настроенным товарищам, они пришлись не по душе, то «тупые дети с конга» точно загнали бы мне карму в минуса :)
Итак, управление.
Тыкаем на пацана, тыкаем куда идти, идем.
Тыкаем по пустому месту, чтобы снять «выделение».
Кружочки я все-таки оставил.
На дверях. В будущем, над разными объектами (двери, ящики, бочки, кнопки).
Тыкаем по кружочку, чтобы дверь открылась или закрылась.
Кружочки появляются только на соседних клетках с выбранным марином.
Нужен фидбэк.
Стало лучше? Сетка не сильно страшная?
Ну, что еще?
Сетка рисуется быстро, потому что пикселей мало. На квадрат 4*4 пиксела заполняются только два.
Рассматривал несколько вариантов:
1. Рисовать в текстуру пола.
Не пойдет, потому что будут лифты/платформы, да и вообще, мне такой подход не сильно нравится. Искать координаты ячеек в текстуре, сохранять старый кусок, рисовать новый. Можно, конечно, все это сделать, но не люблю такое.
Еще будут проблемы с тонкими линиями.
2. Рисовать в отдельную битмапу попиксельно и блендить поверх основной картинки.
Рисование прошло бы быстро, блендинг тоже быстро.
Проблема — очищать каждый кадр побочную картинку, причем очищать «руками», а не через fillRect(). Возможно к этому варианту еще вернусь.
3. Рисовать прозрачные текстурированные квады.
Почти как сейчас, только линии нарисованы в текстуре, а не отдельно.
Проблема — пропадают пиксели в линиях и ОЧЕНЬ медленно все рисуется.
Попутно поборолся с рисованием линий (была проблема с z-файтингом) и прозрачных полигонов, которые рисуются ОЧЕНЬ медленно.
Прозрачных полигонов будет мало.
Что делать с эффектами — пока с трудом представляю.
Анимации пока не трогал, но буду.
Резкий переход от открывания двери к стоячему положению меня раздражает.
Будет медленно, зато не так убого.
Много времени (день) ушло на «моделлинг», текстурирование и анимацию двери :)
Мне проще написать несколько килобайт кода, чем набросать пару боксов в 3дМаксе.
Одновременно изучать 3дмакс, пытаться сделать не сильно страшно, думать о производительности и ограничениях движка довольно тяжело.
Ассеты.
Ассетов будет много, их уже сейчас дофига.
Модельки, анимации, текстуры, всякие внутренние данные.
Привык все эмбедить кодом, у меня во всех проектах есть отдельный большой файл с кучей эмбедов. Я его генерю с помощью скрипта, так что это не сильно страшно, но в данном случае решил пойти по другому пути.
1. Все ассеты пакуются в один/несколько зипов.
2. Зипы эмбеддятся.
3. Пишутся функции получитьБитмапуПоИмени(), получитьСтрокуПоИмени() и т.д.
4. В функциях вытаскиваем файл из архива, приводим к нужному объекту, возвращаем.
Получается фактически виртуальная файловая система в режиме ридонли, с поддержкой каталогов и т.д.
Удобно, хотя и медленно.
Если будет сильно тормозить — придется писать свои функции для архивов/конвертации форматов, пока использую следующее:
1. Чтение зипов — nochump.com/blog/archives/15
2. Чтение картинок — www.zaalabs.com/2010/04/introducing-zaail-40-image-format-support-for-flash/
Пока все, работаю дальше.
- +3
- ryzed
Комментарии (30)
Показалось, что так хорошо.
Значит буду еще пробовать.
Если добавить легкую пульсацию сетки возможных ходов, от текущего состояния до нуля и обратно идейно будет сразу чувствоваться что это сетка ходов. «Виртуальный план»
Имеется ввиду, что волны (ромбовидные? круглые?) будут ходить от выбранного марина и обратно?
Или от текущей клетки под курсором до выбранного марина?
Подсветку объекта сделаю, да.
Ближе к релизу все, конечно, буду подгонять.
Как геймплей допилю — буду искать артиста, чтобы нарисовал 2д и помог по общему дизайну.
По игре — сетку б ярче,)
Никогда не обращал внимания.
С камерой еще надо будет поработать, как минимум прибить ее к постоянной высоте.
Цвет сетки буду подбирать.
и еще мне кажется кружочки на дверью сделать чуть больше, имхо не заметят и опять же их выделить, чтобы не сливались с текстурами.
а так, очень круто) лучше чем в предыдущем топике :)
из того, что лично мне хотелось бы еще увидеть — чтобы выбор персонажа не сбрасывался при повороте камеры (т.е. как-то отличать обычный клик по местности и зажатый клик для повортоа камеры). а еще лучше — подумать нужен ли вообще сброс выбора персонажа. вполне может быть, что в твоем геймплее кроме персонажей ничего выбирать и не нужно будет.
и второе — функциональные объекты типа дверей должны как-то обозначаться даже если персонаж не стоит рядом. возможно кружочек не убирать совсем, а просто делать дизейбленым и при наведении на него показывать тултип — «подойдите чтобы активировть». а то сейчас двери не отличишь от других объектов бэкграунда, если не стоишь с ними рядом.
Можно и не сбрасывать.
Про убирание кружочков тоже думал.
Поковыряю.
Камеру закреплять сильно не хочется.
Не все уровни будут такими плоскими как этот. Будет сложно заглядывать «за стенку».
Посмотрим. Может сделаю 4 фиксированных угла.
И немного раздражает то, чтобы выбрать другого марина приходиться на нем кликать дважды (сбросить выделение старого, выделить нового).
Лайтмапы жрут память.
Пока думаю, как все это утолкать.
Просто сейчас роботы слишком яркие.
Амбиент хочу менять, но пока отложил.
Писать свой трейсер? Или читать из лайтмапа пола?
Т.е. при генерации уровня грузишь лайтмапы, считаешь амбиент составляющую и сохраняешь её в квадратах. Ну а потом, в самой игре просто берёшь амбиент из ближайших квадратов и интерполируешь в соотвествии с позицией юнита.
Модельки мелкополигональные, интенсивность между вершинами интерполируется.
Должно получиться интересно.
Имхо лайтмапы + амбиент для флеша за глаза хватит.