Создать игру без знаний в IT практически невозможно, но мы нашли решение и разработали платформу, на которой пользователи могут сделать свои аналоги популярной игры Wordle. Как проходила работа над проектом, почему пришлось заново переписать почти весь код и что получилось в итоге, рассказываем в статье.
*Статью написали студенты ФИИТ — направления матмеха УрФУ, обучение на котором курирует Контур.
Что такое Wordle?
Это игра от газеты The New York Times, в которой с помощью подсказок нужно угадать слово из пяти букв. С течением времени у неё появился широкий фандом. Фанаты стали создавать подобные игры, загадывать в которых можно не просто слова, а книги, фильмы, игры, персонажей из игр и многое другое.
MVP: как родилась идея и прокрустово ложе выбранного стека
Однажды мы придумали разработать платформу для создания и агрегации игр, подобных Wordle, с которой сможет справиться даже человек без знаний в IT. Между собой мы такие игры называли «dle’ами» и dle-подобными играми. Так родилась идея названия: кем бы вы не были, вы всегда сможете создать свою dle-игру на нашей платформе, вашу собственную (your) — поэтому и YOURdle.
Идею мы обсуждали в начале четвёртого семестра обучения на ФИИТ, захотели убить двух зайцев: закрыть курс проектного практикума и экзаменационную работу курса по основам веб-разработки. Это накладывало определённые ограничения на выбор стека, ведь одним из требований экзаменационной работы было использование чистого стека HTML+CSS+JS без фреймворков и плагинов. Поэтому на нём мы и остановились несмотря на то, что реальные проекты обычно пишутся на каком-либо из фреймворков.
Для бэкенда выбрали C#, так как каждый из нас умел программировать на нём, с ASP.Net Core и EFCore — стандартами индустрии в платформе dotnet для работы с веб-серверами и базами данных. Такой выбор не только позволил бы впоследствии перенести опыт работы с ними в рабочую практику, но и наоборот.
В качестве БД мы решили остановиться на PostgreSQL: никто из нас на тот момент ещё не работал ни с одной СУБД, кроме SQLite в предыдущем проекте, так что выбор был не слишком информированным — не было исчерпывающего опыта работы с SQL- и NoSQL-базами данных, не было чёткого понимания, как будет развиваться проект, и поэтому обосновать строго какую-либо из парадигм было сложно. В рамках конкретной же парадигмы выбор размывался ещё сильнее. PostgreSQL распространён в индустрии, поэтому изобилие гайдов и полнота документации, а также готовая поддержка в EF Core сделали этот выбор относительно простым.
К сожалению (или к счастью ?), первый прототип игры сохранился лишь в виде скриншотов в беседе нашей команды. Если посмотрим на них (добавили чуть ниже?), то увидим попытки в стильный дизайн, но без каких-либо знаний о том, как это работает. КАПС на всех кнопках без отступов по краям, кислотные цвета на контрасте с серой палитрой, случайно подобранные иконки из гугла… Помимо этого, структура интерфейса вызывала уйму вопросов у нас самих, а правильно пользоваться сайтом умел один человек из команды. На тот момент фронтендеры в нашей команде были с вёрсткой на «вы», а с дизайном и UI/UX и вовсе на «Ваше Величество». Результат — идейно и потенциально красиво, но совершенно неюзабельно для обычного пользователя.
Архитектура приложения на бэкенде тоже оставляла желать лучшего, но это мы узнали позже. В целом, копилка наших плохих решений, не замеченных из-за неопытности, выглядела внушительно, хотя сейчас мы оглядываемся на них, не сдерживая улыбки. Но тогда мы не видели ошибок, и были уверены в нашем проекте — защита ведь прошла успешно, и мы даже получили хорошие отметки.
Реализация на альтернативном стеке
К этому проекту мы вернулись спустя полгода, в шестом семестре, после того, как семестр поработали над другим проектом, полностью фронтендовым. Многое поменялось за это время: больше половины команды сходили на стажировки, появились опыт и знания, которых недоставало раньше. Курс веб-разработки остался позади, и теперь наш проект был только для проектного практикума, а значит, отпала необходимость в строгом соответствии стеку HTML+CSS+JS без фреймворков.
С высоты нового опыта разработки мы смогли определить немало ошибок, совершённых в первой итерации:
⛔️ дизайн нашего интерфейса был неудобным, но самобытным и интересным — при этом понимаем, что самобытность не делает интерфейс хорошим;
⛔️ из-за сжатых сроков немало вещей оказались сырыми: плейсхолдеры вместо некоторых кнопок и картинок, банальное отсутствие стилизации части элементов, повсеместно съезжающий или нечитаемый текст;
⛔️ сайт не поддерживал мобильные устройства, хотя потенциально именно оттуда подразумевался основной приток пользователей;
⛔️ решения по типу кодов игр делали платформу неудобной, а отсутствие обучения делало порог использования платформы пусть и не чрезмерно высоким, но ощутимым. По словам одного из наших пользователей, «Я что-то нажала, что-то всплыло – я ничего не поняла!»;
⛔️ проекты на чистых HTML+CSS+JS поддерживать сложнее, и это не распространённая практика, а значит, подобные навыки хотя и хороши для обучения основам фронтенд-разработки и пониманию принципов работы браузера и модели DOM, не будут полезны при трудоустройстве. Поэтому, чтобы наши фронтендеры нарабатывали более полезные навыки и меньше страдали с кодом на чистом JS, мы сместились в сторону TypeScript и фреймворка React как одного из самых распространённых в индустрии. К тому же, у нас за плечами был семестровый курс разработки на React. Тем не менее, это означало, что фронтенд предстоит переписать полностью;
⛔️ бекенд пережил фазу «переписываем всё», сохранив изначально выбранный стек (не в последнюю очередь потому, что основной бэкендер в команде работал как раз в бэкенд-разработке на C#). Предстояло в значительной степени пересмотреть архитектуру приложения, потому что из-за многих поспешно принятых решений расширяемость оставляла желать лучшего — так, расширять количество типов полей при создании игры или докручивать совершенно новый функционал вроде тегов требовало значительно переписывать другие совершенно не связанные места из-за плохого разделения ответственности в коде, — а API было спроектировано исключительно под руководством принципа «хороших вайбов» (до того, как это стало мейнстримом). Хотя GET /api/games/FIITDLE/get и был близко, мы решили, что хотим привести интерфейс в соответствие принципу REST;
✅ PostgreSQL выдержал испытание временем — в нашем случае он не накладывал никаких дополнительных расходов на поддержание, интегрировался двумя строчками кода и не был узким местом при исполнении запросов при том, что мы даже никак не меняли настройки. Тем не менее, мы заметно изменили схему базы данных, чтобы почистить её от устаревших полей и таблиц и подготовить пространство для разработки новых фич.
В сущности, наш стек сильно не поменялся — максимум, сменил пальто на куртку. С точки зрения целей же, если в первом семестре работы над проектом мы хотели воплотить как можно больше идей — добавить картинки в поля, сделать (в конечном итоге всё равно выпиленные ?) уникальные коды игр, закрыть создание игр на регистрацию, сделать поля, сравниваемые по принципу «больше-меньше», – то теперь поставили в приоритет сделать хорошие UX и UI, чтобы в следующем семестре не возникло желание снова всё переписать, а результат работы было легко поддерживать.
Помимо этого мы решили подготовить проект к коммерциализации, то есть довести продукт до стабильного состояния, в котором он способен привлекать и удерживать пользователей, которые впоследствии могли бы стать источником дохода. Это было нашей мечтой о том, что наше детище однажды угостит нас пиццей.?
Чтобы переписать весь проект, нам пришлось знатно поработать в течение семестра, и за это время мы разрешили все отмеченные в начале семестра проблемы: редизайн, перевёрстку, REST API и переработку схемы БД. Сверх этого мы также вложились в параметризацию и модульность сборок проекта, чтобы в дальнейшем работать над проектом было удобнее.
Новой версией сайта стало удобнее пользоваться почти по всем параметрам. От некоторых идей, которые казались нам прикольными, мы отказались. Например, сначала мы хотели присваивать каждой игре уникальный код из семи символов и ограничивать доступ только по ним. В такой схеме, не зная кода, посетитель сайта не смог бы сыграть ни в одну игру. Однако на практике оказалось, что эта идея слишком недружелюбна к пользователям и неудобна, поэтому от этого мы отказались полностью в пользу галереи публичных игр. Немало усилий было вложено в опыт пользования редактором игр, одним из самых заметных улучшений стала возможность сохранять прогресс работы над игрой без его публикации, чего (подумать только!) не было раньше. На «победный» попап мы добавили историю угадывания и ссылку на игру, чтобы своим успехом можно было поделиться и призвать испытать свои силы.
Улучшение UX/UI и обратная связь первых пользователей
В последнем семестре работы над проектом планов всё переписать уже не возникало, мы остались по большей части довольны тем, что уже сделали. Но на этом этапе нам ещё предстояло расширить функционал и улучшить пользовательский опыт.
Нам предложили представить наш проект на стенде Контура в рамках «Времени Карьеры» — мероприятия, где студентам и школьникам рассказывают о перспективах будущей работы. Его участники могли попробовать нашу платформу. Возможность протестировать сервис на реальных пользователях стала для нас поводом научиться собирать и хранить метрики, провести нагрузочное тестирование и убедиться, что решение не упадёт под нагрузкой посетителей стенда. Также мы переехали на хостинг на собственном железе, так как хоститься в облаке было слишком дорого в масштабах нашего проекта.
«Время Карьеры» прошло для нас крайне успешно. В первую очередь, мы подтвердили нашу гипотезу о том, что есть много пользователей, которым формат интересен. В течение дня на мероприятии мы также собирали статистику по вовлечению посетителей стенда в нашу активность.
Количество людей, которые предприняли попытку пройти игру, по итогу превзошло наши предположения и надежды, а процент завершения приятно удивил.
В конечном счёте, мы остались довольны техническим результатом, также нас порадовали многочисленные отзывы пользователей.
На основе фидбека с «Времени Карьеры» мы сделали вывод об успешности наших изменений в направлении дизайна, которые опробовали на страничке игры, и решили применить его и к другим страницам сайта.
Будущее проекта
На этом наша работа над платформой в рамках проектных практикумов закончилась, но бросать его мы не намерены, так как сильно прикипели к нему и хотим раскрыть весь его потенциал.
Мы собираемся и дальше поддерживать работоспособность площадки и разрабатывать новые фичи в более размеренном темпе, насколько у нас будет хватать сил и времени. В планах многое: создать систему модерации, обновить внешний вид и функционал конструктора, добавить новые режимы игры, серии побед, переработать и полноценно запустить систему тегов и подбора релевантных игр. И лучшие дни платформы, определённо, ещё ждут нас впереди.
Сайт нашего проекта доступен по адресу www.yourdle.fun, и мы будем рады видеть вас среди его посетителей. Кто знает, возможно, ваши единомышленники уже создали игру вашей мечты? А если нет, то даже лучше, ведь этот шанс достанется вам! ?