Курсы создания компьютерных игр на C/C++ ( Часть 8 )
Для самых-самых начинающих программистов :] Часть 7.2 - http://pikabu.ru/story/_3476269
![Курсы создания компьютерных игр на C/C++ ( Часть 8 ) Для самых-самых начинающих программистов :] Часть 7.2 - <a href="http://pikabu.ru/story/kursyi_sozdaniya_kompyuternyikh_igr_na_cc__chast_72__3476269">http://pikabu.ru/story/_3476269</a>](https://cs5.pikabu.ru/post_img/big/2015/07/24/11/1437765485_1043627964.jpg)
Привет, извини за долгое отсутствие, пару месяцев занят был и что-то забыл про эти уроки. Теперь пора вернутся и делать игры. Так вот, собественно, у меня возник вопрос по поводу реализации классов в этой игре.
Ты сделал класс Game для реализации всей игры, но есть ли в этом смысл, если объект этого класса будет всего один? Не проще ли разбить игру на несколько более мелких классов, чтобы уже на каждый класс было больше одного объекта. Например, класс для уровня, класс для врага и т.п.
раскрыть ветку (75)
Смысл в правильной архитектуре. :) Классов должно быть столько, сколько существует сложных отдельных модульных задач :) Ну и я приверженец древовидной архитектуры с главным корневым классом-объектом( Как Game в данном случае ). Остальные объекты должны находится внутри Game, а в них уже могут быть свои объекты, ну и так далее :)
В этом уроке происходит только ознакомление с классами, поэтому тут используется такая упрощенная архитектура из нескольких классов :)
раскрыть ветку (66)
Можно тебя совета попросить, а то у меня мелкий баг появился, а код я пишу сам, стараясь в твой не смотреть. Можешь словами описать то, как у тебя перемещаются противники вбок. Ну сам процесс по шагам. Вот у меня просто есть специальный класс для противников. Я создал массив из объектов этого класса. Так вот, чтобы каждый противник двинулся, я создал функцию, которая циклом перебирает каждый объект и двигает его (с помощью метода класса) вбок на определенное расстояние. Движение происходит так: если он двигался в своей клетке - просто меняем координату. Если он двинулся в другую клетку, то мы ставим пробел на то место где он был, меняем координату, отрисовываем его в новой координате.
В принципе, все работает, я даже сделал нормальную стрельбу и противники уничтожаются, но есть мелкий баг. Иногда при стрельбе попадаются противники, которым насрать на снаряды, которые попадают в них. Они их как будто проглатывают их. Это происходит буквально долю секунды и как только этот противник перемещается (вбок или вниз), то эта "неуязвимость" пропадает. Мелочь, но довольно досадная. И поймать ее очень сложно.
Я думаю это связано с кривым перемещением.
раскрыть ветку (65)
Во-первых отрисовка в клетки не должна влиять на позицию объектов, просто должно происходить отрезание дробной части координат для получения row и column :)
Во-вторых лучше посмотреть как это реализовано у меня, ибо какой смысл тогда в уроках? :)
раскрыть ветку (64)
Нет, уроки то я читаю. Теория нужна. Но вот как реализовать саму игру пытаюсь сам. Потому что иначе это будет просто бездумное списывание.
По поводу перемещения. Как оно происходит у меня прямо по шагам:
1. Высчитываю новую позицию противника (float).
2. Проверяю перешел ли он в новую клетку (if ((int)NewPosition_X == Position_X))
3. Если да, то просто ему прописываю новую координату.
4. Если нет, то тут идет несколько действий:
5. Отрисовываю пробел на старой позиции противника
6. В схему уровня (которая двухмерный массив) ставлю пробел в клетку старой позиции
7. Прописываю новую координату (точно также как в п.3)
8. На новой позиции отрисовываю противника.
9. В схему уровня ставлю значок противника в клетку новой позиции
Так вот у меня вопрос. Так ли я все делаю. Оно работает, но тот баг не дает мне покоя. Если они стоят, то он не возникает, но как они двигаются, то иногда проскакивает эта временная "неуязвимость".
раскрыть ветку (63)
Ну пробел точно не нужно рисовать руками, еще с прошлой части это автоматически делает система рендера :) Как и руками не нужно рисовать вообще никакие значки, они автоматически должны рисоваться через вызовы render для GameObject.
раскрыть ветку (62)
Ну я не руками рисую. Вызываю рендерную функцию, которая рисует. Ну функция, которая принимает координаты, символ, цвет символа и цвет фона. Вот с ее помощью я ставлю пробелы и символ противника, где нужно. Это так должно делаться или я чего-то не понимаю?
Я решил проблему. Вот какая причина была. Вот представь летит снаряд, а сбоку в него приходит противник. Они же ходят вбок, поэтому и могут зацепить летящий рядом снаряд. А такая ситуация у меня не обрабатывалась и вызывала непредвиденные последствия.
Правда появилась другая беда, если долго стрелять, то все противники начинают дергаться. Но это я решу.
Все, проблему окончательно решил и у меня возник к тебе вопрос. Что должно происходить с противником, когда его убили. У меня есть метод в классе, который этим занимается. Так вот он обнуляет ХП и отрисовывает на месте противника пробел, и выставляет координаты противнику куда подальше (у меня эти координаты находятся за полем игры, куда никто не заходит). Это нормально, что я так делаю или это как-то можно более грамотно реализовать?
раскрыть ветку (59)
раскрыть ветку (58)
раскрыть ветку (57)
раскрыть ветку (56)
Все, разобрался. То есть мы в начале создаем массив указателей. Потом туда закидываем динамически выделенный указатель на объект. И дальше на протяжении программы работаем с объектом только через указатель, так?
раскрыть ветку (55)
раскрыть ветку (54)
Переделал программу так как ты мне подсказал с небольшим отличием. Все работает, спасибо больше. Самое главное, что я теперь понимаю как это делается без всяких костылей.
У меня вопрос. Можно ли каким то образом сделать массив из функций? Просто перед каждым уровнем надо сделать описание, а оно же разным будет и чтобы не пользоваться switch, можно было бы просто вызывать функции в зависимости от номера уровня. Я где-то читал, что можно сделать указатель на функцию, но больше этого ничего не помню. Подскажи, пожалуйста, как тут удобнее сделать.
раскрыть ветку (38)
void Function1()
{
}
void Function2()
{
}
typedef void (*FunctionRef)();
int main()
{
FunctionRef pointer1 = &Function1;
FunctionRef pointer2 = &Function2;
std::vector< FunctionRef > pointers;
pointers.push_back( pointer1 );
pointers.push_back( pointer2 );
(*pointers[0])();
return 0;
}
раскрыть ветку (37)
Я почти понял. Это контейнер из STL. Мы создаем ссылки на функции и закидываем их в контейнер. Но я не понял вот эту строчку:
typedef void (*FunctionRef)();
И соответственно, что за тип FunctionRef. И смысл последней строчки:
(*pointers[0])();
Что мы с помощью этого делаем?
раскрыть ветку (36)
typedef void (*FunctionRef)(); - объявлем свой тип данных FunctionRef, который является указателем на функцию возвращающую void и не принимающую аргументов.
раскрыть ветку (35)
А, все понял, спасибо. А почему мы обязательно создаем ссылки на функцию. Можно ли сделать указатель на функцию и создать просто массив таких указателей вместо контейнера?
раскрыть ветку (34)
Это и есть указатель :)
Просто "FunctionRef pointer" писать приятнее, чем "void (*pointer)()";
раскрыть ветку (33)
раскрыть ветку (32)
раскрыть ветку (31)
А, точно, совсем забыл. Спасибо за разъяснение. Вместо контейнера можно обычным массивом воспользоваться?
раскрыть ветку (30)
раскрыть ветку (29)
раскрыть ветку (28)
раскрыть ветку (27)
Я закончил. Подошел ответственно. Сделал 10 уровней. 10 различных противников, 5 бонусов. Полировал от багов пару дней. Вроде таких явных уже не осталось. Посмотри, пожалуйста.
https://wdfiles.ru/901q
раскрыть ветку (25)
Огромный плюс за старания ))) К сожалению уровни довольно долгие, поэтому пока на работе особо поиграть не могу :) Выглядит круто ))
раскрыть ветку (24)
Спасибо) У меня тут вопрос возник по поводу заголовочных файлов и файлов исходного. Как правильно все это организовать. Вот у меня для персонажа, для мобов и для снарядов отдельные классы. И соответственно, отдельные заголовочные файлы, где я написал класс, и написал все его методы, также в этих заголовочных файлах содержатся дополнительные функции, которые используются в main. То есть по сути у меня есть заголовочный файл Mob.h и всем все по мобам. Стоит ли так вообще делать?
Или лучше создать файл исходного кода, в нем определить класс, расписать методы и функции, а потом создать заголовочный файл заголовочного кода, где будут лишь прототипы?
Просто во время создания игры сталкивался с такой проблемой, что допустим, чтобы нормально работали функции связанные обработкой выстрелов нужно к нему подключить файл с мобами, файл с персонажем, файл еще с чем-то. А например, при работе с файлом персонажа нужно было подключить файл с мобами. В итоге получалась неработающая каша. Вот как бы этого избежать и структурировать все части кода?
раскрыть ветку (23)
Типы (классы) должны определяться только в хэдерах (заголовочных файлах), а методы по возможности (шаблонов это не касается) - определяться файлах исходного кода.
Нужно следить, чтобы классы не содержали друг друга (что антилогично и не скомпилируется). Если же необходимо обращаться к методам друг друга, нужно помещать ссылки или указатели. А перед типами предварительно объявлять зависимый тип (Forward declaration):
// ------ SomeType.h ------------------
#pragma once
class AnotherType; // Forward declaration
class SomeType
{
public:
SomeType(AnotherType *dependency) : _dependency(dependency)
{...}
AnotherType *_dependency;private:
};
// ------ AnotherType.h ------------------
#pragma once
class SomeType; // Forward declaration
class AnotherType
{
public:
AnotherType(SomeType *dependency) : _dependency(dependency)
{...}
private:
SomeType *_dependency;
};
раскрыть ветку (22)
Спасибо, не знал, что методы у класса можно отдельно прописывать.
А вот допустим функции, которые используют данные класса (не методы, а отдельные функции) тоже прописывать в файлах исходного кода, и просто оставлять прототип в заголовочном файле?
И еще вопрос. Если у меня в методе одного класса нужно использовать метод другого, то что нужно сделать? Использовать указатель или ссылку, чтобы просто передать переменную одного класса в метод другого?
раскрыть ветку (21)
Если функции не используются нигде, кроме этого файла, то выносить их в хэдер не обязательно. Вообще, туда выносят объявления того, что хотят шарить в разных местах. Кстати, если в классе у вас только указатели или ссылки на тип, то include для него тоже желательно уносить в cpp-файл, а вместо него оставлять forward decl'ы, как я показывал выше.
Если у меня в методе одного класса нужно использовать метод другого, то что нужно сделать? Использовать указатель или ссылку, чтобы просто передать переменную одного класса в метод другого?
Зависит от того, что вам нужно. Если вы делаете ссылку или указатель, то это вы как бы внедряете зависимость, через ссылку/указатель у вашего экземпляра класса будет ниточка-связь с экземпляром другого типа (который хранится отдельно).
Если же вы просто делаете экземпляр другого типа членом вашего, то он как бы "врастает" в него и физически располагается внутри (похоже на приватное наследование).
Тут, кстати, близко к этому всему лежит принцип внедрения зависимостей (Dependency Injection), следование которому позволяет уменьшить зависимость типа друг от друга и легко дробить программу на модули, разделяя сферы ответственности. Что в последствии поможет легче разрабатывать, покрывать код юнит-тестами и даже следовать TDD...но это всё у вас впереди =)
раскрыть ветку (20)
Спасибо за советы. Буду в будущем стараться как-то делать так, чтобы у меня не было каши в подключаемых файлах. А то бывает нелепо, когда нужно подключить второй файл в первый, а потом первый во второй.
Вот еще один вопрос возник по той же тематике. Пилю я игру уже по следующему уроку. Там у меня есть заголвочный файл для снарядов, которые выстреливают игрок и мобы. В нем описан класса снаряда. Его методы описаны в файле исходного кода. Все гладко.
Но где создавать массив указателей, где будут хранится указатели на объекты этого класса?
Если создать в файле исходного кода, то пользоваться этим массивом в других файлах будет нельзя. Если создать в заголовочном, то будет выдавать ошибку из-за многократного определения.
Мне помогло только то, что я определил этот массив как static. Но правильно ли это?
раскрыть ветку (18)
Неправильно :) Массив указателей на объекты должен быть членом класса положенному ему по архитектуре, например Game :)
раскрыть ветку (17)
То есть, если у меня нет класса, который описывает всю игру, то по другому мне уже не сделать?
раскрыть ветку (16)
Ну я не сказал, что обязательно всю игру :) Просто принцип Инкапсуляции подразумевает, что всё должно быть в соответствующих контейнерах :)
раскрыть ветку (15)
Нет, я не про это. Просто проблему с массивом указателей по другому не решить? Ну, не создавай большой класс Game.
раскрыть ветку (14)
Ну я про то, что он не в воздухе должен висеть типа
static GameObject* s_globalObjects[256];
А аккуратно лежат внутри какого-нибудь класса:
GameObject* m_objects[256];
P.S. Работать то будут оба варианта, но второй - правильный с точки зрения архитектуры.
раскрыть ветку (13)
Проблема в том, что даже первый у меня не работает, потому что лежит в заголовочном файле рядом с определением класса, и поэтому выдает ошибку, что массив несколько раз определяется.
раскрыть ветку (12)
раскрыть ветку (11)
Ох, это сложно. Но есть очень похожая ошибка, и если с ней разобраться то и та не будет проблемой. Касается она заголовочного файла со всякими константами и прочими переменными, которые используются по всей программе. Если это константа, то проблем нет. Но если это переменная, то как раз вылезает ошибка о множественном определении, потому что этот заголовочный файл встроен почти во все другие файлы программы.
Просто если я ставлю static на таких переменных (в прошлой игре так и делал и это работало), то в этой это вызывает обнуление этих переменных когда не надо.
Как вообще должны быть организованны эти переменные и константы? Где их хранить и как использовать?
раскрыть ветку (10)
Константы - можно глобально, можно в классах, по необходимости :)
Переменные - желательно внутри классов, глобальные - только по острой необходимости или для отладки
раскрыть ветку (9)
Вот смотри. Конкретный пример. Вот есть массив указателей на объект, в частности на выстрелы. И вот наш персонаж стреляет. Значит должен создаваться объект и его адрес должен передаваться в этот массив, а точнее в элемент массив с каким-то номером. Вот как у меня определяется этот номер. Существует глобальная переменная, которая по началу равна нулю. Персонаж делает первый выстрел и в нулевом элементе массива теперь хранится адрес о первом выстреле. После этого эта переменная увеличивается на один, чтобы следующий выстрел хранился уже в первом элементе массива.
Так вот эта переменная, по сути, является глобальной. И как я понял, у тебя в программе такие переменные являются членами класса Game, да?
раскрыть ветку (8)
раскрыть ветку (7)
Все, понял, спасибо. Завтра буду переписывать код так, чтобы у меня был один большой класс Game. И у меня опять вопрос)
У меня есть большой класс Game. Соответственно он должен содержать всякие другие классы помельче. Точнее объекты этих классов. Это значит, что нужно в отдельных файлах, эти классы расписать и подключить эти файлы потом к файлу, где мы описываем класс Game. Но проблема в том, чтобы описать эти мелкие классы, понадобятся переменные из большого класса. Что делать в таком случае?
раскрыть ветку (6)
Зачем? Классы нужно разбивать так, чтобы они по-максимуму были самодостаточными и независимыми. Если что-то нужно для настройки, то это можно передать в конструктор при создании.
раскрыть ветку (5)
Ну вот смотри, если вернуться к прошлому конкретному примеру, где ты сказал, что эта переменная должна хранится в классе Game. Но ведь эта переменная должна использоваться в более мелких классах. Например, в классе нашего персонажа, где и создаются выстрелы. То есть в файл, где описан класс нашего персонажа, нужно подключить файл, где описан класс Game, чтобы использовать эту переменную. Так?
раскрыть ветку (4)
Во все дочерние классы ты спокойно можешь передавать указатель на Game и использовать его там для обратной связи
раскрыть ветку (3)
А дочерний класс определяется также как обычный, просто объект этого класса является частью другого? Если да, то опиши, пожалуйста как использовать ссылку на родительский класс внутри дочернего. А то на словах я не очень понял.
раскрыть ветку (2)
А как грамотно выполнить в данной проге меню, продолжать ли в случае проигрыша или выходить?
Когда while(1) в main() добавил - то появились лаги.
раскрыть ветку (13)
Нужно ввести какой-то enum, который будет указывать текущее состояние игры и исходя из него в рендере рисовать либо саму игру, либо диалог с вопросом :) Ну и также исходя из него обрабатывать нажатия кнопок :)
раскрыть ветку (12)
Спасибо. Но это уже чисто для своего развития.
А по курсовому преподаватель сказал,
что никаких лишних "ххх.h" быть не должно.
Чисто MVC. То есть даже файл "level.h" частично
отправить во View, а частично в Model.
А именно, если я правильно понял, то сам уровень
из символов и пробелов (массив срок) в модель GameObject,
а уже преобразование этих символов в символы, которые
будут отображены в консоли - во View - то есть renderSystem...
раскрыть ветку (11)
раскрыть ветку (10)
Ну, кроме классов и их хедеров "все
конфиги должны быть подключены
через соответствующее наследование" (цитата).
К таковым и относится, например, "level.h".
Я же просто разделю его содержимое и кину в соответствующие места,
а точнее, в те, которые мне кажутся таковыми...
Что-то мне это MVC не слишком помогает, либо до сих пор
немного не понимаю, хотя в инете достаточно много инфы.
Буду рад увидеть у тебя пост по применению разных паттернов в C++!
Но более насущным является то, что преподавателя не устроила
инициализация в Contoller (а я принял за него класс Game)
void Game::initialize() должно производиться в каком-то доп.классе или же в самой Model (касс GameObject). Можешь что посоветовать, а то прям горит...
раскрыть ветку (8)
раскрыть ветку (7)
раскрыть ветку (6)
раскрыть ветку (5)
Так у меня не укладывается пока в голове, как это аргументировать, что в одном сегменте model or view or controller будет несколько классов.
И как эти классы должны быть друг с другом связаны.
Наследованием?
раскрыть ветку (4)
Да как угодно :)) MVC предполагает разделение на Модули, а не на Классы :)) А в Модуле может столько классов, сколько нужно
раскрыть ветку (3)
Хорошо, тогда к какому модулю мне отнести остатки от класса GameObject?
Совсем торможу уже - вроде все ок получается, и правда. Спасибо за пояснение.
раскрыть ветку (2)
остатки от класса GameObject
Что значит "остатки"? GameObject не нужно трогать, нужно просто чтоб все объекты теперь жили в классе Model, который бы в свою очередь находился в Controller
раскрыть ветку (1)
Итого: renderSystem - View
game - Controller, из которого перемещаем в model "лишний" код.
gameObject - относится к Model
model - тоже относится к Model
И надо добавить в game к инициализации объектов классов renderSystem и gameObject еще одну инициализацию - класса model.
Мотивация не та, но мысль правильная.То, что у класса лишь один экземпляр - это не плохо само по себе. Есть даже такой архитекрутный паттерн, как "Singleton". (Готов поспорить с желающими назвать его антипаттерном).
Модуляризацией приложения можно улучшить абстракцию элементов программы, что упростит поддержку (модернизацию) и позволит проводить их независимое тестирование.
Но чтобы понять, какие проблемы такой подход решает, их нужно встретить самостоятельно.
Ну и монолит пишется компактнее и лучше читается. Новичкам это важнее.
раскрыть ветку (7)
Я как Singleton использую в 99% случаев только главный корневой класс-объект :) И то, только с возвратом экземпляра без автоматического создания :) Это отличный паттерн при правильном использовании :)
раскрыть ветку (6)
А вот как бы данную прогу выполнить в стиле Model-View-Controller?
Не будет времени хоть приблизительно наметить где какие классы и методы будут располагаться при применении данного паттерна?
Вообще, надо подобие танчиков в MVC, но следующая прога слишком заморочена, так как после еще и придется разные алгоритмы и диаграммы по проге составлять.
Думаю, если уж с этой разберусь, то что-то немногим сложнее как по маслу пойдет.
раскрыть ветку (5)
Эээм... Ну это ИМХО уже слишком - наворачивать MVC для примитивного консольного приложения :) Оверинженеринг какой-то :)
раскрыть ветку (4)
Так курсовой проект задали реализовать игру именно в консоли, причем применяя MVC в обязательном порядке. Надеялся на Ваши уроки, думал, что поболее вникну в указатели и объекты - и справлюсь, но нет... Причем само описание паттерна вполне понятно, а вот на реализации встрял, не то что с нуля, а даже просто переделать мозгов не хватает.
раскрыть ветку (2)
Ну если так, то можно просто переименовать часть файлов и классов ))) RenderSystem превратится во View, Game в Controller, а level.h переименовать в model.h )))
раскрыть ветку (1)
Я совсем скатился в своих же глазах.
Не смог Вашу версию программы запустить.
https://pp.vk.me/c636626/v636626618/47075/I7zHxQ4Hl9w.jpg
В принципе, ведь модель - это исходное поле (двумерный массив) и все вычисления, вид - система рендера, а вот как это грамотно через контроллер пропустить...