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

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

Хорошо, допустим. Тогда в чем соль? Разницы никакой, практически. Про внешний вид кода предлагаю не говорить, это не показатель.

Нужно проверить столкновения пули со всеми обьектами, с которыми она должна сталкиваться. Да, здесь нужен перебор. Можно как-то оптимизировать чтобы отбросить лишние обьекты на раннем этапе.

Если пуля имеет обьем, то есть это не точка, а например круг или прямоугольник, можно сделать swept test, особенно если пуля летит по прямой. Если пуля в виде точки, а ее траектория сводится к отрезку (line segment), тогда тест упрощается до проверки коллизии линии с каким либо обьемом (круг, прямоугольник и т.д.).

Swept test прямоугольной (или круглой, вобщем обьемной) пули, имеющей линейную траекторию (лайн сегмент) сводится к формированию прямоугольника в виде движения самой прямоугольной пули от начала лайна до конца лайна. То есть выставив два прямоугольника в начале и конце лайна, также получается новый прямоугольник, внутри которого пуля могла бы двигаться по данной линии от ее начала к ее концу. При таком тесте точка контакта пули с препятствием может быть найдена заранее, при условии что все препятствия статичны, либо тест также должен поддерживать динамические препятствия.

Имхо не показатель, второй вариант быстрее не будет. Можно и while(end != true) написать, и что...

Надо собирать Плейбои и искать плакаты о розыске. Возможно также пройти достижения в Стиме. (Achievements)

Либо тривиально x,y += step_value; Либо интерполируй по линии.

Если интересует, то пиши в ЛС обсудим, может договоримся. Моделить можно в любом софте, результат в формате 3ds.

Рассмотрю также и встречные предложения.

ESRB рейтинг М 17+

MATURE
Titles rated M (Mature) have content that may be suitable for persons ages 17 and older. Titles in this category may contain intense violence, blood and gore, sexual content and/or strong language.

Либо ESRB рейтинг АО 18+

ADULTS ONLY
Titles rated AO (Adults Only) have content that should only be played by persons 18 years and older. Titles in this category may include prolonged scenes of intense violence and/or graphic sexual content and nudity.

Либо по законам страны где зарегистрировано ваше ООО (если вы коммерс). Для бесплатных не интересовался, наверно тоже рейтинг нужен.

Не зная подробностей, слишком сложно ответить на этот вопрос.

Это тоже, но я выделил освещение так как есть в целом два подхода... Первый это вообще без освещения, образно говоря если освещение и есть то это например освещение OpenGL/DX по умолчанию... можно так сказать, что никакое... С таким освещением качество графики зависит только от качества контента, в данном случае это бесшейдерный рендер... Второе это освещение любого типа которое не встроено в ГАПИ, от лайтмапа до SSAO, плюс основные шейдерные эффекты, DOF и т.д. и т.п., в том же числе и вершинное освещение и пиксельное... Партиклы и т.д. я не причисляю сюда... Можно и не шейдерный свет тоже, в принципе... зависит от реализации... Хотя именно красота это понятие имхо спорное... я бы считал в попугаях например... но это уже мощность рендера будет...

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

// Например снести третий элемент из массива, предположим он там есть....
int delete_item = 3;

ObjectsList.erase(ObjectsList.begin() + delete_item);

Если пули видны (хмм 2Д игра что ли...) и у них есть геометрическое представление... можно создать одну пулю в виде геометрии заранее, все остальные создавать динамически в виде позиции (для 2д это два скаляра) и ориентации (для 2д это 4 скаляра), потом при рендере рисовать пулю с геометрией но трансформировать ее матрицей и выставить позицию... Если пуля вышла за пределы экрана, тогда ее удалять... при стрельбе создавать новые... Тогда одни будут удаляться, другие создаваться.. динамически. Пуля с геометрией остается всегда и выступает как прокси для рендера и т.д.

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

Можно сделать без виртуальных функций и наследования вообще...

Если ты хочешь обратиться к функциям одного класса внутри другого класса, можно сделать первый класс глобальным (extern). В таком случае, после создания глобального класса CObject к нему можно обратиться из любой точки программы. Второй вариант - внутри класса CPlayer создать класс CObject, тогда при создании обьекта класса CPlayer этот класс будет иметь в себе также и обьект класса CObject.

Если ты хочешь запихивать в один и тот же массив обьекты разных классов, то есть и CPlayer и CObject, опять же ест вариант без наследования и без виртуальных функций.

Делается это так.. Создается общий класс, например CObjectVarying... Потом ты создаешь enum список, там перечисляешь типы обьектов - например Item, Player, Vehicle, и т.д. Также ты создаешь struct с описанием параметров... Допустим, Position, Orientation а также главное не забыть занести туда элемент типа int и назовем его допустим, Type; После всего этого мы в классе CObjectVarying создаем обьект типа struct, который мы описали... А дальше, всякий раз когда мы создаем обьект класса CObjectVarying, мы просто заполняем наш struct и заодно в нашей переменной Type указываем что у нас за обьект... Потом мы создаем все нужные функции для всех этих типов обьектов внутри класса и в цикле при работе с обьектами проверяем переменную Type и опознаем с каким обьектом именно мы работаем... Вот и все, один класс - много разных типов обьектов... никакого наследования... все просто...

Псевдокод :

Зависит от реализации, если например класс CObject имеет функцию для рендера данного обьекта или например функции для работы с данным обьектом, допустим, инициализацию обьекта (задать хотя бы начальную позицию), тогда эти функции и вызываешь. То есть делаешь в цикле все то что нужно проделать с каждым обьектом. Например рендер каждого из обьектов (при условии что функция Render существует) , итератор я не стал использовать:

Ниже у тебя виртуальная клавиатура, впрочем неважно, здесь нужно просто создать обьект и закинуть его в массив обьектов. Есть одно но - надо бы сделать проверку чтобы создавать только один обьект, потому что при нажатии кнопки у тебя будут создаваться обьекты не один раз, а до тех пор пока ты кнопку пробел не отпустишь (пробел это в данном случае)... Решается это либо вызовом return; после создания обьекта, либо делается переменная типа bool (можно также int)...

Можно использовать тип bool вместо int для отмечания состояния нажатия кнопок.

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

Можно и бесплатно, если например за идею или есть другие выгоды. Навар может выражаться и не в деньгах тоже.

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

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