Разработка стратегии в реальном времени

В данный момент пишу игру, если быть точнее пытаюсь ее написать, т.к. для меня это пока сложновато дается, жанр - стратегия в реальном времени, в игровом плане должно выйти что-то типо Starcraft'a. Прошу вашей помощи, возможно Вы писали что-нибудь типо этой или близко к данной теме, возможен C# и C++, может у Вас есть какие-то заброшенные наработки, если таковые имеются прошу скинуть их в данной теме или же в лс, это бы заметно облегчило мою работу. Буду очень благодарен.

Подсчет времени в реальном времениДобрый день, подскажи пожалуйста как нужно сделать что бы подсчитать количество часов. В первом.

Разработка на реальном устройстве?Приветствую! Столкнулся с такой проблемой при попытке разблокировать телефон инструкцией как.

График в реальном времениЗдравствуйте. Делаю сейчас лабораторную по програмированию, задача такая, чтобы выполнить.

Checkbox в реальном времениХочу сделать такую штуку, есть checkbox и edit (не активен); при нажатии на checkbox, edit.

Ссылок и наработок пока подкинуть не могу, но выскажу пару идей.

Скорее всего, чего-то слишком сложного не нужно. Достаточно пяток типов зданий и примерно столько же юнитов. Насчет проекции можно тоже не заморачиваться - вид строго сверху, размер картинки соответствует размеру объекта.

Структура игры - самая тривиальная. Есть класс игровой локации (я ее привык называть игровым полем), на ней располагаются экземпляры классов игровых объектов. Можно разбить поле на клетки, тогда каждый объект содержит информацию о том, какую форму он имеет (в простейшем случае, когда все прямоугольные - размер в клетках) и координаты "главной" клетки (центральной, верхнего левого угла или еще что), но тогда будет неудобно обращаться с юнитами (если клетки довольно крупные и каждый юнит занимает одну клетку, то будет жуткое столпотворение; если они меньше клетки, то с ними трудно работать). Так что можно просто приравнять размер клетки к одному пикселю и хранить в объектах их координаты и размеры в пикселях. Игровое поле может хранить объекты в виде коллекции (в плюсах я для этой цели предпочитаю std::deque - удобно добавлять новые, получать доступ в середину по индексу, но предполагается, что объекты не нужно слишком часто удалять).

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

Игровое поле само себя рисует - сначала рисует землю, потом пробегает по коллекциям игровых объектов (удобно хранить отдельно здания, отдельно юнитов, отдельно элементы ландшафта), заставляет их рисовать самих себя. Обычно вся карта не влезает на экран, поэтому рисуется только видимая часть - видимая часть земли и видимые объекты. При желании можно оптимизировать процесс, разбив карту на куски поменьше и относить объекты к тому куску, на котором он находится. Тогда придется проверять не все объекты.

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

Рисовать проще всего с помощью каких-нибудь картинок типа TBitmap из VCL (C++ Builder / Delphi) или QPicture из Qt.

Такие курсовые дают в Республике Беларусь, в г.Минске, в веселом университете БГУИР, если хочешь поступай и с тобой поделятся, даже сравнительно быстро, на втором курсе. Тему выбирал не сам, так распределил преподаватель, был конечно не большой выбор, но все примерно одно и то же: пошаговые стратегии, онлайн игра, RPG, экшен от первого лица и т.д.

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

Добавлено через 9 минут

Ссылок и наработок пока подкинуть не могу, но выскажу пару идей.

Скорее всего, чего-то слишком сложного не нужно. Достаточно пяток типов зданий и примерно столько же юнитов. Насчет проекции можно тоже не заморачиваться - вид строго сверху, размер картинки соответствует размеру объекта.

Структура игры - самая тривиальная. Есть класс игровой локации (я ее привык называть игровым полем), на ней располагаются экземпляры классов игровых объектов. Можно разбить поле на клетки, тогда каждый объект содержит информацию о том, какую форму он имеет (в простейшем случае, когда все прямоугольные - размер в клетках) и координаты "главной" клетки (центральной, верхнего левого угла или еще что), но тогда будет неудобно обращаться с юнитами (если клетки довольно крупные и каждый юнит занимает одну клетку, то будет жуткое столпотворение; если они меньше клетки, то с ними трудно работать). Так что можно просто приравнять размер клетки к одному пикселю и хранить в объектах их координаты и размеры в пикселях. Игровое поле может хранить объекты в виде коллекции (в плюсах я для этой цели предпочитаю std::deque - удобно добавлять новые, получать доступ в середину по индексу, но предполагается, что объекты не нужно слишком часто удалять).

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

Игровое поле само себя рисует - сначала рисует землю, потом пробегает по коллекциям игровых объектов (удобно хранить отдельно здания, отдельно юнитов, отдельно элементы ландшафта), заставляет их рисовать самих себя. Обычно вся карта не влезает на экран, поэтому рисуется только видимая часть - видимая часть земли и видимые объекты. При желании можно оптимизировать процесс, разбив карту на куски поменьше и относить объекты к тому куску, на котором он находится. Тогда придется проверять не все объекты.

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

Рисовать проще всего с помощью каких-нибудь картинок типа TBitmap из VCL (C++ Builder / Delphi) или QPicture из Qt.

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

Огромное спасибо за Ваш совет, все прочитал и учел, уже не так безнадежно смотрю на поставленную задачу. Но все таки возможно поподробнее о структуре игры? Я не знаю знаю с чего мне это все начать, написание самой игры и возможно есть какая-нибудь литература которая поможет мне именно в этой области, или статейки какие?

Ну а как по вашим словам, я понял, что начинать мне нужно с прорисовки карты, юнитов и строения, так?