Comments 123
Можно поподробнее по поводу:
«В конце концов мы решили использовать png24 с полупрозрачными краями накладывающиеся друг на друга»
«В конце концов мы решили использовать png24 с полупрозрачными краями накладывающиеся друг на друга»
0
В Цив3 используются иконки с ровными краями которые должны пиксель в пиксель стыковаться друг с другом чтобы сложилась картинка. Мы же решили сделать иконки больше чем нужно для отрисовки и накладывать друг на друга. На концах каждой иконки размытость делаем, что позволяет плавно перетекать из одного типа территории в другой.
+6
UFO just landed and posted this here
Я решил перехитрить <… > В итоге пришлось написать дурацкую логику <… > Вернул все назад
Люди никогда не учатся на чужих ошибках, пока не изобретут свой велосипед :)
Но вообще спасибо за статью, интересно
+1
Играю с удовольствием, спасибо за работу:)
А pathfinding юнита делается на клиенте или на сервере? И с чем связано ограничение на максимальный путь (сообщение «Слишком далеко») — это техническое или чисто игровое? Учитываются ли проложенные дороги при расчете пути?
Как обеспечиваете равномерность распределения ресурсов на карте?
В правом нижнем углу есть прогресс-бар/кнопка с текущим исследованием. Почините у нее тултип:)
А pathfinding юнита делается на клиенте или на сервере? И с чем связано ограничение на максимальный путь (сообщение «Слишком далеко») — это техническое или чисто игровое? Учитываются ли проложенные дороги при расчете пути?
Как обеспечиваете равномерность распределения ресурсов на карте?
В правом нижнем углу есть прогресс-бар/кнопка с текущим исследованием. Почините у нее тултип:)
0
pathfinding на сервере. И достаточно тупо — дороги и местность не учитываются. Есть в планах сделать поиск кратчайшего пути.
ограничение на длину пути — техническое, взял из головы, чтобы не напрягать сервер. Если кто-то введет расстояние в 500 клеток серверу придется напрячься, чтобы высчитать путь. Достать клетки из БД по типу территории рассчитать скорость перемещения. Там еще ресурсы охотники собирают с леса — это высчитывается. В общем много работы достаточно.
«Как обеспечиваете равномерность распределения ресурсов на карте?»
Одинаковое количество в каждом регионе 10 на 10 клеток. А внутри региона случайное положение.
Про тултип есть баг! Починим). Спасибо.
ограничение на длину пути — техническое, взял из головы, чтобы не напрягать сервер. Если кто-то введет расстояние в 500 клеток серверу придется напрячься, чтобы высчитать путь. Достать клетки из БД по типу территории рассчитать скорость перемещения. Там еще ресурсы охотники собирают с леса — это высчитывается. В общем много работы достаточно.
«Как обеспечиваете равномерность распределения ресурсов на карте?»
Одинаковое количество в каждом регионе 10 на 10 клеток. А внутри региона случайное положение.
Про тултип есть баг! Починим). Спасибо.
0
Сколько у вас ушло времени на разработку, планируете ли монетизацию игры?
+2
Монетизацию планируем — но руки пока не дошли что-то сделать по этому поводу.
Ушло полтора года по вечерам. Если бы наладить монетизацию пошло бы быстрее =) А пока как можем делаем… времени конечно не хватает очень…
Ушло полтора года по вечерам. Если бы наладить монетизацию пошло бы быстрее =) А пока как можем делаем… времени конечно не хватает очень…
+2
Игра получилась играбительной в духе цивилизации. И на первый взгляд все сделано вполне качественно, удачи вам в развитии.
Наверняка у вас в планах уже это есть, но все же предложу. Рейтинг игроков, по нескольким критериям, и возможность по достижению определённого уровня очков выйты из игры, оставшись в рейтингах.
Интересует вот какой момент, как будет решаться вопрос разницы игроков по времени жизни, у кого-то будут танки, а кто-то только открыл огонь? (Детально в игровую механику еще не вдавался, возможно вы этот вопрос уже сняли)
Наверняка у вас в планах уже это есть, но все же предложу. Рейтинг игроков, по нескольким критериям, и возможность по достижению определённого уровня очков выйты из игры, оставшись в рейтингах.
Интересует вот какой момент, как будет решаться вопрос разницы игроков по времени жизни, у кого-то будут танки, а кто-то только открыл огонь? (Детально в игровую механику еще не вдавался, возможно вы этот вопрос уже сняли)
0
Спасибо!
Так рейтинг есть же по 3-ем категориям. Надеюсь вы не про демонстрационную версию говорите?)
Скорость исследования технологий со временем будет удешевляться. Новые игроки смогут намного быстрее пройти первые этапы. + после определенного периода регистрация будет закрыта конечно. Нет смысла охотникам воевать с танками =) + новые игроки будут расположены вдали от развитых.
Так рейтинг есть же по 3-ем категориям. Надеюсь вы не про демонстрационную версию говорите?)
Скорость исследования технологий со временем будет удешевляться. Новые игроки смогут намного быстрее пройти первые этапы. + после определенного периода регистрация будет закрыта конечно. Нет смысла охотникам воевать с танками =) + новые игроки будут расположены вдали от развитых.
0
А сколько человек в команде?
0
Не работает кнопка «Enter the game» Opera 11.1 MacOS
0
Хотелось бы отметить — очень красивый и качественный дизайн. Молодцы. Полтора года для подобного проекта — не такой уж большой срок (учитывая, что работали не полный день и бесплатно). Удачи вам, продолжайте.
+5
Я тут с вашего позволения влезу со своим имхо касательно производительности. Мне кажется, если карта у вас загружается регионами — было бы интереснее хранить ее в redis, по регионам, в запакованном виде. Для redis 10 000 записей вообще не проблема, и скорость выборки однозначно будет выше чем из mysql. Что касается permissions, я бы на вашем месте тоже хранил это в redis, но, со взглядом на будущее, сделал бы шардинг по player_id. Единственная проблема — придется вручную делать «Join», но mget вам поможет)
0
Спасибо — учту.
+2
Абсолютно согласен, говорю как разработчик браузерной стратегии. ))
0
и скорость выборки однозначно будет выше чем из mysql
Даже при использовании handler socket?
0
Спорный вопрос. Я не уверен на 100%, но по-моему при изменении таблицы и последующем к ней запросе mysql все равно будет дергать диск, а redis живет в памяти и сброс данных на диск происходит с меньшим приоритетом чем собственно работа с базой. Плюс, насколько я помню (про HS читал отрывочно, могу врать) HS не умеет JOINы. А redis, хоть и не умеет, может очень быстро отдавать данные по списку ключей, а сгенерить на php такой список — копейки по сравнению с основными вычислениями. На HS тоже можно сделать такой ручной JOIN, но не уверен, что запрос с IN сравнится с redis MGET.
В общем, резюмируя, надо тестировать. Я лично не использую HS, поскольку лично наблюдал последние два месяца, как мои коллеги еженедельно натыкались на новые грабли, пытаясь заставить его работать в нашем окружении. При этом с redis проблем не было ни разу, поэтому я его и советую)
В общем, резюмируя, надо тестировать. Я лично не использую HS, поскольку лично наблюдал последние два месяца, как мои коллеги еженедельно натыкались на новые грабли, пытаясь заставить его работать в нашем окружении. При этом с redis проблем не было ни разу, поэтому я его и советую)
+1
1) редис живет пока данные вмещаются в оперативную память (версию 2 не капал) — нужно много памяти или шардинг редисов
2) производительность редиса и HS соизмерима
3) HS так же не умеет делать JOIN
2) производительность редиса и HS соизмерима
3) HS так же не умеет делать JOIN
0
Редис имеет несколько вариантов хранения — все в памяти, в памяти только ключи, данные на диске, комбинированный вариант.
Плюс в том, что редис масштабировать намного проще чем мускул, плюс даються очень вкусные штуки вроде Pub/Sub
Плюс в том, что редис масштабировать намного проще чем мускул, плюс даються очень вкусные штуки вроде Pub/Sub
0
это наверно начиная с версии 2.0?
я копался с редисом два года назад, был более ограниченный функционал
делал на нем оперативное хранение справочников
я копался с редисом два года назад, был более ограниченный функционал
делал на нем оперативное хранение справочников
0
>Плюс в том, что редис масштабировать намного проще чем мускул
про какое масштабирование идет речь?
про какое масштабирование идет речь?
0
многоуровневые схемы мастер-слейв, репликация и т.п.
0
вертикальное масштабирование поддерживается в мускуле в табл типа FEDERATED
вот промышленные варианты масштабирования
www.hscale.org/display/HSCALE/Home
spockproxy.sourceforge.net/
можно организовать шардинг (горизонтальное масштабирование) самому, это будет на 1 табл больше + транзакции на запись.
в этом нет ничего сложного, стоит только гууглянуть
вот промышленные варианты масштабирования
www.hscale.org/display/HSCALE/Home
spockproxy.sourceforge.net/
можно организовать шардинг (горизонтальное масштабирование) самому, это будет на 1 табл больше + транзакции на запись.
в этом нет ничего сложного, стоит только гууглянуть
0
то, чт можно я знаю :) я говорю что проще. редис отлично подходит для всяких реалтайм штук — общения например. и как распределенный кеш-быстрое хранилище важных частых данных. Обычно в результате оказывается, что во многих проектах достаточно одной базы для обслуживания приложения.
0
А я все таки надеялся что сервер выдержит)
+3
Про наложение ромбиков была бы отличная отдельная статья.
+1
Касательно карты, необязательно хранить 1 млн записей.
Как уже писали
а) редис
б) хранить записи только о тех, что не являются океаном (скажем так нулевые записи)
в) о ресурсах хранить записи отдельно (у них еще больше «пустых» полей будет, так что еще меньше записей)
г) я бы делал на питоне с архитектурой внутри программы, если интересует уже есть готовая рабочая платформа с подключенным redis на gevent. Очень шустро работает. Можем сотрудничать.
д) касательно хостеров, пусть реверсы проверят и spf записи сделают, если желаете готовы и в этом плане сотрудничать :).
Как уже писали
а) редис
б) хранить записи только о тех, что не являются океаном (скажем так нулевые записи)
в) о ресурсах хранить записи отдельно (у них еще больше «пустых» полей будет, так что еще меньше записей)
г) я бы делал на питоне с архитектурой внутри программы, если интересует уже есть готовая рабочая платформа с подключенным redis на gevent. Очень шустро работает. Можем сотрудничать.
д) касательно хостеров, пусть реверсы проверят и spf записи сделают, если желаете готовы и в этом плане сотрудничать :).
+1
Естественно, забыл добавить, игра очень понравилась :) так держать, но видно еще много недоделок, хотя даже такой она меня затянула на 30 минут :). Любитель цивилизации, даже купил полный пак civ4 (знаю что не лучшая, по мне лучшая 3я)
0
Все сайт лег чо ли?
0
Прочитав то, как Цукерберг хранит картинки и юзерпики в Фейсбуке я начинаю думать, что с хранением информации о клетках Вы намельчили. Представьте, что будет если сто строк, описывающих сто клеток региона, хранить в одной строке.
По-моему, лучше дёргать из сервера сразу целый регион, а потом уже в памяти выдёргивать из этой строчки нужные данные, чем заставлять сервер мельтешить ради всех этих отдельных клеток.
Конечно, зависит ещё от взаимного расположения сервера и базы данных — если они на разных машинах, то пропускная способность сети может стать узким местом.
По-моему, лучше дёргать из сервера сразу целый регион, а потом уже в памяти выдёргивать из этой строчки нужные данные, чем заставлять сервер мельтешить ради всех этих отдельных клеток.
Конечно, зависит ещё от взаимного расположения сервера и базы данных — если они на разных машинах, то пропускная способность сети может стать узким местом.
+2
Неплохая идея, но записи модифицируются — построил дорогу — нужно это занести в запись. Если их объединить, то нужно будет выбирать вместо отдельных клеток регионы. При перемещении тоже нужны клетки отдельные.
Но попробовать стоит конечно такой вариант.
Но попробовать стоит конечно такой вариант.
0
Подскажите, пожалуйста, где можно прочесть о том, как в Фейсбуке организовано хранение картинок и юзерпиков?
+3
присоединяюсь к вопросу
0
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
ну и далее в гугл, была статья в блоге фейсбук инжиниринг
0
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 картинки в директории
0
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 за ссылки :-)
0
сайт не отвечает.
0
Я понимаю, что не хотите мельчить, но прошу следующую статью поподробней про клиентскую часть (особенно про canvas). Очень интересно.
+3
Могу предложить ряд оптимизаций:
1) карту хранить в файле, при старте сервиса бэкэнда — карту грузить в память.
2) апдейты по карте тоже хранить в памяти, при необходимости сбрасывать периодически в файл, для восстановления в случае падения.
И хотелось бы очень увидеть продолжение, очень интересно посмотреть на реализацию фронт энда :)
Попутно вопрос? тестировалось ли на мобильных браузерах? (не могу проверить изза нагрузки сайта)
1) карту хранить в файле, при старте сервиса бэкэнда — карту грузить в память.
2) апдейты по карте тоже хранить в памяти, при необходимости сбрасывать периодически в файл, для восстановления в случае падения.
И хотелось бы очень увидеть продолжение, очень интересно посмотреть на реализацию фронт энда :)
Попутно вопрос? тестировалось ли на мобильных браузерах? (не могу проверить изза нагрузки сайта)
0
Нет не тестировалось. Минимальное разрешения для нормальной работы 1280 800, а лучше больше.
Для мобильных устройств с низким разрешением нужно менять интерфейс.
Для мобильных устройств с низким разрешением нужно менять интерфейс.
+1
А как показывать пользователю только часть карты?
+1
Зависит от реализации, но абстрактно можно сделать так:
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 — открытая.
И тогда не сложно написать алгоритм выдачи пользователю текущего куска карты (карта накладыватся с маской и выдаётся результат). Работать будет очень быстро, т.к. мы жертвуем памятью в сторону производительности.
0
Маска легко убирается ;)
+1
Или вы предлагаете накладывать маску на стороне сервера?
0
Я так понял он про сервер все это говорит. А на клиент понятно что всю карту не нужно грузить =)
0
Конечно, и карта и маска всё на стороне сервера. Клиенту выдаём только часть карты с маской.
И кстати сериализация и десериализация маски в файл работать должна очень быстро (это в случае если всё-таки у нас есть серьёзные ограничения по памяти).
И кстати сериализация и десериализация маски в файл работать должна очень быстро (это в случае если всё-таки у нас есть серьёзные ограничения по памяти).
0
карту хранить не в файле а в любом из noSQL
в качестве хранилища могу посоветовать TokyoTyran — производительность чуть медленнее мемкеша, соизмерим с редисом, все данные периодисчески сбрасывает на диск (практически без потерь), на диске занимает меньше места чем memcacheDb, работает быстрее memcacheDb, протокол memcache.
поддерживает mget/mset
в качестве хранилища могу посоветовать TokyoTyran — производительность чуть медленнее мемкеша, соизмерим с редисом, все данные периодисчески сбрасывает на диск (практически без потерь), на диске занимает меньше места чем memcacheDb, работает быстрее memcacheDb, протокол memcache.
поддерживает mget/mset
0
Про игру ничего сказать не могу, похоже сайт накрыло, но скрины очень симпотичные.
Планируете ли какое-то публичное API?
Планируете ли какое-то публичное API?
0
Есть ли в планах адоптация интерфейса под мобильные устройства? Думаю многие почитатели захотят также играть например и в дороге ( в метро например ). А т.к. сделанно без участия флеша то мне кажется что вполне реально адаптировать под айфон и андроиды.
-1
Вроде отпустило — можно смотреть.
0
Помимо Цивилизации чем-то напомнило браузерную стратегию decline, мир её праху.
0
Кому понравилась игра или топик прошу проголосовать за нас на конкурсе.
microsoft.promo.eprize.com/ie9app/gallery?id=210
Заранее спасибо!
microsoft.promo.eprize.com/ie9app/gallery?id=210
Заранее спасибо!
+5
Картинка симпатичная, но что касается иконок кажется немного недобрали с метафорами в угоду реалистичности. Например что изображено на иконке глины я так и не понял, хлеб в уменьшенном виде тоже совершенно не распознаётся, зелёная шестерёнка (?) тоже. Всё такое меланхолично-осеннее.
Нужно чтоб кто-нибудь по английской версии прошёлся: сетка это grid, а не net; артикль в названии по-моему правильнее было бы поставить перед nation, а перед fate наоборот убрать: тут ж судьба нашей нации решается, а не какой-то там; building of crops > growing crops, ну и тому подобное.
А так, для начала круто, спасибо
Нужно чтоб кто-нибудь по английской версии прошёлся: сетка это grid, а не net; артикль в названии по-моему правильнее было бы поставить перед nation, а перед fate наоборот убрать: тут ж судьба нашей нации решается, а не какой-то там; building of crops > growing crops, ну и тому подобное.
А так, для начала круто, спасибо
+1
Ух, спасибо, шикарно! Давно ждал нечто подобное, пожалуйста, только не бросайте писать, с удовольствием бы читал до самого конца и внутренностей создания проекта.
0
А карта технологий будет?
0
Как реализованы таймеры, на постройку и т.д.?
Как передаются данные игрокам, о том, что другой игрок подошел, дергается запрос по таймеру, кто в данной локации?
Как передаются данные игрокам, о том, что другой игрок подошел, дергается запрос по таймеру, кто в данной локации?
+1
Английский в проекте убийственно безграмотен
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.
0
Эти предложения склеиваются из разных частей — где-то переглючивает видимо. Спасибо за комментарии — буду исправлять!
0
Исправил сразу все. При первом апдейте залью на сервер.
Еще Total force of the attack заменил на Total offence.
Если вам не лень то сообщайте о подобном — буду признателен. Лучше в личку — тут можно пропустить.
Еще Total force of the attack заменил на Total offence.
Если вам не лень то сообщайте о подобном — буду признателен. Лучше в личку — тут можно пропустить.
+1
В момент выбора постройки на сервере рассчитывается время из текущего производства города и сложности постройки. Затем в БД в запись города заносится что он строит и когда это строительство завершится. Клиент соответственно знает точное время когда нужно обновить инфу о городе.
Нет по таймеру ничего не обновляется. Обновляется только если игрок что-то делает: двигает карту или города просматривает — тогда дергаются запросы на обновление карты. Если игрок оставит карту в покое то он не увидит подхода войск. Пока так сделано — таймер поставить тоже можно. Но пока никто не жаловался.
Нет по таймеру ничего не обновляется. Обновляется только если игрок что-то делает: двигает карту или города просматривает — тогда дергаются запросы на обновление карты. Если игрок оставит карту в покое то он не увидит подхода войск. Пока так сделано — таймер поставить тоже можно. Но пока никто не жаловался.
0
Партиционирование для таблицы с картой не пробовали применить?
0
Интересно было бы почитать о том, как реализован обмен данными с сервером, какая технология и инструментарий применяется, какая логика и т.д. Сам сейчас занимаюсь разработкой простенькой браузерной игры, пока обмен данными идет AJAX'ом по таймеру, а серверная логика работает по крону.
Большое спасибо за статью, прочитал на одном дыхании. От самой игры под впечатлением. Успехов Вам в дальнейшей разработке.
Большое спасибо за статью, прочитал на одном дыхании. От самой игры под впечатлением. Успехов Вам в дальнейшей разработке.
0
Спасибо. Крон это не очень хорошая идея для пересчетов, если вы об этом. Напишу потом как-нибудь как у нас реализовано.
0
у нас было так:
1) висел бэдграундный процесс (процесс обработчик), который имел свой пид файл
2) процесс засыпал на 1-5 сек, потом начинал считывать очередь и ее обрабатывать
3) после отработки 1000 циклов процесс уничтожал пид-файл, и перезапускал сам себя в бэдграунде (на случай утечек и зависаний)
4) раз в минуту запускался этот же процесс по крону, если существовал пид-файл, то он завершался (как бы на случай страховки)
все работает без сбоев уже второй год
1) висел бэдграундный процесс (процесс обработчик), который имел свой пид файл
2) процесс засыпал на 1-5 сек, потом начинал считывать очередь и ее обрабатывать
3) после отработки 1000 циклов процесс уничтожал пид-файл, и перезапускал сам себя в бэдграунде (на случай утечек и зависаний)
4) раз в минуту запускался этот же процесс по крону, если существовал пид-файл, то он завершался (как бы на случай страховки)
все работает без сбоев уже второй год
0
Наверное правильно писать The Fate of a Nation, нет?
-1
в общем спасибо за игру,
предложения по архитектуре ищи в комментариях,
предложения по архитектуре ищи в комментариях,
0
Пропишите пожалуйста alt для статусбара исследований.
0
А сколько по времени создавалась игра?
0
Восстановление пароля не работает, к сожалению.
0
1) Сколько народу всего работает над проектом и в каких «должностях»?
2) Какова конфигурация железа (сколько серверов, параметры)?
3) 10к человек — это максимальный онлайн или максимум зарегистрированных игроков всего?
2) Какова конфигурация железа (сколько серверов, параметры)?
3) 10к человек — это максимальный онлайн или максимум зарегистрированных игроков всего?
0
1) работает 1 программист (я) и 1 дизайнер/художник
2) недавно взяли 4-ядерный Xeon с 4Гб оперативки
3) я немного слукавил про 10 000 =) На самом деле сейчас помещается 2500 игроков. Так как по просьбе геймеров я разнес стартовые позиции по дальше друг от друга. Ограничение это физическое — на карту больше не поместится. Нужно другую карту(мир, сервер) делать что следующие 2500 играли.
2) недавно взяли 4-ядерный Xeon с 4Гб оперативки
3) я немного слукавил про 10 000 =) На самом деле сейчас помещается 2500 игроков. Так как по просьбе геймеров я разнес стартовые позиции по дальше друг от друга. Ограничение это физическое — на карту больше не поместится. Нужно другую карту(мир, сервер) делать что следующие 2500 играли.
0
Хочется более логичного «поиска пути». Пример
Р — равнина, Г — горы Л — лес. В X стоит рабочий, которому нужно придти в 0
РРРХР
РРГРР
РГРРР
0РРРР
Выбирается логичный, но самый длинный, путь через клетки с горами >4 минут на шаг, вместо двух по равнине.
Р — равнина, Г — горы Л — лес. В X стоит рабочий, которому нужно придти в 0
РРРХР
РРГРР
РГРРР
0РРРР
Выбирается логичный, но самый длинный, путь через клетки с горами >4 минут на шаг, вместо двух по равнине.
+1
Сегодня впервые узнал о вашем проекте. Сам занимаюсь разработкой игрушек (правда во флэше), очень понравились некоторые моменты вашей бизнес логики, ну а графика, конечно — выше всяких похвал, молоды. Очень жду продолжения статьи, очень хочется узнать как все это работает на более низком уровне (какие протоколы используете, еще языки программирования какие, фрэймворки...).
0
Интересная статья!
Однако, интересно узнать про механику игры — ведь взятая за основу Цивилизация все-таки пошаговая стратегия, а реализация автора — реал тайм насколько я понимаю?
Т.е. игроки ходят не последовательно друг за другом?
И пока у меня не открыто окно браузера с игрой у меня не исследуются технологии?
А что происходит, когда на меня нападает противник, а я в оффлайне?
Что касается технической реализации — на мой взгляд разумней было бы использовать на серверной стороне NodeJS + Redis.
Во-первых — высокая скорость работы.
Во-вторых — и там и там js, это дает замечательные возможности, можно писать общий код, двигать участки кода между клиентом и сервером.
Однако, интересно узнать про механику игры — ведь взятая за основу Цивилизация все-таки пошаговая стратегия, а реализация автора — реал тайм насколько я понимаю?
Т.е. игроки ходят не последовательно друг за другом?
И пока у меня не открыто окно браузера с игрой у меня не исследуются технологии?
А что происходит, когда на меня нападает противник, а я в оффлайне?
Что касается технической реализации — на мой взгляд разумней было бы использовать на серверной стороне NodeJS + Redis.
Во-первых — высокая скорость работы.
Во-вторых — и там и там js, это дает замечательные возможности, можно писать общий код, двигать участки кода между клиентом и сервером.
0
Да, реал-тайм, не последовательно, а параллельно.
Конечно исследуются и при закрытом окне — этот процесс на сервере просчитывается.
Если вы в офлайне это ваши проблемы =) Но у нас есть в планах множество идей как скрасить эту проблему. Например дадим возможность на 10 часов в сутки залочить игру — при этом на вас не смогут нападать.
Да было бы круто наверное использовать NodeJs и Redis — но сделали по другому — возможно со временем переделаем.
Конечно исследуются и при закрытом окне — этот процесс на сервере просчитывается.
Если вы в офлайне это ваши проблемы =) Но у нас есть в планах множество идей как скрасить эту проблему. Например дадим возможность на 10 часов в сутки залочить игру — при этом на вас не смогут нападать.
Да было бы круто наверное использовать NodeJs и Redis — но сделали по другому — возможно со временем переделаем.
0
Про регионы вопрос.
Тот факт, что клиент запрашивает регионы по 10*10 клеток, означает что информация хранится на клиенте и таким образом, анализируя ответы сервера мои юниты могут «видеть» эту территорию?
Тот факт, что клиент запрашивает регионы по 10*10 клеток, означает что информация хранится на клиенте и таким образом, анализируя ответы сервера мои юниты могут «видеть» эту территорию?
0
Спасибо за игру. В результате пары дней тестирования возникла пара мыслей/советов:
Ну ооочень тормозит статика. Может, стоит попробовать использовать HTML5-манифест для хранения статики на клиенте?
Решение ограничить размер карты кажется неправильным: думаю, что лучше сделать карту во всё окно, как в оригинальной игре.
Ну ооочень тормозит статика. Может, стоит попробовать использовать HTML5-манифест для хранения статики на клиенте?
Решение ограничить размер карты кажется неправильным: думаю, что лучше сделать карту во всё окно, как в оригинальной игре.
0
Sign up to leave a comment.
Разработка браузерной стратегии