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

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

Страницы: 1 2 3 Следующая »
#15
(Правка: 14:13) 13:49, 13 дек. 2018

Mira
>сделать игру или сделать игру мечты
Вы лукавите, сделать что то или сгореть и не сделать ничего. Что то можно будет постепенно допилить, с ничем ничего и не сделаешь.
>рендер 800
Их не то, что надо рендерить. С этим как раз проблем нет. Вопрос как обсчитывать их поведение и взаимодействие.
>прпвда не на бп
Я и не думаю, ВСЕ это родить на БП. Скорее рожать на БП, зная, что когда это упрется в перфоманс, перенос на ++ решит проблему.

x
Хороший вопрос, изначально сам думал взять 2д.
Но вот из 2д в 3д переехать будет сложно, а из дерьмового 3д в что то лучшее сильно полегче.
Плюс, 3д позволяет переложить много на базовый функционал движка, не заморачиваясь с реализацией. Например? Ну например просчет видимости до цели за холмом, в 3д я кину трассировку, а в 2д мне придется писать ковырять псевдоландшафт и делать свои алгоритмы просчета.

DemiosFantasimo
Тут иначе никак. Каждый тик это ненужно и невозможно.
Тикрейт сервера то же вряд ли превысит 10.


sledo
3) Мб мы представляем это немного по разному или я криво объяснил. Я бы разлился мыслью да оффтоп.
6) Не совсем, я тут скорее подозревал редактируемую систему вейпоинтов, которая еще в разных комбинациях с разными юнитами ведет себя по разному.
Что бы поняли о чем я: В SupCom из завода выходил юнит на точку сбора, точка сбора могла указывать на точку подбора транспортом, точка высадки транспортом могла указывать на начало движения\патруля или приказ двигаться с атакой.
В итоге юниты с завода автоматически доставлялись в замес.
А еще все это дело при нажатии шифта редактировалось.

>Слишком общий.
Тут не понял.

>Что я рекомендую
>Найти человека который будет воплощать мои фантазии за хлеб с маслом
Ну серьезно =) У меня на такое не наглости не самоуверенности нет. Было бы что показать, но это нужно с начала сделать, об этом сейчас и разговор.
>можно взять готовые решения и на них отработать основную концепцию, да и только
Это и было изначальной идеей. Я просто пытаюсь найти наиболее верный способ реализовать как можно больше из изначально задуманного, и желательно там где более опытный человек сможет развернутся без переезда.


#16
19:56, 13 дек. 2018

Zurab
3) Ваша тема, офтопьте сколько угодно.
6) Ну а вейспоинты вы где хранить то будете? Конечно подходы у всех разные, но лично я бы сделал их либо листами, либо массивами. Это уже и есть базы данных - т.е. хранилища с информацией.
Ну ок, предположим. Итак, на заводе наверное предполагаются производственные цепочки? Создаем список (List) для этих цепочек к которому обращается интерфейс. Создали юнита. Что вообще это значит? Запускаем таймер и по истечении времени создаем игровой объект (game object - ГО) на сцене. Откуда игра знает что это именно юнит? Создаем базу в которой хранятся то что может создать завод. Итак таки создали, поставили точку сбора, перемещаем вычитанием координат. Дошли до вейпоинта, что с этим вейпоинтом делать дальше? Откуда игра знает что у машина на этом же вейпоинте забирает юнита? Значит у этого вейпоинта есть набор свойств который определяет его характеристики. Что делаем? Правильно, создаем лист в котором определяем свойства вейспоинта. Итак у нас уже двухуровневая логика с пересекающимися базами данных. Сюда добавляется взаимодейтсвие с базами данных машины, у которой есть свои вейпоинты. Как машина поедет на вейпоинт который принадлежит юниту? Значит для машины надо создать его дубликат и внести в базу вейпоинтов. И вот у нас уже на машинке чужие базы данных, которые не должны конфликтовать с уже имеющимися, а потом еще и как то удалиться. Или же постоянно обращаться к юниту за вейпоинтом, а значит на юните или машинке надо создать отдельный обработчик событий для этих обращений.
Понимаете? Логические пересечения тут растут как снежный ком и что бы это все работало надо быть либо сумрачным гением, либо задротом который уже Толстого читает в двоичном коде. Поэтому то этим ни кто не заморачивается, ибо сложна.

Что касается на чем делать, то мое мнение это однозначно как минимум Юнити. Вроде как есть какой то движок заточенный под РТСки, но я с ним дело не имел.
Из готовых решений могу посоветовать - https://assetstore.unity.com/packages/templates/systems/urts-toolkit-17660
https://assetstore.unity.com/packages/templates/packs/rts-engine-79732
https://assetstore.unity.com/packages/templates/packs/srts-pack-21370
Но лично я бы начал бы писать его с нуля, заточенный под конкретную задачу, ибо контроль над ресурсами и иерархией тут нужен будет очень строгий.

#17
(Правка: 21:08) 20:57, 13 дек. 2018

sledo
3) Ну давайте по оффтопим.
Цепочки можно заставить обрабатывать самому ИИ, а можно сделать что то вроде шаблонов, да их придется иметь довольно большое кол-во, но сложность каждого из них это уменьшит.
Сейчас разольюсь мыслью по примеру:

+ Показать

6) По вейпоинтам? Ну с заводами это был реальный пример, я заводов не планирую, но вот как представлял у себя.

+ Показать

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


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

+ Показать

А низкий уровень, ну... там же плюсы =) По идеи можно что угодно родить.

#18
22:11, 13 дек. 2018

sledo
> Но лично я бы начал бы писать его с нуля, заточенный под конкретную задачу, ибо контроль над ресурсами и иерархией тут нужен будет очень строгий.
+1

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

Zurab
> Как сделать? Разбить всю карту на глобальные тайлы.
Первое, что надо сделать — это отделить базовую физику игры от, собственно, ИИ.
Т. е. четко решить, что относится к ИИ, а что — к базовой механике, и детально разработать интерфейс взаимодействия между ними.
Если этого не сделать, проект быстро превратиться в лапшу, в которой абсолютно непонятно, что, как и с чем взаимодействует.
Например, поиск пути из пункта A в пункт B — это относится к физике, или же она умеет двигать юнитов только по прямой?
Еще кстати, тайлы для определения видимости (физика) могут не совпадать с тайлами ИИ.

> Таких сценариев можно наплодить великое множество, это большая работа, но не особо сложная с точки зрения программирования, просто объемная.
Это только кажется. Для действительно сложного ИИ количество вариантов и особых случаев, которые надо предусмотреть, растет по экспоненте.
Начиная с определенной сложности наборы вариантов приходится заменять на более общие системы принятия решений.
Например, у юнитов есть просто набор доступных действий, а ИИ занимается оптимизацией, подбирая цепочку действий с наибольшей "ценностью".

> Я вот сейчас понял, что мне нужно то, что можно будет легко параллелить.
Не стоит на начальном этапе задумываться об оптимизации, вообще, особенно не имея опыта.

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

}:+()___ [Smile]

Учитывайте, что я работал только в уече и скован представлениями о работе его рамками.

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

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

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

Но тут прошу меня простить, за излишнее рвение, эффект Крюгера же.

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

#20
23:38, 13 дек. 2018

Zurab
// не обижайся, и особо не вникай в мои слова.

?? 1000 боевых единиц..
Это не нужно.
Тоесть, визуально, для игрока, можно нарисовать столько,
но в составе _сквадов (отряд бойцов, аля 5-20 солдат).

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

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

Важно придумывать удобные боевые единицы.


?? Угол зрения боевой единицы..
Сомнительная идея.

(оказалось, что автор имел ввиду обычный радиус обзора)


?? Большое поле боя..
Что то мутное. Не ясно чего надо автору.
Игрок должн каждый 5 секунд кликать по мини-карте,
чтобы успевать обозревать события на большом поле боя ?
Кто из игроков не успевает (не читерит) - тот проигрывает ?


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

Рекомендую автору развивать идею цепочки (разбить по тикам).

Тоесть, элемент удачи - чей солдат попадает в очередь первым,
тем у него шанс опередить своим выстрелом в дуэльке,
ведь обработка второго дуэльянта сработает лиш через пару секунд.

Мало юнитов - очередь процедур малая.
Много юнитов - очередь большая, зато нагрузка,
как-будто юнитов мало.

По поводу сложностей интелекта юнитов - автору надо упростить,
и внести игнорирование некоторых сигналов ...
Тоесть, сыпем сигналы, но без гарантий их отработки,
и с карантином _вектора_логики, чтобы юниту
не смогли указать противо-положные цели - юнит примет
первую цель, и будет игнорить (какое-то время) указание
на вторую цель с подобным индексом _вектора_логики
(стрелять = 1, стрелять_преследовать = 2, бежать = 2).

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


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

Видеть-развидеть - перебор попадания позиции юнита
в одну из сфер _штаба_игрока, где штаб обновляет свои
сферы каждые пару секунд (как и перебор детекции).

Автору надо слегка пере-придумать свои методы
обновления ситуаций на поле боя.

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

#21
(Правка: 14 дек. 2018, 0:19) 23:45, 13 дек. 2018

slatazan
>не обижайся, и особо не вникай в мои слова.
Не обижаюсь и не вникаю, половина мимо, половина из контекста выдрано и додумано.

Если хотите поспорить о проблемах современных RTS с точки зрения игрока, я не против, но не здесь.

#22
(Правка: 0:26) 0:19, 14 дек. 2018

slatazan

... хотя мне делать не чего, почему бы и нет. Жанр RTS не то что в застое, он просто по уши в дерьме, со времен начала 00х игр серьезно развивающих этот жанр вышло наверно до десяти. Причем многие из этих прорывных игр, после взлета - окуклились в достаточно узком комьюнити и не породили подражанцев, коих наплодили АоЕ и SC. Многие, тот же MoW продолжают жить и развиваться, кто то существует как сгнившие зомби - SupCom, CoH вроде подох с концами, во всяком случае о его сетевой жизни я не слышу ничего от 3х лиц.

+ Показать

#23
3:01, 14 дек. 2018

С точки зрения производительсти я бы предложил сделать тестовую карту, поставить на ней несколько спавнеров для разных команд и с определённой регулярностью отправлять наборы юнитов в одну точку, наращивая их количество и сложность логики ИИ, начиная с волн кубов, обстреливающих друг друга конусами. В какой-то момент будет понятно, менять лыжи или строить планы скромнее. Все обсуждения РТС на УЕ4, которые я видел, носили сугубо теоретический характер.

#24
9:44, 14 дек. 2018

Bodrin
Полностью поддерживаю.
Zurab
Вы пока слабо представляете что такое РТС с точки зрения разработчика. То что вы пишите для реализации пока что выглядит либо как фантастическая утопия, либо как абсолютная дилетантская ересь. Но мыслите вы в правильном направлении - надо начать с чего то и потихоньку вникать. Ну а там на сколько хватит упорства в достижении цели. Авось лет через пять у нас появится новый Dwarf Fortress в жанре РТС.

Застой в жанре вызван естественными причинами.

#25
13:43, 14 дек. 2018

sledo
Ладно, я не буду спорить, что то я через чур распустил свою шизу.

В итоге я решил, пока остаться на уе4, и проверить еще пару способов с виженом, т.к. за пол года успел кое где углубися в него, жаль терять это время и жаль тратить новое на изучение унити, так же попробую его накидать на ++. Если все это провалится буду пытаться пересесть на юнити.

#26
17:06, 14 дек. 2018

sledo
> Разные унреалы это про графон. Про возможности это юнька.

унреал еще не долго просидит на троне графона, а вот возможности гибчайшего расширения так и не получит.

#27
17:50, 14 дек. 2018

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

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

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

главное чтобы потом можно легко было открутить обратно : )

#28
18:53, 14 дек. 2018

Zurab
Вот это правильно. Я примерно таким же был лет 6 назад, только за моими плечами было лет десять программирования, потому для меня вход был относительно лёгкий. Но ничего, готовлю к релизу 4й проект.
Вам нужен кодер, а заполучить его вы сможете только если у вас будут наработки, ну и совпадение взглядов. Кроме того вы руководитель проекта и должны адекватно ставить задачи, а не "создать все это и что бы работало". Для этого и нужно начать с малого.
iperov
Ну пока это светлое будущее не наступило, Унреал про графон)

#29
20:50, 14 дек. 2018

Zurab
Я сам - тупой игрок.
Мне понравился-бы глобальный откат клик-приказов (3-5 секунд).
Тоесть, враждебные стороны не могут превысить частоту
кликов (есть буфер для одного нэкст-клика = всё ровненько).
Допустим, что клики по мини-карте не учитываем, как _приказ.
(и копание в саб-менюшках тож не приказы).

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

Угол зрения - всегда можно добавить - не нужно его _сразу_хотеть.
С углом зрения _солдатика, игра скатывается в другой жанр
(стэлс-нинзя-всех-убить-снайперкой).

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

Складки рельефа - Metal Gear Solid ?
// Укрытия гир-оф-варс - норма (родной движок).
// (но я не знаю, насколько легко внедрять родные фичи анрила).

Возможно, достаточно выдать солдатику _баф,
который занизит _целевой_урон по этому солдатику.
(снимать такой баф, если игрок сменил позу из _ползучего).
(бонус такой нельзя получить, если свойство куска земли _ровный).
(давать 2-3 слоя этого бафа, если накастовалась поза _окопался).
(тайл земли обязан иметь свойство _копаемый для позы _окопался).
(иметь ограничитель процентов бонусов и проклятий на юните).
(возможно, ограничители связаны с качеством юнита).
(редкие бафы можно сделать ультимативными - мимо ограничителей).


// ====
Выдача солдатикам разных орудий, и разных бое-припасов.
(козырная специфика никуда не уходит).
(учитывать цену - если денег много - стреляй много).
(нет денег - нет патронов - грызи зубами - ползи в тени).
(как-то перекрыть тактику забрасывания дешовым ржавым хламом).
(блефовать, выставляя фанерные танки, в счёт лимита техники).
(завод танков изначально в маскировке - ложная просветка).
// всё-таки стэлс-элементы - важная фишка - разведка рулит.

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