Как да модернизираме онлайн игра, която милиони все още играят

Изображение: Svetni.me / ИИ генерирано изображение

Модернизирането на активна онлайн игра с милиони потребители изисква управлението на съществуващото съдържание и навиците на играчите като преки системни зависимости, а не просто като софтуерен код. Според анализ на архитекта на системи за геймплей Александър Жорау, публикуван в Software Engineering Daily, всяка пусната функция оставя след себе си дълбоки зависимости [1]. Дизайнерите изграждат съдържание около стари инструменти, инженерите свързват нови системи към остарели интерфейси, а потребителите научават специфични поведения в играта, които първоначалният екип може никога да не е планирал. След десетилетие работа дори най-малката техническа промяна може да засегне стотици активи и милиони играчи, поради което студиата се нуждаят от ясен план за миграция преди изграждането на нова архитектура [1].

Изображение: Svetni.me / ИИ генерирана инфографика

Анализ на зависимостите и контролирано съвместно съществуване

Успешният план за миграция на софтуерните компоненти в една онлайн игра изисква отговор на пет ключови въпроса преди началото на внедряването. Те включват идентифициране на зависимостите, възможността за паралелно функциониране на старата и новата система, разпределянето на отговорността за миграция на съдържанието, откриването на регресии и условията за окончателно премахване на старата система [1].

В по-големите проекти за разработка на игри се разглеждат различни технологични двигатели като Unreal Engine и Unity, както и собствени (proprietary) архитектурни платформи [1]. При прехода към нова система се налага поддържане на контролирано съвместно съществуване на старата и новата имплементация, за да не се наруши работата на екипите по съдържанието. В тези екосистеми се използват и разпределени системи за обработка на мрежовите заявки и управление на състоянията на играчите на живо.

Навиците на играчите и системните граници

Особен аспект при поддръжката на дългогодишни заглавия са „поведенческите договори“ с потребителите [1]. В практиката си Александър Жорау дава пример за дефект, при който мерникът в игра се е показвал наполовина по-малък от планираното, но играчите са свикнали с него и корекцията му би променила изживяването им. Поради това екипите трябва да изследват как потребителите използват дадена функция, преди да я модифицират.

За откриване на поверенически и производителни проблеми при миграцията се препоръчва използването на функционални, интеграционни и end-to-end тестове, които покриват взаимодействията отвъд границите на отделните компоненти [1]. Мониторингът на производителността в реално време (базово време за кадър, памет, мрежова латентност) остава задължителен за улавяне на проблеми, които тестовете пропускат.

Институционализиране на решенията и ролята на наследствения код

В големи технологични организации, включително и такива с мащабите на Meta, техническите решения трябва да бъдат кодирани в самата система чрез стабилни интерфейси, валидиращи правила и автоматизирани тестове, вместо да се разчита на устно предавана история [1]. Това улеснява новите инженери и предотвратява случаи, при които премахването на привидно излишен код води до регресия.

Наследственият (legacy) код не трябва да се разглежда автоматично като лош код. Подмяната му е оправдана само при ясни ползи за производителността или скоростта на производство на съдържание [1]. Някои системи изискват изолация чрез ясни граници, докато други трябва да останат непокътнати, докато бизнес нуждите не наложат промяна. Жорау, който има опит в компании като Wargaming и Splash Damage, подчертава, че целта на модернизацията не е да се изтрие историята на софтуера, а да се предотврати блокирането на следващото издание [1].

Източници:

[1]: How to Modernize an Online Game That Millions Still Play - Software Engineering Daily