gl да, hf - ну тут я не знаю. Игра интересная, оформлена так, как многие казуальные проекты не оформлены. Есть проблема, игра сложная, игра не казуальная. Объясню почему.

Вставь то, не знамо что, в ту хрень, которая не понятно зачем здесь вообще нужна.
Это я про ключи и другие кружочки и звёздочки. Запускаю уровень, и что я вижу: большую табличку, типа пройди уровень за 2 минуты, фоном выступает сам уровень. Нажимаем Погнали и вперёд. Вижу человечка прицел, краем глаза что-то потемнело. Куча чёрных прямоугольников звёздочки и др. очков. Посбивал, очки звёздочки, попробовал пострелять подальше, не получается. По старой памяти знаю что звёздочки можно вставлять. Куда? Попробовал в один квадрат, не вставляется, падает. Попробвал в другой - вставляется, вторую взял, в первый не вставляется, во второй вставилась, квадрат посветлел, о фантастика. Только есть две незадачи: 1. откуда я знаю что за квадратом должно быть? 2. Зачем мне заниматься перебором звёздочек с квадратами, когда идёт время. С первым кое как разобрался. Увидел при очередном рестарте, что квадраты темнеют, а потом ещё догадался сдвинуть стартовую табличку. Стали видны квадраты на начальном экране. Уже лучше, но что мне делать когда я подымусь выше? Второе вытекает из первого. Илья ты наверно специально хотел, чтобы люди проходили уровень по несколько раз, потому как пока не узнаешь, что за каждым квадратом и что куда вставлять быстро уровень не пройдёшь.

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

Предметы вставляетмые тоже плохо описаны, ни есть гут.

Я теперь о хорошем. Игра получилась интересная не смотря на все недочёты. Порадовало многократные отражения луча и когда он всё-таки достигает свою цель. Интересно было проходить уровни с предметами, если бы только не долбило время по скорости. Графика хорошая, соответствует космической теме. Двиг работает хорошо :). Кнопку опций можно было б и убрать если она не работает :).

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

gl - несомненно да.
hf - да, но ...

(:

описание некоторых стандартных типов.

cVector2 - класс вектора в пространстве R2 со стандартными операциями скалярного произведения и т.д.
typedef cVector2<float> Float2;
typedef cVector2<double> Double2;
typedef cVector2<long> Point2;
typedef cVector2<ulong> Dimension2;

cRect - Шаблон ориентированного по осям экрана прямоугольника.
Особо полезен в 2д. Реализация имеет 2 позиции противоположных углов прямоугольника, что отдаётся быстрыми методами проверки сталкновений с другими прямоугольниками или точками.
в основном для описания области на текстуре или на экране используется cRect<float>

HWColor - это цвет который хранится в формате двига, а именно A8R8G8B8. Синоним типу ulong.

ColorValue - класс цвета.
Цвет состоит из 4 вещественных компонент(float), каждая из которых не меньше 0 и не больше 1.
r, g и b определяют цвет. Чем больше значение компоненты, тем больше этой состовляющей в цвете.
a - компонента прозрачности, 0.0 обозначает абсолютную прозрачность, 1.0 - абсолютная непрозрачность.
GetHWColor() вычисляет и возвращает целочисленный цвет типа HWColor.

ZOrderType - тип определяющий порядок вывода в слое. синоним byte.
установка взятие у детей cRenderable класса - GetZ() и SetZ(ZOrderType).

LayerOrderType - тип определяющий порядок вывода слоёв. Каждый слой имеет свой уникальный. синоним byte.
LayerOrderType индефикатор, который и определяет каким по очереди будет выводится слой.
чтобы нарисовать объект - нужно вызвать у него метод Draw(LayerOrderType Layer). а в Layer указать число 0..255 которое и будет указывать номер слоя.
слоям можно изменять всякие настройки. чтобы по номеру получить указатель на слой(cRenderLayer*) нужно вызвать cRender::GetInstance().GetLayer(LayerOrderType Layer). а затем проводить манипуляции с нужным слоем.

не нужно плодить слои, нужно разделять использование z координаты и слоёв.

ПО-УМОЛЧАНИЮ(!) в tabooConfig.h деректива TABOO_RENDER_ZERO_IS_BOTTOM == 1. это означает z или слой с порядком 0 будут лежать на самом нижу.
если TABOO_RENDER_ZERO_IS_BOTTOM == 0, то 0 будет означать самый верх.

freetype
теперь можно выкинуть утилиту создания шрифтов к чёрту, потому что я наконец-то сделал in-core генерацию шрифтов. текстурка автоматически подгоняется по оптимальному размеру, хранится в памяти в формате A8L8.
сегодня сделал простейший класс отрисовки надписей cFontLabel с минимальными возможностями: позиция, цвет шрифта и тени, текст с переносами, горизонтальное выравнивание. всё успешно рисуется. дальше думаю создать cFontLabelFX с поворотами и масштабированием, а затем и cFontText для которого понадобится написать ф-ции расстановки переносов слов на новые строки по области, прокрутку, обрезание по области. неплохо было бы реализовать поддержку текстовых тегов: смена цвета, выравнивание, эффекты.

int64
раньше ф-ция сортировки выглядела ужасно, столько вложенных друг в друга проверок.. z, шейдер, текстура(а может и две и три), тип примитива.
теперь сделал вычисление 64битного хеша для cRenderable. по нему всё теперь и сортируется.

MT
ура, я доделал поддержку мультитекстурирования. =) правда не знаю что сделать в демке на эту возможность.

целый час переделывал старый двиг. цель была переделать кое-что под юникод, чтобы чешская версия была самодостаточной. конфигурация char-set игры и движка теперь unicode. однако не все строки и ф-ции unicode. большая часть осталась ansi, т.к. не требует никакой языковой поддержки кроме английского.

весёлое у нас комьюнити))))

http://www.taboo-games.com/ - чтобы было :)

http://www.kazual.ru/forum/viewtopic.php?t=62 - о нас уже пишут

http://www.alawar.com/soon/birdies/ - однако

Сегодня я по необходимости открыл собственно дизайн документ нашего Kg, т.е. киндергартена. Он был написан аж 01.09.2005, несколько раз модифицировался, последнее изменение 23.11.2005. Прошёл уже год и ещё немного. Интересно, что осталось в ДД Кг того времени в ныне существующем варианте Кг как приложения?

Основная идея и концепта не поменялись. Это уже хорошо, т.е. сделали то, что и задумывали. Осоебнности игры и "фичи", которые были описаны первоначально реализованы полностью даже немного добавилось. Вот с размером дистрибутива вышла небольшая промашка. Заявленное "не более 10 Мб" раздулось в 21Мб, а в распакованном виде все 107 Мб.

Элемент игры который претерпел наибольшее количество изменений, за исключением интерфейса и самого графического оформления это очередь. Под влиянием идей продюсеров она менялась многократно и наверно устаканилась только к марту-апрелю 2006 года. В самом начале желания птенцов были скрыты облачком с вопросиком, и чтобы это желание узнать необходимо было подходить к птенцу. Однако сей момент очень плохо сказывался на построении очереди действий. Не зная что за желание игрок не мог заказывать следующие действия для его выполнения. По этой же причине Аист перестал "переносить" желания и взаимодествовать соответственно желаниям. При этом отпал и жёсткий контроль желаний. После всех этих изменений играть стало проще.

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

Алгоритм ходьбы Аиста между объектами. Т.к. объекты свободно размещаемы на поле, то нужн был алгоритм для генерации путей. Алгоритм такой был создан, но он работал не совсем красиво, путь был достаточно ломанный и Аист при ходьбе выполнял весёлые движения. Для выравнивания был написан другой алгоритм, генерации по сетке. Но и он был затем заменён на вручную расставляемые пути :). Как собственно и предлагалось в самом начале.

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

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

выдержка из Exceptions в играх (2 стр) by cppguru

>>...в этом году многие российские компании с корнями выдирали использование буста из движка
>Это в связи с чем, пардон?
Code bloat, выражается в нескольких вещах:
• Взлетает до звёзд время компиляции (это самое меньшее из зол).
• После некоторого лимита компилятор перестаёт инлайнить функции, даже абсолютно тривиальные (пустое тело).
• В результате размер exe растёт линейно (или ещё хуже) от количества вызовов функций из буста.
• Сложность поддержки кода возрастает в разы.

всё это заставило задуматься. что скажете?