Comments 8
Последний абзац «не усложняйте себе жизнь» — остальное вода. Без обид, иногда код пишется не только что бы «не заморачивался за фон», «не запаривался за красивости», «не успел доделать», а что бы потом спокойно без сложностей менять именно игровую механику, красоты и красивости лучше заложить сразу, не рисовать конечно, но заложить стоит. Все это мое личное мнение и оно может не совпадать с мнением бесконечного числа людей.
ООП и «без сложностей менять» — это уже давно не смешная шутка.
при всем моем уважении (а я знаю вас уже много лет, с 2005 вроде), мое персональное мнение основанное на собственном опыте — ООП удобнее и эффективнее в больших проектах
Это было бы хорошим комментарием к посту разработчиков, но как отдельный пост смотрится несколько неуместно.
Спасибо, что вы обратили внимание на hahaton и написали даже пост и свою «мини игру». Критика и вправду нам очень ценна.
Нас действительно много: 7 человек. Но пишут код только двое (я и Максим). Если бы все 7 программировали, то да, объем написанного за выходные удручал бы. Максим пробует JS впервые. Я на JS прототипы раньше не использовал и не знал, как. Сталкиваемся с тем, что некоторые вещи не понимаем, приходится искать, читать, иногда что-то подсказывают в чате.
Далее поговорим по нашему коду. Жаль, что вы не комментируете что-то конкретное, судя по вашему первому топику опыт с JS у вас не малый.
Первое, что встречает человек, зашедший в папку game на гитхабе — это крутой файл BaseScene.js. Не побоюсь привести его длинный листинг:
Это — плохой пример. Файл я делал на всякий случай, когда еще не очень представлял структуру того, что будет. Хотя и сейчас остается вероятность того, что для игровых сцен понадобится добавить какие-то методы с общей реализацией.
К счастью, остальные файлы, в основном, более ёмкие. Пройдемся по порядку:
Там еще есть несколько файлов по папкам, но все они в разработке. В некоторые я пока не смотрел- их пишет Максим. Файл с игроком — там уже есть «крутая» физика управления, которая позволит нам физически достоверно толкать игрока пулями, монстрами. Притягивать к появляющимся черным дырам на карте и т.п. Сейчас буду писать туда физику отскока пули от щита с помощью функций из functions.js.
В целом, мне кажется, что мы не слишком и разбиваем все на файлы и классы. Если чуть углубиться, становится ясно, что все они нужны, именно это я и хотел сейчас показать, надеюсь, удалось. Мы не стремимся и идеальному ООП. Просто, мы уже в своем время наговнокодили оочень много (например я на Delphi, или на том же JS — вот мой паровозик на HTML5). Теперь хочется написать то, что не стыдно показать знающим людям изнутри и то, что легко сопровождается. Мне кажется, пока, мы выдерживаем золотую середину: то, что вы видите сейчас на ХАХАтоне в текущей версии — это — вершина айсберга. Внутри там уже есть большой задел под будущий функционал.
Простите, что там много букв, но у вас тоже не мало. Привет от нашей команды :-)
Нас действительно много: 7 человек. Но пишут код только двое (я и Максим). Если бы все 7 программировали, то да, объем написанного за выходные удручал бы. Максим пробует JS впервые. Я на JS прототипы раньше не использовал и не знал, как. Сталкиваемся с тем, что некоторые вещи не понимаем, приходится искать, читать, иногда что-то подсказывают в чате.
Далее поговорим по нашему коду. Жаль, что вы не комментируете что-то конкретное, судя по вашему первому топику опыт с JS у вас не малый.
Первое, что встречает человек, зашедший в папку game на гитхабе — это крутой файл BaseScene.js. Не побоюсь привести его длинный листинг:
function BaseScene(){ }
Это — плохой пример. Файл я делал на всякий случай, когда еще не очень представлял структуру того, что будет. Хотя и сейчас остается вероятность того, что для игровых сцен понадобится добавить какие-то методы с общей реализацией.
К счастью, остальные файлы, в основном, более ёмкие. Пройдемся по порядку:
- Файл Camera.js. В нем реализовано «умное» слежение за героем игры. Скролл фона за игроком, а когда он у края уровня — скролл останавливается. Можно ли обойтись без класса? Можно. Написать две функции и вызывать их на каждом кадре, завести глобальные переменные lookAtX, lookAtY. Но это будет тоже самое, только неаккуратно. Можно ли вообще без функций тут обойтись? Можно, но тогда в методе — отрисовке кадра будет весь этот код, что тоже не сильно упрощает.
- Файлы сцен: Credits, Menu, Game. Список сцен будет расширяться. Если вам не нужно переключение а-ля из меню в игру, из игры в настройки и обратно, то сцены вам не нужны. Иначе, как обойтись без них?
- Файл Global.js. Существует для быстрого доступа ко всяким переменным, чтобы не плодить глобальных. Есть мнение, что от них от всех можно было избавиться, чтобы получилось грамотное ООП, но это уже слишком :-)
- MenuButton.js — честно украденный из примеров к движку. Немного изменен, добавлены твины для кнопок.
- Preload.js. Куда без него? Это — надстройка над соответствующим классом из движка. Производит загрузку необходимых картинок, хранит в удобном виде в ассоциативном массиве, изменяет прогресс бар при загрузке игры. В файле не все гладко, будем еще допиливать, но в целом — без него ведь не обойтись?
- SceneController.js. Менеджер сцен. Хранит в себе все сцены, умеет их переключать одним методом.
- CutSprite.js — просто для тестов. Умеет взрывать спрайт с помощью png развертки. Вероятно его удалим, если не понадобится разрывать спрайты.
- Extend.js Хранит одну функцию, позволяющую наследовать классы. Пока не придумали, куда её запихнуть в другое место. Похожий файл functions.js, содержит вспомогательные функции. Сейчас я в нем пишу кусок математики отскока пули от разных граней щита.
- Main.js — «точка входа». Инициализация всего и вся.
- Далее по папкам: BackGround.js. Крутой класс, который рисует крутой случайный фон лунной поверхности по куче файлов, которые так старательно делала Евгения — один из наших художников. Можно это сделать в main.js? Да, но какой тогда он будет по размерам?
Там еще есть несколько файлов по папкам, но все они в разработке. В некоторые я пока не смотрел- их пишет Максим. Файл с игроком — там уже есть «крутая» физика управления, которая позволит нам физически достоверно толкать игрока пулями, монстрами. Притягивать к появляющимся черным дырам на карте и т.п. Сейчас буду писать туда физику отскока пули от щита с помощью функций из functions.js.
В целом, мне кажется, что мы не слишком и разбиваем все на файлы и классы. Если чуть углубиться, становится ясно, что все они нужны, именно это я и хотел сейчас показать, надеюсь, удалось. Мы не стремимся и идеальному ООП. Просто, мы уже в своем время наговнокодили оочень много (например я на Delphi, или на том же JS — вот мой паровозик на HTML5). Теперь хочется написать то, что не стыдно показать знающим людям изнутри и то, что легко сопровождается. Мне кажется, пока, мы выдерживаем золотую середину: то, что вы видите сейчас на ХАХАтоне в текущей версии — это — вершина айсберга. Внутри там уже есть большой задел под будущий функционал.
Простите, что там много букв, но у вас тоже не мало. Привет от нашей команды :-)
Спасибо за такой подробный ответ. Думаю, этот комментарий можно выложить на гитхаб в readme к вашему проекту. Но я писал немного не про это. Естественно, при желании я бы разобрался во всех этих файлах и классах. И понятно, что они рано или поздно будут нужны. Я лишь написал своё видение подхода к разработке. Рефакторить, как вы сами сейчас признались, вам всё равно придется. И совсем не факт, что то, что появилось на текущем этапе, останется в будущем. Поэтому я позволил себе предложить немного другой подход — как можно быстрее увидеть результат — отрефакторить — усложнить — отрефакторить… и так далее. В любом случае, как писать код — это выбор лично каждого, зависящий от пути по которому человек пришел к этому. Желаю вашему проекту удачи, с удовольствием понаблюдаю за процессом дальше.
Sign up to leave a comment.
Мысли по процессу разработки игры REFLECT