Бумажное подземелье: Некоторое .EXE
Хотелось бы поделиться со всем Гамином своим действительно огромным прогрессом этой игры, но его нет.
Или есть? Смотрите в <читать дальше>
Лишь какие-то очень технические и не ведомые игроку вещи, вроде генераций подземелий.
Из визуально нового есть очередная GIF, которая ни то баг, ни то фича (классика).
У меня есть целых три версии одной и той же недо-демки. Это не совсем демо-версия, скорее тест на запуск и какие-то прям очень базовые (и по сути все, ха) механики.
Вот эта версия самая простая. Она требует ДХ11, но это не точно — это и желательно проверить.
Вот эта версия уже с шейдером HLSL11, вероятно может стать проблемой для запуска.
А вот эта версия такая же, как и простая, но имеет один дополнительный эффект, который невозможно заметить, но скорее всего нагрузу будет иметь (будет необходим для игры дальше).
Управление такое:
WASD — двигаться по направлению, QE — поворот влево\вправо. F — включить\выключить слежение камеры за курсором. ЛКМ (если курсор в 3д виде) — действие, ПКМ (если курсор в 3д виде) — атака.
Я бы хотел, чтобы каждый игрок сам доходил до каких-то базовых элементов в игре, но для ясности всё же опишу их:
Если drag'n'drop-нуть предмет из инвентаря в 3д вид, то он выбросится из инвентаря в клетку перед игроком.
Сундуки можно уничтожить ударив их, при этом, их содержание будет «выброшено».
По задумке с NPC можно будет взаимодействовать, пока в планах drag-n-drop на них предметов. Но сейчас ничего нет, кроме тестовой фразы, да.
Интересует какие FPS выдаёт каждая из сборок.
Ну и немножечко скриншотов разработки:
Генерирую подземелья методом BSP
Что-то пошло не так и .. или .. не то чем ... ДОМ ВВЕРХ ДНОМ!
Игра лучше левел дизайнер, чем я
(баг. Заключается в том, что подземелье сгенерировалось в комнате, где я руками расставил особые объекты, заменяющие текстуру стен)
Больше особого прогресса и показать нельзя. Все что есть — в ЕХЕ. Да, наверно будут ещё враги, предметы, ну и нужно будет зачистить 100500 этажей подземелья, чтоб в конце ууу-сюжетный-поворот.
Ах да, ещё же будет офигенный трек (лучше, чем игра) от товарища 0int!
- 13 октября 2018, 18:38
- 015
А почему именно фпс, а не время обработки кадра? Ведь между 59 и 60 фпс может быть большая, а может быть маленькая разница.
Там сразу 2 фпс пишется - на котором залочена игра и "реальное".
Не совсем понимаю зачем именно смотреть время обработки кадра т.к. оно как раз обратное к ФПС.
Тогда ок.
Если рассматривать не только целиком, а каждую составляющую кода кадра, то удобнее сравнивать, складывать именно миллисекунды.
ГМС не даёт такую возможность, чтоб граф и каждую часть отдельно сравнивать. В самом IDE ГМС-а конечно есть что-то подобное. Мне кажется, там заранее как-то написано так, что он рисует и обрабатывает ровно столько, сколько указано (по дефолту 30 кадров, но конкретно здесь - 60)
Но ты же берёшь откуда-то фпс, которое ты называешь "реальным"?
Скорее всего, он обрабатывает меньше времени, а остальное время "спит". Вот замеряя это время, мы можем сравнивать разные варианты на производительность (тогда как фпс может быть при этом всегда 60).
Его Гейммекер и даёт. Там две переменных - fps и fps_real. fps не может быть больше установленной скорости шагов в секунду (похоже, что там и условный update и draw идут подряд).
Ну fps в теории и должен быть всего 60, но вот fps_real может быть и 70 и 120 и 300 и основываясь именно на этой цифре можно узнать насколько оно тянет это всё. У меня конкретно всё началось с 200 с чем-то фпс_реальных, затем я добавлял всякие штуки и по итогу теперь пишется то 120, то резко скакнут до 200+ и затем опять 120.
Но при этом просто ФПС всё равно 60 и это хорошо.
Понятно. Странная терминология, если фпс ограничен, ты не сможешь посчитать заодно и кадры в неограниченном режиме. А если не ограничен, то что такое 60? :)
Скорее всего, это обратное среднее время обработки кадра (update + draw).
Да, в ГМС всё странно и наверно термины подменили, но при этом и не соврали. Кадры в секунду отражают именно обработку внутри движка (как раз update+draw) т.е. будет 60 вызовов этих самых draw и update в секунду, но при этом само быстродействие движка это fps_real, условно сколько раз в секунду он отрисовывает саму поверхность вывода (но не саму игру). Не знаю как точно объяснить это, но я частично понимаю что там может быть внутри.
А, вот как. 60 - это количество тиков, а фпс - неограниченное.
Ну выходит что-то вроде этого. Но только если тики указаны в 60, но машина не справляется, то fps и fps_real будут показывать число меньше (и соответственно тиков в секунду меньше?), ну например 40.
Т.е. там всё сложно, но догадаться думаю можно.
Попробовал версию с шейдером, всё норм.
Немного не очевидно, что удар на ПКМ.
Неплохо было бы сделать визуальную подсказку, в виде рисунка компьютерной мышки, на левой кнопке которой нарисована рука, а на правой - меч.
Да, интуитивность управления примерно на уровне 0.
Есть правда кнопки справа на панели управления (как сильно звучит), но там тоже не очень очевидно.
Я про панель справа и говорил.
Можно там сделать чуточку интуитивно понятнее, пририсовав кнопки мыши.
Хм, вчера я был уверен, что ты пишешь про иконки мышки возле курсора! А, ну да, для меня это было поздно вечером. Ох уж этот игрострой!
Да, у меня были мысли что-то с иконками ввода сделать. То ли обучения какие-то делать с текстом (не читают, инфа 100%), либо вот что-то такое, о чём ты пишешь.
У меня 60 выдаёт каждая из сборок.
Во всех трёх у меня 60 fps. В первой в скобках число за 200, во второй 120 с чем-то, в третьей 150-160. Долго не мог понять, как поворачиваться. Ну как долго, секунд 10-20 – всё никак не мог свыкнуться с мыслью, что ни мышка, ни AD тут не помощники. Но вообще я ничего не тестил – просто fps посмотрел, побегав немного.
Отлично! Но думаю в силах ограниченного времени и как бы мне не хотелось сделать свет, HLSL версия похоже пойдёт никуда или в будущее.
Разница между в 200+ и 160 вполне закономерная и итоговая версия будет на основе 160, что всё ещё больше 60 кадров почти в 3 раза. Возможно успеется даже оптимизация.
Да, управление оказывается крайне непонятным, хм. У меня была мысль даже нарисовать "на стенке" картинку-управления прям со старта, но при этом в игре самой.
Просто от такой игры стрейфа не ожидаешь. А тут он прямо на AD. В старых игрушках, где поворачивали ещё не мышкой, а AD, стрейф, если был, то как раз на QE вешался. Но мне кажется, он всё равно там был неудобен и лично мной не использовался (но это вообще сто лет назад было).
Хм, даже и не знал, что раньше наоборот было про AD и QE. Могу ещё добавить управление на стрелочки, чтоб вперёд-назад и повороты (но что наверно будет сбивать с толку, не знаю).
Думаю всё же сделаю как Разери советует, только ещё и кнопки на той панели подпишу.
На стрелочки можно продублировать. Чтобы было удобно тем, кому удобны стрелочки.
Да, но тогда непонятно что именно назначить на стороны - то ли стрейф, то ли поворот. Секции с нумпадами не у всех тоже есть.
Идеально было бы конечно сделать назначение кнопок.
Так что важнее, то и назначить. По-моему, без стрейфа жить можно, а без поворотов не очень. Ну и вообще это только как бонус – всё равно скорее всего у большинства это будет WASD + мышка. Если этот бонус не нужен или сложен в реализации – ну и ну его.
по Ishar стрейф на нумпаде был 4-6, а поворот - 1-3. особый шик был в том, что "вперёд" был как на 8 так и на 5, т.е. была суперпозиция, где можно соблюдать либо нумпадокрестик для стандартного стрейфа, либо транспозиция конструкции WSAD на 1-2-3-5 для поворотов, и с вынесенным на QE ( = 4-6) стрейфом.