Quote:у меня с паттернами вообще говоря практически шапочное знакомство

Да у меня тоже. Трогал только как раз абстрактную фабрику и визитора - ну и синглтон, естественно. Ещё "мост" пытался щупать, но уже позабыл всё. Ещё начинал читать книжку по ним - но там такая вода написана, что аж уши вянут

Quote:а вот 6 базовых параметров практически на 100% незыблемы

Дык на класс же это не тянет. Это всего лишь enum. Класс - это "раса", "класс" (в Днд-шном смысле) или "оружие", но уж никак не конкретные параметры.

Или может быть билдером создавать расу с классом и т.п.?

а про параметры - довльно тонкий вопрос. с одной стороны, это просто число, а с другой - у него подхарактеристики есть, куча производных чисел считается, чеки всякие. и мне не до конца понятно относится ли это к внутренней кухне стата или нет.

Паттерн "билдер" я в своё время толком так и не понял. Точнее гря - я не нашёл особых различий между ним и MVC... Так что тут подсказать не могу.

Если у параметров есть какие-то "подхарактеристики" - тогда да, придётся делать их классом. Странновато выглядит, но придётся...

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

Quote:это базовое число, или текущее значение, или базовое число и список того что на него влияет, или вообще чёрти пойми что.

Вот именно поэтому я и рекомендую использовать проперти. По крайней мере, можно будет просто написать goblin.force = 10 - и не париться, что при этой операции будет изменяться ещё туева хуча "подхарактеристик" персонажа. Только не стоит забывать про ехplicit-конструкторы

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

Я думаю, что все методы, которые принимают хар-ки в качестве параметров, должны быть внешними.

А вообще, можно не париться и юзать распространённый подход: делать всё private - а когда по ходу дальнейшей разработки понадобится "доступ извне", сделать такой метод публичным. Обычно, человеком с опытом уже видит, что какой-то из методов нарушает инкапсуляцию - и он тогда поймёт, что сейчас менять private на public нельзя (и стоит, например, разделить метод на два - "приватную" и "публичную" части).

Есть такая штука:

Вектор объектов "танк". (class Enemy)
Вектор объектов "патрон" летящих в танки. (Class Ammo)

Среди параметров патрона есть Enemy *target (ссылка непосредственно на объект Enemy (танк) )

Проблема:
Танк "взрывается" До того как долетят все патроны. И после взрыва танка патроны теряют цель, и тупо улетают за экран ( и там вечно летят )

Пробовал решить проблему так:
Но во-первых вроде сравнение неверное
А во-вторых вылетает "выход за границы вектора" (в момент исчезновения последнего патрона(выделен желтым кругом) на данного врага)

Есть еще мысли, чтобы патроны взрывались именно в том месте, где был танк (а потом взорвался)

У тебя сама модель построена неправильно. Зачем вообще "патрон" хранит в себе "врага-цель"? И логично, что если уж танк-цель взрывается каким-то "сторонним" образом - то "патрон" не знает, как себя вести. Ведь он перестаёт быть нужным!

Намного правильнее было бы, если бы "патроны" не были привязаны к конкретным "танкам", а летели сами по себе. А проверка "попал или нет" проводилась бы по координатам, а не по "целям". То бишь - проходимся по всем "танкам" и смотрим, не совпали ли их координаты с какими-либо "патронами". Если да - то взрываем все такие "патроны", ведь их может быть несколько (ну и сам танк заодно).

Как бы это решил я:

- для всех игровых объектов создал бы абстрактный класс GameObject, от которого уже затем наследовал бы конкретные (танки, патроны, башни);
- разбил бы игровое поле на квадратные клетки (класс Cell), представляющие из себя спрайты N*N пикселей;
- каждая Cell-клетка хранила бы в себе указатель на GameObject, который показывал бы, чем именно "занята" эта клетка;
- тогда попадание патрона в танк проверялось бы легко: если "новая" клетка патрона уже кем-то занята - то этот "кто-то" взрывается (ну, если умеет).

Забавно) но все так, или практически так) За исключением клеток.

Quote:Намного правильнее было бы, если бы "патроны" не были привязаны к конкретным "танкам", а летели сами по себе. А проверка "попал или нет" проводилась бы по координатам, а не по "целям". То бишь - проходимся по всем "танкам" и смотрим, не совпали ли их координаты с какими-либо "патронами". Если да - то взрываем все такие "патроны", ведь их может быть несколько (ну и сам танк заодно).

Они и летят сами по себе, столкновение определяется так: есть структура Rect с 4 переменными (прямоугольник)
и в каждую 0,1 сек для всех объектов создается по этому Ректу, потом все эти ректы проверяются на столкновение.

Но есть одно Но! А куда им собственно лететь? Им нужно куда то лететь! Наиболее подходящим способом я избрал создать ссылку на объект (target) и черпать из него координаты (target->yy)

Quote:- для всех игровых объектов создал бы абстрактный класс GameObject, от которого уже затем наследовал бы конкретные (танки, патроны, башни);

Присутствует

Quote:- разбил бы игровое поле на квадратные клетки (класс Cell), представляющие из себя спрайты N*N пикселей;

Ну это будет оочень условно. У меня шаг 1 пиксель, и проверка на столкновение обрабатывается чуть ли не до касания бампера танка)

В общем вот можно пощупать (или хотя бы *ехе запустить, лучше 1 раз увидеть чем 100 раз услышать)
Просто не думаю, что у кого то есть желание копаться в моем коде) Но я старался очень и очень структурировано кодить и вроде как прибирался обычно.

P.S. У меня часто вылазит ошибка вектора - но ошибку кажет в _vector.h

Quote: __stl_throw_out_of_range("vector");

Нельзя ли как нибудь настроить, чтобы узнать ГДЕ именно происходит эта неправильность???
Вот опытным путем удалось установить что ошибка в строке 196, ну или +\- 20 строк )

Ошибка очевидна. Внутри вложенного цикла
   for (unsigned int j=0; j<ammo_tower_group.size(); j++)
вызывается метод
   Boom_Enemy(i)
который удаляет i-ый элемент из глобального массива enemy_group.
Однако i после этого не меняется (ведь это вложенный цикл, который работает по j, а не внешний), и поэтому в строке
   ammo_tower_group.at(j).target==&enemy_group.at(i)
вовсе не факт, что enemy_group.at(i) будет существовать.

А вообще, Пакка, твой код по-прежнему представляет из себя мешанину из: названий различного стиля, размазанных по всему файлу классов (что мешает их в отдельные файлы выделить?), отсутствия комментариев и кучи глобальных переменных. Особенно последнее огорчает... Если уж хочешь, чтобы твой код был понятен другому человеку - пиши его так, чтобы он был понятен. Чтобы человеку не приходилось рыскать по всему файлу, дабы узнать - что значит такая-то глобальная переменная...

Quote:Ошибка очевидна. Внутри вложенного цикла

Кстати да, тоже заметил один раз, только потом забыл подумать и больше не возвращался. Эффект замыленности на лицо

Quote:А вообще, Пакка, твой код по-прежнему представляет из себя мешанину

А я думал прибрался... Просто я как дома, для меня все там на полочках))) Не подумал как то что непонятно может быть (

Quote:(что мешает их в отдельные файлы выделить?)

Знания, спасибо что натолкнул, попробую.

Quote: и кучи глобальных переменных

Ну инкапсуляция, имхо, высший класс и вообще оптимизация! Я пока на дне )

Не получается собрать воедино!
Решил вытащить классы в отдельный файл, а они так срослись!

есть Unit1.cpp в нём используется вектор ammo_tower_group;(ниже) пробовал писать extern vector <Ammo_First> ammo_tower_group; - не помогает. (#include "Unit1.h",#include "Unit2.h")
есть Unit1.h
есть Unit2.cpp в нём описание class Ammo_First; вектор vector <Ammo_First> ammo_tower_group; (#include "Unit2.h",#include "Unit1.h")
есть Unit2.h в нём объявление class Ammo_First; (#include "Unit1.h")

вылазит куча ошибок типа
[C++ Error] Unit2.cpp(7): E2238 Multiple declaration for 'vector'
[C++ Error] Unit2.cpp(6): E2141 Declaration syntax error

Вообще порядком запутался что и где екстернить нужно. =(

Смотрел в интернете, есть ситуация 1 в 1, только вместо моего типа Ammo_First там int и все благополучно работает!

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

Вот, только боюсь там немного путанно, ибо я запутался(

Изначальная идея - для каждого класса (всего их штук 5) выделить отдельный файл.
Конкретнее Враги\Патроны\Бункер\Интерфейс\Препятствия.

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

P.S.А почему не залил?) мой любимый)

Так и не понял, где в твоём коде "разбиение классов по файлам". File1 - это всё, что ли? Ну да ладно.

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

"Заголовок" функции - это её тип, сигнатура и дополнительные атрибуты (explicit, inline, virtual, const, throw(), = 0). То есть всё, что стоит перед её фигурными скобками. При этом, внутри хедеров нужно указывать полный заголовок функции, а вот внутри цпп-шников лишь частичный: из атрибутов функции указываются лишь те, что стоят справа от сигнатуры.

Начинать "выделение классов в файлы" стоит с самых мелких классов, которые не зависят от других. И лишь затем переходит к более крупным. Кстати, у тебя строка с инклудом File1.h почему-то стоит выше строки с прагмой - это неверно, поскольку у тебя в этом хедере содержится не стандартный класс, а твой собственный (который может меняться).