настройка покадровой навигации по меню против всего кода - PullRequest
0 голосов
/ 06 января 2010

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

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

Ответы [ 4 ]

2 голосов
/ 07 января 2010

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

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

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

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

    }
}

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

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

1 голос
/ 06 января 2010

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

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

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

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

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

0 голосов
/ 20 июля 2011

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

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

Итог: работайте, как бы вы ни быликомфортно, когда можешь, но уметь работать так, как тебе нужно.

0 голосов
/ 20 июля 2011

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

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

Эта альтернативная перспектива может показаться вам интересной http://www.developria.com/2010/04/combining-the-timeline-with-oo.html

...