Итак, версия обновлена. Ссылку, если потеряли, вот здесь : тут. Желательно прикрепить к первому посту.
---
Разработка с моей стороны завершена. Если хотите улучшить игру, то исходники в той же ссылке.
---
Добавлен логотип при запуске игры (вы можете изменить его, редактировав logo.png, соблюдая черные и белые цвета, иначе хрен что получится, можно менять разрешение, лого автоматически масштабируется под экран), запоминание рекорда, и фиксы багов.

NaruTREY, Игра супер получилась! Позже гляну код.
Кстати, если активировать магнит и нажать паузу, то блоки всё равно притягиваться будут.

NaruTREY, И код отличный. Браво

aNNiMON, Но только не RMS.

NaruTREY, Игра действительно хороша, но позволь сделать пару замечаний по коду..
Твой Код хорош для Си, но не для Явы. Не прими за оскорбление
1. Первое, что бросается в глаза - все классы в <default package>. Это совсем не ООП подход
2. Названия переменных. Да, этот код не так громаден, чтобы путаться, но переменные C, z, scrw, a.x, GM, MB и похожие не отражают их предназначения. Пусть переменные будут длинные(lasttimeblinkstatusupdated, doesntrequireforcefocusnotifying), но понятные, чтобы по доступу из других классов(который, кстати, неплохо бы было оформить в виде get/set методов) было понятно, для чего они служат.
3. Большой плюс за комментарии, они частично раскрывают тайны названий C, z, GM, MB, да и вообще "живые"
4. Громадный минус за объединение Модели и Вида(Рендера). Стандартная модель ООП - MVC (Модель-Вид-Контроллер), в которой каждая часть существуюет отдельно. Не стоит в draw методе просчитывать физику и логику. Гораздо лучше только отрисовать текущие даные, которые будут обновляться в другом треде.
5. В RMS классе плохо то, что ты держишь открытым соединение неизвестно долгое время. Любые соединения рекомендуется закрывать так шустро, как это только возможно.
6. И наконец то, о чем я уже говорил: доступ к переменным вне класса путем статического доступа. Это плохо.

Не подумай, что я пытаюсь тебя обвинить, просто прими на заметку) Спасибо за внимание, если кто-то дочитал до конца

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

1. Первое, что бросается в глаза - все классы в <default package>. Это совсем не ООП подход Для Java ME все нормально И так в очень многих играх. 2. Названия переменных. Да, этот код не так громаден, чтобы путаться, но переменные C, z, scrw, a.x, GM, MB и похожие не отражают их предназначения. Пусть переменные будут длинные(lasttimeblinkstatusupdated, doesntrequireforcefocusnotifying), но понятные, чтобы по доступу из других классов(который, кстати, неплохо бы было оформить в виде get/set методов) было понятно, для чего они служат. Обычно, когда я пишу код, то сначала для быстроты печатания я делаю короткие названия переменных, ну а потом в NetBeans переименовываю. Видно я эти переменные забыл или поленился переименовать. 3. Большой плюс за комментарии, они частично раскрывают тайны названий C, z, GM, MB, да и вообще "живые" Ага, комментировать я люблю. Особенно крутой комментарий описания коллизий . 4. Громадный минус за объединение Модели и Вида(Рендера). Стандартная модель ООП - MVC (Модель-Вид-Контроллер), в которой каждая часть существуюет отдельно. Не стоит в draw методе просчитывать физику и логику. Гораздо лучше только отрисовать текущие даные, которые будут обновляться в другом треде. Для этой игры это простительно. Мне просто незачем делать так:
Так как игра слишком проста для этого. Мне легче объединить код в один метод.5. В RMS классе плохо то, что ты держишь открытым соединение неизвестно долгое время. Любые соединения рекомендуется закрывать так шустро, как это только возможно. Да, RMS тут гуавно. Я там накосячил так. 6. И наконец то, о чем я уже говорил: доступ к переменным вне класса путем статического доступа. Это плохо. Зато производительность выше.

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

Длиные имена переменых это-
мазахизм для прогера
(MG42)
Зачем?
Обьявил переменую с коментом и всё
Например: int kx// курсор по иксу
П.С я из-за ваших переменых, когда яву учил, немог понять где переменая, а где команда
Переменая должна быть неболее 3х символов, комбинации хватит на любую программу

NaruTREY, 1. Да ну?) Может, я смотрел "неправильный" код, но везде все расфассовано по пакетам
2. А зря. Лучше потрать пару минут на грамотные названия переменных - потом уже и сам не поймешь
4. Проста - не проста, а делать так все-таки надо. Если не научишься делать в маленьких проектах, то в больших не сможешь все проектировать
6. 4 пункт сводит на нет этот прирост. Да и вообще, телефоны уже давно вышли на другой уровень. А хочешь производительности - пиши на асме)