разница имхо в том, что нанесение специфических особенностей текстуры делается параметрически, в режиме "условий приближенных к натуральным" - т.е. не ты решаешь КАК ИМЕННО текла ржавчина или окалина - а он тебе это РАССЧИТЫВАЕТ ПОЛНОСТЬЮ В СООТВЕТСТВИИ С МОДЕЛЬЮ!! т.е. если художник (имеющий тренированный взгляд и понимание фактуры) наносит ржавчину с натуры и это очень просто сделать и простой кистью. то тут возможно нанесение предельно реалистичной ржавчины когда вообще нет никаких образцов - и она будет "растекаться" натурально и максимально реалистично. вот и вся фишка. я например давно ждал такую вещь!!!! хотел было сам написать по ржавчине или непропорциональному старению фактуры.. но чет у меня знаний не хватило!! Мыслю - значит программирую... Конструктивная критика - умных ведет к совершенству... Великие умы обсуждают идеи, средние - обсуждают поступки, а малые - людей.
Сообщение отредактировал KamiRonin - Воскресенье, 22 Декабря 2013, 09:49
Привет всем! Смотрели новости про Substance Painter? Там можно рисовать не только кисточкой, но и "действуя" на текстуру (которая уже наложена на 3D модель) разными эффектами с частицами: огонь, ветер, вода, сварка, взрывы, расползающаяся ржавчина и т.д.
И это все работает не изменяя исходную текстуру, слоями и параметрически!!
Мыслю - значит программирую... Конструктивная критика - умных ведет к совершенству... Великие умы обсуждают идеи, средние - обсуждают поступки, а малые - людей.
тут один чел разработал Мыслю - значит программирую... Конструктивная критика - умных ведет к совершенству... Великие умы обсуждают идеи, средние - обсуждают поступки, а малые - людей.
Сообщение отредактировал KamiRonin - Среда, 18 Декабря 2013, 18:04
мне тоже!! канули тему слегка... спасибо всем кто читал, участвовал и оценил!!! Мыслю - значит программирую... Конструктивная критика - умных ведет к совершенству... Великие умы обсуждают идеи, средние - обсуждают поступки, а малые - людей.
И написали то, что я цитировал, не дождавшись моего ответа))
нуу.. чаще на форум заглядывать надо.. тогда и ответы будут своевременные :)) Мыслю - значит программирую... Конструктивная критика - умных ведет к совершенству... Великие умы обсуждают идеи, средние - обсуждают поступки, а малые - людей.
Как где? у вещи на лбу....эм я хотел сказать в скрипте этой вещи-_- И на полу изображать то что прописано в скрипте
вот об этом часть "спора" формально и вышла - какая именно часть должна отвечать за визуализацию - сама вещь себя рисует или центровой скрипт и тп.. можно конечно "сказать никакой разницы - кому как нравится", но кто пробовал - знает, что во первых эт не такой простой вопрос как кажется. а во вторых это только частный случай более важного вопроса - есть ли отдельный скрипт на каждую вещь, в котором все связанное с этой вещью и делается или вещь хранит только формальные данные и параметры себя, а все остальное делает - центровой скрипт? Мыслю - значит программирую... Конструктивная критика - умных ведет к совершенству... Великие умы обсуждают идеи, средние - обсуждают поступки, а малые - людей.
Сообщение отредактировал KamiRonin - Понедельник, 16 Декабря 2013, 21:52
чтобы не мучаться - правильно спланированная структура классов решает это дело.. сочувствую.. сам мучаюсь с отладкой модели классов.. я не смог пойти твоим путем - просто отложил игру. там лепить универсальность совсем не с руки было...
в общем, lentinant, вот тебе две модели - одна универсализм - глубоко абстрактные классы с облаком примочек вокруг них и более индивидуалистическая модель - с жесткой структурой заранее наполненных классов.
из-за отсутствия абстракций порой код часто дублировался или создавались методы там где они не должны были создаваться. Но вообще все это происходит из-за спешек и усталости)
ппц жаль! сочувствую. но тут есть система организации труда и средства моделирования структуры классов. абстракции могут быть жесткие но при этом дающие полную свободу в расширяемости кода.. в общем оффтопить не буду. лады.
надо на форуме продолжить тему организации структуры игры!! -- углубленное ооп (абстракции, наследования, полиморфизмы, делегаты, эвенты и тп.) -- планирование локализации кода (схему необходимых и обязательных элементов внутри структуры входящих компонент) -- оптимизация поддержки кода в проекте -- психологические аспекты интенсивной разработки игр и мультимедиа приложений. ("устал - смени род деятельности", "замылился взгляд - перформатируй документ" )
НО НЕКОМУ ЗАНИМАТЬСЯ!! у меня вообще нет времени.. хотя я бы мог куски добавить на любую из этих тем
Мыслю - значит программирую... Конструктивная критика - умных ведет к совершенству... Великие умы обсуждают идеи, средние - обсуждают поступки, а малые - людей.
Посути полуручной редактор игры без интерфейса ( вбиваю xml сам ))
по сути ты сделал универсальный движок этого вида игры.. и просто в этот раз наполнил его контентом сам и вот так.. ну эт реально достижение!!!! респект!! просто насколько это ТОТ путь каким должны идти все кто пишет крафты?!
предельно просто!! на самом деле мысль понятна.. но ПОЧЕМУ Пошел таким путем - совсем я не понял. разве не легче было у Hero сделать метод TakeBlow(int мainSkill, List<additionEffects> addEff); который бы вызывал атакующий и передавал туда параметры. а внутри метода у хироу - просто +/- по всем его внутренним наличиям - что-то на основной хит бы ложилось (минусовало или плюсовало урон), а что-то на эффекты?!?!? :-/ в списке эффектов - заморозка, отравление и прочее!!
Да - у меня нет ни одного индивидуального класса ни на монстра, ни на героя, ни на вещи, ни на артефакты) это позволяет мне максимально быстро добавлять новый контент на основе имеющихся ресурсов и скриптов. Я просто делаю описательный документ xml файл и это в игре:)
ууухх.. какой однако резон, имхо, немного сомнительный!! что каждый день по 20 новых монстров или сабелек появляется?? прям не знаю.. Мыслю - значит программирую... Конструктивная критика - умных ведет к совершенству... Великие умы обсуждают идеи, средние - обсуждают поступки, а малые - людей.
ээ - использованием делегатов можно избавиться от большого кол-ва условий.
тут человек не знает как к классам подступить.. а ты сразу делегатами его! :)))) ну в принципе в качестве ориентира - на будущее... тоже полезно!
Цитатаpixeye ()
У меня сейчас больше 40 предметов. Из них 16 ломаются. Я сомневаюсь что у каждой из 16 вещи будет свой индивидуальный механизм. в 90% будет копипаста. Допустим по какой то причине я изменил правила поломки. Следует из того что ты написал, что мне надо будет 16 раз менять свой код?)
ну не знаю.. я код не видел. может у тебя все предметы ломаются одинаково - "отмычка порвана в клочья", "веревка заржавела и разбилась вдребезги" :))) ведь если универсализировать понятие поломки - типа "целостность веревки 65%" и все тут.. тогда вообще лафа..
Цитатаpixeye ()
Да. У меня был крафт ( сейчас заморожен ) - написал где-то за неделю. Сейчас есть апгрейд вещей по кристалликам. Есть уровень вещи, он влияет на значение шанса успешного апгрейда, есть цена апгрейда в деньгах и кристаллах. Через N уровней нужно использовать другой кристалл ( более редкий ), так же уровень влияет на базовое значение вещи ( атака, хп, защита ) и повышает прочность ( влияет на шанс поломки ) и значение бафа/черты которая присоединена к вещи ( например перк вампиризм N % шанс насосаться крови врага )
молоток!!! так держать! там класс вещи - такой же простой?? ну в смысле - обошелся без индивидуального класса на каждый предмет? Мыслю - значит программирую... Конструктивная критика - умных ведет к совершенству... Великие умы обсуждают идеи, средние - обсуждают поступки, а малые - людей.
Сообщение отредактировал KamiRonin - Понедельник, 16 Декабря 2013, 13:45
объект может быть и пустым. но как сделать инвентарный предмет видимый в игре и при этом чтобы у него отсутствовал игровой объект... только если инвентарь является менеджером объектов и просто по описанию строит их изображение. просто обычно в инвентаре - объект таскается и кидается на слоты или другие объекты.. стоит ли все отрабатывать так, чтобы не было объекта предмета вообще? не сложнее ли это?! в текстовых играх объект может быть просто словом.. и поэтому можно обойтись.
Цитатаseaman ()
Только унаследованный от MonoBehaviour. Кто Вам мешает от него не наследоваться?
абсолютно согласен. но нужно было с чего то начать дискуссию. в ScriptingReference любой класс рекомендуют оформлять в виде отдельного файла. причем имя файла должно совпадать с именем класса в обязательном порядке! и с наследованием от моно эт никак не связано. но конечно опыт показывает что в один файл можно запихать и несколько классов. эт да. тут на форуме была тема о том, как лучше для проектов организовывать скрипты. писать много или все совать в один..
Цитатаseaman ()
У меня 90% скриптов НЕ прикреплены к объектам. Что я делаю не так?
подловили. у меня (и в некоторых других примерах) скрипты связанные с квестами, крафтами и инвентарем - прикреплены к объектам... но это - Ваша правда -- дело вкуса. Если Вы пишете в основном статические классы или библиотеки инструментальных классов и функций, или делаете не мононаследующие структуры классов со статическими функциями - это же просто логика организации структуры выбранная Вами и все.
Цитатаpixeye ()
Что за... фигня?
1) Нужно понять, что ваши только что сделанные скрипты - классы таковы потому что наследуются от юнитивского MonoBehaviour 2) Любая вещь инвентаря есть описание этой вещи. ID картинки, ID описания из файла локализации, Количество.
Ничего более. Ни при каких обстоятельствах не нужно мешать сюда код рендеринга ( очень любят мешать все до кучи )
скрипты классы в C# потому что они всегда классы. а не потому что наследуются от моно. и про рендеринг .. может я что то пропустил ??
вещь инвентаря - это просто описание этой вещи, и просто её индивидуальный способ взаимодействия с другими объектами, и просто некие условия её например порчи, продажи и прочего. просто для меня например - писать все эти сопутствующие вещи - в одном скрипте на плейменеджере каком нибудь или инвентаре - это получается неоправданно перегруженный условиями скрипт! ведь он должен проверять все сопутствующие условия для каждого вида объекта. конечно от логики организации зависит. если сделать универсальные параметры "поломки" вещи (например отмычка или веревка) тогда можно и так. но разве не нагляднее в каждом предмете иметь свой "механизм" поломки и прочего. ну эт дело вкуса и способа восприятия целостности системы.
Добавлено (16.12.2013, 13:26) --------------------------------------------- pixeye, очень наглядно в "грубом примере"! что можно обойтись вообще без каких либо игровых объектов - просто выбор лука на пальцах, "в уме"!! и игродел сам решит, что делать потом с этим виртуальным луком - как визуализировать, ГДЕ, к кому прикрепить, как взаимодействовать! супер. чистая база объектов и больше ничего. из lootSpriteID потом достается картинка для инвентаря или еще для чего. нормально!! и главное четко на вопрос отвечает - спросили про абстрактные объекты вне сцены - вот ответ! молоток!! можно и так, почему нет?!!!! и в ngui отдельный класс для такой базы в примере был создан. еще 3D префаб к итему указывается по имени и все. потом одеваешь орка в любые браслеты.
Цитатаpixeye ()
у меня в данжелоте2 вещи делятся на артефакты со своей логикой, но все они наследуют базовые элементы от абстрактного класса вещи.
спросить хочу, а там функции кроме выбрал-купил-добавил_скил какие нибудь предусмотрены в работе с объектами? ну - соединение, поломка, апгрейд и тп Мыслю - значит программирую... Конструктивная критика - умных ведет к совершенству... Великие умы обсуждают идеи, средние - обсуждают поступки, а малые - людей.
Сообщение отредактировал KamiRonin - Понедельник, 16 Декабря 2013, 15:11
в Unity один скрипт = один класс (в обычных обстоятельствах). есть статические элементы класса - которые доступны из любой области игрового мира. скрипт это почти всегда -- компонент, прикрепленный к объекту. т.е. методика обращения к элементам скрипта это - найти объект в пространстве, получить компонент, взять нужные данные из объекта. (статические классы могут быть доступны и без этого естессно.)
инвентарь - для ВИЗУАЛЬНОЙ (не текстовой) игры - это всегда игровой объект, даже если он "пока" в инвентаре. в плагине NGUI есть пример инвентаря для Unity и еще в нескольких плагинах и китах. в общих словах - это префаб, для которого хранятся данные в скрипте (базе рюкзака), когда активизируется рюкзак - предмет визуализируется (не знаю какой уровень очевидности для тебя пройден! ).
крафтинг - имхо, целая игровая система, где одним скриптом (классом) не обойдешься никак. т.е. скорее всего - на каждый предмет крафта будет свой класс (отдельный файл со скриптом) и будут отдельные классы для процесса крафтинга, для обучения ему, отслеживания в сценарии и тп и тд. для всех предметов крафтинга - будет предок класс, из него будут расти потомки разного вида, у них будут персональные значения полей - "учитель", "условия получения", "цена покупки", "рецепт", "текущий владелец" и тп не знаю что еще.. сделать сбалансированную классовую модель крафтинга - это и будет "создать свой Craft Kit пакет". в общем тут нужна система классов. просто хранить данные можно и в структуре. делать переменную этой структуры можно будет где угодно. тут если бы был пример всей цепочки можно было бы конкретнее показать. Мыслю - значит программирую... Конструктивная критика - умных ведет к совершенству... Великие умы обсуждают идеи, средние - обсуждают поступки, а малые - людей.
Сообщение отредактировал KamiRonin - Понедельник, 16 Декабря 2013, 09:48
нуу.. я бы сделал - сборные как фоторобот - и складывал бы вариации из 5-6 вариантов в каждой номинации: небо (облака, луна, звезды, солнце, злвещие тучи на все небо) пархающие сущности (летучие мыши, драконы, карлосоны, бабочки, феи) основной центр (замок, поляна, прянишный домик, гора(ры), водопад и тп) граунд (зловещая трава, умильная травка, каменистый, кладбище, песок с осколками и проч)
каждую из компонент сделал бы и в дневном и в ночном варианте и - рандом их!! белая пушистая дневная летучая мышь - клево же!!! Мыслю - значит программирую... Конструктивная критика - умных ведет к совершенству... Великие умы обсуждают идеи, средние - обсуждают поступки, а малые - людей.
Сообщение отредактировал KamiRonin - Воскресенье, 15 Декабря 2013, 18:57
Подумываем сделать параллакс облаков или звезд. Может быть для фона полет опадающих листочков с деревьев в середине поля... это если осенняя тема будет
- рекомендую менять фон на каждом бою. - лучше всего небольшой темный стиллизованый замок на фоне с летучими мышами, луной и звездами - если типа атакует первой светлая ( она в гости пришла) - или поляна с радугой и проч - если первой атакует темная (т.е. мы в месте где живет светлая) ну в таком ключе логика. как вам? Мыслю - значит программирую... Конструктивная критика - умных ведет к совершенству... Великие умы обсуждают идеи, средние - обсуждают поступки, а малые - людей.
Гипнолягуш - понятно, но почему я - ПОХИТИТЕЛЬ СИЛ ??? )))
логика была такая: на картинке воришка -> значит будет похититель -> игра средневековая и магическая -> значит должен похищать что то магическое -> карта боевая -> значит должен при похищении наносить урон какой нибудь -> похитив что можно нанести урон? -> жизнь, манна, сила, карты игрока, веб мани (конкретная магия для меня - как деньги в циферках держать и ждать что никто не сопрет ) ... -> ну вот и выбрал СИЛ! ну не жизни же.. Мыслю - значит программирую... Конструктивная критика - умных ведет к совершенству... Великие умы обсуждают идеи, средние - обсуждают поступки, а малые - людей.
не, сами карты .. в стиле так сказать. а что с рубашками и числовыми то?? а фон??!?! картинок жеж море бесплатных на фон то.. ну замок там какой нибудь или сетку из шестигранников или водный мир какой..
а по моему - очень даже!! Мыслю - значит программирую... Конструктивная критика - умных ведет к совершенству... Великие умы обсуждают идеи, средние - обсуждают поступки, а малые - людей.
Сообщение отредактировал KamiRonin - Воскресенье, 15 Декабря 2013, 18:24
Любое пространство разбивается на 2D - для поиска пути, когда путь найден - вам просто выдаётся лист с координатами точек по которым нужно пройти.
нууу вооот!! теперь вся рыба наша! И СНОВА: то, что мне это хорошо известно - ясно из первого поста. Задача -- не в том, чтобы понять как вообще организована логика 2D поиска пути, а КАКИЕ ЕСТЬ ПРОГРАММНЫЕ ГОТОВЫЕ ФРИ РЕШЕНИЯ, алгоритмы для их ПРОГРАММНОЙ Unity реализации. Самая сложная задача в ПРОИЗВОЛЬНОМ 2D пространстве - построить "поле" квадратов (треугольников, шестиугольников) внутри предлагаемого спрайта у которого нет четкой градации цветов (если бы признак стены - был цвет например), у которого есть только "физическая" стенка для теста лучом (например) и тп.
Внутри A* Pf Pr -- есть система построения сети опорных точек вручную - расставляешь пустышки-ГО по нужной тебе траектории, задаешь им определенный тег на этапе разработки и передаешь все это А*машине - она "автоматом" строит "поле" в котором можно перемещаться только по этим точкам во время поиска пути. у меня поле не квадратное (см. фото в первом посте)! и возможных точек прохождения больше 1000!! вручную это расставлять??!?! думаю немного накладно будет!!
Сам поиск по гриду в 2D НИКАКОЙ сложности не представляет!! и его программная реализация известна. Кстати, два лидирующих алгоритма по реализации это JumpPointSearch (в разы более быстрая разновидность А*) и алгоритм Ли (волновой).
Вопрос как в произвольном спрайте построить правильно и оперативно ГРИД!!? А с учетом подвижных препятствий?!! А с быстрым доступом к точке, если поле - не квадрат!?!? Нет, можно конечно сделать огромный квадрат из любой локации и просто вычеркнуть из обработки три четверти точек, но стоит ли?!
В одном из примеров с A*Pf Pr - пошли таким путем - создали чистое поле, а потом программно вычеркнули "стены" из него - с указанием координат прохождения стены. Опять ручной вариант!!! Легче?? Конечно даа..
В моем варианте, результат которого показан на фото в первом посте - берется спрайт, ставится ему EdgeCollider по стенке, вешается скрипт генерации поля, в котором указывается точка старта (нулевой угол), и размер сектора - все. Он строит поле в любом пространстве - с прямыми углами, с косыми, в не квадратном поле и проч. Рассчитан на квадратный сектор пока... Но я на него слишком много времени потратил! И еще нужно обтесывать! Вот и возник вопрос - есть ли готовое что нибудь! Мыслю - значит программирую... Конструктивная критика - умных ведет к совершенству... Великие умы обсуждают идеи, средние - обсуждают поступки, а малые - людей.
Сообщение отредактировал KamiRonin - Суббота, 14 Декабря 2013, 09:31
ппц жаль! сочувствую. 