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

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

Входные данные:
За плечами есть опыт коммерческой разработки на 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 знаю
  • Вопрос задан
  • 715 просмотров
Пригласить эксперта
Ответы на вопрос 2
@vGrabko99
html, css, js, php, golang, mysql
1. на серверной стороне делаем Api (для всего где вебсокеты не обязательны) + веб сокеты. Я бы вам посоветовал компилируемый язык если игра в планах будет иметь 100к+ (к примеру чудесный язык golang)

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

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

А вообще одностраничник за вечер можно сделать. А все анимации делаем с помощью css или libcanvas
Ответ написан
@Elizavetta
Matroid: gamedev/js-разработка
Структура примерно стандартная, клиент можно разбить на модули. Phaser не вполне профессиональный инструмент, но вполне возможен. По поводу backbone - зависит от объема клиентской логики, и планируемой поддержки, и также от размера команды. Чем больше логики и меньше команда, тем хуже будет вести себя BB (тогда надо выбрать фреймворк, Angular - не единственное решение). Структура папок не столь важна, в процессе рефакторинга поправите.

Владимир Грабко : Phaser не для API, а для рендеринга, физики итп
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы