2010-01-06 3 views
0

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

Мне просто интересно узнать, что лучше всего подходит для этого и что самое выгодное. Что делают профессионалы.

+0

можно присвоить метку кадру и использовать gotoAndPlay (frameNum или label) – oldUser

ответ

1

Если вы начинаете с Flash, просто IDE, а затем узнаете, как кодировать, перемещение по кадрам имеет смысл, поскольку он мертв легко понять/реализовать.

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

Я угадываю, как Keith Peters код там виды и меню 100%. Как только вы создадите свой маленький игровой движок (с меню и экранами), готовый к повторному использованию (Asobu), временная шкала кажется немного бессмысленной для переключения видов. PushButtonEngine выглядит великолепно с этой точки зрения.

Если вы работаете с дизайнером, и он/она проектирует экраны, а навигация по временной шкале имеет для него смысл, в то время как прототипирование, я предполагаю, что есть средняя точка. Пока каждый экран является MovieClip на своем собственном, внутри основной временной шкалы вы можете установить класс для каждого экрана MovieClip и продолжить оттуда. Если вам нужно что-то, чтобы объявить вам экземпляры сцены, я написал tiny extension, которые могли бы дать вам это. Затем вы можете продолжить логику в своей предпочтительной среде IDE.

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

+0

Мой код не такой сложный, но я вижу, что вы говорите. Я мог бы также придерживаться того, что лучше для меня. Кодирование. спасибо – numerical25

+0

Да, есть много способов сделать то же самое. Сделайте то, что заставляет вас чувствовать себя комфортно и получать удовольствие. Рад, что я мог бы помочь :) –

2

Использование временной шкалы обычно считается не лучшей практикой. Вы, как правило, найдете дизайнеров, которые начинают программирование, как правило, используют временную шкалу, как то, к чему они привыкли. Также программисты, которые начали с AS1 или AS2, как правило, имеют плохие habbits. Если что-то стоит делать правильно.

Проблема с использованием временной шкалы заключается в управлении вашими переменными состояниями. Любые переменные, объявленные в кадре, будут потеряны, если вы перейдете к другому кадру (кроме первого кадра). Чтобы продемонстрировать, представьте себе этот базовый пример:

В первом кадре есть кнопка параметров, которая при нажатии переходит к другому варианту кадра. В этом кадре параметров есть кнопка проверки, а также объявляется другой объект. Он также имеет кнопку для возврата в главное меню. Это то, на что похоже, когда компилятор сгенерировал его в код:

package DemoAvoid_fla 
{ 
    import fl.controls.*; 
    import flash.display.*; 
    import flash.events.*; 

    dynamic public class MainTimeline extends MovieClip 
    { 
     public var btnOptions:SimpleButton; 
     public var chkHints:CheckBox; 
     public var myWorld:Object; 
     public var btnReturnToMainMenu:SimpleButton; 
     public var declareSomeInstace:Object; 

     public function MainTimeline() 
     { 
      addFrameScript(0, this.frame1, 1, this.frame2); 
      return; 
     }// end function 

     public function onOptionsClick(event:MouseEvent) : void 
     { 
      gotoAndStop("options"); 
      return; 
     }// end function 

     function frame1() 
     { 
      stop(); 
      this.myWorld = new Object(); 
      this.btnOptions.addEventListener(MouseEvent.CLICK, this.onOptionsClick); 
      return; 
     }// end function 

     public function onReturnToMainMenu(event:Event) : void 
     { 
      gotoAndStop("mainMenu"); 
      return; 
     }// end function 

     function frame2() 
     { 
      stop(); 
      this.chkHints.addEventListener(Event.CHANGE, this.onHintsChange); 
      this.btnReturnToMainMenu.addEventListene(MouseEvent.CLICK,this.onReturnToMainMenu); 
      this.declareSomeInstace = new Object(); 
      return; 
     }// end function 

     public function onHintsChange(event:Event) : void 
     { 
      var _loc_2:* = event.target.selected; 
      trace(_loc_2); 
      return; 
     }// end function 

    } 
} 

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

Мой стиль кодирования для меню заключается в создании каждого экрана в качестве мувиклипа. Затем поместите каждый мувиклип на первый кадр, но на разные слои. Затем я скрыть/показать слой, который я хочу.Его также легко контролировать из внешних классов и так же быстро разрабатывать и избегать любых проблем, о которых я упомянул :)

+0

Ну, я чувствую себя более свободным. В любом случае я не собирался использовать timeLine. Но все же самое сложное программирование - это управление всеми этими экранными объектами. вам не нужно вручную удалять их все. но вы также должны убедиться, что все прослушиватели событий также уничтожены. Я только что начал actioncript, поэтому я все изучаю. но все же пытается привыкнуть к этому. и лучшие практики для группировки отображаемых объектов, которые нужно уничтожить вместе с прослушивателями. – numerical25

+2

Очень интересно, как Flash, который коренится в метафоре кадра, в конце концов, стал чуть более чем сосудом для ActionScript, чтобы говорить с графическими объектами. (Если это). Практически все разработчики AS, которых я знаю, включили в себя, стараются как можно меньше времени проводить во Flash IDE и скорее будут работать с чистыми проектами ActionScript и импортировать графические объекты во время выполнения. Просто мимолетное презрение. :) – Martin

+0

Это, безусловно, есть :). Теперь я обнаруживаю, что избегаю даже использования компилятора Adobe и написания AS3 на другом языке. – Allan

0

Я думаю, что это настоящий позор, что использование временной шкалы считается не лучшей практикой. Я чувствую, что это во многом виноват Adobe, поскольку не предоставляет документацию о том, как использовать временную шкалу в соответствии с хорошей практикой развития, когда вышел AS3/CS3.

Если вы используете временную шкалу, у вас есть гораздо больше вариантов, связанных с такими вещами, как когда ваши внедренные объекты загружаются, а это значит, что вам не нужно загружать столько кода, пока фильм не запустится - так что вы не у вас есть такой длинный preloader, чтобы рекламировать, что вы такой кодирующий ниндзя, в который вы вставляете все до кадра 1. Из-за того, что пользователи намного счастливее, когда знают, что они просматривают что-то, созданное кодирующим ниндзя, поэтому они готовы ждать Привилегия.

Вы могли бы найти это альтернативный взгляд интересный http://www.developria.com/2010/04/combining-the-timeline-with-oo.html

0

Лично я склоняюсь в сторону только с помощью Flash IDE для создания активов SWC файлов. Вся моя логика и компиляция выполняется с использованием FDT. Время компиляции намного быстрее, и отладчик работает.

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

Итог: работайте, однако, вам удобно, когда можете, но можете работать, но вы обязаны.