Flash, Flixel и Tower defence или первые шаги в геймдеве

В последнее время не доходили руки до своего блога. За это время я занялся разработкой своей первой игры.
Для начала логично было бы сделать что то простое, а из относительно простых в разработке жанров игр мне самому нравятся только Tower Defence. Выбор технологии тоже был достаточно простым — большая часть мелких игр делают на Flash.

Определившись что и на чем я буду писать, принялся за поиск подходящего фреймворка и тут меня ожидало разочарование. Практически нет толковых Flash фреймворков для 2Д игр. Из того что нашел:

Flixel
FlashPunk
Citrus Engine
PushButton Engine

Ни один из них меня не впечатлил, но решил что лучше пользоватся тем что есть чем городить велосипед с нуля тем более что раньше вообще не имел дел ни с флешем ни с играми. Остановился на Flixel как на самом простом и с живым комьюнити. Позже я не раз пожалел о выборе фреймворка. Flixel идеален для примитивных платформеров, для всего остального там мало того что недостаточный функционал, но даже некоторые вещи проще было бы сделать вообще без фреймворка чем с ним. К примеру в нем нет нормальных средств для организации интерфейсов, невозможно создать два пересекающихся элемента интерфейса (один над другим) — клик будет работать по обоим, а не по тому что сверху.

Из меня никакой дизайнер и не имел дела с играми, поэтому решил искать людей в команду: дизайнера и гейм дизайнера. Это опять было ошибкой. Если у Вас нет совсем близких знакомых с необходимыми навыками (при том эти знакомые должны быть энтузиастами своего дела) то найти человека который будет работать без зарплаты, на голом энтузиазме практически не возможно. А если и найдете то у них быстро угасает энтузиазм и они начинают косячить, тянуть время ИТД. В итоге проект либо тянется годами либо просто умирает.

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

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

В заключение выкладываю рабочий прототип игры версии 0.1. 90% програмного функционала уже реализовано, сейчас работаю над балансом и контентом (карты, монстры ИТД).

Posted in Flash | Tagged , , | Leave a comment

debian + php-fpm + chroot + mail()

Столкнулся с проблемой что перестала работать функция mail() в PHP когда я настроил chroot.
Мучался довольно долго, хотя решается все очень просто.
Предположим что chroot у Вас там-же где и у меня: /var/www

Нашел в сети несколько решений. Обычное — это установить mini_sendmail.

wget http://www.acme.com/software/mini_sendmail/mini_sendmail-1.3.6.tar.gz
tar -zxvf mini_sendmail-1.3.6.tar.gz
cd mini_sendmail-1.3.6

далее для того чтобы упростить себе жизнь меняем одну строчку в mini_sendmail.c:

username=getlogin();

заменяем на:

username=www;

где www это пользователь от которого запускаются скрипты. Если этого не делать то надо будет в chroot добавить все что нужно для определения пользователя — файлы пароля итд.

make
mkdir -p /var/www/usr/sbin
cp mini_sendmail /webroot/usr/sbin/sendmail

в php.ini должно быть (по умолчанию оно так и есть):

sendmail_path=/usr/sbin/sendmail -t -i

если было не так, не забываем перезапустить php-fpm.

И последнее, из-за чего у меня лично и не работало.
Нужно установить в chroot оболочку:
apt-get install bash-static
mkdir -p /var/www/bin
cp /bin/bash-static /var/www/bin/sh

После этого все волшебным образом все начинает работать.

Posted in Uncategorized | Leave a comment

Простой скрипт для бекапа mysql таблиц

Вот сделал такой простенький скрипт, может кому пригодится:

#!/bin/sh

path=/var/backups/mysql/
delete_after=5

for db in db1 db2 db3 db4
do
mysqldump $db | gzip -c ' $path$db-`date '+%Y-%m-mysqldump $db | gzip -c > $path$db-`date "+%Y-%m-%d"`.gz 
done

find $path* -mtime +$delete_after -exec rm {} \;

db1 db2 db3 db4
Список баз данных которые нужно сохранять.

path=/var/backups/mysql/
Куда складывать архивы

delete_after=5
За сколько дней их хранить

Если еще не сделали необходимо в файл /root/.my.conf добавить параметры доступа к mysql

[mysqldump]
user = root
password = password

Posted in MySQL | Leave a comment

Сортировка Украинских букв в MySQL UTF8

Столкнулся с такой проблемой что при сортировке в MySQL Украинские буквы не сортируются правильно по алфавиту. Первыми идут «І, Є», а потом только начинаются (А, Б, В)…
Решение очень простое — выбрать сравнение utf8_unicode_ci.
При этом данные надо загрузить заново — например экспортировать данные, поменять сравнение и импортировать обратно.
Если просто поменять сравнение через ALTER TABLE то проблема останется.

Posted in MySQL | Tagged , | 2 Comments

ZFConf + MageConf впечатления

Сразу скажу — я знаю что такое Zend Framework и Magento поэтому не слишком обольщался что могу что-то интересное для себя лично почерпнуть.
Но они обещали интересные общие моменты для PHP.

На самом деле во всех докладах (кроме Zend потока) на любую тему слово «Magento» повторялось по 10 раз в минуту.
Ну ладно, предположим — ведь они не зря организовывали евент — надо и попиаристся ведь.

Было 4 потока. Zend, Magento, PHP, MIX. Три последние проводились Magento.

Комнаты с Zend и Magento для меня вообще не представляли интереса, так-как ими я не пользуюсь и не планирую пользоваться в этой жизни.

Первый доклад в секции PHP был абстрактным но интересным. В основном все касалось «Велосипедов» и правильного подхода к разработке. Вещи банальные но за счет толкового оратора было довольно интересно.

Второй доклад был просто ляпом со стороны докладчика (Данил Кочерга Tech lead, Oggetto Web.). Такого Epic Fail я не ожидал :) .
Доклад назывался «Опыт построения High Load интернет-магазина». Начнем с того что из названия я ожидал что расскажут что-то на своем личном опыте — реальном проекте. И уж тем более не ожидал что в докладе каким-то образом будет фигурировать Magento. Оказалось что речь шла о нагрузочном тестировании магазина под Magento.

Дальше самое интересное:
На сколько помню железо:
Amazon Extra Large Instance
15 GB memory
8 EC2 Compute Units (4 virtual cores with 2 EC2 Compute Units each)
1,690 GB instance storage
64-bit platform
I/O Performance: High

Очень даже круто, да?

Заранее извиняюсь точных цифр из тестирования не помню (если появится на сайте мероприятия скопирую сюда точные данные).

В детали методики тестирования вдаваться не будем но была поставлена задача до 5сек на полную загрузку сайта со всеми картинками, скриптами, CSSками итд.

Без дополнительной оптимизации на стандартном LAMP сервере это чудо под названием Magento справлялось с задачей не больше чем при 20 запросах в секунду (тут можно делать Face-Palm и кричать EPIC FAIL).

Дальше они начали применять стандартные методы улучшения производительности nginx, memcached, настройки серверного ПО, сжатие скриптов и картинок…

В результате на последнем шаге, они с гордостью демонстрировали слайд с загрузкой сайта при 100 запросах в секунду, за что-то в районе 4сек и генерацией странички за 0.3сек (тут можно повторно делать Face-Palm и кричать EPIC FAIL).

Больше 50 запросов в секунду они даже и не тестировали. В зале был отчетливо слышен неприличный ехидный смех. Кто-то прямо спросил — А Вы понимаете, что Вы сами только-что показали что НА ТАКОМ сервере в дефолтной конфигурации Magento вообще нельзя использовать со сколько-нибудь серьезной нагрузкой? Ответ был тоже супер: «ну это результаты тестирования».

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

В общем я еще походил по другим докладам, ничего интересного для себя не нашел и успешно ушел домой.

Posted in Конференции | Tagged , , , , | 2 Comments

IQ Туписова заблокировано

Только что получил крутое письмо. Вот самый смешной абзац:

Уважаемая администрация сайта!
У меня к Вам два вопроса.
Сегодня я по своей доброй воле хотела помочь знакомому художнику Туписову В.Г.
из Кирова зарегистрироваться на вашем сайте. Он не мог сделать этого сам, т.к в
регистрации не появлялась возможность написать свою фамилию. Сделала это за
него, но он на эту страницу не мог зайти, хотя увидел себя в списке новых
людей. Может быть его IQ или что там подобное заблокирован.

Я давно так не смеялся…:)

Posted in Uncategorized | Tagged | 5 Comments

В поиске google теперь есть предпросмотр сайтов

Не перестаю удивятся как они придумывают новые интересные плюшки. Как Вам это? Удобно, можно посмотреть сайт еще до того как клацнешь. И теперь гугл делает еще и хранит скриншоты ВСЕХ сайтов интернета…

Posted in SEO | Tagged | Leave a comment

Redis, что такое и с чем его есть?

Цель статьи — ознакомить читателей с этой базой данных, а также изложить свои мысли о том в каких случаях её можно использовать.

Официальный сайт Redis.

Как о нем говорят сами разработчики — Redis это Memcached на стероидах. Основное отличие от Memcached — это то что Redis является персистентным хранилищем. Достигается это за счет того, что данные время от времени (либо при каждой записи но об этом ниже) скидываются на жесткий диск. Это происходит асинхронно и не затрагивает производительность чтения/записи в БД.

Второе важное отличие состоит в том — что редис поддерживает не только простое ключ-значение, а также сложные структуры данных, может выполнять операции с любым из элементов вложенных массивов, хешей не доставая все содержимое ключа. Кстати это учитывая накладные расходы на сериализацию/десериализацию объектов хранимых в мемкашеде может быть просто огромным плюсом в производительности (особенно учитывая скорость десериализации в PHP). Думаю я еще изучу и протестирую этот момент отдельно и выложу результаты.

Кроме всего вышеперечисленного Редис поддерживает репликацию мастер-клиент. Клиент в свою очередь тоже может выступать мастер сервером для других клиентов — это позволяет организовывать своего рода деревья из серверов Редиса. К сожалению реплецирования мастер-мастер на данный момент не поддерживается, но уже сейчас в разработке решение Redis Cluster.

Редис так-же поддерживает атомарные операции, транзакции. Умеет работать с массивами, сортировать их, ограничивать выборки (аналог LIMIT в SQL) и многое другое.

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

Сфера использования:

  • Может как и Memcached использоваться для кеширования данных(кстати регулярный дамп на жесткий диск можно и отключить при желании)
  • Идеально подходит для реализации разного рода счетчиков, чатов и других подобных задач.
  • В случае если Вам хватает предоставленного функционала — может выступать в качестве основной БД. В таком случае пропадает надобность в лишнем слое логики — кешировании, а в месте с ним пропадает огромный класс проблем в разработке. Вам больше не нужно будет при каждом обновлении данных сбрасывать нужные кеши, отлавливать ошибки связанные с тем что где-то Вы это забыли сделать. Все это будет брать на себя Редис. Просто работайте с базой данной и не о чем таком можете даже не думать. При этом скорость работы по многим тестам (тест, тест2) даже превосходит Memcached. Это отличная идея для высоко нагруженных проектов и я собираюсь некоторые из своих будущих проектов делать исключительно на Redis, а в уже существующие внедряю его там где он даст ощутимый прирост в производительности. Когда же появится достаточно производительная библиотека для PHP то думаю можно будет полностью отказаться от memcached в сторону Redis.

Теперь о недостатках решения:

  • Вам нужно столько оперативной памяти — сколько у Вас есть данных в БД. И с ростом БД будет пропорционально расти и потребление ОЗУ. Конечно, в версии 2 появилась такая вещь как встроенная «виртуальная память» но при её использовании весь смысл Редиса теряется. Так-как скорость работы резко падает.
  • По большинству тестов сам по себе Redis обходит Memcached в производительности. Но проведя небольшой тест я получил другие результаты. Видимо конкретная реализация клиентской библиотеки под PHP в силу того что она достаточно новая, является пока не слишком производительной. В итоге при использовании с PHP, Redis оказывается в проигрыше по производительности. Но даже в таком варианте он не слишком отстает от Memcached. И думаю эта проблема решится в следующих версиях модуля для PHP.
  • При настройках по умолчанию, данные сбрасываются на диск раз в какое-то время/количество запросов. В таком режиме например если у сервера пропадет питание, Вы можете потерять самые свежие данные. Есть возможность настроить другой режим работы, при котором каждая запись в БД сопровождается записью на жесткий диск, но тогда мы снова теряем производительность и смысл использования Редиса. Однако, есть команда которая частично решает эту проблему, она немедленно инициирует новый дамп на жесткий диск. Её к примеру можно использовать после записи только критических данных.

Надеюсь Вы получили представление о том что такое Редис?
Более подробно о конкретном внедрении, синтаксисе, настройке я расскажу в последующих статьях.

Posted in High load | Tagged , , | Leave a comment

Тест скорости Memcached VS Redis

FreeBSD, Core2Duo 3Ghz. Сервер под небольшой нагрузкой, мемкаш используется (и в нем куча данных) так-что у редиса должна быть фора…

PHP 5.3.3

Библиотеки:

phpredis, memcache

100 000 случайных записей

Memcached 100 000 random sets: 4.5468878746033

Redis 100 000 random sets: 6.2901890277863

100 000 чтений одного ключа

Memcached 100 000 gets: 4.1142840385437

Redis 100 000 gets: 5.2948369979858

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

Этот тест меня еще раз убедил в том что — доверяй но проверяй :)

Сам тест, наваял буквально за несколько минут:

$memcache_obj = memcache_connect('localhost', 11211);
$redis = new Redis();
$redis->connect('localhost',6379);

function set_memcache($k,$v)
{
    global $memcache_obj;
    memcache_set($memcache_obj,$k,$v,0,10);
}
function get_memcache($k)
{
    global $memcache_obj;
    memcache_get($memcache_obj,$k);
}
function set_redis($k,$v)
{
    global $redis;
    $redis->set($k, $v);
}
function get_redis($k)
{
    global $redis;
    $redis->get($k);
}


$before=microtime(true);
for ($i = 1; $i <= 100000; $i++) {
    set_memcache(md5(rand()),md5(rand()));
}
print 'Memcached 100 000 random sets: '.(microtime(true)-$before)."\n";

$before2=microtime(true);
for ($i = 1; $i <= 100000; $i++) {
    set_redis(md5(rand()),md5(rand()));
}
print 'Redis 100 000 random sets: '.(microtime(true)-$before2)."\n";

$key=md5(rand());


$before3=microtime(true);
set_memcache($key,md5(rand()));
for ($i = 1; $i <= 100000; $i++) {
    get_memcache($key);
}
print 'Memcached 100 000 gets: '.(microtime(true)-$before3)."\n";

$before4=microtime(true);

set_redis($key,md5(rand()));
for ($i = 1; $i <= 100000; $i++) {
    get_redis($key);
}
print 'Redis 100 000 gets: '.(microtime(true)-$before4)."\n";

Update спустя пару часов:
Нашел аналогичные моим результаты, только там еще больше клиентов участвуют.

http://www.ezwebsitemonitoring.com/blog/php-benchmark-memcached-with-pecl-memcache-php-memcached-redis-with-predis-rediska

Posted in High load | Tagged , | 3 Comments

Redis быстрей чем memcached?

В последнее время о редисе очень много говорят, но я как-то обходил его своим вниманием. Сегодня мне скинули ссылку на результаты тестов сравнения производительности Redis с Memcached и я был мягко говоря удивлен тем что он его обходит! Это при том что Redis персистентное хранилище — то есть он хранит данные так-же и на диске и например при ребуте сервера не теряет.

Очень заинтересовался, уже установил на сервер. Попробую для теста перевести рейтинг сайтов на arts.in.ua с memcached на Redis. Тем более что это сильно упростит логику — сейчас данные счетчика сидят в мемкашеде и время от времени скидывается в MySQL.

Еще возникает вопрос какую из 4х Redis библиотек для PHP выбрать…

О результатах тестирования и внедрения напишу позже.

Ссылки на эти тесты:

http://www.ruturaj.net/redis-memcached-tokyo-tyrant-mysql-comparison

http://antirez.com/post/redis-memcached-benchmark.html

Posted in High load | Tagged | 2 Comments