В БД (или быстрый кэш, типа Redis). Причин несколько:
Ваше приложение может упасть. Игрокам не понравится, если у них вдруг пропадут карты. БД тоже падают, но вероятность этого гораздо меньше (у них больше разработчиков и тестеров).
Массивы в памяти не масштабируются. Положим, пару десятков одновременных партий в памяти держать можно, но когда счет пойдет на тысячи, это будет жрать RAM, плюс тормоза на GC. А БД можно вынести на отдельный сервер и даже на отдельный кластер.
Ну, понятно, что в учебном примере пофиг на надежность и масштабируемость, но почему бы не делать сразу правильно?
В разработке -- там все сложно с обратной совместимостью, потому что парсер должен работать в совершенно другом режиме при загрузке модуля, то есть надо знать, в файле CJS это или ES6, прежде чем отдавать его парсеру.
Пока можно использовать babel-register. Я пишу пока без модулей, если соблюдать некоторые правила, то переход будет не очень сложным.
А нафига тогда модули вообще, если их не использовать? Уберите и собирайте все с помощью gulp-concat, это ведь очень весело — вручную определять порядок загрузки файлов и постоянно добавлять и убирать файлы в списке вручную:)
TypeScript, к сожалению или к счастью, не умеет собирать приложение в один файл — полагаясь на сторонние решения, которых много и которые представляют другие плюшки.
> У webpack + babel есть такая возможность — не использовать никакую систему, а используется собственный компоновщик.
Babel тут вообще не при чем, он тоже не умеет склеивать файлы. А в webpack нет такой «возможности», он использует уже существующие форматы модулей — из коробки поддерживаются amd, cjs и es6 (import/export и import()). Советую присмотреться, это хоть и головная боль поначалу, но вообще стоит того.
Если совсем вкратце, то каждое значение в data заворачивается в геттер и сеттер. Таким образом при изменении свойства у нас вызывается функция-сеттер и мы можем об этом узнать и произвести какие-то действия.
P.S. Можно еще rivets расковырять, там похожий подход, но кода поменьше.
Недостаточно данных, какую именно игру хотите? Например, Годвилль ничем не отличается от обычного SPA. Если что-то должно бегать-прыгать-взрываться, то надо смотреть на игровые движки (phaser.io, CraftyJS), писать будете на JS или TypeScript. Если 3D — BabylonJS или PlayCanvas. Не исключен вариант с конструкторами типа ClickFusion или Construct 2, которые умеют публиковать в веб, тут вообще программирование мышкой. Unity 3D тоже умеет публиковать в веб. Еще многообещающий инструмент Blend4Web.
На практике agile выглядит так: после планирования разрабы вежливо выпроваживают бизнес за дверь и начинают писать код. Он им нужен исключительно чтобы бизнес не подкидывал новые гениальные сверхсрочные хотелки, а так-то любой девелопер за исключением совсем уж новичков может организовать себя.
Бизнес думает, что agile ему нужен для контроля, но на самом деле он нужен для -понимания, что нельзя получить все сразу и уже вчера- расстановки приоритетов, котов пасти все равно невозможно.
Тройка по химии в школьном аттестате, поступил на химфак. Универ не кончил, работаю программером за границей. На оценки дельным людям похрен, важны реальные знания/навыки и понимание.
Корочки, однако, помогают общаться с некоторыми бюрократическими организациями (например, без диплома получить в Европе blue card будет существенно сложнее). Но внутрь, повторюсь, никто не заглядывает.
Некоторые библиотеки упакованы так же в gem'ы, но это исключение на данный момент.
Как я понимаю, сейчас везде тенденция создавать в корне package.json и Gulpfile.js (или чем вы хотите собирать статику) и отдавать фронтенд на откуп тому, кто знает, как с этим обращаться.