Войти
ПрограммированиеФорумОбщее

Проблемы с оценкой возможностей своих и движка, для RTS.

Страницы: 1 2 3 Следующая »
#0
19:05, 12 дек. 2018

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

Я не планировал серьезные графонистые навороты, они мне не интересны, да и объективно - я в них не смогу, но очень хотелось довольно детального просчета некоторых специфичных особенностей юнитов, которые требовали бы достаточно простые операции но в большом количестве.

Помотался я с UE4 и вроде бы все хорошо, но на БП и инклудив нативизации - я уперся в масштабы. Хочется стабильно мочь в 800 юнитов в критическом пике, причем имеющим FoV. Но вот даже при статичном спавне 800 движущихся мешей, уеч (Правда на БП) начинает проседать. Если приделать этим юнитам еще FoV из меша и заставлять каждого из них видеть\развидеть другого - производительность падает до совсем непотребных значений.

Да, если это сделает хороший кодер на ++ скорее всего это будет работать быстрее и в разы. Но все равно будет жрать знатную долю производительности. Очень знатную. А еще ведь ИИ, пачфайндинг и куча куча куча всего другого. Я если это и заморочусь сразу писать в код сделаю это максимум на С с классами и скорее всего плохо.

Собственно задаю вопрос

1) Реально ли достаточно детально просчитывать 800, ну даже хрен с ним 500 юнитов. Т.е. обрабатывать ИИ каждого и с десяток хар-к влияющих на его статы. С тикретом скажем 10? >>Без серьезного кода и лазанья в глубь движка<<
2) Что бы каждый имел FoV
3) Иметь достаточно большие масштабы карты. Скажем 5-10 масштабных км2.

И на чем лучше всего это пытаться? Мне люди посоветовали посмотреть от уеча в сторону юнити, т.к. там будет легче реализовать многопоточность.


#1
20:02, 12 дек. 2018

Разные унреалы это про графон. Про возможности это юнька. Там есть уже ассет для РТС, как раз на последних обновах автор что то около 1000 юнитов добился на билбордах.
Нуи есть шаблоны ртсок, где все готово, но конечно не на такое количество юнитов.
А так, навмешь спокойно обрабатывает по 1500 объектов.

#2
20:10, 12 дек. 2018

sledo
Вопрос больше не в самой возможности кол-ва, я понимаю, что это ограничивает моя криворукость в первую очередь. А в FoV, т.к. скажем функция для RTS, а тем более масштабных, довольно не специфичная.

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

#3
20:39, 12 дек. 2018

Zurab
> Реально ли достаточно детально просчитывать 800, ну даже хрен с ним 500 юнитов.
Зачем? В РТС довольно небольшой лимит юнитов, после которого контролировать все вручную становится слишком сложно, и у тебя, по сути, вместо отдельных юнитов получается просто бесформенный боевой поток.
> Иметь достаточно большие масштабы карты. Скажем 5-10 масштабных км2.
Поле измеряется не в км, а в ячейках

#4
(Правка: 20:54) 20:53, 12 дек. 2018

BingoBongo
>Зачем?
Несколько игроков + несколько не стандарт, так, что такой проблемы возникать не должно, тут я вам как пользователь и ЦА говорю =)

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

#5
21:06, 12 дек. 2018

Под FoV вы что подразумеваете? Угол зрения для каждого юнита?

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

Вы бы поделились ключевыми фичами игры, обрисовали бы что хотите от неё, как то более конструктивно. А мы бы вам сказали сможете ли вы это сделать с вашим уровнем или лучше использовать готовые решения, а может и вообще забить на это дело.
На моём веку полегла со своими идеями маленькая армия начинающих игроделов. А все по тому что их мечты не совпадали с их возможностями.

#6
(Правка: 22:22) 22:13, 12 дек. 2018

sledo
>Угол зрения для каждого юнита?
Именно.

Опыт программирования есть. Правда процедурного, понятно в чем.
Поделится. А черт с ним, все равно ради человечества хотел делать. =)

>Вы бы поделились ключевыми фичами игры, обрисовали бы что хотите от неё, как то более конструктивно

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

Есть задачи - решить проблему зависимости от АПМ, при этом сохранив рилтайм, так как ТБС это другая крайность, устранить возможность выработки универсальных эффективных тактик для общей ситуации, уйти от прямого влияния хар-к юнитов на его эффективность. (ну в разумных пределах).
Вдохновили меня на это серия wargame, там очень хорошо решили 3й пункт, но к сожалению сохранили сильную зависимость от АПМ. Flashpoint Campaigns, там ребята придумали просто революционную на мой взгляд вещь - очередь и цепочку приказов и потенциально дали ответ на то "Как победить АПМ".  Есть еще ребята из Graviteam но долгое отсутствие мультиплеера, проблемы с ИИ и общая нацеленность на сингл отпугнули меня в свое время от их продукта, хотя то, что я знаю о их игре довольно сильно пересекается с моим итоговым концептом, с тем лишь различием, что RTS я вижу как столкновение умов и хитрости нескольких людей, а не одного против ИИ.

И так суть:
1) Общая стилистика игры - современные локальные конфликты, со всеми вытекающими.
2) Максимальные дальность взаимодействия юнитов - километры, но тут ловушка с масштабом . Я к сожалению не пришел к конечному мнению, скорее всего придется выяснять это на концепте, хотелось бы реальных, но может быть пусто и скучно, или тяжело для ПК.
3) Непрямое управление юнитами. Цепочка приказов, игрок - комотд(юнит) - юниты, через имитацию радиоканала. Это режет возможности управления, но открывает кучу других. Как реализовать догадываюсь, даже где то на бумаге блоксхемы с протоколами в псевдокоде.
4) Предыдущий пункт требует наличие очень сильного ИИ. Точнее двух. Личного, для имитации поведения единичного юнита и оперативный, для их тактического взаимодействия.
На самом деле я не вижу проблем реализации таких ИИ на конечном автомате. Вопрос лишь в вычислительных мощностях, которые по большей части уйдут на сбор окружающих данных.
5) Как следствие возможность юнитов взаимодействовать между собой и иметь довольно широкую свободу.
6) Гибкий UI, вдохновлялся Supreme Commander, после него каждый раз задаюсь вопросом "почему вот в этой RTS его нет" и хочется довести его до абсурда.
7) Сам процесс представляет из себя очень ограниченную (не видится, что у игрока за всю партию будет больше 10 единиц БТ и 150 пехотинцев) по ресурсам игру, с локально высокой ценой ошибки и при этом сохраняя возможность отыграться (не вижу противоречия), решение кризисных ситуаций(просрать отделение из 12 человек, в котором вынесли командира или попытаться вытащить рискнув другим, паникующие юниты спамят в канал и тд и тп, вариантов море) и доп миссий возникающих в ходе игры.

Отсюда получаю тех требования.
1) До 8х игроков до 100 юнитов в пике у каждого (с пессимистичным запасом (как игроков так и юнитов))
Тут кстати ловушка в понимании слова юнит, подконтрольных единиц вряд ли будет больше 15-20, а просчитываемых игровых персонажей вполне.
2) Размеры карты 5-10 масштабных КМ.
3) FoV юнитов от ~300 до ~3000 масштабных М. Т.е. да, некоторые юниты должны мочЬ видеть половину довольно большой карты.
4) Иметь запас производительности для возможности каждого юнита собирать, хранить и передавать довольно большой комплекс информации.
5) Иметь запас производительности для возможности каждого юнита просчитывать свои действия в неких рамках свободы.

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

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

PS И да, я в курсе, что скорее всего у меня ничего не получится и не по рту кусок.

#7
22:28, 12 дек. 2018

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

#8
(Правка: 22:36) 22:34, 12 дек. 2018

DemiosFantasimo
Я делал.
Создавал 800 базовых персонажей с треугольным мешем и капсулой коллизии и делал их друг друга видеть\развидеть.
Один способ не тянул и очень сильно, об другой разбил лоб об забытый баг уеча.

Вопрос в том, что мне делать, продолжать пытаться и учится вглубь или лучше пересесть на что то иное, а то и вовсе по умерить запросы.

#9
22:57, 12 дек. 2018

RTS это хардкор, там нужно каждый байт считать.
Готового движка который смог бы в RTS без дикой оптимизации не существует.

#10
8:51, 13 дек. 2018

Zurab
> Вопрос в том, что мне делать, продолжать пытаться и учится вглубь или лучше
> пересесть на что то иное, а то и вовсе по умерить запросы.

Ну тут нужно самому определиться что важнее, сделать игру или сделать игру мечты. В первом варианте приспосабливаться к условиям и идти на уступки, во втором изучать платформы, алгоритмы, набираться опыта, может быть даже изучать языки программирования

#11
9:21, 13 дек. 2018

DemiosFantasimo
Второе тут кто нибудь осилил?
То у меня уже чего только не переделано в процессе, и все равно до мечты далеко:/

А на просто игру , так, по прикидкам месяц надо +- и то больше контент.

#12
9:59, 13 дек. 2018

2) это реализовываться через  масштабирование. Конечно можно и всю планету создать, но вот наполнить её не получится.
3 и все что его затрагивает) Цепочки приказов которые обрабатывает сам ИИ, это уже довольно сложно. Это прямой путь к сложным иерархиям баз данных - для этого надо иметь очень высокий уровень специалиста по разработке. Хотя бы просто выстроить логические цепочки, не то что забить все это в код. Потому это практически ни где не реализованно.
6) гибкий UI понятие растяжимое. Если хочется динамично создавать новые элементы меню, то возвращаемся к предыдущему пункту. В стратегиях я не силён, не особо в курсе как что где.
Если простая настройка, то это довольно просто. Относительно просто.
7) Слишком общий.

В целом мой вердикт что для вас это не просто не по рту кусок, это не реально примерно так же как и построить лайнер типа Титаник в гараже.
Что я рекомендую:
1) это точно не про разные унреалы. Тут слишком много сложных пересекающихся между собой логических решений, все это придётся выстраивать с нуля. А это прямой путь к нативному коду сразу под какую нибудь винду, а не к внутри программным языкам разных движков.
2) Найти человека, матерого такого программиста и застимулировать его на создание движка конкретно под эту игру. Есть такие кодеры которым важно решать архисложные задачи больше чем иметь материальное благо от этого.
3) Конечно можно это все попробовать сделать на Юньке, но боюсь даже он тут не поможет. Максимум можно взять готовые решения и на них отработать основную концепцию, да и только.
Как тут выше верно подметили, степень подготовки специалиста должен быть такой, что он сможет эффективно использовать каждый байт.

#13
10:27, 13 дек. 2018

На юнити этот ваш fov я бы как раз попробовал сделать на свежезавезенном burst, который призван решать проблемы массивных геометрических вычислений.

Рендерить 800 юнитов, ну хз. Какие у вас там требования? Если анимаций не много и не сложных и без затей, то можно запечь анимации в фреймы ценой некоего перерпсхода на память. Зато можно забатчить и рисовать без боли.

На анриле не знаю, но тоже наверняка есть решения (прпвда не на бп).

#14
11:08, 13 дек. 2018

Кстати, как вариант давно обдумывал о такой теории. Делать не все игровые расчеты ИИ на каждый тик а распределять группами по тикам. По идее должно снижать нагрузку а на глаз не должно быть заметно.

Страницы: 1 2 3 Следующая »
ПрограммированиеФорумОбщее