Глобальное хранилище

Глобальное хранилище:

При разработке всегда хочется создать некий удобный сундучек, куда можно было бы складывать часто используемые вещи, то есть указатели на экземпляры классов или их методов для быстрого доступа к ним. И вот сегодня я хочу поделиться с вами таким сундучком [...]

Апельсины недоумевают или немного про деньги

Апельсины недоумевают или немного про деньги:

Cover Orange никак не определится, где ему быть в топах. То пробирается на хорошие места, то вовсе вылетает из топов. Издатели суетятся, предпринимают какие-то попытки, в середине марта даже предпримут сразу несколько попыток в одно время. Должно помочь, а то ведь непонятно. Не гоже.

Вот малость статистики: версию для айфона скачали (и заплатили за это) почти 130 тысяч человек. Версию для айпада скачали (это я за все время имею ввиду) 100 тысяч человек. Сюда же засуну и про Physics GameBox - 100 тысяч купивших. Итого – всего заработано играми на айдевайсах – 400 тысяч долларов с гаком. От этой цифры откусывает свою долю Эппл (хорошо живут), оставшееся делим мы с издателем.

Суточные платные скачивания на сейчас – 2000-3000 штук в среднем. В выходные и до 4000 доходит (рекорд – 13 тысяч), в понедельники и до 1500 скачавших [...]

Аддиктивность

Аддиктивность:

Аддикция - навязчивая потребность, ощущаемая человеком, подвигающая к определенной деятельности. Это зависимость от интернета, курения, телевизора, постоянных покупок, игр, влюбленности и т.д.

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

Люди играют в игры по разным причинам: хотят расслабиться, занять свободное время, самоутвердиться, побыть в ином мире и т. д. Во всех случаях игроки не любят прекращать игру. И в этом нет ничего особенного. Так же люди не любят прерываться посредине просмотра фильма или бросать чтение на интересном месте. Но иногда бросить играть решительно невозможно. Хочется играть еще и еще. Что-то постоянно заставляет делать еще один ход, получать еще один уровень, проходить еще одну пещеру. А если человек в данный момент не играет, то постоянно думает об игре. Такое поведение я называю аддиктивностью.

 

Внутренняя аддиктивность

…возникает во время игры. Игрок просто не может остановиться играть. Но если уж остановился, то вернуться в игру особо не стремиться (если нет внешней аддиктивности).

Каждый образованный игрок может назвать минимум одну игру, которая не позволяла оторваться от игрового процесса. Мой топ – Civilization. Фраза “еще один ход, и ложусь спать” возникла, наверное, именно в этой игре. Вообще пошаговые игры типа HoMM имеют довольно сильную внутреннюю аддиктивность. Игры, основанные на рандомном дропе (Diablo) также заставляют постоянно играть. “Однорукие бандиты” тоже, кстати, основаны на рандомном дропе :) Сокровища Монтесумы – игра, отлично демонстрирующая наличие внутренней аддиктивности и отсутствие внешней. Пока играешь – оторваться невозможно. А оторвавшись можно забыть об игре до следующей игровой сессии [...]

Видеоурок №3

Видеоурок №3:

Урок про создание тел в Box2d, в том числе — невыпуклых полигонов, а также, про отображение тел Box2d мира при помощи спрайтов.

Видео отныне на Vimeo. Архив проекта. Приятного просмотра! )

TowerDefence #6. Редактор уровней

TowerDefence #6. Редактор уровней:

В прошлом уроке мы научили наших врагов искать путь и даже немного бегать по карте, но все это пшик без редактора уровней. Настало самое время отделить игровой процесс от редактора уровня и разобраться со способом хранения уровней в нашей игре.

Не программные примеры шаблонов проектирования программного обеспечения

Не программные примеры шаблонов проектирования программного обеспечения:

Шаблоны проектирования программного обеспечения уходят корнями в архитектурные шаблоны Кристофера Александера, и в вопросы перехода к объектам. Согласно Александеру, шаблоны повторяют самих себя, поскольку они являются обобщенным решением для задаваемой системы сил. Вопросы перехода к объектам рассматривается в реальном мире для того, чтобы проникнуть в суть взаимоотношений при моделировании программного обеспечения. С такими двойственными корнями, вполне логичным будет найти повторяемость шаблонов проектирования программного обеспечения в объектах реального мира. В этой статье представлен реальный мир, не программные экземпляры каждого шаблона проектирования из книги «Приемы объектно-ориентированного проектирования. Шаблоны проектирования» [13]. В статье также приводятся выводы о не программных примерах как эффективной основе языка шаблонов для взаимообщения и обучения проектированию шаблонов.

1. Введение

В индустрии программного обеспечения существует растущее сообщество сторонников применения шаблонов. Корни перехода к шаблонам можно найти в работах архитектора Кристофера Александера, который описывал шаблоны как обобщенное решение для задаваемой системы сил в мире [1]. Шаблоны Александера можно обнаружить в повседневных структурах. Каждый из шаблонов в «Языке шаблонов» [2], включает в себя картину архетипического примера шаблона.

Поскольку объекты были преобладающим взглядом на мир в то время, когда мир программного обеспечения знакомился с шаблонами, они тоже имеют корни в переходе к объектам [9]. К сожалению примеров шаблонов моделирования программного обеспечения было не так много как у Александера, а они представляли собой более элегантные модели, в отличие от моделей, что люди генерировали в самом начале [13]. Доступ к элегантным моделям часто ограничивался в связи с проприетарным характером большей части программного обеспечения, разработанного сегодня.

Согласно Александеру, реальный мир шаблонов всегда повторяет самого себя, поскольку в соответствии с заданным набором обстоятельств, всегда существует определенные поля взаимосвязей, которые являются наиболее хорошо приспособленными к силам, которые уже существуют [1]. В программном обеспечении, задачи реального мира либо моделируются целиком, либо объекты реального мира сводят к аппаратному программному обеспечению, а программы выводят результаты реального мира [5]. Поскольку шаблоны моделирования программного обеспечения имеют корни как в шаблонах Александера, так и в вопросах перехода к объектам, представляется вполне логичным, что шаблоны моделирования программного обеспечения могут быть найдены и в объектах реального мира. Это не означает, что шаблонам моделирования программного обеспечения необходимы модели объектов реального мира, но взаимосвязи между объектами, которые приспособлены для работы с определенными силами, могут быть обнаружены как в «реальном мире», так и в объектах программного обеспечения. Чтобы проверить эту гипотезу, были найдены примеры из реального мира для каждого из 23 шаблонов «Банды Четырех» [13]. Эти примеры приводятся далее в разделах со 2 по 4.

2. Порождающие шаблоны

Пять порождающих шаблонов были задокументированы группой авторов, называвших себя «Бандой Четырех». Примеры таких порождающих шаблонов могут быть найдены в обрабатывающей промышленности, на предприятиях быстрого питания, в биологии и в политических институтах [...]

Биндинг в ActionScript проектах. Часть 1

Биндинг в ActionScript проектах. Часть 1:

Перед разработчиками часто встает вопрос о взамодействии различных классов в приложении. Как классы приложения будут обмениваться информацией между собой, сообщать о тех или иных изменениях? Это должно происходить своевременно. Для этих целей во Flex-фреймворке есть замечательный инструмент, значительно облегчающий жизнь разработчику – биндинг (binding). И как оказалось этой возможностью можно с успехом пользоваться и без использования Flex-фреймворка. Начиная с какой-то-там одной из третьих версий SDK адобовцы постарались максимально изолировать биндинг и все что с ним связано, и теперь его использование добавляет приложению считанные килобайты.

Как бы мы сделали

Немного отвлечемся и поговорим о частном случае. Когда же нам может все это дело пригодиться? Например, при разработке с использованием паттерна MVC встает вопрос о своевременном реагировании компонентов отображения на изменения в модели.

Как известно в MVC классы модели ничего не должны знать и не иметь ссылок ни на классы контроллера, ни на классы отображения. А вот на модель имеют ссылку и контроллер и отображение. Контроллеру нужна ссылка для того чтобы изменить модель, отображению – чтобы отреагировать на изменения. С изменением модели вроде все понятно – нужно поменять свойство. Но как отображение узнает о том что данные были изменены, чтобы самому измениться? Как правило для этих целей используются события. Мы создаем в модели сеттер на нужное нам свойство и в тот момент когда свойство меняется – посылаем соответствующее событие:

1 2 3 4 5 6 7 8 9

private var _text:String; public function set text (value:String):void{     if (value == _text){         return;     }     _text = value;     dispatchEvent(new Event("textChanged")); }

Класс отображения имея ссылку на модель может поймать данное событие и отреагировать на него соответствующим образом. Все вроде хорошо, но есть ряд неудобств:

1. Для каждого свойства в модели придется писать геттер/сеттер. А это много рутинной писанины, класс начинает пухнуть.
2. При большом количестве свойств в модели будет либо расти количество типов событий, либо придется делать кастомное событие и передавать дополнительно что же именно изменилось и новое значение. В любом случае неудобно.

Как это делается с помощью биндинга

А как же все таки было бы здорово просто написать в классе отображения: “при изменении вот этого свойства вон в том экземпляре класса изменить вот это свойство” или вот так: “при изменении вот этого свойства вон в том экземпляре класса вызвать вот этот метод для обработки”. Так вот стандартный флэксовый биндинг работает именно так.

Давайте посмотрим как это будет выглядеть непосредственно в коде. То свойство за которым нам необходимо пристально следить нужно пометить как bindable. Делается это очень просто, с помощью метатега [Bindable]:

1 2 3 4 5 6 7 8 9

package{     import flash.events.EventDispatcher;     // Класс который использует метатег [Bindable] должен обязательно расширяться от EventDispatcher     public class ClassWithTextProperty extends EventDispatcher{         [Bindable]         public var text:String;     } }

В классе который должен следить за свойством text в другом классе будет написано следующее [...]