
Как делалась первая игра. Советы начинающим
Всем Привет. Меня зовут Андрей, и я с детства увлекался видеоиграми. Идея делать флеш игры засела мне в голову пару лет назад, но всё как-то не было времени. Я читал форумы и блоги разработчиков, играл в игры, завёл тетрадку куда записывал свои идеи, но руки как-то не доходили. Оказалось, самое трудное это начать.
Я очень рад, что моя половина разделила моё увлечение и всячески помогала мне в этом, не только советами но и делом.
Эта статья не в коем случае не является 100% руководством к действию, в ней я описываю наш “путь” первой игры. Возможно профи увидят в написанном много глупостей и очевидностей, или знают как реализовать той или иной функционал более изящным методом. Профи, пишите комментарии о ляпах и помогите советом нам, начинающим.
Есть такая поговорка: «Счастье, плохой наблюдательный пункт». Именьно поэтому я решил написать статью с “наблюдательного пункта“ после создания первой игры. Пока ещё свежи воспоминания.
Начало
Чтобы что-то строить, нужно уметь держать в руках инструмент. Глупо забивать гвозди микроскопом, когда удобнее использовать молоток. Первая игра должна быть простой в реализации. Есть готовые движки и библиотеки для создание игр Box2d, Pixel, Push Button Engine, WCK … К некоторым есть подробные гайды даже на русском языке, но сначала я бы рекомендовал изучить основы AS3.
Именно AS3.
Для этого подойдёт книга Рич Шупа и Зевана Россера Колина «Изучаем ActionScript 3.0» или книга Колина Мука «ActionScript 3.0 Для Flash». Она большая, но прочитайте хотя бы первые 6 глав. Ну хотя бы главу про список отображения.
Ещё бы я посоветовал прочитать туториал MJW по созданию игры. Именно на основе его прочтения я и сделал движок для Светлячка. Если у вас проблеы с английским, то гугл переводчик более менее сносно переведёт. Зато вы узнаете много интересного, о том как взаимодействуют объекты и как это описать. Туториал очень подробный, со всеми исходниками. Всего 12 глав, на каждую главу не более часа. И к каждой главе есть отдельные исходники.
Для игры вам нужна Идея. И не просто идея: “ну пусть это будет стрелялка про зомби и кровищи побольше”, а глубоко проработанная идея. Кто герой, какое оружие, как будет развиваться герой от уровня к уровню, сколько будет уровней, какая цель героя, какое управление, сколько уровней, сколько противников, как начинается уровень и как заканчивается… Чем глубже будет проработано, тем лучше вы сможете представить себе структуру игры. Конечно потом в процессе создания можно всё изменять, но имея в голове стуктуру игры(а лучше на бумаге) гораздо проще сделать план разработки и действовать по нему.
Кстати про план, очень полезная штука, если им правильно пользоваться. Чем подробнее план, тем лучше. Распишите все элементы, которые нужно сделать(нарисовать и запрограмировать). И от малого к большому начинайте реализовывать. Так приятно вычёркивать из списка уже сделанное. Если на чём то забуксовали, просто разбейте на более мелкие части.
Код
Мне вообще нравится использовать карандаш и бумагу для планирования. Перед тем как писать код нарисуйте структуру игры. Прелоадер => Главное Меню => Выбор Уровня => Игра => Выигрыш => Игра …
Понятно, что из Главного Меню можно попасть не только на Выбор Уровня, но и на Настройки, а из Выбора Уровня можно попасть назад в Главное Меню. А куда можно попасть из Игры? Очевидно что в Паузу или Выигрыш или Проигрыш. А из Паузы? Нарисуйте всю структуру и связи в ней.
К связям неплохо приписать информацию, которая передаётся в новый элемент. Например из Игры в Выигрыш можно передавать информацию о кол-ве очков, время игры, оставшихся жихнях. А из Выбора Уровня как минимум передаётся информация о выбранном уровне.
В своё время я кучу времени потратил на поиск удобного способа передачи информации между классами. От родителя к сыну и наоборот( от вызывающего класса к вызванному, и наоборот). Например у меня Игра, это класс который вызывается каждый раз с разными параметрами в зависимости от выбранного уровня в Выбор Уровня.
Передать данные в вызванный класс легко:
А вот наоборот сложнее, вызванный класс не может обратиться к родителю и передать ему данные. Для этого отлично подходит dispatchEvent.
Логика проста:
1)создаётся класс для передачи событий NavigationEvent, наследник Event
2)создаётся слушатель события
playScreen.addEventListener( NavigationEvent.WIN, onWin)
3)при наступлении условий для выигрыша в коде класса PlayScreen пишется
4)Вуаля, если условия для выигрыша выполняются, срабатывает dispatchEvent и передаёт событие NavigationEvent.WIN, а его слушатель уже вызывает функцию onWin в родителе.
Не обязательно использовать константу в классе NavigationEvent:
вместо неё можно передавать переменную типа string, об этом подробнее в части про звук.
Старайтесь не тратить много времени на оптимизацию кода, который выполняется разово(например при инициализации меню), но если код используется часто на EventFrame или по таймеру, оптимизируйте его. Я потратил несколько дней на оптимизацию кода меню выборауровней, а потом только подумал — ну стало не 140 строчек кода, а 40. Кто заметит разницу? И наоборот оптимизация часто повторяющегося кода в игре очень заметна. Для отслеживания «пульса» игры используйте счётчик FPS. Например этот. Используя код по ссылке создать класс FPSMemCounter, а в код добавить:
Графика
Использовать графику во флеш можно и растровую и векторную. Использование растровой графики плохо сказывается на объёме файла, зато хорошо на производительности — если речь идёт о сложной графике.
Наоборот, использование векторной графики хорошо сказывается на объёме, но плохо на производительности, особенно когда очень много небольших элементов. Мы рисовали графику прямо во флэш.
Совет — флеш автоматически ужимает растровую графику при публикации, поэтому лучше самому настроить параметры публикации иначе на выходе можнополучить графику низкого качества.
Для улучшения производительности с векторной графикой, её можно оптимизировать (Модификация => Фигура => Оптимизация). Неплохо пользоваться cacheAsBitmap = true, тогда ваша векторная графика не будет перерисовываться каждый кадр, что тоже позволит улучшить производительность.
Насчёт рисования я плохой советчик. Здесь уже полно уроков по рисованию. Но вот мои пять копеек: Для рисования лучше использовать планшет Wacom, они конечно стоят дорого, но можно заказать б.у. на e-bay. Если планшета нет, можно обрисовывать контуры рисунка мышкой и подправлять их прямо во флеш. И не забывать про Ctrl+Z.
Звук
Про звук не так много статей. Я использовал Audacity, бесплатная программа для обработки музыки. Она позволяет не только обрезать звук в нужных местах, там есть очень полезные фильтры: удаление шума, затухание звука и нарастание и многие другие, но я пользовался именно этими. Звуки для игры я записывал или на телефон или прямо на микрофон ноутбука.
Звуки кнопок, это звук удара по бамбуковым палкам, звук взрыва, это звук колокола коровы и т.п.
Потом просто применял фильтр от шума, затухание вконце и нарастание в начале. Звук готов.
Конечно, если есть возможность лучше нанимать профессионала, но если нет возможности…
программирование звука — прочитайте тут
Очень удобно управлять звуками создав специальный класс и использовать dispatchEvent для передачи событий в этот класс для проигрывания звуков.
С этим классом удобно использовать кнопки выключения/включения звука по каналам.
FIN
Игра готова? Протестирована на знакомых?
Не забудьте сделать прелоадер. Я с этим мучался 3 дня. Всё работало, но экран прелоадера показывался только с 80%. Перечитав кучу гайдов о том, как сделать прелоадер и перепробывав более 6 методов, перепроверяя код, ловя ошибки я ни к чему не пришёл. Начал по кускам удалять игру и смотреть, что получится. В итоге причина была проста, во «второй кадр», в котором лежит всё, что должно подгружаться при вставке из библиотеки вкладывался только 1 звук, остальные не включались в этот кадр. Это баг или ещё что-то, не знаю. В символе AssetsHolder, в котором лежат все объекты для до загрузки, звуки вложил на разные кадры- сработало. Теперь считает от 1%.
Попытайтесь найти продюсера для своей игры, если не получится (у меня не получилось), прийдётся делать всё самому, без советов.
Я сделал всё не так(из-за чего игра пока не продана), но, полагаю, что нужно было действовать следующим образом:
1)сделать сайт лок для FGL
2)составить хорошее описание на хорошем английском
3)сделать красивый аватар(100*100)
4)подготовить красивые принт скрины игры
5)сделать небольшое видео с лучшими моментами геймплея
6)разослать по спонсорам предложение посмотреть
ps
Возможно, между 5 и 6 пунктом лучше сделать «порку» на форуме, доработать и уже потом показывать?
Повторюсь, я пока не продал игры и этот рассказ с моей колокольни. Саму игру можно посмотреть по ссылке.
Прочитав множество блогов разработчиков я хотел бы тоже преподнести свой небольшой вклад. Надеюсь, информация была полезной и увлекательной.

Я очень рад, что моя половина разделила моё увлечение и всячески помогала мне в этом, не только советами но и делом.
Эта статья не в коем случае не является 100% руководством к действию, в ней я описываю наш “путь” первой игры. Возможно профи увидят в написанном много глупостей и очевидностей, или знают как реализовать той или иной функционал более изящным методом. Профи, пишите комментарии о ляпах и помогите советом нам, начинающим.
Есть такая поговорка: «Счастье, плохой наблюдательный пункт». Именьно поэтому я решил написать статью с “наблюдательного пункта“ после создания первой игры. Пока ещё свежи воспоминания.
Начало
Чтобы что-то строить, нужно уметь держать в руках инструмент. Глупо забивать гвозди микроскопом, когда удобнее использовать молоток. Первая игра должна быть простой в реализации. Есть готовые движки и библиотеки для создание игр Box2d, Pixel, Push Button Engine, WCK … К некоторым есть подробные гайды даже на русском языке, но сначала я бы рекомендовал изучить основы AS3.
Именно AS3.
Для этого подойдёт книга Рич Шупа и Зевана Россера Колина «Изучаем ActionScript 3.0» или книга Колина Мука «ActionScript 3.0 Для Flash». Она большая, но прочитайте хотя бы первые 6 глав. Ну хотя бы главу про список отображения.
Ещё бы я посоветовал прочитать туториал MJW по созданию игры. Именно на основе его прочтения я и сделал движок для Светлячка. Если у вас проблеы с английским, то гугл переводчик более менее сносно переведёт. Зато вы узнаете много интересного, о том как взаимодействуют объекты и как это описать. Туториал очень подробный, со всеми исходниками. Всего 12 глав, на каждую главу не более часа. И к каждой главе есть отдельные исходники.
Для игры вам нужна Идея. И не просто идея: “ну пусть это будет стрелялка про зомби и кровищи побольше”, а глубоко проработанная идея. Кто герой, какое оружие, как будет развиваться герой от уровня к уровню, сколько будет уровней, какая цель героя, какое управление, сколько уровней, сколько противников, как начинается уровень и как заканчивается… Чем глубже будет проработано, тем лучше вы сможете представить себе структуру игры. Конечно потом в процессе создания можно всё изменять, но имея в голове стуктуру игры(а лучше на бумаге) гораздо проще сделать план разработки и действовать по нему.
Кстати про план, очень полезная штука, если им правильно пользоваться. Чем подробнее план, тем лучше. Распишите все элементы, которые нужно сделать(нарисовать и запрограмировать). И от малого к большому начинайте реализовывать. Так приятно вычёркивать из списка уже сделанное. Если на чём то забуксовали, просто разбейте на более мелкие части.
Код
Мне вообще нравится использовать карандаш и бумагу для планирования. Перед тем как писать код нарисуйте структуру игры. Прелоадер => Главное Меню => Выбор Уровня => Игра => Выигрыш => Игра …
Понятно, что из Главного Меню можно попасть не только на Выбор Уровня, но и на Настройки, а из Выбора Уровня можно попасть назад в Главное Меню. А куда можно попасть из Игры? Очевидно что в Паузу или Выигрыш или Проигрыш. А из Паузы? Нарисуйте всю структуру и связи в ней.
К связям неплохо приписать информацию, которая передаётся в новый элемент. Например из Игры в Выигрыш можно передавать информацию о кол-ве очков, время игры, оставшихся жихнях. А из Выбора Уровня как минимум передаётся информация о выбранном уровне.
В своё время я кучу времени потратил на поиск удобного способа передачи информации между классами. От родителя к сыну и наоборот( от вызывающего класса к вызванному, и наоборот). Например у меня Игра, это класс который вызывается каждый раз с разными параметрами в зависимости от выбранного уровня в Выбор Уровня.
Передать данные в вызванный класс легко:
playScreen = new PlayScreen();
addChild( playScreen );// добавляем класс
playScreen.pusk(false,0);// вызываем в этом классе функцию с передачей данных из родителя
или
playScreen = new PlayScreen();
playScreen.numEnemy = 3; // передаём данные в переменную numEnemy (она должна быть public)
playScreen.numBonus = 1;// передаём данные в переменную numBonus
addChild( playScreen );// добавляем клас
А вот наоборот сложнее, вызванный класс не может обратиться к родителю и передать ему данные. Для этого отлично подходит dispatchEvent.
Логика проста:
1)создаётся класс для передачи событий NavigationEvent, наследник Event
package
{
import flash.events.Event;
public class NavigationEvent extends Event
{
public static const WIN:String = "win";
public function NavigationEvent( type:String )
{
super( type );
}
}
}
2)создаётся слушатель события
playScreen.addEventListener( NavigationEvent.WIN, onWin)
3)при наступлении условий для выигрыша в коде класса PlayScreen пишется
dispatchEvent( new NavigationEvent( NavigationEvent.WIN ) );
4)Вуаля, если условия для выигрыша выполняются, срабатывает dispatchEvent и передаёт событие NavigationEvent.WIN, а его слушатель уже вызывает функцию onWin в родителе.
Не обязательно использовать константу в классе NavigationEvent:
public static const WIN:String = "win";
вместо неё можно передавать переменную типа string, об этом подробнее в части про звук.
Старайтесь не тратить много времени на оптимизацию кода, который выполняется разово(например при инициализации меню), но если код используется часто на EventFrame или по таймеру, оптимизируйте его. Я потратил несколько дней на оптимизацию кода меню выборауровней, а потом только подумал — ну стало не 140 строчек кода, а 40. Кто заметит разницу? И наоборот оптимизация часто повторяющегося кода в игре очень заметна. Для отслеживания «пульса» игры используйте счётчик FPS. Например этот. Используя код по ссылке создать класс FPSMemCounter, а в код добавить:
var MyFPSMemCounter : FPSMemCounter = new FPSMemCounter ();
addChild( MyFPSMemCounter );
Графика
Использовать графику во флеш можно и растровую и векторную. Использование растровой графики плохо сказывается на объёме файла, зато хорошо на производительности — если речь идёт о сложной графике.
Наоборот, использование векторной графики хорошо сказывается на объёме, но плохо на производительности, особенно когда очень много небольших элементов. Мы рисовали графику прямо во флэш.
Совет — флеш автоматически ужимает растровую графику при публикации, поэтому лучше самому настроить параметры публикации иначе на выходе можнополучить графику низкого качества.
Для улучшения производительности с векторной графикой, её можно оптимизировать (Модификация => Фигура => Оптимизация). Неплохо пользоваться cacheAsBitmap = true, тогда ваша векторная графика не будет перерисовываться каждый кадр, что тоже позволит улучшить производительность.
Насчёт рисования я плохой советчик. Здесь уже полно уроков по рисованию. Но вот мои пять копеек: Для рисования лучше использовать планшет Wacom, они конечно стоят дорого, но можно заказать б.у. на e-bay. Если планшета нет, можно обрисовывать контуры рисунка мышкой и подправлять их прямо во флеш. И не забывать про Ctrl+Z.
Звук
Про звук не так много статей. Я использовал Audacity, бесплатная программа для обработки музыки. Она позволяет не только обрезать звук в нужных местах, там есть очень полезные фильтры: удаление шума, затухание звука и нарастание и многие другие, но я пользовался именно этими. Звуки для игры я записывал или на телефон или прямо на микрофон ноутбука.
Звуки кнопок, это звук удара по бамбуковым палкам, звук взрыва, это звук колокола коровы и т.п.
Потом просто применял фильтр от шума, затухание вконце и нарастание в начале. Звук готов.
Конечно, если есть возможность лучше нанимать профессионала, но если нет возможности…
программирование звука — прочитайте тут
Очень удобно управлять звуками создав специальный класс и использовать dispatchEvent для передачи событий в этот класс для проигрывания звуков.
С этим классом удобно использовать кнопки выключения/включения звука по каналам.
FIN
Игра готова? Протестирована на знакомых?
Не забудьте сделать прелоадер. Я с этим мучался 3 дня. Всё работало, но экран прелоадера показывался только с 80%. Перечитав кучу гайдов о том, как сделать прелоадер и перепробывав более 6 методов, перепроверяя код, ловя ошибки я ни к чему не пришёл. Начал по кускам удалять игру и смотреть, что получится. В итоге причина была проста, во «второй кадр», в котором лежит всё, что должно подгружаться при вставке из библиотеки вкладывался только 1 звук, остальные не включались в этот кадр. Это баг или ещё что-то, не знаю. В символе AssetsHolder, в котором лежат все объекты для до загрузки, звуки вложил на разные кадры- сработало. Теперь считает от 1%.
Попытайтесь найти продюсера для своей игры, если не получится (у меня не получилось), прийдётся делать всё самому, без советов.
Я сделал всё не так(из-за чего игра пока не продана), но, полагаю, что нужно было действовать следующим образом:
1)сделать сайт лок для FGL
2)составить хорошее описание на хорошем английском
3)сделать красивый аватар(100*100)
4)подготовить красивые принт скрины игры
5)сделать небольшое видео с лучшими моментами геймплея
6)разослать по спонсорам предложение посмотреть
ps
Возможно, между 5 и 6 пунктом лучше сделать «порку» на форуме, доработать и уже потом показывать?
Повторюсь, я пока не продал игры и этот рассказ с моей колокольни. Саму игру можно посмотреть по ссылке.
Прочитав множество блогов разработчиков я хотел бы тоже преподнести свой небольшой вклад. Надеюсь, информация была полезной и увлекательной.
- +9
- FreeShift
Комментарии (81)
1. за зеленые листики давать очки, за красные отнимать
2. убрать движение экрана влево-вправо
3. убрать мерцание экрана при касании любых листиков
4. добавить хоть какое-то развитие геймплея, чтобы игроки не заснули/закрыли игру через 1 минуту
5. пока что вы наврятли сможете метко попасть в эстетствующих хардкорщиков, так что рекомендую обратить своё внимание на казуальный стиль графики — светло, ярко, радостно, легко. С музыкой — тот же совет.
Удачи!
Как статья то? В
2 никому движение не нравится, думал это прибавит объёма
3 я как раз хотел фидбек сделать, что прикосновение с препятствием это плохо.
4 оно постепенно развивается от уровня к уровню, видимо недостаточно быстро
Спасибо.
Ну если надо тебе — вызывай прямо функцию у родителя, зачем что-то диспачить?
Хотя может это модно сейчас. Хз.
Например у меня вся логика геймплея в классе Game, который был вызван и добавлен на сцену через главный класс(DocumentClass).
Как вызвать из кода класса Game функцию своего родителя?
Например функцию удаления класса Game со сцены?
Как-то так.
Просто непонятно, зачем терять ссылку на родителя, а потом через диспач ее снова искать.
Рассылаешь сообщения, кому они нужны — получают и делают, что положено.
Зачем потомкам что-то знать о родителях? Они выполняют свою работу и оповещают об изменениях
Согласен применять все надо исходя из особенностей проекта.
В общем случае отсутствие сильной привязки к остальным классам делает его более универсальным и облегчает повторное использование.
Поэтому надо просто это сделать.
Вообще, лично я считаю, что с опытом программист постигает самый главный дзен: «знать всякие штуки и уметь их НЕ применять» :)
Однако стараюсь не вдаваться в крайности, поэтому в таком случае юзаю вызов полей-функций (var onWin: Function). И писать мало, и со структурой порядок.
И гораздо проще чем я делал. В будущем упростит сильно жизнь.
Но зато сделал на диспатче класс звуков. :)
когда я делаю так, то при запуске игры почему то все ас3 файлы(весь код игры) загружается в первый кадр, что приводит к тормозам в прелодере.
я к примеру продаю вне ФГЛ
тут присваиваете? или все таки на равенство проверяете?
Event'ы вещь удобная, но весь движок на них строить не стоит, они очень медленные (даже если брать их заменители).
При сильной вложенности и большом количестве объектов еще и управлять всем этим будет сложно.
Я предпочитаю (за редким исключением) чтобы ивенты жили в пределах одного объекта и занимались только этим объектом.
И лучше организовать передачу параметров, меньше объем кода будет (про это уже написали).
Да они медленнее, но это не те значения которые так уж сильно сказываются. Обычно другие факторы вносят намного большие тормоза.
В треде на флешере довольно много хороших специалистов отписались, и практически все пишут, что если правильно их применять, то ничего плохого в них нет.
Ивенты вещь не только удобная, но и быстрая и более гибкая чем те-же калбеки. Под быстрой я понимаю, что не медленней вызова функции через указатель (в норм языках это быстро во флеше произвоительность меняется от версии к версии). Это конечно исключает оригинальные ивенты от индийских прогламмистов идущие с самим флешем.
ЛОЛ. Ивенты как раз упрощают управление. Сложно переключить мозг на писание под ивент-архитектуру, если он уже испорчен другими подходами-парадигмами, но юзать уже написанные и протестированные либы — одно удовольствие.
Не удивительно, что после стрельбы из пушки по воробьям ивенты и неудобные и медленные и кучу ненужного кода порождают. Порождают плохой код не подходы, а тот, кто неумело ими пользуется.
— Я понял — тут заговор матерых программистов — они не хотят палить тему с крутостью ивентов, чтоб молодые задрачивались ваще на мегарульном функциональном программировании, которое в изначально полностью ООП-шном АС3 вообще редкостный и изысканнейший изврат.
— И вообще, лично я считаю, что с опытом программист постигает самый главный дзен: «знать всякие штуки и уметь их правильно применять как надо и где надо»: Р — Т.е. понимать, нафига оно вообще надо, а не использовать для спила дерева не пилу, а пилочку для ногтей — а чо, тоже ж можно и дзен типа постигаешь.
— Ивенты дают гибкость. Это главная их особенность.
Есть четко поставленное условие от которого не будет отклонений и нет подходящего фреймвока — писать с нуля и жестко (с прямыми вызовами, кастомными списками обработчиков) будет проще и быстрее.
Нет четкой задачи, условия будут перестраиваться по ходу — уже лучше использовать ивент архитектуру, даже если писать ее с нуля.
— Насчет примеров кода с тормозящими ивентами — та изобразить можно что угодно, причем тормозящее проще. Самый главный фактор, вносящий тормоза — это когда программист тормоз :) — шутка ничего личного и не про кого лично.
— @abyss: юзай ивенты, но пойми для чего они нужны. И тогда ты извлечешь из них только хорошее.
А вот пример про пилочку для ногтей в топку.) В корни неверный пример и преувеличенный в сотни раз.
Могу на этом примере лично по своему мнению сказать вот так — Это тоже самое что использовать пилу для сруба дерева, но в отношении эвентов мы её ещё и натачивать будим.)))
А если в аналогии писать ли жестко на методах без ивентов и с ними (кстати калбек — это одиночный обработчик события, т.е. упрощенный механизм обработки событий), то скорее это так: для спила нескольких деревьев тебе дают или просто пилу или пилу, топор, точило, веревку и бензопилу с бензином.
P.S. Использую и ивенты и колбеки, говорить что одно лучше чем другое — глупо, надо выбирать по конкретной ситуации.
Не немного сложнее чем setCallback(), не?
мб, так лучше:
или свичем будет потом в слушателе разбирать?
Или можно сделать слушателем метод класса и цеплять его, например, в конструкторе тогда у него будет прямой доступ к свойству level
Вам надо будет плодить классы для разных кнопок. Т.е. для выбора уровня у вас будет класс LevelButton с полем level, для качества отрисовки понадобится класс QualityButton с полем quality. А проще создать класс MyButton который будет иметь метод setCallback() и использовать этот класс повсеместно.
или это похоже на мой способ, или я чего-то не понял :)
А на счет классов, если группа кнопок имеет одинаковое поведение и свойства, например: линейные размеры, одинаковые наборы картинок на каждое состояние, etc. — то не вижу нечего зазорного чтобы выделить их в отдельный классы, а не передавать каждый раз в конструктор множество повторяющихся параметров.
nameButton = event.target.name;
var myLevel = int(nameButton.charAt(4)+nameButton.charAt(5));// имена lvl_1...lvl_15 например
Но такой способ проще, если делаешь меню в IDE, там даешь инстанс-имена кнопкам и их классы генерирует IDE
Рановато вам ивенты юзать :)
запись ...args вам понятна?
Что мешает повесить один слушатель на само меню (в котором расположены кнопки), а дальше через event.target смотреть какая именно кнопка нажата.
А другие пусть используют ивенты в пределах одного класса и доказывают, что калбеки (которые с некоторым утрированием можно назвать частным случаем ивентов).
Это каких событиях?
События на то и события, что они генерятся не в определенное время. Какие преимущества дают при этом колбеки?
Каждый все равно будет писать так, как ему удобно. Да и автор, сам решит как ему удобнее.
Не нужно из мухи делать слона. Из всего написанного обсуждать можно только скорость, все остальное — на вкус и цвет.
Здесь все лишь комментарии в конце концов, и дискуссии тут вести не удобно совсем.
Скорость чего?
Разработки? — ивенты ее увеличивают если их использовать в общей архитектуре на расширяемых узлах (Вот кнопки как раз оч хороший пример, только если не узколобо лепить к ним единственный обработчик).
Быстродействия? — стандартные ивенты тормозные, для скорости надо писать свои. Свои быстрые насколько оптимально написан их код.
Для кого — вкус и цвет, а для кого сознательный выбор более эффективного средства.
Я не холиварю. Я привожу разумные выводы (на доводы к сожалению места нет — да, неудобно тут с этим), а не домыслы и надуманные куски кода, которыми тут кишит. Разница понятна между убеждениями и выводами. Поэтому я нисколько не холиварю — это делают большинство остальных.
зы: кстати калбэки устаревшая техника со времен когда не было ООП и был такой язык Си без плюс-плюс. И выпиливаются калбэки ООП элементарно, ибо тупо передаем не сслылку на функцию, а объект с нужными интерфейсами, которые дергаются. И это уже кстати гибче и быстрее, т.к. приведения типов не надо — будет дергаться нужный метод с нужным набором параметров. Я могу еще продолжать, но надоело… Все, кому надо услышали и поняли, остальные — юзайте древние приблуды и гордитесь этим.
Вот только это постепенно нужно делать, а не забивать себе голову с самого начала.
И зря ты так про С. Это язык жив и еще многие новомодные плюшки переживет.
Потому как идеально заменят ассемблер и дает максимум скорости при стандартной разработке.
А на повестке дня у нас как раз слабые системы. Смартфоны, планшеты, приставки, нетбуки.
И ObjectiveC хорошо это доказывает (это совсем не C++).
Вытеснили его только там, где нужен параллелизм + скорость, но там и текущие OOP фавориты тоже в пролете.
Но это уже оффтопик.
Вот для начинающего лучше и ориентироваться сразу правильно. Для начала стандартные флешовые поюзать, понять, потом под себя либу сделать.
Еще в кратце: СОП (событийно ориентированный подход/программирование) позволяет реализовать даже некоторые парадигмы ООП, что актуально для процедурных языков без ООП. Также позволяет избавится от нагромождения select-case в типичной модели состояний системы, просто включая и отключая нужные обработчики событий. Дает большую гибкость для доработки кода — это (как и ООП) оценится когда надо будет переписывать и повторно использовать куски кода от предыдущих проектов.
Рекомендую! :) *зловеще потирает руки: еще одного обратил: Е*
зы: еще можно пошарить по исходникам мочиАПИ — у них своя система ивентов, хотя и недалеко от стандартной флешевой ушла — ленивые они. Но для понимания подойдет. А дальше под свои нужды либу ивентов можно написать или воспользоваться готовой — они есть. Есть либа turbosignals, но она больше для примера как раз того как калбэки заменяются в ООП. И еще она очень быстрая за счет прямых вызовов методов. Но в реале ее неудобно использовать — только посмотреть для обучения. На флешере выкладывали свои наработки люди и еще есть robertpenner/as3-signals — неплохая либа порт на АС3 с пошарпаной Qt.
Как по мне либа as3-signals сильно навороченая, возможности там больше для системного программирования чем для игрового. В большинстве случаев в играх примитивной реализации — событие со списком слушателей (вызываемых калбеками) вполне достаточно.
Кстати евенты и колбеки одна малина — что мешает использовать евент, как колбек
Да. Вариант калбеков, которые тут приводились — это уже примитивная форма ивент подхода. Более развитая и гибкая, это когда на событие цепляется несколько калбеков. Т.е. по сути тут несли фигню: ивент архитектура использует калбеки в основе, соотв. использование калбеков — уже использование примитивной ивент архитектуры.
мне как начинающему, начинающему, и все никак не начавшему свою первую игру, очень интересно смотреть на первые игры других девелоперов, а у вас на фгл игра закрыта(
Пытался сделать видео, но пока не получается. Как сделаю, тут же добавлю. Проблема в том, что мы путешествуем, а нетбук и старый ноут тормозят при записи. Я попросил друга записать, так что скоро добавлю. Да и на FGL в описании игры видео сильно не хватает. Говорят, спонсоры не любят игры играть, они любят ролики смотреть.
«Для отслеживания «пульса» игры используйте счётчик FPS. Например этот (ссылка).»
А ссылки нет :)
согласен с остальными — использование ивентов это спорный момент, особенно для начинающих мне кажется это трудно для восприятия. но тут на помощь им придут комментарии к этому посту и люди поймут в какую сторону копать. так что всё нормально)
Некоторые слишком сложны пока, но большинство примеров я уже попробовал запрограммировать и они сработали. Думаю ими воспользоваться в следующей игре. Надеюсь эти советы пригодятся не только мне.
По аналогии с хабром:
— Теперь я знаю знаю как управлять flashgameblogs, нужно постить советы как программировать (зловещий хохот за кадром) :)