From: Anna Ivanova Date: Thu, 11 Aug 2016 05:26:40 +0000 (+0500) Subject: Add article and more screenshots. X-Git-Url: http://deadsoftware.ru/gitweb?a=commitdiff_plain;h=a7f4a5218eb5182499ae127d3fc59d85aac7aea9;p=LongFlight.git Add article and more screenshots. --- diff --git a/album.png b/album.png new file mode 100644 index 0000000..e6efceb Binary files /dev/null and b/album.png differ diff --git a/article/article.txt b/article/article.txt new file mode 100644 index 0000000..89e31d2 --- /dev/null +++ b/article/article.txt @@ -0,0 +1,57 @@ +[color=#454545][center]Сожмите протон до одной миллиардной его размера и упакуйте в это пространство столовую ложку вещества.[/center][/color] + + [url=http://annimon.com/forum/?act=post&id=393212]Long Flight[/url] - конкурсная игра, опубликованная в начале 2015 года. В данной статье будет описан процесс разработки. Целью является поделится личным опытом. + +[head]Как всё началось[/head] + Всё началось больше года назад, с первой программы, написанной мной на MIDlet Pascal. Всё что она собой представляла - это множество белых точек на абсолютно чёрном фоне. Тогда это было весьма трудно назвать космосом, но уже было нечто похожее: так называемые звёзды циклически падали вниз. +[center][img=screenshot0.png]screenshot0.png[/img][/center] + Тогда, в принципе, всё было идеально: я являлся героем в своих глазах, а небольшой код в несколько десятков строк вызывал во вне чувство гордости за себя, что вся эта куча символов вообще работает. + +[head]Акт 1: StarFire. Первая попытка[/head] + Спортивный интерес не давал мне остановиться, меня затягивало всё сильнее и сильнее: я добавил космический кораблик и возможность им управлять, а в скором времени были добавлены враги и пули. Разработка продолжалась, и уже к январю 2014 года была создана первая тестовая версия игры. Аркадка к тому времени выглядела намного милее: +[center][img=screenshot2.png]screenshot2.png[/img][img=screenshot1.png]screenshot1.png[/img][/center] + Код становился всё больше и больше, и уже здесь возникли первые проблемы - бэкапы, откат изменений, редактирование больших участков кода, бесконечные рефакторинги, вечное стремление к идеальному коду, и так далее... Я мог в первый день написать кучу кода без предварительного проектирования, на следующий день заняться переименовыванием переменных или подпрограмм, а на третий половину кода заменить на что-то новое. А ещё позже вообще может оказаться, что нужно сделать откат! И попробуй тут выкручивайся с тысячами бэкапов - голова кругом пойдёт!.. [i]А все проблемы решаются простым способом - просто их не нужно создавать или стремиться сводить их появление к нулю.[/i] +[spoiler=О том, как это можно сделать] + О разработке программного обеспечения есть [url=http://annimon.com/download/index.php?act=view&id=378]очень хорошее руководство для начинающих[/url], оно так и называется - "Разработка программного обеспечения", написанное Виктором Мельником. Более точно к этому вопросу обращается С. Макконнелл в книге "Совершенный код". + Об управлении версиями и почему это так важно вы можете почитать в статье "[url=http://annimon.com/article/764]Лёгкое введение в git[/url]". Хорошим справочником по работе с git может послужить книга S. Chacon - "Pro Git". +[/spoiler] + +[head]Акт 2: Space in Fire. Продолжение[/head] + Теперь разработкой занимался уже не один человек, а несколько: один занимался программированием, а второй разработкой дизайна и графики. Проблемы возникли, когда от MIDlet Pascal требовалось намного больше, чем он умеет. Таким образом, спустя один месяц игра встала на продвинутый уровень развития, переписанная уже на языке Java - именно здесь и начался сущий ад. Разработка велась на протяжении 5 месяцев, после чего была заброшена. Как же так получилось? Вообще-то никакого продолжения не должно было быть - задуманная игра была уже почти доделана. Именно в этот момент в полную силу была ощутима ошибка неправильной разработки: несогласованность действий, несерьёзное отношение к проектированию. А результат - два человека вместе занимались разработкой двух разных игр. Перед тем, как делать продолжение игры, нужно было выяснить, каким оно является и будет ли это вообще продолжением, а не созданием новой игры. Прежде чем приступать к кодингу, необходимо всё расставить по полочкам и продумать каждую мелочь; заниматься разработкой следует в хронологическом порядке, а именно: не нужно делать всё и сразу вместо того, чтобы сконцентрироваться на чём-то определённом и сделать это качественно (а для этого необходимо умение распределять своё время); нужно быть честным: движок к этой игре было нереально сложно разрабатывать, да и оптимизировать под Java ME тоже весьма непростая задача. Именно это и послужило тому, что проект почти не развивался, но на него были потрачены огромные усилия. Таким образом, исходный код StarFire был утерян, а на исходники Space in Fire уже не было никакого смысла смотреть. +[center][img=screenshot3.png]screenshot3.png[/img][img=screenshot4.png]screenshot4.png[/img][/center] + События со стороны дизайнера тоже развивались интересно. Еще давным давно я (SashaG) привык, что мой Nokia X2-00 заменяет мне компьютер. Вот только с кодингом были проблемы: ни Mobile BASIC, ни MobPascal не были подходящими инструментами разработки; поэтому времени было валом и было чем заняться. Довольно долго и много я рисовал в ProPaintMobile и на обычно пустующей MicroSD-флешке собрался приличный архив графики, различных модов и тем. Но этим я ограничиваться не хотел, мне нужна была игра, ибо мне порядком все надоело, однажды я сказал: "так лень жить, что аж лень умирать"... Внезапно стукнула идея сделать порт Космических Рейнджеров. Так как с кодом я ничего поделать не мог, я решил, что даже просто графика - уже хорошо. Рисую я не как все. Удобно сохранять каждый этап, ибо тут слоев никаких нет, а мне порой нужно было откатить изменения. Название каждой картинки было примерно таким: "file_aaa.png". Количество "а" означало номер этапов. Иногда я пользовался другими буквами (когда размер имени файла норму превышал, например). С каждым новым пикселем одновременно формировались самые разные идеи, которые иногда даже выходили за рамки проекта... Внезапно я наткнулся на игру Kalter'а. Естественно, предложил сотрудничать. Увидев предоставленные мной наброски, он согласился. С этого момента игра терпит изменения. Так как у меня было много идей, то я через своего коллегу делал свою игру. В чем же была идея игры? - Пошаговой я ее видеть не хотел, нужен был драйв. В остальном это была двухмерная версия Galaxy on Fire 2 или аркадный вариант Космических Рейнджеров, как угодно. Так начался Space in Fire. Самый первый шаг - сделать управление, подобная реализация была в игре GangStar для мобильников. Тут было много веселья... Взяв ручку и бумагу, я вывел тригонометрические формулы (что само по себе странно) и передал коллеге. Первый билд комом. Корабль летал опираясь на свои собственные законы и было сложно понять, что с ним происходило. Заметив некую закономерность, я попросил уменьшить скорость корабля и понял, что он поворачивает в обратном направлении (то есть, при нажатии вправо – поворот против часовой стрелки, к примеру). Быстро пофиксили и получилась веселая леталка без ничего. Далее серьезных изменений игра не перетерпела и постепенно проект остановился. Проходит время... Случилось многое, но об этом не здесь. Уже лучший друг Kalter поведал мне о конкурсе (к сожалению, когда половина времени на разработку проекта прошла). Я взялся за свой проект, а он делал свой. Почти сразу он попросил разрешения брать мою графику (которая предназначалась для Space in Fire) и я, конечно, разрешил. В тяжелейших духовных поисках я пытался создать более-менее годный дизайн. Чтобы проект выглядел целостным нужны были единые гайдлайны. Возможные вариации дизайна проекта (их могло быть значительно больше): +[center][img=gfx0.png]gfx0.png[/img][img=gfx1.png]gfx1.png[/img][img=gfx2.png]gfx2.png[/img][img=gfx3.png]gfx3.png[/img][img=gfx4.png]gfx4.png[/img][img=gfx5.png]gfx5.png[/img][/center] + +[head]О том, как было реализовано управление в Space in Fire[/head] + Выведем несколько основных формул. Так как действие происходит в декартовой двухмерной системе координат, и лететь нужно строго, куда смотрит кораблик, вводим новую векторную величину, характеризующую изменение положения кораблика, прямо зависимую от скорости (speed) и обратно зависимую от промежутка времени (frame). Обозначим её, как step и запишем в следующем виде: +[math]\[step=\frac{speed}{frame}\][/math] +Так как промежутком времени будет считаться один кадр, переменную frame можно опустить. Тогда зависимость станет прямой: +[math]\[step=speed\][/math] +Переводим в скалярную форму. Для этого нам нужно знать угол (обозначим его через [math]\[\alpha\][/math]) и применить тригонометрические функции. Тогда выражение примет следующий вид: +[math]\[stepx=cos\alpha*speed\][/math] +[math]\[stepy=sin\alpha*speed\][/math] +Это и есть величины, характеризующие изменение положение кораблика за один кадр. + +[head]Акт 3: Long Flight[/head] +[center][img=album.png]album.png[/img][/center] + Цель была такова: сделать простую, но красивую леталку. Основной упор работы шёл на качество исполнения. Время распределял по своим возможностям и силам, от чего на создание непосредственно самого игрового процесса времени выделялось не много. Прежде чем начать разработку подготовил все необходимые инструменты: + [b]*[/b] Java ME SDK 3.4 - инструменты разработки под Java ME + [b]*[/b] NetBeans IDE 8.0 - удобная среда разработки +Для тестирования использовались 3 эмулятора: + [b]1.[/b] KEmulator 1.0.0 + [b]2.[/b] MicroEmulator 2.0.4.63 + [b]3.[/b] Pstros +Приходилось находить компромисс между первыми двумя: первый мог исполнять нерабочий код, а второй иногда не мог исполнять рабочий код. Третий эмулятор во многом аналогичен второму. +Для удобства написания игры было создано 3 проекта среды NetBeans: + [b]*[/b] Debug + [b]*[/b] Release + [b]*[/b] Crypto +Дам описание каждой из них: + [i]Debug[/i] - первичная версия проекта. Содержит необходимую отладочную информацию - она является очень удобной, поскольку упрощает поиск и исправление багов. Допустим, если возникнет какое-либо исключение, оно тут же будет перехвачено и передано на консоль эмулятора, где будет выведен стек-стрейс и полный путь к возникшему исключению (с точностью до строчки в исходном коде!). + [i]Release[/i] - окончательная версия проекта. Все ресурсы шифруются, классы обфусцируются, удаляется отладочная информация. + [i]Crypto[/i] - отдельный проект, шифрующий ресурсы. +Так как разработка велась на разных устройствах, а следовательно необходим чёткий контроль версий, был создан локальный git репозиторий. К тому же NetBeans дружит с git и осуществляет удобную работу с ним. + Сначала сделал заготовку (были созданы все игровые экраны), ближе к новому году была создана игра, а все последующие дня были отведены для исправления багов и неточностей. Разработка в целом велась благоприятно, и проект был сдан в намеченные сроки. +[center][img=screenshot5.png]screenshot5.png[/img][img=screenshot6.png]screenshot6.png[/img][/center] + +На этом всё. [url=https://github.com/KalterFive/LongFlight]Исходники[/url] можно найти на GitHub. \ No newline at end of file diff --git a/article/gfx/gfx0.png b/article/gfx/gfx0.png new file mode 100644 index 0000000..4003de8 Binary files /dev/null and b/article/gfx/gfx0.png differ diff --git a/article/gfx/gfx1.png b/article/gfx/gfx1.png new file mode 100644 index 0000000..a9209a6 Binary files /dev/null and b/article/gfx/gfx1.png differ diff --git a/article/gfx/gfx2.png b/article/gfx/gfx2.png new file mode 100644 index 0000000..1838d8d Binary files /dev/null and b/article/gfx/gfx2.png differ diff --git a/article/gfx/gfx3.png b/article/gfx/gfx3.png new file mode 100644 index 0000000..91af7c2 Binary files /dev/null and b/article/gfx/gfx3.png differ diff --git a/article/gfx/gfx4.png b/article/gfx/gfx4.png new file mode 100644 index 0000000..b19a94c Binary files /dev/null and b/article/gfx/gfx4.png differ diff --git a/article/gfx/gfx5.png b/article/gfx/gfx5.png new file mode 100644 index 0000000..cdd4dba Binary files /dev/null and b/article/gfx/gfx5.png differ diff --git a/article/screenshot/screenshot0.png b/article/screenshot/screenshot0.png new file mode 100644 index 0000000..6660f6f Binary files /dev/null and b/article/screenshot/screenshot0.png differ diff --git a/article/screenshot/screenshot1.png b/article/screenshot/screenshot1.png new file mode 100644 index 0000000..2d8bf39 Binary files /dev/null and b/article/screenshot/screenshot1.png differ diff --git a/article/screenshot/screenshot2.png b/article/screenshot/screenshot2.png new file mode 100644 index 0000000..30dd81d Binary files /dev/null and b/article/screenshot/screenshot2.png differ diff --git a/article/screenshot/screenshot3.png b/article/screenshot/screenshot3.png new file mode 100644 index 0000000..617cd92 Binary files /dev/null and b/article/screenshot/screenshot3.png differ diff --git a/article/screenshot/screenshot4.png b/article/screenshot/screenshot4.png new file mode 100644 index 0000000..d999a88 Binary files /dev/null and b/article/screenshot/screenshot4.png differ diff --git a/article/screenshot/screenshot5.png b/article/screenshot/screenshot5.png new file mode 100644 index 0000000..e602cb3 Binary files /dev/null and b/article/screenshot/screenshot5.png differ diff --git a/article/screenshot/screenshot6.png b/article/screenshot/screenshot6.png new file mode 100644 index 0000000..fc18212 Binary files /dev/null and b/article/screenshot/screenshot6.png differ diff --git a/article/screenshot/screenshot7.png b/article/screenshot/screenshot7.png new file mode 100644 index 0000000..feb2576 Binary files /dev/null and b/article/screenshot/screenshot7.png differ