Юрий

пока яндекс не склеил (и вы работаете без редииректа) это отдельные сайты, то есть на одном сайтмап http на другом https. после склейки - делаете редирект. http sitemap уже не актуален, оставляем только https.

исходить нужно из того что за игру вы планируете делать. какой размер игры...
если вы планируете работать как инди или в маленькой команде то вам дорога в Unity + C#. или другой движок, например CryEngine, который год назад стал бесплатен.
если игры ААА класса в большой команде то С/С++, но тут выбор языка уже не за вами.

function DNAStrand(dna){
var dnk = '', i = 0;
  for (i; i < dna.length; i++){
  switch(dna[i]){
  case 'A': (dnk += 'T'); break;
  case 'T': (dnk += 'A'); break;
  case 'C': (dnk += 'G'); break;
  default : (dnk += 'C');
  }
  };
  return dnk;
}

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

<?php echo file_get_contents("https://toster.ru/main.rss");

и уже этот скрипт указывать в rss

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

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

UPD подведу итог, я бы рекомендовал
1) использовать кастомные твиг функции, когда требуется какая то сложная логика или запрос данных из системы, но не рекомендовал бы ее для генерации html, просто потому что html в пхп не гуд. но в кастомной функции вы можете вызвать render другого шаблона, это норм, просто может ухудшить поиск верстки для фронтендеров (в случае инклюда для них все очевидно).
2) макросы - для кучки небольших вещей которые используются часто и повсеместно (инпуты)
3) инклюды для остальных кейсов, то есть когда данные уже есть и нужно их оформить в html

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

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

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

полистав пример тестового приложения понял что статусы хранятся в поле marking у сущности https://github.com/lyrixx/SFLive-Paris2016-Workflo...
поле имеет тип json_array. надо бы запустить этот тестовый проект, погонять. например для меня пока не очевидно как сделать фильтрацию сущностей по этому статусу, неужели отдельное поле/я добавлять и в подписчиках его менять.

также можно полистать исходники самого бандла, вот например метод для смены статуса https://github.com/symfony/workflow/blob/master/Wo...

при встраивании в div минус в том что сайт который встривает имеет полный доступ к контенту. может менять дизайн/код и тд. из плюсов только если нужно чтобы этот сайт получал кэллбэки на разные действия. например когда клиент добавил в корзину.
с iframe это сделать чуть сложнее (через postMessage). iframe дает вам полную изоляцию от сайтов, они уже не смогут подглядывать внутрь и модифицировать.
также если высота контента должна меняться, то с див все просто, для iframe нужно опять же делать через postMessage.

по реализации: либо бюджетный вариант - просто отдельная версия сайта с переходами внутри (еще один плюс iframe - страницу можно обновлять, делать переходы на другие урл). бюджетный, потому что фронтенд простейший, можете даже просто ваш сайт без header/footer туда запихнуть.
не бюджетный - SPA приложение, для него просто используйте любой js фреймворк (ангулар/реакт и тд).