Посоветуйте книгу по java , libGDX

А что не так пошло конкретно, кроме того, что можно шарик сначала создать и задать нужные свойства, а затем пихать его в список?

А что не так пошло конкретно, кроме того, что можно шарик сначала создать и задать нужные свойства, а затем пихать его в список?

Разве этот код красивый?

Или вот я ещё пытался граф сделать. Тут код специфический и не дописанный до конца.

class Graf {
    ArrayList<GrafNode> nodes;

    public void createGraf(){

    }
    public void bfs(int startNode){
        int count = 1;
        Queue<GrafNode> queue = new LinkedList();
        queue.add(nodes.get(startNode));
        nodes.get(startNode).type = 1;
        while(!queue.isEmpty()) {
            GrafNode node = queue.remove();
            for(int i = 0; i < node.link.size(); i++){
                if(nodes.get(node.link.get(i)).type != 1) {
                    queue.add(nodes.get(node.link.get(i)));
                    count++;
                }
            }
        }
    }

    public void searchBigGroups(){

    }
}

весьма большой набор разных arrayList HashMap и так далее

К слову, некоторые из них любят мусорить в некоторых случаях и лучше пользоваться их аналогами из libgdx.

Есть книга за авторством автора libgdx — Mario Zechner - Beginning Android Games, можно на неё глянуть (правда учитывай то, что книга старая и может не отражать текущее состояние библиотеки).

Не очень, но я если честно сомневаюсь, что где-либо есть книги, обучающие «правильному» и «красивому» коду, т.к. эти понятия на мой взгляд не слишком четкие.

Пока оно РАБОТАЕТ, можно оставить как есть, но не факт, что вернувшись к этому коду через месяц тебе будет приятно на него смотреть. С другой стороны если такое случится, то будет очевидно, что нужно исправить.

В любом случае, мне кажется, что можно сколько угодно вариться в соло режиме, а потом, при выходе в свет, окажется что с точки зрения командной разработки код - говно. Подобно тому, как часто обучение с репетитором/тренером более эффективно, я думаю, что есть некоторый потолок для соло работы. А потому рано или поздно придется влезать в коллективные проекты, или хотя бы смотреть на них.

А для всего остального есть официальная документация и примеры, последние в принципе можно даже использовать в качестве ориентира.

По Java собственно Thinking in Java для основы и официальная документация для остального.

Есть еще его же книга «Программирование игр под андроид» 2013 года выпуска. На английском, может, и 2014 есть что-нибудь.

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

Если интересно – я вижу такие проблемы:

1. Проблемы со стилем. После запятых надо ставить пробелы, операторы надо обрамлять пробелами. Есть официальный Java code style, рекомендуется его придерживаться.

2. Использование поля body в Java не принято. Надо создать геттер и использовать как getBody().

3. Стоит устранить дублирование и вынести pBalls.get(pBalls.size()-1).body в отдельную переменную.

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

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

Вероятно как следствие недописанности, бфс тут нерабочий. :)

Пройденные ноды не помечаются и по факту ничего не ищется.

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

Могу привести свой вариант метода, но не уверен насколько это хорошо с педагогической точки зрения :)

Всегда бесил libgdx, терпел и изучал поделие пока не потребовалось gui. После чего забросил это шило на помойку. Большая часть кода сабжа писали два чела - гребанные энтузиасты. Не смотри как они пишут. И долго не задерживайся.

Предметных претензий давай.

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

Только в плюсе эффективность, масса батареек внутри (GUI, физика, шрифты, рендер текстур и линий), а также куча тестов, которые можно сразу копипастить в рабочий код, и не залезать вовнутрь.

Более того, сейчас они стабилизировались, вот пару лет назад могли взять, и полностью поменять пару сигнатур в новом билде. А сейчас все очень сносно.

без коментариев. Как говорится, тот кто знает - тот поймёт. Если устраивает - то отлично, не стоит обижаться на мой комент)