Comments 5
На редкость сумбурно, аж пролистал 80% текста без вникания в него. Упомянуты очереди — хорошо, а как они применены в случае требования синхронизованного с отображением процесса обработки нажатий куда-то там? Упомянуты шейдеры — хорошо, но тут же идет работа с какими-то структурами типа array of int, без объяснения, что это и нафига. Упомянуты глобальные переменные — так скажем плохо, запахло антипаттерном God Object. И всё это перемешано с фразами вроде "при работе с Х нужен апи версии У", которые хотя и могут кому-то пригодиться, но в публичном техническом тексте как минимум мешаются.
Автор, за попытку что-то изучать - огромный плюс! За статью - условный минус (без занесения в карму).
Почему?
Очень плох русский язык, простите. Текст кишит "проезжая мимо станции, у меня слетела шляпа", ага. Местами как будто даже в Ворде не проверяли.
Важность придаётся каким-то случайным моментам, часто связанным с вашими личными переживаниями. Особенно ломают мозг такие предложения, как: "я увидел что есть помимо того что я знаю (я про очереди сообщений), есть ещё mqueue".
Никто из присутствующих не знает ни вас лично, ни объёма ваших знаний. Как говорил один мой наставник, "забудьте слово Я, в науке ваши эмоции на пути к решению проблемы - это факт вашей личной биографии". Чтобы интересно рассказать о пути решения проблемы, надо провести какое-то внятное сравнение, анализ.Кидать куски кода в статью - моветон. Это приемлемо разве что в обучающих статьях, и то очень осторожно. Тем более, в коде вбиты какие-то константы, он специфичен для вашей игры - думаете, кто-то ещё сможет его применить?
Почему-то невежество в некоторых вопросах вы предъявляете в качестве доблести. Как, например, про глобальные переменные. Раз всё просвещённое человечество пришло к такому умозаключению - вероятно, оно имело на то некоторые соображения? Вы в праве с ними не соглашаться - но тогда докажите, чем позиция классиков плоха :)
Код. Ну, придираться не буду, все мы так делали. Но упомяну:
Что за шаманство с подгонкой спрайтов? Должны быть готовые решения. А иначе стоит вашей игре попасть на устройство с другой версией ОС / диагональю / dpi - и всё намертво сломается.
Для определения endianness, а также для правильного чтения ресурсов с его учётом, есть широкое множество библиотек.
В статье нет видео с результатом. Пришлось сходить в паблик.
Ну и вкусовщина. Стартовый экран выглядит хорошо, интересно, приятно. Стильно. Графика геймплея - очень скудная. Почему нельзя было сделать такой всю игру? :)
Отвечу на 7 вопрос, хотя он наверное является риторическим. )
В gameplay сложно придумать что-то такое, чтобы не отвлекало от процесса. Здесь важна концентрация как я считаю, а не разглядывание разным спрайтов.
Ладно, попробую ответить еще на 4 вопрос.
глобальные переменные, это как общие переменные для всей программы. То есть чтобы не писать в одном файле весь код, мы разделяем его на несколько файлов, но так как нам нужны переменные, которые были объявлены в начале файла, то будет удобней просто прокидывать их в нужный файл с помощью extern. Давайте посмотрим один из примеров, который мне сейчас в голову пришел. Объявим массив классов.
Sprite *sp = new Sprite[10];В данном случае мы не можем сразу в конструктор передать какие-либо переменные. Глобальные переменные с помощью extern дают нам возможность использовать любой набор данных и они общие для всех. Я люблю использовать глобальные переменные, просто в этом проекте я решил попробовать не использовать их и нарвался на неудобства. Главное те что нельзя передавать в другие файлы, надо помечать как static. Вообще использования глобальных переменных это особый стиль, важно попробовать и то и то и убедиться самому что тебе больше подходит. Да, возможно если ты пишешь библиотеку для общего пользования, то глобальные переменные не должны иметь силу, чтобы не путать с кодом программиста. Но если у тебя свое приложение, а не библиотека, то это приобретает другой смысл. Я уже пописать успел и так и так и знаю что больше удобно. Ну вот скажи, чем плохи глобальные переменные в своем приложении, если это не библиотека?
Поясняю, почему так не делают. Общие переменные - значит, полностью открытый доступ. Приходи кто хочешь, делай что хочешь. Пока приложение крохотное, простое, делается за неделю и помещается в голове - ага, оно работает и кажется удобным. Но вот приходит время работать над проектом совместно с двумя, тремя, десятью программистами...
Программист Петя объявил у себя глобальную переменную X. Пусть, скажем, это текущее поведение монстра в игре. У себя в коде он чётко знает, каким кодом переменная устанавливается и каким кодом она изменяется.
После этого пришёл программист Вася, который должен дописать "стадный инстинкт" монстрам. Он смотрит - опа, где-то среди 10 тысяч строк кода лежит такая вся невинная переменная. А давай я напишу код, который сам будет в неё ставить что нужно.
Пришёл Дима. Теперь ему поручили написать код, отвечающий за управление монстрами под контролем игрока. Он взял и дописал к 20 тысячам строк кода ещё несколько мест, где переменная изменяется. Часть из них до обновления переменной кодом Васи.
Пришёл Коля. Он решил, что всё работает очень медленно, и давайте-ка сделаем многопоточность. В итоге часть решений, связанных с управлением монстром, он вынес в отдельные потоки. Теперь переменная может ОДНОВРЕМЕННО изменяться из нескольких разных мест.
Вопрос - на каком этапе проекту настанет капут? Вероятнее всего, на этапе Васи ещё можно будет разобраться, где и что изменяется, а вот до Коли "доедут одни только уши". Между прочим, случаи ни фига не выдуманные (:
А если в процессе мы ещё и управляем памятью?..
Потому имеет смысл сразу привыкать к тому, чтобы делать так, чтобы таких проблем не возникало. Великие умы прошлого уже придумали основные "велосипеды".
P.S. Пример вообще не понял. Если нужно создать разом много классов - то можно создать фабрику, которая удобно их сконструирует. Или сконструировать их через foreach. Или ещё пол-дюжины методов на любой вкус и стандарт компилятора. И каждый, каждый из этих методов будет безопасен, легитимен и получит одобрение самого взыскательного критика.
Не, ну вы каких то программистов описываете, совсем тупых. Конечно надо учитывать несколько факторов. Вы пытаетесь найти довод в каком то случае, в котором не приемлемо употреблять глобальные переменные и выбираете для них самый не правильный способ. Надо грамотно подходить к процессу. Например, глобальную переменную указывать как текущий размер экрана, то есть такие общие, которые должны влиять на все места, если они изменяться. Ну вот даже скорость игры, которая должна иногда увеличиваться. У меня например за все квадраты отвечает один спрайт и он начинает рисовать прямо за экраном и так до конца экрана рисует, потом меняет позицию. Если были бы мобы в игре, то мне бы при смене скорости нужно было бы всех мобов в цикле поменять скорость перемещения (то есть как по вашей логике), хотя по вашей логике им можно сделать указатель на эту переменную. ну короче. Если есть глобальная переменная ускорения, то поменяв её, она повлияет на всю игру. Да, те программисты их вашего примера определенно накосячили бы, но так как я объясняю будет намного лучше код пониматься. То есть главный например класс, он меняет скорость игры и всё. Зачем программистам менять скорость в другом месте? Если будут ссылки, то поменяв ссылку, то же самое будет, хотя её можно установить как const для спрайтов. Ну это как я размышляю. Может я и не настолько ещё профессионал, но я уж сам разберусь где использовать глобальные переменные и где нет.
Но вот вы конечно привели способ, чтобы поспорить просто. Потому что общий для моба стадный инстинкт определяется например в конструкторе. Еще раз повторю, глобальный переменные это те, которые должны быть доступны по всех программе, а не только у одного типа класса. Почему я должен с вами спорить вообще. Я больше вам писать не буду, потому что раздражает объяснять.
Как я разрабатывал игру fly bird 2