Сюрреализм на JavaScript

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

if(это компилируется?) {
WebView на весь экран
} else {
ZIP архив с манифестом
}

Ваше HTML приложение + макет с WebView = сборка под какую-то платформу

Как обходят неработающие cookie?
В таких случаях, как правило, на уровне CMS, реализуется механизм, который автоматически дописывает номер сессии пользователя в виде параметра во все ссылки на странице. Например, до:
http://wap.samsung.ru/games/index.do
И после:
http://wap.samsung.ru/games/index.do

В течение месяца я писал нарды для телевизора. Когда они были готовы, менеджер неожиданно снял задачу и проект прикрыли. Хорошим выходом из ситуации было выпустить игру на других платформах (телефоны, расширение, десктопные браузеры), но это было невозможно, т.к. я совершил следующие ошибки:
У меня была фиксированная верстка. Если бы я верстал резиной, размер экрана не имел бы для меня значения.
Управление было завязано на API пульта.
По-нормальному, API пульта должно было быть только одним из возможных вариантов управления. Сейчас я использую универсальный модуль, который предоставляет пользователю сразу несколько вариантов управления, от клавиатуры — до touch интерфейса, а на выходе публикует универсальные события: left, right и т.д.

Если ваше приложение состоит из большого числа модулей, то, возможно, у вас имеется большое количество таймеров. Эта проблема особенно актуальна для игровых движков, т.к. они могут иметь в своем составе довольно много независимых модулей и объектов с таймерами. Такая ситуация приводит к тому, чтобы начать упорядочивать их работу. Оптимизация состоит из трех ступеней:
Один таймер на один модуль.
Один таймер на все модули.

Если вам интересно, как создают уровни нормальные мужики в нормальных проектах, почитайте следующего автора:
Дизайн уровней. Теория и практика
Михаил Кадиков
http://pro.level-design.ru

При написании сложной архитектуры на JavaScript вам очень часто предстоит делать выбор между сильными тормозами в начале либо мелкими тормозами позднее. Выбор следует делать исключительно путем проб и ошибок. Для каждого продукта — он свой. Но если у вас небольшое приложение и мало ресурсов, тогда смело загружайте их при старте. Как правило, небольшая задержка на старте остается незамеченной пользователями благодаря анимированной заставке (сплеш-скрин).

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

Оставляйте зазор минимум в 1px между картинками на спрайте, т.к. на мобильниках при применении CSS-анимации графика может немного поплыть и края спрайта будут либо размазаны, либо будет видна небольшая полоска от соседней картинки на спрайте.