Насколько сильно связывать объекты в игре?

[cyklop77]

Помогите пожалуйста разобраться в вопросе организации кода в простейшей игре. и в результате скажите:
1. правильный первый вариант
2. правильный второй вариант
3. оба варианта правильные и используются в зависимости от ситуации
4. давно уже существует паттерн %patternname% и с успехом используется в такой ситуации

Допустим есть 2D-ландшафт, над ним летит корабль игрока. Корабль может стрелять ракетами. 

Описываю первый вариант организации ООП-кода на js(в js контроллер и представление совмещены):
инициализация игры начинается с создания spaceView, который в свою очередь инициализирует: 
ландшафт,
корабль игрока

PlayerShipView - корабль игрока. Он может стрельнуть ракетой(PlayerRocketView). То есть объект корабля связан с объектом ракеты

Ракета может столкнуться с ландшафтом. То есть объект ракеты связан с объектом spaceView

В результате: 
Имеем 3 связанных объекта, но каждый из них содержит только свою функциональность(это плюс). 
Но если в программе придётся что-нибудь менять(например отключить кораблю игрока возможность стрелять ракетами), то вносить правки придётся в разных местах программы(это минус).
Есть несколько глобальных переменных(это минус) 

Описываю второй вариант организации ООП-кода на js(в js контроллер и представление совмещены):
инициализация игры начинается с создания spaceView, который в свою очередь инициализирует: 
ландшафт,
корабль игрока,
ракеты(есть нажата кнопка "огонь")
и вообще все остальные объекты

Таким образом: 
Если например игрок нажимает "огонь", то инициализация ракеты происходит в spaceView, а PlayerShipView вообще ничего не знает об объекте ракеты(это плюс).
Соответственно нет глобальных переменных(это плюс).
Но в spaceView содержится куча логики(всей игры, в котрой кроме корабля игрока и ракеты существует очень много других объектов).

Для наглядности я реализовал первый вариант здесь: https://github.com/zlodiak/space-1
В нём используются различные библиотечки типа backbone, underscore, но незнание их не мешает пониманию общей структуры программы

Не бейте(ногами), я знаю что вопрос для телепатов

Edited May 14, 2016 by cyklop77

[cat]

>в js контроллер и представление совмещены
backbone позволяет разделить представление и бизнеслогику.

По поводу основного вопроса: сильная связанность – плохо, слабая связанность – хорошо.
В идеале ни один из модулей не должен ничего знать о других модулях и зависеть от них.
Я думаю, что тут необходим промежуточный слой(медиатор).
Модули должны только публиковать события, а медиатор соответственно реагировать на них.

http://largescalejs.ru/the-mediator-pattern/

[nerv]

В 5/16/2016 в 06:20, cat сказал:

По поводу основного вопроса: сильная связанность – плохо, слабая связанность – хорошо.

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

[Николя223]

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

[cyklop77]

запутал я всех своими абстракциями, но сейчас всё пояснится

в книжке того же эдди османи "Разработка Backbone.js приложений (2014)" в главе "агрегаторы событий и посредники" рассказывается как раз об тех двух подходах, которые я описал в первом посте. и сама библиотека backbone там не при чём

я так понял, что в первом случае(который я описал в первом посте) совсем избежать связанности не получится. пример:

летит снаряд, он постоянно перебирает массив астероидов(то есть знает о существовании других объетов), и если сталкивается с астероидом, то генерирует событие, которое обрабатывается некоторым ядром(ядро только слушает подобно jquery-методу .on()). в результате например ядро заставляет астероид взорваться

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

 

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

 

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

 

ps:

написал всё это скорее для себя. чтобы отложилось))

Edited May 18, 2016 by cyklop77