Anthill Framework. Анонс
Настало время анонсировать и немного рассказать о своем фреймворке, который я использую для разработки своих игр. Но пока, к сожалению, без публикации самого фреймворка.
?ногда у меня краснеют уши и я прям левой пяткой чувствую, что где-то там, на нашей просторной планете возникают такие возгласы: «Ээй! Где-же опять Карлов? Пообещал, значит, оживить блог, писать чаще и куда-то опять пропал почти на месяц!?». Да, пропал, но пропал не зря, все то время и даже больше, которое я не посвящал блогу я активно копал в Minecraft дорабатывал свой Framework, чтобы поскорее отдать его вам на растерзание! ? сейчас я уже готов заявить, что я его более менее «доработал» и он получил гордую подпись «Alpha»! :) Доработал в кавычках, и приставка Alpha как бы намекает, что это далеко не финал и скорее всего там еще полно недостающего функционала, шероховатых углов, багов и недочетов, но это уже хотя бы то, что мне не стыдно будет показать и отдать в использование.
Почему свой «велосипед»!?
Почему свой фреймворк, почему не выбрать какой-нибудь из тех, что уже существуют? — спросите вы. Прежде, чем я решился на разработку своего фреймворка, я внимательно посмотрел на некоторые другие фреймворки с надеждой найти уже что-то, подходящее мне среди известных фреймворков. Я посмотрел такие движки как Flixel, FlashPunk и PushButtonEngine (последний более не поддерживается) — все эти движки оказались по-своему хороши, но где-то мне не понравилась структура, где-то работа производится исключительно со стандартными Sprite и MovieClip, в общем идеального кандидата для моих нужд не оказалось. К идеалу был очень близок Flixel, но он заточен исключительно под пиксельную (растровую) графику, без возможности кэшировать клипы, к тому же он не заточен на работу с Box2D и имеет свой весьма простой физический движок, плюс еще некоторые недостатки, которые без полноценного хирургического вмешательства в этот движок не позволили бы мне создавать игры, так как я привык это делать. Поэтому взяв за основу идею Flixel, я решил сделать свой фреймворк, такой, как мне нравится, и заодно позаимствовать интересные и удачные на мой взгляд решения из всех этих вместе взятых движков понемножку :)
Anthill Framework
Свой фреймворк я решил назвать Anthill (муравейник), но не потому, что это созвучно с Molehill, просто, как известно, моё имя начинается на Ant (муравей) и первоначальная идея интерпритации этого слова была как Ant hill — то есть «кучка ант'а», хотя и в интерпретации «муравейника» получается еще интереснее. Любой фреймворк состоит из множества классов, которым отведены разные функции и задачи, и все вместе эти классы делают одну большую работу и создают некий организм/механизм, в общем почти как муравьи в муравейнике :) Таким образом, в моем фреймворке каждый класс получил почетный префикс Ant, что очень похоже на префикс Flx в фреймворке Flixel. Но, помимо логичности и похожести на Flixel, польза от этого заключается и в том, что названия классов моего фреймворка не будут пересекаться с названиями классов в ваших и моих играх, что очень удобно, тем более при условии, что игровые классы должны наследоваться от классов фреймворка. Так что если вам доведется работать с Anthill, то печатая каждый раз:
var actor:AntActor = new AntActor();
Не думайте о том, что вы пишете сокращение моего имени — на самом деле вы пишите актер:МуравейАктер = новый МуравейАктер(). ;)
Что он будет уметь?
Сразу хочется громко заявить, что не стоит рассчитывать на какой-то супер-дупер инструмент, который позволит создавать вам игры как из конструктора. Нет, тут на самом деле все намного хуже, хуже даже, чем у Flixel и других интересных движков... Пока хуже. Суть движка в текущем состоянии заключается в том, что в нем собраны и тесно переплетены разные интересные и полезные решения, упрощающие создание игр на Flash, но при этом самих каких-либо игровых заготовок, конечно, же нет.
Anthill начал свое рождение с кэширования векторных клипов в растр на лету и встал на ноги благодаря «ручному рендеру». Реализация рендера пока не идеальна, но отлажена и работает достаточно хорошо. При растеризации векторных клипов отсекается все лишнее из каждого кадра автоматически, реализация такой растеризации позаимствована у Scmorr из его статьи на блогах — несмотря на то, что изначально у меня с этим были проблемы при внедрении в растровый рендер, я все же напрягся и разобрался с этим вопросом раз и навсегда. Рендер, как и рендер во Flixel, разделен на два метода: первый, простой и быстрый метод copyPixels() применяется для анимаций без каких-либо трансформаций, второй, более сложный, работает с объектами, для которых были сделаны какие-либо трансформации типа scale, rotation или blend. Метод отрисовки, конечно же, выбирается автоматически, и разработчику не нужно переживать об этом, как и о том, какие объекты попадают в область видимости, что нужно отрисовывать или вовсе удалить из игровой структуры, чтобы не уходили ресурсы на обработку невидимых объектов — все это делается автоматически. Более того, я позаботился и о камерах, реализация камер похожа на камеры во Flixel, правда сейчас они не настолько функциональны, но разделить экран на 2 и более частей совсем несложно и игровые миры теперь нет необходимости двигать, как это приходилось делать с обычными клипами. Кэширование анимаций есть, классы для работы с анимациями и их рендером тоже есть, теперь уж и без отладочных инструментов таких как профайлер производительности, консоль и монитор для слежения за значениями переменных — никак не обойтись!
Все отладочные классы объединяются одним классом AntDebugger, который процессит необходимые из них и управляет их окнами. Окошко каждого отладочного класса можно перетащить, закрыть когда не нужно и открыть когда понадобится. Корни консоли уходят в класс консоли, о котором я рассказывал здесь, а класс профайлера — это модернизированный SWFProfiler и дополненный статистикой по временным затратам на что-либо: сколько там на апдейт объектов времени понадобилось, сколько на рендер, на физику и т.п. В общем круто замахнулся, тут пришлось и остальные мелочи сделать, так чтобы все было комфортно.
? вот тут я как раз хочу немного поругать Flixel за то, что он не умеет работать с группами объектов. То есть с группами то он работать умеет, но вот так, чтобы вложить один спрайт в другой или даже сложить кучу спрайтов в группу, а потом их все лихо повернуть на 45 градусов — фигушки. Во всяком случае, ковыряя исходники Flixel, я так и не понял, как это сделать так же казуально, как я привык это делать с клипами и спрайтами. Невозможность кэшировать клипы на лету в растр и работать с ними, как с анимациями — это для Flixel еще хоть как-то простительно (олдскульный фреймворк и все такое), то невозможность вращать и двигать группы — это прям удар ниже пояса. В Anthill все визуальные объекты унаследованы от сущности AntEntity, которая представляет собой базовый не визуальный класс для работы с группами, то есть, в Anthill можно вкладывать объекты друг в друга, двигать, вращать и т.п. прямо как старые добрые MovieClip и Sprite.
Если в Зомботроне мне еще приходилось делать кнопки и текстовые метки обычными клипами и TextField'ами, то буквально на днях я добавил в Anthill пару базовых элементов GUI: AntButton и AntLabel. Оба эти класса очень похожи на AntActor и имеют все аналогичные плюшки. Да-да, текстовые метки и кнопки можно вращать, скэйлить, перекрашивать в разные цвета и вкладывать друг в друга.
Так же в Anthill есть и классы для работы с мышкой, клавиатурой и SharedObject, которые хоть и имеют некоторые переделки, но все же фактически 1 в 1, как у Flixel.
А вот работа со звуками в Anthill существенно отличается. Сейчас уже сложно сказать, в чем именно отличия работы со звуками, например от Flixel, так как реализация звуковых классов осуществлялась еще в конце прошлой зимы. Но точно могу сказать, что звуки добавляются в менеджер звуков по именам и могут быть вызваны через глобальное хранилище движка по ключевому имени, в качестве цели может быть указан некий объект и в таком случае будет рассчитываться стерео эффект, исходя из настроек звукового менеджера, положения камеры и т.п. Более того, мне как разработчику, работающему удаленно со звуковиком, имеется острая необходимость воспроизводить внешние файлы типа *.mp3, которые должны располагаться где-нибудь в папке рядом с игрой, чтобы звуковик мог без моего участия легко и быстро подставлять свои звуки в игру и таким образом тюнить их столько, сколько ему угодно, не мучая при этом меня перекомпиляциями игры. Что собственно и реализовано в классе звукового менеджера. Таким образом, с использованием звукового менеджера игра не подозревает о звуках, мы просто командуем звуковому менеджеру, что он там должен пиликать, а класс менеджер уже сам разбирается что и куда ему воспроизводить.
Поскольку большинство моих игр сделано с использованием отличной физической библиотеки Box2D, то не обошлось и без классов надстроек над Box2D, которые собственно позволяют забыть о непривычном синтаксисе движка Box2D (который не соотвествует гайдлайнам ActionScript, так как портирован с C++ и соотвествует его гайдлайнам, ну и чтобы соотвествовать родной документации), и неудобных величинах измерений. Вообще про надстройку над Box2D хочется рассказать отдельно и по-больше, но это уже выйдет явно за рамки анонса всего фреймворка. Скажу, пожалуй просто, что надстройка позволяет быстро и удобно создавать/удалять физические тела, джоинты и т.п., так же позволяет забыть про их синхронизацию с графическими сущностями. Отладочный рендер физического движка переделан таким образом, что рендерится в общий буфер камер, то есть, чтобы видеть отладочную прорисовку физики - не придётся работать с обычными спрайтами и при скролле двигать эти самые спрайты, чтобы дебаг отрисовка физики совпадала с графическим контентом. В общем, все максимально синхронизированно. Так же есть и несколько классов помощников, которые позволяют легко работать с масками для столкновений и создавать сложные составные объекты из клипов c заданными трансформациями (кто пытался создать рэгдолл, повёрнутый на N градусов, возможно поймет, что я имею в виду :)). Но тут есть НО: надстройка будет опубликована немного позже, чем сам Anthill так как над ней мне еще надо поработать, и в первую очередь перевести её на Box2D 2.1a, а то ведь я «динозавр», по старинке работаю с 2.0.1. В общем для физической надстройки над Box2D будет свой пост с подробным описанием тамошних «муравьев».
А когда, когда будет?
Anthill целиком и полностью с примерами и подробным описанием будет выложен на GitHub в течении 1-2 недель (это я так с запасом говорю), но пока без физических надстроек. В данный момент я работаю над примерами, которые быстро и наглядно покажут не только базовые возможности, но и на которых можно будет разобраться, как весь этот «муравейник» можно будет использовать в своих проектах. Плюс ко всему этому я напишу большую и подробную запись, в которой будет рассказано какой «муравей», зачем нужен, и как его «готовить». Ну, и помимо всей этой информации, все исходники напичканы весьма подробными комментариями, причем на русском языке, так что не разберется только самый ленивый, ну или кто читать не умеет :)
Ну и сколько, сколько!?
Это я сразу этот вопрос поднимаю, чтобы все было прозрачно и ясно: исходники отдаю совершенно безвозмездно для абсолютно любого использования. Деньги мне брать — совесть не позволяет, так как с выходом Molehill, методы copyPixels() и draw() потеряли немного в акутальности, да и идеи собранные в «муравейнике» не являются моим интеллектуальным трудом в полной мере. Как можно судить из анонса большинство идей и реализаций взято совершенно из разных мест и организованны в Anthill. В общем "за что взял, за то и продаю" :)
Но все же, взамен я буду рад получить критику, пожелания, информацию о том, как можно что-то улучшить, оптимизировать, исправить и вообще — я надеюсь, что вместе с теми, кому это реально будет интересно, мы сделаем только лучше и надежнее.
А что с аппаратным ускорением?
Такой вот еще маленький «напоследок»: опережая вопросы по поводу аппаратной поддержки и Molehill в целом — пока не знаю, что ответить. Не задумывался еще об этом. Пока не все порталы полноценно поддерживают Stage3D — я не спешу переходить на Stage3D. Тем более движок случился случайно, то есть можно сказать что слепился из того, что было. ?гры мне нравится делать определенно больше, чем движки, поэтому разработка игр более приорететна для меня, и заниматься разработкой своего движка с аппаратной поддержкой ради того, чтобы быть на передовых — мне не так интересно, мало опыта, времени и сил. В общем, в одиночку такой груз брать не буду. Так что аппаратная поддержка случится только тогда, когда она реально будет нужна мне и моим играм ;)
Антон, вы молодец!
Думаю было бы отлично, если бы выложили и надстройку под Box2d 2.0.1 - на нем ведь многие люди тоже еще сидят. А там бы уже каждый выбирал под какую версию.
Спасибо!
Все время удивляюсь Вашему трудолюбию. С удовольствием посмотрю на Framework!
Последний Safari вместе с FP 11.4 стал поддерживать MBP Retina (обнаружил случайно, анонса этого не нашел). Думаю, что и Chrome скоро подтянется.
Соответственно все изначально растровые или динамически растеризованные игры выглядят на ретине не очень приятно. Например, в Kingdom Rush бросаются в глаза растровая карта, объекты и качественные векторные шрифты, векторные элементы интерфейса.
Поэтому было бы здорово в фреймворк добавить, например, следующее: для ретины растеризовать спрайты в два раза более высоком разрешении, но выводить в прежнем масштабе и без copyPixels. ?ли через Stage3D.
Правда, я пока не нашел способа, как определить, что перед нами пользователь с ретина - stageWidth и stageHeight остаются прежними.
Хотел добавить, что мой пост выше - просто пожелания.
? как потенциальный пользователь с нетерпением жду релиза фреймворка!
Не перестаю удивляться – сделать свой движек и дошлифовать его до паблик версии – очень круто. Жду релиза, название что надо :)
Очень интересно! Спасибо!
Планируется ли выпуск WYSIWYG редактора для игр как часть этого движка?
На конец то этот день свершился:) ? MineCraft классная штука
Круто)) давно хочу свой сделать. С нетерпением жду твой муравейник .. покапаться!)
молодец!
Антон, где вы берёте силы и почём?
Этот фреймворк я действительно ждал! Совсем недавно воровал пару функций из AntMath, а весь проект пестрит AntActor`ами. Но фреймворк задаром, это приятно удивило (и хоть вы говорите, что там есть вещи, которые вам не принадлежат, но собрать всё в единую работающую систему - это нужно постараться)
?нтересно, один я, читаю этот блог с чаем и печенюшками?
Да тут адепты у Антона уже появились, на пустом месте создают ажиотаж и поют дифирамбы, при всем уважении.
@Komizart,
"Кучка" звучит немного грубо. Думаю это слово больше подходит к вашим играм.
@ВП, почему нет? Написать игру, потом фреймворк и выложить это в открытый доступ совсем непростое дело.
класс!
С нетерпением ждем! Обрадовало, что ты планируешь делать детальную документацию с примерами - уже руки чешутся все посмотреть! :)
Антон, ты нереально крут!
Жду с нетерпением опубликования альфы!
Удачи!
Это конечно очень здорово, но не лучше ли перейти на Nape вместо Box2D? Nape гораздо быстрее, а во всех ваших предыдущих проектах слабым местом является именно тормоза из-за физики.
Это просто невероятно. Присоединяюсь к остальным, вы невероятно трудолюбивы. Да и планку держите высоко.
@Rise, в любом случае прежде чем выкладывать физические надстройки — их еще надо немного отрефакторить и подготовить информацию. Поэтому это в любом случае будет немного позже сделано.
@programmer, MBP с ретиной в данный момент весьма экслюзивная штука! :) Поэтому пока можно особо не переживать по поводу HD графики в играх. Когда Apple хотя бы на 50% обновит свою продукцию на ретину, тогда можно уже начинать заботится об этом, но все же основная пользователей сидит на PC где даже слова такого не знают.
Но скажу, что поддержку ретины можно сделать в несколько строчек, во всяком случае камрады которые экспериментировали с Air, смогли легко и быстро добавить атрибут scale в класс AntAnimation который позволяет получать растр графики под ретину :)
@smck87, не смотря на то, что я выложу фреймворк — это будет лишь альфа версия, поэтому дополнений и исправлений будет еще вагон и тележка :)
@Vadim,
> Планируется ли выпуск WYSIWYG редактора для игр как часть этого движка?
Не уверен, так как все (включая уровни) я создаю во Flash IDE и фремворк разрабатывался с расчетом на то, что контент для игры создается во Flash IDE. То есть по сути своей Flash IDE и есть этот самый редактор.
С одной стороны это вроде недостаток, так как графический и игровой контент ограничивается Flash IDE, с другой стороны Flash IDE уже есть и он имеет кучу классных возможностей :)
@Davros, Nape безусловно хороший физический движок и я поглядываю в его сторону, но отпугивает пока небольшое количество документации и примеров, а так же в случае портирования игр на какие-либо другие платформы, придётся портировать еще и Nape или возвращаться на Box2D.
Box2D 2.1a по быстрее чем предыдущая версия. Я пользовался старой версией во всех своих играх.
Всем спасибо за отзывы и поддержку! Надеюсь вам понравятся мои наработки. Сейчас работаю над примерами и описаниями, тестирую и выгребаю баги охапками.
Спасибо за движок.
С релизом выложите побольше примеров использования возможностей движка, чтобы неискушенный пользователь мог не разбираясь в устройстве сразу увидеть чего он может достигнуть начав использовать вашего Анта.
Ребята девчата, начинающие игроделы, если есть желание приобрести видео курс по созданию flash игр - Box2d Basic, но по каким либо причинам не выходит выложить 2276р. То загляните сюда - http://t.co/Y1fSN3PP там ребята скидываются на покупку цифровой версии курса, сейчас их троя.
Привет, Антон.
Выложить движок в паблик - молодец! Я пока не решился этого сделать, хотя допиливаю вторую версию двига и она мне уже не нравится - хотелось бы все переделать )) (перфекционист).
На счет Nape - настоятельно рекомендую разобраться с ним!
Во-первых, информации по нему уже предостаточно.
Во-вторых, он активно развивается и поддержка со стороны Луки просто огромна. Движок также тестируется на мобильных платформах.
В-третьих, ты увидишь, что он намного легче, быстрее и мощнее чем Бокс.
В-четвертых, Бокс 2.1 уже более двух лет как мертв и в нем, кстати, есть баги и мемори лики, я хочу сказать, что версия 2.0.2 хоть немного медленней но зато стабильней (да и я лично не вижу смысла работать с мертвым двигом, тем более если есть такая замена как Nape).
В ближайшем времени Лука обещался выкатить новый мажорный релиз - там будет много изменений и в частности будет добавлен CCD.
Релиз сделает изменения в АП?, потому если сейчас влом с ним разбираться, тогда можно начать после этого релиза.
Ну конечно же - хозяин барин ))
Есть один вопрос по тому как реализован алгоритм определения видимости объекта (попадает в экран или нет). Была использована регулярная сетка или quad-tree ?
Спасибо
@VirtualMaestro, желание все взять и переписать появляется у каждого программиста в процессе.
? многие настойчиво советуют забить на это желание. Потому что так вообще никогда не доведете дело до конца.
Круто! Молодец.
@VirtualMaestro, про Nape заинтриговали прям. Пошел смотреть примеры и документацию. Производительность порадовала, документация не очень удобная, но в целом вникнуть можно. Демки не очень порадовали (разве что динамическая разрушаемость объектов/изменения шейпа — выглядит здорово). Основной недостаток для меня оказался в том, что движок в *.swc — нет возможности заглянуть в код и подглядеть, что и как там работает чтобы это правильно использовать или если методы какие забыл :) Но если делать надстройку над Nape, это конечно не проблема. В целом впечатления положительные, тем более уже ранее слышал много хороших отзывов. Обязательно на досуге поковыряю.
С боксом по всем пунктам согласен: брошен, тормозной и утечки с багами имеются в достаточном количестве — пичаль :( Но наработки за пару лет уже накопились :)
> Есть один вопрос по тому как реализован алгоритм определения видимости объекта (попадает в экран или нет). Была использована регулярная сетка или quad-tree ?
QuadTree есть, но по дефолту в движке не используется, его можно создавать вручную и загружать в него объекты чтобы быстро с ними работать. А отработка видимости объекта производится простым способом. Например, есть группа, мы добавляем в нее другие объекты, если мы вызовем для этой группы метод draw(), то для всех объектов в этой группе так же будет вызван метод draw() где-то в нем то и происходит проверка на попадание каждго из объектов в камеры и если объект не попадает, то отрисовка объекта в буфер камеры не производится.
Но тут и через QuadTree так же просто все сделать. Например, так же добавляем все объекты в группу, потом загружаем эту группу в QuadTree, а из дерева уже делаем AABB запрос и для всех объектов которые вернулись по запросу, выполняем метод draw(). Ну и конечно же, прежде чем отрисовать результат полученный из дерева, его можно отсортировать.
Ну вот, как-то так :)
Антон, а в вашем фреймворке будут классы для работы с ???
Не совсем понял по группам. Сама группа понятна - такой метод организации объектов, так сказать, для пакетной обработки. Но получается, что групп может быть много. Напр., у нас есть 10 групп по 10 объектов и того 100 объектов. Алгоритм перебирает все объекты и анализирует попадает ли в область или сначала идет фильтрация на уровне групп (то есть какая группа попадает в камеру для отрисовки), а потом на уровне объектов этой группы?
На счет Nape, беглый взгляд это только начало)) Если вникнуть, то можно увидеть насколько просто и мощно все сделано, куча утилитных классов для облегчения работы, больше информации для физ. симуляции (напр. сколько инфы предоставляет Arbiter в сравнении с боксом). Один минус это пока нету CCD, но как сказал Лука в ближайшие недели выкатит обновление.
Если че у меня на блоге есть несколько статьей для начинающих в Nape, но ввиду приближающегося обновления некоторая инфа будет устаревшей.
Забыл кинуть ссылку на блог (если вдруг заинтересует) http://flashnotes.ru/2012/02/07/nape-2-soderzhanie/
Антон, как с вами гарантированно связаться? По почте не вышло. ?ли вы просто проигнорировали письмо? :)
Оч ждем демо. Как-раз пишу свой фрэймворк и за основу тоже взят Flixel :)). Даже приставочки к классам хотел делать "Ant" так как фамилия у меня "Мурашко:)" но видел что Вы в ваших классах юзаете этот префикс (e.g. AntActor.as ) и назвал подругому, а узнав что планируется выход фрэймворка в паблик - обрадовался вдвойне: за то что он выйдет, и за то что я свой подругому назвал:).
?тнерестно будеть увидеть симбиоз подходов реализации в вашем фрэймворке. С радостью поделюсь идеями.
Антон, когда собираешься делать новую игру, если не секрет? Пилить фреймворки, конечно, доброе дело, но разве не интереснее делать сами игры?
@WXY, классы помошники описанные в первой записи про ?? будут в комплекте без привязки к фреймворку, но каких-либо готовых решений по ?? не будет.
@VirtualMaestro, на ссылку с вводным описанием о Nape — большое спасибо! Пробежался по первым двум записям, отличный материал чтобы вникнуть быстро в суть. На днях постараюсь поковырять глубже :)
> Не совсем понял по группам. Сама группа понятна - такой метод организации объектов, так сказать, для пакетной обработки.
Внутри групп нет никаких фильтраций, если для группы вызван метод draw() то для всех вложенных объектов так же будет произведен вызов метода draw(), но перед тем как объект будет непосредственно отрисован в буфер камеры, выполнится проверка на его попадание в видимость камеры. То есть даже если для объекта был вызван метод draw() то он будет отрисован только в том случае если он попадает в область видимости.
Тут я пытаюсь предугадать что вас беспокоит и попробую ответить на упреждение. Данный способ описан для классических анимированных объектов (монстры, герои, бонусы, какие-то игровые объекты). А вот реализация тайлов (графических объектов из которых состоит, например, игровой уровень) реализована иным способом. ?гровые карты состоят из AntTile которые объединяются классом AntTileMap и вот он уже берет положение и размеры каждой камеры, вычисляет с какого по какой тайл камера видит и рендерит только те тайлы которые попадают в диапазон видимых тайлов. Все тайлы внутри такой карты хранятся в одномерном массиве и перебор производится не для всех тайлов, а только для определенного диапазона.
Если не нравится, что рендер актеров производится перебором всех (видимых и не видимых) сущностей, то тогда вместо того чтобы вызывать метод draw() для самой рутовой группы в которую помещены другие группы, можно загрузить рутовую группу в quad tree и от туда сделать выборку только тех объектов, которые попадают в заданный прямоугольник и вызвать метод draw() только для тек кто 100% виден. Но такой способ годится не всегда, и порой сгенерировать quad tree дерево дольше чем перебрать все объекты. Тут способ реализации нужно выбирать уже исходя из целей и задач.
@V.exeR, гарантированно связаться только по почте. Отвечаю на письма (если они не попали в спам), раз в несколько дней, буквально 1-3 раза в неделю.
@NM, здесь же в записи я написал, что игры делать мне интереснее :) ? как раз по этой причине "физическая часть" фреймворка появится немного позже.
Над новой игрой уже работаю, просто пока много непонятных моментов и поэтому не могу пока анонсировать. Ну и без допиленного фреймворка игру не сделать ;)
@Ant.Karlov
А как физика привязана к Flesh IDE? Это что то на подобие WCK? Если да то можно пожалуйста в кратце описать основные отличия если таковые имеются?
Не пишите Антону комментарии, каждый коммент отнимает 5 минут его работы и отдаляет выход фреймворка))).
Антон, а когда примерно будет продолжение статьи о искусственных интелектах?
@Vadim, от WCK я видел только демки, поэтому не очень понимаю как там устроено все внутри. В моей надстройке физики используются простые компоненты для создания простых физических объектов с заданием им соответствующих параметров. Физический мир не создается автоматически, разработчик просто скармливает клип с этим компонентами некому классу менеджеру который извлекает информацию из клипа и освобождает клип, далее разработчик просто запрашивает некое тело или список тел из класса менеджера и может задать дополнительные трансформации всей модели или отдельным её частям, джоинты так же создаются вручную разработчиком на основе информации в менеджере.
Абстрактный код демонстрирующий работу:
// ?звлекаем нужную модель
var myModel = myManager.getModel("someModel");
// Устанавливаем позицию
myModel.setPosition(100, 340);
// Устанавливаем угол разворота для модели
myModel.setAngle(90);
// Создаем тело
var myBody1:AntBody = myModel.makeBody("bodyName1");
// Создаем другое тело
var myBody2:AntBody = myMode.makeBody("bodyName2");
// Соединяем оба тела джоинтом
myModel.makeJoint("myJoint", myBody1, myBody2);
Такой подход позволяет делать сложные физические регдоллы с трансформациями минимизируя количество кода в самой игре. Настройки задаются во FlashIDE, либо можно так же задавать новые настройки в коде при необходимости.
@Sumbit, про ?? обязательно допишу как выложу фреймворк.
@Ant.Karlov с нетерпением жду возможности потестить, потому как во flixel как раз эти вещи и раздражают типа работы с группами и физический движок
@Ant.Karlov а частицы будут?
// Боже, ты услышал мои молитвы. Молодчина!
<postscriptum>
первым пишется вопросительный знак, вот так — ?!
</postscriptum>
// ;D
Две недели прошли
Антон, когда выложите фреймворк, я уже заждался) ?
@Lisnic Alexandr, в течении этой недели.
@Ant.Karlov, с нетерпением жду твоей библиотеки.
Начинаю свой путь инди-разработчика. При возникновении сложностей с твоей библиотекой или с библиотекой Box2D можно будет заручиться твоей поддержкой?
Здравствуйте Антон, делаю flash игру, в рутину продажи пока особо не нырял, но задался вопросом - продаешь игру, fla исходник отдаешь?, если да, то я так понимаю все папки символы в библиотеке должны быть на английском?
Здравствуйте Антон, как жрать всю неделю и похудеть на 20 килограмм?
@Naitonium, с вопросами по Box2D лучше сразу на форум flashgamedev.ru обращатся, там больше народу неплохо разбирающихся в этой библиотеки. Ну и ответов интересных с разными вариантами решений можно больше получить :)
По поводу моей библиотеки конечно можно задавать вопросы мне.
@Владимир, при обычной продажи, а правильнее говорить: при спононсировании — исходники игр не отдаются спонсорам вообще. Если спонсору необходимы исходные коды, то такие вещи оговариваются отдельно за отдельные суммы. Если вы планируете продать и исходники вашей игры, то конечно, тут стоит заранее позаботится о том, чтобы в ваших трудах смогли разобраться другие люди.
Рекомендую вам всегда называть клипы и папки на английском языке, желательно английскими словами — это не только упростит вам немного жизнь в будущем но и за одно подучите английский язык ;)
Спасибо за совет )
Зашел на http://flashdaily.net/ а там аж 2 поста про AntHill и Зомботрон. Поздравляю!
Как раз всерьёз задумался что делать, перебрав разный движки и закручинившись, что они не соответствуют моим пожеланиям) Посмотрю и на ваш с удовольствием, тем более, что многие мои "хотелки" относятся к вашим же туториалам)
Уже думаю ваять свой велосипед, да всё лень не позволяет)
Антон, почему ты не оптимизировал сам код actionscript`a я про приемы как использование Vector вместо array, или цикла while вместо for, или if(){} вместо ?:: ..и т.д.
@Lisnic Alexandr, Vector не трогал со времен FP 10, чтобы не случалось неприятностей на 9-ом плеере, сейчас конечно это уже почти не актуально. В ближайшем будущем заменю Array на Vector.
for на while как-то не вижу особого повода менять. Например здесь результаты тестов for vs while почти не отличаются.
Сокращенное условия стараюсь использовать там где возможно. Если где-то встречаются развернутые условия, то это возможно из-за того что в теле условия может появится дополнительный код. Либо изначально написал полное, а потом упустил из виду что можно было записать короткое — такое тоже бывает.
MineCraft вдохновляет)
Ну поздравляю, ты сделал свою "кучку"! А вот я из тех ленивых и занятых, поэтому подожду демки и примеры) Но за труд большое спасибо
24 Августа 2012
— 22:45
#