В последнее время, мне пришлось немного поработать с блокчейном Ethereum. Идея, над которой я работал, требовала хранить прямо в блокчейне некоторое достаточно большое количество целых чисел, так, чтобы смарт-контракт имел к ним удобный доступ. Большинство уроков по разработке смарт-контрактов говорят нам «не храните много данных в блокчейне, это дорого!». Но сколько это «много», и с какого количества цена становится слишком высокой для практического использования? Это мне надо было выяснить, потому что нам наши данные выносить офф-чейн было никак нельзя, рушилась вся затея.

Я только начинаю работать с Solidity и EVM, поэтому эта статья не претендует на истину в последней инстанции, но других материалов по этой теме ни на русском, ни на английском мне найти не удалось (хотя очень плохо, что вот эта статья мне не попалась раньше), поэтому я надеюсь, что она может оказаться кому-то полезна. Ну или в крайнем случае, она может оказаться полезна мне, если опытные товарищи расскажут, насколько и где именно я в ней не прав.

Для начала, я решил быстро прикинуть — получится ли у нас? Давайте возьмём стандартный, широко распространённый тип контракта — токен ERC20. По крайней мере, такой контракт хранит в блокчейне соответствие адресов людей, который купили токены, их балансам. В реальности, хранятся только балансы, каждый из которых занимает 32 байта (на деле здесь экономить не имеет смысла из-за особенностей Solidity и EVM). У более-менее успешного токена легко могут быть десятки тысяч обладателей, и таким образом получаем, что хранить в блокчейне около 320000 байт — вполне допустимо. А нам больше и не надо!

Наивный подход

Ну что же, попробуем наши данные сохранить. Значительная их часть — 8-битные целые беззнаковые числа, поэтому передадим их массив в контракт, и попробуем записать их в постоянную память:

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

У меня есть один проект. Для сборки он использует CMake, а также менеджер пакетов для C++ под названием Hunter, хорошо с CMake интегрированный. Проекту необходимо собираться для нескольких платформ, одна из которых — Android. Hunter собирает зависимости под Android без проблем — но ему нужна версия CMake >= 3.7, поскольку именно в 3.7 была добавлена улучшенная поддержка этой платформы. Эта очень важная деталь.

Статья обновлена с учётом полезных комментариев. Большое спасибо всем комментаторам за важные уточнения и дополнения.

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

Выходом является использование готовых универсальных UI библиотек. Текущее их поколение представлено такими «монстрами» как Scaleform и Coherent UI, хотя если вам так хочется писать UI на HTML, то можно и просто взять Awesomium.

К сожалению, у этой троицы, при всех её преимуществах, есть один существенный недостаток — жуткие тормоза, особенно на мобильных устройствах (несколько лет назад, я лично наблюдал, как практически пустой экран на Scaleform потреблял 50% от времени кадра на iPhone4).

На этом фоне, мне всегда было интересно, почему никто не использует в играх Qt — библиотеку, неплохо зарекомендовавшую себя в десктопных приложениях. На самом деле, это утверждение не совсем верно — в Wiki проекта Qt есть список игр, однако в нём почти нет современных профессиональных проектов.

Впрочем, причина, по которой именно привычные старые Qt Widgets не используются в играх, лежит на поверхности: они не рассчитаны на использование совместно с OpenGL или DirectX рендером. Попытки их скрестить дают довольно плохую производительность даже на десктопе, а про мобилки и говорить нечего.

Однако, уже довольно давно в Qt есть гораздо более подходящая для этой задачи библиотека: QtQuick. Её контролы по умолчанию рендерятся ускоренно, а возможность задавать описание UI в текстовом формате отлично подходит для быстрой настройки и изменения внешнего вида игры.

Тем не менее, я до сих пор не слышал об использовании Qt в профессиональном геймдеве. Статей на тему тоже не нашлось, поэтому я решил разобраться сам — то ли все что-то знают, чего не знаю я (но не рассказывают!), то ли просто не видят хорошую возможность сэкономить на времени разработки.

Пришла весна. Коты думаю о кошках, мужчины о женщинах, а программист — куда бы ещё портировать имеющийся код. Я ещё прошлой осенью стал обладателем Meizu MX4 Ubuntu Edition, и поэтому выбор был давно очевиден. А тут нашлось и время, и силы.

Недавно я выпустил в свет свой первый законченный «домашний» проект — ремейк игры «Island of Dr. Destructo» (также известной как просто Destructo) с ZX Spectrum. В этом посте я хотел бы рассказать немного о том, как шла разработка и поделиться некоторыми интересными замечаниями о кросс-платформенной разработке и архитектуре кода.