Правильно ли построены структура и процесс разработки браузерной игры?

Question

[Анатолий К.]

В общем, планируется небольшая браузерная игра с мультиплеером и шлю.. плюшками =)

Входные данные:
За плечами есть опыт коммерческой разработки на C#. Отсюда, JS в его чистом виде с прототипно-ориентированным стилем не привлекает, более по душе синтаксис TypeScript. Ну, и в качестве IDE, соответственно, до боли знакомая Visual Studio Community.

Сам проект логически разбиваю на 3 дочерних проекта:
- клиентская часть (скорее всего в виде одностраничного приложения) - Backbone.JS
- серверная часть на сокетах - Node.JS
- игровой клиент (будет подгружаться клиентской частью, но для упрощения процесса разработки выношу отдельным проектом) - Phaser

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

Структуру проекта вижу примерно следующим образом:

Solution/
--libs/
----typings/
----node_modules/
--client/
----app/
------static/
------views/
------models/
------collections/
------app.ts
----index.html
--server/
--game/
----states/
----prefabs/
----app.ts

Где

• папка libs - все используемые проектами зависимости (решил не плодить таковую в каждом отдельном проекте).
  
• серверная часть будет частично заимствовать логику клиентской (точно пока структуру файлов набросать не могу)
  

Собственно, основной вопрос:
Мучает организация клиентской части: оставить, как есть, либо видоизменить следующим образом:

--client/
----app/
------modules/
--------demo-module/
----------static/
----------views/
----------models/
----------collections/
------app.ts
----index.html

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

Собственно, основной вопрос в структуре приложения и рациональности выбранных инструментов, подхода к реализации.

Ну, и конечно же:
Буду благодарен за аргументированную критику и советы

P. S::
Не хочу ASP.NET в качестве backend-а и про Angular знаю

Comments

[vasIvas]

Для меня она выглядит, как игра нарисованная на салфетке. Вот как Вы думаете крутая у меня игра? Она знаете какая? Есть кнопки старт и паузы и тип бегает и стреляет. ?

[Анатолий К.]

vasIvas: честно говоря, не улавливаю уровень сарказма, так как вся игровая логика лежит на плечах Phaser и Node.JS, а Backbone в данном случае нужен для вывода статистики, данных, пополнения счета и прочих социальных плюшек, которые не логично засовывать в игровой клиент.
А тут уже не важно, какая игра и что она делает - предложенная архитектура не изменится от того, будет ли это action или аркада, с кнопками или без.

Суть в том, что вопросы вызывает, в основном, клиентская часть. Можно, конечно же, делать на голом HTML5 + jQuery, но с ростом проекта его всё сложнее будет поддерживать

Answer 1

[v- smerti]

1. на серверной стороне делаем Api (для всего где вебсокеты не обязательны) + веб сокеты. Я бы вам посоветовал компилируемый язык если игра в планах будет иметь 100к+ (к примеру чудесный язык golang)

2. Phaser заменяем на набор js классов которые работают с вашим API
3. Если нужен "быстрый интерфейс" то юзаем libcanvas + nativeJS (на крайний случай jquery) + учимся использовать опен сорс.

4. Структура папок особо не важна.

А вообще одностраничник за вечер можно сделать. А все анимации делаем с помощью css или libcanvas

Comments

[Vladislav]

Владимир Грабко а это сильно писать серер для мультиплеера на java? или на nodejs?

[Vladislav]

Vladislav: сильно плохо ?

[Анатолий К.]

1. Для HighLoad-a не важно, компилируемый ли язык или нет. К тому же, тут весь упор на одном ЯП всё реализовать.
Да, для различных не интерактивных действий будет RESTful API.
2. Зачем, если Phaser это тоже умеет?
4. Спорный момент, так как имелся опыт работы с плохо спроектированным проектом, разросшимся до ужасающего количества кода.

Под одностраничником не landing имеется ввиду, а single page application. То есть, динамическая подгрузка страниц

[v- smerti]

Анатолий К.: мда.... сравните производительность компилируемых и скриптовых ЯП

[v- smerti]

Vladislav: НЕТ. если использовать микросервисную архитектуру то даже серверную часть можно писать на 10500 яп))
В любом случае клиенту не чего не известно о сервере, а серверу не чего не известно о клиенте) В этом и профит от API

[v- smerti]

Анатолий К.: www.hostingadvice.com/blog/nodejs-vs-golang
habrahabr.ru/post/228751

[Vladislav]

Владимир Грабко: я имел виду по производительности. Плохо ли писать сервер на java

[v- smerti]

Vladislav: честно говоря не знаю.

Answer 2

[Елизавета Борисова]

Структура примерно стандартная, клиент можно разбить на модули. Phaser не вполне профессиональный инструмент, но вполне возможен. По поводу backbone - зависит от объема клиентской логики, и планируемой поддержки, и также от размера команды. Чем больше логики и меньше команда, тем хуже будет вести себя BB (тогда надо выбрать фреймворк, Angular - не единственное решение). Структура папок не столь важна, в процессе рефакторинга поправите.

Владимир Грабко : Phaser не для API, а для рендеринга, физики итп