Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 123
Можно поподробнее по поводу:
«В конце концов мы решили использовать png24 с полупрозрачными краями накладывающиеся друг на друга»
«В конце концов мы решили использовать png24 с полупрозрачными краями накладывающиеся друг на друга»
В Цив3 используются иконки с ровными краями которые должны пиксель в пиксель стыковаться друг с другом чтобы сложилась картинка. Мы же решили сделать иконки больше чем нужно для отрисовки и накладывать друг на друга. На концах каждой иконки размытость делаем, что позволяет плавно перетекать из одного типа территории в другой.
Я решил перехитрить <… > В итоге пришлось написать дурацкую логику <… > Вернул все назад
Люди никогда не учатся на чужих ошибках, пока не изобретут свой велосипед :)
Но вообще спасибо за статью, интересно
Играю с удовольствием, спасибо за работу:)
А pathfinding юнита делается на клиенте или на сервере? И с чем связано ограничение на максимальный путь (сообщение «Слишком далеко») — это техническое или чисто игровое? Учитываются ли проложенные дороги при расчете пути?
Как обеспечиваете равномерность распределения ресурсов на карте?
В правом нижнем углу есть прогресс-бар/кнопка с текущим исследованием. Почините у нее тултип:)
А pathfinding юнита делается на клиенте или на сервере? И с чем связано ограничение на максимальный путь (сообщение «Слишком далеко») — это техническое или чисто игровое? Учитываются ли проложенные дороги при расчете пути?
Как обеспечиваете равномерность распределения ресурсов на карте?
В правом нижнем углу есть прогресс-бар/кнопка с текущим исследованием. Почините у нее тултип:)
pathfinding на сервере. И достаточно тупо — дороги и местность не учитываются. Есть в планах сделать поиск кратчайшего пути.
ограничение на длину пути — техническое, взял из головы, чтобы не напрягать сервер. Если кто-то введет расстояние в 500 клеток серверу придется напрячься, чтобы высчитать путь. Достать клетки из БД по типу территории рассчитать скорость перемещения. Там еще ресурсы охотники собирают с леса — это высчитывается. В общем много работы достаточно.
«Как обеспечиваете равномерность распределения ресурсов на карте?»
Одинаковое количество в каждом регионе 10 на 10 клеток. А внутри региона случайное положение.
Про тултип есть баг! Починим). Спасибо.
ограничение на длину пути — техническое, взял из головы, чтобы не напрягать сервер. Если кто-то введет расстояние в 500 клеток серверу придется напрячься, чтобы высчитать путь. Достать клетки из БД по типу территории рассчитать скорость перемещения. Там еще ресурсы охотники собирают с леса — это высчитывается. В общем много работы достаточно.
«Как обеспечиваете равномерность распределения ресурсов на карте?»
Одинаковое количество в каждом регионе 10 на 10 клеток. А внутри региона случайное положение.
Про тултип есть баг! Починим). Спасибо.
Сколько у вас ушло времени на разработку, планируете ли монетизацию игры?
Монетизацию планируем — но руки пока не дошли что-то сделать по этому поводу.
Ушло полтора года по вечерам. Если бы наладить монетизацию пошло бы быстрее =) А пока как можем делаем… времени конечно не хватает очень…
Ушло полтора года по вечерам. Если бы наладить монетизацию пошло бы быстрее =) А пока как можем делаем… времени конечно не хватает очень…
Игра получилась играбительной в духе цивилизации. И на первый взгляд все сделано вполне качественно, удачи вам в развитии.
Наверняка у вас в планах уже это есть, но все же предложу. Рейтинг игроков, по нескольким критериям, и возможность по достижению определённого уровня очков выйты из игры, оставшись в рейтингах.
Интересует вот какой момент, как будет решаться вопрос разницы игроков по времени жизни, у кого-то будут танки, а кто-то только открыл огонь? (Детально в игровую механику еще не вдавался, возможно вы этот вопрос уже сняли)
Наверняка у вас в планах уже это есть, но все же предложу. Рейтинг игроков, по нескольким критериям, и возможность по достижению определённого уровня очков выйты из игры, оставшись в рейтингах.
Интересует вот какой момент, как будет решаться вопрос разницы игроков по времени жизни, у кого-то будут танки, а кто-то только открыл огонь? (Детально в игровую механику еще не вдавался, возможно вы этот вопрос уже сняли)
Спасибо!
Так рейтинг есть же по 3-ем категориям. Надеюсь вы не про демонстрационную версию говорите?)
Скорость исследования технологий со временем будет удешевляться. Новые игроки смогут намного быстрее пройти первые этапы. + после определенного периода регистрация будет закрыта конечно. Нет смысла охотникам воевать с танками =) + новые игроки будут расположены вдали от развитых.
Так рейтинг есть же по 3-ем категориям. Надеюсь вы не про демонстрационную версию говорите?)
Скорость исследования технологий со временем будет удешевляться. Новые игроки смогут намного быстрее пройти первые этапы. + после определенного периода регистрация будет закрыта конечно. Нет смысла охотникам воевать с танками =) + новые игроки будут расположены вдали от развитых.
А сколько человек в команде?
Не работает кнопка «Enter the game» Opera 11.1 MacOS
Хотелось бы отметить — очень красивый и качественный дизайн. Молодцы. Полтора года для подобного проекта — не такой уж большой срок (учитывая, что работали не полный день и бесплатно). Удачи вам, продолжайте.
Я тут с вашего позволения влезу со своим имхо касательно производительности. Мне кажется, если карта у вас загружается регионами — было бы интереснее хранить ее в redis, по регионам, в запакованном виде. Для redis 10 000 записей вообще не проблема, и скорость выборки однозначно будет выше чем из mysql. Что касается permissions, я бы на вашем месте тоже хранил это в redis, но, со взглядом на будущее, сделал бы шардинг по player_id. Единственная проблема — придется вручную делать «Join», но mget вам поможет)
Спасибо — учту.
Абсолютно согласен, говорю как разработчик браузерной стратегии. ))
и скорость выборки однозначно будет выше чем из mysql
Даже при использовании handler socket?
Спорный вопрос. Я не уверен на 100%, но по-моему при изменении таблицы и последующем к ней запросе mysql все равно будет дергать диск, а redis живет в памяти и сброс данных на диск происходит с меньшим приоритетом чем собственно работа с базой. Плюс, насколько я помню (про HS читал отрывочно, могу врать) HS не умеет JOINы. А redis, хоть и не умеет, может очень быстро отдавать данные по списку ключей, а сгенерить на php такой список — копейки по сравнению с основными вычислениями. На HS тоже можно сделать такой ручной JOIN, но не уверен, что запрос с IN сравнится с redis MGET.
В общем, резюмируя, надо тестировать. Я лично не использую HS, поскольку лично наблюдал последние два месяца, как мои коллеги еженедельно натыкались на новые грабли, пытаясь заставить его работать в нашем окружении. При этом с redis проблем не было ни разу, поэтому я его и советую)
В общем, резюмируя, надо тестировать. Я лично не использую HS, поскольку лично наблюдал последние два месяца, как мои коллеги еженедельно натыкались на новые грабли, пытаясь заставить его работать в нашем окружении. При этом с redis проблем не было ни разу, поэтому я его и советую)
1) редис живет пока данные вмещаются в оперативную память (версию 2 не капал) — нужно много памяти или шардинг редисов
2) производительность редиса и HS соизмерима
3) HS так же не умеет делать JOIN
2) производительность редиса и HS соизмерима
3) HS так же не умеет делать JOIN
Редис имеет несколько вариантов хранения — все в памяти, в памяти только ключи, данные на диске, комбинированный вариант.
Плюс в том, что редис масштабировать намного проще чем мускул, плюс даються очень вкусные штуки вроде Pub/Sub
Плюс в том, что редис масштабировать намного проще чем мускул, плюс даються очень вкусные штуки вроде Pub/Sub
это наверно начиная с версии 2.0?
я копался с редисом два года назад, был более ограниченный функционал
делал на нем оперативное хранение справочников
я копался с редисом два года назад, был более ограниченный функционал
делал на нем оперативное хранение справочников
>Плюс в том, что редис масштабировать намного проще чем мускул
про какое масштабирование идет речь?
про какое масштабирование идет речь?
многоуровневые схемы мастер-слейв, репликация и т.п.
вертикальное масштабирование поддерживается в мускуле в табл типа FEDERATED
вот промышленные варианты масштабирования
www.hscale.org/display/HSCALE/Home
spockproxy.sourceforge.net/
можно организовать шардинг (горизонтальное масштабирование) самому, это будет на 1 табл больше + транзакции на запись.
в этом нет ничего сложного, стоит только гууглянуть
вот промышленные варианты масштабирования
www.hscale.org/display/HSCALE/Home
spockproxy.sourceforge.net/
можно организовать шардинг (горизонтальное масштабирование) самому, это будет на 1 табл больше + транзакции на запись.
в этом нет ничего сложного, стоит только гууглянуть
А я все таки надеялся что сервер выдержит)
Про наложение ромбиков была бы отличная отдельная статья.
Касательно карты, необязательно хранить 1 млн записей.
Как уже писали
а) редис
б) хранить записи только о тех, что не являются океаном (скажем так нулевые записи)
в) о ресурсах хранить записи отдельно (у них еще больше «пустых» полей будет, так что еще меньше записей)
г) я бы делал на питоне с архитектурой внутри программы, если интересует уже есть готовая рабочая платформа с подключенным redis на gevent. Очень шустро работает. Можем сотрудничать.
д) касательно хостеров, пусть реверсы проверят и spf записи сделают, если желаете готовы и в этом плане сотрудничать :).
Как уже писали
а) редис
б) хранить записи только о тех, что не являются океаном (скажем так нулевые записи)
в) о ресурсах хранить записи отдельно (у них еще больше «пустых» полей будет, так что еще меньше записей)
г) я бы делал на питоне с архитектурой внутри программы, если интересует уже есть готовая рабочая платформа с подключенным redis на gevent. Очень шустро работает. Можем сотрудничать.
д) касательно хостеров, пусть реверсы проверят и spf записи сделают, если желаете готовы и в этом плане сотрудничать :).
Все сайт лег чо ли?
Прочитав то, как Цукерберг хранит картинки и юзерпики в Фейсбуке я начинаю думать, что с хранением информации о клетках Вы намельчили. Представьте, что будет если сто строк, описывающих сто клеток региона, хранить в одной строке.
По-моему, лучше дёргать из сервера сразу целый регион, а потом уже в памяти выдёргивать из этой строчки нужные данные, чем заставлять сервер мельтешить ради всех этих отдельных клеток.
Конечно, зависит ещё от взаимного расположения сервера и базы данных — если они на разных машинах, то пропускная способность сети может стать узким местом.
По-моему, лучше дёргать из сервера сразу целый регион, а потом уже в памяти выдёргивать из этой строчки нужные данные, чем заставлять сервер мельтешить ради всех этих отдельных клеток.
Конечно, зависит ещё от взаимного расположения сервера и базы данных — если они на разных машинах, то пропускная способность сети может стать узким местом.
Неплохая идея, но записи модифицируются — построил дорогу — нужно это занести в запись. Если их объединить, то нужно будет выбирать вместо отдельных клеток регионы. При перемещении тоже нужны клетки отдельные.
Но попробовать стоит конечно такой вариант.
Но попробовать стоит конечно такой вариант.
Подскажите, пожалуйста, где можно прочесть о том, как в Фейсбуке организовано хранение картинок и юзерпиков?
присоединяюсь к вопросу
mukulblog.blogspot.com/2008/06/facebook-photo-storage-architecture.html
highscalability.com/blog/2009/7/2/product-facebooks-cassandra-a-massive-distributed-store.html
ну и далее в гугл, была статья в блоге фейсбук инжиниринг
highscalability.com/blog/2009/7/2/product-facebooks-cassandra-a-massive-distributed-store.html
ну и далее в гугл, была статья в блоге фейсбук инжиниринг
www.insight-it.ru/masshtabiruemost/arkhitektura-facebook/
не стоит забывать, что Фейсбук — большой проект и многие решения могут не подойти
что могу посоветовать (общие рекомендации):
— для картинок используй легкий WEB сервер, на Хабре была статья про image-server (надо собирать самому)
я могу посоветовать 0-httpd 0w.ru/httpd/ ну или varnish
— все картинки групируем в поддиректории, не более 1024 картинки в директории
не стоит забывать, что Фейсбук — большой проект и многие решения могут не подойти
что могу посоветовать (общие рекомендации):
— для картинок используй легкий WEB сервер, на Хабре была статья про image-server (надо собирать самому)
я могу посоветовать 0-httpd 0w.ru/httpd/ ну или varnish
— все картинки групируем в поддиректории, не более 1024 картинки в директории
mukulblog.blogspot.com/2008/06/facebook-photo-storage-architecture.html
highscalability.com/blog/2009/7/2/product-facebooks-cassandra-a-massive-distributed-store.html
спасибо aleks_raiden за ссылки :-)
highscalability.com/blog/2009/7/2/product-facebooks-cassandra-a-massive-distributed-store.html
спасибо aleks_raiden за ссылки :-)
сайт не отвечает.
Я понимаю, что не хотите мельчить, но прошу следующую статью поподробней про клиентскую часть (особенно про canvas). Очень интересно.
Могу предложить ряд оптимизаций:
1) карту хранить в файле, при старте сервиса бэкэнда — карту грузить в память.
2) апдейты по карте тоже хранить в памяти, при необходимости сбрасывать периодически в файл, для восстановления в случае падения.
И хотелось бы очень увидеть продолжение, очень интересно посмотреть на реализацию фронт энда :)
Попутно вопрос? тестировалось ли на мобильных браузерах? (не могу проверить изза нагрузки сайта)
1) карту хранить в файле, при старте сервиса бэкэнда — карту грузить в память.
2) апдейты по карте тоже хранить в памяти, при необходимости сбрасывать периодически в файл, для восстановления в случае падения.
И хотелось бы очень увидеть продолжение, очень интересно посмотреть на реализацию фронт энда :)
Попутно вопрос? тестировалось ли на мобильных браузерах? (не могу проверить изза нагрузки сайта)
Нет не тестировалось. Минимальное разрешения для нормальной работы 1280 800, а лучше больше.
Для мобильных устройств с низким разрешением нужно менять интерфейс.
Для мобильных устройств с низким разрешением нужно менять интерфейс.
А как показывать пользователю только часть карты?
Зависит от реализации, но абстрактно можно сделать так:
1) карта хранится в виде 2х мерного массива:
1,2,3,1,2,3
2,1,3,4,2,3
2,1,2,3,4,2
, где 1-4 — тип клетки карты.
2) Тогда можно легко реализовать скрытие от игрока не открытой части карты в виде маски на такую карту, т.е:
1,1,1,1,1,1
1,1,0,0,1,1
1,0,0,0,0,1
, где 1 — скрытая клетка карты, 0 — открытая.
И тогда не сложно написать алгоритм выдачи пользователю текущего куска карты (карта накладыватся с маской и выдаётся результат). Работать будет очень быстро, т.к. мы жертвуем памятью в сторону производительности.
1) карта хранится в виде 2х мерного массива:
1,2,3,1,2,3
2,1,3,4,2,3
2,1,2,3,4,2
, где 1-4 — тип клетки карты.
2) Тогда можно легко реализовать скрытие от игрока не открытой части карты в виде маски на такую карту, т.е:
1,1,1,1,1,1
1,1,0,0,1,1
1,0,0,0,0,1
, где 1 — скрытая клетка карты, 0 — открытая.
И тогда не сложно написать алгоритм выдачи пользователю текущего куска карты (карта накладыватся с маской и выдаётся результат). Работать будет очень быстро, т.к. мы жертвуем памятью в сторону производительности.
Маска легко убирается ;)
Или вы предлагаете накладывать маску на стороне сервера?
Я так понял он про сервер все это говорит. А на клиент понятно что всю карту не нужно грузить =)
Конечно, и карта и маска всё на стороне сервера. Клиенту выдаём только часть карты с маской.
И кстати сериализация и десериализация маски в файл работать должна очень быстро (это в случае если всё-таки у нас есть серьёзные ограничения по памяти).
И кстати сериализация и десериализация маски в файл работать должна очень быстро (это в случае если всё-таки у нас есть серьёзные ограничения по памяти).
карту хранить не в файле а в любом из noSQL
в качестве хранилища могу посоветовать TokyoTyran — производительность чуть медленнее мемкеша, соизмерим с редисом, все данные периодисчески сбрасывает на диск (практически без потерь), на диске занимает меньше места чем memcacheDb, работает быстрее memcacheDb, протокол memcache.
поддерживает mget/mset
в качестве хранилища могу посоветовать TokyoTyran — производительность чуть медленнее мемкеша, соизмерим с редисом, все данные периодисчески сбрасывает на диск (практически без потерь), на диске занимает меньше места чем memcacheDb, работает быстрее memcacheDb, протокол memcache.
поддерживает mget/mset
Про игру ничего сказать не могу, похоже сайт накрыло, но скрины очень симпотичные.
Планируете ли какое-то публичное API?
Планируете ли какое-то публичное API?
Есть ли в планах адоптация интерфейса под мобильные устройства? Думаю многие почитатели захотят также играть например и в дороге ( в метро например ). А т.к. сделанно без участия флеша то мне кажется что вполне реально адаптировать под айфон и андроиды.
Вроде отпустило — можно смотреть.
Помимо Цивилизации чем-то напомнило браузерную стратегию decline, мир её праху.
Кому понравилась игра или топик прошу проголосовать за нас на конкурсе.
microsoft.promo.eprize.com/ie9app/gallery?id=210
Заранее спасибо!
microsoft.promo.eprize.com/ie9app/gallery?id=210
Заранее спасибо!
Картинка симпатичная, но что касается иконок кажется немного недобрали с метафорами в угоду реалистичности. Например что изображено на иконке глины я так и не понял, хлеб в уменьшенном виде тоже совершенно не распознаётся, зелёная шестерёнка (?) тоже. Всё такое меланхолично-осеннее.
Нужно чтоб кто-нибудь по английской версии прошёлся: сетка это grid, а не net; артикль в названии по-моему правильнее было бы поставить перед nation, а перед fate наоборот убрать: тут ж судьба нашей нации решается, а не какой-то там; building of crops > growing crops, ну и тому подобное.
А так, для начала круто, спасибо
Нужно чтоб кто-нибудь по английской версии прошёлся: сетка это grid, а не net; артикль в названии по-моему правильнее было бы поставить перед nation, а перед fate наоборот убрать: тут ж судьба нашей нации решается, а не какой-то там; building of crops > growing crops, ну и тому подобное.
А так, для начала круто, спасибо
Ух, спасибо, шикарно! Давно ждал нечто подобное, пожалуйста, только не бросайте писать, с удовольствием бы читал до самого конца и внутренностей создания проекта.
А карта технологий будет?
Как реализованы таймеры, на постройку и т.д.?
Как передаются данные игрокам, о том, что другой игрок подошел, дергается запрос по таймеру, кто в данной локации?
Как передаются данные игрокам, о том, что другой игрок подошел, дергается запрос по таймеру, кто в данной локации?
Английский в проекте убийственно безграмотен
New knowledge was revealed toour witch us: «Fire»
+1 culturea per day
Totalforce of defense (force of можно замиеть power of если очень хочется)
Will comein to 210:-117 in 3 minutes 13 seconds
...workers will be able to get food by moving through the forest.
New knowledge was revealed to
+1 culture
Total
Will come
...workers will be able to get food by moving through the forest.
Эти предложения склеиваются из разных частей — где-то переглючивает видимо. Спасибо за комментарии — буду исправлять!
Исправил сразу все. При первом апдейте залью на сервер.
Еще Total force of the attack заменил на Total offence.
Если вам не лень то сообщайте о подобном — буду признателен. Лучше в личку — тут можно пропустить.
Еще Total force of the attack заменил на Total offence.
Если вам не лень то сообщайте о подобном — буду признателен. Лучше в личку — тут можно пропустить.
В момент выбора постройки на сервере рассчитывается время из текущего производства города и сложности постройки. Затем в БД в запись города заносится что он строит и когда это строительство завершится. Клиент соответственно знает точное время когда нужно обновить инфу о городе.
Нет по таймеру ничего не обновляется. Обновляется только если игрок что-то делает: двигает карту или города просматривает — тогда дергаются запросы на обновление карты. Если игрок оставит карту в покое то он не увидит подхода войск. Пока так сделано — таймер поставить тоже можно. Но пока никто не жаловался.
Нет по таймеру ничего не обновляется. Обновляется только если игрок что-то делает: двигает карту или города просматривает — тогда дергаются запросы на обновление карты. Если игрок оставит карту в покое то он не увидит подхода войск. Пока так сделано — таймер поставить тоже можно. Но пока никто не жаловался.
Партиционирование для таблицы с картой не пробовали применить?
Интересно было бы почитать о том, как реализован обмен данными с сервером, какая технология и инструментарий применяется, какая логика и т.д. Сам сейчас занимаюсь разработкой простенькой браузерной игры, пока обмен данными идет AJAX'ом по таймеру, а серверная логика работает по крону.
Большое спасибо за статью, прочитал на одном дыхании. От самой игры под впечатлением. Успехов Вам в дальнейшей разработке.
Большое спасибо за статью, прочитал на одном дыхании. От самой игры под впечатлением. Успехов Вам в дальнейшей разработке.
Спасибо. Крон это не очень хорошая идея для пересчетов, если вы об этом. Напишу потом как-нибудь как у нас реализовано.
у нас было так:
1) висел бэдграундный процесс (процесс обработчик), который имел свой пид файл
2) процесс засыпал на 1-5 сек, потом начинал считывать очередь и ее обрабатывать
3) после отработки 1000 циклов процесс уничтожал пид-файл, и перезапускал сам себя в бэдграунде (на случай утечек и зависаний)
4) раз в минуту запускался этот же процесс по крону, если существовал пид-файл, то он завершался (как бы на случай страховки)
все работает без сбоев уже второй год
1) висел бэдграундный процесс (процесс обработчик), который имел свой пид файл
2) процесс засыпал на 1-5 сек, потом начинал считывать очередь и ее обрабатывать
3) после отработки 1000 циклов процесс уничтожал пид-файл, и перезапускал сам себя в бэдграунде (на случай утечек и зависаний)
4) раз в минуту запускался этот же процесс по крону, если существовал пид-файл, то он завершался (как бы на случай страховки)
все работает без сбоев уже второй год
Наверное правильно писать The Fate of a Nation, нет?
в общем спасибо за игру,
предложения по архитектуре ищи в комментариях,
предложения по архитектуре ищи в комментариях,
Пропишите пожалуйста alt для статусбара исследований.
А сколько по времени создавалась игра?
Восстановление пароля не работает, к сожалению.
1) Сколько народу всего работает над проектом и в каких «должностях»?
2) Какова конфигурация железа (сколько серверов, параметры)?
3) 10к человек — это максимальный онлайн или максимум зарегистрированных игроков всего?
2) Какова конфигурация железа (сколько серверов, параметры)?
3) 10к человек — это максимальный онлайн или максимум зарегистрированных игроков всего?
1) работает 1 программист (я) и 1 дизайнер/художник
2) недавно взяли 4-ядерный Xeon с 4Гб оперативки
3) я немного слукавил про 10 000 =) На самом деле сейчас помещается 2500 игроков. Так как по просьбе геймеров я разнес стартовые позиции по дальше друг от друга. Ограничение это физическое — на карту больше не поместится. Нужно другую карту(мир, сервер) делать что следующие 2500 играли.
2) недавно взяли 4-ядерный Xeon с 4Гб оперативки
3) я немного слукавил про 10 000 =) На самом деле сейчас помещается 2500 игроков. Так как по просьбе геймеров я разнес стартовые позиции по дальше друг от друга. Ограничение это физическое — на карту больше не поместится. Нужно другую карту(мир, сервер) делать что следующие 2500 играли.
Хочется более логичного «поиска пути». Пример
Р — равнина, Г — горы Л — лес. В X стоит рабочий, которому нужно придти в 0
РРРХР
РРГРР
РГРРР
0РРРР
Выбирается логичный, но самый длинный, путь через клетки с горами >4 минут на шаг, вместо двух по равнине.
Р — равнина, Г — горы Л — лес. В X стоит рабочий, которому нужно придти в 0
РРРХР
РРГРР
РГРРР
0РРРР
Выбирается логичный, но самый длинный, путь через клетки с горами >4 минут на шаг, вместо двух по равнине.
Сегодня впервые узнал о вашем проекте. Сам занимаюсь разработкой игрушек (правда во флэше), очень понравились некоторые моменты вашей бизнес логики, ну а графика, конечно — выше всяких похвал, молоды. Очень жду продолжения статьи, очень хочется узнать как все это работает на более низком уровне (какие протоколы используете, еще языки программирования какие, фрэймворки...).
Интересная статья!
Однако, интересно узнать про механику игры — ведь взятая за основу Цивилизация все-таки пошаговая стратегия, а реализация автора — реал тайм насколько я понимаю?
Т.е. игроки ходят не последовательно друг за другом?
И пока у меня не открыто окно браузера с игрой у меня не исследуются технологии?
А что происходит, когда на меня нападает противник, а я в оффлайне?
Что касается технической реализации — на мой взгляд разумней было бы использовать на серверной стороне NodeJS + Redis.
Во-первых — высокая скорость работы.
Во-вторых — и там и там js, это дает замечательные возможности, можно писать общий код, двигать участки кода между клиентом и сервером.
Однако, интересно узнать про механику игры — ведь взятая за основу Цивилизация все-таки пошаговая стратегия, а реализация автора — реал тайм насколько я понимаю?
Т.е. игроки ходят не последовательно друг за другом?
И пока у меня не открыто окно браузера с игрой у меня не исследуются технологии?
А что происходит, когда на меня нападает противник, а я в оффлайне?
Что касается технической реализации — на мой взгляд разумней было бы использовать на серверной стороне NodeJS + Redis.
Во-первых — высокая скорость работы.
Во-вторых — и там и там js, это дает замечательные возможности, можно писать общий код, двигать участки кода между клиентом и сервером.
Да, реал-тайм, не последовательно, а параллельно.
Конечно исследуются и при закрытом окне — этот процесс на сервере просчитывается.
Если вы в офлайне это ваши проблемы =) Но у нас есть в планах множество идей как скрасить эту проблему. Например дадим возможность на 10 часов в сутки залочить игру — при этом на вас не смогут нападать.
Да было бы круто наверное использовать NodeJs и Redis — но сделали по другому — возможно со временем переделаем.
Конечно исследуются и при закрытом окне — этот процесс на сервере просчитывается.
Если вы в офлайне это ваши проблемы =) Но у нас есть в планах множество идей как скрасить эту проблему. Например дадим возможность на 10 часов в сутки залочить игру — при этом на вас не смогут нападать.
Да было бы круто наверное использовать NodeJs и Redis — но сделали по другому — возможно со временем переделаем.
Про регионы вопрос.
Тот факт, что клиент запрашивает регионы по 10*10 клеток, означает что информация хранится на клиенте и таким образом, анализируя ответы сервера мои юниты могут «видеть» эту территорию?
Тот факт, что клиент запрашивает регионы по 10*10 клеток, означает что информация хранится на клиенте и таким образом, анализируя ответы сервера мои юниты могут «видеть» эту территорию?
Спасибо за игру. В результате пары дней тестирования возникла пара мыслей/советов:
Ну ооочень тормозит статика. Может, стоит попробовать использовать HTML5-манифест для хранения статики на клиенте?
Решение ограничить размер карты кажется неправильным: думаю, что лучше сделать карту во всё окно, как в оригинальной игре.
Ну ооочень тормозит статика. Может, стоит попробовать использовать HTML5-манифест для хранения статики на клиенте?
Решение ограничить размер карты кажется неправильным: думаю, что лучше сделать карту во всё окно, как в оригинальной игре.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка браузерной стратегии