- foxes
- Постоялец
foxes
Вперед!
IROV..
> Вперед!
Уже давно от туда.
IROV..
"По пятому каналу про жизнь электрика рассказывают."
Дальше что?
foxes
> В продолжении этому можно развить тему, поскольку уже непосредственные
> инструментальные элементы, в которые входят часть анимации, тирейны, колайдеры
> (разновидности) и прочие механизмы тоже по сути являются над слоем самого
> движка как и UI.
Тут очень важно правильно понимать термины. Залог однозначного понимания меж людей в однозначном понимании базовых терминов каждым. Самих по себе слов, к примеру. :)
Кой-кто, хоть и пытается использовать понятные нам с тобой слова, так и не удосужил обучить себя равнозначному с нами пониманию этих самых слов. А в результате мы имеем просто пустую трату человеческой энергии (и твоего личного времени, кстати). :)
Так вот. Да, твоя правда. Просто само понимание послоевой (слоеной) организации проекта само по себе подразумевает создание на каждом нижнем слое уровня абстракции для предоставления инструментария верхнему слою (API, читай).
Тут в сообществе лекций есть один хороший стрим про организацию проекта. Вот.
http://www.gamedev.ru/community/gamedev_lecture/articles/?id=571
foxes
> А как базовое Api с чего то скрипты должны брать. Это уже математика
> привязанная к конкретному объекту, ни чего сверх естественного нет,
> используется ли это в скриптах или языке.
Дело в том, что разработчиков низкого и среднего уровней вообще не стоит загружать подобными вещами. В скрипте, для среднего уровня, я допускаю подобные вещи только для облегчения труда техдиза.
Чтоб не грузить его структурами нижнего уровня по загрузке ресурсов и установке связей, я даю ему набор удобных функций: одной - создать объект и положить в него модель; другой - загрузить анимацию для модели и связать ее с моделью в объекте. Контент превращать в код - это самое последнее и самое неблагодарное дело (чисто мое мнение).
Stain
Попрошу без перехода на личности и хамства.
the_siv
а где это Stain перешел на личность и хамит? )
>>Але, марсианин. как слышно?
В прочем, может показалось, я вообще сначала подумал, что это обращение ко мне...
the_siv
У меня нет оснований и желаний грубить или хамить кому-либо.
А на "ты" я всегда и ко всем обращался, люди это только с позитивом принимали. :)
Ок, так и к чему позитивному пришли? К решению там какого-нибудь насущного вопроса, например, не?
Да вроде все так же - ни к чему. :)
Лично я концепций не вижу. Нет, с моей точки зрения, перспектив у начинания. Пока что нет.
Гитхаб есть, Сив? Организуемся мож? Трелло + организация на гитхабе. Сделаем роадмап, пулл тасков, запланируем основные вехи с этапами?
Я сюда вообще вклинился потому что мне захотелось поделиться имеющимися знаниями.
Stain
Гитхаб был, удалил репозиторий за ненадобностью... Так эта! Делиться знаниями - это хорошо, расскажи что-нибудь интересное. Например, расскажи общее устройство движка как ты его видишь.
А мне лично интересно про spine, но это вопрос к IROV.., я так понимаю ты его использовал? Какие плюсы/минусы, подводные камни и т.д.
the_siv
Гитхаб, если что, нужен однозначно. Если планируется коллективная разработка, то гитхаб обязан иметься или все будет очень плохо.
Давай луч я про спайн рсскажу :) Я с ним работал, ковырял его, оптимизировал и понял что в нем не так.
Плюсы: 2D скелетка - это супер. В пакет спайна включено очень много плюх: простые костные анимации, IK, различного рода зависимости, скины объектов, возможность компановать все в одну текстуру, поддержка различных графических элементов на костях (спрайт, FFD, еще что то было). Доступен блендинг анимаций, разложение последовательностей анимаций с блендингом на отдельные дорожки (треки).
Минусы : формат минусую однозначно - json + LibGDX Atlas - это плохо. Все расчеты делаются только на CPU девайса. PureC Runtime у спайна очень-очень-очень тяжелый (у меня для такого кода есть только одна фраза : Так не пишут!).
Если, максимум, на экране понадобится использовать 5-10 скелетов, то все можно использовать из коробки. Иначе... Иначе становится сложнее.
Stain
> Просто само понимание послоевой (слоеной) организации проекта само по себе
> подразумевает создание на каждом нижнем слое уровня абстракции для
> предоставления инструментария верхнему слою
Я в этом плане пытаюсь реализовать большую прозрачность от высокого до низкого уровня - но это для производительности. Очень много абстракций в закрытом от пользователя коде не помогает проекту, но усложняет его разработку их отсутствие. Собственно ты уже об этом написал....
Stain
> Контент превращать в код - это самое последнее и самое неблагодарное дело
Это уже творчество, кто как проявляет себя в нем...
Тут есть момент когда такого рода код превращается в очень удобную визуальную блок схему с которой очень интересно и удобно работать. Но это когда уже есть ui и уровни абстракции между собой настолько прозрачны, что прямое использование блока подразумевает использование метода "низкого уровня". За счет положение всей абстракции за ширмой UI и объема функциональности движка позволяет простым низкоуровневым методом управлять высокоуровневым объектом абстракции/приложения.
Это уже разница между визуальным функциональным и принятым и используемым визуальным объектно ориентированным методом моделирования приложения.
Столкнулся со всей это иерархичностью проекта в QT это конечно хорошо для разработки в большой компании, но когда смотришь на это с точки зрения черного ящика с входом и выходом, а внутри него оказывается бесконечная фрактальная абстракция различная по узору и сколько ты не опускаешься натыкаешься на новую модель фигуры, которая по сути своей структуры ни чем не отличается от предыдущего уровня масштаба архитектурной абстракции. Тот же QML и связанные с ним инструменты это еще 3 дополнительных слоя взаимосвязей объектов между собой, которые просто клонируют и "портируют" данные, кроме самого QT.
В общем это мое ИМХО и я не сторонник таких завихов (и велосипед).
foxes
> Я в этом плане пытаюсь реализовать большую прозрачность от высокого до низкого
> уровня - но это для производительности.
Этож организация подсистем. :)
Это две осевых парадигмы планирования: слои и подсистемы. Их не две всего, есть и пайпы/файберы, и микроядро, метаслои... куча их. Но слои с подсистемами (подобно MVC, как самая популярная идеома) используются чаще всего. И очень часто они используются вместе.
А еще их часто путают. :)
foxes
> Это уже творчество, кто как проявляет себя в нем...
Такие вещи хороши для создания прототипов, безусловно. Когда скорость разработки и достижение строго поставленного результата превыше всего.
Если и делать такое в своем движке, то только и строго в отдельной ветке. Тут Git станет безупречным помошником, с его системой локальных копий и веток переключиться с боевого кода на "прототипный" проблемы составлять не должно.
Боевое двигло, как продакшен код, должно быть однозначно избавлено от подобных вещей. Не просто по техническим причинам, а в первую очередь чтоб ни у кого из команды (особенно новичков, джуниоров и *дизов) соблазна не возникло использовать этот код "в бою".
Тема в архиве.