на разных клиентах могут быть (и будут) разные расхождения. Поэтому последняя инстанция, похоже — это все-таки сервер. Вместо того, чтоб на сервере сместить игрока на полметра, Можно на клиенте подкорректировать позицию персонажа. И чтоб не было «скачка», надо попытаться сдвинуть его «естественно». Если движется — скорректировать скорость перемещения. Если уже стоит — пусть сделает шаг в нужную сторону. Статья http://www.gamasutra.com/view/feature/131638/dead_reckoning_latency_hiding_for_.php — для меня в свое время была отправной точкой при разработке мультиплеера.
нет, Вы не ошибаетесь — действительно для флэша существует много решений для СОЗДАНИЯ 2D анимации.
А вот автор оригинальной статьи (Jochen Diehl), помянутой в самом начале, которую он озаглавил как «Skeletal Animations» предложил способ не создания анимации, а КОПИРОВАНИЯ уже существующий анимации с любого раскадрованного движения.
Поскольку моя заметка писалась «по мотивам» статьи с названием «Skeletal Animations», то и я счел возможным в скобках «примазаться» к плодам его работы.
Джоинты (joint — сустав (англ.)) — в оригинальной статье автор отмечал точками в ключевых кадрах суставы. Если же фигуру «подключить» к физическому движку в качестве рэгдола, то обычные joint (суставы) могут стать специальными joint (сочленениями).
Наверное, перед моей заметкой, мне все-таки стоило переписать статью автора идеи — тогда не возникло бы столько недопонимания (я и сам при первом прочтении не понимал, при чем тут «скелетная анимация»).
Название «Skeletal Animations», как мне кажется, было дано ради звучности, привлечения внимания. Ведь идея описывалась в далеком 2007 году — не было тогда еще для флэша сегодняшнего инструментального разнообразия. Ну и как имя для JavaScript сделали очень похожим на популярный тогда Java, так и Jochen Diehl назвал статью «Skeletal Animations».
метод, предложенный автором (Jochen Diehl) не предусматривает «получения» ключевых позиций, он НЕ создает анимацию, а именно КОПИРУЕТ прямо из раскадровки записи уже «готового движения». Затем просто соединяет точки линиями (в статье, на которую я ссылаюсь, все подробно описано).
Мне кажется, что между нами сложилось некоторое недопонимание.
1. это не скелетная анимация — в первом же предложении отмечено.
это нежелание моделировать.
это попытка копировать (мне неучу, кажется, что скопировать и чуть откорректировать в определенных ситуациях проще и дешевле, нежели моделировать с нуля).
2. всегда завидовал умениям и знаниям студентов теормеха — я, к сожалению, был студентом медвуза.
3. что русскому хорошо, то немцу смерть — без претензий. Да — статья от неуча. Но, нет предела совершенству — научусь. И благодаря обсуждениям в том числе. Спасибо за это.
Виноват, если не смог ясно объясниться в рамках статьи.
ага, не ответил — виноват. почему-то принял Ваше сообщение за рекламу (поздно было, похоже), хотел было было ответить… а потом подумал, что на рекламу обычно не отвечают
понятно. это не серебряная пуля
смысл же для меня, например, подробнее если:
1. нужна 2D анимация, которую можно было бы сделать в куче продуктов а-ля dragonbones.effecthub.com/demo.html. НО! для этого надо изучить какой-нибудь из продуктов, чтоб понять, а годится ли? а удобен ли? а смогу ли я в нем разобраться? научиться моделировать? (одну из статей я обязательно посвящу тому, как «натянуть» скины на эти точки, используя РАЗНЫЕ проекции)
2. метод «инверсной кинематики» (спасибо, не знал) позволяет это сделать легко (в рамках конкретной узкой задачи, конечно) БЕЗ моделирования — перенося точки хоть из полюбившегося кино
3. при этом можно разнообразить типовые actions путем нехитрых манипуляций, описываемых в статье.
4. далее, на эти точки, понятно, легко цепляется реальный рэгдолл — чтоб умереть персонажу. или чтоб плавно сделать переход между разными actions. зачем он еще нужен?
5. хочется максимально облегчить код — не привлекать сторонние библиотеки без надобности — ради потенциальной кроссплатформенности (полезного кода ведь там только массив с точками, и «интерполлятор», остальное выносится в редактор)
Я тоже, не специалист, поэтому воспользуюсь определением из википедии, а потом сопоставлю его с вариантом из статьи: «Скелетная анимация заключается в том, что моделер создаёт скелет, представляющий собой как правило древообразную структуру костей, в которой каждая последующая кость «привязана» к предыдущей, то есть повторяет за ней движения и повороты с учётом ИЕРАРХИИ в скелете». Ключевое слово — иерархия. Если в скелетной анимации я «дерну за локоть», то дернется и кисть, В настоящем варианте — это просто точки без иерархии. Эти точки, скорее, напоминают технологию motion capture — копирование движения. С помощью уже добавлений, описанных мной, можно характер этих движений до некоторой степени разнообразить.
абсолютно с Вами согласен по-поводу неправильности представления пространства. Более того — в Вашем варианте можно легко изобразить черную дыру, или даже «червоточину»!
остановился же на варинате сетки я главным образом потому, что не могу представить, как будут пересекаться концентрическими окружностями рядом расположенные массивные объекты (картинки тоже не нашел)
мне статья не понравилась — просто калейдоскоп какой-то:
1. на мой вкус, слишком много «воды», связанной с внутренними метаниями автора
2. не люблю в принципе супер-обширные темы, пытающиеся уместиться пусть и в цикл статей, как-то «написание компьютерной игры» — иным авторам в полноценных книгах места не хватает
3. было бы интересно почитать об опыте использования какого-нибудь КОНКРЕТНОГО инструмента, применительно к флэшу — то же ЮНИТ-тестирование. Сколько ни ЧИТАЛ о нем, ну не могу поверить в его удобство и целесообразность применения именно в AS-проектах (желательно с цифрами, типа сколько времени на сопровождение кода уходило ДО, и сколько ПОСЛЕ внедрения тестирования)
4. просто кровь из глаз брызжет, когда натыкаешься на подобное: «если мы пишем библиотеку «на экспорт», то возникает вопрос о предоставлении потребителю достойной документации» — это же статья для НАЧИНАЮЩИХ и ЗЕВАК, какой экспорт?!.. Это же АБСТРАКТНАЯ игра — кому нужна документация?
ЗЫ: хотел ответить, что хабр создан не для любви. Но потому «расписался», и получилось, что отвечать надо было автору, а не комментатору
Классный проект — простенький, без лишних наворотов, с открытым кодом(!)
1. если думать только о десктоп-приложениях, то можно было бы смело попытаться прикрутить библиотеку через Alchemy. Я и попробую позже. Единственно, смущают негативные отзывы о работе Alchemy на мобильных приложениях. Ну — будет повод разобраться.
2. если Alchemy не оправдает ожиданий, можно подсмотреть, как они реализовали стенки (надеюсь, без физики обошлись) — можно будет подсмотреть. А то я пока не решил, как со стенами вопрос решить без хитростей (открытые пространства; широкие коридоры, и если откинуло взрывом на стенку — сразу несовместимые с жизнью травмы )
А вот автор оригинальной статьи (Jochen Diehl), помянутой в самом начале, которую он озаглавил как «Skeletal Animations» предложил способ не создания анимации, а КОПИРОВАНИЯ уже существующий анимации с любого раскадрованного движения.
Поскольку моя заметка писалась «по мотивам» статьи с названием «Skeletal Animations», то и я счел возможным в скобках «примазаться» к плодам его работы.
Джоинты (joint — сустав (англ.)) — в оригинальной статье автор отмечал точками в ключевых кадрах суставы. Если же фигуру «подключить» к физическому движку в качестве рэгдола, то обычные joint (суставы) могут стать специальными joint (сочленениями).
Наверное, перед моей заметкой, мне все-таки стоило переписать статью автора идеи — тогда не возникло бы столько недопонимания (я и сам при первом прочтении не понимал, при чем тут «скелетная анимация»).
Название «Skeletal Animations», как мне кажется, было дано ради звучности, привлечения внимания. Ведь идея описывалась в далеком 2007 году — не было тогда еще для флэша сегодняшнего инструментального разнообразия. Ну и как имя для JavaScript сделали очень похожим на популярный тогда Java, так и Jochen Diehl назвал статью «Skeletal Animations».
Мне кажется, что между нами сложилось некоторое недопонимание.
это нежелание моделировать.
это попытка копировать (мне неучу, кажется, что скопировать и чуть откорректировать в определенных ситуациях проще и дешевле, нежели моделировать с нуля).
2. всегда завидовал умениям и знаниям студентов теормеха — я, к сожалению, был студентом медвуза.
3. что русскому хорошо, то немцу смерть — без претензий. Да — статья от неуча. Но, нет предела совершенству — научусь. И благодаря обсуждениям в том числе. Спасибо за это.
Виноват, если не смог ясно объясниться в рамках статьи.
смысл же для меня, например, подробнее если:
1. нужна 2D анимация, которую можно было бы сделать в куче продуктов а-ля dragonbones.effecthub.com/demo.html. НО! для этого надо изучить какой-нибудь из продуктов, чтоб понять, а годится ли? а удобен ли? а смогу ли я в нем разобраться? научиться моделировать? (одну из статей я обязательно посвящу тому, как «натянуть» скины на эти точки, используя РАЗНЫЕ проекции)
2. метод «инверсной кинематики» (спасибо, не знал) позволяет это сделать легко (в рамках конкретной узкой задачи, конечно) БЕЗ моделирования — перенося точки хоть из полюбившегося кино
3. при этом можно разнообразить типовые actions путем нехитрых манипуляций, описываемых в статье.
4. далее, на эти точки, понятно, легко цепляется реальный рэгдолл — чтоб умереть персонажу. или чтоб плавно сделать переход между разными actions. зачем он еще нужен?
5. хочется максимально облегчить код — не привлекать сторонние библиотеки без надобности — ради потенциальной кроссплатформенности (полезного кода ведь там только массив с точками, и «интерполлятор», остальное выносится в редактор)
остановился же на варинате сетки я главным образом потому, что не могу представить, как будут пересекаться концентрическими окружностями рядом расположенные массивные объекты (картинки тоже не нашел)
1. на мой вкус, слишком много «воды», связанной с внутренними метаниями автора
2. не люблю в принципе супер-обширные темы, пытающиеся уместиться пусть и в цикл статей, как-то «написание компьютерной игры» — иным авторам в полноценных книгах места не хватает
3. было бы интересно почитать об опыте использования какого-нибудь КОНКРЕТНОГО инструмента, применительно к флэшу — то же ЮНИТ-тестирование. Сколько ни ЧИТАЛ о нем, ну не могу поверить в его удобство и целесообразность применения именно в AS-проектах (желательно с цифрами, типа сколько времени на сопровождение кода уходило ДО, и сколько ПОСЛЕ внедрения тестирования)
4. просто кровь из глаз брызжет, когда натыкаешься на подобное: «если мы пишем библиотеку «на экспорт», то возникает вопрос о предоставлении потребителю достойной документации» — это же статья для НАЧИНАЮЩИХ и ЗЕВАК, какой экспорт?!.. Это же АБСТРАКТНАЯ игра — кому нужна документация?
ЗЫ: хотел ответить, что хабр создан не для любви. Но потому «расписался», и получилось, что отвечать надо было автору, а не комментатору
1. если думать только о десктоп-приложениях, то можно было бы смело попытаться прикрутить библиотеку через Alchemy. Я и попробую позже. Единственно, смущают негативные отзывы о работе Alchemy на мобильных приложениях. Ну — будет повод разобраться.
2. если Alchemy не оправдает ожиданий, можно подсмотреть, как они реализовали стенки (надеюсь, без физики обошлись) — можно будет подсмотреть. А то я пока не решил, как со стенами вопрос решить без хитростей (открытые пространства; широкие коридоры, и если откинуло взрывом на стенку — сразу несовместимые с жизнью травмы )
Большое спасибо за ссылку