О чем ты? Посмотри в создающиеся вопросы. Люди не могут простой триггер на ГУИ наклепать, куда им до понимания int32. Я согласен с мнением выше о том что статью толком поймет человек знакомый с программированием. Но для полного новичка это слишком сложно.
Вот в такой формулировке - да, согласен.
С другой стороны, в JASS нечего делать тем людям, которым сложно даже в триггерах. Полагаю, стоит написать пояснение по этому поводу в начале статьи.
В качестве альтернативы - можно вдаться в то, чем по факту является память и из этого вывести более чёткое определение.
Можно добавить, что использование кейворда return допустимо также в функциях, которые ничего не возвращают, при таком использовании исполнение функции будет прервано при достижении строки с return. Как правило, используется совместно с условным оператором в теле цикла.
И не только это. :)
Есть уже целый крупный список задач по статье, который позволит сделать её лучше. Об этом подробнее напишу позднее.
Как правило, написание ключевого слова return без ничего будет просто сокращённой формой записи return nothing (вроде бы, запись return nothing заставит синтаксический анализатор ругаться).
Нет, он динамический. Исходный размер при создании - 1024. И расширяется на 1024 ячейки по мере доступа вплоть до максимальных 8192.
Спасибо за пояснение, я этого не знал. То есть, сначала инициализируется 1024 ячейки, когда происходит доступ к следующим 1024-м, инициализируется ещё 1024 и это происходит до максимума в 8192, понял ли я это верно? Мдамс, над статьёй работать ещё и работать...
Хеш-таблица для чего была придумана? В ней же можно хранить индекс боевой единицы, используя её хендл-идентификатор. А ещё есть Set\GetUnitUserData..., если конечно он не забронирован другой системой.
Стоит отдать хэш-таблице должное - она точно ещё тяжелее группы.
с чего вдруг рекурсивные? Обычные циклы-переборы. На Си скорость выходит такая, что любые костыли-попытки на жассе в пролете.
Собственно, моя задача в том, чтобы сделать быструю систему с максимальным взаимодействием с ядром WarCraft III, то есть плагин, а не костыль.
Вот и ищу способ.
чего ты хочешь добиться? ни один костыль не работает быстрее, чем нативка. нативки групп быстрее любого перебора на жассе. доступ к массиву чуть-чуть быстрее, чем к группе, но в 99.9% случаев вы не используете вечные таймеры с 0.02 таймаутом, чтобы это что-то решало.
если работаешь с группами - то так и работай. это связанный список с динамической линковкой юнитов, ничего в нем плохого нет. а про память волноваться следовало в 90х - сегодня +- мегабайт никто и не заметит. Ну а если прям зудит - массив это ~10 байт на служебные и максимальныйиндекс*4 под данные. Группа - ~200 байт под служебные и кол-во юнитов*4 под список
Подождите, подождите. Откуда взяты цифры в 10 байт и в 200 байт?
Разве массив в WarCraft III не предынициализирует 8192 ячейки памяти (по Вашей формуле, в моём случае он потребляет 8192*4=32768 байт, то есть 32Кб)? Он ведь не динамический.
Очень годно, дружище.
Статейка хорошая, полноценная.
Но, присоединяюсь к форумчанам из верхних комментариев: она не для молодых, т.к. умы, не закалённые программированием, не будут читать такую здоровенную уйму текста.
Дело здесь не в закалке. Задача статьи - дать материал, по которому каждый читатель сможет разобраться, на каких китах JASS стоит и как его использовать. Причём если в данной статье главное - это желание, то во многих других "базовых" статьях о JASS (даже в пределах этого сайта) основных определений не дано вовсе, что в дальнейшем затрудняет общение с воспитанными на них программистами, потому что они "плавают" в терминах.
Скорость обучения в них жертвует его качеством.
Насчёт уймы текста
Увы, но JASS нельзя полно объяснить более коротко. Как и было написано в статье...
Вы только что доказали, что некоторые из комментаторов выше неправы в том, что развивающимся программистам (пусть даже и в WarCraft III) статья не нужно. Огромное Вам спасибо!
Я не программист, но неплохо освоил jass, и меня некоторые вещи смущают. Например <...>постоянная функция -<...>
зачем она тогда нужна, не проще взять переменную?
Проще и лучше взять переменную. Вы правы.
Константные функции почти не используют, но, например, многие native-функции константны, так как получают значения из таблиц.
Один из примеров применения пользовательских константных функций - стандарт для написания заклинаний с открытым исходным кодом (JESP). О нём я расскажу, как найду время, в отдельной статье.
Пиши еще, можешь, знаешь например про Vjass =)) про него не много написано, даже я мало знаю
Планирую сделать такие статейки по наиболее распространённым диалектам: vJASS, cJASS, ZINC, WurstScript. Для плавающих в терминах людей руководство по vJASS, например, написано слишком сложным языком.
ты даёшь много информации которая сложна/непонятна для новичков
например раздел родительский тип в таблице
ты и правда думаешь что вася из 5б знает что такое _int32?
Узко мыслите. Вася из 5-го "Б", желающий узнать, что такое __int32 (два знака нижнего подчёркивания, не один) , всегда справится с этим. Тем более, на каждый из основных типов дана ссылка на Википедию, что существенно упрощает понимание того, что это на самом деле такое.
вообще в статье много отсылок к c/c++ (видимо ты изучаешь этот язык, скорее всего ты студент либо джуниор т.к. люди постарше в основном акцентируют внимание на алгоритмах и проектировании)
В статье много отсылок к C и C++ по одной простой причине - на этих языках (даже больше на C, чем на C++) написан код движка WarCraft III.
Скажу честно - не студент, не джуниор, а просто человек, желающий докопаться и донести результаты личного исследования до других, потому что другие также могут извлечь пользу из него.
Голубчик... Если бы люди постарше действительно делали акцент на алгоритмах и проектировании, ошибок и недоработок в программах было бы намного меньше, чем есть сейчас.
так же термины программирования которые ты дал будут бесполезны для большинства людей т.к. нубы просто хотят запилить спел как в доте и срать они хотели на программирование
Нет и ещё раз нет. Статья таргетирована на вполне определённый диапазон аудитории, так что всё написанное в ней полезно и пригодится. Яркий пример - пользователь, оставивший комментарий до Вашего.
а "про" либо забросили джасс давным давно либо работают программистами и знают всю терминологию
Каждый судит со своей колокольни. Возможно, у "про", о которых Вы ведёте сейчас речь, просто нет времени и они ещё вернутся. Возможно, они просто сделали шаг к саморазвитию, а в этом нет ничего плохого. Возможно, они просто почувствовали, что принесут больше пользы в другой сфере. А Вы говорите, "забросили".
Clamp,
Приятно видеть серьёзный подход человека к критике.
Моё предложение - спрятать это критическое резюме под кат, потому что, как по мне, не у каждого пользователя есть желание скроллировать вниз критику, которая и касается-то только автора статьи и интересна (кроме автора, разумеется) лишь узкому кругу лиц.
Мой разбор Вашего резюме
Из персонального фидбэка могу назвать только лирические вставки не по теме (например, про "такой подход - путь к деградации") со ссылками лурк-стайл (в таблице далее - ещё и многократно повторяющиеся), что не очень вяжется с претенциозностью (в самом лучшем смысле) остальной статьи.
Эти вставки предназначались только для того, чтобы немножко поднять настроение автору и этим дать ему мотивацию к продолжению работы над статьёй, а вот почистить их по готовности статьи автор забыл. Прошу прощения.
Си - это всё-таки язык высокого уровня, если придерживаться строгой классификации. На нём действительно можно писать на низком уровне абстракции, но, тем не менее, Си был создан как компилируемый язык, что по факту исключает возможность называть его языком низкого уровня.
Мой явный промах. Свою базу по уровням языков программирования я брал из этой статьи на сайте Tproger. Не понимал до неё, куда конкретно изначально нужно было классифицировать Си (инструментов из разных уровней в нём ну слишком уж много) и решил руководствоваться этим источником.
После Вашего замечания переделал абзац. Теперь мне благодаря Вам окончательно ясно, как чётко структурировать ЯП-ы по уровням.
Предложение сформулировано таким образом, что читателю остаётся непонятно, про Си идёт речь, или про JASS. Если первое, то замечу, что Си - процедурный язык программирования, и нативного функционала работы с событиями (event subscription) в нём нет вовсе.
Разве этот функционал традиционно называют не event handling, а функции не event handler'ами? В любом случае, формулировка уточнена.
Интерпретатор считывает исходный код программы и выполняет его <...> Компиляторы же полностью переобразовывают исходный код программы в бинарный, который целевая система может выполнять самостоятельно (создают исполняемый файл). <...>
Если говорить в отношении "чистого" JASS, то это скриптовый язык, и, следовательно, он именно интерпретируемый. <...>
Советую в соответствии с этим замечанием пересмотреть некоторые формулировки в статье, чтобы не сбивать читателей с толку. В отношении JASS, возможно, это значения не имеет, но сам по себе момент достаточно принципиальный, и неверное его понимание в будущем может выстрелить читателю в колено.
Соглашусь. Конкретизация понятий компилятора и интерпретатора сделала статью более простой для понимания. Надеюсь, что теперь, после редактуры, эти две разновидности трансляторов объяснены правильно.
Не указано, какие "подобные недочёты" имеются в виду. Если это про ошибки из предыдущего абзаца, то замечу, что RB работал из-за совершенно иного недочёта разработчиков игры и был весьма топорно заткнут в патче 1.24. Популярный сейчас Memory Hack технически эксплуатирует ту же самую ошибку.
В новой формулировке этот абзац не нужен вовсе. Так что я его убрал.
Не согласен, понятность кода зависит только от того, как он написан, независимо от ЯП (разумеется, если это не ASM).
Полемично, но логично. Здесь речь шла не о коде, а о его структуре. Но в целях того, чтобы читателя не путать и не дезинформировать, переработал предложение.
Она условно есть, просто появилась случайно
Реальная необходимость работать напрямую с памятью в WarCraft не для хака функционала, который "забыли" добавить в нативки отсутствует => это сложно считать недостатком, скорее просто характеристикой
Убедительно. Убрал это из списка недостатков.
Практически единственное адекватное применение trackable - как раз-таки создание альтернативного внутриигрового UI.
Ну... да, этой конкретизации в абзаце действительно не хватало.
Так и есть, поскольку JASS-скрипт исполняется через VM.
Спасибо огромное за уточнение! Теперь можно убрать эту неопределённость.
Освобождается при смерти потока, но только при условии, что переменной не задано значение. Базовые типы прямо наследуются от типов из Си, поэтому с ними работает его сборщик мусора, и обнулять их не требуется (в статье Скорпа были уточнения на этот счёт).
Очень не хотелось нагружать новобранцев такими понятиями, как потоки (однопоточность и многопоточность), синхронное и асинхронное программирование. Старался упростить.
ЕМНИП, там принципиально различается подход к использованию памяти, это не только удобство.
После внимательного перечитывания организации памяти массивных и немассивных переменных могу только согласиться. Да и объяснение того, что это такое, благодаря Вашему замечанию, теперь в разы понятнее, чем было до редактуры.
Крайне советую разбить пример кода <...> чтобы пояснить разницу между объявлением переменной и её инициализацией. Технически, в JASS это практически одно и то же, но концептуально это разные вещи. Кроме того, кейворд local имеет смысл только после введения в контекст понятия "функция", так как вне её оно не может быть использовано.
Видите ли, здесь такое дело. Получается бесконечный цикл между переменными и функциями. Понимаю, что понятие функции, введённое до его определения - это структурная ошибка в статье, но как её исправить, когда только писал статью, был без понятия.
Помимо этого, в классическом недиалектовом JASS прямого объявления глобальных переменных без приставки udg_ через Редактор нет. Их можно только "дописать" в файл war3map.j в уже сохранённой карте. Хотя, указать в статье наличие такого способа имеет смысл.
Уточнение - только в одном неймспейсе, в противном случае будет использоваться переменная с наименьшей областью видимости. <...> То есть, глобальная переменная может иметь одинаковое имя с функцией. Ну и да, опять-таки, слово "функция" используется раньше пояснения, что это такое. Читатель-то не компилирует, а интерпретирует текст, построчно. =)
Проверил, переработал этот пункт. Весьма нелепый промах с моей стороны. Насчёт использования понятия функции до определения уже упомянуто выше. Весьма красивая аналогия о компиляции и интерпретации, кстати.
Native - родной, функции называют так в силу того, что они предоставляются вместе с языком на правах базовых, и их фактическая реализация находится на более низком уровне абстракции.
И серьёзно, 11я ссылка на одну и ту-же статью в википедии. Мне как читателю стало понятно личное отношение автора к проприетарному софту ещё на таблице, и даже там повторения было избыточными.
Конструктивное замечание о native. Исправлено.
Ссылки на статью о проприетарном ПО в Википедии почищены практически все. На тему проприетарного программного обеспечения я ещё напишу в своём дневнике, когда дойдёт дело до того, чтобы его завести.
ЕМНИП, константы в JASS - это именно константы, а не константные функции. Могу ошибаться.
На самом деле, ключевое слово constant в JASS можно применять как к функциям, так и к переменным. Понимая, что в статье не было уделено достаточно внимания объяснению того, как работает это ключевое слово в одном и в другом случае, исправился.
Лучше написать "прерывается", так как остановка может подразумевать продолжение исполнения в дальнейшем.
Очень конструктивное замечание. Стыдно признаться, но до этого сам называл прерывания остановками.
Можно вынести перед таблицей и не повторять для каждого элемента.
Хотелось дать на это акцент, так как читатель в силу своей невнимательности обычно смотрит только в таблицу, а пояснения над ней читает реже. В данном же случае Ваш вариант имеет место быть.
В целом - весьма здорово написано, видно, что автор вложил довольно-таки много труда, надеюсь, что мой фидбек поможет сделать статью ещё лучше.
Он очень помог. Спасибо Вам огромное за то время, которое Вы уделили этому труду!
слишкам сложна и многа букаф
имхо кмб нужен чтобы научить основам полного нуба
Программирование на самом деле по своей природе в разы объёмнее, чем то, что указано в статье, поэтому фактически она и есть полный курс молодого бойца для того, кто хочет освоить JASS.
Эта статья как раз рассчитана на новичка. Чтобы убедиться в этом, изучите её структуру.
здесь же текст рассчитан на человека знакомого с программированием и терминологией
причём ничего нового для таких людей эта статья не рассказывает
У Вас могло сложиться такое мнение, потому что Вы, наверное, читали статью не с самого начала или не вдумчиво, а обзорно. Её концепция состоит в строгой иерархической последовательности ввода терминов, так, чтобы каждый последующий термин исходил из предыдущего. Это и делает освоение JASS простым для тех новичков, которые действительно пришли его изучить.
красиво, полно, но для молодых бойцов - это все равно что "духов" кинуть в горячую точку. куча излишних уточнений.
Приятно видеть то, что Вы действительно вчитывались в детали. Программирование, на самом деле, несколько более интересная штука - она становится горячей точкой всякий раз, когда в порядке терминов пропадает объяснение одного из них. Это ломает всю структуру.
Как её упростить, чтобы статья больше подходила под молодых бойцов? Об этом я ещё думаю и кое-какие мысли уже есть, но их уже буду реализовывать в новой редакции этого материала.
Кстати, начального значения у переменных нет - они считаются неинициализированными и завалят выполнение при доступе. У массивов это решается тем, что они генерируются при объявлении, поэтому хотя бы в заполенные нулями адреса ты всегда попадешь.
Хорошее, конструктивное замечание. Оно попало в список исправлений. У типов, впрочем, значение по умолчанию всегда имеется, а у скаляров - действительно нет.
ну и про утечки памяти вновь криво сказано. Не страшно, если ты хендл не освободишь, забыл зануллить. Страшно, если ты не уничтожишь объект, который не планируешь использовать.
Формулировку утечек исправил.
Примечательно, что никто не заметил отсутствия раздела о возможных действиях с типами данных. Свёл их в одну таблицу и добавил к основному содержанию статьи.
Незамысловатая, но такая затягивающая аркада. Жаль, что я на Линуксе, а игра его не поддерживает, иначе обязательно, прямо сейчас бы её купил и опробовал. К концу лета я ещё вернусь к ней - там у меня будет кое-что помощнее слабенького Q45.
Не стану писать критики (было бы по меньшей мере невежливо писать критику, не поиграв в то, что критикуется), но опишу то, что мне уже точно понятно, судя по материалам, представленным в проекте, и моё предварительное отношение к этому.
Что понравилось:
Игра слов в названии. Очень порадовал творческий подход.
Графика. Судя по обзору и трейлерам - это отпад. Залип. Всегда любил приятную пиксельную восьми- и шестнадцатибитную графику. Она вернула меня на 10-12 лет назад, когда я страсть как любил рубиться в NES и Super Nintendo, где игры были именно с подобной графикой. Сколько было потрачено времени на неё?
Игровой процесс. На самом деле, бесхитростный, но, тем не менее, затягивающий. Во всяком случае, если я безотрывно смотрел обзор игрового процесса до самого конца, остаётся только предполагать, насколько же интересно в это играть. При этом геймплей Peace, Death! развивает внимательность, умение логически мыслить и принимать быстрые решения.
Наличие мини-игр. Это я сейчас о сейфе. Дифференциация игрового процесса всегда идёт на пользу. Особенно когда речь о таких аркадах. Есть алгоритмы, которые могут быстро решать такие задачи и те, кто знает их, быстро справятся, но всё равно получат удовольствие от присутствия головоломок.
Что не понравилось:
Растянутая по горизонтали страница. Это не к автору, а к комментаторам. Ребята, пожалуйста, прячьте арты в комментариях под спойлеры или уменьшайте их. Читать очень неудобно, особенно с мобильников из-за этого вот.
Отсутствие многопользовательского режима (если я не ошибся, конечно). В такую концепцию идеально впишется режим дуэли с рейтингом Эло (как в шахматах), где одному игроку подбирает случайного соперника, который приблизительно одинаков с игроком по уровню мастерства. Эти дуэльки будут динамичные, а сортировка на скорость - сама по себе очень затягивающая задача. Причём оттуда поломку лифта можно вырезать (просто оставить принцип сортировки, а за ошибку снимать очки). Да и вообще на многопользовательку в такой концепции идей можно придумать массу.
Отсутствие режима бесконечной игры. Кому-то может быть интересно не выполнять ряд миссий, а просто быть эдаким себе хардкорным работягой-жнецом, который задался целью сделать в "Апокалипсисе" состояние. Такие дела.
Вещь полезная, но её реализация какая-то уж слишком неоптимальная. Измеряли ли Вы вычислительную сложность этого алгоритма? Держу пари, Вы диву дадитесь, сколько Ваша реализация этого метода кушает.
Сразу скажу - я не знаю, провоцирует ли такое спамерское "добавление-удаление" способностей боевой единице утечки памяти, потому что исходный код Варкрафта, увы, это тайна за семью печатями.
Немного истории: Способ модификации максимальных параметров боевой единицы (здоровья и маны) был случайно обнаружен 15 февраля 2006 года пользователем сайта WC3C под ником Blade.dk. Он создавал способность, которая давала 50 здоровья за каждый её уровень всем боевым единицам в радиусе её действия. Для манипуляции максимальным здоровьем боевой единицы использовалась способность, сделанная на базе Life Bonus (Greater).
В процессе разработки оказалось, что при повышении уровня способности, базированной на Life Bonus (Greater), она не добавляла максимальное здоровье, которое должна была.
После тщательной серии проверок выяснилось следующее:
При добавлении способности боевой единице она добавляла максимальное здоровье, которое было указано в соответствующем поле для первого уровня способности.
При повышении уровня способности она не меняла здоровье вообще.
При повышении уровня и последующем удалении способности она уменьшала значение максимального здоровья не на значение, указанное в соответствующем поле для первого уровня способности, а на значение, указанное в соответствующем поле для текущего уровня способности.
В результате Blade.dk сделал систему, которая была доведена до блеска. Её можно найти в этой теме на WC3C.
Полагаю, что эти знания пригодятся Вам при доработке Вашего варианта такой системы.
На будущее - пишите JASS в верхнем регистре. Это не слово, а аббревиатура, которая расшифровывается, как Just Another Scripting Syntax, что в переводе означает "Ещё Один Синтаксис Скриптования". Когда Вы это делаете, где-то в мире Вам ставит плюсик один граммар-наци. :)
Всё дело в том, что GUI (или триггеры) - это графическая надстройка для того, чтобы сделать JASS более дружелюбным для новичков-картостроителей. Да, в GUI нет таких понятий, как работа с локальными переменными, функциями и наследование типов объектов, зато GUI отлично подходит для ознакомления с некоторыми возможностями JASS.
Если Вы до этого не имели опыта с программированием, понять JASS Вам будет затруднительно без изучения GUI, но функционал в JASS на три головы выше, поэтому JASS однозначно стоит потраченного на его изучение времени.
Больная тема, нужно переписать эту статью. Я бы помог, да вот не считаю себя JASS-гуру :(
P.S. Всегда писал JASS в верхнем регистре. Смерти желаю тем кто называет JASS - jass'ом.
Все мы далеки от совершенства. Важно лишь то, что конкретно мы делаем для того, чтобы стать на шаг или два ближе к нему.
Небольшой постскриптум
Не стоит желать смерти людям, которые пишут JASS в нижнем регистре. Лучше пожелать им просветления. Ни Вы, ни я не можем знать наверняка - сегодня какой-нибудь человек пишет JASS в нижнем регистре, а завтра он изобретёт решение проблемы в JASS, которую никто до него не мог решить.
А всё потому, что Вы пожелали ему просветления, а не смерти. Всё ведь начинается с малого. :)
Принимая во внимание год написания статьи (воды с того времени утекло немало), автор действительно старался. Плюсую статью за то, что для своего времени она написана очень и очень хорошо. Выписал несколько "заметок на полях", которые помогут ей (сейчас разговор идёт именно о данной статье, исключая её подразделы) стать лучше.
Заметки на полях:
Осторожно, текст!
Даже в предисловии не стоит стращать читателя. Если он зашёл сюда, он решил для себя по крайней мере посмотреть, что такое World Editor. Да и для создания достойных, качественных сценариев никогда не надо сидеть безвылазно. Это чревато определёнными последствиями. Мотивируйте читателя думать, искать подход, применять различные методы улучшения принятия своих решений, а не отказываться от идеи, потому что... В общем, это тоже может быть чревато.
Измените структуру статьи. Сейчас она несколько неорганизована. Нужно больше заголовков, ведь рассказ в разделе идёт не только о возможностях World Editor, но также и о его сильных и слабых сторонах. Не раскрыто, какие модули входят в комплект World Editor (Редактор рельефа (Terrain Editor), Редактор триггеров (Trigger Editor), Редактор звуков (Sound Editor), Редактор объектов (Object Editor), Редактор кампаний (Campaign Editor), Редактор ИИ (AI Editor), Менеджер объектов (Object Manager), Менеджер импорта (Import Manager)).
Преимущества и недостатки стройте на редакторах подобного спектра действий: рассмотрите StarEdit (из первого и второго StarCraft) и сравните его с WorldEdit. В разметке сайта txt2 существует форматирование таблиц, что позволит сделать такое сравнение с лёгкостью.
"Существуют две версии WE: русская и английская. Должен предупредить, что в русской версии нельзя давать русские названия триггерам, регионам, камерам и некоторым другим объектам" По смыслу этого предложения у меня сразу возникает вопрос - ладно, в русской нельзя, а в английской можно? Уверен, что нельзя. Но тогда это надо дать понять в предложении.
На самом деле, World Editor очень гибкий, то есть подстраивается под нужды пользователя максимально. Применяя творческий подход к обыденным задачам, можно даже обойти стандартные лимитации WE (к примеру, возьмите очень популярную карту, сделанную в этом редакторе - DotA Allstars, где у героя Bloodseeker сделан разгон по скорости перемещения даже выше 522, в обход лимита; также заслуживает внимания способность Blueshift героя Disciple of the Moon из карты Tides of Blood, где реализовано даже замедление снарядов у героев дальнего боя, что средствами редактора до этого считалось невозможным). Этим он и хорош.
Надеюсь, что мои рекомендации окажутся полезными для улучшения статьи, чтобы она ещё долгие годы служила новичкам и даже опытным картоделам.
В общем случае, если в правилах не оговорены сроки, всё зависит от менеджера.
Правила не запрещают отправку менеджеру личных сообщений для уточнения деталей.
Наконец, нашёл, на какую исправленную и дополненную статью ссылался автор оригинала. Прочитал и удивился тому, насколько глубоко автор заглянул в JASS и его структуру.
Конструктивно. Заметно, что автор рецензии разбирается в предмете (если я не ошибаюсь, автор разработал интерпретатор для диалекта cJASS (AdicHelper), а это уже говорит об опыте и компетенции). Не упущу случая сделать несколько существенных добавлений к рецензии.
Всё, сказанное под этим спойлером, является субъективным мнением комментатора
Яркий пример нарушения этических норм критики. Не стоит унижать автора, особенно автора того труда, по которому Вы сами обучались программированию на языке JASS. Может, Вы и не хотели, чтобы так читалось, но введение будто бы написано немножко хамоватым тоном. Следом идёт ровно такое же потенциальное унижение читателей. Если изложить суть введения вкратце, то у меня получается следующее: "Как-то учился JASS по статье одного автора, подсознательно понимая, что он где-то неправ, но теперь я с уверенностью и авторитетом заявляю: автор - подлинное недалёкое нубьё. А те, кто даже в его изложении ничего не понял - нубьё похуже автора, недостойное читать мои солнцеликие изречения, проливающие свет истины на ситуацию."
У меня нет претензий к автору, однако, слушается это (как по мне) несколько резко.
Подпишусь под каждым словом. С другой стороны, если нужно быстро "набросать" какую-то рутинную простенькую неарифметическую функцию для того, чтобы посмотреть, как движок будет себя с ней вести (скажем, перемещение всех войск в области в другую точку), редактор триггеров (GUI) для этого отлично подойдёт.
У меня здесь не критика, а вопрос. Исходя из приведённой трактовки локальных переменных ("Память под них выделяется в момент входа в функцию, и освобождается при выходе из нее"), странно как-то получается. Если всё действительно так, как Вы пишете, зачем обнулять локальные переменные в конце функции, ведь при выходе из функции память всё равно будет освобождена? Насчёт использования таймеров - подписываюсь - они намного гибче GUI-шных Wait и PolledWait. Да и не в пример быстрее. И поддерживают значения меньше сотой доли секунды.
Думаю, что vJASS (как и ZINC, как и JESP, как и cJASS) - отдельная тема для рассмотрения, которая достойна отдельной статьи. Здесь под прицелом статья о классическом JASS, том самом JASS "для самых маленьких" - без диалектов, без модификаций, NewGen-паков и прочих наворотов. Поэтому "уродливые udg_" (расшифровка, надо полагать - Uniquely Defined Global - уникально объявленная глобальная переменная) - это требование синтаксиса, а не порок.
А так, в общем и целом... только вопрос выше и ремарка, упрощающая восприятие всего этого раздела: если хранить используемые объекты в локальных переменных, ими становится гораздо легче управлять - создавать, изменять, уничтожать и вытирать ссылки на них.
Мне и самому было интересно, откуда у автора ненормальная зависимость от Wait-ов. Новичкам стоит сразу рассказать, что использовать Wait - плохо, что в арсенале JASS есть такая вещь, как таймеры, что с её помощью можно решить всё гораздо эффективнее. Жирный плюс этому разделу.
Про конструкцию с использованием elseif очень верное замечание. Эта конструкция является одной из очень удобных вещей в JASS. Сюда же стоит отнести и множественный exitwhen с несколькими точками выхода из цикла. Это позволяет проворачивать в WarCraft III более интересные алгоритмы. Официант, ещё одну печеньку автору рецензии. Поправьте ошибку, пожалуйста: не bollean, а boolean.
Меня огорчило наличие BJ в примере автора рассматриваемой статьи без разъяснения того, что такое Native и что такое BJ. Замечание существенное.
Кажется, рецензию на статью Jon'a (это ведь нынешний J?) я написал немного раньше, о её недостатках можно узнать там же, но ссылка сделана правильно. Плюс.
О-о-о, на таких "извлечениях" файла war3map.j из карты какое-то время назад учился программировать и я сам. Крайне интересное чтиво, особенно для тех, кто мало понимает, что изначально "сидит" в карте. Ещё меньше людей знают то, что этот код (та самая заветная функция init или main, каждый зовёт её по-своему) можно изменить только в самом war3map.j при необходимости (и то делать это советую осторожно - неправильная редакция сломает всю карту). Спасибо за ностальгию по моим собственным первым шагам картодела.
DDS, стековая организация, игровой кэш (до 1.24), хеш-таблицы (после 1.24), сортировка массивов... Способов вагон и маленькая тележка. Перебор массива неэффективен, да, но зато это самое простое и понятное для новичка средство поиска нужного объекта. Уже позже ему откроется мир, полный удивительного, но пока что ему просто интересно, как сделать это попроще. Хеш-таблица - тоже вариант объяснения, но требуется как минимум понимание принципа работы двумерных массивов.
Полностью согласен. Да и кроме того, событие триггера, вроде бы, менее поддаётся антиутечному контролю, чем таймер.
Интересная идея с векторами. Она точно будет работать быстрее, чем формула с вызовом Cos и Sin, видел такое решение ещё очень давно в некоторых способностях, сделанных нашими вьетнамскми коллегами-скриптерами. Они утверждали, что есть преимущество в быстродействии. Незначительное, но есть.
Думаю, лучше, чем в уже упомянутой статье Jon'a, нельзя сказать об очистке памяти и сборке мусора.
С 11 по 15 главы чтение уже не имеет смысла, так как Return Bug был убран в обновлении 1.24. Но всё, что там написано - справедливо.
Итог - плюс. Несколько рекомендаций - уделите немного внимания грамматике, а также сглаживанию углов во вступлении. Получится замечательная, образцовая критика.
AlexSan: Предлагаю не разводить флуд (тем более, флейм) на эту тему, такой спор может длиться вечно и истина в нём вряд ли родится. А вот оставить оба наших мнения здесь будет хорошо: тот, кто прочитает их, будет иметь более разносторонний взгляд на эту статейку.
В случае который ты привел тут, лучше последний вариант (все в верхнем регистре). Но в случае с jass'ом, как мне кажется лучше все таки использовать нижний регистр, так как расшифровка не несет особой нагрузки.
Несёт. Она показывает, что это Scripting Syntax, хоть он и Just Another. Смысл в себе несёт всякая аббревиатура, но не все его замечают.
Мне просто всегда казалось что на эту статью человек приходит с мыслью "Нужно подучить jass", но не с мыслью "Хммм, а что это такое".
Вот в какой-то статье типа "Осваиваем редактор карт. Возможности и общее знакомство." такая инфа была бы очень даже к месту.
Как бы так сказать... JASS - это JASS, это отдельная часть редактора карт. Общее знакомство не скажет о нём ничего больше общего обзорного определения, а затем предложит прочитать данный цикл статей по JASS. Сам пришёл на эту статью с мыслью "Что же это такое по мнению автора? Может, есть, чему научиться?"
Кривая аналогия. Тем более что тут первое содержание играет роль навигации и присутствует во всех статьях цикла, а второе лишь как оглавление и показывает читателю, который уже начал читать и вошел в поток, что вообще ему может этот цикл статей дать.
Первое, по большому счёту, объединяет в себе оба вышеуказанных смысла. Не лучше ли будет тогда написать в "теле" статьи что-то вроде: "Прочитав этот цикл статей, вы освоите то-то, то-то, то-то и то-то"?
Да, разный. Но разговорный все таки менее формален, и, как мне кажется, воспринимать новый материал в неформальной подаче в духе "вот давай я тебя сейчас все объясню" гораздо легче чем в форме статьи с википедии.
Да и в конце концов статья написана от лица автора, а не как абстрактная энциклопедическая статья.
На самом деле, на вкус и цвет. Вы тоже правы по-своему, однако, следовать общим правилам гораздо лучше, потому что они охватывают больший процент читателей, давая правильное понимание описываемого. Вам ближе неформальная подача материала, мне ближе чёткий энциклопедический стиль. Оба стиля имеют право на жизнь, если верно излагают материал.
Важная тема. Уметь правильно собирать мусор скрипта очень важно для повышения производительности. Однако, вопреки некоторым комментаторам выше, до статуса великолепной этой статье ещё расти и расти. До того, как писать к статье комментарий, прочёл её раз десять, затем применил свои рекомендации в местной песочнице, чтобы убедиться, что все советы, которые будут даны, действительно помогут статье стать лучше.
Заметки на полях:
Куча текста, открывать на свой страх и риск!
Не обнаружил оглавления. Оглавление - важная часть любой статьи, даже самой маленькой. Согласно статье в Википедии, оглавление ускоряет поиск частей статьи. А если читатель найдёт именно то, что ему нужно (не только найдёт, но и поймёт написанное), он охотно кинет Вам и спасибку, и печеньку, и плюсик в рейтинг. С точки зрения читателя сейчас статья смотрится как один большой "ой-куда-меня-занесло". Отсутствие оглавления создаёт впечатление, что автор статьи ставит своей целью не лаконичное изложение читателю необходимой информации, а собственное самоутверждение. Искренне верю, что это не так и что автор исправится, добавив содержание в начало статьи и упростив читателю навигацию.
Зачем изобретать колесо? Здесь я имею в виду перечисление и описание типов переменных. Для этого на сайте есть определённый цикл статей, где должны быть приведены как основные типы переменных, так и их описания. Заботьтесь о читателе, создавая не "костыли" в виде краткого пересказа общей информации, а грамотную ссылочную структуру на эту самую информацию. Так читателю будет дан максимум необходимой общей информации, а к Вашей статье он направится за разъяснением конкретного случая (в данной статье этот случай - тонкости оптимизации триггеров и JASS-скриптов). Вы будете не конкурировать с другими статьями, а органично дополнять их, ведь хороший автор ставит своей целью не унижение других авторов, а их дополнение либо разъяснение того, что было упущено в их работах, не уменьшая вместе с тем важность их вклада в развитие сегмента. Все авторы обучающих статей фактически делают общее дело (лаконичное донесение необходимой читателю информации), так что здесь не должно быть внутренних скрытых распрей. Прошу прощения, если зря Вас обидел своим мировоззрением.
Так как Ваша статья находится на стыке GUI и JASS, отличной идеей будет предоставление ссылок как на обучающие статьи по JASS, так и на обучающие статьи по GUI (таким образом, статья будет прочитываться на одном дыхании).
Наличие больших кусков кода в тексте статьи существенно затрудняет её восприятие. Большие фрагменты кода лучше прятать под спойлеры. Если читатель нуждается в просмотре кода, он откроет спойлер. Другим читателям, которые, скажем, уже изучали "начинку" BJ-функций и знают её, это существенно облегчит прочтение статьи, а, значит, и усвоение материала.
Будьте ближе к читателю. Откажитесь от использования профессионального сленга там, где можно без него обойтись ("юзать", "джаззер", "триггерщик"). Читатели будут благодарны за то, что Вашу статью легко читать даже новичку.
Многие разработчики модификаций WarCraft III забывают, что JASS - это не слово, а аббревиатура. В частности из-за того, что во многих статьях JASS не пишут в верхнем регистре.
Стоит подчеркнуть, что тип location в чистом JASS рационально использовать только в одном случае - при получении высоты ландшафта в определённой точке (функция GetLocationZ). Для всего остального есть получение координат X и Y.
Хорошо бы добавить статье раздел TL;DR (краткое содержание, аббревиатура расшифровывается как Too Long; Didn't Read - слишком длинно; не читал). Это в своём идеальном варианте таблица с колонками: Тип переменной - Способ очистки в JASS - Способ очистки в GUI. Это позволит ничего не упустить.
Не ставлю минуса - изложение хорошее, но и плюса - много мелочей для доработки.
Надеюсь, что рекомендации действительно оказались полезны.
Всегда ваш,
Звучит больше как придирки, особенно пункты №1, 2, 4 и 6.
А вот со словариком я согласен, в свое время меня это немного сбивало с толку.
Знал, что буду так воспринят, поэтому заранее попросил прощения за расхождение в наших мировоззрениях. Меня учили думать, прежде чем делать.
Насчёт пунктов, воспринятых придирками:
Лично Вам как было бы понятнее, если бы вы не знали смысла: ToEFL, toefl, TOEFL? Последнее больше подсознательно воспринимается как аббревиатура. И это просто личное наблюдение. Простите за граммар-нацизм, но искоренять это - моя обязанность.
А разве плохо дать читателю знать, с чем он имеет дело? На разных ресурсах есть любители раздела Trivia (на русский язык переводится как "Это интересно"). Расшифровка аббревиатуры JASS относится именно к нему.
Если бы Вы сдавали экзамен и Вам дали бы заполнять тест двойного объёма от обычного, неужели Вы не сказали бы, что совершена ошибка?
Литературный и разговорный язык всё-таки вещи разные, согласитесь.
Singularity, прошло 12 лет) Достаточно субъективное мнение, надо бы чтобы кто-то отрецензировал и дополнил статью действительно.
Не претендую ни на последнюю инстанцию, ни на абсолютную истину, но... Срок давности никак не отменяет тот факт, что новичков сюда действительно посылают и они получают информацию в таком виде. Скорее, прискорбно, что вот уже 12 лет происходит такая несуразица. За 12 лет, несмотря на востребованность, статью не редактировали и не дополняли.
Если есть необходимость, могу найти время и оказать посильную помощь в улучшении этого цикла статей, в чём-то уже не актуального (к примеру, Return Bug был исправлен в патче 1.24).
Людей, которые делают свои первые шаги в освоении скриптового языка JASS, часто направляют именно сюда. Решил посмотреть, почему. Разочаровался.
Автор, это же одно из несущих руководств сайта по обучению JASS. Это - первое, что предстаёт взору начинающих JASS-скриптовальщиков. А качество у него ниже среднего. Не подумайте, пожалуйста, что я придираюсь. Цель моих замечаний только в том, чтобы помочь улучшить данный материал.
Сейчас я поведу речь только о секции 0-1 (далее - статья), то есть конкретно о данной части рассматриваемого цикла статей.
Заметки на полях:
Осторожно, много текста!
На протяжении всей статьи автор предпочитает писать "JASS" маленькими буквами. Регистр букв вносит понимание того, что речь идёт об аббревиатуре. То есть, для правильной подсознательной передачи смысла стоит писать не jass, не Jass, а именно JASS. Повторюсь - грамотное написание облегчает восприятие. Любопытный факт - в заголовке официальной статьи о JASS в Википедии аббревиатура не написана в верхнем регистре. Во всех прочих местах статьи написание аббревиатуры верное.
Нигде во вводной части статьи не сказано о том, что JASS расшифровывается как Just Another Scripting Syntax ("Ещё Один Синтаксис Скриптования"). На русский язык аббревиатура JASS переводится как ЕОСС, но так как заимствование английского сокращения гораздо привычнее как в рамках этого сайта, так и в рамках некоторых других сообществ, имеющих WarCraft III в списке своих тематик, мы просто оставим англоязычную аббревиатуру JASS.
Совсем нелишне будет добавить словарик "сленга" (специфических терминов среди тех, кто использует JASS). Далеко не каждый знает, что такое:
Джассер(джасскодер, скриптер, кодер) - человек, знающий и умеющий применять JASS.
Сетить(реже - ассигнить) - присваивать значение какой-либо переменной.
ЯП - аббревиатура от словосочетания "язык программирования".
Гуй(гуи, триггер) - графический интерфейс для работы с JASS. Сленговое определение возникло из англоязычной аббревиатуры GUI (Graphical User Interface), которая переводится как "Графический интерфейс пользователя" как в данном (относительно JASS), так и в общем контексте (в программировании в целом это общепринятый термин).
Компилировать(сейвить, собирать, компилить) - обычно означает сохранять карту для дальнейших проверок работоспособности кода, написанного на JASS. Общее определение компиляции как подготовки кода для обработки процессором сюда не подойдёт, так как JASS работает через посредника - он инструктирует движок, на котором написан WarCraft III, как нужно использовать свои функции, а уже сам движок работает непосредственно с процессором. Таким образом, компиляция JASS - это подготовка кода для корректной работы с движком WarCraft III. Не от всего защищает, правда, но это уже другая история, требующая более детального разбора языка.
Нативки - функции JASS, которые перечислены в файле common.j: эти функции обращаются к функциям ядра WarCraft III напрямую, без привлечения дополнительного кода JASS. Эти функции используются большинством других, которые написаны пользователями (исключая, разумеется, функции, где используется только арифметика) и являются основой JASS.
БЖ - функции JASS, которые перечислены в файле blizzard.j (отсюда и название - BJ или БЖ): подавляющее большинство этих функций активно используют нативки. Некоторые из этих функций действительно полезны и являются дополнительным облегчением нелёгкого труда программиста, другие являются "дубликатами" нативок (БЖ-функция называется так же, как и нативка, которая в ней содержится, с добавлением приставки BJ, иногда с небольшими изменениями аргументов). Из-за того, что большинство БЖ-функций не умеют правильно работать с памятью, их ругательно называют говнокодом. БЖ-функции были изначально созданы для адаптации нативок к GUI (редактору триггеров), чтобы несведующему картоделу было легче разобраться в сути инструкций, которые предоставляет JASS. Небольшой пример - в GUI работа с цветами и альфа-каналом для облегчения восприятия осуществляется в процентах (интенсивность цвета задаётся от 0% до 100%), в то время как нативки работают с целочисленными значениями от 0 до 255 по компьютерному стандарту представления цветов, который известен большинству программистов из школьного курса информатики. Одни ветераны JASS-фронта рекомендуют отказаться от использования BJ-функций вообще, другие - внимательно смотреть их содержание. Сам отношусь к последним.
Начинка - содержание той или иной функции.
Обнуление(реже - нуллификация) - очистка значения переменной-ссылки (типа, сводящегося к типу handle), то есть присвоение ей значения null.
Кастом(реже - КС или CS) - понятие, означающее Custom Script (пользовательский код). Это понятие больше относится к GUI, поскольку означает прямое прописывание строки JASS без конвертации всего триггера в код. Назван по одноимённой функции в арсенале GUI Варкрафта.
Хендл - любой сводящийся к handle тип переменной в JASS (коих 99%, существует только 4 нехендловых типа переменных: integer, real, boolean, string). В силу своей природы и страсти к засорению памяти (к сожалению, сборщик мусора в JASS не реализован), программистам напоминают о необходимости чистки кода, то есть ручном удалении хендлов после их использования. Сленговое понятие возникло из названия родительского типа handle и является его транскрипцией на русский язык.
Хардкод - код, вшитый в ядро, содержание которого мы не можем посмотреть. Зачастую является причиной непонятных вещей в работе программы, потому что программист, увы, не может узнать, что находится за стеной, которой программисты намеренно отделили исходный код ядра от пользователей JASS. Мы не знаем, как код работает с памятью - можем только догадываться. Поэтому хардкод наиболее рационально трактовать как часть кода, скрытая от глаз программиста в каких-либо целях.
Утечки - использованные, ненужные, но не очищенные из памяти объекты, приводящие к падению производительности кода. Начинающие JASS-программисты часто добавляют сюда и понятие висячих ссылок, что неправильно, потому что утечка памяти и висячая ссылка - разные вещи.
Думаю, нет необходимости дважды писать содержание статьи. Тем более, что верхнее кликабельно.
Не бойтесь ссылаться на источники. Смело давайте ссылки на то, что позволит читателю больше узнать об используемом термине. Взять, к примеру, вот этот абзац:
Дело в том, что blizzard создали свой миниязык программирования jass. Они хотели упростить работу по программированию сценариев и их правил. Но даже такой упрощенный язык слишком сложен для многих картостроителей. Поэтому был создан редактор Trigger editor – где вместо того, чтобы набирать команды вручную, можно создавать триггеры путем выбора команд из списка. В редакторе мы работаем с триггерами, но когда игра запускает определенный сценарий, она читает не триггеры, а КОД, который создается путем перевода всех триггеров игры на язык jass.
Эту кучу текста можно сделать намного лаконичнее, вот таким образом:
Для того, чтобы сделать создание карт для WarCraft III более гибким, компания Blizzard Entertainment, создавшая эту игру, также произвела на свет простой событийно-ориентированный язык программирования JASS. В процессе сборки и сохранения карты World Editor проверяет, может ли игра корректно обработать написанный код. Если запуск проверяемого кода не представляется возможным, карта в игре не будет запущена.
Чтобы сэкономить создателям карт время сборки и потраченные нервы на отладку, Blizzard также разработала графический интерфейс для JASS. В редакторе его называют Trigger Editor (редактор триггеров). Если Вы - совсем новичок и делаете первые шаги в долгой, но увлекательной дороге картостроителя и до этого не имели дела с программированием, рекомендую начать своё обучение именно с ознакомления с редактором триггеров, потому что это заметно облегчит знакомство с JASS и его освоение.
Заметьте - несмотря на то, что текста больше, читается он намного легче. Присутствие ссылок на другие ресурсы (как в пределах XGM, так и на общепринятые (Википедия и т.п.)) подчёркивает то, что статья написана человеком, разбирающимся в вопросе, компетентным, ссылающимся на другие материалы ради облегчения восприятия.
Гораздо лучше будет оформить плюсы JASS по сравнению с GUI. То есть сделать сводную таблицу. Посмотрите, как её сделали разработчики Discord. Такое сравнение в разы облегчит восприятие - читатель любит смотреть таблицы и картинки, когда сравниваются различные варианты.
Стоит заметить, что разметка txt2, которую использует сайт, поддерживает вставку таблиц. Эту функцию здесь можно применить по назначению.
У меня (как у читателя) сложилось ощущение, что автор не писал план содержания статьи заранее, а дописывал его уже по ходу дела. В результате из оглавления получился кавардак. По существу для общей статьи ознакомления с ЯП JASS из него потенциально полезны только разделы 0, 1, 2, 3, 4, 5, 6, 10, 12, 15. Разделы 2 и 3 по факту можно соединить в один раздел о локальных переменных.
Между разделами должна наблюдаться связь. Один раздел должен вытекать из другого (либо все остальные разделы должны вытекать из первого). К примеру, при описании преимуществ JASS стоит выделить создание локальных переменных (отсылка к разделу 2-3), доступность большего количества типов для работы с ними (в особенности с типом trackable, для которого поддержка в GUI не предусмотрена), больше возможностей для удаления висячих ссылок (отсылка к разделу 10) и многое другое.
Статья завершается вредным советом. Мне это показало, что автор сам не понимает, чего он хочет - открыть читателю, что такое JASS, или сказать, что JASS неповоротлив и сидеть в графическом редакторе лучше (неправда!) . Задача курса о JASS - мотивировать читателя научиться работать с JASS, с более глубоким уровнем программирования карт, нежели использование графического редактора; дать читателю понять, что было упрощено при помощи GUI.
Автор, Ваша правда, на JASS невозможно сделать с WarCraft III всё, что угодно. Однако, JASS открывает максимальный потенциал World Editor'a. Скажем, создать такую карту, как Гран-при Азерота, одними лишь средствами GUI было бы крайне затруднительно - карта бы не была такой производительной без прямого использования JASS. Порекомендуйте читателю посмотреть исходник этой карты - там найдётся много интересного. У читателя появится мотивация разобрать этот исходник. Доверять Вам они будут из-за того, что карта сделана Blizzard - разработчиками игры, причём для демонстрации возможностей JASS. А Ваш цикл статей должен помочь в этом.
Собственный гибкий AI можно строить и на GUI (есть необходимый функционал). Рифма получилась непреднамеренно... Это не является преимуществом JASS.
Следите не только за подачей материала, но также за орфографией и пунктуацией (увы, здесь она уже столько лет - если верить сайту, с 2005 года, хромает).
Пока что по моим критериям оценивания эта статья заслуживает минус. Изменю свою оценку с повторным рецензированием, если автор поработает над ней кропотливее.
Успехов Вам в нелёгком труде написания статей, а читателям - в освоении материала!
» WarCraft 3 / JASS: Курс молодого бойца
С другой стороны, в JASS нечего делать тем людям, которым сложно даже в триггерах. Полагаю, стоит написать пояснение по этому поводу в начале статьи.
Есть уже целый крупный список задач по статье, который позволит сделать её лучше. Об этом подробнее напишу позднее.
Как правило, написание ключевого слова return без ничего будет просто сокращённой формой записи return nothing (вроде бы, запись return nothing заставит синтаксический анализатор ругаться).
Отредактирован Singularity
» WarCraft 3 / JASS: группа или массив?
Мдамс, над статьёй работать ещё и работать...
Отредактирован Singularity
» WarCraft 3 / JASS: группа или массив?
Вот и ищу способ.
Отредактирован Singularity
» WarCraft 3 / JASS: группа или массив?
Разве массив в WarCraft III не предынициализирует 8192 ячейки памяти (по Вашей формуле, в моём случае он потребляет 8192*4=32768 байт, то есть 32Кб)? Он ведь не динамический.
Отредактирован Singularity
» WarCraft 3 / JASS: Курс молодого бойца
Скорость обучения в них жертвует его качеством.
Константные функции почти не используют, но, например, многие native-функции константны, так как получают значения из таблиц.
Один из примеров применения пользовательских константных функций - стандарт для написания заклинаний с открытым исходным кодом (JESP). О нём я расскажу, как найду время, в отдельной статье.
Скажу честно - не студент, не джуниор, а просто человек, желающий докопаться и донести результаты личного исследования до других, потому что другие также могут извлечь пользу из него.
Голубчик... Если бы люди постарше действительно делали акцент на алгоритмах и проектировании, ошибок и недоработок в программах было бы намного меньше, чем есть сейчас.
» WarCraft 3 / JASS: Курс молодого бойца
Приятно видеть серьёзный подход человека к критике.
После Вашего замечания переделал абзац. Теперь мне благодаря Вам окончательно ясно, как чётко структурировать ЯП-ы по уровням.
Помимо этого, в классическом недиалектовом JASS прямого объявления глобальных переменных без приставки udg_ через Редактор нет. Их можно только "дописать" в файл war3map.j в уже сохранённой карте. Хотя, указать в статье наличие такого способа имеет смысл.
Ссылки на статью о проприетарном ПО в Википедии почищены практически все. На тему проприетарного программного обеспечения я ещё напишу в своём дневнике, когда дойдёт дело до того, чтобы его завести.
Эта статья как раз рассчитана на новичка. Чтобы убедиться в этом, изучите её структуру. причём ничего нового для таких людей эта статья не рассказывает
У Вас могло сложиться такое мнение, потому что Вы, наверное, читали статью не с самого начала или не вдумчиво, а обзорно. Её концепция состоит в строгой иерархической последовательности ввода терминов, так, чтобы каждый последующий термин исходил из предыдущего. Это и делает освоение JASS простым для тех новичков, которые действительно пришли его изучить.
Как её упростить, чтобы статья больше подходила под молодых бойцов? Об этом я ещё думаю и кое-какие мысли уже есть, но их уже буду реализовывать в новой редакции этого материала.
» Peace, Death! / Главная страница
Отредактирован Singularity
» WarCraft 3 / Изменить максимальные HP юниту
В процессе разработки оказалось, что при повышении уровня способности, базированной на Life Bonus (Greater), она не добавляла максимальное здоровье, которое должна была.
После тщательной серии проверок выяснилось следующее:
Отредактирован Singularity
» WarCraft 3 / Jass
» WarCraft 3 / Осваиваем jass (0-1)
А всё потому, что Вы пожелали ему просветления, а не смерти. Всё ведь начинается с малого. :)
» WarCraft 3 / Осваиваем World Editor
Отредактирован Singularity
» WarCraft 3 / Премодерация
Правила не запрещают отправку менеджеру личных сообщений для уточнения деталей.
» WarCraft 3 / Осваиваем JASS - исправления и дополнения
Конструктивно. Заметно, что автор рецензии разбирается в предмете (если я не ошибаюсь, автор разработал интерпретатор для диалекта cJASS (AdicHelper), а это уже говорит об опыте и компетенции). Не упущу случая сделать несколько существенных добавлений к рецензии.
У меня нет претензий к автору, однако, слушается это (как по мне) несколько резко.
Думаю, что vJASS (как и ZINC, как и JESP, как и cJASS) - отдельная тема для рассмотрения, которая достойна отдельной статьи. Здесь под прицелом статья о классическом JASS, том самом JASS "для самых маленьких" - без диалектов, без модификаций, NewGen-паков и прочих наворотов. Поэтому "уродливые udg_" (расшифровка, надо полагать - Uniquely Defined Global - уникально объявленная глобальная переменная) - это требование синтаксиса, а не порок.
А так, в общем и целом... только вопрос выше и ремарка, упрощающая восприятие всего этого раздела: если хранить используемые объекты в локальных переменных, ими становится гораздо легче управлять - создавать, изменять, уничтожать и вытирать ссылки на них.
Поправьте ошибку, пожалуйста: не bollean, а boolean.
Кажется, рецензию на статью Jon'a (это ведь нынешний J?) я написал немного раньше, о её недостатках можно узнать там же, но ссылка сделана правильно. Плюс.
Отредактирован Singularity
» WarCraft 3 / Осваиваем jass (0-1)
Предлагаю не разводить флуд (тем более, флейм) на эту тему, такой спор может длиться вечно и истина в нём вряд ли родится. А вот оставить оба наших мнения здесь будет хорошо: тот, кто прочитает их, будет иметь более разносторонний взгляд на эту статейку.
Сам пришёл на эту статью с мыслью "Что же это такое по мнению автора? Может, есть, чему научиться?"
Отредактирован Singularity
» WarCraft 3 / Оптимизация триггеров и jass кода
Так как Ваша статья находится на стыке GUI и JASS, отличной идеей будет предоставление ссылок как на обучающие статьи по JASS, так и на обучающие статьи по GUI (таким образом, статья будет прочитываться на одном дыхании).
Всегда ваш,
Отредактирован Singularity
» WarCraft 3 / Осваиваем jass (0-1)
Насчёт пунктов, воспринятых придирками:
Отредактирован Singularity
» WarCraft 3 / Осваиваем jass (0-1)
» WarCraft 3 / Осваиваем jass (0-1)
Сейчас я поведу речь только о секции 0-1 (далее - статья), то есть конкретно о данной части рассматриваемого цикла статей.
- На протяжении всей статьи автор предпочитает писать "JASS" маленькими буквами. Регистр букв вносит понимание того, что речь идёт об аббревиатуре. То есть, для правильной подсознательной передачи смысла стоит писать не jass, не Jass, а именно JASS. Повторюсь - грамотное написание облегчает восприятие. Любопытный факт - в заголовке официальной статьи о JASS в Википедии аббревиатура не написана в верхнем регистре. Во всех прочих местах статьи написание аббревиатуры верное.
- Нигде во вводной части статьи не сказано о том, что JASS расшифровывается как Just Another Scripting Syntax ("Ещё Один Синтаксис Скриптования"). На русский язык аббревиатура JASS переводится как ЕОСС, но так как заимствование английского сокращения гораздо привычнее как в рамках этого сайта, так и в рамках некоторых других сообществ, имеющих WarCraft III в списке своих тематик, мы просто оставим англоязычную аббревиатуру JASS.
- Совсем нелишне будет добавить словарик "сленга" (специфических терминов среди тех, кто использует JASS). Далеко не каждый знает, что такое:
- Джассер (джасскодер, скриптер, кодер) - человек, знающий и умеющий применять JASS.
- Сетить (реже - ассигнить) - присваивать значение какой-либо переменной.
- ЯП - аббревиатура от словосочетания "язык программирования".
- Гуй (гуи, триггер) - графический интерфейс для работы с JASS. Сленговое определение возникло из англоязычной аббревиатуры GUI (Graphical User Interface), которая переводится как "Графический интерфейс пользователя" как в данном (относительно JASS), так и в общем контексте (в программировании в целом это общепринятый термин).
- Компилировать (сейвить, собирать, компилить) - обычно означает сохранять карту для дальнейших проверок работоспособности кода, написанного на JASS. Общее определение компиляции как подготовки кода для обработки процессором сюда не подойдёт, так как JASS работает через посредника - он инструктирует движок, на котором написан WarCraft III, как нужно использовать свои функции, а уже сам движок работает непосредственно с процессором. Таким образом, компиляция JASS - это подготовка кода для корректной работы с движком WarCraft III. Не от всего защищает, правда, но это уже другая история, требующая более детального разбора языка.
- Нативки - функции JASS, которые перечислены в файле common.j: эти функции обращаются к функциям ядра WarCraft III напрямую, без привлечения дополнительного кода JASS. Эти функции используются большинством других, которые написаны пользователями (исключая, разумеется, функции, где используется только арифметика) и являются основой JASS.
- БЖ - функции JASS, которые перечислены в файле blizzard.j (отсюда и название - BJ или БЖ): подавляющее большинство этих функций активно используют нативки. Некоторые из этих функций действительно полезны и являются дополнительным облегчением нелёгкого труда программиста, другие являются "дубликатами" нативок (БЖ-функция называется так же, как и нативка, которая в ней содержится, с добавлением приставки BJ, иногда с небольшими изменениями аргументов). Из-за того, что большинство БЖ-функций не умеют правильно работать с памятью, их ругательно называют говнокодом. БЖ-функции были изначально созданы для адаптации нативок к GUI (редактору триггеров), чтобы несведующему картоделу было легче разобраться в сути инструкций, которые предоставляет JASS. Небольшой пример - в GUI работа с цветами и альфа-каналом для облегчения восприятия осуществляется в процентах (интенсивность цвета задаётся от 0% до 100%), в то время как нативки работают с целочисленными значениями от 0 до 255 по компьютерному стандарту представления цветов, который известен большинству программистов из школьного курса информатики. Одни ветераны JASS-фронта рекомендуют отказаться от использования BJ-функций вообще, другие - внимательно смотреть их содержание. Сам отношусь к последним.
- Начинка - содержание той или иной функции.
- Обнуление (реже - нуллификация) - очистка значения переменной-ссылки (типа, сводящегося к типу handle), то есть присвоение ей значения null.
- Кастом (реже - КС или CS) - понятие, означающее Custom Script (пользовательский код). Это понятие больше относится к GUI, поскольку означает прямое прописывание строки JASS без конвертации всего триггера в код. Назван по одноимённой функции в арсенале GUI Варкрафта.
- Хендл - любой сводящийся к handle тип переменной в JASS (коих 99%, существует только 4 нехендловых типа переменных: integer, real, boolean, string). В силу своей природы и страсти к засорению памяти (к сожалению, сборщик мусора в JASS не реализован), программистам напоминают о необходимости чистки кода, то есть ручном удалении хендлов после их использования. Сленговое понятие возникло из названия родительского типа handle и является его транскрипцией на русский язык.
- Хардкод - код, вшитый в ядро, содержание которого мы не можем посмотреть. Зачастую является причиной непонятных вещей в работе программы, потому что программист, увы, не может узнать, что находится за стеной, которой программисты намеренно отделили исходный код ядра от пользователей JASS. Мы не знаем, как код работает с памятью - можем только догадываться. Поэтому хардкод наиболее рационально трактовать как часть кода, скрытая от глаз программиста в каких-либо целях.
- Утечки - использованные, ненужные, но не очищенные из памяти объекты, приводящие к падению производительности кода. Начинающие JASS-программисты часто добавляют сюда и понятие висячих ссылок, что неправильно, потому что утечка памяти и висячая ссылка - разные вещи.
- Думаю, нет необходимости дважды писать содержание статьи. Тем более, что верхнее кликабельно.
- Ссылка Осваиваем JASS - исправления и дополнения не кликабельна. Скорее всего, статья настолько старая, что помнит ещё эру XGM.RU (известно из истории сайта).
- Не бойтесь ссылаться на источники. Смело давайте ссылки на то, что позволит читателю больше узнать об используемом термине. Взять, к примеру, вот этот абзац:
Эту кучу текста можно сделать намного лаконичнее, вот таким образом: Заметьте - несмотря на то, что текста больше, читается он намного легче. Присутствие ссылок на другие ресурсы (как в пределах XGM, так и на общепринятые (Википедия и т.п.)) подчёркивает то, что статья написана человеком, разбирающимся в вопросе, компетентным, ссылающимся на другие материалы ради облегчения восприятия.Стоит заметить, что разметка txt2, которую использует сайт, поддерживает вставку таблиц. Эту функцию здесь можно применить по назначению.
Между разделами должна наблюдаться связь. Один раздел должен вытекать из другого (либо все остальные разделы должны вытекать из первого). К примеру, при описании преимуществ JASS стоит выделить создание локальных переменных (отсылка к разделу 2-3), доступность большего количества типов для работы с ними (в особенности с типом trackable, для которого поддержка в GUI не предусмотрена), больше возможностей для удаления висячих ссылок (отсылка к разделу 10) и многое другое.
Автор, Ваша правда, на JASS невозможно сделать с WarCraft III всё, что угодно. Однако, JASS открывает максимальный потенциал World Editor'a. Скажем, создать такую карту, как Гран-при Азерота, одними лишь средствами GUI было бы крайне затруднительно - карта бы не была такой производительной без прямого использования JASS. Порекомендуйте читателю посмотреть исходник этой карты - там найдётся много интересного. У читателя появится мотивация разобрать этот исходник. Доверять Вам они будут из-за того, что карта сделана Blizzard - разработчиками игры, причём для демонстрации возможностей JASS. А Ваш цикл статей должен помочь в этом.
Успехов Вам в нелёгком труде написания статей, а читателям - в освоении материала!