- Alprog
- Модератор
Ещё, на мой взгляд, не стоит прерывать анимацию кувырка. Если она началась, то кувырок проигрывается до конца.
Даже если мы перестали двигаться по горизонтали или развернулись на 180 градусов — анимация кувырка продолжается.
И даже если мы атакуем во время сальто. В этом случае просто рисуется ударная волна напротив персонажа. Надо всё это пробовать, короче :)
RPGman
> Как тебе lua в функциональном стиле? Не без объектов, но без классового фанатизма.
Lua я люблю.
Вот это я, например, написал полностью на lua:
http://store.steampowered.com/app/223000
Движок был на с++, но он отвечал только за графику и звук (то есть он даже не в курсе, какого жанра игра на нём пишется).
> Везде присыпано кложурками и местами присахарено dsl :)
Кложуры особо не использую, так как стараюсь писать код проще (чтобы потом на отладке не мучаться и другие могли разобраться).
У меня почти всё работало на корутинах (до 100 штук одновременно запущенных). Ну и множественным наследованием не чурался (переопределяя функции у таблички).
Что такое dsl?
Alprog
>Возможно, проблема в том, что прыжок прерывается в любой момент (на любой высоте). Это так и нужно?
Я так заказывал. Это дает больший контроль. Игра полагается на умение и мастерство игрока. Получается более плавный и непрерывный геймплей. Может быть этот момент в данной реализации не до конца развит и подчеркнут. Надо править динамику и смотреть что будет.
>Этот момент часто пропускаешь, и персонаж совершает лишний (неожиданный) прыжок.
Именно из-за этого. Хотя, сейчас потыкал Кастлванию, у неё одно нажатие = один прыжок. Прыжок управляемый и высота зависит от нажатия. Но он какой-то воздушный и антигравитационный. У Метроида то же самое, только прыжок ещё выше. У кастлвании серия прыжков более приятная(возможно за счет двойного прыжка), у метроида бывают проскальзывания.
Может быть, когда пробовали сделать 1 прыжок=1 кнопка, не правильно делали считывание, из-за чего нажатие не засчитывалось пока игрок точно не встанет на землю. Надо делать какой-то эпсилон и научится предвидеть землю, чтобы нажатую не вовремя кнопку засчитывало и исполняло.
> Но управление это очень важная штука.
Я с этим полностью согласен.
RPGman
> Не уверен только, что можно так сразу стартануть командой без чёткого плана и разделения.
Ты не торопись. Разработка затянется надолго. Писать будем не в постоянном режиме, а "приступами".
Командность послужит здесь только дополнительным мотиватором не разбежаться. Но всё равно кто-то может не дотянуть до конца.
А кто-то, наоборот, присоединится под конец проекта. Давай пока пообсуждаем фронт работ, технологии и предпочтения :)
> Используя фичи самого луа делаются возможными такие выражения, которые кажутся естественным языком для описываемой проблемы
Можно пример?
Sohei
> выкатить демку Инквизитора
Давно пора!
Alprog
> А давайте попробуем опенсорс.
Да, будет неплохо. Я не могу в принципе один тянуть - тяжело, недостаточный уровень знаний и умений.
RPGman
> живу в линухе
Я его стороной обхожу, но кроссплатформерность не самая большая проблема.
> за глаза хватает Love2d. Там и графика с шойдерами (вдруг приспичит), и звук с физикой
Дебагер луа нормально цепляется? Пока не смотрел, но склоняюсь к написанию велосипеда.
> Tiled
Инструментарий мне видится неотъемлемым от игры. Один и тот же код рисует и игру и редактор.
> "Луа - язык костылей"? :)
Да, в той теме я развернул тему, в принципе.
Sohei
> Надо делать какой-то эпсилон и научится предвидеть землю, чтобы нажатую не
> вовремя кнопку засчитывало и исполняло.
Да, это так. Когда я делал "Ловкого Лорда", там было две помогалки прыжку.
1. Если игрок нажал кнопку прыжка слишком рано, он всё равно сможет прыгнуть, когда долетит до земли. Флаг о нажатии хранился три-четыре кадра.
2. Если игрок нажал кнопку прыжка слишком поздно, он тоже сможет прыгнуть. Например, он бежит и начинает падать с обрыва. Нажимает прыжок уже в падении, но всё равно прыгает: флаг о том, что игрок касается земли хранился два-три кадра.
С этой системой игралось гораздо комфортнее: никто не падал с обрыва по ошибке, и никто не получал несрабатывание прыжка если нажал его немного раньше приземления.
Сама же система для игрока абсолютно незаметна: он о ней и не знает.
RPGman
> Будет много ненужных поначалу телодвижений
Зато будет меньше ненужных телодвижений в середине и конце :)
Я предлагаю делать не прототип, а игру.
p.s. Здесь не нужно сложный движок сочинять. Телодвижений не так уж много, как кажется.
Incvisitor
// вышел из бана
Поздравляю ))
// выкатить демку Инквизитора
Мне понравилась твоя работа.
RPGman
Я не против использования Tiled на первых порах, но позже, думаю, всё равно придём к собственному редактору.
Ведь будет хотеться, чтобы редактор отражал всё также, как это будет в игре (чтобы сразу анимация игралась, шейдера использовались и т.д.)
С редактором, использующим единый код с игрой, тут ничего не сравнится.
По поводу Love: я его покручу малость для расширения кругозора, но предлагаю сразу от него отказаться.
Нам от движка не так уж много функционала нужно, но зато он будет свой и без "фатального недостатка" (обычно этим выражением иронизируют, но на самом деле это весьма важный момент).
> Релизный код пилить с самого начала - неблагодарное дело
Понятное дело, что код будет развиваться эволюционно, но и в мусорное ведро строчить не охота.
RPGman
> Но не писать же заново окошки, и т.д.?
Это не самая большая проблема для людей, которые собрались такой проект тянуть :)
Если энтузиазма не хватит даже на это, то, видимо, явно что-то не так изначально.
Быстрый видимый результат бывает только в начале проекта. Настоящее испытание энтузиазма — это когда начнётся тюнинг.
А написать вывод спрайта в окошке и обработку инпута — это цветочки :)
RPGman
> Ты хоть не против SDL?
Нет, не против. Обёртки в первом топорном приближении тогда беру на себя. На OpenGL придётся, я полагаю. Тебе только нативное окошко под линь переписить надо будет :)
Ты, кстати, сам вкручивал когда-нибудь lua в C++ проект? tolua++ или luabind?
RPGman
У Love, кстати, уж что-то совсем тонкая С++ часть.
Мне привычнее, когда сценграф и его обход происходит в крестах, а Lua оперирует уже нодами этого графа.
> нельзя влобно протаскивать классы, и особенно нельзя делать геттеры/сеттеры полей
Чё это вдруг? Опыт подсказывает, что ещё как можно. И никаких проблем с быстродействием на таблетках и телефонах.
Что-то ты мне тут шаблон порвал: такими вещами заморачивался, а предмет первой необходимости — дебагер — не используешь о_О
RPGman
> А лавинообразный рост обращений туда-сюда между хостом и vm
Дык, я ж говорю, что на практике никаких тормозов в этом месте обнаружено не было.
Если и были узкие места, то это алгоритмы, полностью реализованные в lua (в паре случаев просто вытаскивали этот алгоритм целиком в С++).
И раз уж мы говорим про лавину, разве подход с тонкой С++ частью, где каждый вызов Draw — это vm <--> host, не брутальнее по количеству дёргания туда-сюда?
Incvisitor
Инк, ты с нами вообще? Ты где?
RPGman
Мне кажется, ты драматизируешь. Это какая-то преждевременная оптимизация прям. В действительности всё очень шустро работает.
> минимум переписываний при экспериментах и активный поиск/пробы разных вариантов
Ну, можно экспериментировать и с С++ частью. В любом случае, сначала в lua протянем тонкую прослойку, а толстая появится позже (если появится вообще).
Можно будет даже поэкспериментировать на предмет того, где удачнее творить основной "жир": в крестах или луашечке.
Тема в архиве.
