Примечание. Это только первая из серии статей, посвященных играм TTRPG и Svelte Web Development. Эта работа служит введением в серию. Загляните сюда позже, чтобы узнать о дополнительных выпусках этой серии, так как работа еще продолжается.

Далее: SvelteQuest II: Настройка

Прежде чем мы начнем, немного о моем предыстории:

Как разработчик

Я был веб-разработчиком три года. Я использовал и любил Vue для веб-приложений, хотя с годами все больше внимания уделяется созданию и поддержке API-интерфейсов JavaScript и TypeScript Express.

Как игрок DND

Недавно я закончил шестимесячное пребывание в качестве DM (Dungeon Master, в основном «рассказчик / исполнитель правил») для группы смутно бесстрашных, псевдофункциональных авантюристов. За это время я получил большой опыт работы с веб-инструментами и технологиями, доступными онлайн-игрокам в TTRPG (настольная ролевая игра) и GM (Game Masters, более общий термин). Теперь, когда я снова стал игроком, я обнаружил, что у меня очень мало времени в поисках нового способа удовлетворить свое желание поработать над чем-то связанным с TTRPG.

Проблема

Мое знакомство со Svelte было выступлением Рича Харриса (создателя Svelte) в New York Times, которое я бы рекомендовал просмотреть полностью. Чтобы уловить один из основных моментов Харриса:

«Есть только один надежный способ ускорить код - избавиться от него. Будьте как Мари Кондо: разве этот JavaScript вызывает радость? »

Я люблю фреймворки. Мне сказали, что они делают веб-разработку намного проще, чем раньше. Однако в сообществе JavaScript и в сообществе программистов в целом принято считать, что веб-приложения JavaScript становятся большими и ресурсоемкими. То есть они выполняют слишком много кода.

Моя старая версия могла бы утверждать, что размер и производительность приложения в веб-фреймворках - это в значительной степени академические дебаты, ведущиеся в килобайтах и ​​наносекундах, которые пользователи никогда не увидят. Старый я не осознавал, что принадлежу к привилегированной интернет-элите.

Я не аномальный программист. Я строю сайты, слушая музыку и запускаю четыре чат-приложения в фоновом режиме своего Macbook Pro 2020 года, блаженно не подозревая о скорости загрузки 649,5 Мбит / с и скорости загрузки 39,3 Мбит / с моего домашнего интернета, работающего в фоновом режиме. Когда я создаю свое приложение, я ничего не знаю о том, как оно загружается со средней скоростью загрузки 10 Мбит / с, не говоря уже о скорости загрузки 7 Мбит / с для телефонов, подключенных только к 4g.

И, если пойти дальше, то соединение 4G - это довольно удивительно в целом. Следующая карта послужит убедительным доказательством:

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

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

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

Почему Svelte?

Если вы посмотрите на эти таблицы из Log Rocket, вы увидите, что Svelte имеет явное преимущество перед другими ведущими отраслевыми фреймворками (Angular, React и Vue) в сфере эффективности. Чтобы синтезировать таблицы:

  • Общий вес Svelte в килобайтах на сегодняшний день самый маленький.
  • Svelte является постоянно интерактивным (своего рода метрика времени до интерактивности) менее чем за 2 секунды, чего не могут достичь другие фреймворки.
  • Во всех тестах, связанных с памятью (готовая память, рабочая память, использование памяти после артиллерийских операций с данными), Svelte блистает.

Если решение проблем, которые я перечислил выше, является главным приоритетом, эти показатели могут сделать решение, отличное от Svelte, неоправданным. Теперь я люблю Vue, и он всегда будет занимать особое место в моем сердце (любой фреймворк, заменяющий jQuery, окажет такое влияние на разработчика), но в этой конкретной серии я буду избегать Vue, потому что я почувствовал Svelte (я думал о замене этого пункта; я не позволю себе это сделать).

Проект

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

В разгар COVID мы с друзьями начали использовать некоторые из замечательных существующих инструментов для удаленной игры в Dungeons and Dragons, и мы прекрасно провели время. Несмотря на то, что сейчас мы играем лично, большинство из нас по-прежнему предпочитают веб-инструменты, такие как онлайн-таблицы персонажей (проще в управлении) и виртуальные столы (дешевле), их материальным аналогам.

По мере того как наши личные игры обогащаются веб-технологиями, я начал задаваться вопросом, что бы я мог сделать, чтобы развлечь нашу вечеринку. Моей первой мыслью (когда я ложился поздно вечером в субботу, выполняя беговую работу по кампании для следующего дневного сеанса, что достаточно обычное явление для DM), было приложение для построения мира, которое устраняет или упрощает большую часть скуки, связанной с бегом по дому. -заваренные игры. Однако теперь я могу с радостью сказать, что использую бета-версию фантастической вики по построению мира под названием Legendkeeper, которую я просто не могу похвалить.

Итак, что еще я могу построить? Инструменты DND довольно надежны. Виртуальные столешницы тоже в надежных руках. Итак, как насчет более широкого инструментария TTRPG? Как бы мне и моим друзьям не нравился DND, у нас есть некоторые претензии к нему, связанные с вечеринками. В первую очередь, нам не нравятся бои в режиме DND, которые, как мы думаем, имеют тенденцию затягиваться или быть неинтересными (возможно, потому, что большую часть времени это чья-то очередь).

С тех пор, как мы начали играть, мне было любопытно, что нужно для создания TTRPG с нуля. Очевидно, это усложняется. TTRPG нуждаются во всевозможных нетехнических работах, чтобы увидеть свет. Вам нужен кто-то с большим умом для вероятностей и статистики, чтобы понять, как игра должна быть сбалансирована. Вам нужны отличные копирайтеры, чтобы создавать мир, создавать монстров и предметы, а также кратко резюмировать и представлять игровую механику для игроков (даже в этом случае есть целые форумы, посвященные правильному толкованию священных евангелий, которые являются основными сводами правил DND). И вам нужны игровые тестеры, чтобы пробовать игру снова и снова, пока сложность не будет сбалансирована, не говоря уже о том, чтобы понять, действительно ли то, что вы собрали, приносит удовольствие.

Теперь мы собираемся заняться всем этим, но это тема для другой серии статей. Эта серия статей якобы посвящена разработке на Svelte, поэтому мне нужно найти способ использовать свои веб-знания для разработки нашей TTRPG. Я расставлю приоритеты. Что в первую очередь хочет сделать каждый, когда начинает новую ролевую игру? Бросьте, конечно же, персонажа!

Мне приходит в голову, что современные веб-страницы являются своего рода идеальным носителем для сложных листов символов, а листы символов на самом деле являются довольно хорошим способом продемонстрировать все, что должно эффективно делать современное веб-приложение. Наш список персонажей должен:

  1. Читайте данные из обширных источников (данные персонажей, заклинания, способности, правила и т. Д.).
  2. Поддержка множества взаимодействий с пользователем - клики, прокрутки, прокрутки, потребление слотов, остатки.
  3. Поддержка сложного взаимодействия с пользователем, например управления запасами.
  4. Поддержка повышения уровня, создания персонажей и других процессов управления формами.
  5. Поддержка пользовательских биографий персонажей и другого пользовательского контента.
  6. Будьте предельно отзывчивыми и доступными.

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

Цель

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

Но как только код написан и все мелкие ошибки наконец устранены, как мне его протестировать? Как я могу с уверенностью сказать, что составленный мной список персонажей удовлетворительно решает этические и практические соображения, которые я изложил ранее? Как я узнаю, что создал что-то производительное?

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

Он не может загрузить лист персонажей DND Beyond. На самом деле, он не может загрузить много чего. Мне кажется, что цель SvelteQuest вполне ясна: загрузить приложение с пользовательскими таблицами персонажей на мой дрянной планшет при ухудшенном интернет-соединении. Но, как засвидетельствует большинство игроков, ни один квест не обходится без BBEG (Big Bad Evil Guy, «Злодей»), с которым нужно бороться, поэтому моя вторая цель также становится ясной: приложение Svelte должно получить лучший результат Lighthouse в каждой категории. чем мой текущий лист символов "Не беспокоить".

Это будет непросто.