Gyre! [2D rlg/trpg]

Форум для проектов, находящихся на стадии Альфа и Бета. В них ещё не реализована вся задуманная автором функциональность, а значит идёт активная разработка.

Модераторы: Sanja, Максим Кич

Venom
Сообщения: 51
Зарегистрирован: 05 апр 2011, 21:44

Gyre! [2D rlg/trpg]

Сообщение Venom » 07 янв 2014, 22:28

День добрый.

Пришел я за советом мудрым, ну и создать бложик для самоконтроля и самоотчетности.
Вводные к вопросу:
Пишу игру. Почти рогалик, отчего и здесь.
Профессия моя связана с IT и кодингом, но не с геймдевом; отчего необходимы советы - преимущественно практические, о реализации тех или иных вещей в архитектуре и, надеюсь, в дальнейшем об организации правильного UX.
24yo, бородат и женат, если это кому-нибудь важно.

Набросал на праздниках немного кода, язык - C++, графика (всё в 2D) - SDL2, конфиги в JSON, дата, предположительно, будет тоже.
Брать готовое решение - Юнити, ГМ, Анархию - не рассматриваю, это убивает мой фан.
Брать другой язык или другие инструменты - готов выслушать обоснованные советы. Если С++ и SDL2 для меня в целом привычны и их возможности я представляю хорошо, то JSON был выбран в общем-то в слепую.

Вопрос 1 [Архитектура рендера]
Есть вот такая схемка - нарисовал для упрощения коммуникации, не UML-compliant, сам знаю. Если принципиально или не понятна суть вопроса - могу нарисовать всё в UML, np.
Изображение
Суть происходящего, по задумке: GameSession владеет всеми менеджерами - мир, объекты, актёры, скрипты, ui. Всё, что должно рисовать себя на экране - наследуется от Renderable и умеет возращать RenderDescription. Внутрях у ней неонка айдишник текстуры (возможно указатель на текстуру, нужны тесты) и информация о том, куда это рисовать. Текстурами владеет система менеджмента ресурсов, внутреннее устройство которой сейчас не обсуждается - BigBlackBox на схеме. Рендерер каждый кадр просит у GameSession все заказы на рендер, GameSession (через систему подписок) собирает их с объектов и отдаёт обратно. Рендерер просит у менеджера ресурсов нужные текстуры (тут простор для оптимизации, подозреваю - обилие однотипных текстур на экране, тайлов, спрайтов, етс), сортирует RenderDescription в нужном порядке, рисует.
Вопрос - взлетит? Прототип набросал, попробовал, очень удобно в работе, соответствует духу ООП. Кто тут более опытный - тыкните носом в слабые места, будьте добры. Волнуюсь за производительность, но с другой стороны - не BF4 пишу же, неужели на современном железе нельзя будет в лоб рисовать и не проседать по производительности?

Вопрос 2 [POD]
Друзья мои, кто как хранит дату? Пока что выбрал JSON, но сильно к нему не успел привязаться. Выслушаю советов мудрых.

Вопрос 3 [Проблемы с видимостью для игрока]
Проще всего проиллюстрировать на скриншоте:
Изображение
За объектами игроку не видны персонажи. Дорога в правой части не видна за домом.
Эта же проблема в UFO:Defense: инопланетянин на втором этаже? На третьем? Чтобы его увидеть сквозь дырку в полу нужно сделать шаг вперед или два? В нём же был костыль - счетчик видимых команде противников.
У меня в концепте действие завязано на тактике в ограниченом пространстве: представьте колонию из Aliens. Участок земли, обнесенный забором, снаружи пустота, внутри три-пять больших зданий, с обилием входов, шахт вентиляции, окон, етс. Можно, разумеется, фичекатом свести все к одному этажу, но тогда рушится основная задумка.
Если кто-то заподорил дурное - да, MurderRL возращается.
Предполагется, что у игрока будет общий для нексольких персонажей FOV, и персонажи могут находиться на разных этажах. Что делать, господа?
Счётчик видимых объектов - костыль прямиком из 90х. Переходить в 3d - платить за модели и текстуры при наличии живого теплого бесплатного художника под боком. Алсо, в 2d - ламповость.

Уточнение правил: если я пишу что-то похожее на рогалик, мне можно вести тут уютный тред? Показать пока что нечего - могу приложить скриншот с тестовыми спрайтами на тестовом фоне, разве что.
Я здесь (преимущественно в r/o) где-то с 2011, первое что помню - MotherloadRL и свой первый 7drl, нагло прерванный личной жизнью, так что думаю, впишусь в атмосферу.
Англоязычное комьюнити погрязло в success story и портах на андроид, геймдев стал филиалом одной известной борды, так что встречайте бездомного.

Best regards, EM
Последний раз редактировалось Venom 03 фев 2014, 07:16, всего редактировалось 3 раза.

Аватара пользователя
Xecutor
Мастер
Сообщения: 758
Зарегистрирован: 25 мар 2008, 08:32

Re: Yet Another Костылей Тред

Сообщение Xecutor » 08 янв 2014, 04:11

Welcome! :)

1. Вполне взлетит. Надо только еще разобраться с анимацией, если таковая вообще планируется.
У меня были понятия фоновой и блокирующей анимации.
Опять же, в SDL2 ведь можно рендерить с помощью OpenGL.
И тут простенькое 2D даже на старом GMA950 загрузит проц максимум процентов на 10 при 50 fps.
С++, если ты им нормально владеешь, самый надёжный и портабельный вариант.
Надо только сразу решить вопрос memory management-а, что б потом не было мучительно больно.
ref counting ИМХО оптимален, особенно если не использовать многопоточность.

2. Я использовал code driven подход. Не очень понравилось.
С другой стороны data driven тоже имеет ряд своих недостатков.
По идее чем-то вроде золотой середины был бы lua.
Но тут надо не скатиться в написание половины кода на нём.
Ибо это будет печально.

3. Хм. Если вопрос только в рассчёте fov, то есть несколько вариантов.
Самый простой - для каждого твоего перса считать плоский fov на каждом этаже,
если точка на этом этаже над/под ним не заблокирована. Плюс пост процессинг.
Честный 3d fov заманаешься реализовывать. Хотя теоретически возможно.

Аватара пользователя
Максим Кич
Администратор
Сообщения: 1642
Зарегистрирован: 03 дек 2006, 20:17
Откуда: Витебск, Беларусь
Контактная информация:

Re: Yet Another Костылей Тред

Сообщение Максим Кич » 08 янв 2014, 10:16

Venom писал(а): Вопрос 1 [Архитектура рендера]
В общем — выглядит разумно, но схема слишком общая, чтобы разглядеть Дьявола, кроющегося в деталях.
Venom писал(а): Вопрос 2 [POD]
Пока что выбрал JSON, но сильно к нему не успел привязаться. Выслушаю советов мудрых.
Lua, как мне кажется, лучше подойдёт. Я очень люблю JSON, но я пишу на JS. Последний мой опыт прикручивания JSON к чему-то строго-типизированному был, как бы мягче сказать, травматичен.
Venom писал(а): Вопрос 3 [Проблемы с видимостью для игрока]
Предполагется, что у игрока будет общий для нексольких персонажей FOV, и персонажи могут находиться на разных этажах. Что делать, господа?
Вижу навскидку несколько вариантов:
1. Чэстный просчёт видимости в 3d — алгоритмов на эту тему полно. Карта квантованная, должно быть вполне подъёмной задачей.
2. Нечэстный просчёт видимости в псевно3d. Идея навскидку такая — считаем видимость в 2d плюс костыли для дырок в полу и потолке. Например, персонаж видит клетку внизу/вверху, если стоит непосредственно рядом с дырой, плюс ещё пара костылей.
3. Почти бесчэстный вариант в 3d — считаем видимость в 2d, если есть дыра вверх-вниз — кидаем брезенхема через стартовую точку+дыру. Но я понятия не имею, как это будет работать с открытыми пространствами.

Так что лучше воскурить алгоритмы, применяемые в воксельной графике, имхо. Правда, тут есть ещё один момент: POV игрока не совпадает ни с одним из POV персонажей.
Venom писал(а): Уточнение правил: если я пишу что-то похожее на рогалик, мне можно вести тут уютный тред? Показать пока что нечего - могу приложить скриншот с тестовыми спрайтами на тестовом фоне, разве что.
«Что-то» показать — это «мастерский» норматив на личный раздел форума с правами модерации. Тему в разделе разработки можно вести при любом состоянии проекта. Лучше, правда, озаглавить её чуть более вменяемо (это можно сделать, отредактировав стартовое сообщение, если хочешь продолжать писать прямо тут). Думаю, с «похожестью» на рогалик проблем и возражений не будет.
Dump the screen? [y/n]

Venom
Сообщения: 51
Зарегистрирован: 05 апр 2011, 21:44

Re: Yet Another Костылей Тред

Сообщение Venom » 08 янв 2014, 10:57

Максим Кич писал(а): В общем — выглядит разумно, но схема слишком общая, чтобы разглядеть Дьявола, кроющегося в деталях.
Пока что всё на такой стадии разработки, что не до деталей. Очевидно, что мелкие проблемы всё равно не поймать до конца реализации. Если двум человекам схема не показалась критично сломаной - это уже неплохо.
Xecutor писал(а): Надо только еще разобраться с анимацией, если таковая вообще планируется.
У меня были понятия фоновой и блокирующей анимации.
Опять же, в SDL2 ведь можно рендерить с помощью OpenGL.
И тут простенькое 2D даже на старом GMA950 загрузит проц максимум процентов на 10 при 50 fps.
С++, если ты им нормально владеешь, самый надёжный и портабельный вариант.
Надо только сразу решить вопрос memory management-а, что б потом не было мучительно больно.
ref counting ИМХО оптимален, особенно если не использовать многопоточность.
Обильной сложной анимации не предполагается, то, что есть в текущую систему вписывается. Сейчас расширю PoC, покручу еще немного, что называется, в руках.
Рендерером by default SDL2 успешно рисует на моем дохлом ноуте по 10к 200х200 спрайтов на кадр без преобразований. Только что проверил. Думаю, это можно считать успешным результатом. Подозреваю, что через OpenGL он их и рисует.
Уровень владения - мид, но очень ржавый. С 2011 я занимался многими вещами - от предвыборных кампаний до сейлза, но не кодингом.
О памяти подумал, сейчас прорабатываю на всё том же уровне - PoC - внутренности менеджера.
Xecutor писал(а): 2. Я использовал code driven подход. Не очень понравилось.
С другой стороны data driven тоже имеет ряд своих недостатков.
По идее чем-то вроде золотой середины был бы lua.
Но тут надо не скатиться в написание половины кода на нём.
Ибо это будет печально.
Максим Кич писал(а): Lua, как мне кажется, лучше подойдёт. Я очень люблю JSON, но я пишу на JS. Последний мой опыт прикручивания JSON к чему-то строго-типизированному был, как бы мягче сказать, травматичен.
Полностью code driven - это ужасающее чудовище в разработке. Связку (Lua + C++) встречал на работе, ощущения ниже среднего. Наш архитектор не умел его готовить, или всё-таки не всё так хорошо и удобно, как расписывает хабра?
Алсо, ужасающая производительность Lua поменялась за последние пару лет?
Алсо, в чём проблема прикручивания JSON к строго-типизированным языкам? Пока что парсер вполне успешно распихивает по нужным переменным прочитанные из файла значения. Если видит что-то непонятное - пишет в лог. В условиях большой команды - мистайпы и ошибки замучат, но для пары человек должно быть норм, нет? Да и в целом это типичная для внешних конфигов проблема - проверять каждый миллиметр, полученный "из вне".
Xecutor писал(а): 3. Хм. Если вопрос только в рассчёте fov, то есть несколько вариантов.
Самый простой - для каждого твоего перса считать плоский fov на каждом этаже,
если точка на этом этаже над/под ним не заблокирована. Плюс пост процессинг.
Честный 3d fov заманаешься реализовывать. Хотя теоретически возможно.
Максим Кич писал(а): Вижу навскидку несколько вариантов:
1. Чэстный просчёт видимости в 3d — алгоритмов на эту тему полно. Карта квантованная, должно быть вполне подъёмной задачей.
2. Нечэстный просчёт видимости в псевно3d. Идея навскидку такая — считаем видимость в 2d плюс костыли для дырок в полу и потолке. Например, персонаж видит клетку внизу/вверху, если стоит непосредственно рядом с дырой, плюс ещё пара костылей.
3. Почти бесчэстный вариант в 3d — считаем видимость в 2d, если есть дыра вверх-вниз — кидаем брезенхема через стартовую точку+дыру. Но я понятия не имею, как это будет работать с открытыми пространствами.
Так что лучше воскурить алгоритмы, применяемые в воксельной графике, имхо. Правда, тут есть ещё один момент: POV игрока не совпадает ни с одним из POV персонажей.
Расчет фов, собственно, только часть вопроса. Есть еще вопрос о UX - как это подать игроку? Подсвечивать скрытые за предметами от игрока, но не от персонажа объекты контуром? Делать предметы прозрачными или обрезать? Ввести мигающий счетчик видимых противников, как в старых играх?
Фов, пока что, просто посчитаю в лоб как 2d и подопру костылями. Открытых пространств много не нужно, так что в основном нужно решать проблему фов в коридорах\комнатах.
Максим Кич писал(а): «Что-то» показать — это «мастерский» норматив на личный раздел форума с правами модерации. Тему в разделе разработки можно вести при любом состоянии проекта. Лучше, правда, озаглавить её чуть более вменяемо (это можно сделать, отредактировав стартовое сообщение, если хочешь продолжать писать прямо тут). Думаю, с «похожестью» на рогалик проблем и возражений не будет.
Ок. Ограниченая модерка мне не нужна, тему сейчас переименую.

Аватара пользователя
Xecutor
Мастер
Сообщения: 758
Зарегистрирован: 25 мар 2008, 08:32

Re: Yet Another Костылей Тред

Сообщение Xecutor » 08 янв 2014, 11:45

Venom писал(а): Полностью code driven - это ужасающее чудовище в разработке. Связку (Lua + C++) встречал на работе, ощущения ниже среднего. Наш архитектор не умел его готовить, или всё-таки не всё так хорошо и удобно, как расписывает хабра?
Алсо, ужасающая производительность Lua поменялась за последние пару лет?
Алсо, в чём проблема прикручивания JSON к строго-типизированным языкам? Пока что парсер вполне успешно распихивает по нужным переменным прочитанные из файла значения. Если видит что-то непонятное - пишет в лог. В условиях большой команды - мистайпы и ошибки замучат, но для пары человек должно быть норм, нет? Да и в целом это типичная для внешних конфигов проблема - проверять каждый миллиметр, полученный "из вне".
Lua один из самых быстрых динамически типизированных языков. Особенно если не забывать писать local :)
А если нужна мегаскорость, то luajit местами уделывает С++ код сгенерёный без термоядерной оптимизации.
Для C++11 есть очень даже клёвые обёртки.
Главная проблема lua - отсутствие (из-за идеологической сложности) "правильного" редактора.

А по поводу lua vs json - если ты собираешься задавать игровые данные внешним образом, то скорее
всего, рано или поздно, тебе захочется добавить туда какие-то формулы, простенькие взаимодействия...
Если формулы и взаимодействия держать строго в коде, а в json это всё выражать флагами, то получится развесистая клюква.
Venom писал(а): Расчет фов, собственно, только часть вопроса. Есть еще вопрос о UX - как это подать игроку? Подсвечивать скрытые за предметами от игрока, но не от персонажа объекты контуром? Делать предметы прозрачными или обрезать? Ввести мигающий счетчик видимых противников, как в старых играх?
ИМХО нужно что бы ВСЁ, что видят персы было видно. То бишь стены и потолок, которые закрывают клетки пола которые видит хоть один
перс нужно делать (полу)прозрачными. Силует - мне кажется лажа. Угадай врага по силуэту?

Venom
Сообщения: 51
Зарегистрирован: 05 апр 2011, 21:44

Re: Yet Another Костылей Тред

Сообщение Venom » 08 янв 2014, 13:27

Xecutor писал(а): Lua один из самых быстрых динамически типизированных языков. Особенно если не забывать писать local :)
А если нужна мегаскорость, то luajit местами уделывает С++ код сгенерёный без термоядерной оптимизации.
Для C++11 есть очень даже клёвые обёртки.
Главная проблема lua - отсутствие (из-за идеологической сложности) "правильного" редактора.
Как будто хаброй окатили из ведра. No offense.
Xecutor писал(а): А по поводу lua vs json - если ты собираешься задавать игровые данные внешним образом, то скорее
всего, рано или поздно, тебе захочется добавить туда какие-то формулы, простенькие взаимодействия...
Если формулы и взаимодействия держать строго в коде, а в json это всё выражать флагами, то получится развесистая клюква.
Да, об этом тоже думал. С другой стороны, в текущем проекте очень простая механика, традиционных для рогалика префиксов со скриптами, элементов с обработчиками и уникальных мобов нет, почему взгляд на JSON и упал. Я сразу уточнил в вопросе, бтв - в JSON лежит сериализованый POD. И то, скорее всего, только на время активной фазы разработки - потом засуну, от любопытных глаз подальше, в бинарник.
Так что вопрос скорее не JSON vs скриптовые языки, а JSON vs XML vs YAML vs Самописный_формат.
Xecutor писал(а): ИМХО нужно что бы ВСЁ, что видят персы было видно. То бишь стены и потолок, которые закрывают клетки пола которые видит хоть один
перс нужно делать (полу)прозрачными. Силует - мне кажется лажа. Угадай врага по силуэту?
Месье не помнит эту болезнь кучи старых игр?
Вопрос, собственно, в том, что хочется не заморачиваясь лишний раз сделать обычные прямые тайлы, как во всех рогаликах. Но для игрока это очень неудобно в многоэтажных зданиях - привет, кнопка [UP] и [DOWN] из старого UFO. Никак автоматически эту проблему не решить - кроме, разве что, очень хитрой прозрачностью в полу "окнами" на нижний этаж. Или подсветкой противников. Или еще каким извращением.
На выходных думаю напилить мокапов, покажу, в чем проблема.
В изометрии становится чуть лучше и читабельнее, но всё равно не идеально.

Аватара пользователя
Максим Кич
Администратор
Сообщения: 1642
Зарегистрирован: 03 дек 2006, 20:17
Откуда: Витебск, Беларусь
Контактная информация:

Re: Yet Another Костылей Тред

Сообщение Максим Кич » 08 янв 2014, 13:37

Xecutor писал(а): Главная проблема lua - отсутствие (из-за идеологической сложности) "правильного" редактора.
«Intellij IDEA» неплохо справляется. Прикрутить подсветку синтаксиса для Lua+LuaDOC — уже можно работать. Я два года так жил под Corona SDK и немного love2d.
Venom писал(а): Месье не помнит эту болезнь кучи старых игр?
Вопрос, собственно, в том, что хочется не заморачиваясь лишний раз сделать обычные прямые тайлы, как во всех рогаликах. Но для игрока это очень неудобно в многоэтажных зданиях - привет, кнопка [UP] и [DOWN] из старого UFO. Никак автоматически эту проблему не решить - кроме, разве что, очень хитрой прозрачностью в полу "окнами" на нижний этаж. Или подсветкой противников. Или еще каким извращением.
На выходных думаю напилить мокапов, покажу, в чем проблема.
В изометрии становится чуть лучше и читабельнее, но всё равно не идеально.
Ну тут, простите, «или/или». 2d движок в любом случае не будет отображать 3d карту без потерь. Если хочется прямых тайлов, я бы предложил выводить их на плоскости в 3d пространстве и дальше играть с прозрачностью, масками, плавными переходами и т.д. Может быть что-то получится.
Dump the screen? [y/n]

Аватара пользователя
karagy
Сообщения: 1271
Зарегистрирован: 10 янв 2007, 14:13

Re: Разработка [пока-что-без-имени] рогалика

Сообщение karagy » 08 янв 2014, 14:29

Venom, вы не озвучили самые важные начальные условия. Из-за чего многие ответы вам, возможно, уже даны в ошибочных смысловых контекстах.
Пожалуйста уточните:
1. это будет чистый single-player? multi-player? Или сингл с заделом на миграцию в мультик на будущее?
2. это turn-based? realtime? смешанное? если пахнет хотя-бы частичным риалтаймом - то насколько жесткий биллинг (квантование времени игрового мира)?
Мене важные, но плясать надо сразу от мечталок-хотелок:
3. пользователь обозревает мир в режиме Бога? Т.е. ему видно многое что не видно, например вон тому юниту-стрелку за углом? Или восприятие через сенсорику юнита (группы юнитов)? От этого будет зависеть и FOV, и временная полупрозрачность стен и т.п.

По поводу Lua. Опытному программисту полезно ознакомиться с этим тектом http://notebook.kulchenko.com/programmi ... ugly-parts

Venom
Сообщения: 51
Зарегистрирован: 05 апр 2011, 21:44

Re: Yet Another Костылей Тред

Сообщение Venom » 08 янв 2014, 14:57

Парни, если что, ко мне можно на "ты". Никогда не был ценителем этикета в интернетах.
Максим Кич писал(а): Ну тут, простите, «или/или». 2d движок в любом случае не будет отображать 3d карту без потерь. Если хочется прямых тайлов, я бы предложил выводить их на плоскости в 3d пространстве и дальше играть с прозрачностью, масками, плавными переходами и т.д. Может быть что-то получится.
Ну, тогда поступлю как принято в разработке рогаликов - пожертвую usability. Спасибо за соображения, мысль с плоскостями интересная весьма.
karagy писал(а): Venom, вы не озвучили самые важные начальные условия. Из-за чего многие ответы вам, возможно, уже даны в ошибочных смысловых контекстах.
Пожалуйста уточните:
1. это будет чистый single-player? multi-player? Или сингл с заделом на миграцию в мультик на будущее?
2. это turn-based? realtime? смешанное? если пахнет хотя-бы частичным риалтаймом - то насколько жесткий биллинг (квантование времени игрового мира)?
Мене важные, но плясать надо сразу от мечталок-хотелок:
3. пользователь обозревает мир в режиме Бога? Т.е. ему видно многое что не видно, например вон тому юниту-стрелку за углом? Или восприятие через сенсорику юнита (группы юнитов)? От этого будет зависеть и FOV, и временная полупрозрачность стен и т.п.
Nope, напротив, хайв отлично почувствал мой ход мыслей и дал ответы в тему ^^
1. Сингл, не верю в мультиплеер с саспенсом и погружением.
2. Смешанное. Фаза для всех начинается одновременно, сколько занимает - покажут плейтесты, ориентировочно около трех-пяти секунд. В фазу каждый персонаж производит одно сложное(рывок, сложное взаимодействие с объектом, выбивание двери, выстрел с прицеливанием, перезарядка экзотического оружия) или два (возможно разных) простых действия(два шага, две перезарядки, два выстрела от бедра, два простых действия). Физики нет и не нужна, поэтому требования к стабильности фреймрейта чисто номинальные - не режет глаз, да и ладно. Из этих соображений вместо серьезного чужого рендерера - свой велосипед, если что.
3. Через сенсорику, как и обычно в жанре. Группа юнитов.
karagy писал(а): По поводу Lua. Опытному программисту полезно ознакомиться с этим тектом http://notebook.kulchenko.com/programmi ... ugly-parts
Прочитал, спасибо. Если будет нужда в скриптовом языке - прикручу. Сейчас, даже без фичеката, внешняя логика не нужна. Разве что AI туда вынести, но это отдаёт запахом проблем при невысоком выхлопе.

Аватара пользователя
Xecutor
Мастер
Сообщения: 758
Зарегистрирован: 25 мар 2008, 08:32

Re: Yet Another Костылей Тред

Сообщение Xecutor » 08 янв 2014, 15:18

Venom писал(а):, бтв - в JSON лежит сериализованый POD. И то, скорее всего, только на время активной фазы разработки - потом засуну, от любопытных глаз подальше, в бинарник.
Так что вопрос скорее не JSON vs скриптовые языки, а JSON vs XML vs YAML vs Самописный_формат.
Да проще тогда сразу в коде C++ :)
Массив структурок и вперёд. Всякие разговорчики про время компиляции ИМХО сильно это время преувеличивают.
На современном компе, особенно если компилять без суровой оптимизации, один .cpp файл откомпилируется, а затем бинарник слинкуется, очень быстро.
В цикле "сохранить игру, выйти, отредактировать файл, <пересобрать>, перезапустить, загрузить" <пересобрать> займёт незначительный процент.
Проверил. В толстом проекте поменял .cpp файл. Компиляция и линковка заняли 1.4 секунды. И это корявский mingw с чуждой на винде архитекторой.

Venom
Сообщения: 51
Зарегистрирован: 05 апр 2011, 21:44

Re: Yet Another Костылей Тред

Сообщение Venom » 08 янв 2014, 21:38

Xecutor писал(а): Да проще тогда сразу в коде C++ :)
Массив структурок и вперёд. Всякие разговорчики про время компиляции ИМХО сильно это время преувеличивают.
На современном компе, особенно если компилять без суровой оптимизации, один .cpp файл откомпилируется, а затем бинарник слинкуется, очень быстро.
На сторону темную слова твои влекут меня =)
Xecutor писал(а): В цикле "сохранить игру, выйти, отредактировать файл, <пересобрать>, перезапустить, загрузить" <пересобрать> займёт незначительный процент.
Проверил. В толстом проекте поменял .cpp файл. Компиляция и линковка заняли 1.4 секунды. И это корявский mingw с чуждой на винде архитекторой.
Если не секрет, а что с mingw не так? Сам использую связку mingw + Code::Blocks, отлично всё работает. На работе приходилось использовать компилятор из студии - ощущения значительно хуже. Разве что Unity Build прекрасен.

Алсо, господа, товарищи и коллеги: как вы решаете вопрос с разными разрешениями у пользователя?
Одинаковый internal resolution + scaling? Увеличиваете view?
Как боретесь с размерами GUI? Рисуете под каждое разрешение, Android-style? Используете вектор? К своему стыду, раньше никогда не обращал внимание, да и рогалики графические, честно говоря, не перевариваю, кроме DCSS.
Написал код для радиального меню, обнаружил, что при 640х480 - пользователю не видны выпадающие меню, при разрешениях выше 1980х1260 пользователю вообще ничего не видно, слишком мелко. Масштабировать будет довольно проблематично - придется всё переделать в вектор, но лучше сейчас, чем потом.
Алсо, будет еще character sheet и (возможно) боковое меню со статусами и логом, так что вопрос насущный.
Алсо, бинды или контекстные меню? Кто что предпочитает? В вижне радиальное меню в стиле NWN, кто не видел - могу доставить скриншот.
/r советов мудрых.

Аватара пользователя
Xecutor
Мастер
Сообщения: 758
Зарегистрирован: 25 мар 2008, 08:32

Re: Yet Another Костылей Тред

Сообщение Xecutor » 09 янв 2014, 05:27

Venom писал(а):
Xecutor писал(а): В цикле "сохранить игру, выйти, отредактировать файл, <пересобрать>, перезапустить, загрузить" <пересобрать> займёт незначительный процент.
Проверил. В толстом проекте поменял .cpp файл. Компиляция и линковка заняли 1.4 секунды. И это корявский mingw с чуждой на винде архитекторой.
Если не секрет, а что с mingw не так? Сам использую связку mingw + Code::Blocks, отлично всё работает. На работе приходилось использовать компилятор из студии - ощущения значительно хуже. Разве что Unity Build прекрасен.
Ну у gcc процесс компиляции это запуск тучи подпроцессов с пайпингом данных между ними. На винде это работает тупо медленно.
На существенно более слабом маке у меня один и тот же проект собирается гораздо быстрее чем на винде.
На винде (из command line) студийный компайлер работает шустрее.
Venom писал(а): Алсо, господа, товарищи и коллеги: как вы решаете вопрос с разными разрешениями у пользователя?
Одинаковый internal resolution + scaling? Увеличиваете view?
Как боретесь с размерами GUI? Рисуете под каждое разрешение, Android-style? Используете вектор? К своему стыду, раньше никогда не обращал внимание, да и рогалики графические, честно говоря, не перевариваю, кроме DCSS.
Написал код для радиального меню, обнаружил, что при 640х480 - пользователю не видны выпадающие меню, при разрешениях выше 1980х1260 пользователю вообще ничего не видно, слишком мелко. Масштабировать будет довольно проблематично - придется всё переделать в вектор, но лучше сейчас, чем потом.
Алсо, будет еще character sheet и (возможно) боковое меню со статусами и логом, так что вопрос насущный.
Алсо, бинды или контекстные меню? Кто что предпочитает? В вижне радиальное меню в стиле NWN, кто не видел - могу доставить скриншот.
/r советов мудрых.
ИМХО
1) Дать возможность рулить размером фонта UI
2) Скэйлить UI исходя из размера фонта
3) Эксперементально найти минимальную резу куда всё влазит, и поставить пользователя перед фактом, что с меньшей резой не работает :)

Меню... Тут на вкус и цвет. ИМХО надо исходить из функциональных требований. Если игра преимущественно mouse driven, то радиальное по идее должно быть в тему. Но не пощупав тяжело оценивать.

Venom
Сообщения: 51
Зарегистрирован: 05 апр 2011, 21:44

Re: Yet Another Костылей Тред

Сообщение Venom » 09 янв 2014, 06:52

Xecutor писал(а): Ну у gcc процесс компиляции это запуск тучи подпроцессов с пайпингом данных между ними. На винде это работает тупо медленно.
На существенно более слабом маке у меня один и тот же проект собирается гораздо быстрее чем на винде.
На винде (из command line) студийный компайлер работает шустрее.
Еще бы студийный компилятор использовал стандарт вместо ms-specific c++ и цены бы ему не было. Флаги, знаю, но проводить эксперименты всегда было лень. Но это вкусовщина, да.
Насчет скорости, бтв - хз, на работе прошлой немаленький такой проект под виндой как-то собирался гнушным компилятором со сравнимой скоростью. Может, там какие костыли есть? Я в сборку не лез, у нас отдельная шобла занималась её поддержкой и кодогенераторами.
Xecutor писал(а): ИМХО
1) Дать возможность рулить размером фонта UI
2) Скэйлить UI исходя из размера фонта
3) Эксперементально найти минимальную резу куда всё влазит, и поставить пользователя перед фактом, что с меньшей резой не работает :)
Меню... Тут на вкус и цвет. ИМХО надо исходить из функциональных требований. Если игра преимущественно mouse driven, то радиальное по идее должно быть в тему. Но не пощупав тяжело оценивать.
"Здравствуйте, %user_name%! Выберите желаемый размер шрифтов для каждого из 82 меню перед началом игры!"
jk. Хотя я помню, как на /agdg закидывали добром разработчика, у которого gui не влазил в экраны меньше, чем 1280x1024. "Это фича."
Мне не принципиально, mouse-driven или клавиатура. В более завершенной фазе будет ясно, какой из режимов выкинуть, наверно. Вопрос, скорее, к UX относящийся - что психологически легче, список биндов или тяжелый gui?

Алсо, коллеги, тут кто-нибудь кроме меня рендерит весь этаж в огромную текстуру? Как в Alien Shooter было реализовано, если кто помнит. Или все рисуют каждый фрейм tile-by-tile?
Мега-текстура жрёт лишнюю память, да, но чёрт возьми, 2014 год! Алсо, не нужно лишний раз дергать тайлы - только если игрок что-то из стен порушил, что скорее внеплановая ситуация, и то - отрендерил сверху заплатку, и всё готово.
Авторов рогаликов с псевдобесшовным миром просьба не беспокиться =)

Аватара пользователя
kipar
Сообщения: 2120
Зарегистрирован: 10 мар 2010, 13:16
Откуда: Москва

Re: Разработка [пока-что-без-имени] рогалика

Сообщение kipar » 09 янв 2014, 08:09

Venom писал(а):Алсо, коллеги, тут кто-нибудь кроме меня рендерит весь этаж в огромную текстуру? Как в Alien Shooter было реализовано, если кто помнит. Или все рисуют каждый фрейм tile-by-tile?Мега-текстура жрёт лишнюю память, да, но чёрт возьми, 2014 год!
Именно что 2014. Как ни рисуй, 2д игра все равно тормозить не будет.

Venom
Сообщения: 51
Зарегистрирован: 05 апр 2011, 21:44

Re: Разработка [пока-что-без-имени] рогалика

Сообщение Venom » 09 янв 2014, 08:14

kipar писал(а): Именно что 2014. Как ни рисуй, 2д игра все равно тормозить не будет.
Предоставить доказательство обратного? Могу хоть своим кодом, хоть в стиме показать вполне себе успешно релизнутые 2d игры с фреймдропами.

Ответить

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 7 гостей