Framework: State & StateManager

Как работает мой игровой фреймворк? В основе всего лежит State и управляющий им StateManager.

State

elmortem.states.State
Наследуется от Sprite и реализует в своих наследниках логику игровых экранов. Например от него наследуются классы Mainmenu, Gameplay, Options и т.д.
Конструктор принимает не обязательный Object, который сохраняется в публичном параметре attr. Это позволяет передавать игровым экранам любое количество параметров любого типа и является универсальным. Такой метод передачи параметров используется почти во всех моих объектах.

StateManager

elmortem.states.StateManager
Этот класс управляет игровыми экранами. Он добавляет их на сцену, инициализирует, удаляет. Экземпляр этого класса является статическим параметром моего основного класса Main, который либо является DocumentClass'ом, либо создаётся в Preloader'е.
Конструктор принимает Object с пока единственным свойством clip — сцена, в которую будут добавляться игровые экраны.

Выглядит это примерно так:
// Document Class
class Main extends Sprite {
  static public var stateManager:StateManager;

  public function Main() {
    if(stage) init();
    else addEventListener(Event.ADDED_TO_STAGE, init);
  }
  private function init(e:Event = null):void {
    stateManager = new StateManager({clip:this});
    // clip - сцена, куда будут добавляться экраны
    
    stateManager.show(new Mainmenu());
  }
}
// MAINMENU
public class Mainmenu extends State {
  public function Mainmenu(attrIn:Object = null) {
    super(attrIn);
  }
  override protected function init():void {
    // вызывается после ADDED_TO_STAGE, реализовано в State
    addEventListener(MouseEvent.CLICK, onClick);
  }
  override public function free():void {
    // free - единое для всех моих объектов название метода удаления объекта
    // После вызова этого метода объект использовать нельзя
    removeEventListener(MouseEvent.CLICK, onClick);
  }
  private function onClick(e:MouseEvent):void {
    Main.stateManager.show(new Gameplay({map:1}));
  }
}
// GAMEPLAY
public class Gameplay extends State {
  public function Gameplay(attrIn:Object = null) {
    super(attrIn);
  }
  override protected function init():void {
    trace("Map "+attr.map);
    addEventListener(MouseEvent.CLICK, onClick);
  }
  override public function free():void {
    removeEventListener(MouseEvent.CLICK, onClick);
  }
  private function onClick(e:MouseEvent):void {
    Main.stateManager.show(new Mainmenu());
  }
}


Продолжение следует...

Комментарии (11)

0
переноси свои посты в коллективный блог ActionScript. :)

я правда не совсем понял о каком фреймворке идет речь. такое ощущение, что ты об этом писал пост, а он потерялся). выложить свой фреймворк и написать по нему цикл статей это отлично! тем, кто только начинает было бы очень полезно. но такое ощущение, что ты пропустил вступительное слово про фреймворк с сылкой на скачивание и сразу начал со статей. или я не так понял?)
0
Это я просто писать посты не умею. Просто решил рассказать, как работает мой фреймворк. Выкладывать его нет смысла, он простой, про него проще рассказать. Хотя может и выложу, если совсем непонятно будет…
0
класса StateManager нету
а было бы интересно посмотреть
0
Интересный пост. Очень актуален для меня. Я совсем недавно перешел на AS3 и по привычке все меню, подменю, сам игровой экран и т.д. делал в отдельных кадрах root'а (как обычно делается в AS2). Как раз начал задумываться о том, как бы по удобнее организовать управление такими экранами в одном фрейме. Спасибо :)
0
Дальше ещё расскажу про организацию и обработку юнитов — самое интересное, про подключение и использование Box2D и про свой универсальный редактор, который можно встраивать практически в любую игру, чтобы пользователи могли создавать свои уровни. (:
0
Жду, потирая руки :):):)
0
Будет интересно сравнить реализацию редактора со своей
0
Как то не подробно…
и структура мне не оч понравилась,
хотя я юзаю твою стейт машину еще с двига ХГЕ ее увидел и переделал под себя)
у меня еще есть класс перехода, он останавливает текущий стейт -делает анимацию и показывает следующий.
0
Каких именно подробностей не хватает? Я же привёл пример работы и листинги классов. Расскажи, чем именноне нравится структура? Может я чего переделаю…
Вообще у многих же есть свои фреймворки, было бы неплохо, если бы каждый рассказал про свой, мы бы друг у друга правильных идей позаимствовали и все бы были довольны.
0
Я сначала не увидел класс Манагера — он был другой теме…
ну не нравиться) на сколько я понял у тебя при переходе на новый виджет старый удаляется? и потом если надо вернуться на первый
— его нужно снова создать? да? вот этим подход и не понравился.
к примеру, у тебя пользователь на первом стейте — кнопку музыки нажал…
и в следующий раз при переходе на первый стейт тебе нужно этот параметр каждый раз передавать?

ПС мой фреймворк настолько мутный,
все руки не доходят его поправить)
и он на столько по-индуски написан, что даже я не смогу все пере-осознать.
0
Все глобальные данные надо хранить глобально, у меня для этого используется профиль на основе SharedObject. Так что ничего передавать не нужно, сохраняем в профиле и загружаем из профиля.
А оставлять целый стейт в памяти может быть очень накладно по памяти. При этом ничто не мешает не реализовывать удаления в методе free и сам стейт хранить отдельно, тогда его не нужно будет пересоздавать.
Про профиль расскажу следующим постом, раз уж к слову пришлось…
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.