MGDS Studio

просто я вот люблю такими техническими моментами заниматься, но знаю , что это лучше оставлять на потом, ближе к бета-версии. Иначе я могу потратить (ладно, с удовольствием провести) кучу времени, а игра так и не выйдет из-за совсем других причин. Критичные проблемы типа < 18 FPS конечно лучше решать сразу, но лишь потому , что это усложняет адекватное тестирование.

А что за адовые проблемы с опттмизацией под ПК еще не готовой игры?

Почему в одном хит-параде и книги, непривязанные к какому-то конкретному инструментарию, а также книги, жестко завязаные на определенный софт? Все вперемешку. Если про инструментарий - то тут все очень субьективно. Если в общем про геймдев, то почему нет книг Game Development Patterns? Game Engine Architecture? Real Time Rendering? Book of shaders?

Предложение действует для всех, вкладывающую душу?

Я честно немного не на тот вопрос отвечал или не тому юзеру коммент отослал. Я говорил про метод реализации полного сохранения как симуляции игры от последнего чекпоинта без рендеринга.

Но раз уж про реплей заговорили, то я вижу лишь две возможные проблемы:
1) Идея с реплеем появилась уже после того, как архитектура игры скомпоновалась и работает. Это задница.
2) Нет доступа к исходникам физического движка и движка анимации. А ни тот ни другой не позволяет симулировать временной шаг с отрицательным знаком.

По поводу рандома - это вообще не проблема. Я вот в своей игре видя теоретическую возможность мультиплеера в будущем в начале каждого уровня генерирую массив рандомных чисел и когда мне в игре потребуются рандомоные числа - я их забираю оттуда по очереди, а не генерирую по необходимости. Они точно также могут быть сохранены на диск или отправлены всем игрокам в мультиплеере.

По поводу Вашего предложения по системе управления - да именно так и надо делать управление. Управление на низком уровне - это экземпляр класса команда, где есть:

1) идентификатор персонажа, которым управляем,
2) клавиша
3) состояние клавиши (нажата или отпущена)
4) Временная метка.

Между игроком и НПС разница лишь в том, что первый генерирует эти команды контроллером клавиатуры, а второй искуственным интелектом. Ваши поиски путей - это более высокий уровень и эти данные не стоит сохранять - они рассчитываются. Если ИИ генерирует команды без учета рандома - то и их можно не сохранять - они воспроизводимы. Т.е. поиск путей ищет ключевые точки пути, контроллер управления НПС считает, какие клавиши нужно нажать, чтобы двигаться по нужным траекториям и создает нужные команды. И Вы сразу решите проблему - как управлять персонажами в массовых кат сценах - отключаем опрос клавиатуры и ИИ у мобов и с нужными таймингами рассылаем сохраненные на диск команды управления.
Также вы решите проблему воспроизведения сложных багов - тестер может сохранить все команды, которые были сгенерированы перед падением игры и массив рандомных чисел, сгенерированный им в начале игровой сессии, а Вы воспроизведете их у себя на компе с включенным отладчиком и отключенной клавиатурой.

Те проблемы, которые Вы переоцениваете, не кажуться столь чудовищьными, если ознакомиться с книгой Game development patterns от Robert Nystrom (есть не только на вражеском).

Так а если сохранять с самой последней кат сцены не состояние, а набор команд пользовательского ввода игрока и команд управления противниками искуственным интелектом (с временными метками конечно) и при загрузке все это проиграть, но без рендеринга на экран? Получишь то же самое состояние и даже после загрузки сможешь отмотать время вспять. И загрузки там были не быстрые - полагаю игра проигрывала в офлайне игру до чекпоинта и от кат сцены

За красоту не переживается не разу

Когда игра от одного разработчика, не программиста - стало быть нас ждет игра с нулевыми геймплейными особенностями. Чем нас должна зацепить игра кроме атмосферы, трейлер которой мы будем так терпеливо ждать до
конца года?

Я просто с HTML не знаком, я подключал Yandex Ads SDK для своей Java игры на Android. Но там то мне было все знакомо, разве что SDK на Kotlin. А тут я всерьез подумал запилить порт под HTML и боюсь не разобраться, не имея опыта с HTML и тем, как LibGDX портирует проекты под HTML

Расшифрую, программисты любят пилить игры, потому что они имеют полный доступ ко всех архитектуре игры - а не только к высокоуровневыми скриптам. Как раз хотел задать вопрос в тему (сам считаю себя Java-разработчиком, хоть и не по профессии, а по призванию) - почему не выбрали JME3 или на крайний (самый крайний) случай LibGDX? Просто любопытно

Я выскажу свое мнение - я считаю Ваш вывод неверный. Цитата:

"Начните создавать инфополе вокруг своей игры, как только вам будет что показать. Общайтесь со своей аудиторией и блоггерами, прислушивайтесь к их мнению, заказывайте рекламу (если есть такая возможность)"

Это работает, когда Вы крупная студия и за Вами следят и так комьюнити, ибо оно у Вас есть, благодаря прошлым успешным и характерным играм или издателю. Это сработало у Yacht Club Games с их Shovel Knight, потому что у них было комьюнити, собранное на KickStarted и оно следило за игрой (и за своими вложенными деньгами). И оно готово было ждать 9 месяцев релиза.
НО! Когда Вы соло индюшатник/индюшка, тут все работает по другому. Если Вы начнете выкладывать Ваши первые скриншоты и гемплейные ролики - они должны быть просто безупречны, иначе никто не будет ждать несколько лет выхода Вашей игры - есть куча других проектов, на которые можно обратить внимание и забыть Вашу игру. Это не новый The Elder Scrolls, который люди будут ждать, отрывая листики календаря. Это наоборот - игра, в которую могут погонять туда-сюда, пока ждут тот самый новый The Elder Scrolls. Это игра, которую будут держать в памяти минут двадцать после просмотра скриншотов, и если у Вас нет странички с готовой демкой и кнопкой "добавить в вишлист" - вся Ваша маркетинговая политика будет тратой времени - к релизу ждунов не останется. С соло-индюшатней подход такой - делаем игру и релизим вместе с демкой и тут же все силы в маркетинг, реклама, блоггеры, комьюнити и прочее. Я бы лучше сперва выложил бесплатно игру с парой уровней на Android платформу, чтобы собрать баги и дизлайки, исправить их и полную версию зарелизил бы уже на Desktop за денежку и не отвлекался бы на фиксы багов - только маркетинг, пока игра в топах. Помните - то время, которое Вы бы потратили на маркетинг еще не готовой игры - Вы отобрали у процесса разработки этой игры.

Я вот смотрю на Ваш геймплей и вообще ни разу не вспоминаю ни один Соулс. Я вспоминаю первый Quake - готические замки, стрельба, там еще были рыцари в огромных доспехах. Поиграйте в классику, очень рекомендую. Только там геймплей пободрее - раз в пять. Так и скажите - сделали Quake для тех, кто на геймпаде играет.

А в чем Соулс лайк то? Соулс лайк это не про готические замки, это про геймплей и интересную боевую систему

Не слишком ли круто программиста C++ на индюшатню пускать? Вы там что-ли на голом Direct X движок пишите? Или это Вы так завуалировали разработчика на Unreal Engine?

А Вы уверены что при 2D игре спрайт разбивается на два треугольника и вершинный шейдер вызывается шесть раз и спрайт рендерится по треугольникам? Разве вершинный шейдер не должен вызываться четыре раза а спрайт выводиться сразу всем прямоугольником? Как GPU выбирает, по какой диагонали разбить прямоугольный спрайт на два треугольника?

... громко сказано "пилит" - собирает из кусков имелось ввиду

Запросто могу себе представить опездуха из десятого В, который на фоне не скорого ЕГЭ пилит выживач в своей родной школе с зомби-учителями.

Про конкурс расскажите. Какие требования к игре были. Меня поражает до сих пор, что подобные конкурсы не требуют например использования лишь отечественных движков. Видимо игры должны быть посвящены российской тематике/истории

'''
до этого работавших только в игровом движке поначалу было сложно осознать всю комплексность такой сущности как видеоигра и сложность её создания.
'''
Поясните эту цитату. Как Вы теперь делаете игры? На голом DirectX ? Сменили движок? Используете фреймворк для разработки игр?

Это тот самый жанр, который можно охарактеризовать как "мы не нашли программиста"?

пожалуй, останусь на VK Play и Itch

а язык то программирования какой?

Как там подключать рекламное API в двух словах? Свой предыдущий проект я делал на Java и релизил на Android, потому у Яндекса взял их рекламный API, который нативно встал в мой Java-проект (API на Котлин , что по сути = Javа). А как с Яндекс играми? У них свои обертки для своей библиотеки? Плагины для игровых движков? Или только библиотека - подключай как хочешь?

я про ядро на C++

'''Если вам показалось, что данный движок больше ориентирован на C# разработку, нежели на C++, то вы ошибаетесь. Напротив, ядро движка реализовано на С++, что позволяет соответствующим разработчикам использовать его API напрямую..'''

А бывает иначе в коммерческих движках?

А негры-трансгендеры будут?

Прихожу к выводу, что люди, учавствующие в джемах, не любят делать игры. Если бы любили - делали игры, которые им интересны, и получались бы интересные продукты, которые наверняка нашли бы свою публику, а не пытались бы склепать говно под выбранную тему на простых механиках с надеждой, что их скоровысратое говно выстрелит.

Даже в Яндексе такие схемы. Правда на позицию инженера-конструктора.

Для меня геймджемы - это как олимпиады по программированию. Для близких звучит гордо, а тебя приучают писать говнокод, тяп-ляп, но лишь бы хоть как то работало. Ересь, которая не пройдет ни одно код-ревью и низачто и никогда не пойдет в продакшен. Поэтому единственная ценность - это когда они проводяться очно, и ты погружаешься в эту атмосферу, находишь новых друзей, единомышленников, будущих коллег для твоей гениальных инди-проектов, бабу в конце-концов и понимаешь, что ты не один такой - сидишь по вечерам и расставляешь коллайдеры с идиотской улыбкой, вместо того, чтобы выйти погулять.

Там законодательство мудреное у них, какие-то хитрые бумаги нужно иметь. Помоему в этом плане лучше Tap-tap. Они вроде игнорируют их, но я не помню точно.