Elite Games - Свобода среди звезд!
.
  » Техническая помощь в реализации самописных игр | страница 3
Конференция предназначена для общения пилотов. Для удобства она разделена на каналы, каждый из которых посвящен определенной игре. Пожалуйста, открывайте темы только в соответствующих каналах и после того, как убедитесь, что данный вопрос не обсуждался ранее.

Поиск | Правила конференции | Фотоальбом | Регистрация | Список пилотов | Профиль | Войти и проверить личные сообщения | Вход

   Страница 3 из 15
На страницу: Пред.  1, 2, 3, 4 ... 13, 14, 15  След.    Перейти:   Все страницы
Поиск в этой теме:
Канал Игры Мечты: «Техническая помощь в реализации самописных игр»
Варсик
 545 EGP


Рейтинг канала: 4(81)
Репутация: 117
Сообщения: 4034
Откуда: Москва
Зарегистрирован: 22.12.2002
БулерМэн :
Эта задачка на уровне "придумай свой 3d-редактор" в котором можно изгибать поверхности потягивая за "узлы". Сложновато, имхо.
А вектора тебе чем не угодили?..
_________________
WARNING: By reading this post you accept that this post is genius.
    Добавлено: 21:33 29-01-2015   
БулерМэн
 410 EGP


Рейтинг канала: 2(21)
Репутация: 68
Сообщения: 1580
Откуда: Гороховец
Зарегистрирован: 07.02.2006
Olorin :
Обшивка же не в воздухе висит, а цепляется на внутренности, но именно цепляется


Я честно скажу - полновесный редактор с кривыми безье и прочими вкусностями по твоей задумке - лично я не потяну. Даже прототип.

Но мне кажется что проще реализовать перетаскивание твоих треугольников вот с таким вот интерфейсом - там есть готовые куски начиная с минимальных, заканчивая готовыми деталям корпуса, созданными игроком или другими игроками.
Картинка под катом:
 Cкрытый текст   (кликните здесь для просмотра)



добавлено спустя 1 минуту:
Варсик :
А вектора тебе чем не угодили?..

меня смущает объем кода, который нужно написать с нуля. Хотя наверное можно содрать с какого-нибудь опенсорсного проекта... но его еще нужно найти..

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

Последний раз редактировалось: БулерМэн (22:01 29-01-2015), всего редактировалось 5 раз(а)
    Добавлено: 21:56 29-01-2015   
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 раз(а)
    Добавлено: 18:12 30-01-2015   
БулерМэн
 410 EGP


Рейтинг канала: 2(21)
Репутация: 68
Сообщения: 1580
Откуда: Гороховец
Зарегистрирован: 07.02.2006
Olorin :
тыкаешь кнопку "создать фрагмент обшивки" - включается режим выбора точек, тыкаешь в разные места имеющейся модели (подвешенные к ней евенты запоминают автоматически отмапленные в пространство координаты накликанных точек)

Что-то мне кажется, что точек будет дофига. Если только точки (вершины) будут доступны для выделения только одного фрагмента общей геометрии.
    Добавлено: 19:38 30-01-2015   
Olorin
 70 EGP


Рейтинг канала: 1(6)
Репутация: 12
Сообщения: 97
Откуда: Хьёрвард
Зарегистрирован: 27.02.2006
БулерМэн :
Olorin :
тыкаешь кнопку "создать фрагмент обшивки" - включается режим выбора точек, тыкаешь в разные места имеющейся модели (подвешенные к ней евенты запоминают автоматически отмапленные в пространство координаты накликанных точек)

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

"Разные места имеющейся геометрии" - любые точки на уже существующей геометрии (внешние стороны отсеков, торчащие части скелета - построения крыльев для). С предпочтением вершин ранее заданных фрагментов обшивки.
_________________
Мы на многое не отваживаемся не потому что оно трудно; оно трудно именно потому, что мы на него не отваживаемся.
Сенека Старший
    Добавлено: 20:23 30-01-2015   
Minx
 912 EGP


Модератор
Рейтинг канала: 6(320)
Репутация: 136
Сообщения: 10417
Откуда: 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 кстати не самый ещё простой формат. Для ещё более простых случаев есть командная строка и её аргументы.

ТехноМаг :
Если не ошибаюсь, то можно вот таким образом: http://igroman14.livejournal.com/116218.html

Можно. Но очень поверхностный образ, можно сказать, стартовый.
_________________
μηδείς αγεωμέτρητος εισίτω
    Добавлено: 21:02 30-01-2015   
Olorin
 70 EGP


Рейтинг канала: 1(6)
Репутация: 12
Сообщения: 97
Откуда: Хьёрвард
Зарегистрирован: 27.02.2006
Minx :
По большому счету все. Если пункты не нужны, то лучше ini-like.

У xml при наличии схемы (которую можно сгенерить из написанного документа и подрихтовать руками) еще
+автодополнение по структуре (ощутимо упрощает и ускоряет написание самого конфига)
+автоматическая сериализация через кодогенерацию (ощутимо упрощает и ускоряет реализацию парсинга)
_________________
Мы на многое не отваживаемся не потому что оно трудно; оно трудно именно потому, что мы на него не отваживаемся.
Сенека Старший
    Добавлено: 21:22 30-01-2015   
Michael_Moon
 100 EGP

Рейтинг канала: 1(2)
Репутация: -2
Сообщения: 669
Откуда: РК, Кокшетау
Зарегистрирован: 15.02.2011
Как оказалось, юнька намного проще и грамотней сконструирована для построения ГУИ любой сложности. Куришь мануал и втыкиваешься в решения.
Так что, всем спасибо за помощь.

Что не исключает возможности постучания в личку Улыбка
    Добавлено: 21:25 30-01-2015   
БулерМэн
 410 EGP


Рейтинг канала: 2(21)
Репутация: 68
Сообщения: 1580
Откуда: Гороховец
Зарегистрирован: 07.02.2006
Michael_Moon :
юнька намного проще и грамотней сконструирована для построения ГУИ любой сложности.

то есть ты отказался от ini-файлов?
    Добавлено: 00:47 31-01-2015   
Michael_Moon
 100 EGP

Рейтинг канала: 1(2)
Репутация: -2
Сообщения: 669
Откуда: РК, Кокшетау
Зарегистрирован: 15.02.2011
БулерМэн :
Michael_Moon :
юнька намного проще и грамотней сконструирована для построения ГУИ любой сложности.

то есть ты отказался от ini-файлов?

Для ГУИ - да. На данном этапе реализации.
Но ведь игра не только из ГУИ состоит Улыбка
    Добавлено: 14:32 31-01-2015   
Minx
 912 EGP


Модератор
Рейтинг канала: 6(320)
Репутация: 136
Сообщения: 10417
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
Olorin :
У xml при наличии схемы

В общем случае XML берет во многом засчет развившейся в последение лет 5-10 инфраструктуры. Т.е. для длительных проектов есть существенная вероятность применения чего-то с XML. Соответственно, не придется переезжать с ini на XML или писать преобразователь.

Но. Если речь идет о конфигурации, то ini - это простейший файл и моментальный подхват в приложение как map/multimap. XML же это та ещё куча телодвижений и букв.

При этом если не тянуть логику в ini, то в дальнейшем при необходимости ini легко трансформируется в XML.
_________________
μηδείς αγεωμέτρητος εισίτω
    Добавлено: 17:15 31-01-2015   
БулерМэн
 410 EGP


Рейтинг канала: 2(21)
Репутация: 68
Сообщения: 1580
Откуда: Гороховец
Зарегистрирован: 07.02.2006
Если рассматривать движок GameMaker'а то загрузка данных из ini выполняется в один присест: указал секцию, указал имя параметра.
Можно сказать, что работа с ini на движке GM упрощена до безобразия. Несомненно на Unity скорее всего тоже все отлично с этим.
    Добавлено: 21:19 31-01-2015   
Michael_Moon
 100 EGP

Рейтинг канала: 1(2)
Репутация: -2
Сообщения: 669
Откуда: РК, Кокшетау
Зарегистрирован: 15.02.2011
БулерМэн :
Если рассматривать движок GameMaker'а то загрузка данных из ini выполняется в один присест: указал секцию, указал имя параметра.
Можно сказать, что работа с ini на движке GM упрощена до безобразия. Несомненно на Unity скорее всего тоже все отлично с этим.

Да, но в Юнити сейчас еще и работа с ГУИ упрощена до безобразия. Даже по сравнению, как это было пару лет назад, когда я предпринимал первые робкие шаги для визуализации калькулятора цусимского сражения.
Ини для Юнити будет хорош для инициализации всех глобальных переменных. Чтобы собрать их все в одну кучу, наподобие того, как это было сделано в ЗВ (файл АИ)
    Добавлено: 21:22 31-01-2015   
Minx
 912 EGP


Модератор
Рейтинг канала: 6(320)
Репутация: 136
Сообщения: 10417
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
Michael_Moon :
Ини для Юнити будет хорош для инициализации всех глобальных переменных.

Число глобальных переменных вообще лучше держать на значении 0.

Т.е. ini в системах, которые сложнее лабораторной работы на 1.5 часа должен быть распилен на разделы или множество типовых файлов.
_________________
μηδείς αγεωμέτρητος εισίτω
    Добавлено: 21:50 31-01-2015   
Michael_Moon
 100 EGP

Рейтинг канала: 1(2)
Репутация: -2
Сообщения: 669
Откуда: РК, Кокшетау
Зарегистрирован: 15.02.2011
Minx :
Michael_Moon :
Ини для Юнити будет хорош для инициализации всех глобальных переменных.

Число глобальных переменных вообще лучше держать на значении 0.

Т.е. ini в системах, которые сложнее лабораторной работы на 1.5 часа должен быть распилен на разделы или множество типовых файлов.

Если ты знаком с Юнити, то должен знать, чем проект отличается от готовой сборки. После компиляции этот файл снаружи виден не будет, т.к. сидит в ресурсах. А в проекте как раз удобно держать все глобальные в одном месте, чтобы не рыть скрипты, когда их число перевалит за несколько десятков/сотен.
Плюс, если прикручивать к юньке всякие надстройки, типа Антареса, НГУИ и прочего, то и подавно.
    Добавлено: 23:31 31-01-2015   
Minx
 912 EGP


Модератор
Рейтинг канала: 6(320)
Репутация: 136
Сообщения: 10417
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
Michael_Moon :
Если ты знаком с Юнити, то должен знать, чем проект отличается от готовой сборки. После компиляции этот файл снаружи виден не будет, т.к. сидит в ресурсах. А в проекте как раз удобно держать все глобальные в одном месте, чтобы не рыть скрипты, когда их число перевалит за несколько десятков/сотен.
Плюс, если прикручивать к юньке всякие надстройки, типа Антареса, НГУИ и прочего, то и подавно.

Множество распиленных файлов - это формат работы с исходниками. Загрузка в Юнити - это итоговый пакет сборки. Между ними - сборка. Которая в данном случае может быть автоматической. Т.е. несколько ini-файлов можно банально смержить bat-ником.

Сборка не всегда удобна и приемлима, потому даже не настаиваю.
_________________
μηδείς αγεωμέτρητος εισίτω

Последний раз редактировалось: Minx (00:06 01-02-2015), всего редактировалось 1 раз
    Добавлено: 23:46 31-01-2015   
БулерМэн
 410 EGP


Рейтинг канала: 2(21)
Репутация: 68
Сообщения: 1580
Откуда: Гороховец
Зарегистрирован: 07.02.2006
Minx :
Число глобальных переменных вообще лучше держать на значении 0.

Согласен. Поэтому выражение
Michael_Moon :
когда их число перевалит за несколько десятков/сотен.

выглядит как страшный сон.
    Добавлено: 15:20 01-02-2015   
Michael_Moon
 100 EGP

Рейтинг канала: 1(2)
Репутация: -2
Сообщения: 669
Откуда: РК, Кокшетау
Зарегистрирован: 15.02.2011
БулерМэн :
выглядит как страшный сон.

Это нормально. Чем писать километровые простыни, в которых запутаешься через неделю после написания, лучше разбить на несколько скриптов помельче, каждый из которых будет отвечать за свой маленький кусочек игры Улыбка
Ты разве не так делаешь?
    Добавлено: 15:23 01-02-2015   
БулерМэн
 410 EGP


Рейтинг канала: 2(21)
Репутация: 68
Сообщения: 1580
Откуда: Гороховец
Зарегистрирован: 07.02.2006
Michael_Moon :
Чем писать километровые простыни, в которых запутаешься через неделю после написания

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

добавлено спустя 3 минуты:
И да, при воздействии объектов, если это возможно, лучше не использовать глобальные переменные, а изменять локальные другого объекта напрямую. Если конечно вас не пугает выяснение обстоятельств, по которым "что-то пошло не так" Гы-гы

Последний раз редактировалось: БулерМэн (15:52 01-02-2015), всего редактировалось 3 раз(а)
    Добавлено: 15:51 01-02-2015   
Michael_Moon
 100 EGP

Рейтинг канала: 1(2)
Репутация: -2
Сообщения: 669
Откуда: РК, Кокшетау
Зарегистрирован: 15.02.2011
БулерМэн :
Так обычно делаю я, но это не значит, что это удобно всем.

Я говорил примерно о том же самом. Только управление глобальными (передаваемыми в код "в качестве аргумента") берет на себя (возможно и далеко не всегда) ini-файл. Таким образом глобальные сосредоточены в одном месте, где их легко можно найти и подогнать под нужные тебе параметры.

Неплохая реализация такого подхода сделана в ЗВ (правда там ini-файл вынесен наружу).
    Добавлено: 15:53 01-02-2015   
Канал Игры Мечты: «Техническая помощь в реализации самописных игр»
На страницу: Пред.  1, 2, 3, 4 ... 13, 14, 15  След.    Перейти:   Все страницы
  
Показать: 
Предыдущая тема | Следующая тема |
К списку каналов | Наверх страницы
Цитата не в тему: Я расслабился уже у тебя в профиле. (Romeo-must-die)

  » Техническая помощь в реализации самописных игр | страница 3
Каналы: Новости | Elite | Elite: Dangerous | Freelancer | Star Citizen | X-Tension/X-BTF | X2: The Threat | X3: Reunion | X3: Terran Conflict | X Rebirth | X4: Foundations | EVE Online | Orbiter | Kerbal Space Program | Evochron | VoidExpanse | Космические Миры | Онлайновые игры | Другие игры | Цифровая дистрибуция | play.elite-games.ru | ЗВ 2: Гражданская война | Творчество | Железо | Игра Мечты | Сайт
   Дизайн Elite Games V5 beta.18