выложил статью
 

Интересно!
 

Да, да это интересно и требует вдумчивого чтения.

p.s. Продайся макромедии !!!

Интересно - но сложно. Я не уверен, что во всем СНГ есть больше 100 человек, которые способны это до конца осмыслить. В общем, людей, которые занимаются разработкой больших проектов, не так уж и много.
Как я понимаю, это отрывок из книги. Денег она особых не принесет. 10% от стоимости тиража - тысячи полторы максимум с одного издания. Но зато почет и уважение:)
Если оценить стилистику текста, я наберусь наглости сделать несколько замечаний:
- Слишком много "Я", "Мне" и т.д. Писать от первого лица считается плохим тоном. Это допустимо лишь во введении. Даже лауреаты нобелевской премии обходятся без местоимения "Я" (на худой конец его можно заменить "автор").
- Внимательнее со знаками препинания. Из опыта известно, что редактор может неправильно понять - и сильно испортить текст.
А по содержанию все очень хорошо. Я обязательно куплю эту книгу, когда она выйдет. Кстати, вы вполне можете расчитывать на ее перевод на английский язык. Я знаю трех авторов, которым удалось напечататься у буржуев - и их тверения были куда менее концептуальны.

Полностью поддерживаю,
но не сразу все получается....

Наконец-то появился человек, пишущий про логику приложений... да еще во флеше (причем это не сводится к описанию архитектуры мм-компонентов)... да еще на русском! Хорошее начало! С нетерпением жду продолжения.

нтересно, буду читать..

To: Гений john

В таких случаях, не знаю что должно сказать ... СПАСИБО ГЕНИЙ JOHN.

интересно и полезно :)

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

но вобщем здорово канеш :)

зы: предложение "мое знакомство с ооп достойно отдельной статьи" выделенное в отдельный абзац - вышибает слезу :))

Это есть немаленькая работа, John :-| Продолжай в том же духе.

john, порадовал. впрочем, как всегда :)

Почему конвеер?
Под конвеером понимается, разбиение задачи на однотипные действия.

Стек.

Очень полезно.

2Dagi
в СНГ ежегодно выпускается тысяч несколько человек которым предложенный подход излагают в школе.

Я вполне уверен, что есть как минимум 10000.

Помоему ты не прав!
Каждый MovieClip - по сути своей поток с таймером.
Я вообще сторонник распределения кода по потокам (мувикам)

Скоро представлю иллюстрацию.

Стек есть лишь конструкция списка, в котором реализуется правило «первым вошел, первым вышел». И ничего более. Механизм конвейера предлагает целый комплекс сервисов, и называть его стеком не совсем правильно. Это то же самое что назвать автомобиль двигателем внутреннего сгорания.

К тому же само понятие стека не совсем применимо к списку конвейера. Принцип «вложенных списков» предполагает более сложное поведение чем «первым вошел первым вышел», ибо действия помещается не только в конец списка, но и в нужную точку списка.

Я рад и горд за нашу страну за то, что в нашей школе преподают основы объектно-ориентированного программирования и паттерны проектирования…..

Если ты имеешь ввиду лишь знакомство с принципом стека (предполагаю, скорее всего в контексте работы памяти при выполнении кода), то этого не совсем достаточно, чтобы говорить «предложенный подход». Это было бы слишком поверхностно…

Скорее всего ты имеешь ввиду, мое утверждение что флэш имеет только один поток исполнения?

А тут не нужно быть не правим или правым. Это факт. Причем факт который описан самой макромедией.

Вот иллюстрация.
Здесь 25 треугольников(75=25*3-вершин) в трёхмерном пространстве(хотя это и не очень заметно...).
Каждая вершина (мувик) движется независимо в однородном поле тяжести и отражается от стенок.
Каждый треугольник(мувик) независимо закрашивает контур, определяемый тремя варшинами.
В руте просто аттачатся треугольники и stop().

А что было бы, если всё это обрабатывать в цикле в руте...

По моему это косвенное подтверждение "потоковости" мувика.

P.S. Прошу прощение за схематичность примера.

2 _1_Maxim

скорее всего вы не совсем понимаете термин "многопоточность"....

применительно к флэш
многопоточность это ситуация когда в разных "мувиках"

был следующий код:

// mc1

trace("mc #1 ___ 1 ____")
trace("mc #1 ___ 2 ____")
trace("mc #1 ___ 3 ____")

// mc2

trace("mc #2 ___ 1 ____")
trace("mc #2 ___ 2 ____")
trace("mc #2 ___ 3 ____")

и протрейсилось бы так

mc #1 ___ 1 ____
mc #2 ___ 1 ____
mc #1 ___ 2 ____
mc #2 ___ 2 ____
mc #1 ___ 3 ____
mc #2 ___ 3 ____

а в реальности будет так:

mc #1 ___ 1 ____
mc #1 ___ 2 ____
mc #1 ___ 3 ____
mc #2 ___ 1 ____
mc #2 ___ 2 ____
mc #2 ___ 3 ____

код выполнится сначала в "одном месте", а потом в другом.
не не "одновременно"... паралельно.

Верняк Number(String("10000") add "0")

Я не уверен, что в России есть 10000 человек, попросту владеющих ActionScript выше уровня
on(release){
gotoAndPlay(2);
}
Уж не говоря про тех, кому могла бы быть интересна теория конвееров:)

Ты гонишь. Если бы это всё обрабатывалось по умному в руте, было бы ни как не хуже. Даю гарантию 10000000%. Уметь надо.

И поражающая воображение неграмотность этой строчки:
Number(String("10000") add "0")
подтверждение моим словам.
Многие думают, что они хорошо знают ActionScript. Но людей, которые в нем действительно разбираются, единицы:)
И очень приятно, что один из самых заметных флешеров решил поделится своим опытом. Но до конца осознать этот опыт смогут не 10000. И даже не 5000. И дело не в знании стеков и паттернов. Просто это очень специфично.

"по умному" в руте не получится! Ты, вообще, замечал, что у каждого мувика есть свой Timeline?
А насчёт астрономических гарантий-это слова. Докажи!

john
Давайте не будем спорить. Вы говорили, что ваши слова подтверждает Macromedia. Может дадите ссылку, где сказанно об однопоточности Flash?

_1_Maxim, не о том надо с джоном спорить :)

речь о том, что "многопоточность" означает, что симулируется (симулируется !) "одновременное" выполнение нескольких процессов при помощи поочередной (в соответствии с приоритетами) приостановки выполнения одного процесса и выполнения части действий другого.

а во флэше этого НЕТ.

Нет, мне это нравится. ;) Вместо того, чтобы спорить о методе написания такой, в общем-то, весьма нужной системы... Ну или о нюансах... Спорят о ее необходимости. ;)

Жень я имел ввиду курс лекций "управление процессами"
в "теоретических основах операционных систем".

2greyshaman

«Управление процессами» - это все замечательно, но какое отношение это имеет к обсуждаемой статье?

Я упомянул многопоточность на первой странице статьи, и высказал сожаление, что многопоточности нет во Flash.

Далее предлагается некая система описания, протяженных во времени действий. Удобной для понимания и проверенная на многих проектах в течении четырех лет.

Нет даже желания реализовывать многопоточность во Flash.

Даже намека на желание.

В последний раз вернусь к многопоточности. Многопоточность (многозадачность) есть некий механизм, который позволяет оптимально распределить процессорное время между разными выполняемыми задачами. Задачи выполняются в соответствии со своим приоритетом.

Это так сказать машинная логика многозадачности.

Многозадачность помогает компьютеру лучше работать. Не
вижу никаких аналогий с механизмом конвейера, так как конвейер решает задачу упрощения понимания для разработчика….

Многозадачность – как средство разработки приложений – тоже хорошо, но во Flash этого нет, а реализовать многозадачность в полной мере, во Flash было бы и обременительно и бесполезно, так как необходимо было бы реализовывать еще один интерпретатор, который бы реализовал несколько потоков исполнения. Что привело бы к тому, что Flash приложения с этим механизмом работали бы в десятки раз медленнее.

Поэтому конвейер – это не технологическое решение, он в первую очередь решает задачу – как упростить описание, понимание и планирование протяженного во времени действия.

Не вижу никаких аналогий с процессами и многозадачностью.

Поэтому меня несколько огорчает такое отношение как «описанный подход».

И хватит о многозадачности.

Ничего доказывать я не буду. Я слишком умный, что бы развязывать болтовню с каждым, кому не попопдя.

Как я устал от безапелляционной и бездоказательной болтовни.

по-моему это взаимно :))

О чём, орлы, спорите?! О какой многозадачности?! Ведь у вас перед глазами постоянно маячит махонькое такое окошечко с надписью "12 fps"! Ну, или кто любит погорячее - 25 фпс или там 300 фпс. А это значит, что код выполняется именно с привязкой ко времени а не к приоритету объектов. И месит плеер каждую 1/12 секунды по порядку всё, что встретит на пути. И об этом сказано было ещё в книжке по 4 флешу. И с тех пор, насколько мне известно, ничего в этой области не изменилось, ибо это фундаментальная часть флешь-технологии. И остаётся нам, как сказал ещё Полиграф Полиграфович Шариков: "- В очередь, сукины дети! В очередь!". И спасибо автору за то, что он за всех подумал как это сделать. Потому что действительно мало у кого на это хватило бы мозгов.

Пардон, что встрял.

прочел первую статью про историю становления конвеера... запутался напрочь.
попробовал почитать данный топик...
вообще перепутался.

прочел вторую статью, со слов "Конкретный пример" и все стало ясно.
весь конвеер служит для упрощения написания скрипта. чтобы по прошествии полугода не лазить по десяткам вложенных друг в друга мувиклипам, вспоминая что к чему и как работает весь код пишется в одном месте, а timeline служит для покадровой анимации.

вот только одно непонятно
пока не выпонится весь код в руте (или где он там хранится), проигрывание остальных кадров не начнется или нет???

Привет john,
прочитал твою статью. Изучаю Яву уже около года, про класс Thread и его методы знаю не понаслышке. Я уже осознал важность изучения ООП и паттернов проектирования в программировании. Планирую вплотную познакомиться с Rational Rose.
Недавно я задал вопрос на другом форуме (ActionScript - http://www.flasher.ru/forum/showthre...threadid=52471), но на него пока никто не ответил. Полагаю у тебя есть для меня ответ. Вот вопрос:

Предположим я хочу написать игру - 2D ходилку, типа Dizzy или Seymour, которые раньше были на ZX-Spectrum'ах. Кто знает, тот поймёт.
Вот как я себе это представляю:
Каждый движущийся объект на экране - отдельный класс со свойствами и методами. Возможно будет 1 обстрактный класс - Enemy - враг, от которого все будут наследовать.
Есть класс Screen - он инициализируется статическими и динамическими объектами - врагами, например. У Screen'a есть матрица - она инициализируется изначально только статическими объектами. Потом все объекты классов (врагов и героя) начинают взаимодействовать с матрицей Screen'a и ведут себя по законам определённым в классах этих объектов.
Например, вопрос:
Каждый объект должен действовать асинхронно с помощью setInterval , например, или следует создать какой нибудь manager, который будет опрашивать объекты?
Сколько RAM может использовать флэш плеер? следует ли буферизовать соседние Screen'ы?
Каких размеров лучше делать матрицу? В каждой ячейке лучше хранить цифры от 0 до 9 , например? а не true/false. Какого размера ячейки?
Возможны ли проблемы со скоростью игры? Следует ли использовать где-нибудь onEnterFrame?

Главный вопрос: если у вас есть опыт подобного программирования или другие варианты решения 2D игры, можете ли вы что-нибудь посоветовать для вышеизложенного решения? или предложить свой.

Ещё вопрос: можно ли написать "единый" движок для 2D игр, с абстрактными классами врагов, статических взаимодействующих объектов (например кувшин, который можно разбить ногой)? скорее, вопрос, не "можно ли", а имеет ли смысл, и не окажется ли в конце, что это никому не нужно, этот движок глючит, сплошные тормоза и вообще C++ рулит.

Как ты видишь, я задал вопрос о менеджере потока событий ещё до того, как прочитал твою статью. Значит данный вопрос актуален.
В качестве ещё одного вопроса: подойдёт ли твой движок для более сложной игры, нежели рулетка? 2D игры с героем, перемещающимся по экрану и взаимодействущим с врагами или другими объектами. И если да, то как лучше это реализовать?

2Geniot

В твоем вопросе много частностей, и здесь выбор самого разработчика, как и что делать. Если вопрос в конвейере: стоит или не стоит использовать в этом случае – для меня ответ очевиден – стоит. Он хорош тогда, когда есть сложное и разнообразное поведение, состоящие из протяженных во времени действий.

Посоветую использовать схему – один главный конвейер, конвейеры менеджеров, и конвейеры отдельных компонентов (персонажей). Распределяя ответственность и управляя через главный конвейер можно добиться ощутимого контроля над системой.

2Stone
Удовольствие от использования технологии конвейера можно получить, набив достаточное количество шишек до этого. Если есть проблемы с пониманием, то я бы не рекомендовал пока использовать конвейер.

Джон, я тут ошибочку нашел :)
------------------------------------------------
Итак, на дворе четвертый Flash, и «приложения» делают так. Каждое действие приложение помещается в отдельный мувиклип, без графики, который имеет набор неких фреймов. Фреймы реализуют логику одной протяженной во времени «команды». Запуская проигрывание некого мувиклипа-команды, мы инициализировали процесс выполнения этой команды. Фреймы проигрываются, код в них выполняется, и в конечно
-----------------------------------------------
надо М добавить.

2Usnul

спасибо огромное,
у меня есть уже текст с литературной правкой,
но переверстать статью все не доходят руки

Ну что john, раскрутка по полной :)
http://cleoag.com/blog/

2Geniot

Ответы на большинство твоих вопросов можно найти в отличной книге по программированию игр "macromedia flash mx game design demystified"
автор jobe makar
Официальное руководство по программированию игр.
Ребята, что работали над книгой написали немало игрушек и несколько из них довольно известны. С одной я сталкивался в инете еще за полтора года до того, как увидел эту книгу в первый раз.

Пока эта книга, к сожалению, только на английском, но если владеешь языком, то постарайся найти.
Скоро будет и перевод - мне как раз пришлось этим заниматься и осталось перевести только предметный указатель. Работа нудная, но я буду стараться сделать ее побыстрее.
По опыту-еще два -три месяца и книга выйдет из печати.

Там по программированию ходилок целый раздел.
Но особо интересно то, что рассматривается весь процесс создания игры от планирования на начальном этапе, идеи, эскизов и т.п. до создания серверной поддержки и конструкторов уровней.

на русском есть такая книжка:

http://www.ozon.ru/context/detail/id/1401736/

хотя сложно сказать чтоб она могла сделать всех счастливыми...

а "Macromedia Flash MX Game Design Demystified" можно взять тут — ftp://Guest:www.7yue.com@210.192.122...emystified.rar