|
|
|
Канал Игры Мечты: «Техническая помощь в реализации самописных игр» |
|
|
Варсик 545 EGP
Рейтинг канала: 4(81) Репутация: 117 Сообщения: 4039 Откуда: Москва Зарегистрирован: 22.12.2002 |
|
БулерМэн : |
Эта задачка на уровне "придумай свой 3d-редактор" в котором можно изгибать поверхности потягивая за "узлы". Сложновато, имхо.
|
А вектора тебе чем не угодили?..
_________________ WARNING: By reading this post you accept that this post is genius. |
|
|
БулерМэн 420 EGP
Рейтинг канала: 2(21) Репутация: 68 Сообщения: 1580 Откуда: Гороховец Зарегистрирован: 07.02.2006 |
|
Olorin : |
Обшивка же не в воздухе висит, а цепляется на внутренности, но именно цепляется
|
Я честно скажу - полновесный редактор с кривыми безье и прочими вкусностями по твоей задумке - лично я не потяну. Даже прототип.
Но мне кажется что проще реализовать перетаскивание твоих треугольников вот с таким вот интерфейсом - там есть готовые куски начиная с минимальных, заканчивая готовыми деталям корпуса, созданными игроком или другими игроками.
Картинка под катом:
Cкрытый текст (кликните здесь для просмотра)
|
добавлено спустя 1 минуту:
Варсик : |
А вектора тебе чем не угодили?..
|
меня смущает объем кода, который нужно написать с нуля. Хотя наверное можно содрать с какого-нибудь опенсорсного проекта... но его еще нужно найти..
добавлено спустя 2 минуты:
просто если это автогенератор формы - это один вопрос, а если игроку представляется возможность самому эту форму задать, не векторами - это другой вопрос. Векторами сложную форму не нарисовать, имхо. Что интереснее автору вопроса - известно только ему, я только предложил
Последний раз редактировалось: БулерМэн (22:01 29-01-2015), всего редактировалось 5 раз(а) |
|
|
Olorin 70 EGP
Рейтинг канала: 1(6) Репутация: 12 Сообщения: 97 Откуда: Хьёрвард Зарегистрирован: 27.02.2006 |
|
БулерМэн : |
Cкрытый текст (кликните здесь для просмотра)
Olorin : |
Там потому так и заложено, чтоб можно было способы описания поверхностей добавлять.
|
А собственно, что мешает всю логику относительно генерации поверхности корабля выделить в отдельный блок кода и не трогать его пока не будет реализован весь остальной "простой кубизм" который уже всем приелся?
Мне кажется, что фичу игры лучше добавлять к более менее реализованному проекту, чем отсекать лишнее от монолита и добиваться работоспособности всего в целом. На не структурированный подход, без выделения блоков - уйдет больше времени и сил. Сейчас у тебя кусок кода отвечает за генерацию поверхности по кривой, а потом у тебя появится какая-либо необходимость что-то изменить и полезут баги - так как данная фича это не отдельное нечто, не какой-либо "модификатор", а часть общего кода, который жестко вшит.
добавлено спустя 5 минут:
--
Кстати, а не проще ли игроку в этом случае - лепить поверхность кораблика не по кривой, а брать этот треугольник и перетаскиванием прицеплять на другой треугольник?
Просто с точки зрения сложности кода - такой подход с перетаскиванием и заготовками - намного проще, имхо.
добавлено спустя 6 минут:
--
Если представить, что у тебя уже есть код, который генерирует поверхность из треугольников то появляется резонный вопрос - а как сделать так, чтобы количество треугольников было одинаковым по всей поверхности модельки?
Допускаю, что у тебя все треугольники подгоняются в размерах, "тянутся" и создают гладкую поверхность. Но от того, что они разные каким образом ты будешь автоматом подгонять текстуру?
А вот если взять готовые куски, то на готовый кусок можно сделать стандартную текстуру или несколько. Да, возможно будет угловато, но тут уж надо для себя решить, что ты хочешь:
а) проще реализовать программисту + долго рисовать игроку
б) сложнее реализовать программисту + быстро рисовать игроку.
добавлено спустя 3 минуты:
Эта задачка на уровне "придумай свой 3d-редактор" в котором можно изгибать поверхности потягивая за "узлы". Сложновато, имхо.
|
|
Это уже воркфлоу редактора. Я его сам и пишу. Подвис именно на построении визуальной модели (полигончиков) по внутреннему описанию (см. "дано" и "надо" тут), т.к. после двух лет ынтырпрайза моск очень сопротивляется загружанию в него аналитической геометрии за пределами операций с векторами.
А сам сценарий такой и есть, например создание скелета: тыкаешь кнопку "создать кусок скелета" - создается кусок скелета с дефолтными параметрами, по нему строится визуальная моделька, которая подшивается к wpf'ной визуализации, на которую цепляются евенты, обработчики которых делают селекшон и перетаскивание с обновлением внутреннего описания. Прежде чем перетащить и обновить - проверяют, коллижон ли в визуальном представлении, в котором конкретная полигональная геометрия.
Или для создания фрагмента обшивки: тыкаешь кнопку "создать фрагмент обшивки" - включается режим выбора точек, тыкаешь в разные места имеющейся модели (подвешенные к ней евенты запоминают автоматически отмапленные в пространство координаты накликанных точек), тыкаешь "ок" - по выбранным точкам во внутреннее описание добавляется фрагмент обшивки, из которого тут же строится визуальная моделька (в соответствии с методом выбранным режимом) и подшивается в wpf'ную визуализацию - опа, видим построенный кусок обшивки. К нему подшиваются евенты, через обработчики которых потом делается перетаскивание его целиком и/или его опорных точек.
На количество точек в единицу пространства пока плевать, т.к. только цвет без текстур пока.
(хотя в уме гипотетическое решение вопроса фактуры есть....)
Реквестируемый алгоритм построения визуальной модели (полигонов) по внутреннему описанию (той структурной модели) не имеет никаких внешних зависимостей, кроме внутренней модели и спец интерфейса-билдера, который строит визуальную модель методами ДобавьВеришну(x,y,z):индекс, ДобавьПолигон(индекс,индекс,индекс).
(я сам его могу к такому виду отрефакторить)
Так что даже типы представления полигональной модели меня не особенно волнуют.
_________________ Мы на многое не отваживаемся не потому что оно трудно; оно трудно именно потому, что мы на него не отваживаемся.
Сенека Старший
Последний раз редактировалось: Olorin (18:24 30-01-2015), всего редактировалось 3 раз(а) |
|
|
БулерМэн 420 EGP
Рейтинг канала: 2(21) Репутация: 68 Сообщения: 1580 Откуда: Гороховец Зарегистрирован: 07.02.2006 |
|
Olorin : |
тыкаешь кнопку "создать фрагмент обшивки" - включается режим выбора точек, тыкаешь в разные места имеющейся модели (подвешенные к ней евенты запоминают автоматически отмапленные в пространство координаты накликанных точек)
|
Что-то мне кажется, что точек будет дофига. Если только точки (вершины) будут доступны для выделения только одного фрагмента общей геометрии.
|
|
|
Olorin 70 EGP
Рейтинг канала: 1(6) Репутация: 12 Сообщения: 97 Откуда: Хьёрвард Зарегистрирован: 27.02.2006 |
|
БулерМэн : |
Olorin : |
тыкаешь кнопку "создать фрагмент обшивки" - включается режим выбора точек, тыкаешь в разные места имеющейся модели (подвешенные к ней евенты запоминают автоматически отмапленные в пространство координаты накликанных точек)
|
Что-то мне кажется, что точек будет дофига. Если только точки (вершины) будут доступны для выделения только одного фрагмента общей геометрии.
|
"Разные места имеющейся геометрии" - любые точки на уже существующей геометрии (внешние стороны отсеков, торчащие части скелета - построения крыльев для). С предпочтением вершин ранее заданных фрагментов обшивки.
_________________ Мы на многое не отваживаемся не потому что оно трудно; оно трудно именно потому, что мы на него не отваживаемся.
Сенека Старший |
|
|
Minx 979 EGP
Рейтинг канала: 6(328) Репутация: 135 Сообщения: 10528 Откуда: Gomel, Belarus Зарегистрирован: 19.11.2005 |
|
ТехноМаг : |
xml`ка в этом плане будет гораздо удобнее.
|
Здесь все зависит от задачи и развития проекта.
Форматы а-ля ini очень удобны с точки зрения простоты. Их просто собирать. Их просто разбирать. В них просто вьезжать (если все незаезжено). Банально, ini-файлы намного проще читать.
Формат ini он не один. Например в поставке Poco есть готовый фреймворк для задания конфигурирования. И он более гибок и мощен, чем ini. Хотя далеко не ушел.
xml нужен в случаях, когда:
- нужно дерево (в ini все плоское)
- нужна валидация и верификация (XML 1.0, DTD/Schema)
- нужны комплексные запросы (XPath)
- нужна более прозрачная группировка (несколько вложенных групп тегов с одинаковым поддеревом)
- нужен продвинутый процессинг (xslt)
- религиозная необходимость (вся команда использует XML)
- не нужна скорость (потому что стройка DOM'a ест ресурсы)
По большому счету все. Если пункты не нужны, то лучше ini-like.
Т.е. простые задачи, и большие проекты, где вы сам себе хозяин и имеете способность к грамотной организации данных - то однозначно ini.
ini кстати не самый ещё простой формат. Для ещё более простых случаев есть командная строка и её аргументы.
Можно. Но очень поверхностный образ, можно сказать, стартовый.
_________________ μηδείς αγεωμέτρητος εισίτω |
|
|
Olorin 70 EGP
Рейтинг канала: 1(6) Репутация: 12 Сообщения: 97 Откуда: Хьёрвард Зарегистрирован: 27.02.2006 |
|
Minx : |
По большому счету все. Если пункты не нужны, то лучше ini-like.
|
У xml при наличии схемы (которую можно сгенерить из написанного документа и подрихтовать руками) еще
+автодополнение по структуре (ощутимо упрощает и ускоряет написание самого конфига)
+автоматическая сериализация через кодогенерацию (ощутимо упрощает и ускоряет реализацию парсинга)
_________________ Мы на многое не отваживаемся не потому что оно трудно; оно трудно именно потому, что мы на него не отваживаемся.
Сенека Старший |
|
|
Michael_Moon 100 EGP
Рейтинг канала: 1(2) Репутация: -2 Сообщения: 669 Откуда: РК, Кокшетау Зарегистрирован: 15.02.2011 |
|
Как оказалось, юнька намного проще и грамотней сконструирована для построения ГУИ любой сложности. Куришь мануал и втыкиваешься в решения.
Так что, всем спасибо за помощь.
Что не исключает возможности постучания в личку
|
|
|
БулерМэн 420 EGP
Рейтинг канала: 2(21) Репутация: 68 Сообщения: 1580 Откуда: Гороховец Зарегистрирован: 07.02.2006 |
|
Michael_Moon : |
юнька намного проще и грамотней сконструирована для построения ГУИ любой сложности.
|
то есть ты отказался от ini-файлов?
|
|
|
Michael_Moon 100 EGP
Рейтинг канала: 1(2) Репутация: -2 Сообщения: 669 Откуда: РК, Кокшетау Зарегистрирован: 15.02.2011 |
|
БулерМэн : |
Michael_Moon : |
юнька намного проще и грамотней сконструирована для построения ГУИ любой сложности.
|
то есть ты отказался от ini-файлов?
|
Для ГУИ - да. На данном этапе реализации.
Но ведь игра не только из ГУИ состоит
|
|
|
Minx 979 EGP
Рейтинг канала: 6(328) Репутация: 135 Сообщения: 10528 Откуда: Gomel, Belarus Зарегистрирован: 19.11.2005 |
|
Olorin : |
У xml при наличии схемы
|
В общем случае XML берет во многом засчет развившейся в последение лет 5-10 инфраструктуры. Т.е. для длительных проектов есть существенная вероятность применения чего-то с XML. Соответственно, не придется переезжать с ini на XML или писать преобразователь.
Но. Если речь идет о конфигурации, то ini - это простейший файл и моментальный подхват в приложение как map/multimap. XML же это та ещё куча телодвижений и букв.
При этом если не тянуть логику в ini, то в дальнейшем при необходимости ini легко трансформируется в XML.
_________________ μηδείς αγεωμέτρητος εισίτω |
|
|
БулерМэн 420 EGP
Рейтинг канала: 2(21) Репутация: 68 Сообщения: 1580 Откуда: Гороховец Зарегистрирован: 07.02.2006 |
|
Если рассматривать движок GameMaker'а то загрузка данных из ini выполняется в один присест: указал секцию, указал имя параметра.
Можно сказать, что работа с ini на движке GM упрощена до безобразия. Несомненно на Unity скорее всего тоже все отлично с этим.
|
|
|
Michael_Moon 100 EGP
Рейтинг канала: 1(2) Репутация: -2 Сообщения: 669 Откуда: РК, Кокшетау Зарегистрирован: 15.02.2011 |
|
БулерМэн : |
Если рассматривать движок GameMaker'а то загрузка данных из ini выполняется в один присест: указал секцию, указал имя параметра.
Можно сказать, что работа с ini на движке GM упрощена до безобразия. Несомненно на Unity скорее всего тоже все отлично с этим.
|
Да, но в Юнити сейчас еще и работа с ГУИ упрощена до безобразия. Даже по сравнению, как это было пару лет назад, когда я предпринимал первые робкие шаги для визуализации калькулятора цусимского сражения.
Ини для Юнити будет хорош для инициализации всех глобальных переменных. Чтобы собрать их все в одну кучу, наподобие того, как это было сделано в ЗВ (файл АИ)
|
|
|
Minx 979 EGP
Рейтинг канала: 6(328) Репутация: 135 Сообщения: 10528 Откуда: Gomel, Belarus Зарегистрирован: 19.11.2005 |
|
Michael_Moon : |
Ини для Юнити будет хорош для инициализации всех глобальных переменных.
|
Число глобальных переменных вообще лучше держать на значении 0.
Т.е. ini в системах, которые сложнее лабораторной работы на 1.5 часа должен быть распилен на разделы или множество типовых файлов.
_________________ μηδείς αγεωμέτρητος εισίτω |
|
|
Michael_Moon 100 EGP
Рейтинг канала: 1(2) Репутация: -2 Сообщения: 669 Откуда: РК, Кокшетау Зарегистрирован: 15.02.2011 |
|
Minx : |
Michael_Moon : |
Ини для Юнити будет хорош для инициализации всех глобальных переменных.
|
Число глобальных переменных вообще лучше держать на значении 0.
Т.е. ini в системах, которые сложнее лабораторной работы на 1.5 часа должен быть распилен на разделы или множество типовых файлов.
|
Если ты знаком с Юнити, то должен знать, чем проект отличается от готовой сборки. После компиляции этот файл снаружи виден не будет, т.к. сидит в ресурсах. А в проекте как раз удобно держать все глобальные в одном месте, чтобы не рыть скрипты, когда их число перевалит за несколько десятков/сотен.
Плюс, если прикручивать к юньке всякие надстройки, типа Антареса, НГУИ и прочего, то и подавно.
|
|
|
Minx 979 EGP
Рейтинг канала: 6(328) Репутация: 135 Сообщения: 10528 Откуда: Gomel, Belarus Зарегистрирован: 19.11.2005 |
|
Michael_Moon : |
Если ты знаком с Юнити, то должен знать, чем проект отличается от готовой сборки. После компиляции этот файл снаружи виден не будет, т.к. сидит в ресурсах. А в проекте как раз удобно держать все глобальные в одном месте, чтобы не рыть скрипты, когда их число перевалит за несколько десятков/сотен.
Плюс, если прикручивать к юньке всякие надстройки, типа Антареса, НГУИ и прочего, то и подавно.
|
Множество распиленных файлов - это формат работы с исходниками. Загрузка в Юнити - это итоговый пакет сборки. Между ними - сборка. Которая в данном случае может быть автоматической. Т.е. несколько ini-файлов можно банально смержить bat-ником.
Сборка не всегда удобна и приемлима, потому даже не настаиваю.
_________________ μηδείς αγεωμέτρητος εισίτω
Последний раз редактировалось: Minx (00:06 01-02-2015), всего редактировалось 1 раз |
|
|
БулерМэн 420 EGP
Рейтинг канала: 2(21) Репутация: 68 Сообщения: 1580 Откуда: Гороховец Зарегистрирован: 07.02.2006 |
|
Minx : |
Число глобальных переменных вообще лучше держать на значении 0.
|
Согласен. Поэтому выражение
Michael_Moon : |
когда их число перевалит за несколько десятков/сотен.
|
выглядит как страшный сон.
|
|
|
Michael_Moon 100 EGP
Рейтинг канала: 1(2) Репутация: -2 Сообщения: 669 Откуда: РК, Кокшетау Зарегистрирован: 15.02.2011 |
|
БулерМэн : |
выглядит как страшный сон.
|
Это нормально. Чем писать километровые простыни, в которых запутаешься через неделю после написания, лучше разбить на несколько скриптов помельче, каждый из которых будет отвечать за свой маленький кусочек игры
Ты разве не так делаешь?
|
|
|
БулерМэн 420 EGP
Рейтинг канала: 2(21) Репутация: 68 Сообщения: 1580 Откуда: Гороховец Зарегистрирован: 07.02.2006 |
|
Michael_Moon : |
Чем писать километровые простыни, в которых запутаешься через неделю после написания
|
Я стараюсь разбивать на законченные куски, которые не потребуют в дальнейшем изменения, не взаимодействуют с глобальными переменными напрямую.
Для того, чтобы не влезать в код в дальнейшем - достаточно использовать локальные переменные. Глобальная переменная может быть передана в кусок кода(функцию) в качестве аргумента.
Таким образом, мы заранее определяем, в каком куске явно используется та или иная глобальная переменная, не пытаясь даже искать ее в коде этих фрагментов.
Так обычно делаю я, но это не значит, что это удобно всем.
добавлено спустя 3 минуты:
И да, при воздействии объектов, если это возможно, лучше не использовать глобальные переменные, а изменять локальные другого объекта напрямую. Если конечно вас не пугает выяснение обстоятельств, по которым "что-то пошло не так"
Последний раз редактировалось: БулерМэн (15:52 01-02-2015), всего редактировалось 3 раз(а) |
|
|
Michael_Moon 100 EGP
Рейтинг канала: 1(2) Репутация: -2 Сообщения: 669 Откуда: РК, Кокшетау Зарегистрирован: 15.02.2011 |
|
БулерМэн : |
Так обычно делаю я, но это не значит, что это удобно всем.
|
Я говорил примерно о том же самом. Только управление глобальными (передаваемыми в код "в качестве аргумента") берет на себя (возможно и далеко не всегда) ini-файл. Таким образом глобальные сосредоточены в одном месте, где их легко можно найти и подогнать под нужные тебе параметры.
Неплохая реализация такого подхода сделана в ЗВ (правда там ini-файл вынесен наружу).
|
|
|
|
|
|
Канал Игры Мечты: «Техническая помощь в реализации самописных игр» |
|