@kiberlain

Как пишут игры на канвасе?

Интересно услышать от опытных разработчиков, как они пишут простые игры. Возьмем к примеру простейшую мини игру в жанре tower defence. Какое-то поле, стоит пушка, появляется враг, при его приближении пушка выпускает снаряд, снаряд летит, попадает во врага, у того отнимается здоровье. Интересует:
1) как вы графику подгружаете? прямо из картинок? можно как то из бинарного файла брать?
2) с чего начинаете написание программы? Какой то список из необходимых функций или даже классов создаёте, а потом в каждой пишете логику? Чем являются в вашей программе пушка, вылетающий снаряд и враг?
3) Насколько проще такого рода игрушки писать на фреймворках вроде phaser или можно не менее быстро написать и на pure javascript?

Вот такие детские вопросы... Надеюсь игроделы не станут сильно смеяться, а без иронии обстоятельно поведают о своём ежедневном процессе разработки :)
  • Вопрос задан
  • 388 просмотров
Пригласить эксперта
Ответы на вопрос 3
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Просто берёте и создаёте архитектуру вашего приложения (игры), читаете документацию канваса (или API фреймворка) и пишите.
Графика - тайл-мэп.
Объекты игры - классы.
Ответ написан
Комментировать
@JuniorNoobie
Сижу в поддержке, пишу мелкие проекты
Есть три подхода для создания игр, если ты новичок:
1) Это брать и делать. Не планируя далеко вперед, наступая на всевозможные грабли, преодолевая и себя и свой плохой код. Минусы очевидны. Плюсы: не нужно заморачиваться с теоретической базой, делаешь все тяп-ляп "лишь бы работало", но зато обрастаешь практическими знаниями как на дрожжах.
2) Читать методологическую литературу. Долго, муторно, упорно. Причем большинство годной литературы есть только на английском. Выписывать то, что тебе кажется пригодиться в разработке, написать какой-никакой план своих будущих действий. Минусы: это долго, это тяжело, ты забываешь то, что прочитал не так давно. В конечном случае все получится не так, как ты планировал. Плюсы: ты будешь на чужом опыте научен всевозможным граблям. Другое дело, что ты и не поймешь почему это грабли, т.к. практики маловато.
3) Найти опытную команду и вступить туда джуном. Причем обязательно в новый проект. Небольшой. Можешь даже ничего там не делать, кофе носить, но ты должен быть в курсе всего, что там происходит. Постоянно следить за изменениями, интересоваться почему это делают так, а не иначе и все в таком духе. Плюсы очевидны.

Ну и есть комбинированный подход, который чаще всего встречается на практике. Ты читаешь несколько книг, приступаешь к разработке, делаешь какой-никакой прототип, потом читаешь еще, интересуешься у более опытных ребят, что ты делаешь не так. Улучшаешь свою игру, рефакторишь. Итерация за итерацией, цикл за циклом, повторение за повторением...

А что касается непосредственного вопроса, судя по всему вы даже не знаете как устроены игровые студии и их разработка, что собой представляет игровой движок... Прочтите, для начала, книгу "Game Engine Architecture" Джейсона Грегори, чтобы иметь представление о главном инструменте в руках разработчика игр. Вот там описано что такое движок, из каких подсистем он обычно состоит, как это обычно реализуется и как с этим работают программисты и творцы игр.

И это техническая часть. По гейм дизайну там книжек на порядок больше, потому что геймплей всегда решает.
Ответ написан
Комментировать
t-alexashka
@t-alexashka
Сразу пишу legacy код
Прелесть фреймворков как раз и заключается в избавлении от рутины вроде предзагрузчиков, расчета физики, и генерации уровней на основе внешних данных (карты). Если вам принципиально надо все самому делать и изобретать свой велосипед - то да, дока по canvas вам в помощь. Если вы хотите сэкономить время - то phaser(3) и ему подобные движки.
Ответ написан
Комментировать
Ваш ответ на вопрос

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

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