azShoo

Давайте будем честными, продукты имеющие реальную продуктовую ценность имеют такое число состояний, что какие-то из них будут всегда сломаны.
Независимо от фреймворков, тестирования и прочего. Баги будут, и чем больше изменений вы вносите - тем больше шансов привнести и баги.

Тем не менее, есть вполне стандартные методы минимизировать эту боль.
Это и практики тестирования (не только силами тестировщиков) и повышение code culture, код ревью, мониторинг состояния продукта, нормальные практики релизов и прочее-прочее-прочее.
Никакого единого способа "всё и сразу починить" нету.

"Оптимальный" путь зависит многих факторов.
Например, от архитектуры игр: предполагается постоянный коннект клиента с сервером, или можно жить в оффлайне?
Например, от UI и игровой логики: должен ли у пользователя быть постоянный real-time доступ к состоянию таймера восстановления, или оно просто должно тикать где-то в фоне?
Может ли он взаимодействовать с этим таймером (напр. дебаффать других игроков, что бы замедлить восстановление, или задонатить что бы сократить время)

В целом детерминированная по определенным правильнам, регулярно случающаяся активность идеально попадает под Scheduled Job \ Timer внутри игровой логики.
У вас есть момент инициализации таймера, в который вы рассчитываете с какой скоростью и в каком объеме у вас должен происходить "тик" восстановления энергии.
У вас есть момент окончания таймера - объект из буффера кидается в очередь на передачу клиента, обрабатывается клиентом, происходит так.
У вас есть критерии его окончания - пользователь ушел в оффлайн? Грохнули все таймеры для него, например. Или, наоборот, зафризили.

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

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

Второй вариант - тулзы для этого предназначенные. Уже упомянутый BrowserStack, SauceLabs(который лично я рекомендую) и куча альтернатив которые можно найти на alternativeto.net/software/sauce-labs
Из минусов этого подхода - что-то очень медленно работает, что-то очень криво работает (т.к. гоняет эмуляторы вместо конкретных версий браузера). + проблемы с локальными хостами и прочим.

Такие дела.

Я думаю, что есть очень много вопросов, над которым вам надо подумать перед тем, как браться за эту идею.
Как минимум потому, что ваше описание проекта трудночитаемо и слабо понятно.
1) Окей, есть "социальная сеть".
Что там должны делать инди-разработчики?
Завести канал и постить видео? О чем? О геймплее, о разработке?
Или надо постить рекламные посты и обзоры?
Или надо кидать ссылки на гуглплей \ кикстартер?
Или как стим будете прикручивать "каталог" игр?

Что там должны делать пользователи?
Искать и скачивать игры? Читать обзоры\смотреть видосы?
Или генерировать контент с обзорами игр и оценками? Если да, то зачем им это?

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

2) Как вы всё это будете монетизировать?

3) Как вы будете привлекать туда аудиторию, как со стороны разработчиков, так и со стороны игроков?
Чем вы лучше какого-нибудь 4pda или тонны форумов про геймдев? Или раздела рутрекера с инди играми.
Стрим предлагает канал продаж, ютуб - удобный хостинг видео + реклама, кикстартер - краудфандинговую платформу.

Про это даже говорить не хочу:

дать возможность игрокам пополнять счет и вносить пожертвования понравившимся проектам за внутрисистемные ачивки.

Ибо с безопасностью непонятно что, с мотивацией - тоже (покупаемые ачивки? лол, зачем?!), с условиями получения и вывода - тоже непонятно. В общем вопросов ещё на полтора поста.

Как уже советовали - напишите тз\бп, спроектируйте сервис хотя бы на уровне бизнес-процессов, а потом беритесь за реализацию и ищите товарищей.

Искусственный интеллект? Серьезно?
Ну йомана.

Для браузеров с >15% аудитории сервиса - только живые браузеры, при необходимости - виртуалки.
Для остального - сойдет браузерстак.

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

Их нет.
Арендодателям проще передать весь гемор агенту, ибо платит за это арендатор.
Как результат - без агента сдается дай бог 5% квартир. Т.е. такие сервисы мало осмысленны, хотя и не хочется платить комиссию лишним упырям

Написано же, с помощью одного из средств автоматизации.
Берете селениум\тестнг\любойдругой фреймворк автотестов, и пишите.

Боюсь показаться капитаном очевидностью, но... Бизнес аналитик?

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

Нет, не целесообразно.
Сделать защищенный сервис у вас не получится, а бесполезное шифрование только добавит багов.

Если при загрузке файла пользователь дает явное согласие, что загружаемый им контент не является объектом чужих авторских прав (или он имеет право на распространение данного контента) - то сайт не является "нарушителем".
Но, нужно учитывать два момента:
1) Придется оперативно обрабатывать и удалять требования правоторговцев. В частности, указанные вами критерии оценки "нарушает - не нарушает" их может и не устраивать.
2) От вас могут потребовать данные аплоадеров, для дальнейшего разбирательства с ними.

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

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

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

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