Класс Ball, как вы описали, действительно хорошая идея. Таким образом, вы можете повторить его, если, как в некоторых «прорывных» играх, вам когда-нибудь захочется создать два или более шаров - или если вы захотите повторно использовать этот код в другой игре. Вы также можете иметь класс Paddle с аналогичными координатами X, Y (или получить как Ball, так и Paddle из класса «ScreenObject», если выяснится, что они имеют много таких похожих членов). Paddle может читать переменную общего доступа, которая обновляется потоком / событием, получающим пользовательский ввод.
Простые столкновения, такие как со стенами, могут быть выполнены в вашем классе Ball на основе глобально доступных значений, таких как размеры экрана. Ваша процедура обновления может просто обратить вспять один компонент скорости, когда эта конкретная стена поражена. Вы можете определить и установить делегат / обратный вызов в классе Ball для воспроизведения звука, когда мяч подпрыгивает. Аналогично, в обновлении Paddle можно проверить размер экрана, чтобы вы не могли переместить весло за пределы экрана.
Как и рекомендовано TottiW, столкновение между объектами лучше всего выполнять в родительском классе «manager», который владеет всеми объектами или имеет доступ к их элементам X, Y или ограничительным рамкам. Это хороший объектно-ориентированный дизайн. Ball и Paddle не должны иметь доступа к позициям X, Y друг друга! ... но менеджер делает. Это также может устранить избыточные проверки столкновений. Если объект A проверяется на столкновение с объектом B, B не должен впоследствии проверять наличие столкновения с A. Таким образом, на самом деле все, что нужно сделать вашему классу менеджера, это проверить для каждого Весла положение каждого Шара. Это может быть еще более упрощено, так как весло может двигаться только в одном направлении, скажем, горизонтально, в фиксированной позиции Y. Таким образом, ваша первая проверка может немедленно устранить любой Ball.Y
В играх с большим количеством объектов вам не нужно обнаруживать столкновения для всех, только для ближайших. В этом случае «менеджер» становится больше «менеджером сцены», который хранит связанные списки объектов в направлениях X и Y. Когда объекты проходят мимо других объектов, они обмениваются указателями в списках, поэтому списки всегда остаются отсортированными. Таким образом, для любого данного объекта мы знаем объекты непосредственно слева / справа / сверху / снизу, поэтому нам нужно только проверять столкновения с этими ... экономя много времени и заставляя вашу игру работать с максимальной скоростью. Может быть, вы не до этого момента, хотя!
Удачи и, как говорили другие, веселитесь!