У меня много скриптов. Я хочу иметь возможность управлять ими все в 1 скрипте. Я хочу, чтобы основной скрипт активировал определенный скрипт, а затем, когда вторичный скрипт завершен, он возвращает значение основному скрипту. После этого главный скрипт вызывает другой вторичный скрипт и т. Д. ...
Есть ли правильный способ сделать это?
Более точный вопрос:
Можно ли активировать скрипт AHK из другого скрипта AHK?
В настоящий момент, чтобы обнаружить, что на вторичном скрипте завершен, способ, которым я в настоящее время пользуюсь, заключается в том, что прямо перед завершением вторичного скрипта я нажимаю комбинацию ключей, которые обнаружит основной скрипт. И как только он будет обнаружен, он увеличит основную переменную сценария на один, и это вызовет активацию следующего скрипта. Есть ли лучший способ достичь этого?
3 ответы
Ниже приведен рабочий пример из документации:
; Example: Send a string of any length from one script to another. This is a working example. ; To use it, save and run both of the following scripts then press Win+Space to show an ; InputBox that will prompt you to type in a string. ; Save the following script as "Receiver.ahk" then launch it: #SingleInstance OnMessage(0x4a, "Receive_WM_COPYDATA") ; 0x4a is WM_COPYDATA return Receive_WM_COPYDATA(wParam, lParam) { StringAddress:= NumGet(lParam + 2*A_PtrSize) ; Retrieves the CopyDataStruct"s lpData member. CopyOfData:= StrGet(StringAddress) ; Copy the string out of the structure. ; Show it with ToolTip vs. MsgBox so we can return in a timely fashion: ToolTip %A_ScriptName%`nReceived the following string:`n%CopyOfData% return true ; Returning 1 (true) is the traditional way to acknowledge this message. } ; Save the following script as "Sender.ahk" then launch it. After that, press the Win+Space hotkey. TargetScriptTitle = Receiver.ahk ahk_class AutoHotkey #space:: ; Win+Space hotkey. Press it to show an InputBox for entry of a message string. InputBox, StringToSend, Send text via WM_COPYDATA, Enter some text to Send: if ErrorLevel ; User pressed the Cancel button. return result:= Send_WM_COPYDATA(StringToSend, TargetScriptTitle) if result = FAIL MsgBox SendMessage failed. Does the following WinTitle exist?:`n%TargetScriptTitle% else if result = 0 MsgBox Message sent but the target window responded with 0, which may mean it ignored it. return Send_WM_COPYDATA(ByRef StringToSend, ByRef TargetScriptTitle) ; ByRef saves a little memory in this case. ; This function sends the specified string to the specified window and returns the reply. ; The reply is 1 if the target window processed the message, or 0 if it ignored it. { VarSetCapacity(CopyDataStruct, 3*A_PtrSize, 0) ; Set up the structure"s memory area. ; First set the structure"s cbData member to the size of the string, including its zero terminator: SizeInBytes:= (StrLen(StringToSend) + 1) * (A_IsUnicode ? 2: 1) NumPut(SizeInBytes, CopyDataStruct, A_PtrSize) ; OS requires that this be done. NumPut(&StringToSend, CopyDataStruct, 2*A_PtrSize) ; Set lpData to point to the string itself. Prev_DetectHiddenWindows:= A_DetectHiddenWindows Prev_TitleMatchMode:= A_TitleMatchMode DetectHiddenWindows On SetTitleMatchMode 2 SendMessage, 0x4a, 0, &CopyDataStruct, %TargetScriptTitle% ; 0x4a is WM_COPYDATA. Must use Send not Post. DetectHiddenWindows %Prev_DetectHiddenWindows% ; Restore original setting for the caller. SetTitleMatchMode %Prev_TitleMatchMode% ; Same. return ErrorLevel ; Return SendMessage"s reply back to our caller. }
теоретически вы также можете использовать файловый объект между сценариями как метод stdin/stdout, так как при открытии файла с файловым объектом вы можете установить его как общий.
Вы также можете установить переменную окружения и передать имя переменной скрипту, учитывая, что у вас есть настройка аргумента в целевом скрипте, который затем устанавливает значение переменной среды при закрытии. используя RunWait, и вы можете узнать, что результат возврата скрипта после запуска.
Наконец, изучите использование функции, поскольку это, вероятно, «лучшая практика» для того, что вы пытаетесь сделать. Поскольку функция может делать все, что может сделать сценарий, и вы можете передать ей массив для работы с или с помощью ByRef в параметре массива. Это означало бы, что вам не нужно писать в кучу параметров при записи функции, и переменные будут освобождать память после завершения функции автоматически. Вы даже можете записать свои функции в отдельный файл и использовать #Include, чтобы использовать их в своем скрипте.
Даже средний Unity3D проект очень быстро наполняется большим количеством разнообразных скриптов и возникает вопрос взаимодействия этих скриптов друг с другом.Данная статья предлагает несколько различных подходов к организации таких взаимодействий от простого до продвинутого и описывает к каким проблемам может привести каждый из подходов, а так же предложит способы решения этих проблем.
Подход 1. Назначение через редактор Unity3D
Пусть у нас в проекте есть два скрипта. Первый скрип отвечает за начисление очков в игре, а второй за пользовательский интерфейс, который, отображает количество набранных очков на экране игры.Назовем оба скрипта менеджерами: ScoresManager и HUDManager.
Каким же образом менеджеру, отвечающему за меню экрана можно получить текущее количество очков от менеджера, отвечающего за начисление очков?
Предполагается, что в иерархии объектов(Hierarchy) сцены существуют два объекта, на один из которых назначен скрипт ScoresManager, а на другой скрипт HUDManager.
Один из подходов, содержит следующий принцип:
В скрипте UIManager определяем переменную типа ScoresManager:
Public class HUDManager: MonoBehaviour
{
public ScoresManager ScoresManager;
}
Но переменную ScoresManager необходимо еще инициализировать экземпляром класса. Для этого выберем в иерархии объектов объект, на который назначен скрипт HUDManager и в настройках объекта увидим переменную ScoresManager со значением None.
После чего, у нас появляется возможность из кода HUDManager обращаться к скрипту ScoresManager, таким образом:
Public class HUDManager: MonoBehaviour
{
public ScoresManager ScoresManager;
public void Update ()
{
ShowScores(ScoresManager.Scores);
}
}
Все просто, но игра, не ограничивается одними набранными очками, HUD может отображать текущие жизни игрока, меню доступных действия игрока, информацию о уровне и многое другое. Игра может насчитывать в себе десятки и сотни различных скриптов, которым нужно получать информацию друг от друга.
Чтобы получить в одном скрипте данные из другого скрипта нам каждый раз придется описывать переменную в одном скрипте и назначать (перетаскивать вручную) ее с помощью редактора, что само по себе нудная работа, которую легко можно забыть сделать и потом долго искать какая из переменных не инициализирована.
Если мы захотим что-то отрефакторить, переименовать скрипт, то все старые инициализации в иерархии объектов, связанные с переименованным скриптом, сбросятся и придется их назначать снова.
В то же время, такой механизм не работает для префабов (prefab) - динамического создания объектов из шаблона. Если какому-либо префабу нужно обращаться к менеджеру, расположенному в иерархии объектов, то вы не сможете назначить самому префабу элемент из иерархии, а придется сначала создать объект из префаба и после этого программно присвоить экземпляр менеджера переменной только что созданного объекта. Не нужная работа, не нужный код, дополнительная связанность.
Следующий подход решает все эти проблемы.
Подход 2. «Синглтоны»
Применим упрощенную классификацию возможных скриптов, которые используются при создании игры. Первый тип скриптов: «скрипты-менеджеры», второй: «скрипты-игровые-объекты».Основное отличие одних от других в том, что «скрипты-менеджеры» всегда имеют единственный экземпляр в игре, в то время как «скрипты-игровые-объекты» могут иметь количество экземпляров больше единицы.
Примеры
Как правило, в единственном экземпляре существуют скрипты, отвечающие за общую логику пользовательского интерфейса, за проигрывание музыки, за отслеживание условий завершения уровня, за управление системой заданий, за отображение спецэффектов и так далее.В то же время, скрипты игровых объектов существуют в большом количестве экземпляров: каждая птичка из «Angry Birds» управляется экземпляром скрипта птички со своим уникальным состоянием; для любого юнита в стратегии создается экземпляр скрипта юнита, содержащий его текущее количество жизней, позицию на поле и личную цель; поведение пяти разных иконок обеспечивается различными экземплярами одних и тех же скриптов, отвечающих за это поведение.
В примере из предыдущего шага скрипты HUDManager и ScoresManager всегда существуют в единственном экземпляре. Для их взаимодействия друг с другом применим паттерн «синглтон» (Singleton, он же одиночка).
В классе ScoresManager опишем статическое свойство типа ScoresManager, в котором будет храниться единственный экземпляр менеджера очков:
Public class ScoresManager: MonoBehaviour
{
public static ScoresManager Instance { get; private set; }
public int Scores;
}
Осталось инициализировать свойство Instance экземпляром класса, который создает среда Unity3D. Так как ScoresManager наследник MonoBehaviour, то он участвует в жизненном цикле всех активных скриптов в сцене и во время инициализации скрипта у него вызывается метод Awake. В этот метод мы и поместить код инициализации свойства Instance:
Public class ScoresManager: MonoBehaviour
{
public static ScoresManager Instance { get; private set; }
public int Scores;
public void Awake()
{
Instance = this;
}
}
После чего, использовать ScoresManager из других скриптов можно следующим образом:
Public class HUDManager: MonoBehaviour
{
public void Update ()
{
ShowScores(ScoresManager.Instance.Scores);
}
}
Теперь нет необходимости в HUDManager описывать поле типа ScoresManager и назначать его в редакторе Unity3D, любой «скрипт-менеджер» может предоставлять доступ к себе через статическое свойство Instance, которое будет инициализировать в функции Awake.
Плюсы
- нет необходимости описывать поле скрипта и назначать его через редактор Unity3D.- можно смело рефакторить код, если что и отвалится, то компилятор даст знать.
- к другим «скриптам-менеджерам» теперь можно обращаться из префабов, через свойство Instance.
Минусы
- подход обеспечивает доступ только к «скриптам-менеджерам», существующим в единственном экземпляре.- сильная связанность.
На последнем «минусе» остановимся подробнее.
Пусть мы разрабатываем игру, в которой есть персонажи (unit) и эти персонажи могут погибать (die).
Где-то находится участок кода, который проверяет не погиб ли наш персонаж:
Public class Unit: MonoBehaviour
{
public int LifePoints;
public void TakeDamage(int damage)
{
LifePoints -= damage;
if (LifePoints <= 0)
Die();
}
}
Каким образом игра может отреагировать на смерть персонажа? Множеством разнообразных реакций! Приведу несколько вариантов:
- надо удалить персонажа из сцены игры, чтобы он больше не отображался на ней.
- в игре начисляются очки за каждого погибшего персонажа, нужно их начислить и обновить значение на экране.
- на специальной панели отображаются все персонажи в игре, где мы можем выбрать конкретного персонажа. При смерти персонажа, нам нужно обновить панель, либо убрать персонажа с нее, либо отобразить что он мертв.
- нужно проиграть звуковой эффект смерти персонажа.
- нужно проиграть визуальный эффект смерти персонажа (взрыв, брызги крови).
- система достижений игры имеет достижение, которое считает общее число убитых персонажей за все время. Нужно добавить к счетчику только что умершего персонажа.
- система аналитики игры отправляет на внешний сервер факт смерти персонажа, нам этот факт важен для отслеживания прогресса игрока.
Учитывая все вышеперечисленное, функция Die может выглядеть следующим образом:
Private void Die()
{
DeleteFromScene();
ScoresManager.Instance.OnUnitDied(this);
LevelConditionManager.Instance.OnUnitDied(this);
UnitsPanel.Instance.RemoveUnit(this);
SoundsManager.Instance.PlayUnitDieSound();
EffectsManager.Instance.PlaySmallExplosion();
AchivementsManager.Instance.OnUnitDied(this);
AnaliticsManager.Instance.SendUnitDiedEvent(this);
}
Получается, что персонаж после совей смерти должен разослать всем компонентам, которые в ней заинтересованы этот печальный факт, он должен знать о существовании этих компонентов и должен знать, что они им интересуются. Не слишком ли много знаний, для маленького юнита?
Так как игра, по логике, очень связанная структура, то и события происходящие в других компонентах интересуют третьи, юнит тут ничем не особенный.
Примеры таких событий (далеко не все):
- Условие прохождение уровня зависит от количества набранных очков, набрали 1000 очков – прошли уровень (LevelConditionManager связан с ScoresManager).
- Когда набираем 500 очков, достигаем важную стадию прохождения уровня, нужно проиграть веселую мелодию и визуальный эффект (ScoresManager связан с EffectsManager и SoundsManager).
- Когда персонаж восстанавливает здоровье, нужно проиграть эффект лечения над картинкой персонажа в панели персонажа (UnitsPanel связан с EffectsManager).
- и так далее.
В результате таких связей мы приходим к картине похожей на следующую, где все про всех все знают:
Пример со смертью персонажа немного преувеличен, сообщать о смерти (или другом событии) шести разным компонентам не так часто приходится. Но варианты, когда при каком-то событии в игре, функция, в которой произошло событие, сообщает об этом 2-3 другим компонентам встречается сплошь и рядом по всему коду.
Следующий подход пытается решает эту проблему.
Подход 3. Мировой эфир (Event Aggregator)
Введем специальный компонент «EventAggregator», основная функция которого хранить список событий, происходящих в игре.Событие в игре - это функционал, предоставляющий любому другому компоненту возможность как подписаться на себя, так и опубликовать факт совершения этого события. Реализация функционала события может быть любой на вкус разработчика, можно использовать стандартные решения языка или написать свою реализацию.
Пример простой реализации события из прошлого примера (о смерти юнита):
Public class UnitDiedEvent
{
private readonly List
Добавляем это событие в «EventAggregator»:
Public class EventAggregator
{
public static UnitDiedEvent UnitDied;
}
Теперь, функция Die из предыдущего примера с восемью строчками преобразуется в функцию с одной строчкой кода. Нам нет необходимости сообщать о том, что юнит умер всем заинтересованным компонентам и знать о этих заинтересованных. Мы просто публикуем факт свершения события:
Private void Die()
{
EventAggregator.UnitDied.Publish(this);
}
А любой компонент, которому интересно это событие, может отреагировать на него следующим образом (на примере менеджера отвечающего за количество набранных очков):
Public class ScoresManager: MonoBehaviour
{
public int Scores;
public void Awake()
{
EventAggregator.UnitDied.Subscribe(OnUnitDied);
}
private void OnUnitDied(Unit unit)
{
Scores += CalculateScores(unit);
}
}
В функции Awake менеджер подписывается на событие и передает делегат, отвечающий за обработку этого события. Сам же обработчик события, принимает в качестве параметра экземпляр умершего юнита и добавляет количество очков в зависимости от типа этого юнита.
Таким же образом, все другие компоненты, кому интересно событие смерти юнита, могут подписаться на него и обработать, когда событие произойдет.
В результате, диаграмма связей между компонентами, когда каждая компонента знала друг о друге, превращается в диаграмму, когда компоненты знают только о событиях, которые происходят в игре (только о интересующих их событиях), но им все равно, от куда эти события пришли. Новая диаграмма будет выглядеть следующим образом:
Я же люблю другую интерпретацию: представьте, что прямоугольник «EventAggregator» растянулся во все стороны и захватил внутрь себя все остальные прямоугольники, превратившись в границы мира. В моей голове, на этой диаграмме «EventAggregator» вообще отсутствует. «EventAggregator» это просто мир игры, некий «игровой эфир», куда различные части игры кричат «Эй, народ! Юнит такой-то умер!», и все прослушивают эфир и если какое-то из услышанных событий их заинтересует, они на него отреагируют. Таким образом - связей нет, каждый компонент независим.
Если я компонент и отвечаю за публикацию какого-то события, то я кричу в эфир мол этот умер, этот получил уровень, снаряд врезался в танк. И мне наплевать интересно кому-нибудь об этом. Возможно, никто не слушает это событие сейчас, а может на него подписана сотня других объектов. Меня, как автора события, это ни грамма не волнует, я про них ничего не знаю и знать не хочу.
Такой подход позволяет легко вводить новый функционал без изменения старого. Допустим, в готовую игру мы решили добавить систему достижений. Мы создаем новую компоненту системы достижений и подписываемся на все интересующие нас события. Никакой другой код не меняется. Не надо ходить по другим компонентам и из них вызывать систему достижений и говорить ей мол и мое событие посчитай пожалуйста. К тому же, все кто публикуют события в мире ничего не знают о системе достижений, даже о факте ее существования.
Замечание
Говоря, что никакой другой код не меняется, я конечно немножко лукавлю. Может оказаться так, что систему достижений интересуют события, которые ранее просто не публиковались в игре, потому как ни одну другую систему до этого не интересовали. И в этом случае, нам нужно будет решить какие новые события добавить в игру и кто будет их публиковать. Но в идеальной игре уже все возможные события есть и эфир наполнен ими по полной.Плюсы
- не связанность компонентов, мне достаточно просто опубликовать событие, а кого оно интересует не имеет значение.- не связанность компонентов, я просто подписываюсь на нужные мне события.
- можно добавлять отдельные модули без изменения в существующем функционале.
Минусы
- нужно постоянно описывать новые события и добавлять их в мир.- нарушение функциональной атомарности.
Последний минус рассмотрим более детально
Представим, что у нас есть объект «ObjectA», в котором вызывается метод «MethodA». Метод «MethodA», состоит из трех шагов и вызывает внутри себя три других метода, которые выполняют эти шаги последовательно («MethodA1», «MethodA2» и «MethodA3»). Во втором методе «MethodA2» происходит публикация какого-то события. И тут происходит следующее: все кто подписан на это событие начнут его обрабатывать, выполняя какую-то свою логику. В этой логике тоже может произойти публикация других событий, обработка которых также может привести к публикации новых событий и так далее. Дерево публикаций и реакции в отдельных случаях может очень сильно разрастись. Такие длинные цепочки крайне тяжело отлаживать.Но самая страшная проблема, которая тут может произойти, это когда одна из веток цепочки приводит обратно в «ObjectA» и начинает обрабатывать событие путем вызова какого-то другого метода «MethodB». Получается, что метод «MethodA» у нас еще не выполнил все шаги, так как был прерван на втором шаге, и содержит сейчас в себе не валидное состояние (в шаге 1 и 2 мы изменили состояние объекта, но последнее изменение из шага 3 еще не сделали) и при этом начинается выполняться «MethodB» в этом же объекте, имея это не валидное состояние. Такие ситуации порождают ошибки, очень сложно отлавливаются, приводят к тому, что надо контролировать порядок вызова методов и публикации событий, когда по логике этого делать нет необходимости и вводят дополнительную сложность, которую хотелось бы избежать.
Решение
Решить описанную проблему не сложно, достаточно добавить функционал отложенной реакции на событие. В качестве простой реализации такого функционала мы можем завести хранилище, в которое будем складывать произошедшие события. Когда событие произошло, мы не выполняем его немедленно, а просто сохраняем где-то у себя. И в момент наступления очереди выполнения функционала какой-то компоненты в игре (в методе Update, например) мы проверяем на наличие произошедших событий и выполняем обработку, если есть такие события.Таким образом, при выполнении метода «MethodA» не происходит его прерывание, а опубликованное событие все заинтересованные записывают себе в специальное хранилище. И только после того как к заинтересованным подписчикам дойдет очередь, они достанут из хранилища событие и обработают его. В этот момент весь «MethodA» будет завершен и «ObjectA» будет иметь валидное состояние.
Заключение
Компьютерная игра это сложная структура с большим количеством компонентов, которые тесно взаимодействуют друг с другом. Можно придумать множество механизмов организации этого взаимодействия, я же предпочитаю механизм, описанный мною, основанный на событиях и к которому я пришел эволюционным путем прохода по всевозможным граблям. Надеюсь кому-нибудь он тоже понравится и моя статья внесет ясность и будет полезной.Слово "спрайт" часто используется в программировании игр для обозначения фигурок героев и предметов. Такие фигурки – это на самом деле рисунки или фотографии, то есть компьютерная графика.
Однако спрайт – не только картинка, это объект, наделенный программным кодом и как следствие свойствами и способностями. Со спрайтом можно взаимодействовать как с виртуальной сущностью, отдавать ей команды и получать от нее данные.
Кот в Scratch – не единственный объект-спрайт. Добавить на сцену другие можно несколькими способами: загрузить картинку с компьютера, нарисовать в самой среде программирования, выбрать из библиотеки. Для всего этого в Scratch предусмотрено специальное меню, которое находится внизу справа на панели спрайтов:
Пока ограничимся тем, что будем выбирать готовые спрайты из библиотеки. Для этого надо нажать лупу. Откроется библиотека, где можно найти подходящего героя.
После клика по нему он появится на сцене. Также на панели спрайтов под свойствами появится его иконка. Рядом с иконкой кота. Свойства объекта, где вы задаете ему имя, положение, размер и поворот, отображаются только для того спрайта, который выделен.
Если вы захотите удалить один из спрайтов, кликните по его иконке под свойствами. Этот спрайт станет выделенным, выбранным, иконка обрамится синим цветом и у нее появится крестик, кликнув по которому можно убрать спрайт из игры.
Когда в Scratch мы собираем блоки в программный код, этот код не существует в прострации сам по себе. Чаще всего он относится к какому-то спрайту. Другими словами, у каждого спрайта свой программный код, своя программа, свое предназначение. Герои могут "общаться" между собой через сигналы, которые посылают друг к другу. Но это другая история.
Сейчас надо запомнить, что когда мы работаем с блоками, следует обращать внимание на то, какой объект выделен. В Scratch появляется подсказка в верхнем правом углу поля редактора кода. Там бледным цветом отображается фигурка выделенного на данный момент спрайта. А значит весь код, который вы видите в рабочей области, относится только к данному герою.
Когда выделяется другой спрайт, то код предыдущего становится невидимым.
Нередко код одного спрайта оказывается похожим на другой. Например, оба героя ходят по сцене, просто с разной скоростью и в разные направления. Собирать два раза почти одинаковую комбинацию блоков – не слишком удачное решение. Проще скопировать программу одного спрайта, добавить ее другому, а потом немного изменить.
В Scratch копировать собранные в программу блоки можно как в пределах одного проекта, так и переносить копию в "рюкзаке" из одного проекта в другой. Рюкзак находится внизу интерфейса среды разработки.
Допустим, у нас есть проект под названием "Проект 1", где мы составили программу движения кота туда-сюда. Мы хотим скопировать этот код в "Проект 2". Тогда мы заходим в первый проект, открываем рюкзак и перетаскиваем сюда конструкцию блоков.
При этом надо помнить правило: переносится участок кода от верхнего блока, за который мы держимся, и блоки, расположенные ниже него. Если вы взялись за блок, расположенный где-то в середине программы, то верхние блоки оторвутся и не будут захвачены.
Положив в рюкзак программу, мы возвращаемся во второй проект. Выделяем спрайт, которому хотим добавить код. Открываем рюкзак и достаем из него нашу программу.
Чтобы скопировать программу одного спрайта на другой в пределах одного проекта, достаточно захватить код и бросить его на иконку другого спрайта, которая расположена под свойствами на панели спрайтов.
Если надо скопировать код в пределах одного спрайта, надо кликнуть по конструкции правой кнопкой мыши и в контекстном меню выбрать "Дублировать".
Также обратите внимание на пункт "Добавить комментарий". Программисты часто пользуются комментариями, чтобы пояснить себе и остальным, что делает та или иная часть программы. Ведь при взгляде на сложный код не всегда сразу можно понять, для чего он, и как все это работает.
Когда на сцене обитают несколько спрайтов, становится важным их положение относительно друг друга, их место на сцене. Как вы уже должны были понять, изучая панель свойств спрайта, положение героя задается координатами, то есть точкой на плоскости.
В Scratch начало отсчета, то есть точка с координатами (0; 0), находится в центре сцены. Общая ширина сцены составляет 480 точек. Это значит, что координата x может принимать значения от -240 до 240. Общая высота сцены составляет 360 точек. Это значит, что координата y может принимать значения от -180 до 180.
Хотя работу с фонами мы будем изучать позже, добавим на сцену координатную сетку. Это поможет нам сориентироваться в системе координат Скретча. Чтобы выбрать фон из библиотеки, надо нажать на лупу в меню сцены, которое находится в нижнем правом углу окна, на панели "Сцена".
Откроется библиотека фонов, прокрутите ее в самый низ и выберите фон "Xy-grid". На сцене появится координатная сетка.
Давайте уменьшим размер наших спрайтов раза в два, то есть примерно до 50%, чтобы они не занимали большую площадь сцены, а больше походили на точку. Теперь поиграем с их координатами. Для этого можно менять значения x и y на панели свойств и смотреть, где после этого окажется герой. Или просто перетаскивать мышью спрайт на сцене и смотреть как меняются x и y в свойствах.
Например, если x = 0, y = 150, спрайт окажется в центре по горизонтали и вверху по вертикали. Если x = 200, y = 0, то спрайт окажется справа по горизонтали и в центре по вертикали.
На самом деле не обязательно до запуска программы устанавливать спрайты в нужное место с помощью мыши или панели свойств. Обычно это делают программно, с помощью специальных блоков кода, находящихся в разделе "Движение". Одним из управляющих местоположением блоков является команда "перейти в x: … y: …". Вместо точек указываются желаемые координаты.
Эта команда быстро перебрасывает спрайт в заданную точку, поэтому ее часто используют в начале программы:
В приведенном примере, где бы ни стоял на сцене спрайт до запуска программы, как только будет нажат зеленый флажок, герой тут же окажется в точке (0; 50).
Отметим напоследок про слои. Наше пространство не двумерное, как плоскость, а трехмерное. У нас есть высота, ширина и длина. Хотя Scratch позволяет создавать только двумерные анимации, на самом деле даже в 2D-анимации есть своего рода третье измерение. Это слои.
Пусть по сцене перемещаются два спрайта. Что будет когда их координаты совпадут? Ничего. Они не столкнуться и не затормозят друг друга. Один спрайт пройдет как бы позади другого, а другой – поверх первого. Каждый живет на своем слое плоскости и ему нет дела до другого.
Однако бывает важно, слой какого спрайта расположен выше, то есть впереди. Посмотрите на рисунок:
Слева слой ракеты расположен выше, слоя кота. Справа, наоборот, кот находится над ракетой.
В Scratch изменить очередность слоев можно как мышкой на сцене, так и с помощью блоков кода. Чтобы это сделать первым способом, надо взять тот спрайт, который должен быть над, и кинуть его на спрайт, чей слой должен быть под.
Блоки изменения очередности слоев находятся в фиолетовой секции "Внешний вид". Это команды "перейти на передний/задний фон" и "перейти вперед/назад на … слоя".
Задание
Составьте программу, в которой один спрайт постоянно ходит за указателем мыши, а второй – находится в центре сцены и, стоя на одном месте, медленно крутится по часовой стрелке. Слой первого объекта должен быть над слоем второго.
