Браузерная стратегия «Пути Истории». Архитектура и эволюция проекта

В этой статье я расскажу о разработке и эволюции технической части браузерной игры «Пути Истории».
Уделю внимание выбору языка программирования, базы данных, технологии и архитектуры. Расскажу о хостинге.

Пути Истории — это массовая браузерная стратегическая игра. Проект начинался с энтузиазма одного человека и вырос до серьзного проекта с немалой аудиторией.

Читать дальше: Браузерная стратегия «Пути Истории». Архитектура и эволюция проекта

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

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

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

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

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

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

1. Введение

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

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

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

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

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

Осваиваем Flash. Часть 5.

Осваиваем Flash. Часть 5.:

Всем привет!

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

Без лишних слов, приступим!

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

Всегда и везде, мы хотим свести наше участие, как программиста, в работе системы к минимуму, предоставив дизайнерам возможность воплощать любые их, даже самые смелые, замыслы, не отвлекая нас от зарубов в Quake. Объекты в нашей программе должны быть максимально самостоятельными, нас не должно волновать ни их количество, ни их тип или детали их функционирования и взаимодействия. Это все конечно в идеале, в жизни все немножко сложнее, но без трудностей было бы просто не интересно.

• Нам потребуется некоторый универсальный объект на все случаи жизни, таким объектом станет класс S_Node.
• Для управления этими универсальными объектами нам понадобится менеджер сцены S_SceneManager. 
• Так как менеджер сцены сам по себе не может хранить объекты, то для этой цели мы опишем менеджера образцов S_InstanceManager и расширим класс S_Node, создав класс S_Instance (потомок класса S_Node). Это связано с тем, что менеджер образцов работает только с объектами типа S_Instance.

Программист игровой логики будет создавать новые классы и объекты, наследуя класс S_Instance. Таким образом мы избавим его от необходимости вникать в тонкости функционирования системы в целом, давая возможность сосредоточится на реализации конкретного элемента интерактивного приложения или объекта игры.

Давайте остановимся на универсальном объекте S_Node и посмотрим, что он должен уметь. О расширении этого класса - S_Instance поговорим позже, когда доберемся до менеджера образцов [...]

TowerDefence #4. Готовимся к поиску пути

TowerDefence #4. Готовимся к поиску пути: "Очень мне хотелось в данном уроке уже рассказать о том, как мы будем искать путь, но пока еще не все для этого готово. Нужно сделать некоторые исправления и добавить новый функционал в нашу игру."

Package organization

Package organization: "

Организация кода в пакеты

Словарь

Рефакторинг - Классическая книга описывающая практики рефакторинга - http://www.ozon.ru/context/detail/id/1308678/
DSL - Domain-specific language

Введение

Пакеты это механизм для организации кода и разрешения конфликта уникальности наименования классов. Это техническое определение, но по какому принципу создавать наименования? Какими критериями руководствоваться? И зачем вообще об этом задумываться?
К сожалению этот вопрос слабо освещен в классической литературе. В данной статье я хочу поделиться своим опытом и некоторыми исследованиями по данному вопросу. Первая часть статьи это моя попытка выделить общие принципы. В частности много идей я подчеркнул из презентации Juergen Hoeller, http://www.infoq.com/presentations/code-organization-large-project. Вторая часть статьи - описание вымышленного flex проекта и пошаговое развитие его структуры на основе сформулированных принципов и моего личного опыта.

Общие принципы

Можно сформулировать следующие архитектурные принципы:

Избегать циклических зависимостей;
Избегать дублирования;
Формировать модули;
Стремиться создавать слабо связанные модули;
Выбирать модули на основе логической, концептуальной организации (домена)

Далее о каждом их них более подробно [...]

TowerDefence #3. Первый враг

TowerDefence #3. Первый враг: "В основном все игры начинаются с обработки действий игрока в игре. Но в случае с товер дефенсом, я считаю, следует идти другим путем. Прежде чем добавлять башенки, которые будут отстреливать нечисть, добавим саму нечисть — так как это пожалуй самый сложный и инетересный элемент."

Осваиваем Flash. Часть 3.

Осваиваем Flash. Часть 3.: "Всем привет!

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

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



Часть третья. Почувствуйте себя архитектором.

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

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

Читать дальше: Осваиваем Flash. Часть 3.