Проблема работы с TimerEvent, Tweener'ом

[Wolsh]

Вы не правы, да.
Во-первых, у меня вообще локальная переменная. Когда функция отработает, вообще никакого bl не будет (у автора не так). Ссылки на шарики как бы не нужны вовсе. Они в дисплейлисте, и никуда не денутся. А привязка данных к ним осуществлена через Справочник. Слушатель же получает ссылку на конкретный шарик из event.currentTarget. Такая вот разгрузка кода.
Про галерею: по тексту все отлично. Не вижу противоречий, каждый занимается своим делом.
Откуда Вы взяли странную мысль что я советую писать все в одном классе? О__о Я вот сейчас снова начал писать паззл, набросал скелет, и у меня 24 класса. И по мере наращивания жирка я собираюсь еще по ним пройтись и разделить кое-где ответственность, так что ещё штук 6-8 от них точно отпочкуются, не говоря уже о куче просто новых, пока не вступивших в игру. Классы длиннее 300 строк считаю тяжелыми и трудными для восприятия.

причем имеет в себе довольно простые функции, которые влияют лишь на мячик?

Изменение положения мячика влияет лишь на мячик? О__о
1) Как изменение положения влияет на мячик? Мячик как-то изменяется?
2) Как изменение положения мячика НЕ влияет на поле, содержащее мячики? Поле с мячиками не меняется?

Не для это разве пишутся паблик функции в классе, чтобы им можно было управлять извне?

Именно для этого и пишутся, чтобы управлять извне. Именно поэтому как бы вы ни развивали интеллект мячика, чтобы он сам назначал себе координаты в вакууме, в любой момент кто угодно может поставить его "на место", выбросив всю его внутреннюю логику в помойное ведро.
Какое отношение паблик функции имеют к Вашей идее, что мячик должен сам летать куда ему вздумается?

То есть если делать классы, то делать полностью универсальными и редко ими пользоваться? Если футбольное поле, то не класс поле, в нем экземпляр мячика (композиция применяется), экземпляры детей и экземпляр трава, к примеру, а класс поле, а в нем функции "дети, мячик, трава" и в каждой куча кода и куча своих переменных и для управления каждым нужном создавать каждому по 3-4 функции все это внутри класса поля? Разве не от такой системы идет переход в AS3 и ООП?

1)Еще раз — я не знаю, откуда Вы взяли про "функции мячика и мальчика". У автора изначально был класс Ball, как и положено. Это как бы даже не обсуждалось, ибо правильно. Был прекрасный "мячик в себе", делавший то что положено мячику. Ни о каких "функциях", рисующих мячики прямо в Мейне, не было и речи.
2) Переход в AS3 и ООП идет от слепоглухонемого кода на объекте к коду, связывающему объекты в иерархическую систему. Когда мячик меняет состояние поля, подчиненной частью которого он является, это анархический беспредел. Вот манифест этого беспредела:

ball:FootballBall = new FootballBall(ширина и высота поля)

Вы когда-нибудь покупали в магазине "мячик для поля 100 х 210 метров"?
Вы действительно видите в этом какую-то логику?

[MINASTIS]

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

Даже если в нем прописать всю физику, то она не будет взаимодействовать с пределами поля\стола, он просто к примеру будет останавливаться и не идти дальше.

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

С мячиком и полем, это как startDrag()
Только вместо объекта для перетаскивания мячик а вместо области для "в пределах которой можно объект таскать" - ширина и высота поля, чтобы как ни таскайся\двигайся мячик - он не уйдет за его пределы.
Это простой пример ограничения движения. Т.е. поле может рисоваться само и в экземпляр мячика просто кидает уже после своей отрисовки свои же ширину и высоту.
По сути поле диктует мячику, в какой области он может двигаться.

И еще насчет непонимания, как оказалось, я понятия не имею про dictionary и что он делает, поэтому для меня весь код показался странным)

Т.е. все мои вопросы и претензии изначально беспочвенны. Насчет структуры, это да, я считаю, что твины для движения и любые листенеры для взаимодействия с мышкой должны быть в классе ball, т.к. так проще, на мой взгляд. Внутри.
Т.е. создавать не класс ball, который просто рисует шарик, а класс, к примеру, AwayBall. Это часто делает надобность писать кучу других классов для других шариков, если таковые имеются, но что поделать. Зато следить за огромной структурой приложения, если она такой будет, будет удобней.

[Wolsh]

startDrag это да, отличный пример-привет из AS1, каких немного осталось в ActionScript после перехода к парадигме ООП))) Заслуживает памятника "За проявленную стойкость"..

а так происходит упрощение игры, чтобы мячик не мог улететь за пределы поля

Цель игры не в том, чтобы мячик не улетел за пределы поля. Вам в любом случае требуется отслеживать все перемещения мячика по полю и его взаимодействие с другими объектами (шарами в бильярде, ок). Это не шар должен решать, что он задел не тот шар или попал в лузу. Это не его, кругляшка на экране, дело. Не надо шарику знать о всей системе, в которой он участвует. Более чем достаточно, что Система знает о шарике. Я уже не знаю как объяснять)))) Вы видите ООП как разделение кода на объекты, каждый из которых берет на себя все тяготы мира. Но ключевая парадигма ООП это абстрагирование в Объект некоторой ответственности, в идеале ровно одной. Каждый объект отвечает за что-то отдельное и конкретное. Это и есть Объектно-ориентированное программирование. И в ответственность мячика никак не входит определение, где бы он хотел быть и когда ему начинать или вообще не начинать что-то делать в Системе. Каждый делает что-то в себе. Мячик рисует свои лоскутки, швы и эмблемы. Свойства вроде х и у — публичные. Они для того, чтобы этот мячик можно было перемещать в системе координат контейнера. Для самого мячика эти свойства не значат вообще ничего. Ровным счетом. Это свойства его положения относительно системы. Они никак не изменяют мячик. Попадание в лузу никак не изменяет мячик. Удар кием никак не изменяет мячик. Проигрыш или выигрыш никак не изменяют мячик. В этом его объектность. Он постоянен в выполнении своей ответственности.
Хотел бы я сыграть с Вами в шахматы. Посмотреть, как Вы будете ждать от фигур правильных ходов.

[MINASTIS]

Кажется, я начинаю понимать свою ошибку.
Спасибо за объяснения

[Wolsh]

Это хорошо.
Вот у Вас допустим есть класс БильярдныйСтол, описывающий размеры стола и положение луз, трение поверхности, ну и если это не MVC, то конечно рисующий сам столик.
Есть класс БильярдныйШар, описывающий шарик, его размеры и возможно физические параметры (трение и массу для инерции), и умеющий рисовать красивый шарик с бликами и цифрами, заданного цвета.
И есть класс, управляющий физикой шариков на столе. Этот класс принимает как параметры БильярдныйСтол и БильярдныйШар.
И наконец есть судейский класс, интерпретирующий происходящее на столе в соответствии с принятыми Правилами игры.
Это — обычное решение в стиле ООП. Начиная с этого момента Вы можете свободно заменять классы стола и шариков, как угодно. Если надо подкорректировать физику, Вам достаточно покопаться в классе-менеджере физики. И вы можете менять Правила судейства для разных игр на бильярде. Это ключевые концепции проектирования в ООП: универсальность, заменяемость, расширяемость, разделение ответственности.
Вы можете включить в игру несколько комнат с разными красивыми столами. Разные стили шариков. Разные правила игры. При этом стол будет описывать только стол. Шарик — только шарик. Вам не нужно будет писать всю физику системы в каждом классе шариков или столов. Нужно только описать характерные свойства именно данного класса шарика, данного класса стола. И в будущем, если вы захотите написать новый бильярд, Вы сможете воспользоваться этими же классами "как есть".
А теперь представьте, что в эту систему кинули шарик, который сам все решает....

Еще один пример.. Вам в программе потребовалась кнопка. Допустим это простой СимплБаттон, не важно. Вы нашли где-то класс, рисующий красивые кнопочки для Состояний кнопки, принимая цвета, размеры, текст лейбла и т.п. Вы собрали из них красивейшую кнопку, но счастье длилось не долго: оказывается, создатель этого класса запихал в него собственное поведение при мышиных событиях и переопределил сеттеры размеров, альфы, visible и до кучи mouseEnabled))))))) Это умозрительный эксперимент, мало кто до такого додумается — я нарочно утрирую, чтобы показать непрактичность такого подхода. Всё, что требовалось от состояния — быть красивым и визуально настраиваемым. В этом вся его ответственность. А его поведение должно настраиваться системой, в которой его решили использовать — в данном случае кнопкой.