С момента написания прошлого отчёта прошло около недели и должен сказать, что она не прошла зря. Но обо всём по порядку.
То что я описывал в отчётах и показывал в видео ранее, это была разработка технологий которые буду использоваться в игре. Это и физика и логика мира и т.д. Но это только технологии, а о какойто игре говорить язык не поворачивается. Несмотря на матричную простоту мира и относительно простую логику работы с ней, бомбермен это не тетрис и не змейка, эта игра имеет все признаки "большой" игры. О чём я говорю? Дело в том, что без объектно ориентированного программирования очень тяжело описывать игровые объекты. Это персонажи и бомбы. Конечно можно обойтись и простыми переменными и даже записями record, но это очень сложно. Особенно если есть много похожих объектов, напр. персонажи.
И поэтому прошлось придумывать каркас игры и всех её игровых объектов. Я чесно говоря думал, что без ООП всё и так получится, но это усложнило мне код и жизнь.
И так начнём с мира и его объектов. Мир это матрица, а персонаж это объект который может перемещаться между ячеек матрици. Значит свойство положения такого объекта это число с запятой. А всё остальные игровые объекты могут находится только по целочисленным положениям. Это практически все объекты кроме персонажей. Каждый персонаж должен иметь свой контроллер движения, который я описывал раннее. И управление персонажем сведётся к нажатию виртуальных клавиш направления движения. Я не зря сказал "виртуальных", так как таким персонажем может управлять как человек, так и ИИ. Поэтому контроллер находится в теле персонажа. Значит без классов уже не обойтись. Можно и записью всё это сделать, но это громоздко будет. Теперь мы сделали фактически фабрику персонажей. Которая может выпускать достаточное колличество персонажей. Но это ещё не всё. Сам персонаж это не только его тело которым можно "ходить", это ещё и тот кто этим телом управляет. Например главный герой игры, это не только тот человечек который бегает по ту сторону экрана. Это игрок и виртуальное тело ГГ. Вот они в двоём и являются одним персонажем, играющим свою роль в игре. А если телом будет управлять ИИ, то они вдвоём будут называться персонажем. Поэтому конструкция классов такова:
1. Сначала идёт "стандартный фундамент" персонажа. У которого будут такие свойства, которые есть у каждого разного персонажа. Напр. та же "хотьба", ходить могут все, поэтому фундамент перса в Бомбермене просто обязан иметь в себе физ. тело и контроллер движения, упрощающий управление им.
2. Соответствующая надстройка над фундаментом. Эта надстройка поможет хранить в себе ИИ. Тоесть можно не создавать отдельно кучу интелектов, кучу тел, а потом каждому интелекту раздавать по телу. А создать такой объект, который будет иметь ИИ в себе. Вы скажете, - а почему нельзя запихнуть ИИ в фундамент и не делать этой надстройки? Ответ прост, - ГГ или второму игроку в своём теле ИИ не нужен. Тоесть надстройка позволяет создавать похожие объекты но со своими отличиями, без которых они не могут играть свою роль в игре. Тоже самое касается и наличие бомб. Только бомбермены могут ставить бомбы, а все остальные персонажи - нет.
Ну с классами разобрались. Теперь о бомбах. Бомбы мучали и мучают меня довольно не слабо. Я начал писать логику для них дней пять назад и скажу, что даже сейчас они рботают не идеально. Все проблемы начались с того, что у персонажей количество бомб стало больше одной. Учёт подрыва соседней бомбы, усложнил логику просчёта (какие блоки всё же нада удалить в конце?) очень сильно. Это трудно описать словами, но я приведу один пример и на основе него будет видно как работает всё.
Одна бомба стоит слева, другая справа. Первая взорвётся - левая. У каждой бомбы есть четыре направления взрыва. Сначала проверяем по каждому направлению растояние до ближайшего блока (не важно разрушаемый или нет). Всё, мы знаем растояние, теперь проверяем, какой это блок и если нада убиваем его. Такой подход работал нормально в одиночку, но если две бомбы, то каждая из бомб (если даже и подорвёт соседнюю), всё равно в рамках одного цикла взрывается поочереди, а значит каждая из них заберёт по блоку на себя. А это не правильно, согласно игрового процесса. И тут мне пришла идея, отключать взрывные волны по направлению к возможной бомбе, и тогда гарантия того что бомбы не будут отнимать блоки друг у друга, была обеспечена. Но в коде это выглядит немного перевёрнуто, поэтому и трудно читаемо.
Теперь расскажу о рендере. Я конечно ещё в поиске финальной картинки, но сдвиг мира относительно дисплея меня привлекает. Сам мир к счастью работает не зависимо от рендера и это не даёт нам ни каких ограничений.
Рендер опирается на цифровой костяк игры поэтому для простой визуализации я увеличил один блок до размера 40x40 единиц. Тоесть один условный метр это 40 единиц. Я не сказал пикселей, потому что это значение опирается на переменную "Zoom" которая руководит маштабом всего . Рабочий зум при котором все спрайты равняются пикселям их текстуры, виден на видео в прошлом отчёте. Теперь хочу показать пока ещё огрызок игрушки на данном этапе. Смотреть желательно на полный экран, так как нужно правильное восприятие.
То что я описывал в отчётах и показывал в видео ранее, это была разработка технологий которые буду использоваться в игре. Это и физика и логика мира и т.д. Но это только технологии, а о какойто игре говорить язык не поворачивается. Несмотря на матричную простоту мира и относительно простую логику работы с ней, бомбермен это не тетрис и не змейка, эта игра имеет все признаки "большой" игры. О чём я говорю? Дело в том, что без объектно ориентированного программирования очень тяжело описывать игровые объекты. Это персонажи и бомбы. Конечно можно обойтись и простыми переменными и даже записями record, но это очень сложно. Особенно если есть много похожих объектов, напр. персонажи.
И поэтому прошлось придумывать каркас игры и всех её игровых объектов. Я чесно говоря думал, что без ООП всё и так получится, но это усложнило мне код и жизнь.
И так начнём с мира и его объектов. Мир это матрица, а персонаж это объект который может перемещаться между ячеек матрици. Значит свойство положения такого объекта это число с запятой. А всё остальные игровые объекты могут находится только по целочисленным положениям. Это практически все объекты кроме персонажей. Каждый персонаж должен иметь свой контроллер движения, который я описывал раннее. И управление персонажем сведётся к нажатию виртуальных клавиш направления движения. Я не зря сказал "виртуальных", так как таким персонажем может управлять как человек, так и ИИ. Поэтому контроллер находится в теле персонажа. Значит без классов уже не обойтись. Можно и записью всё это сделать, но это громоздко будет. Теперь мы сделали фактически фабрику персонажей. Которая может выпускать достаточное колличество персонажей. Но это ещё не всё. Сам персонаж это не только его тело которым можно "ходить", это ещё и тот кто этим телом управляет. Например главный герой игры, это не только тот человечек который бегает по ту сторону экрана. Это игрок и виртуальное тело ГГ. Вот они в двоём и являются одним персонажем, играющим свою роль в игре. А если телом будет управлять ИИ, то они вдвоём будут называться персонажем. Поэтому конструкция классов такова:
1. Сначала идёт "стандартный фундамент" персонажа. У которого будут такие свойства, которые есть у каждого разного персонажа. Напр. та же "хотьба", ходить могут все, поэтому фундамент перса в Бомбермене просто обязан иметь в себе физ. тело и контроллер движения, упрощающий управление им.
2. Соответствующая надстройка над фундаментом. Эта надстройка поможет хранить в себе ИИ. Тоесть можно не создавать отдельно кучу интелектов, кучу тел, а потом каждому интелекту раздавать по телу. А создать такой объект, который будет иметь ИИ в себе. Вы скажете, - а почему нельзя запихнуть ИИ в фундамент и не делать этой надстройки? Ответ прост, - ГГ или второму игроку в своём теле ИИ не нужен. Тоесть надстройка позволяет создавать похожие объекты но со своими отличиями, без которых они не могут играть свою роль в игре. Тоже самое касается и наличие бомб. Только бомбермены могут ставить бомбы, а все остальные персонажи - нет.
Ну с классами разобрались. Теперь о бомбах. Бомбы мучали и мучают меня довольно не слабо. Я начал писать логику для них дней пять назад и скажу, что даже сейчас они рботают не идеально. Все проблемы начались с того, что у персонажей количество бомб стало больше одной. Учёт подрыва соседней бомбы, усложнил логику просчёта (какие блоки всё же нада удалить в конце?) очень сильно. Это трудно описать словами, но я приведу один пример и на основе него будет видно как работает всё.
Одна бомба стоит слева, другая справа. Первая взорвётся - левая. У каждой бомбы есть четыре направления взрыва. Сначала проверяем по каждому направлению растояние до ближайшего блока (не важно разрушаемый или нет). Всё, мы знаем растояние, теперь проверяем, какой это блок и если нада убиваем его. Такой подход работал нормально в одиночку, но если две бомбы, то каждая из бомб (если даже и подорвёт соседнюю), всё равно в рамках одного цикла взрывается поочереди, а значит каждая из них заберёт по блоку на себя. А это не правильно, согласно игрового процесса. И тут мне пришла идея, отключать взрывные волны по направлению к возможной бомбе, и тогда гарантия того что бомбы не будут отнимать блоки друг у друга, была обеспечена. Но в коде это выглядит немного перевёрнуто, поэтому и трудно читаемо.
Теперь расскажу о рендере. Я конечно ещё в поиске финальной картинки, но сдвиг мира относительно дисплея меня привлекает. Сам мир к счастью работает не зависимо от рендера и это не даёт нам ни каких ограничений.
Рендер опирается на цифровой костяк игры поэтому для простой визуализации я увеличил один блок до размера 40x40 единиц. Тоесть один условный метр это 40 единиц. Я не сказал пикселей, потому что это значение опирается на переменную "Zoom" которая руководит маштабом всего . Рабочий зум при котором все спрайты равняются пикселям их текстуры, виден на видео в прошлом отчёте. Теперь хочу показать пока ещё огрызок игрушки на данном этапе. Смотреть желательно на полный экран, так как нужно правильное восприятие.
Класс! Персонаж классный! И в целом приятный глазу арт. С нетерпением жду возможности побегать
ОтветитьУдалитьСпасибо ЗДМаксу. Мощный инструмент визуализации и моделирования. Правда для спрайтовой анимации нехватает автоматической запаковки кадров в длинную текстуру, ну как на киноплёнке. Всё приходится делать руками, а это не такая уж и приятная работа. Для примера, у ГГ 8 текстур по 10 кадров в каждой. Тоесть мне для одного персонажа пришлось 80 кадров ставить на место вручную. И это ещё без вспомогательных анимаций, смерти и т.д.
ОтветитьУдалитьЧесно говоря не уверен был, что такая сырая картинка, может порадовать. Хотя с точки зрения комфорта наблюдения, контрастность всего в целом, подчеркнула игровой процесс. Так, что это видимо одно из условий для художников. Ну а я, только учусь=).