[Java]Небольшая реализация пакмана

[Sna1L]

Всем привет!

Долго думал, в какой раздел написать: в Java или сюда(или вообще в вопросы новичков). Хоть это, собсно, игра, но меня больше интересует код.

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

Если Вы потратите на меня немного времени, поглядите в код и дадите какие-то замечания, буду премного благодарен

Писал, как уже упоминал, на джаве. IDE - эклипс.
В общем цепляю архив с jar'ом и исходниками.
Спасибо за внимание!

[Sna1L]

Неужели, никто не сделает замечаний?

[MooNDeaR]

Java не учил еще пока, но по поводу игры хочу сказать несколько вещей:
1. Стиль ничёшный.
2. Раздражает, что нету кнопки "перезапустить"
3. Враг просто УЖАС какой сильный. Раз 7 пытался убежать, но этот засранец слишком хитер)

[Sna1L]

Спасибо, конечно, но я бы всё-таки хотел услышать критику по коду
То, что игра сама по себе убога я и сам знаю)
Делал я ее, чтобы попрактиковаться в ООП и поиграть в пакмана(в итоге поиграл пять минут, ни разу не победил, сматерился и пошел спать).

ЗЫ я тоже джаву не учил. И не знаю, собсно

[Selestis]

Если по коду, то вроде бы константы принято писать в верхнем регистре, а у вас они все по-разному.. И, например, константы направления движения можно бы было вынести в отдельный enum (да и остальные как-то сгруппировать, чтоб не лежало всё в куче: нехорошо иметь возможность сравнить направление с количеством призраков).
В main, когда вы читаете из файла данные, вы не закрываете поток br. В вашем случае это ни на что не влияет, но всё же...
Есть еще такой негласный совет: метод не должен быть высотой в экран или больше. Например в init можно смело вынести загрузку изображений в отдельный метод. Там же, когда идёт куча if'ов: вы в каждом из них берёте значение из двумерного массива

...else if(textOfMap[i][j] == '#')...

- его можно заранее запомнить в переменную и дальше использовать в условиях: в ситуации посложнее могли бы так сэкономить такты проца.

По поводу архитектуры можно кучу мнений собрать, так что решайте сами) Но я бы сделал базовый класс "игровой объект", который бы имел по крайней мере позицию и метод отрисовки. От него бы отнаследовал пакмана и призрака, переопределяя метод отрисовки. А в render перебирать уже базовые объекты. Опять же, в вашем случае, когда таких объектов только 2 типа, это не имеет особого значения, но в какой-нибудь игре побольше с кучей персонажей ваш render раздуется неимоверно и понять что-то будет почти нереально (у самого была такая простыня метода display на 1.5 тысячи строк давным давно, когда не думал о структуре кода). Вот моё мнение, не знаю насколько справедливое, но всё же.

ps. Игра годная, но сложная - AI слишком брутален: поиск кратчайшего пути это слишком читерски, мне кажется :D

[Sna1L]

2Selestis, спасибо большое!
С константами очень согласен:D, весьма убого. Мне кажется направление стоило просто в каждый класс прописать, пусть память и пожрет, но зато писать меньше придется
Насчет наследования: я тупо не додумался до этого. Сейчас я, конечно, понимаю, что это разумно, но, когда писал, даже внимания на наследование не обращал

p.s. мне почему-то всегда казалось, что призраки за тобой бегают. После 5-ти проигрышей стал вспоминать, что "они бегали как-то по-другому"

[Sna1L]

Модераторы, удалите этот пост, пожалуйста. Извините

[Sna1L]

На счет прорисовки, сейчас пришла мысль:
чтобы не обращаться к методам getPrevCoord и т.д., можно реализовать стек в классе Game с методами public push и private pop и туда пихать координаты, по которым происходили изменения. Как Вам?
Проблема в том, что когда они будут друг за другом(прям в соседних клетках) бегать, клетка будет прорисовываться несколько раз

[Selestis]

Вообще обычно делают некое разделение логических частей игры. В большинстве случаев это: графика, механика, физика, ИИ, звук, обработка пользовательских сообщений (input). Причем каждая из них (по хорошему) не должна почти ничего знать о другой. Пусть есть графический объект "спрайт": у него есть картинка и положение. Есть объект "игровой объект", содержащий ссылку на его графическое представление, а также умеет реагировать на некое событие update. При этом это событие понятия не имеет, использует ли игрок джойстик или клавиатуру: там просто проверяется некий набор входных значений, определяющий движение - так у вас и сделано с помощью поля direction.
Что касается getPrevCoord - это лишь следствие вашего построения архитектуры. Попробую пояснить. Если просто абстрактно представить мир, то он состоит из неких объектов. Мир об объектах по сути ничего не знает. Мир просто их содержит, никак на них не влияет (всё что может влиять - другие объекты). А объект уже определяется положением, формой, цветом и т.д. А у вас получается что именно мир (Game) - главенствующая и всеопределяющая сущность, которая, например, может перемещать объекты, убивая их на прежнем месте и создавая в новом - странновато звучит как-то, да? Всё оттого что представить мир в виде сетки с указанием типа объекта в каждой её ячейке вам показалось проще (может, кстати, так оно и есть в данном случае). Но в логическую картину мира выше это не вписывается, отсюда и возникают другие весёлые вещи типа getPrevCoord :-)
Я не говорю вам переделывать, но в моём понимании игра может быть сделана как-то так:
1) у мира есть фон. пусть даже черный - это один объект. умеет только рисоваться и всё.
2) в мире есть осязаемые объекты: пакман, призрак, стена, еда. У них есть координаты, размер (у всех, правда, одинаковый) и некое поведение. Причем поведение 2 типов: реакция на столкновение с другим объектом и реакция на течение времени (update). Скажем, пакман при столкновении со стеной возвращается туда откуда пришел, еда исчезает когда на неё заходит пакман. Это некие события, которые поднимаются этими сущностями как реакция на событие столкновения, поднятое физической подсистемой. Можно сделать обработку реакции и в самой игре при обновлении, а не в сущностях, не суть.
Это, безусловно, сложнее, но позволит гораздо более адекватно и универсально представлять игровой мир, и быть может, с такой системой для следующей игры придется не так уж много менять...

ps. где-то раскопал диаграмму архитектуры одного движка, это чуть более наглядно демонстрирует сказанное мной: http://s1.ipicture.ru/uploads/20120803/YWz471ch.png

[Sna1L]

Selestis, еще раз спасибо.
Немного переписал код, еще не идеал(я полностью согласен с тем, что Вы написали и большую часть сказанного пытаюсь реализовать). Например, я так и не избавился от использования getCoord.

Итак, переписал ИИ, теперь призрак слоняется от стены к стене, пока не увидит пакмана. Победить стало возможным!:D
Еще, игра теперь запускается кнопкой(сначала показывается окошко с кнопкой "запуск").

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

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

PS если кто не видел, в архиве лежит файлик ридми, там описана структура файла конфиг. Т.е. можно переделать карту.